Why your hospital system must work offline

Ask anyone who has worked a reception desk in a Nigerian hospital what happens when the internet goes. The answer is rarely dramatic. Somebody finds the paper register, the cashier starts writing receipts by hand, and the pharmacy keeps a list on a notepad to be typed in later. The hospital does not stop. The record does.

That is the problem an offline-first system exists to solve. Not the outage itself, which is ordinary, but the gap it leaves in the record and the hours of retyping that follow, when a nurse's afternoon is spent moving handwritten entries into a screen that should have had them all along.

The assumption most systems make

Most hospital software is built as a website. Every screen is a page fetched from a server somewhere else, and every save is a request that has to get there. When the connection is slow, the screen spins. When it is gone, the screen is gone too. A system designed this way treats the network as a given and the outage as an exception, and in much of Nigeria that is the wrong way round.

Power is the same story. A desktop machine that loses power loses whatever was on the screen, and a server in a back room that loses power takes every station with it, whether or not the stations themselves are still running on a laptop battery or an inverter.

Offline is the normal case

Fikacare is designed from the opposite assumption. In our engineering rules it is written as a single sentence: offline is the normal case. No screen, action or background job on a machine in the hospital may wait on the network. If something needs the cloud, it is queued and the screen shows that state. Nothing spins.

This works because every machine holds its own complete, encrypted copy of the records it needs. A registration, a place in the queue, a consultation note, a dispensing, a receipt: each is written to the local machine first, in a single transaction, and the record is complete the moment the save finishes. The connection has nothing to do with it.

How the machines talk to each other

One ordinary Windows machine in the hospital acts as the hub. A second machine stands by with a continuous replica and takes over if the hub fails. Every other station, from reception to the pharmacy to the cashier, runs the same application.

Each station tries to sync in a fixed order, which we call the ladder. First it looks for the hub on the hospital's own network. If the hub cannot be reached but the internet is up, it syncs directly with the cloud, which relays to the other machines. If neither is available, the stations find each other on the local network and exchange records directly. And if a station is entirely alone, it queues everything locally and carries on.

None of this needs the internet. A hospital whose connection has been down all day is running normally on the first rung of the ladder, and the cloud catches up when the connection returns. We recommend that the hub sits on a small UPS so that a power cut does not take it down with the lights, but even if it does, the stations carry on with each other.

Reconciling later, exactly once

Working offline is easy to promise and hard to do well. The difficult part is what happens afterwards, when a day's work from several machines has to be brought together without duplicating a receipt or losing a note.

Fikacare handles this by never exchanging current state between machines. It exchanges the record of what happened. Every write is an event carrying the identity of the machine that made it and a sequence number that goes up by one each time. When machines sync, one asks another for everything after the last number it has seen. Because the sequence has no gaps, missing data is detectable rather than silent, and an event that arrives twice is recognised and ignored.

The same thinking protects receipt numbers and patient card numbers, which must be unique even when the machine that issues them is cut off. Each machine holds a pre-allocated block of numbers, so a cashier working alone issues real receipt numbers that cannot clash with anyone else's.

Knowing how old what you see is

There is one thing an offline system must never do, which is to let a clinician mistake old information for current. A screen showing another machine's records, such as a patient's allergies or a result entered in the laboratory, carries a banner stating how old the data is and which route it came by. On allergy, current-medication and critical-result screens the banner cannot be dismissed. A doctor working through an outage can see everything, and knows exactly what they are looking at.

What this means for the owner

For the person who runs the hospital, the point of all this is not the technology. It is that the record is whole. The receipts from the afternoon the connection failed are in the same ledger as the receipts from the morning. The reports are right, the cash-up balances, and nobody spent the evening retyping a register.

Outages are going to happen. The system's job is to make sure that, afterwards, nobody can tell.