PulseHacks: Zero-Internet Emergency Triage

Zero-internet USSD triage that guides rural patients through a validated risk protocol and instantly dispatches emergency alerts to CHWs and clinics.

Comment

Pulsehacks project story · MD

PulseHacks: Zero-Internet Emergency Triage

Inspiration

In much of rural Sub-Saharan Africa, the barrier between a treatable emergency and a preventable death isn't a lack of medical knowledge — it's a lack of time and a lack of a channel. A mother in labor with a danger sign, or a patient with early sepsis symptoms, often has no smartphone, no data plan, and no reliable signal strong enough for an app or a voice call. What she almost always has is a basic feature phone that can dial a USSD shortcode.

That gap — between "help exists" and "help is reachable in the next five minutes" — is what PulseHacks is built around. As a Mechatronics Engineering student who has already shipped a production USSD-based system (HarvestIQ, a postharvest intelligence platform for smallholder farmers) on AWS serverless infrastructure, I wanted to point that same proven, zero-internet delivery channel at a problem where the cost of delay is measured in lives rather than crop loss.

What it does

PulseHacks is a zero-internet, zero-data emergency triage and alerting platform delivered entirely over USSD:

  1. A patient or Community Health Worker (CHW) dials a shortcode (e.g. *384*HEALTH#) from any feature phone — no app, no data, no smartphone required.
  2. The system walks them through a short, dynamic diagnostic sequence built on a validated triage protocol (modeled on WHO-aligned danger-sign checklists for maternal and acute-emergency care).
  3. Based on the responses, the caller receives immediate, plain-language guidance on their phone.
  4. In parallel, the system automatically dispatches a triage-prioritized alert — via WhatsApp and SMS — to the nearest clinic and on-call CHW, so a human responder is already moving before the patient hangs up. The goal isn't to replace a clinician. It's to close the "time-to-first-alert" gap that currently exists between symptom onset and someone qualified being notified.

How we're building it

PulseHacks extends an AWS serverless architecture already proven in production on HarvestIQ, rather than starting from a blank slate:

  • Telephony layer: Africa's Talking USSD Gateway handles the session with the caller's handset and the SMS fallback pipeline.
  • API layer: AWS API Gateway receives each USSD session step and routes it to compute.
  • Compute: AWS Lambda (Node.js 20.x), deployed via AWS SAM, drives the session state machine and business logic.
  • Clinical decision support: AWS Bedrock (Claude Haiku) is used within the validated triage protocol — not as a freeform diagnostic engine — to handle dynamic question selection and language/context adaptation, so the same core protocol can flex to how a caller actually describes their symptoms.
  • Data: AWS DynamoDB stores encrypted patient interaction logs for continuity of care and later research validation.
  • Dispatch: Meta WhatsApp Cloud API pushes structured, prioritized alerts to clinic and CHW contacts, with SMS as a fallback channel. Reusing a stack we've already deployed and debugged in a live product means Round 1 isn't a purely theoretical pitch — the infrastructure risk is largely already retired.

Challenges we're designing around

  • AI in a clinical context has to be a guardrail, not a diagnosis. The most important design decision in this project is keeping the LLM scoped to protocol navigation and phrasing — not letting it freelance a risk score. Every triage path traces back to a fixed, defensible clinical logic tree.
  • USSD sessions are unforgiving of latency. Most telco USSD sessions time out in roughly 10–20 seconds per interaction. A live model call on every step risks breaking the experience at exactly the moment it matters most. We're designing around this with precomputed/cached responses for common branches, reserving live inference for edge cases the static tree can't resolve.
  • "Zero-internet" needs to be precise. The claim applies to the patient and CHW's handset — the backend gateway and cloud services still require connectivity. Being explicit about this distinction matters for both technical honesty and for the people evaluating feasibility.

  • Alert fatigue and false positives. A triage system that over-alerts will get ignored by overstretched clinic staff. Getting the prioritization thresholds right is as much a design problem as a technical one.

    What we've validated so far

  • The core AWS Lambda / API Gateway / DynamoDB / Africa's Talking USSD pipeline is already running in production for HarvestIQ, confirming the underlying architecture is deployable and cost-efficient at scale.

  • We've mapped the maternal/emergency danger-sign checklist that will anchor the triage logic, so the AI layer has a fixed clinical backbone to operate within rather than open-ended discretion.

    What's next

  • Phase 1 — USSD & AI Triage MVP: Build out the dynamic triage tree and Bedrock-assisted question routing on top of the existing serverless stack.

  • Phase 2 — Regional clinic integration & WhatsApp notification queue: Connect real clinic and CHW contact directories and build the prioritized dispatch queue.

- Phase 3 — Field pilots & research validation: Run limited field pilots to measure time-to-first-alert and gather the data needed for a Scopus-indexed research submission on the triage model's clinical validity.

This submission reflects a Round 1 concept and technical architecture, built on infrastructure already proven in a live production system. A fully functional prototype is planned for later rounds.

Built With

Share this project:

Updates

Submission history