Running a Multi-Branch Hospital Group on One System

A hospital group is not one hospital repeated. It is several hospitals, each with its own consultants, its own local suppliers, its own quirks of layout and habit, and a head office that needs to see all of them at once without flattening what makes each one work. The temptation, when a group grows, is to let every branch run its own systems and reconcile the numbers later. That works until it does not - until a patient who was seen at one branch turns up at another and their history is invisible, until central procurement cannot tell which site is overstocked while another runs dry, until the monthly board pack is three weeks of manually merging spreadsheets that never quite agree. Running a group on one system is not about central control for its own sake. It is about giving each branch autonomy where it needs it and the group visibility where it needs that.

One patient, many branches

The clearest test of a group system is what happens when a patient moves between sites. In a federated mess of separate systems, the patient is effectively a new person at each branch - re-registered, re-explained, their allergies and history left behind at the site that first recorded them. That is not just inconvenient. It is a clinical risk, repeated at every internal referral.

A single patient identity across the group fixes this. The same person carries one record, one history, one set of allergies and results, wherever in the group they are seen:

• A referral from a smaller branch to the group's tertiary centre arrives with the full history attached, not a scribbled note.
• Results ordered at one site are visible to the treating clinician at another.
• The patient does not repeat their story, or their registration, at every door.

Kōami holds that shared identity while still letting each branch run its own OPD, its own wards, and its own local workflows. The record is common; the operation stays local. That balance - shared where it helps the patient, local where it helps the branch - is the whole design principle of a group system.

Cluster structure without a straitjacket

Groups are rarely flat. There are clusters - by city, by region, by tier - and the reporting and control structure has to reflect that reality rather than fighting it. A regional director wants to see their cluster rolled up; a branch administrator wants their own site's numbers without noise from the others; the board wants the whole group on one page.

Centralisation should be a dial, not a switch. Some things belong to the group; many things belong to the branch; wisdom is knowing which is which.

The workable pattern is a hierarchy where the group sets the standards - the master data, the item catalogue, the chart of cost centers, the core policies - and each branch operates within them while keeping local control of the things that are genuinely local. Doctor rosters, OT schedules, ward configurations, and local vendor relationships stay with the branch. Pricing might be set centrally with room for local adjustment, or set locally within group-defined bands. Kōami supports that layered structure so the group is coherent without every branch being forced into an identical mould that fits none of them well.

Inventory that moves across the group

Stock is where a group system pays for itself fastest. Each branch running its own isolated store will, reliably, produce the same absurd situation: one site writing off expired reagents while another places an emergency order for the very same item at a premium. They simply cannot see each other.

Put the branches on one inventory backbone and that waste becomes visible and fixable. Before any site raises an external purchase order, the system can check group-wide stock and suggest an inter-branch transfer from a location holding surplus. Central procurement can negotiate as a group - real volume, real leverage - while each branch still requisitions against its own cost center and receives against its own GRN.

• See on-hand stock across every branch and the central store in one view.
• Suggest transfers before purchases, turning one site's surplus into another's supply.
• Negotiate group contracts on real aggregate volume, not per-site guesswork.
• Keep reorder points local to each branch's actual consumption and lead times.

Because Kōami connects inventory and procurement across the whole group, the reorder logic and the three-way match that work for a single hospital simply extend across many, with the group's scale as an added lever rather than an added headache.

Reporting that reconciles by design

The monthly grind of merging branch spreadsheets exists only because the branches were never on the same data model. When they share one system, the roll-up is not a project; it is a query. Occupancy, revenue, OPD throughput, average length of stay, stock value, procurement spend - each can be read per branch, per cluster, or for the group as a whole, using the same definitions everywhere.

That last point is the quiet one that matters most. When "bed occupancy" or "average length of stay" means the same thing at every site, comparison becomes fair and useful. You can see that one branch discharges faster, ask why, and spread the practice. When every site defines its metrics slightly differently, comparison is noise and the board learns nothing. A common system enforces common definitions as a byproduct, so benchmarking across the group becomes a management tool rather than an argument about whose numbers are right.

Rolling out without breaking the branches

The risk in unifying a group is a big-bang cutover that disrupts live clinical operations across many sites at once. The saner path is to bring branches onto the shared system in sequence, prove the model at one or two sites, carry the master data and identity forward, and let each branch adopt the common core while keeping its local configuration intact. Kōami's shared-identity, layered-control structure is built for that gradual convergence rather than an all-or-nothing switch that no operating hospital can safely afford.

A multi-branch group run well feels, to a patient, like one organisation that happens to have several front doors. It feels, to a branch administrator, like their own hospital with better backup. And it feels, to the group's leadership, like a single trustworthy picture instead of a monthly reconciliation. Getting there is not about imposing sameness. It is about sharing what should be shared - the patient, the standards, the visibility - and leaving to each branch the local judgement that made it worth having in the first place.