How to Manage Patient Records Across Multiple Branches

If your hospital group operates more than one site, every interaction with your EHR is shaped by a single question: where do patient records live? The answer determines onboarding speed, audit visibility, reporting accuracy, and how badly a single bad migration can hurt you.

This piece walks through the three patterns we see in practice — federated, replicated, and natively multi-tenant — and the trade-offs each one locks you into for years.

Pattern 1: Federated installs

The most common starting state. Each branch has its own EHR install, its own database, its own admins. Records don't follow patients between sites. If a patient registered at Branch A walks into Branch B, the receptionist at B either:

• Registers them again (creating a duplicate record), or
• Calls Branch A to look the patient up, then re-types the data into Branch B's system.

Why groups end up here: organic growth. The first clinic deployed an EHR. The second clinic opened, and rather than re-architect everything, the team just stood up another install. By the third or fourth clinic, the federation is permanent.

What it costs you:

• Duplicate patient records. The same person exists three times across three branches. Their allergies, problems, medications all fragment.
• Manual reconciliation. Group reporting requires CSV exports from every branch, merged by hand. By the time the report exists, it's stale.
• No cross-branch operational features. Stock transfers, referrals, shared on-call rotas — all manual.
• Compliance fragility. A regulator audit asks for "every interaction with this patient." You have to ask each branch separately. Some answers conflict.

When it's defensible: if your sites are operationally independent (different business units, different brands, different legal entities), federation might actually be correct. For most hospital groups, it isn't.

Pattern 2: Replicated records

The next stop on most groups' migration path. Each branch still has its own install, but a synchronisation layer (often nightly, sometimes near-real-time) replicates patient records between them. Brand A's patient appears at Brand B with a one-day lag.

Why groups try this: it solves the most visible federation pain (the patient who walked in from another branch) without requiring a full re-platforming.

What it costs you:

• Sync conflicts. Two branches edit the same patient record on the same day. Whose change wins? You will hate the answer.
• Stale data. Anything below your replication interval is effectively invisible. A patient seen at Branch A this morning shows up at Branch B with this morning's encounter missing.
• Operational complexity. You now have an EHR and a replication system. When something breaks, you have to figure out which one to blame at 2am.
• Still no group-level operations. Stock transfers, group-wide reporting — replication doesn't help with these because they aren't about records, they're about workflows.

When it works: in groups with rare cross-branch traffic and very small operational scale. Most multi-branch healthcare groups are neither.

Pattern 3: Natively multi-tenant

A single install. Single database. Branches are first-class entities in the data model. Every row that belongs to a branch carries a branch_id; every query filters automatically; every audit log records which branch the action happened at.

What it gives you:

• One patient, many encounters. The same patient record is seen at any authorised branch, in real time, with no replication.
• Branch-isolated operations. The ward nurse at Branch A doesn't see Branch B's patients. Default behaviour.
• Group-level visibility. Roll-up dashboards work because the data is already unified. No CSV merging.
• Cross-branch workflows as features. Stock transfer, referral, cross-coverage — first-class flows, not workarounds.
• One audit trail. Compliance asks for "every interaction with this patient" — you run one query.

What it costs you:

• Re-platforming if you don't start with it. This is the honest catch. Native multi-tenancy is hard to add to a system that wasn't designed for it. If you're already on a federated stack, switching means migrating — non-trivial.
• Stricter access discipline. Because the data is unified, the access controls have to do real work. Branch-scoping, role-based access, override-with-reason — all of this matters more.

Which pattern fits which group

Rough guidance, with the usual caveats:

• One site, no plans to grow: federation by default works fine. Don't over-engineer.
• Two sites, opportunistic: still federated; revisit when site three is on the horizon.
• Three or more sites, growing: native multi-tenancy is the right destination. If you're not there yet, plan the migration before adding the next site.
• Specialist clinic chain (same brand, repeating service line): native multi-tenancy from day one. The federation tax compounds fast in this shape.
• Holding-company groups (genuinely different brands and services): federation might actually be correct. Don't fight the data model.

The migration question

The hardest decision for most groups is when to migrate from federated to native. The answer is almost always "earlier than you think." The cost of moving 50,000 patient records is high. The cost of moving 500,000 is brutal.

If you're already at the federated-with-replication stage, the migration cost stays roughly flat until something forces it (a regulator change, a brand consolidation, a board decision). It's worth doing the migration before that forcing function, not after.

What CareHubOS does

CareHubOS is natively multi-tenant from the first line of code. Every entity carries a BranchId. Every query is filtered at the database layer (not the application layer — too easy to forget). Every audit log records the branch context. Cross-branch stock transfers, patient lookup across sites, group-level reporting — all first-class workflows, not bolted on.

We didn't build this because it's elegant. We built it because the federation tax — the duplicates, the reconciliation, the missing patient at 11pm on a Saturday — is what hospital groups complain about most often, and the only honest fix is the data model.

If you're choosing between patterns: pick native multi-tenancy unless you have a genuinely compelling reason not to.