Why hospital ERP for tier-2/3 must be offline-first
Tier-2 and tier-3 Indian hospitals run on 2-5 Mbps. An ERP that dies when the link drops is not a hospital system — it's a liability.
A metro hospital has redundant fibre, a UPS room and an IT team. A 50-bed hospital in a tier-2 city has a broadband connection that drops twice a week, a power backup that covers lights but not the server, and the front-desk operator doubles as the "IT person."
Cloud-first ERP works beautifully for the first hospital. For the second, it means: link drops at 2 PM, nurse can't chart vitals, pharmacy can't dispense, billing can't issue, and the doctor dictates notes on paper to be entered "when the internet comes back." That's not a system failure — it's a design failure. The software assumed connectivity that the hospital doesn't have.
Offline-first means the ward app keeps working when the connection drops. Vitals, medication administration, diet orders — the clinical workflow that can't wait for a DNS resolution. When the link returns, the app syncs. Conflicts are resolved by timestamp and attribution.
This isn't a nice-to-have. In a hospital, a system that's down when you need it is worse than no system at all — because staff have already abandoned the paper backup process that worked before the software arrived.
The design implications run deep: every form must validate locally, every save must work against a local store, every sync must handle partial uploads, and the UI must clearly show "offline — changes will sync." It's not a feature flag; it's an architecture decision that affects every screen.
OneCity's ward app is built for this constraint. The clinical flow works on the device. Sync happens in the background. The admin and financial modules (billing, HR, accounting) are online-only because they tolerate brief downtime. The clinical modules — vitals, eMAR, diet orders — do not.
