Clinic Permissions and the Break-Glass Account

When people talk about information security in a clinic, the imagination goes to an outside breach. In practice, most of the incidents clinics encounter are far simpler: an employee who viewed a record they should not have viewed. A neighbor, a relative, a familiar person. There is no sophisticated malicious intent here — there is an overly broad permission and human curiosity.

Permissions are therefore not a technical matter but a management tool. They determine what can be done at all, and so they determine in advance which incidents can occur.

Start from roles, not from people

The common mistake is to define permissions for each employee separately. That is convenient at first and unmaintainable after a year: no one remembers why someone has a certain access, and no one dares to reduce it. The right approach is to define a small set of roles, decide for each role what is allowed, and assign people to roles.

A typical clinic manages with six roles:

Role	What yes	What usually not
System administrator	Settings, users, permissions, audit log	Not necessarily viewing clinical documentation
Prescribing physician or clinician	A full record, visits, prescriptions, orders and results	Changing system settings
Therapist or nurse	Clinical documentation, vital signs, carrying out orders	Prescriptions, financial data
Front-desk staff	Calendar, patient details, reception, payment	Full clinical documentation, lab results
Bookkeeping	Billing, payments, financial reports	Detailed clinical content
Break-glass account	Broad temporary access, subject to justification and documentation	Routine use

The distinction many miss

A permission is not a yes-or-no question, but a question of the type of action. There is a difference between knowing that a record exists, seeing its content, creating a new one, editing and deleting. Front-desk staff need to know that a patient has a visit today and who the clinician is, without reading the clinical summary. Bookkeeping needs to know that a treatment justifying a charge was performed, without reading the details.

A system that allows only full access or full blocking will push you toward full access, because otherwise it is impossible to work. This is a good check when evaluating a system: ask to see the permissions screen and count how many types of actions can be defined.

What a break-glass account is

The term comes from the emergency cabinet whose glass you smash to reach what is inside: possible, but it leaves a mark that cannot be hidden. In the context of medical information systems, this is a mechanism that allows exceptional access in an emergency, at the price of full documentation.

Why it is necessary: because an overly strict permissions policy breaks at the moment of truth. An on-call clinician who needs to see the record of a patient who is not theirs, at an hour when there is no one to approve it, will find a way: they will ask a colleague for a password, use a shared account, work around it. All of these are worse than an orderly mechanism.

A proper mechanism looks like this:

1. The user requests exceptional access and is required to justify it in free text. There is no default and no convenient list to choose from.
2. Access is granted immediately — otherwise the mechanism is worthless in an emergency — and is time-limited.
3. The event is clearly logged, and appears in a separate list rather than being swallowed in the general log.
4. Someone defined reviews the list regularly, for example once a week, and approves or inquires.

The rule: deterrence is better than blocking, when blocking might harm the treatment. A person who knows their access will appear in a list that someone reads behaves differently from a person who assumes no one is checking.

An audit log you can actually use

An audit log exists in almost every system. The question is whether you can ask it questions. Three questions worth verifying you can answer within minutes: who viewed a particular patient’s record over the past six months; what a particular user viewed on a particular day; and which records were edited after they were signed.

It is also worth checking two technical things. First, that the log includes viewing and not only changes — a leak is a viewing. Second, that the log lines are protected against alteration, for example by an integrity signature on each line, so that even someone with access to the database cannot quietly erase traces.

Sensitive cases within the clinic

Every clinic occasionally treats people the staff know: an employee, an employee’s family member, a person known in the community. These are exactly the records that attract curiosity. There are two accepted ways to handle this. The first is flagging the record as sensitive, so that every opening of it requires a justification and appears in a separate report. The second, when it concerns a clinic employee themselves, is to restrict the treatment to one defined clinician.

What matters is not which mechanism is chosen but that it is decided in advance and in writing. A clinic that decides in real time, after something has already happened, makes a worse decision and struggles to explain it.

A fifteen-minute review routine

Information security in a small clinic does not fail for lack of technology but for lack of routine. Four checks that can be done once a month, in a quarter-hour sitting:

1. The list of active users — are they all still working here.
2. The list of exceptional-access uses from the past month — is each one explained.
3. A report of views on records flagged as sensitive.
4. The list of permissions that changed this month, and who approved them.

A routine like this is worth more than any long policy document, because it creates an expectation that someone is looking. And that, in the end, is what changes behavior.

Ongoing maintenance: four actions

• Revoking access on the day of departure. It sounds obvious, and it is the most common failure. It is worth tying it to the offboarding process.
• Reviewing permissions twice a year. A list of all users and their roles, on a single page. Any line that is surprising — investigate.
• No shared accounts. A general reception account renders the entire audit log worthless, because it is impossible to know who did what.
• Temporary permissions that really expire. Access granted to a stand-in for a month should end on its own, not linger.

And what about the administrator

A question that always comes up: is the system administrator allowed to see everything. The accepted answer is to separate technical administration from clinical content. Whoever manages users and settings does not have to read medical records, and their access too should be logged. In a small clinic where the same person fills both roles, at least have two separate accounts — one for routine work and one for administrative actions. This separation costs almost nothing, and completely changes the ability to explain, after the fact, what happened.

Back to the blog