GroundWork: AI-Powered Clinical Workflows for Frontline Health Workers
What Is It?
GroundWork is a healthcare workflow system built for Community Health Workers (CHWs) — the nurses, field workers, and ASHA workers who deliver care in rural and low-income settings where most health tech simply doesn't work.
It takes messy real-world clinical inputs — a symptom description in Kannada, a handwritten prescription, a photo of a malaria test strip — and converts them into structured, standardized health records. Those records then get reliably sent to backend health systems, even when there's no internet.
Who it's for: CHWs, ASHA workers, rural health practitioners, NGO field teams, mobile clinic staff.
Where it runs: Low/no connectivity environments, no EHR systems, multilingual populations, handwritten documents.
The Problem
Over 1–2 billion people globally rely on CHWs as their primary healthcare contact. These workers operate in conditions that break most health software:
- No reliable internet — a system that needs a live connection fails at the worst possible moment
- Handwritten documents — prescriptions and referral slips in regional scripts that standard OCR can't read
- Multiple languages — a single patient encounter might span Kannada, Hindi, and English
- No unified records — patient history is scattered across clinics, hospitals, and paper files
- Decisions made blind — without knowing a patient's TB or COPD history, triage is guesswork
Most health AI is designed for hospitals with stable internet, structured EHR data, and English documentation. Remove any one of those — let alone all four — and the system breaks.
What GroundWork Does
Clinical Input (text / image / document)
↓
AI Extracts Meaning
↓
Deterministic Safety Rules Applied
↓
Standardized Health Record (FHIR R4) Generated
↓
Dispatched to Backend — live or queued for later
AI handles: extracting information from noisy, multilingual, handwritten, or visual inputs.
Deterministic rules handle: safety-critical decisions — e.g., if a patient has COPD and low oxygen, the system escalates regardless of what the AI scored.
The output is always a standards-compliant FHIR record — readable by any modern health system.
Four Core Workflows
1. Text Triage
CHW types or speaks a symptom description in any supported language → AI extracts severity, flags referral need, maps vitals to standard codes → FHIR record generated and dispatched.
2. Prescription OCR
CHW photographs a handwritten prescription → Vision model extracts raw text → Language model interprets medications, dosages, and conditions → FHIR medication records generated.
3. Clinical Image Analysis
CHW photographs a device or finding (malaria RDT strip, pulse oximeter, glucometer) → AI identifies device type and extracts the reading → Output flows into triage or is recorded directly as an Observation.
4. History-Aware Triage
Same as Text Triage, but the system first retrieves the patient's known conditions (TB, COPD, hypertension, diabetes) and injects that context before scoring severity. Known high-risk combinations trigger automatic escalation:
- COPD + SpO2 < 92% → maximum severity, mandatory referral
- TB history + fever → severity upgraded, TB pathway flagged
- Hypertension + chest symptoms → referral forced
Why It Works Offline
Data collected in a zero-connectivity field visit isn't lost. Every generated record is:
- Saved locally to a SQLite database on the device
- Retried automatically every 30 seconds once connectivity returns
- Dispatched exactly once— idempotency keys prevent duplicates
A CHW doing a 6-hour visit with no signal comes back, reconnects, and every record from that day syncs correctly.
Validated Results
| Test | Result |
|---|---|
| FHIR Observation resources generated | 4 |
| FHIR MedicationRequest resources generated | 3 |
| FHIR RiskAssessment resources generated | 1 |
| Kannada handwritten prescription OCR | ✓ |
| Pulse oximeter reading extraction | ✓ |
| Thermometer reading extraction | ✓ |
| Glucometer reading extraction | ✓ |
| Offline queue fallback | ✓ |
| Retry worker draining queue on reconnect | ✓ |
| Duplicate dispatch correctly blocked | ✓ |
| ~120 passing tests across all pipeline stages | ✓ |
Standards Used
GroundWork outputs are real healthcare artifacts, not proprietary JSON blobs:
- FHIR R4 — the international standard for health data exchange
- LOINC — standard codes for vitals (temperature, SpO2, heart rate)
- SNOMED CT — standard codes for symptoms and clinical findings
- RxNorm — standard identifiers for medications
This means any hospital, health system, or NGO platform that speaks FHIR can consume GroundWork's outputs directly — no custom integration needed.
What It Is Not
- Not a chatbot — no conversational interface; it runs structured clinical workflows
- Not an EHR — it doesn't store long-term records; it generates and dispatches them
- Not a diagnostic tool — it triages and escalates; the CHW makes the final call
- Not a dashboard — it executes workflows
Potential Impact
- India's 1 million+ ASHA workers collectively handle hundreds of millions of encounters per year — currently generating fragmented, non-interoperable data
- GroundWork turns every CHW encounter into a standardized, queryable health record usable for disease surveillance and resource planning
- NGOs like MSF and WHO increasingly require FHIR-compliant data — GroundWork generates it as a byproduct of normal clinical workflows
- Telemedicine referrals become structured packages: vitals, history, symptoms, severity — not a verbal handoff
Architecture at a Glance
| Layer | What It Does |
|---|---|
| Frontend | Minimal React UI — image upload, text entry, status display. Works offline. |
| Orchestration | MCP server routing inputs to the right workflow tools |
| AI Layer | Groq API (Llama 3.3 70B for text, Llama 4 Vision for images) |
| Safety Layer | Deterministic escalation rules applied after AI output |
| FHIR Layer | Builds validated FHIR R4 bundles from structured data |
| Dispatch Layer | Sends bundles live; falls back to queue on failure |
| Sync Layer | SQLite queue + 30s retry worker for offline persistence |
Roadmap
- WhatsApp integration — receive clinical inputs through the channel CHWs already use
- Edge AI — run models locally on Android devices for fully offline inference
- Longitudinal records — local FHIR history store synced across visits
- Field pilots — deploy with state health departments or NGO programs for real-world validation
- EHR integration — close the referral loop so district hospitals receive structured pre-admission records from CHW referrals
Log in or sign up for Devpost to join the conversation.