Switching Hospital Management Software Without Losing a Day of Billing

Hospitals stay on software they dislike for years, and the reason is almost never that they cannot find a better one. It is that the current system holds twelve years of patient records, every outstanding balance, the stock on hand, and forty admitted patients, and nobody can see how to move all of that without the hospital stopping.

The hospital cannot stop. That constraint is real and it is the whole design problem. But it is a solved design problem, and the hospitals that switch badly usually did so by treating a migration as an installation.

When is switching actually worth it?

When the current system is costing you more than the switch will, and you can name the cost.

Dissatisfaction is not a business case. These are:

• Revenue leakage you can measure. Charges not captured, claims rejected for reasons the system should prevent, consumables consumed and not billed.
• Compliance exposure. The system cannot produce audit trails, statutory registers, or the ABDM and DPDP behaviour now expected of it, and the vendor has no dated plan.
• Staff time spent on workarounds. Count the hours in registers, spreadsheets and re-keying. In most hospitals this is the largest number and the least measured.
• Vendor risk. The product is no longer developed, support has degraded, or the people who knew your deployment have left.
• Growth you cannot serve. A new branch, a new speciality, or a bed count the system was never designed for.

If none of these apply and the complaint is that the interface looks dated, the switch will probably cost more than it returns. Interfaces are the most visible thing about software and among the least consequential.

What actually has to move?

Six data sets, and they have very different difficulty levels.

• Patient master. Every patient identity, deduplicated. This is the foundation and the one most worth spending time on.
• Financial position. Outstanding balances, advances held, credit notes, and unbilled charges on current admissions. This must be exact; there is no acceptable rounding.
• Clinical history. Consultations, diagnoses, results, prescriptions, discharge summaries. Usually the largest volume and the most variable in structure.
• Stock. Current holdings by store and batch, with expiry, plus open purchase orders.
• Masters and configuration. Tariffs, packages, rate contracts, doctors, departments, users and roles. Rarely migrated; usually rebuilt, and rebuilding is often the right call.
• Open transactions. Admitted patients, pending orders, undelivered lab results, unclosed claims. The hardest category, because it is live at the moment of cutover.

The clinical history can arrive over the following month. The financial position and the admitted patients cannot. Design the cutover around the second group.

How do you handle the patients who are admitted on cutover day?

You bring them across as open admissions, with their charges to date, and you accept that the discharge bill is assembled from two sources.

There are three workable patterns and the right one depends on your admission volume.

Full migration of open cases. Every admitted patient is created in the new system with their admission date, bed, and accrued charges. Clean afterwards, expensive on the night, and requires the old system to produce an accurate charge position at a frozen point in time.

Run-out. New admissions go into the new system from cutover; existing admissions are discharged from the old one. Both systems run for a period equal to your longest length of stay. Simplest technically, and it means two systems, two counters and a confused front office for two or three weeks.

Hybrid, which is what most hospitals end up doing. Long-stay and critical care patients run out in the old system; everything else migrates. Requires a clear rule agreed in advance and a person on each ward who knows which patients are in which system.

Whichever you choose, decide it early. This is the single decision that most affects how the cutover feels to staff.

What does the timeline look like?

For a mid-sized hospital, three to six months from contract to cutover, and the data work starts far earlier than most people expect.

A workable sequence:

Weeks one to three: data audit. Extract everything from the old system and look at it honestly. Duplicate patients, blank fields, free-text where codes should be, balances that do not reconcile. Every migration is delayed by the discovery that the source data was worse than assumed, so make the discovery first.

Weeks two to eight: configuration in parallel. Tariffs, packages, departments, roles, document templates, and the workflow decisions. This is where the new system is actually built, and it is the work most often underestimated.

Weeks six to ten: data cleanup at source. Merge duplicates, close what should be closed, reconcile balances. Doing this in the old system rather than during migration is much cheaper.

Weeks eight to fourteen: trial migrations. At least three. Each one produces a reconciliation report, and the report has to balance before you go further.

Weeks twelve to sixteen: parallel run and training. Selected departments enter data in both systems for a defined period, and every difference is investigated.

Cutover: a low-volume window, usually a weekend, with the final delta migration, a reconciliation sign-off, and both systems available in read-only for a defined period afterwards.

What goes wrong, and how is it prevented?

Five failures account for most bad migrations.

Migrating dirty data because cleaning it felt like a delay. The mess arrives intact and is more expensive to fix live.

No reconciliation gate. Every trial migration must produce a report that ties: patient counts, total outstanding, stock value, by department. If it does not tie, you do not proceed. Hospitals that skip this discover the gap during the first month-end close.

Losing read access to the old system. Negotiate continued read-only access, in writing, before you sign with the new vendor. You will need it for at least a year for queries, disputes and audits, and once the relationship has ended the price of access goes up.

Training as an event. Staff trained six weeks before cutover have forgotten. Train close to go-live, train by role rather than by module, and plan refresher sessions for the second and fourth weeks when the real questions appear.

Nobody owning the decisions. A migration generates a hundred small judgement calls a week. Without a named internal owner with authority, they queue.

What should the contract say?

Four clauses that are much easier to negotiate before you sign than after.

Migration scope and responsibility, stated in data sets, with the new vendor's obligations and yours written separately. "Data migration included" is not a scope.

Reconciliation criteria and a sign-off gate, with an agreed definition of what a successful migration looks like numerically.

Rollback. What happens if the cutover fails at two in the morning, who decides, and how the hospital operates the next day.

Exit. The one you are exercising against your current vendor is the one you will one day exercise against the new one. Ask for the export format and cost in writing now, while you have leverage.

The part nobody plans for

The month after go-live is harder than the cutover, and it is the part that determines whether staff conclude the switch was worth it.

Expect billing queries, reports that do not match the old ones because the old ones were calculated differently, and a fortnight of slower throughput at the counters. Staff the first month deliberately: extra hands at billing and registration, a visible support presence on the floor, and a daily issues meeting at a fixed time that ends when the list is empty.

Kōami's implementations follow the sequence above, with reconciliation gates and read-only access to the outgoing system as standing requirements rather than negotiable extras. That is not a differentiator so much as the minimum any hospital should demand from any vendor it is considering, including the one it already has.