JWT carries branch context
Every authenticated request includes the user's active branch claim plus the set of branches they're authorised against. No request-body branch parameter to spoof.
Multi-branch architecture
Software designed for
hospital groups, not single buildings.
Most healthcare software treats a multi-site group as a deployment problem — run one install per site and figure out the rest. CareHubOS does the opposite. Every entity knows what branch it belongs to. Every read is filtered. Every write is stamped. Cross-site movement is a workflow, not a sync hack.
CareHubOSOPD · Accra HQ
Accra HQ
Your branches
Accra HQPrimary
Tema Clinic
Sunyani Branch
The four layers of branch isolation
Branch context isn't a feature — it's the foundation. Every layer of the stack enforces it.
Query filter at the ORM layer
Every branch-scoped table reads through an Entity Framework filter that checks the JWT claim. The framework refuses to return cross-branch rows unless code explicitly bypasses with audit logging.
Strict mode on listings
List endpoints narrow further to the active branch — even admins. Cross-branch reads go through dedicated, audited, capped endpoints like global patient search.
Stamped on create
When a clinician creates a prescription, a visit, a dispense, an admission — the active branch is stamped automatically from their JWT. No way to forget.
Cross-branch flows you actually need
Strict isolation would be useless if it stopped patients moving between sites or stock crossing the group. So those flows are first-class workflows — not data-sync hacks.
9-state stock transfer
Request → Approve → Reserve → Pack → Ship → In-Transit → Receive → Confirm → Close. Each step records the actor; lots are cloned at the receiving branch so expiry stays correct.
Global patient search
A walk-in from another branch is found by MRN, name, or mobile. The result is capped, audited, and clearly tagged as a cross-branch result — never silently merged into the local list.
Group-wide aggregate views
Dashboards roll up across branches you're authorised for. Operational reads stay strictly per-branch; aggregates are an opt-in, role-gated view.
What changes when branches are first-class
Pulled from a real-world hospital group's pain list.
| Concern | Most EHRs | CareHubOS | |
|---|---|---|---|
| Onboarding a new branch | New install, separate database, weeks of replication setup | New row in Branches. Done. | |
| A doctor working two sites | Two user accounts, two passwords, two record sets | One account, two branch assignments, role per site | |
| Moving stock between branches | Manual paperwork, email, then re-key at the receiving end | 9-state transfer with audit + lot cloning | |
| Reporting across the group | Export CSV, dump in Excel, reconcile manually | Native group-wide aggregates with branch breakdown | |
| A patient from another site walking in | Re-register them; no link to their actual record | Find by MRN, start a visit, audit trail intact | |
| Admin sees cross-branch by accident | Common — filters often opt-in | Impossible — strict isolation by default, audited bypass only |
One install. Every site. Same software.
Book a demo and we'll walk through the branch switcher, a cross-branch transfer, and the per-branch role override on the same screen.