Cloud or On-Premise: The Argument Every Hospital Board Has

The server room of a 220-bed hospital in a tier-2 city is usually behind the accounts department. A split AC runs all year, one rack is half empty, the whiteboard network diagram stopped being accurate in 2019, and the UPS batteries were replaced once, four years ago. The engineer who built it left for a larger group in Pune, and the current IT executive — capable, overworked, the only one — inherited a root password written inside a register cover.

That room is what the board is really arguing about. The debate gets framed as modern versus old-fashioned, the least useful way to have it. Both work, both fail, and what separates them is which set of obligations the hospital is in a position to carry.

For clarity: Kōami is a cloud system, which is why the next section matters most. On-premise has a real case, and a hospital talked out of it by a vendor with a hosting bill to protect has been badly served.

The honest case for on-premise

Start with money already spent. A hospital that put thirty lakh into servers and storage eighteen months ago has years of life left in that hardware. Writing it off for a monthly subscription is a real loss, not an accounting inconvenience, and no amount of capex-to-opex language makes it disappear.

Then connectivity, which deserves the most respect. In many locations the primary link drops, the secondary turns out to be the same last-mile fibre under a different name, and the 4G failover depends on a tower that struggles whenever it rains hard. Registration, billing, pharmacy and the OT list cannot pause for a router, and casualty at 2am cannot wait for an ISP ticket. A hospital with genuinely unreliable connectivity is not being sentimental. It is being honest.

There are others, all legitimate:

• Local integrations. PACS modalities, analysers on old interfaces, biometric attendance, queue displays — simpler on a LAN, and the workarounds cost real money.
• Custody. For a trust or family-owned hospital, the instinct that data should sit in the building reflects a view of accountability that has served the board well elsewhere, and some institutional tie-ups and tenders carry hosting expectations of their own.
• A single-site hospital with a real IT team, a patching routine and a restore that has actually been tested is often better off on-premise, and should be told so.

The honest case for cloud

The cloud case is not about technology either. It is about who does the maintenance.

No server room. No diesel-backed UPS, no AC failing in May, no hardware refresh landing the same year as the new OT block. Patching, key rotation and backups become somebody's full-time job rather than the fourth priority of an executive whose week is passwords and printers.

Multi-site is where the difference turns structural. A group running a main hospital, a satellite unit and a daycare centre gets one patient index, one MRN series, one tariff master, one version of the software. The on-premise equivalent is three databases and a patient who exists twice.

Disaster recovery is the uncomfortable one. Ask an on-premise hospital what happens if the building floods, and the honest answer is often a second server in the same building and a portable drive in the administrator's cupboard. That is a backup with a single point of failure. Geographic redundancy is the one thing a hospital cannot easily build for itself.

Two claims that do not survive contact with a Tuesday

The first is that on-premise is more secure. In principle, possibly. In practice security is maintenance, and maintenance is a staffing question. Ask when the operating system was last patched and whether the database port is exposed. Ask whether the remote-access tool the vendor installed so support could log in on a Sunday is still there with the same password. Ask whether accounts of staff who left are disabled. Physical custody of a box is not security; it is only the opportunity to secure it, taken every week for years.

The second is that cloud moves the responsibility elsewhere. It does not. The provider secures the infrastructure. The hospital still owns what causes incidents: who holds an account, which roles can open which MRN, three billing staff sharing one login, the nursing terminal left unlocked in a corridor, the discharge summary forwarded on WhatsApp.

Almost nobody is breached because the server was in the wrong building. They are breached because nobody was watching the accounts.

Residency, consent and what belongs in the contract

Health data in India carries obligations around consent, purpose limitation, retention and residency, and the framework keeps moving. Anyone claiming to know exactly what is mandated today, in a blog post or a sales deck, deserves suspicion. Take current advice from counsel.

What a board can insist on, without waiting for legal certainty, is that the answers live in the contract rather than in a conversation:

• Where the data resides, and whether that can change without notice.
• Which sub-processors are involved and what they can see.
• Breach notification timelines, audit rights, and what evidence the vendor will produce on request.
• The exit clause: on termination, in what format the data comes back, how fast, at what cost, and whether it is usable without the vendor's software.

That last one applies whether the system is Kōami or anything else, and it is the clause most often left vague. NABH expects documented access control, audit trails, backup and retention policy whatever the hosting model, and ABDM participation brings consent artefacts the system must handle as data rather than paperwork.

The questions a board should actually ask

Most of the debate collapses once these are answered honestly, and if nobody can answer the first with a date, the argument is already over.

• When did we last restore a backup onto a working system, and how long did it take?
• If the internet is down for four hours, what still runs, and has that been rehearsed rather than assumed?
• Who applies patches, on what schedule, and how would we know if that stopped?
• Who holds administrator access today, including vendor engineers and people who have left?
• What is the five-year total either way, including hardware refresh, power, cooling and the person who keeps it running?
• If the building is unusable tomorrow morning, what do we open, and from where?

The decision underneath the decision

The board is not choosing between two technologies. It is choosing who does the unglamorous work — patching, backups, key rotation, reading logs, disabling accounts — and verifying it happened.

On-premise means taking that on, defensible as long as it is staffed and funded like a real commitment rather than added to somebody's existing job. Cloud means buying it, defensible as long as the hospital audits what it bought. The failure mode is not choosing wrongly. It is choosing on-premise for control and never exercising it, or choosing cloud and assuming responsibility left with the server.

Hospitals that have this right are recognisable from one detail. Somebody in the room can answer the restore question with a date.