Inspiration

Pathology reports can contain technical language that is difficult to discuss without the surrounding clinical context. We explored whether a narrowly scoped tool could help someone locate the exact wording in an excerpt and prepare neutral questions for their care team. This is a design motivation, not a measured patient need: we did not conduct patient or clinician interviews, and we make no outcome claims.

What it does

Lumen is an English-only, text-only prototype for pathology-report excerpts. Its intended interaction emphasizes source-linked wording, exact quotations, missing information remaining “not stated,” and neutral questions for a care team. It is not a diagnostic tool or medical advice and does not provide prognosis, treatment recommendations, dosing, trial-eligibility decisions, or urgent-symptom triage.

Important demo limitation: the model provider is disabled in the current build. The actual browser-to-API flow safely returns a generic unavailable message and no claims. The positive result screen used in browser tests is a deterministic synthetic UI fixture—not model output, a clinical answer, or an evaluation result. The project has not been clinically validated and is not ready for patient use.

How we built it

We built the interface with Next.js, React, TypeScript, and Tailwind CSS, with a FastAPI/Python backend using strict Pydantic contracts. The browser talks to same-origin Next.js routes; a bounded, no-store server-side proxy forwards requests to FastAPI. The implementation includes exact source-span checks, a separate verifier stage, fixed refusals for out-of-scope requests, and fail-closed handling. Provider credentials are server-side and model processing is disabled by default. The code has configurable provider adapters, but they are covered by mocks only; no live provider call was made.

All evaluation and UI fixtures are fictional and synthetic. The app does not persist report text in browser storage or the URL, and the prototype has no report database. If a provider is deliberately enabled, its own processing and retention practices would need separate review.

Challenges we ran into

The hardest design challenge was making evidence traceable rather than merely producing fluent text. We had to preserve exact quotations and offsets, distinguish information that is missing from information that is negative, and treat instructions inside a report as untrusted content. Another challenge was keeping the scope narrow: OCR/file upload, automated de-identification, additional languages, and external integrations were deferred because their privacy, review, and source-mapping requirements were not established. A second verifier and a test suite cannot replace clinical review.

Accomplishments that we're proud of

  • A responsive, accessible-by-design text interface with keyboard-operated source panels and exact-quote display.
  • A same-origin browser-to-Next.js-to-FastAPI path with bounded requests, no-store responses, safe errors, and no provider keys in browser assets.
  • 64 backend tests and 10 Playwright browser tests passed; the suite includes a provider-disabled integration flow, error paths, mobile/keyboard checks, and automated axe scans.
  • The frozen synthetic corpus contains 8 fictional reports and 46 hand-authored expected fact labels. All 34 non-null gold quote/offset spans match their fixture text. This is fixture-integrity evidence only—not model accuracy.

What we learned

Exact source linkage and safe abstention need to be designed into the data contracts, proxy, and UI—not added as a final disclaimer. Automated tests can demonstrate software behavior but cannot establish that generated explanations are clinically correct. Provider configuration also changes the privacy boundary: the user must be told which service processes submitted text, and that service's terms and retention need review. Finally, saying “not measured” is more responsible than turning a small synthetic fixture into an accuracy claim.

What's next for Lumen

Before any patient-facing use, Lumen would need a defined intended use, qualified clinician and patient review, human-labeled evaluation of model outputs, manual screen-reader/zoom review, and privacy, security, regulatory, and operational assessment for the intended deployment. No live model evaluation, clinician review, clinical validation, or patient-outcome study has been completed. Until those prerequisites are addressed, Lumen remains a synthetic software prototype.

Built With

Share this project:

Updates

Submission history