Indian hospital groups grow by adding branches, not floors. Branch-level permissions, consolidated revenue and cross-branch patient transfer are table stakes, not enterprise upsells.
Why Indian groups grow horizontally
Land is expensive. Bed licences are constrained. Catchment radius for OPD is 6-10 km in tier-1 cities. So a successful 60-bed hospital opens a second 60-bed hospital five kilometres away rather than adding a floor. By branch 3 the back-office starts to feel the pain — three separate registers, three sets of Excel sheets at month-end, no consolidated view of revenue, no ability to transfer a patient between branches without re-registering. By branch 5 the group either invests in real multi-branch infrastructure or stops growing.
Branch-level RLS — the security primitive that makes everything else safe
Multi-branch capability isn't a feature you bolt on. It's a database-level decision. Postgres row-level security policies enforced on every table mean a user logged into Branch A literally cannot see Branch B's data — not because the UI hides it, but because the database refuses to return it. That's the only foundation strong enough to build cross-branch reports, super-admin views and patient-portal continuity on. Application-level filtering is too brittle — one misconfigured route and you've leaked across branches.
Live revenue rollup — what the CFO actually needs
- Today's revenue across all branches, in one number, refreshed every five minutes.
- Per-branch break-up with day-on-day and same-day-last-week trends.
- Source-of-revenue split — OPD, IPD, pharmacy, lab, ancillary — across the group.
- Outstanding receivables by ageing bucket — 0-30, 31-60, 61-90, 90+ — with TPA-wise and patient-wise drill-downs.
- Pharmacy expiry write-off this month — already the third-biggest cost line in most multi-branch groups.
- Branch-level P&L estimate by 5th of the next month, not by 25th when accounting closes the books.
Cross-branch patient transfer without duplicate records
Patient walks in to Branch A on Monday, gets admitted, gets discharged. Wednesday they walk in to Branch B because Branch A is full. Without proper multi-branch design, Branch B re-registers them as a new patient — losing the entire admission record, allergies, medication list. A real multi-branch implementation looks the patient up across the group on registration, links to the existing patient ID, brings forward the relevant history, and writes the new visit against the same record. The CFO sees one patient with two visits, not two patients.
Permission scoping the right way
- Most users — scoped to one branch. They can never see another branch's data.
- Branch managers — scoped to one branch, but with manager-level reports inside that branch.
- Group operations — scoped to multiple branches with the same role across them.
- Super admin / CFO — group-wide read, but with audit log of every cross-branch query for accountability.
- Patient-portal staff — group-wide patient lookup, but with redacted clinical detail until the patient consents.
What goes wrong without it
Hospitals that don't get this right end up with a 'mother database' problem — one branch's data is treated as canonical, the rest sync to it nightly. Reports drift, patient records exist in two places, and the receptionist at Branch B is asked to wait until 'IT consolidates the data'. By the time the group hits five branches, the back-office is doing two days of reconciliation a month and nobody trusts the rolled-up numbers. The fix is always painful and almost always retroactive.
How MyEMR ships it
MyEMR was multi-branch from day one — every domain table has a hospital_id column with an RLS policy. Group-level reports run against the same single database with a super-admin role that lifts the RLS scope. Cross-branch patient lookup is a single API. Revenue rollup is a materialised view refreshed every five minutes. None of this is an enterprise upsell — it's how the platform is built.