Digitising a 30-Bed Hospital Without an IT Department

A 30-bed nursing home in a tier-2 district town runs on three things: a hardbound register at the front counter, a billing package installed sometime around 2011 that only one person knows how to close properly at day end, and the owner's nephew, who is good with computers. He sets up the printer. He reinstalls Windows when the machine gets slow. When the software throws an error at nine on a Saturday night, he is the one who gets the call. That is the IT department.

This is where a very large share of India's inpatient care actually happens — nursing homes, single-speciality units, small general hospitals in district towns. It is also the segment that enterprise hospital information systems fail most reliably, and the reasons are not technical.

Why enterprise deployments fail at thirty beds

Start with the money. The licence is quoted per bed and sounds reasonable. Then comes implementation: discovery, tariff master configuration, data migration, on-site training, consultant travel, integration charges, a change request or two. A 300-bed corporate hospital absorbs that across hundreds of users and several years. A 30-bed hospital can find it exceeds the entire annual software spend, sometimes by a multiple. Nobody collecting a few lakh a month can underwrite a project that costs more to install than to run.

Then the calendar. Enterprise deployments assume a hospital-side project owner who convenes workshops, chases sign-offs and escalates slipped milestones. In a 30-bed hospital that person is the medical superintendent, who is also running the OPD, or the owner, who is also a practising surgeon. Workshops get rescheduled. Go-live moves from March to June. By month five the enthusiasm has gone and the counter staff have quietly returned to the register, because the new system slows them down at exactly the hour they cannot afford to be slow.

Then the implementation team rotates off to the next project and support becomes a portal, a ticket number and a reply measured in business days. Ask around and the pattern repeats everywhere: registration in the software, billing half in the software and half in Tally, discharge summaries in Word, and the ward on paper.

Cloud, because there is no server room

The single most useful decision a small hospital can make is to not own a server. On paper an on-premise deployment looks cheaper over five years. In practice the "server" is a desktop under the reception counter, sharing a power board with the printer, in a town with four-hour outages and a monsoon that does unkind things to electronics. Nobody sizes the UPS. Nobody tests the backup. The first time anyone discovers the backup has been failing for eleven months is the day the disk dies.

Cloud removes the whole category — no patching, no backup regime, no antivirus licence, no annual maintenance contract for hardware. Kōami runs this way for exactly that reason: the hospital's only infrastructure is a browser.

The honest trade-off is connectivity. Going cloud means a wired line, a 4G failover, and knowing what happens at the billing counter when both are down. The answer should be a documented fallback — printed receipts, reconciliation the next morning — not a shrug. Any vendor who tells you the internet never goes down in a district town has not spent much time in one.

Registration and billing first. Everything else waits.

Phasing is not a compromise, it is the whole strategy. Start with two things.

• Registration. One patient, one MRN, for life. Nothing else works if the same person exists four times under four spellings. This alone repays the project.
• Billing. OPD receipts, IPD interim bills, cash and card, and one day-end summary the owner can actually read.

Run only that for eight to ten weeks. Let the counter staff get fast. Let the day-end tally match without a manual recount. Only then add pharmacy and stores, then IPD orders and nursing charges, then discharge summaries, then TPA and scheme claims.

Going live with everything at once feels efficient and is the most common way these projects die. Fifteen half-learned modules is a worse outcome than two that people trust.

Sensible defaults, and a number that gets answered

Configuration is a tax, and the customer pays it. A discovery workshop that asks a 30-bed hospital to define its bed transfer policy, its ward hierarchy and its charge posting rules is asking questions the hospital has never needed to answer formally. The honest answer is "we do whatever makes sense", which is not a specification.

What works is arriving with defaults already in place: a tariff master that can be edited rather than built, ready OPD, IPD and casualty workflows, NABH-shaped documentation templates, standard receipt and bill formats. The hospital changes the ten things genuinely specific to it — consultant list, room categories, package rates — and goes live in days rather than quarters. Kōami ships opinionated for this reason.

If a small hospital needs a consultant to explain its own software, the software has already failed.

The same realism applies to support. At eleven at night the ward sister cannot print a discharge bill and the family is waiting to leave. She is not going to raise a ticket on a portal; she is going to photograph the screen and send it to whoever helped her last time. Meeting that is not unprofessional. Refusing to is. Behind the scenes it still gets logged, categorised and fixed properly, but the hospital's entry point stays the channel it already uses at midnight. For a hospital with no IT staff, responsive support is not an add-on to the product. It is most of the product.

What not to digitise in year one

Being honest about scope is the cheapest thing a vendor can do.

• Consultant clinical notes. A visiting consultant who spends twenty minutes in the ward will not type. Keep paper notes, scan them against the episode, revisit in year two.
• Point-of-care vitals and nursing charts. Tablets at the bedside are a fine idea and a poor second-year priority.
• Consumable-level inventory. Start with pharmacy sales and high-value items. Batch and expiry tracking on every gauze roll can wait.
• Analytics dashboards. Get six months of clean registration and billing data first. A dashboard built over bad data is worse than none.
• Biomedical asset registers and payroll integration. Real value, wrong year.

The exception worth doing early is identity. Capturing ABHA at registration and getting the facility and practitioner registrations in order under ABDM costs very little and saves a scramble later. Do the identity groundwork; leave the rest of the health-record linkage until the basics are steady.

The test at twelve months

Not how many modules are live. Not whether the dashboard impresses a visitor.

The test is whether the register at the front counter has actually disappeared, whether the day-end collection figure is trusted without a recount, and whether the owner's nephew has got his Saturday nights back. A 30-bed hospital does not need a digital transformation programme. It needs two or three things that work every single day, and someone who picks up the phone when they don't.