Skip to content
Lock & Mercer

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 team

Next

Carrying something similar? Tell us what breaks if it isn’t right.

Get in touch