Features
Role based access
Access control in a hospital is not a matrix of roles against features. It is a question of scope: this technician, at this site, for this department, on this work order, for this vendor. A permission model that only knows what someone is allowed to do, without knowing where, is not a model of a hospital.
- Clinical engineering
- Quality and compliance
- Hospital operations
What is scope-aware role based access?
Definition
Scope-aware RBAC
Scope-aware role based access control grants a permission not globally but within a boundary: a role confers the ability to perform an action on the specific organisations, locations, departments, assets, work orders or vendor relationships the holder is entitled to, rather than on everything of that type.
The difference shows up immediately in a real hospital group. "Technician can edit assets" is useless as a rule, because the actual requirement is "this technician can edit assets at their site, in their departments". Flat RBAC forces you to choose between granting too much and creating a role per site, and organisations end up doing both.
The second requirement is deny by default. A permission model whose failure mode is to allow is not a security model, it is a suggestion, and it fails in the direction that produces incidents.
Why access control fails quietly
Because it is usually implemented where it is visible rather than where it matters, and the gap only becomes apparent when somebody bypasses the interface.
The most common architecture in this category is: hide the button. The user without permission does not see the action, so they cannot take it. This works precisely until someone calls the API, or an integration does, or a new screen forgets the check. The permission was never a rule; it was a rendering decision, and rendering decisions do not travel.
The second failure is the escape hatch. Every system accumulates one: a support role, a break-glass account, an admin flag that skips checks. It exists for good reasons, it is used rarely, and it is a single credential away from being the whole security model. Rydya has no impersonation, which is a real constraint on our own support and a deliberate one.
The third is drift. Permissions granted for a project, a secondment or an audit are never removed, because nobody owns removal. Over three years the model stops describing the organisation, and the only person who knows is the one who eventually leaves with more access than the CEO.
How Rydya enforces access
Server side first, at the database row underneath, deny by default, and scoped to the boundary that matters.
- 1
Every protected action is checked on the server
Before it happens, not after, and independently of what the interface chose to show. If the API is called directly, by a person or an integration, the same check runs. Hiding something in the UI is a convenience and is never the security boundary.
- 2
Every tenant record carries an organisation id
Protected by PostgreSQL row level security. This is the layer beneath the permission check: even a query nobody reviewed cannot read across tenants, because the database refuses. Isolation that depends on developers remembering a WHERE clause is isolation that will fail on a Friday.
- 3
Permissions are scope aware
Across organisation, location, department, asset, work order and external vendor. A technician at site A cannot read site B assets. A vendor sees the work orders they are engaged on and nothing else.
- 4
Deny by default
The absence of a grant is a denial, not an unknown. New capabilities are unavailable until explicitly granted, which is the direction you want a mistake to fail in.
- 5
Every decision lands in the audit trail
Actions that were permitted are recorded append-only and hash-chained, in the same transaction as the change. What the trail contains is therefore what was actually authorised, not what was attempted.
The scopes that matter in a hospital
Six, and a model missing any of them forces someone into a workaround.
Organisation
The hard boundary, enforced at the database row rather than by filtering. Isolation covers the database, storage with organisation-prefixed keys, search, exports, caches, notifications, API keys, webhooks and audit.
Location
The everyday boundary in a group. A location switcher scopes the whole workspace, users only see locations they may access, and organisation-wide figures stay labelled as organisation-wide so a scoped number is never misread.
Department
Where the operational reality lives. Equipment belongs to departments, and so does responsibility, which is why routing and escalation need this scope to mean anything.
Asset and work order
The fine grain. Access to a specific device or a specific job, which is what makes involving someone in one thing possible without involving them in everything.
External vendor
The scope most systems forget. A service engineer from a manufacturer needs the work order they are attending and nothing else, and "nothing else" has to be enforced rather than assumed.
Machine identities
Service accounts are scoped credentials with their own rate limits and location scope, not a shared admin key in a CI variable. An integration should be able to do less than a person, not more.
Where the boundary lives
The same feature name covers architectures with completely different failure modes. The deciding question is what happens when the API is called directly.
| Approach | Stops a direct API call? | Stops an unreviewed query? | Fails toward |
|---|---|---|---|
| Hide the button in the UI | No | No | Allow |
| Check in the client | No | No | Allow |
| Check in the API handler | Yes, if it was written | No | Allow, when forgotten |
| Server check plus row level security | Yes | Yes, the database refuses | Deny |
Access-control approaches against their failure mode
There is no impersonation, and no break-glass override
The platform console has no ability to log in as a tenant user. Support access is requested, time bound, recorded and revocable, and secrets are redacted rather than displayed. This is a genuine constraint on our own support team, which is precisely why it is worth having: an escape hatch nobody can use is the only kind that cannot be misused.
Who should own the model, and how it stays true
Someone with authority to say no, reviewing grants on a schedule. The technology cannot fix a permission model nobody prunes.
Access models do not decay because the software is wrong. They decay because granting is easy, urgent and popular, while removing is fiddly, invisible and unpopular. Every hospital has staff carrying access from a rotation three years ago, and it is nobody's fault in particular, which is exactly why it happens.
The structural help Rydya offers is that scope-aware roles make the right grant convenient. When "this technician, at this site, in these departments" is expressible, people use it, whereas a flat model makes over-granting the path of least resistance. The rest is organisational: someone has to own review, and the audit trail is what makes that review possible rather than theatrical.
Questions
Is hiding a button in the interface enough?
No. A hidden button is a rendering decision rather than a security control. Every protected action in Rydya is checked on the server before it happens, independently of what the interface showed, and every tenant record is additionally protected by row level security at the database. If the API is called directly, by a person or an integration, the same checks run.
Can a technician at one site see another site's equipment?
No. Permissions are scope aware across organisation, location, department, asset, work order and external vendor, and organisation isolation is enforced at the database row by row level security, deny by default. Users only ever see the locations they may access, and that is enforced rather than merely unpresented.
How do external service engineers get access?
Through the external vendor scope: they see the work orders they are engaged on and nothing else. This is the scope most systems forget, which is why vendor access so often becomes a shared login with far more reach than anyone intended.
Can Rydya staff log in as one of our users?
No. There is no impersonation. Support access is requested, time bound, recorded and revocable, and secrets are redacted rather than displayed. It constrains our own support team, and that is the point: an override that exists will eventually be used, so the safest version is the one that was never built.
How do integrations authenticate?
With scoped service accounts that have their own rate limits and location scope, rather than a shared admin key. An integration should be able to do less than a person, not more, and its scope should be visible and revocable independently of any human account.
Keep reading
Audit trails
What gets recorded once a permission check has passed, and why it cannot be edited.
Multi-site operations
Where scope stops being theoretical: one instance, many hospitals.
Work orders
Permission-checked transitions, including the gate with no bypass.
Security
The wider security model, including what we have not done yet.
Authentication
Proving who you are, before this page decides what you may do.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us