Minimum necessary in a permission model

Minimum necessary is easy to say and genuinely hard to build, and the difficulty is not technical. It is that healthcare has a real, unavoidable tension between restricting access and delivering care, and most teams resolve that tension by giving everyone broad access without saying so and relying on policy to constrain behaviour.

That resolution is understandable and it is not compliant, because a policy is not a technical control and the Security Rule's access control standard is about allowing access only to those who have been granted rights [1].

The tension is real, so start by naming it

In a clinical setting, a permission model that is too tight causes harm. The nurse who cannot see the record of the patient in front of them, the covering physician locked out of a chart at two in the morning, the specialist who needs history from another department: each of those is a patient safety problem, and every clinician has a story about a system that blocked their work.

The Security Rule acknowledges this directly by making emergency access procedure Required [1]. The intended design is not "restrict everything." It is scoped access for ordinary work, plus a deliberate, logged path for the cases the scope did not anticipate.

That design is the whole answer, and teams skip it because building the second half is more work than granting broad access. Once the emergency path exists and is properly logged, narrowing ordinary access stops being dangerous, because the failure mode of too-tight scoping is now an inconvenience with a defined remedy rather than a clinical risk.

Why role review finds nothing

The standard approach to minimum necessary is an annual access review that examines role definitions and confirms they look reasonable. They do look reasonable. The definitions were written thoughtfully and nobody has changed them.

The change happens in assignments, and it only goes one way: access grows. Someone joins as a scheduler and gets the scheduling role. They move to billing and get the billing role. Nobody removes scheduling, because removing access has no deadline, no requester, and a real chance of blocking someone's work. Multiply by a few years and a few dozen staff and the effective access in the organisation bears little relationship to the correct model in the code.

The review that finds this computes effective permissions per person and compares them to that person's current function. It produces an uncomfortable list of named individuals with more access than their job requires, which is exactly why it is the version that works and the version that gets avoided.

The harder variant is that effective access is frequently the union of grants across several systems: the clinical application, a reporting tool with its own permissions, a database group, a cloud IAM policy, and a shared credential in a password manager. Each looks defensible alone. Nobody computes the union, and the union is what a person can actually reach.

Write down what each role must not reach

The lasting engineering answer is to write down what each role must not reach, as assertions, and run them on every change.

Positive tests do not protect you here. A test asserting that the billing role can read billing records keeps passing forever and says nothing about the fourteen endpoints added since. The billing role can now reach clinical notes through a new shared component, and every existing test still passes.

The negative assertion is the one that fails when access grows beyond its scope. It is also readable by a compliance reviewer in a way a permission matrix is not: "the scheduling role must not be able to read clinical notes" is a sentence somebody can agree or disagree with, whereas a grid of two hundred permission cells is something everybody approves and nobody checks.

Write these per role, covering the categories of PHI the role should never reach, and make them part of the check suite rather than a document. This is work across many combinations, roles multiplied by data categories multiplied by interfaces, which is precisely the kind of thoroughness that was never affordable before and now takes an afternoon.

Test at the endpoint, not the screen

The most common technical defect behind a minimum necessary failure is authorisation implemented as a rendering decision.

The chart link is not shown to users without the clinical role. The menu item does not appear. And the endpoint behind it answers anyone authenticated who calls it, because the check was in the component that decided what to display. This is not an exotic bug; it is the default outcome when the screen and its authorisation are built in the same afternoon by the same person.

Any test that drives the user interface will pass. The test has to call the endpoint directly, with each role, asserting both the permitted and the forbidden outcomes.

Scoping by relationship, not just by role

The more sophisticated version of minimum necessary in clinical systems is that access should depend on the relationship to the patient, not only on the job title. A nurse should reach the records of patients on their unit rather than every patient in the hospital.

This is harder to build, because it requires the system to know about care relationships, assignments, and coverage, and those change constantly. It is also where the largest reduction in unnecessary access is found, since role-based scoping alone typically leaves every clinician able to reach every patient.

Two practical notes. Relationship-based scoping needs the emergency path more than any other model, because the relationship data will be wrong or missing at exactly the wrong moment. And it makes the audit trail far more useful, because recording the relationship that justified access, as described on audit controls under the Security Rule, turns review from guesswork into a question with an answer.

Service accounts and integrations

The broadest access in most healthcare systems belongs to something that is not a person: the integration credential for a health information exchange, the reporting job that reads everything to build a dashboard, the analytics pipeline, the backup process.

These are provisioned once, generously, because narrowing them would have required knowing exactly what each needed and nobody had time. Then they run for years. Minimum necessary applies to them, and unlike the human version, narrowing them produces no awkward conversations. Compute what each actually touched over a representative period and reduce the grant to match.

If your permission model has been running for a few years and nobody has computed effective access recently, that is where to start. Get in touch and we will run it with you.