Pirates

About the Project

The Problem

Tuberculosis screening is not only a diagnostic problem. In underserved and rural communities, the larger challenge can be continuity of care: collecting information in the field, working with limited connectivity, getting the right evidence reviewed, referring a patient when needed, recording diagnostic results, and ensuring follow-up does not get lost along the way.

We wanted to explore whether AI and a lightweight offline-first workflow could help connect these stages without replacing the healthcare professionals responsible for clinical decisions.

Our Inspiration

We were inspired by a simple question:

What if screening did not end when the field worker left the patient?

This led us to build TBReach, a prototype designed around the complete journey of a synthetic case rather than a single AI prediction.

A field worker can collect information through a simple, mobile-first interface, including typed or voice-transcribed responses. The system can work offline using local storage and synchronize with a central service when connectivity becomes available. A verifier can review the case, request additional screening evidence such as an X-ray or ESR result, and keep that information attached to the same case ID. Diagnostic results and treatment decisions remain explicitly human-controlled.

How We Built It

TBReach was developed incrementally as a series of workflow milestones.

Structured clinical state: We defined a canonical case schema and explicit state transitions so that every stage of the workflow has a predictable structure.
Offline-first architecture: A local SQLite store-and-forward layer allows field data to be captured without continuous connectivity and synchronized later.
Field intake: A simplified interface guides the worker through one question at a time, with English/Hindi support, typed input, and browser-based speech transcription.
AI-assisted summarization: Free-form field-worker notes can be converted into a concise structured summary while retaining the original input.
Screening evidence: The prototype supports X-ray image submission and ESR values as screening evidence.
Human verification: A verifier reviews the case and can explicitly request additional evidence rather than automatically making a diagnosis.
Diagnostic workflow: Laboratory results and clinician-entered diagnosis, rationale, and treatment plans are recorded as separate stages.
Continuity of care: The workflow extends beyond diagnosis into treatment assignment and ASHA follow-up, including missed pickups and rescheduling.
Auditability: Case revisions, evidence, and workflow events are preserved to prevent accidental overwrites and duplicate submissions.

The repository contains the implementation across the M0-M7/M8 workflow stages, including the field interface, reviewer workbench, backend, SQLite stores, and evidence handling.

What We Learned

One of our biggest learnings was that an effective healthcare AI system is not necessarily the one with the most sophisticated model.

The harder engineering problem was building a reliable workflow around the model.

We learned how important it is to:

Design explicit state transitions instead of relying on implicit application logic.
Handle intermittent connectivity as a first-class constraint.
Preserve a single case identity across multiple interactions.
Separate screening signals from clinical diagnosis.
Keep humans in control of referrals and diagnostic decisions.
Make interfaces appropriate for the person actually using them, rather than exposing backend complexity to field workers.
Make retries and duplicate submissions safe through revision checks and provenance.

Challenges We Faced

The project involved several non-trivial challenges.

Offline synchronization: A field worker cannot be expected to have reliable connectivity at every point of care. We therefore had to design local persistence, synchronization, retries, and revision protection.

Keeping the workflow consistent: A case can move through screening, verification, additional evidence collection, diagnostics, treatment, and follow-up. We had to make sure that every transition remained valid and that stale updates could not overwrite newer information.

Human-AI boundaries: We deliberately avoided turning an X-ray model or screening signal into an automatic TB diagnosis. The AI component is used to support screening and information organization, while referral and diagnosis remain explicit human decisions.

Designing for field users: Our initial interface exposed too much technical complexity. We redesigned the field workflow around one question at a time, large controls, voice input, and simple evidence collection, while keeping the detailed workflow available to verifiers.

Current Scope

TBReach is a synthetic-only prototype intended to demonstrate the technical workflow. It is not authenticated for real patient use and is not clinical software. The repository itself documents these limitations and notes that its current summary is deterministic rather than AI-generated.

Our goal with the prototype is to demonstrate how AI, offline-first engineering, human verification, and continuity-of-care workflows can work together to address a problem that extends beyond simply detecting disease.