Field capture on a bad connection
An offline-first data entry interface for remote clinics, built so an outbreak signal is not lost to a dropped connection.
Situation
Health surveillance assumes the data arrives. In a remote clinic on an intermittent 2G connection it frequently does not, and the failure is quiet: a form is filled in, the request times out, and the record is gone. Nobody upstream sees a gap, because a gap and a quiet region look identical.
The engagement was contracted through AMREF Health Africa with Global Fund financing, covering the field data entry interface and the sync layer for a DHIS2 integration. DHIS2 is the open-source platform much of this reporting runs on, and the work sat entirely on the collection side of it.
What we did
Entry is local first. Records persist to IndexedDB in the browser the moment they are entered, so the clinic is never waiting on a network round trip to continue working, and closing the tab does not lose the morning.
Sync is store-and-forward. A queue trickles compressed payloads out over whatever connection exists, retrying without duplicating and without dropping fields on a partial send. During a high-volume event the compression and the queueing both matter, and so does staying off the main browser thread: an interface that locks up while flushing a backlog is an interface that gets abandoned mid-outbreak.
Payloads are compressed for the connection rather than for the server. On a metered 2G link the size of a submission is a cost somebody is paying.
Worth stealing
A dropped record and a quiet district look the same
The dangerous failure in surveillance is not an error, it is silence. If a submission can fail without anybody knowing, then absence of signal stops meaning absence of disease and the system has quietly become unable to do its job. Persist locally before anything else, queue rather than fire and hope, and make an unsent record visible at the clinic so the person who entered it knows it has not left yet.
Scope
- Offline-first data entry interface
- Local persistence in the browser
- Store-and-forward sync queue
- Payload compression for constrained links
- Client
- AMREF Health Africa, funded through the Global Fund
- Sector
- Global health
- Year
- 2025
- Stack
- DHIS2 · IndexedDB · Store-and-forward queueing
What we can’t publish
We are cleared to discuss the DHIS2 integration and the sync patterns. We are not permitted to publish epidemiological data sets, facility identifiers, or server addresses. Nothing on this page is drawn from patient or facility data.
Who did it
Built and carried by Lock & Mercer. The people who took the brief are the people who built it and the people who answered for it afterwards.
The teamNext
Carrying something similar? Tell us what breaks if it isn’t right.
Get in touch