Who can see what: identity and access before anything else

Retrofitting access control does not work

The reason is structural rather than a matter of effort. A system built without access control has queries, screens and reports that assume they can see everything, and the assumption is distributed everywhere rather than concentrated somewhere.

Adding restrictions later means finding every one of those assumptions. You will not find all of them, and the ones you miss are silent nobody gets an error, they just see something they should not.

So this gets settled while the data model is still soft, which in practice means before most of the features exist.

Roles are necessary and not sufficient

Role-based access answers 'what kind of person is this', which is genuinely most of the problem. A pharmacist and a ward clerk should not see the same things, and encoding that once is far better than encoding it per screen.

But roles alone cannot express the constraint that actually governs clinical access: relationship. A nurse should see the patients on their ward this shift, not every patient in the hospital who happens to be under the same role. The question is not only who you are but what your connection to this record is right now.

So the model carries both. Role establishes the ceiling; context establishes what is legitimately reachable within it.

Break-glass, done honestly

There are real emergencies where the correct answer is that a clinician gets access immediately and the paperwork happens afterwards. A system that cannot express this will be worked around, usually by shared logins, which is far worse than the thing it was trying to prevent.

So break-glass exists, it is one step, and it is not hidden. What it is not is silent: it is recorded prominently, reviewed as a matter of routine rather than only after an incident, and the person using it knows both of those things at the moment they use it.

That combination easy to invoke, impossible to invoke quietly is what keeps it rare without making it unusable.

Consent and access are different questions

They get conflated constantly. Access is whether this member of staff, in this context, may see this record. Consent is what the patient has agreed may be shared, with whom, for what purpose, and for how long.

A system can satisfy one and violate the other. Someone can be entirely authorised in role terms and still be outside the scope of what the patient agreed to. Modelling them separately is what makes it possible to answer both questions precisely rather than approximately.

Joiners, movers and leavers

Most access control failures in practice are not clever attacks. They are people who changed jobs six months ago and kept everything they had before, accumulating permissions the way a coat accumulates pockets.

The movers case is the one that is quietly worst leavers at least trigger a process. So access is bound to current role and current assignment rather than granted permanently, which means it lapses by default instead of persisting by default.

The audit trail is part of the control

Every access decision is recorded, including the ones that were allowed. A log of denials tells you about attackers; a log of grants tells you about everything else, and 'everything else' is where the real questions come from.

When a hospital needs to answer who looked at a record and under what authority, that has to be a lookup rather than an investigation. Designing for that question from the start is considerably easier than reconstructing it later from three different logs.