Running hospital software on unreliable internet and power

Ask any Ethiopian hospital's IT officer about their worst day and the story will involve a network outage or a power cut. The connection drops in the middle of the morning OPD. The generator fails to start. A fibre line is cut by roadworks and the backup link turns out to have been disconnected months ago for non-payment. In each case, the question is the same: does patient care stop?

It must not. That is the first principle of running hospital software anywhere, and it matters more where connectivity and power are less reliable. This article sets out how we think about it, at four layers: the software, the connection, the power, and the procedure.

Layer one: software that tolerates a slow connection

Much modern web software is heavy. It downloads several megabytes of JavaScript before showing anything, then makes dozens of requests to draw each screen. On a fast office connection this is invisible. On a congested 3G link shared by a whole hospital, it means a registration screen that takes thirty seconds to load.

Software designed for Ethiopian conditions should do the opposite: render pages on the server, send little JavaScript, keep pages small, and make each action a single request. When the connection is slow, the system should be slow — not broken. This is how CareLink is built: pages are rendered on the server with very little JavaScript, so it stays usable on 3G and on older laptops.

A harder question is what happens when the connection is gone entirely. True offline operation — continuing to register, document and dispense with no connection, then synchronising safely afterwards — is difficult to build correctly, because two departments can change the same record while disconnected. We are building it; it is on our roadmap and we will not claim it before it is ready. Be cautious of any vendor who claims full offline operation without being able to explain how conflicts are resolved.

Layer two: the hospital's connection

• Two connections from two different providers, so a single failure does not take the hospital offline. Where fixed lines are unreliable, a mobile data router as the second link is often enough for a clinic or health center.
• Automatic failover between the two, tested regularly — not a cable someone has to move.
• A simple, documented internal network: the most common cause of "the internet is down" is a failed switch or a disconnected cable inside the building.
• Monitoring that tells the IT officer, not the nurses, when a link fails.

For larger hospitals where the external connection is unreliable, or where policy requires it, an on-premise component can keep critical workflows running inside the hospital network when the link to the outside world fails. Whether this makes sense depends on the facility, and we assess it during the discovery visit rather than assuming.

Layer three: power

Power interruptions are common enough that every hospital already has some backup for its clinical equipment. Software needs the same thinking:

• UPS units on the network equipment — router, switches, wireless access points — so the network survives the gap between mains failure and the generator starting.
• UPS or laptop batteries at the critical workstations: registration, triage, the pharmacy, the cashier and each ward nursing station.
• Generator coverage for the server room or network cabinet, not only the theatre and the ICU.
• Printers on backup power at the pharmacy and cashier, because a dispense or a receipt that cannot print often stops the queue.

Laptops rather than desktops at key points are a simple and underrated measure: a laptop with a healthy battery is its own UPS.

Layer four: the downtime procedure

Even with good software, two connections and backup power, there will be times when the system is unavailable. What matters then is that every member of staff knows exactly what to do. A written downtime procedure should cover:

1. Who declares downtime, and how staff are told.
2. Which paper forms are used for registration, triage, consultation notes, orders, prescriptions, medication administration and payments — printed in advance, kept at each station, and in the same layout as the screens.
3. How patients are identified during downtime, so the paper record can be matched to the electronic one afterwards.
4. How urgent results are communicated between the lab and the wards.
5. Who enters the downtime records into the system once it is back, in what order, and how this is checked.
6. How long the hospital can run on paper before escalating.

The procedure should be rehearsed. A downtime drill once a quarter, during a quiet afternoon, will reveal missing forms and forgotten steps far more cheaply than a real outage.

Medication administration deserves special care

Of all hospital workflows, medication administration on the wards is the one where a gap in the record is most dangerous. If a nurse gives a dose during an outage and it is not recorded, the next nurse may give it again. The downtime procedure should include a printed medication administration record for each inpatient, refreshed each shift while the system is up, so that nurses always have the current schedule on paper. In CareLink's nursing and eMAR module the scheduled doses are generated from the order, which makes a current printout straightforward.

What to ask a vendor

• Show me the system on a throttled 3G connection.
• What happens to a form I am filling in if the connection drops before I save?
• What works with no connection at all — today, not on the roadmap?
• How are backups taken, and when was a restore last rehearsed?
• What does your recommended downtime procedure look like?

Unreliable infrastructure is not a reason to stay on paper; paper fails too, through lost folders and illegible handwriting. It is a reason to plan. If you would like to discuss your facility's connection and power situation, it is one of the first things we look at on a discovery visit. See also choosing a hospital management system in Ethiopia.