Why hospital ERP for tier-2/3 must be offline-first

Tier-2 and tier-3 Indian hospitals run on 2-5 Mbps connections that drop without warning. What "offline-first" actually has to mean architecturally, the conflict-resolution problem it has to solve, and how to test whether a vendor's claim is real before you sign.

By L.K. Monu Borkala, Founder, OneCity Technologies Pvt Ltd

Most hospital ERP marketing says "works on low bandwidth." Very little of it means the same thing when the connection actually drops mid-shift. A front-desk clerk registering the twentieth OPD patient of the morning, a nurse charting vitals on a ward round, a billing clerk closing out a discharge — none of them can afford to watch a spinning loader because the mobile tower had a bad five minutes. In a tier-2/3 hospital on a 2-5 Mbps connection, that isn't a rare event. It's Tuesday.

What "offline-first" actually means, architecturally

Offline-first is a specific design choice, not a marketing adjective. It means the application writes to a local data store — on the device itself, or a small server on the hospital's own LAN — as the primary, authoritative action. The internet connection is something the system syncs with opportunistically, not something the core workflow depends on to function at the moment of use.

This is a meaningfully different architecture from "a web app that also has a mobile version" or "cached for offline viewing." A read-only cache lets you look up a patient's history with no connection; it doesn't let you register a new patient, write a prescription, or close a bill while offline and have that data safely captured. The distinction matters because most of a hospital's actual workload — registration, charting, billing — is write-heavy, not read-heavy.

The conflict-resolution problem nobody markets

The harder problem offline-first has to solve isn't "does it work with no internet" — it's "what happens when connectivity comes back and two devices have both made changes." Two front-desk terminals might register overlapping OPD tokens while the line was down. A nursing station might update a patient's vitals at the same moment billing updates the same visit's charges. If the system just overwrites whichever device happens to sync first, one of those changes silently disappears — and nobody notices until a bill is wrong or a vitals reading is missing from the chart.

A properly designed system logs every change as a timestamped event rather than overwriting a record in place, so when devices reconnect, the sync process can merge changes deterministically rather than picking a winner at random. This is the part of "offline-first" that's actually hard to build correctly, and the part most vendor demos never show you, because it only becomes visible under exactly the failure condition — two people editing related data while disconnected — that a five-minute sales demo never simulates.

How to actually test a vendor's claim before you buy

• Turn off the tablet's wifi mid-transaction. Start writing a prescription or a bill, then kill the connection. Does the screen freeze? Is the in-progress work lost?
• Reconnect and check the sync. Did the transaction complete and sync correctly, with nothing duplicated or silently dropped?
• Repeat with two devices simultaneously. Have two staff members edit related records (same patient, same visit) while both are offline, then reconnect both at once. Does the system merge both changes, or does one disappear?
• Ask what happens after an extended outage — not five minutes, but a full day. Does the local queue of unsynced changes have a limit, and what happens if it's exceeded?

A vendor confident in their offline architecture will let you run this test on the spot. One who hedges, or insists on a "controlled demo environment," is telling you something about how much they've actually stress-tested the failure case.

Where OneCity fits

OneCity runs on a local-first architecture: OPD registration, e-prescription, billing and nursing charting write to the device or a facility-level sync node first, and reconcile with the cloud when connectivity allows. Every change is logged as a timestamped event rather than an in-place overwrite, so reconnecting two devices that both worked offline merges correctly instead of silently dropping one side's changes. A hospital's day-to-day clinical and billing workflow runs entirely on the local network — the internet connection is needed for cloud backup, cross-location reporting, and functions like ABDM exchange or scheme claim submission, not for a nurse to chart a patient's vitals at 2pm when the mobile tower is having a bad afternoon.