Industries
Private hospitals and hospital groups
A hospital group is not a big hospital. It is several hospitals with different equipment, different local practice and different levels of maturity, plus a centre that is accountable for all of it and can see none of it without asking. Almost every problem a group has with equipment is a version of that sentence.
- Hospital operations
- Executive and finance
- Biomedical engineering
What is different about a hospital group?
Everything that was a conversation becomes a report, and everything that was local knowledge becomes an information problem.
In a single hospital, the biomedical manager knows the estate. They know which pumps are unreliable, which ward loses equipment, which vendor turns up. None of that is written down and it does not need to be, because the person who knows is in the building.
Add three more sites and that knowledge does not scale, it fragments. The centre asks a question that sounds simple, such as how much unplanned downtime cost us last quarter, and receives four answers built four different ways, arriving over three weeks, that cannot be added together. The group does not have an equipment problem at that point. It has a comparability problem, and it will keep making decisions without evidence until the comparability is fixed.
The second thing that changes is that local autonomy stops being free. One site tracking maintenance in a spreadsheet is a local choice. Four sites each doing it their own way means the group cannot answer a regulator, negotiate with a vendor from strength, or move a device from where it is idle to where it is needed.
How Rydya handles a group
One tenant containing every site, with scope doing the work that separate systems would otherwise do badly.
One organisation, many locations
A group is one tenant with several locations, not several accounts stitched together. That is what makes a consolidated figure possible at all: the sites are rows in one model rather than exports from four systems.
Scope is the everyday boundary
A location switcher scopes the whole workspace. Users see the sites they may access, enforced by server-side permission checks and row level security rather than by hiding menus. A site lead sees their hospital; the centre sees the group.
Scoped figures stay labelled as scoped
A number filtered to one site says so, and a group-wide number says so. This sounds fussy until the first time a site figure is quoted in a board paper as a group figure, which happens in every organisation that does not do it.
Metrics are defined once
Compliance measured one way at one hospital and another way at the next produces two true reports that contradict each other. Definitions live in a registry with versions, so the group is comparing like with like or it knows it is not.
Local practice survives
Intervals, procedures, limits and approval rules are configuration, set per organisation and applied to the equipment they belong to. Standardising the platform does not force every site to pretend it has the same estate.
Why the group figure is usually the one that fails
Because it is assembled from whatever each site could supply, and a total built from four different definitions is defensible in none of them.
The board asks for a number. Each site produces one. Somebody adds them up in a spreadsheet. The result goes into a paper, and it is wrong in a way nobody can see, because site A counted downtime from the fault report and site B counted it from the engineer arriving, and neither was hiding anything.
This is why the fix is not a better spreadsheet or a stricter reporting template. It is that the sites have to be producing the same record in the first place, from the same definitions, and the consolidation has to be a query rather than an assembly exercise. Any figure that took a fortnight to build is a figure nobody will let you check in the meeting where it matters.
How to roll out across a group without a two-year programme
One site first, deliberately the awkward one, and widen only once the rhythm is real rather than once the plan says so.
The instinct in a group is symmetry: launch everywhere at once so no site feels second. It reliably produces a programme large enough that its failure is nobody's fault. The alternative is to pick a single site, get the register imported, get codes on the equipment that matters, get technicians using the mobile surface, and let the first month of real work expose what the plan got wrong.
Choose the awkward site rather than the enthusiastic one. A pilot at your best hospital tells you what happens when everything goes well, which you did not need to know. A pilot where the estate is messiest tells you what the rollout actually costs, and the group learns it once rather than four times.
Then widen. The second site is faster than the first by a large margin, because the configuration work, the intervals, the templates, the approval rules, is mostly reusable, and because you now have people inside the organisation who can say what good looks like.
A group is one tenant, and cross-tenant sharing is out of scope
Multi-site groups live inside one organisation. Isolation between organisations is enforced at the database row and covers storage, search, exports, notifications, API keys, webhooks and audit. If your structure needs two hospitals in genuinely separate tenants to share a device history, that is not something Rydya does, and it is better to know that now than to discover it during implementation.
Who this is for inside the group
The person accountable for equipment across sites who currently finds out by asking, and the site teams who are tired of being asked.
The centre wants comparability and evidence. The sites want to not spend Thursday assembling a return for somebody else's report. These are usually treated as opposing interests, and they are the same interest: a site whose work produces the record automatically is not asked for a return at all, because the centre can already see it.
That is the honest case for a group. Not that the centre gets a dashboard, but that the reporting burden the centre currently places on the sites stops being a burden, because it stops being a separate activity from doing the work.
Questions
Is each hospital a separate account?
No. A group is one organisation containing many locations, which is what makes a consolidated figure possible rather than an assembly exercise. Access is handled by scope: a location switcher scopes the whole workspace, and users only see the sites they may access, enforced on the server and at the database row rather than by hiding menus.
Can sites keep their own maintenance intervals and procedures?
Yes. Intervals, procedures, limits and approval rules are configuration rather than product opinion, so standardising the platform does not force every site to pretend it has the same estate. What standardises is the shape of the record and the definition of the metric, which is what makes sites comparable in the first place.
Can a site lead see another hospital's equipment?
Only if you grant it. Permissions are scope aware across organisation, location, department, asset, work order and external vendor, deny by default, and enforced by server-side checks plus row level security. Users see the locations they may access; that is enforced rather than merely unpresented in the interface.
How should we roll out across several hospitals?
One site first, and preferably the awkward one. A pilot at your best-run hospital tells you what happens when everything goes well, which you did not need to know. The messiest estate tells you what the rollout actually costs, and the group learns that once instead of four times. The second site is substantially faster because most configuration is reusable.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us