Solutions
Multi-site operations
The second site is where equipment management stops being a spreadsheet problem and becomes an architecture problem. One instance per site turns reporting into reconciliation; one shared instance without real isolation turns a data-protection question into an incident.
- Hospital operations
- Executive and finance
- Quality and compliance
What is multi-site equipment management?
Definition
Multi-site equipment management
Multi-site equipment management is running maintenance, compliance and reporting across several hospitals or clinics from one system, such that each site sees and manages its own equipment while the group can see the whole estate, without either capability compromising the other.
The two halves are in tension, which is the entire difficulty. Systems that optimise for site autonomy become silos that cannot report; systems that optimise for the group view leak, because someone eventually sees data from a site they have no business seeing.
The honest test of any vendor claim here is one question: where is the isolation enforced? If the answer is "we filter the query" or "the interface hides it", the isolation is a convention, and conventions fail under pressure.
Why the second site breaks everything
Because every shortcut that worked at one site was silently relying on there being only one site.
At one hospital, "the pump on ward six" is a sufficient identifier and everyone knows which workshop the job goes to. At three hospitals it is ambiguous, and the person who knows the answer is at a different address. The assumptions simply stopped holding.
The reflex is a system per site. It works until the group asks a question: downtime across the estate last quarter, sites with overdue safety testing, the same part bought at three prices. Each is now a reconciliation project across schemas that have already drifted.
The opposite reflex, one shared system with filtering, is worse. Filtering is applied by whoever wrote the query, which means correctly until someone writes a new one. In healthcare, the failure mode of that mistake is a regulatory event, not a bug report.
How Rydya handles many sites
One instance, one data model, and isolation enforced at the row rather than in the interface.
- 1
Every tenant record carries an organisation id
Not a filter that developers remember to apply. A column, protected by PostgreSQL row level security, plus a server-side permission check on every protected action, deny by default. The database refuses cross-tenant reads.
- 2
Isolation covers everything, not just tables
Database, storage with organisation-prefixed keys, search, exports, caches, notifications, API keys, webhooks and the audit trail. A boundary that holds for rows but not for exports is not a boundary.
- 3
A location switcher scopes the workspace
A user at one hospital works in a view that behaves as though it is the only hospital, across the workspace rather than only on a dashboard, with a visible banner and a one-click clear.
- 4
Users only see the locations they may access
Roles and permissions are scope aware across organisation, location, department, asset, work order and external vendor. A technician at site A cannot read site B assets, enforced rather than merely unpresented.
- 5
Group figures stay labelled as group figures
Organisation-wide numbers are explicitly marked organisation-wide. The most common multi-site reporting error is a scoped figure read as an estate figure, and the fix is honest labelling.
What a group can finally ask
The questions that were previously reconciliation projects become views.
Which sites have overdue planned work
Because plans bind to assets and assets belong to locations, this is a view rather than three exports and a pivot table.
Where the estate is losing the most time
Measured downtime, comparable across sites because it was measured the same way by the same system rather than estimated by three local conventions.
Whether the same fault is happening everywhere
A model failing at one site is a maintenance issue. The same model failing at four is a procurement decision, and you cannot see the pattern from inside one site.
What we are paying for the same part
Procurement, quotes and vendors in one system across sites, which is where group purchasing power stops being theoretical.
Whether a recall affects us anywhere
Recall matching runs against the whole fleet. Doing that per site, by hand, under time pressure, is how devices get missed.
Three ways to run multiple sites
Only one of these gives you both halves, and the difference is where isolation lives.
| Approach | Site autonomy | Group reporting | Isolation risk |
|---|---|---|---|
| One system per site | High | Reconciliation project, always late | Low, but so is everything else |
| One system, UI filtering | High | Easy | High: one unreviewed query leaks |
| One system, row level security | High | Easy | Enforced by the database, deny by default |
| Spreadsheets per site | Total | Not possible | Unknowable, which is its own answer |
Multi-site approaches against what each costs you
Hiding something in the interface is never the security boundary
Rydya treats the UI as a convenience and the database as the boundary. Every tenant record carries an organisation id enforced by row level security, and every protected action is permission checked on the server. If a vendor demonstrates multi-tenancy by showing you a filtered list, ask them what happens when someone calls the API directly.
Who runs it, and how autonomy survives
Centralise the data model and the standards. Leave the operational decisions where the equipment is.
The failure mode of group systems is political, not technical: a central team standardises everything, sites lose the ability to work the way their building works, and within a year there is a shadow spreadsheet.
The line that holds: centralise what has to be comparable, the data model, asset identity, the definition of downtime, the audit. Devolve what has to fit local reality, who is on call, which windows are negotiable, how a workshop sequences its queue. Scoping is per user and per location while the model underneath is shared.
Questions
How is one site's data kept separate from another's?
Every tenant record carries an organisation id, enforced by PostgreSQL row level security and a server-side permission check on every protected action, deny by default. Isolation covers the database, storage with organisation-prefixed keys, search, exports, caches, notifications, API keys, webhooks and the audit trail. Hiding something in the interface is never the security boundary.
Can a user work in one site without seeing the others?
Yes. A location switcher scopes the whole workspace rather than only a dashboard, with a visible banner and a one-click clear. Users only ever see the locations they may access, enforced server side rather than presented selectively.
Can we still get a view across the whole estate?
Yes, and organisation-wide figures stay explicitly labelled as organisation-wide. Overdue work, downtime, recurring failures, procurement pricing and recall exposure are views rather than a reconciliation exercise across separate systems.
What happens when equipment moves between sites?
A transfer moves custody while preserving history. The asset keeps every fault, test and downtime event it has ever had rather than starting again at the new location, which matters when the replacement case is eventually made.
Does each site need its own configuration?
Only where local reality differs. The data model, asset identity, the definition of downtime and the audit stay shared, because those must be comparable. Notification routing, escalation windows and responsibility are configuration, so a site can run its own operation without inventing its own vocabulary.
Keep reading
Executive reporting
What the group asks once the estate is on one data model.
Asset tracking
The register, and how transfers preserve history across sites.
Compliance
Evidence across an estate, without three schemas to reconcile.
Private hospitals and groups
What this scope model looks like for a real hospital group.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us