The ward does not care about your uptime
A nurse is recording observations at the bedside when the clinic's connection drops. The tablet shows a spinner. Either she waits, or she writes the numbers on her hand and enters them later. Neither is acceptable, and the second is how errors get into records.
Many hospital and clinic systems are designed as if the network were a utility that is always on. In much of Nigeria, Ghana and the wider region, connectivity can be patchy inside the building, slow at peak hours, or absent at a satellite clinic. Software for that setting has to treat the network as a convenience, not a dependency. That is what offline first means.
This piece covers the engineering side only: how to design clinical and operational software so it keeps working when the connection does not. It is not guidance on clinical practice.
What offline first really means
It is not "has a cache". It means the application is fully usable with no connection, and synchronisation is a background process that happens when it can.
The local device is where work is done. The server is where work is shared. Reads and writes go to local storage first, so the interface is always fast and never blocked on the network. A sync engine then moves changes both ways when a path exists.
This inverts the usual design. In a typical web app the server is the truth and the client is a view. In an offline first app, each device holds a working copy, and the job becomes reconciling copies.
Decide what must work offline
You cannot make everything offline capable, and trying will bloat the project. List the tasks that a person must complete with no network, in rough priority:
- Registering or finding a patient.
- Recording observations, notes and orders.
- Viewing a recent summary of the patient's record.
- Capturing a dispensing or billing event.
Features that need the wider system, such as a national lookup or an external payment gateway, can degrade gracefully with a clear message and a queued retry. Be explicit about which is which. Users forgive a feature that says "this will send when you are back online". They do not forgive silent loss.
Local storage and what goes on the device
Records need a durable local store. On the web this is typically IndexedDB, on mobile an embedded database such as SQLite. Either way, data on the device is a security concern, because tablets get lost.
Encrypt local data at rest, require a screen lock or a login, and limit what is stored to what that user's role and assigned patients need. A ward tablet does not need the whole hospital's records. Provide a way to wipe a device remotely or on repeated failed logins, and expire cached data that has not been used for a set period.
The hard part: conflicts
Two people can edit the same record while apart. A doctor updates a medication list on one device while a pharmacist annotates it on another. When both sync, which version wins?
There is no universal answer, so design by data type.
Append only data is the easy case. Observations, notes and events are things that happened. Store them as new entries with a timestamp and author, and never overwrite. Two nurses recording readings at different times do not conflict. They simply both exist.
Fields that one person owns at a time can use last write wins, if the loss of the older value is acceptable and visible. Be careful here, because device clocks drift. Prefer a server assigned sequence or a logical clock over trusting the tablet's time.
Structured, safety relevant data such as allergies or active medications should not silently merge. When two edits collide, flag it and ask a human to resolve it. A clear "these two changes disagree" screen is safer than a clever algorithm.
Whatever you pick, keep the full history. If a merge decision turns out wrong, you want to see both versions and who made each.
Identity and duplicates
Offline registration creates a classic problem. Two clinics each register the same patient on the same day, with slightly different spellings. When they sync, there are two records for one person.
Generate record identifiers on the device, using globally unique IDs, so nothing collides on sync. Then treat duplicate detection as a separate, deliberate process: match on a combination of fields, present likely duplicates to staff, and provide a proper merge that keeps an audit trail of what was joined. Avoid automatic merging of clinical records without review.
Sync design that survives bad networks
The network you are designing for is not simply offline. It is flaky: connections that open and die, requests that time out halfway, uploads that arrive twice.
A few principles help.
- Make every write idempotent. Give each change a unique ID so the server can safely receive it twice.
- Sync in small batches with resumable progress, so a dropped connection loses seconds, not an hour.
- Send changes, not whole records, where possible, to respect limited bandwidth and mobile data costs.
- Keep a visible queue on the device. Staff should be able to see how many changes are waiting and when the last sync succeeded.
- Order matters. Apply changes with their dependencies, so an order does not arrive before the patient it refers to.
Make the state obvious
Offline systems fail socially when people cannot tell what state they are in. Show a plain indicator of connection and sync status. Mark records that have local changes not yet sent. When sync fails repeatedly, tell the user and say what to do.
Test the bad days
The failure modes only appear under bad conditions, so test there. Switch the network off mid sync. Edit the same record on two devices. Let a tablet sit offline for a week and reconnect. Corrupt a queued message. These tests are tedious, and they are where offline first systems are won or lost.
Where to start
If you are building or buying clinical software for unreliable connectivity, begin with one workflow, such as bedside observations or patient registration. Make it work fully offline, with clear conflict rules and a visible sync queue. Prove it in a real clinic with real interruptions, then extend the pattern. Offline first is a discipline of assumptions, and the first assumption to drop is that the network will be there.