RBAC, ABAC or Break-the-Glass: Choosing an Access Control Model for Patient Records

A consultant on call at 2am needs the chart of a patient who has just crashed in a ward she does not normally cover. The system says no: she is not on that team, so the record is shut to her. She borrows a house officer's login, opens the chart, and saves the patient. Now ask the harder question. The next morning, the same consultant idly opens the file of a colleague admitted for a procedure she has no part in. The system says yes, because last night you widened her access to stop it blocking care. One model let her save a life and snoop on a workmate with the same permission. That tension, between the chart that must open in an emergency and the chart that must stay shut, is not a policy problem you solve with a memo. It is a design choice, and the choice has a name: RBAC, ABAC, or break-the-glass.

RBAC, ABAC and break-the-glass, in plain terms

Role-Based Access Control (RBAC) decides access from who you are on the org chart. A doctor role sees clinical notes, a pharmacist role sees the medication list, a records clerk sees demographics and appointments. You assign a person to a role, the role carries a fixed bundle of permissions, and that is the whole logic. It is simple to explain to a hospital board and simple to audit, which is why most Nigerian EMR deployments start here.

Attribute-Based Access Control (ABAC) decides from a set of attributes evaluated at the moment of the request: who is asking, which patient, what is the relationship between them, the time, the location, the device. Access is granted only when the rule fires, for example "allow a doctor to read this chart if the doctor is on the patient's current care team and the request comes from a hospital workstation during the admission". RBAC asks one question, what is your role. ABAC asks several, and the answer can change minute to minute.

Break-the-glass is neither a model nor a loophole. It is a deliberate, time-boxed exception built on top of whichever model you run. The consultant who is correctly denied access can override the denial, but the override demands a reason, opens access for a fixed window, fires an alert, and writes a record that names her, the patient, and the time. The glass is meant to break in an emergency. The point of designing it properly is that breaking it is loud, not quiet.

The principles a designer actually reasons from

Before you pick a model, you reason from three principles, and they are older than any EMR. Least privilege says a person gets the minimum access the job needs and nothing spare. The records clerk who books appointments does not need to read psychiatric notes to do that job, so she does not get them. Need-to-know is least privilege applied to a specific patient rather than a category: being a doctor in the building is not the same as being this patient's doctor. Separation of duties says one person should not hold every step of a sensitive action end to end. The clinician who orders a controlled drug and the pharmacist who dispenses it are deliberately different logins, so that a single compromised account cannot both prescribe and release.

None of this is a regulator inventing work. The NDPA classifies health data as sensitive personal data and tells a controller to put appropriate technical and organisational measures in place. Access control is the measure that lands most squarely on the word "appropriate". The National Health Act is blunter. A person may not disclose a patient's health records unless that person is authorised, and the duty to keep those records safe rests with the head of the health establishment, by name. So when the consultant borrows a house officer's login at 2am, the breach is not just bad hygiene. On paper, an unauthorised person read a protected record, and the named person carrying the duty cannot say who. "Authorised" is the word the whole design hangs on. RBAC, ABAC and break-the-glass are three ways of answering it in software: who counts as authorised for this chart, right now.

Where RBAC quietly breaks: the teaching hospital

RBAC works until the org chart stops being simple, and in a Nigerian teaching hospital it stops being simple fast. A house officer rotates through medicine, then surgery, then paediatrics in a single year. A consultant covers her own firm but also takes the night call for three others. A visiting registrar holds an honorary appointment two days a week. Every one of these is a real, defensible access need, and the RBAC answer to each is a new role. "Surgery house officer on the burns rotation covering Saturday call" becomes a role. Then there are forty of them, then a hundred, each a near-duplicate of the last, and nobody can say with confidence what any single role can actually see.

This is the failure that has a name in the literature: role explosion. The model that was meant to make access legible has produced a thicket no auditor can read, and the usual response on the ward makes it worse. Faced with a role that does not quite fit, the path of least resistance is to grant the broader role, or to share a login that already works, and now least privilege is gone in practice while the policy document still claims it. The control did not fail loudly. It rotted quietly while everyone followed the rules.

RBAC asks one question: what is your role. ABAC asks who, which patient, when and from where. The gap between those two questions is where a teaching hospital lives.

ABAC is the answer to role explosion because it stops trying to pre-name every situation. Instead of a role for the burns house officer on Saturday call, you write one rule: allow read where the requester is a clinician, the patient is on a ward the requester is currently assigned to, and the time is within the assignment. The rotation, the night cover, the honorary post all fall out of attributes the hospital already tracks (current posting, on-call roster, care-team membership) rather than out of a hand-built role for each permutation. You trade the simplicity of RBAC for a policy engine you have to feed accurate data, which is a real cost. For a small clinic with stable staff, RBAC is the right answer and ABAC is overkill. For a 600-bed teaching hospital with rotating staff, the cost flips the other way.

Modelling break-the-glass as a designed exception

Whatever model you choose will be too tight at the worst possible moment, because a correct access policy in a hospital must sometimes be wrong. The emergency at 2am is exactly the case the policy was built to deny, and denying it costs a life. So you design the exception in, rather than leaving staff to invent one with a borrowed password.

A break-the-glass that is engineered, not improvised, has four properties. It demands a reason at the point of override, so the consultant types why she is opening a chart she is not assigned to. It is time-boxed, opening access for the encounter and closing it after, rather than handing out a permanent grant that nobody remembers to revoke. It alerts, so a named person knows in near real time that the glass broke. And it logs immutably: who, which patient, when, and the stated reason, written somewhere the user cannot edit. Designed this way, the override is a feature of least privilege rather than a hole in it, because the access is rare, narrow, loud, and accountable after the fact. That is the difference between a control that bends under pressure and one that snaps. It also closes the loop back to the NDPA's "appropriate measures" and the National Health Act's authorisation rule: the emergency reader was authorised by an auditable, deliberate process, not by a shared login nobody can trace.

Choosing, and the plain decision rule

The choice is not RBAC against ABAC against break-the-glass, because break-the-glass sits on top of either of the first two. The real decision is between RBAC and ABAC, and the rule is about as plain as security design gets. If your staff and your access needs are stable and few, start with RBAC, keep the roles to a number a human can recite, and add a properly designed break-the-glass for the emergency case. If you are watching roles multiply past what anyone can audit, that is role explosion announcing itself, and it is the signal to move the rotating, context-heavy decisions to ABAC attributes you already hold. Most Nigerian hospitals are not choosing one religion forever. They run RBAC for the stable majority of staff and reach for ABAC where the org chart refuses to sit still.

Picking the model is the design question. Running the accounts that live inside it, who gets provisioned on day one, whose access is revoked the day they leave, who recertifies the rest, is a separate operational discipline, and we have written it up in Joiner, Mover, Leaver: running the EHR account lifecycle. Design the model first. Then run it.