Designing capability-based RBAC for clinical teams

A hospital is one of the clearest examples of why access control matters. A doctor, a pharmacist, a ward nurse and an operations lead all need different slices of the same patient record. Get it wrong and you've either blocked someone from doing their job or exposed data they should never see. Here's how MedOps keeps that straight with capability-based RBAC.

The trouble with raw role checks

The naive approach is to check the role directly in code: if (user.role === 'doctor'). It works on day one. By month six you have those checks scattered across dozens of endpoints, and a new requirement — “let operations cancel a bill but not delete a patient” — means hunting down every branch and hoping you found them all. Roles drift into a tangle of special cases, and nobody can say with confidence what a given role can actually do.

Capabilities, not roles

MedOps models permissions as capabilities in the form feature.action — for example patients.create, appointments.read, bills.update, prescriptions.sign. Roles are then just named bundles of capabilities. Code never asks “what is your role?”; it asks “do you hold this capability?”

// Instead of scattering role checks…
if (user.role === 'operations') { /* ... */ }

// …guard the action by capability.
@RequirePermission('bills.update')
updateBillStatus(/* ... */) { /* ... */ }

The benefits compound:

• One source of truth — what a role can do is a list of capabilities, not an archaeology dig through the codebase.
• Least privilege by default — a new endpoint is locked until you grant a capability for it.
• Easy evolution — splitting or merging responsibilities is a change to a bundle, not a refactor.

The six roles, mapped to work

MedOps ships six roles, each a bundle tuned to a real job:

Permissions should describe what someone can do, not who they are. People change teams; the action they're performing is what you actually want to authorise.

Enforce in one place, on the server

Capabilities only help if they're checked where it counts. In MedOps the guard runs on the API, before the handler executes — the React client uses the same capability data to hide controls a user can't use, but the UI is a convenience, never the boundary. Every check happens against the authenticated session, which is carried in an AES-256 encrypted, httpOnly cookie rather than a token in browser storage.

Make it auditable

Because actions are expressed as capabilities, they're also easy to log. MedOps writes tenant-scoped audit entries for significant actions — patient.create, prescription.sign, bill.update — so administrators can answer “who did what, and when?” without reverse engineering application logs. Access control and audit end up speaking the same vocabulary.

Where to start

If you're retrofitting an existing system, start by naming the capabilities you already check implicitly, then route every guard through a single decorator or middleware. The first refactor is the hardest; after that, every new feature simply declares the capability it needs and the rest of the system already knows what to do.

Curious how the role model would fit your hospital's workflows? See the roles or book a demo.