Designing health information systems for unreliable connectivity
A health information system designed for unreliable connectivity saves every clinical entry on the device first, queues it, and synchronises it in order when the connection returns, so that a dropped link never interrupts care or loses data. The design question is not whether a facility is online, but what the system does in the minutes, hours or weeks when it is not.
Most health information systems are still specified as if the network were a utility that is always present. For many ministries of health and provincial hospitals it is not. This guide sets out the evidence on connectivity and power in health facilities, the architectural patterns that keep clinical work safe when the network fails, how synchronisation conflicts should be handled, and the questions a procurement team should put to any supplier.
The connectivity reality health systems must be designed for
Global internet use has grown steadily, but the gaps that matter for health facilities remain large. The International Telecommunication Union (ITU) estimates that about 6 billion people were online in 2025 and about 2.2 billion remained offline, with 96 percent of the offline population living in low and middle income countries [1]. Use stood at 94 percent in high income countries and 23 percent in low income countries, and at 85 percent in urban areas against 58 percent in rural areas [1].
The GSMA's mobile connectivity research shows that coverage alone does not solve the problem. Some 96 percent of the world's population lives within reach of mobile internet, yet 3.1 billion people are covered but not using it, and about 300 million live with no mobile internet coverage at all [2]. Mobile accounts for 84 percent of global internet connections [2], which means that many facilities depend on the same shared mobile networks as the surrounding community.
Small island developing states face a sharper version of the same pattern. ITU reports that 85 percent of the population of small island developing states is within reach of a mobile broadband network, against a global average of 95 percent, and that only 43 percent of the rural population has a 4G signal [3].
| Indicator | Figure | Source |
|---|---|---|
| People offline worldwide, 2025 | About 2.2 billion | ITU [1] |
| Share of offline people in low and middle income countries | 96 percent | ITU [1] |
| Internet use, rural versus urban | 58 percent versus 85 percent | ITU [1] |
| People covered by mobile internet but not using it | 3.1 billion | GSMA [2] |
| Mobile broadband coverage in small island developing states | 85 percent, against 95 percent globally | ITU [3] |
| Rural 4G coverage in small island developing states | 43 percent | ITU [3] |
For a health system planner, these figures translate into a simple design constraint: a facility's connection will be intermittent, shared and sometimes absent, and the system must remain safe in each of those states.
Power is part of the connectivity problem
A network link is only as reliable as the electricity behind it. WHO, the World Bank and partners estimate that close to one billion people in low and lower middle income countries are served by health facilities with unreliable electricity or none at all [4]. More than one in ten health facilities in South Asia and sub Saharan Africa have no electricity, and half of facilities in sub Saharan Africa have unreliable supply [4].
Field studies show how these constraints combine. A mapping study of 72 health facilities across all 13 districts of Sierra Leone found that only 10 had functional official internet, and that 59 of the 72 lacked institutionally provided internet [5]. Only 8 of the 11 hospitals with functional generators had fuel at the time of the survey, and staff named inadequate electricity as the greatest threat to digitisation [5].
A review of electronic medical record implementations in low resource settings reached the same conclusion from the literature: reliable power and network services are core infrastructure requirements, and implementers recommend multiple power sources such as generators, solar, batteries and uninterruptible power supplies [6]. The same review notes that unreliable systems push clinics back to paper backups [6], which is the outcome a well designed system should prevent.
What goes wrong when the network is assumed
When a system that assumes constant connectivity loses its connection, the effects reach patients quickly. An analysis of patient safety event reports during electronic health record downtime, published in the Journal of the American Medical Informatics Association, found laboratory problems including specimen identification errors and delayed transmission of results, and noted that medication administration errors were also prevalent during downtime [7]. Those findings come from well resourced hospitals; the exposure is greater where outages are routine.
Outages are not always short. In January 2022 the eruption near Tonga damaged the undersea cable linking the country to Fiji, and full internet access was not restored for 38 days [8]. A national system whose wards and laboratories cannot operate for five weeks without the network is not a resilient system.
Architecture principles for intermittent networks
The software engineering literature describes this design approach as local first or offline first: data is written to local storage on the device and synchronised with other devices and servers in the background. A widely cited essay from the University of Cambridge and the Ink and Switch research lab describes the goals as offline work, collaboration across multiple devices, and improved security, privacy, long term preservation and user control of data [9].
It helps to separate three patterns that are often confused in tenders.
| Pattern | Behaviour when the link drops | Suitability for clinical care |
|---|---|---|
| Online only | Screens fail to load; unsaved entries are lost | Unsafe where outages are routine |
| Offline capable | A separate offline mode with restricted functions and manual upload | Fragile; depends on staff switching modes |
| Designed for unreliable connectivity | Every entry saves locally, queues and synchronises automatically | Appropriate; clinicians work the same way in every state |
The third pattern rests on a small number of rules.
Save locally and acknowledge immediately
Every change a clinician makes is written to the device before anything else happens, and the screen confirms the save. The clinician should not need to know whether the network is present.
Queue every change in order
Each create, update and delete is added to a synchronisation queue that is processed in sequence when the connection returns. Order matters: a medication dose recorded after an allergy update must not reach the server first.
Read from a local copy when the server is unavailable
Patient lists, recent results and medication charts are cached on the device, so that a nurse on a ward round can still see what was prescribed even if the link has dropped.
Track deletions explicitly
If a record is deleted on one device while another device is offline, the deletion must be tracked. Otherwise the second device can restore the deleted record when it reconnects.
Decide what must never be queued
Some actions should only ever be processed online. Authentication must never cache passwords for later replay, and governance changes such as access rights or facility configuration should not be queued and replayed out of context.
Synchronisation and conflict resolution
When two users change the same record while disconnected, the system has a conflict. How it resolves that conflict is one of the most important and least examined questions in health system procurement.
The HL7 FHIR R4 specification describes a standard defence against lost updates, which it calls optimistic locking: the client sends the version it last saw in an If Match header with the resource's ETag, and the server rejects a stale write with a 412 Precondition Failed response rather than overwriting newer data [10]. FHIR transactions are also atomic: the whole set of changes succeeds or fails as a single unit [10]. These mechanisms detect conflicts; the system still has to decide what to do with them.
| Data type | Recommended strategy | Reason |
|---|---|---|
| Observations such as vitals and doses given | Append; never overwrite | Each entry is a separate clinical event |
| Demographics and contact details | Merge field by field where the changes do not overlap | Low clinical risk, high duplication risk |
| Orders, allergies and diagnoses | Hold for review by a named person | A silent overwrite could cause harm |
| Deletions | Track and propagate; block resurrection | Prevents removed records returning |
| Access rights and configuration | Online only | Must never be replayed out of context |
The research on conflict free replicated data types shows that some data structures can be merged automatically and deterministically [9]. Clinical records need more caution. Last write wins, in which the most recent edit replaces every other, is rarely acceptable for orders or allergies, because the later edit is not necessarily the correct one. A conflict that is held for review, visible in an audit log and resolved by an accountable person, is slower but safer.
Security, identity and data held on devices
Holding data on devices introduces risks that a central system does not have. Device theft was named as a threat to digitisation by 22 percent of staff in the Sierra Leone study [5]. Local data must be encrypted, access must be governed by the same role based permissions as the server, and every action taken while disconnected must enter the audit log when the device synchronises. Our guide to health data security and privacy covers these controls in detail.
Patient identity needs particular attention. A patient registered on a disconnected device cannot be checked against the national index at that moment, so the system must expect possible duplicates and provide a way to find and merge them after synchronisation. The guide to master patient index and unique health identifiers explains the matching methods involved.
What to test before you buy
Supplier statements about offline support are easy to make and hard to verify on paper. The refreshed Principles for Digital Development ask implementers to understand the existing ecosystem and to build for sustainability [11], and both principles point to the same practice: test the system under the conditions where it will actually run.
| Test scenario | What a safe result looks like |
|---|---|
| Disconnect the network during a ward round | Entries continue to save; the queue grows visibly |
| Reconnect after several hours | The queue synchronises in order without user action |
| Two users edit the same allergy while disconnected | A conflict is held for review; nothing is silently overwritten |
| Delete a record on one device while another is offline | The record does not reappear after both reconnect |
| Power the device off before synchronisation | No saved entry is lost on restart |
| Attempt a password change while disconnected | The action is refused until the device is online |
| Run the same tests on a fast, stable network | No change to how clinicians work |
These tests also belong in the total cost assessment. A system that needs costly dedicated links to function safely will cost more to run for its whole life, a point covered in the guide to the total cost of ownership of an EHR.
How Moana approaches this
Moana is designed for unreliable connectivity, not for permanent disconnection, because a health system is a network: laboratory results must reach the clinician who ordered them, referrals must reach the receiving hospital, and a ministry needs facility data to detect an outbreak. The design objective is that a dropped connection never interrupts care or loses recorded data.
In practice, every change made in MOANA Desktop or MOANA Mobile is saved on the device first and added to a synchronisation queue. If the connection drops during a ward round, the nurse continues to record vitals and medication doses. When the connection returns, the queue synchronises in order and the updates become available to the rest of the hospital. When the server cannot be reached, screens read from the locally held copy, so patient lists and charts remain available.
Deleted records are tracked, so that an earlier copy cannot be restored when another device reconnects. When two users change the same record while disconnected, the conflict is held for review in the audit log rather than silently overwritten. Some actions are never queued: passwords and governance changes are processed only when the device is online.
The same rules apply across the EHR, MOANA LIS and the pharmacy workspace, with one patient record underneath. Data is exchanged with national systems through named standards, including HL7 FHIR R4, and aggregate reporting flows to DHIS2 from the encounters recorded at the point of care.
Moana performs in the same way on fast, stable networks. Clinicians do not switch modes, and there is no separate offline version to train on or maintain. The resilience matters most in the many facilities where connectivity is unreliable every day, including clinics in the South Pacific and across Pakistan where Moana is live. More detail is on the works everywhere page.
Key questions for procurement
What happens to an entry a clinician saves while the network is down?
It should be written to the device immediately, confirmed on screen, and placed in a queue that synchronises automatically and in order when the connection returns. Ask the supplier to demonstrate this live, not describe it.
How are synchronisation conflicts resolved?
Ask for the strategy by data type. Observations should be appended, demographic changes merged where safe, and changes to orders, allergies and diagnoses held for review by an accountable person. Last write wins should not apply to clinical data.
Which actions are refused when the device is disconnected?
Authentication and governance changes should be online only. A supplier that replays password or permission changes from a queue is creating a security risk.
Is the data stored on the device protected?
Local data should be encrypted, governed by role based access, and every disconnected action should reach the audit log after synchronisation.
Does the system behave differently on a good network?
It should not. A system designed for unreliable connectivity should give clinicians the same workflow on a fibre connection as on a congested mobile link, so that one system and one training programme serve every facility.
Sources
- Measuring digital development: Facts and Figures 2025, press release, International Telecommunication Union, 2025
- GSMA calls for renewed focus on closing the usage gap as more than 3 billion people remain offline, GSMA, 2025
- Data report tracks SIDS connectivity successes and challenges, International Telecommunication Union, 2024
- Close to one billion people globally are served by health care facilities with no electricity access or with unreliable electricity, World Health Organization, 2023
- Electricity, computing hardware, and internet infrastructures in health facilities in Sierra Leone: field mapping study, JMIR Medical Informatics, 2022
- Benefits and challenges of EMR implementations in low resource settings: a state of the art review, BMC Medical Informatics and Decision Making, 2016
- Implications of electronic health record downtime: an analysis of patient safety event reports, Journal of the American Medical Informatics Association, via AHRQ PSNet, 2018
- Internet is back in Tonga after 38 days of outage, Cloudflare, 2022
- Local first software: you own your data, in spite of the cloud, University of Cambridge repository (Onward! 2019), 2019
- FHIR R4 RESTful API: managing resource contention and transactions, HL7 International, 2019
- The Principles for Digital Development have been refreshed for the next decade, Principles for Digital Development, 2024
