Most software is designed on the assumption that a connection is always there. In rural clinics it often is not. Health workers record patients in places where the network drops for hours, power is uncertain, and the tablet in their hands is the only computer for miles. If the software fails there, the patient's record fails with it.
We built offline diagnostic and follow-up workflows for The Fund for Global Health, used by health workers in rural Nigeria. These are the principles we would apply again.
1. Treat offline as the normal state
An app that "also works offline" usually means an online app with a cache. For field health work we reversed that. Every screen reads from and writes to storage on the device. Synchronization is a background task that runs when a connection appears, not a step the health worker has to wait for.
This changes the design of everything else: record identifiers are generated on the device, every change is timestamped, and the interface never shows a spinner that depends on the network.
2. Guide the clinical task, step by step
Health workers are not always specialists. The software has to carry part of the protocol. The same applies beyond Nigeria. For Krakel, a respiratory-assessment product used by clinicians in India, we built a guided 12-point lung-sound recording flow: the app shows where to place the device, records each point and will not move on until the recording is usable. A standard sequence produces comparable recordings, whoever holds the tablet.
3. Make follow-up the software's job
Many conditions are caught in the second visit, not the first. We built follow-up into the workflow itself, with a 10-day cycle that schedules return visits and shows each health worker who is due. The tablet becomes a to-do list for patient care, not just a form.
4. Protect data on the device
A tablet that holds clinical data will eventually be lost or shared. Recordings and records are encrypted at rest, and access is tied to the signed-in health worker. For our related respiratory product we designed encrypted storage to support HIPAA requirements. The same discipline applies wherever patient data sits on a device that leaves the building.
5. Design synchronization for conflict, not for the happy path
When two devices change the same patient record before either has synced, something has to decide which change wins. We define these rules with the clinical team up front, per field, rather than letting "last write wins" silently discard information.
What this means for other industries
The same approach serves anyone whose users work away from reliable networks: field inspections, logistics, education in remote schools, or retail in areas with weak coverage. We have used it for offline exams on managed tablets and for biometric attendance terminals that keep working when a site loses its connection.
If your users cannot count on the network, the architecture has to assume they won't have it. That decision is cheap at the start of a project and expensive to retrofit.
