Discharge Lens
Inspiration
Medical discharge papers are fundamentally broken. They're written in dense clinical jargon by exhausted doctors, then handed to equally exhausted patients who are in pain, heavily medicated, or simply trying to process too much information at once, at the exact moment they're least equipped to absorb it.
We started from a simple, almost uncomfortable observation: the paperwork that matters most for recovery is handed over at the moment a patient is least able to read it. Comprehension and outcome are linked. A patient who understands why they're taking a medication is far more likely to actually finish the course. A patient who can't parse "monitor for signs of dyspnea" has no idea they should be watching their own breathing.
$$P(\text{Readmission}) \propto \frac{1}{\text{Comprehension}}$$
This gap is exponentially worse for non-native speakers, immigrants, and refugees navigating a healthcare system in a language that isn't their own, already at their most vulnerable, and now also locked out of understanding their own care plan. It's worse again for elderly patients managing multiple conditions, and for anyone with low literacy who's spent a lifetime quietly compensating for forms and paperwork not built for them.
For the Tech for Humanity theme, we wanted to build a bridge, not another dashboard for the already-healthy. We asked: what if we could instantly turn a dense, liability-focused document into something a scared, exhausted person could actually act on? Not a simplified summary that loses the medical specifics that matter, but a translation of language, not just of words, that respects both the patient's intelligence and their exhaustion.
What it does
Discharge Lens is a privacy-first web application that transforms complex medical discharge papers into highly visual, simplified dashboards.
Users can upload a PDF, paste text, or use their live webcam to capture their discharge papers. They select their native language and input any known allergies. Within seconds, the app generates a Cyber Healthcare Dashboard featuring:
- Simplified Summary — a jargon-free explanation of the patient's condition, with a native Text-to-Speech "Read Aloud" button for visually impaired or elderly patients.
- Action Checklist — a visual, icon-driven list of immediate next steps.
- Medication Timeline — a clear schedule of what to take and when, exportable directly to the user's
.icscalendar file. - Risk Radar & Safety Checks — automated cross-referencing of prescribed medications against the user's stated allergies, plus clear "red flag" warnings for when to seek emergency care. ## How we built it
We built the frontend using React, TypeScript, and Vite, heavily leaning on Tailwind CSS and Framer Motion to create a premium, responsive, glassmorphism aesthetic; something that feels like a modern healthcare tool rather than a sterile hospital portal.
For the backend, we engineered a completely serverless, ephemeral architecture using Supabase Edge Functions (Deno). When a document is uploaded, the extracted text is routed through a single serverless transit point directly to Google's Gemini 3.5 Flash. We chose Gemini 3.5 Flash for its large context window and fast native multi-language translation.
Crucially, we designed for privacy by default: patient data (PHI) is never written to a database. It exists ephemerally, in memory, during transit, and is discarded the moment the response is returned.
Challenges we ran into
- AI model deprecation mid-hackathon. Our original RAG pipeline was built against an older Gemini API model. Mid-development, our tier stopped supporting it, and we started hitting 400 errors. We had to debug the Google Cloud API rapidly, dynamically list available models, and migrate our entire prompt structure to
gemini-3.5-flashon the fly. - Serverless authentication. Supabase Edge Functions enforce JWT authentication by default. Since we wanted a frictionless, anonymous flow for patients, no forced account creation, we re-architected our deployment using
--no-verify-jwt, while still keeping the Gemini API key secured in the Supabase vault. - Strict JSON schemas. Getting an LLM to return a complex, consistently nested JSON structure (medications, interactions, follow-ups) without stray markdown formatting took extensive prompt engineering and error-boundary parsing on the frontend.
- The live-demo CSS glitch. While recording our final video, the "Save to PDF" feature failed mid-take. It turned out
html2canvas, which we used for client-side PDF generation, struggles to render the complex glassmorphism, backdrop blurs, and neon glow borders of our Cyber Healthcare aesthetic. A good real-time lesson in the tradeoff between cutting-edge UI and legacy canvas rendering.
Accomplishments that we're proud of
- Flawless multi-language translation. We fed the app a dense German medical document during testing, and it summarized, translated, and structured it into plain English in seconds.
- The zero-persistence architecture. We built a genuinely functional medical AI tool with no database at all, drastically reducing the compliance surface area by design rather than by policy.
- The UI/UX. We didn't just want it functional. We wanted it to feel human. Staggered Framer Motion animations, custom scrollbars, and neon-cyan glass cards make the information feel approachable instead of clinical and cold.
What we learned
- Edge functions are powerful. Routing third-party API calls through Deno edge functions turned out to be a fast, secure way to hide API keys without standing up a full Node.js server.
AI reliability is mostly a prompting problem. Defining an exact output schema measurably reduced hallucinations and parse failures: $$\text{Reliability} = f(\text{Strict System Prompts})$$
Accessibility is cheap and high-leverage. Wiring up
window.speechSynthesisfor Text-to-Speech took only a few lines of code, but it's one of the highest-impact features in the app for elderly and visually impaired users.Privacy-by-architecture beats privacy-by-policy. Deciding not to store data solved more compliance problems in an afternoon than any amount of policy language could have.
What's next for Discharge Lens
- Enterprise OCR. Integrating Google Cloud Vision to reliably digitize crumpled, handwritten, or poorly lit photos of discharge papers as real-world documents are rarely as clean as a scan.
- Clinical validation guardrails. A production version needs a secondary validation layer (e.g., cross-referencing against SNOMED CT) before any medication dose is displayed to a patient, to guarantee clinical safety beyond what language-model simplification alone can promise.
- Progressive Web App (PWA) support. Letting users save their dashboard offline, so a medication timeline is still readable deep inside a hospital building with zero signal, often exactly where and when it's needed most.
- Caregiver and family sharing. A read-only shareable link so a family member or caregiver who isn't physically present at discharge can still see the action plan and red-flag list in real time.
- Partnerships with community health organizations. Working with clinics and health-literacy nonprofits that serve non-English-speaking and low-literacy populations directly, to pressure-test the tool against real discharge documents and real patients rather than synthetic test cases.
- SMS-based delivery. For patients without reliable smartphone or data access, a fallback that texts the plain-language summary and medication schedule as a series of short messages rather than requiring an app or a stable connection.
- Formal compliance pathway. Scoping what a signed BAA and a HIPAA-compliant production deployment would actually require, so the zero-persistence prototype has a credible path to becoming a zero-persistence product.
Log in or sign up for Devpost to join the conversation.