LabNav — Understand Your Lab Results

Inspiration

In much of the world, people leave a clinic holding a piece of paper they cannot read. A lab report is a wall of numbers, abbreviations, and reference ranges written for clinicians — not for the worried person trying to understand what is happening in their own body. For someone with low health literacy, in a region where a follow-up visit just to ask what it means is expensive or simply unavailable, that paper is useless at best and frightening at worst.

We kept coming back to one image: a person sitting with a lab result, not knowing which number matters, not knowing whether to be scared, and not even knowing what to ask. The information they need exists — it's just locked in a language they can't decode. That gap, between information existing and a person actually being helped, is the problem LabNav was built to close.

We also made a deliberate decision early: this tool would explain, never diagnose. The goal is to help people understand their results and walk into their next appointment prepared — not to replace a doctor, and never to tell someone what is "wrong" with them.

What it does

LabNav takes a lab report — typed in, or photographed — and turns it into something a person can actually understand:

Plain-language explanations of each test, written at the reader's literacy level, with every medical term defined.
Status at a glance — whether each value is within, above, or below the typical range printed on their own report (we never invent reference ranges).
Urgent-value routing — if a result is dangerously out of range, LabNav calmly and prominently encourages seeking medical care promptly, without panicking the user or explaining the danger away.
Questions to ask your doctor — because our users often don't know what to ask, LabNav generates specific, relevant questions to bring to their appointment.
In your language — explanations are produced natively in English, Kiswahili, or Kinyarwanda.
Read aloud — every explanation can be spoken, for users who find listening easier than reading.
Private by design — results stay on the user's own device. We store no health data on our servers.

Throughout, LabNav holds a firm line: it explains and prepares; it does not diagnose, predict, or recommend treatment.

🛠️ How we built it

Backend: A stateless [Python / FastAPI] service. Each request sends report text to the Claude API and returns a structured, safety-checked explanation. Nothing is stored server-side.
The safety prompt is the product. The heart of LabNav is a carefully engineered system prompt that encodes our ethical boundaries: explain don't diagnose, never falsely reassure, never invent reference ranges, and route dangerous values toward urgent care. We treated this prompt as the most important file in the project and tested it relentlessly.
Document reading: We use Claude's vision capabilities to read messy, real-world phone photos of printed reports — the kind of skewed, low-light images our actual users would take — rather than assuming clean text.
Multilingual output: Rather than translating after the fact, we instruct the model to write the explanation natively in the chosen language, keeping our safety rules intact in the prompt.
Frontend: A lightweight installable PWA so it works like a real app on a phone, with the app shell and past results available offline. Read-aloud uses the browser's built-in speech synthesis — no extra cost, works on-device.
Privacy: Stateless backend, no request-body logging of health data, and device-local storage only, with a clear in-app notice and a one-tap "clear my results."

🧠 What we learned

The model is the engine, not the product. Anyone can paste text into a chatbot. The actual work — and the actual value — is everything around it: reading the messy photo, enforcing safety, meeting people in their language, and turning an explanation into the right questions to ask.
Safety is a design discipline, not a disclaimer. We learned how easily a general model will drift toward diagnosing or falsely reassuring, and how much deliberate prompt engineering and testing it takes to hold a firm, humane boundary.
Honesty about limits is a feature. Telling users plainly what LabNav won't do — and that their conversation isn't a medical service — builds the trust the tool depends on.

🧗 Challenges we faced

Drawing the explain-versus-diagnose line. The hardest part wasn't getting good explanations — it was reliably stopping the model from crossing into diagnosis or "you're fine, don't worry." We built a set of deliberately tricky test cases (including a dangerously high value) and tuned until the guardrails held every time.
Handling dangerous results responsibly. A scary value needs to be flagged without alarming the user and without speculating on what it means. Getting that tone right — calm, honest, and routed toward care — took real iteration.
Reading real-world photos. Clean text is easy; a crumpled, badly lit photo of a printed report is not. Making document reading robust to real conditions was a genuine engineering challenge.
Lower-resource language quality. Output quality varies across languages, and we had to test our three languages carefully — especially on medical terms — rather than assume parity.

What's next

Trend tracking across multiple reports over time, kept entirely on-device.
A lightweight evaluation, with clinician input, measuring explanation accuracy and how reliably the tool flags urgent values — the foundation for a research write-up.
Expanding language coverage and improving voice quality for under-served languages.

LabNav is an interpreter for the things vulnerable people can't decode — built to help people understand their health, safely, in their own language, and to walk into their doctor's office prepared. It is not a doctor, and it never pretends to be one.