For multi-facility operators
Every site independent. Every boundary explicit.
Model several facilities with separate staff, structure and records while keeping tenant and facility scope explicit on every request.
Where the system breaks
Connection cannot mean accidental visibility
Separate systems create separate vendors, security models and upgrade paths. A loosely separated shared system creates a more serious problem: one query or grant can expose one facility’s records to another.
The safe model starts with independent tenant and facility boundaries. It does not infer access from organisational convenience.
Operating model
How the multi-facility model is drawn
Each principle names an owner or a boundary. The architecture is useful only when it prevents responsibility from disappearing at a handoff.
- 01
Each facility keeps its own context
Departments, units, staff affiliations and records are resolved within an explicit facility scope.
- 02
Isolation sits below the screen
Data access applies tenant and facility context at the persistence boundary. Missing scope fails closed.
- 03
Cross-site access is never implied
A person working at more than one site needs an explicit grant for each relevant scope.
- 04
No hidden group-level promise
The model does not imply a parent tenant, consolidated clinical record or cross-site executive view. Those are separate capabilities, not wording shortcuts.
Several facilities can share an architectural standard without sharing records or pretending independent sites are one tenant.
A clearer next step
Apply the model to your setup
We will use your structure and workflow questions, then state plainly what the demonstration and engagement scope can cover.