Almost every EMR vendor will tell you they work offline. Few mean the same thing by it. These are the tests and questions that separate genuine offline architecture from a hopeful claim.
If you are buying an electronic medical record system for a facility where power and connectivity are not guaranteed, offline behaviour is the property that matters most. It is also the one most often overstated. Ask any vendor whether their EMR works offline and the answer is almost always yes. The honest follow-up is to define what offline means and then test it, because the gap between a system that truly runs offline and one that merely caches a screen is the gap between a hospital that keeps working during an outage and one that stops.
This guide gives you the tests and questions to tell the two apart. We have written separately on why offline-first matters for hospitals in Africa; this piece is about how to evaluate it in a vendor.
There is a spectrum hiding behind the word offline. At the weak end, a system needs the internet to function and only caches a little data so a screen does not go blank instantly. In the middle, a system can read records offline but cannot create or change anything until it reconnects. At the strong end, a genuinely offline-first system runs locally on the device, lets staff do full clinical work with no connection at all, and syncs to a central copy when the link returns.
Read-only offline is not enough for a hospital. Staff need to register, chart, order, dispense, and bill during an outage, not just look at what was there before it.
Do not accept a verbal answer. Ask the vendor to run the demo with the network physically disconnected and complete a full patient journey with the connection down. Register a new patient, write a clinical note, order a test, dispense a medication, and raise a bill, all offline. Then reconnect and watch what happens to the data. A real offline-first system completes the journey without complaint and syncs cleanly. A weaker one will stall at the first write, show errors, or quietly fail to save.
If a vendor is reluctant to unplug the network during the demo, that reluctance is itself an answer.
Working offline is half the story. Reconciling that work when the connection returns is the other half, and it is where weak systems break. Ask these.
Data that lives on local devices needs protecting just as much as data in a central store, arguably more. Ask whether data at rest on the device is encrypted, what happens if a device is lost or stolen, and how access is controlled so staff see only what they should. Offline capability is not an excuse to relax security, and a serious vendor will treat the two together. You can see how we frame this on our security page.
Veona is offline-first by design rather than by add-on. The EMR runs locally so staff can do full clinical work with no connection, and it syncs to a central copy when the link returns, with conflict handling built into how sync works rather than bolted on. Data on the device is encrypted, access is role-based, and every record carries an audit trail. You can see the platform on the platform overview and the patient record in our chart module. The fairest way to evaluate us, and any vendor, is the same one we recommend for everyone: unplug the network and watch the system work.
Book a demo and we will disconnect the network, run a full patient journey offline, then reconnect and show the sync.