Plainly

landing page
explanation: output is broken into cards (what it means, what to do next, what to watch for, and plain definitions)
first screen after landing: get the pdf in
follow-up chat: tied to the document

Track 2 - Disability Health Literacy

Inspiration

60 percent of US adults struggle to understand basic health information. For the 7.3 million Americans with intellectual or developmental disabilities (Down Syndrome, Autism, Dyslexia) a complex prescription label isn't just confusing. It's a life-threatening barrier. Current patient portals are built for the people who write the documents, not the people who have to live by them. Caregivers are left bridging that gap every day, without training, tools, or time, translating clinical language on the spot for someone whose health depends on getting it right. The information already exists. The problem is that nobody designed it for the people who need it most. Plainly is our attempt to fix that.

What it does

Upload a medical PDF and Plainly returns four things: a plain-language summary, numbered next steps, clearly flagged warnings, and a glossary in everyday words. What separates Plainly from pasting a PDF into a generic chat window is what happens the second time. Many document tools are stateless: you upload, you prompt, you close the tab, and the next question starts from zero. Plainly fingerprints the file and, when you return with the same PDF, reloads your prior conversation so follow-ups feel like a continuation. Patients rarely have one question; they have the one they remember in the office when something still does not add up. Continuity between those two moments is where the product earns its keep.

How we built it

The frontend is React with Tailwind CSS. The backend is Node.js and Express. PDFs upload through Multer, text is extracted with pdf-parse, and a language model produces the structured breakdown rendered as scannable cards. The engineering we care about most is the identity + recall layer: hashing the file, persisting the Q&A thread against that identity, and restoring context when the same document comes back so the experience feels like an ongoing conversation with your paperwork.

Challenges we ran into

PDFs in the wild are messy. Scans, odd encodings, and layout quirks degrade extraction in ways that ripple through everything downstream. Tone is as hard as structure. Plain language has to feel supportive without drifting into the confident certainty that belongs to a clinician. Scope under a deadline forced honest tradeoffs: we chose to finish an end-to-end path (upload → parse → model → UI → continuity) rather than pretend we had solved every edge case.

Accomplishments that we're proud of

A full vertical slice from drag-and-drop to patient-friendly, structured output. An interface built around clarity instead of feature sprawl. And the document-aware thread that makes follow-up questions possible; the line between a summarizer you try once and a tool you can actually come back to.

What we learned

Health literacy is information design: the limiting factor is often not whether someone can understand their care, but whether the material was organized to give them a fighting chance. LLM output needs a stable shape if the UI is going to stay trustworthy: predictable fields beat one beautiful blob of text. PDF is harder outside demos than inside them; production work is mostly extraction quality, failure states, and humility about what the model should claim.

What's next for Plainly

Better handling for poor scans, with explicit, humane failure modes when the text underneath is unreliable.
Clear disclaimers, optional ties back to source excerpts, and paths for caregiver or clinician review so the tool’s role is obvious.
Localization, mobile-first flows, and accounts so memory survives new devices and new sessions.