Sickway

A sick student should not have to start their story over at every handoff.

Inspiration

Sickway started with a conversation within our team. One of our teammates shared how difficult it was for him, as a non-native English speaker, to communicate about healthcare. His experience gave us a personal reason to care about a problem that can be easy to overlook: finding the words to explain what is wrong and understanding what comes next.

We kept thinking about that difficulty in the context of student life. Imagine waking up with a fever, body aches, and an exam in a few hours. Before you can think about getting better, you have to describe your symptoms, remember when they started, and navigate unfamiliar healthcare terms, all while communicating in a second language.

That became our starting question: What if the student's explanation could become a useful clinician brief, then come back as a clear set of next steps? Our teammate's experience made language access central to the idea from the beginning and shaped our decision to build the student journey in English and Spanish.

That question gave us two connected perspectives: The student's phone experience and the clinician's workspace. We wanted the handoff between them to feel like one continuous conversation.

What it does

Our prototype follows one fictional student through a complete demo workflow. The student describes their symptoms, answers follow-up questions, and reviews the extracted information. They can correct it before separately choosing whether to share it with the demo clinic.

On a paired laptop, the clinician receives a structured SBAR brief: Situation, Background, Assessment, and Recommendation. The source information stays beside the summary, and the brief can be played aloud. The clinician can inspect clearly labeled mock options and sample costs, explicitly request resources for a named therapy, and confirm a selection. A packet then appears back on the student's phone without a manual refresh.

The student journey is available in English and Spanish, including review, consent, status, and the returned packet. We wanted language support to follow the student through each handoff. Their instruction-language preference reaches the clinician, who confirms the packet's languages. The clinician brief remains in English.

How we built it

We built one Next.js application with React and TypeScript, using Tailwind CSS and shadcn/ui for the interface. The phone and laptop share a paired demo session, with Amazon DynamoDB storing encounters, packets, and workflow state. Lightweight polling keeps the two screens in sync.

Google Gemini, through the AI SDK, extracts candidate intake fields and drafts the clinician brief. Zod validates structured outputs. The student reviews the extracted fields, while server code enforces consent, session ownership, resource access, and packet creation. This separation lets generated language support the workflow while explicit rules control its actions.

Our teammate's experience shaped how we designed that review step. We wanted students to have a chance to check whether the system captured what they meant, correct it, and then make a separate decision about sharing. We used plain-language prompts and explanations for unfamiliar healthcare terms so those decisions would be easier to understand.

We chose English and Spanish as a focused first pair and wrote the interface copy ahead of time so we could inspect the wording. A visible language selector lets students choose for themselves; we never infer their language from their profile. Switching languages preserves their draft, unanswered fields, and consent choice, because changing how the interface speaks should not mean starting the intake over.

ElevenLabs provides brief audio, with optional clinician voice interaction and student dictation. Those features sit alongside visible controls: dictation fills an editable field, and the clinician still confirms the packet through the interface.

We also gave the project a visual language: cream paper, black ink, and one red line connecting the journey. Dashed badges identify mock information. We chose legible body text with tired and second-language readers in mind. On phones, we kept navigation and language selection within reach and made the opening intake question easy to find. These choices supported the same goal: give students less interface to decipher while they are trying to explain how they feel.

Challenges we faced

The hardest part was preserving meaning as information moved between people, screens, and a model. An unanswered allergy question cannot quietly become “no allergies.” An unconfirmed onset cannot become an exact fact. This mattered especially to our original motivation: uncertainty about a question's wording must not turn into certainty in a clinician's summary. We carried unknown values through the workflow and kept the reviewed source information visible alongside the brief.

We also had to be honest about the limits of our language support. Prewritten bilingual screens give us wording we can review, but they do not establish that every student will understand it. Our Spanish copy received a teammate read-through, not professional or clinical validation. We kept runtime medical translation outside the prototype's scope and treated broader language support as work that requires further review and feedback.

Another challenge was making AI failure survivable. A slow or unavailable model should not strand the demo. We added bounded requests, validated outputs, manual intake entry, and a labeled deterministic summary built from the current reviewed fields. Changed symptoms must produce a matching brief, rather than silently falling back to an unrelated prepared case.

Two devices also meant two opportunities for stale state. Session-scoped storage, polling, repeatable reset behavior, and duplicate-attachment protection helped make the handoff predictable.

Scope was its own engineering problem. We narrowed the project to one synthetic scenario and one complete loop. That gave us room to work on the less flashy details, consent, source labels, responsive layouts, and recovery states, that make the experience understandable.

What we learned

We learned that a useful AI workflow needs more than fluent output. It needs a clear account of where information came from, what remains unknown, and who gets to approve the next action.

Our teammate's story taught us to treat language access as a decision at every stage of the project. It affects the first button a student presses, the terms they encounter, whether they can correct a misunderstanding, and whether they understand the choice to share their information. Building the full student journey in two languages made that responsibility concrete: each handoff needs to preserve both the student's meaning and their ability to make choices.

Finally, we learned to treat failure paths as part of the product. Declined consent, missing answers, unavailable audio, and a reset between demos all deserve deliberate behavior. Our repository includes tests for these boundaries alongside the main workflow.

What comes next

We are proud of connecting the full loop: a reviewed student story becomes a traceable clinician brief, and a confirmed demo packet returns to the same student's device.

Our next step is feedback from students and college-health clinicians: Is the brief useful? Are the sharing choices clear? Does the returned packet make sense? Clinical review, validated translations, production access controls, and real service integrations would require separate work before any real-world use.

Today, this is a synthetic workflow prototype. Patient profiles, therapies, prices, coverage, pharmacies, and manufacturer resources are fictional. Nothing is booked, prescribed, verified, or transmitted to a pharmacy or external clinic, and we have not measured clinical outcomes or time savings.