Offline first: health software for institutions where the connection fails
In many health institutions the internet isn't slow. It's absent for hours at a time. A system that only works online is a system that doesn't work.
Most health software assumes the connection is there. Offline first assumes it isn't. In institutions where the power and the link both come and go, that one assumption decides whether the system works at all.
The connection drops, returns for twenty minutes, drops again. Most systems are built for the opposite: a link that holds, with the occasional blip.
This was written for Digital Health Week 2026. The roundtable SelNexa Health had scheduled for 4 November is postponed, so the material is here instead. A new date will follow.
What actually breaks
Ask an administrator what happens when the link goes and you get the same answer in different words. Work moves to paper. Registration details, visit notes, drug issues, all of it goes into a book or onto loose sheets, and someone types it back later, if there's time and if the sheets survive.
The cost isn't the paper. It's what happens between the paper and the system. Entries get captured twice or not at all. The monthly return goes in late, built from a count somebody did by hand. The record a clinician needs at the next visit isn't there, so the patient answers the same questions again.
And it's rarely the internet on its own. Power is usually the harder constraint. Software built around a server that runs twenty four hours stops when the power does, whatever the connection is doing. That single fact decides more about the architecture than bandwidth ever does.
Offline first is a decision made before the first line of code, not a fallback mode added afterwards.
What offline first actually involves
The application writes to local storage first and treats the server as somewhere data goes later, rather than something it needs in order to function. A local write queue holds every action until it can be sent. A service worker keeps the application loading with no network at all, so a health worker opens it and it's simply there. Sync runs when the link returns.
Write locally, first
The health worker registers the patient and records the visit. It lands in local storage on the device immediately, with no network involved.
The queue holds it
Every action sits in a local write queue. The application keeps loading and keeps working whether or not there is a link.
Link returns
Sync, with rules
The queue drains to the server. Where two devices changed the same record, both versions are kept and resolved by rules, not by whoever synced last.
It reaches the national system
A common record format, FHIR R4, carries it on to what the ministry already runs, with nobody retyping anything.
Where it goes wrong
Last write wins. Whichever device syncs second overwrites the other, nobody is told, and the record is wrong in a way no one notices for months.
The part people underestimate is what happens when two copies disagree. Two health workers edit the same patient record while both are offline. Both edits are legitimate. When the link returns, the system has to work out what happened, and the easy answer quietly destroys data. The honest version keeps both and applies rules you can explain to the people whose records they are.
Offline cannot mean isolated
There's a failure on the other side of this. You build something that works well with no connection and it becomes an island. The data sits in the institution and never reaches the district, the province or the national system, and you've moved the problem rather than solved it.
So the integration work matters as much as the offline work. A common record format, and talking to what the ministry already runs instead of asking it to adopt something new.
Who owns the data, and who protects it
Designing for disconnection multiplies the places data lives. Every device holding a local copy is another place it can leak, another device that can be stolen, another copy nobody is auditing. You can't design for offline and then treat security as a server-side problem.
In practice that means encryption at rest on the device, access tied to a role so a records clerk and a doctor don't see the same thing, and an audit trail that survives sync, so you can still say who did what after three days with no link.
The institution holds custody of the record. The patient holds rights over it. The vendor holds neither.
A vendor who can read patient records whenever it likes has built the thing wrong, and that includes us. Consent has to travel with the record rather than sit in a server the institution can't reach when it needs to check.
Transform Health, which convenes Digital Health Week, stewarded the Health Data Governance Principles, built around three objectives.
Protect people
Guard individuals and communities against harm at every stage of the data lifecycle.
Promote health value
Get real benefit out of the data, for the patient in front of you and for the system.
Prioritise equity
The hardest one offline. The institutions with the worst connectivity tend to have the least capacity to hold anyone accountable for what happens to their data.
In Zimbabwe the anchors are the Cyber and Data Protection Act and SI 155 of 2024, with POTRAZ as the authority.