How would you know if a clinician had opened the record of a patient they were not caring for?

Why authorisation cannot answer this on its own

A clinical system has to let a clinician open a record they have no prior relationship to, because that is how emergency care, cover arrangements and referrals work. A patient arrives unconscious, an on-call doctor has never met them, and any design that requires a pre-existing link would kill people. So role-based access control gives a doctor the ability to read patient records, and the question of which patients is left open by construction.

That is the structural point to make first, and it reframes the question. You are not being asked to build a permission that prevents this. You are being asked how an organisation retains accountability over access it deliberately allows, which is a different design with three parts: a recorded reason for legitimate access, a friction-bearing path for access without one, and detection over what actually happened.

The principle underneath is minimum necessary in HIPAA's language, and in UK practice the requirement that access rests on a legitimate relationship with the patient, articulated through the Caldicott principles. Under the GDPR, health data is special category data, which raises both the lawful-basis bar and the consequences of getting it wrong. None of those frameworks say "block it"; they say know who saw what, and why.

Making the relationship a first-class object

The workable version of "should this person be looking" is a relationship the system already knows about, derived rather than declared: the patient is on the ward this clinician is rostered to, is on their clinic list today, has an open referral to their team, has been transferred from their care, or is the subject of an order or result they placed. Each of those is an event the system already records, and together they cover the overwhelming majority of legitimate access.

Deriving relationships this way has a cost worth naming, because it is where a naive design fails clinically. Cover arrangements, cross-site working, bank and agency staff, multidisciplinary meetings and specialties that read the whole hospital by nature — radiology, laboratory, coding, infection control, pharmacy — all produce legitimate access with no roster link. If you turn the relationship into a hard gate you will generate a stream of blocked clinicians in a hurry, and the reliable result is shared logins, which is strictly worse than the problem you set out to solve.

So the relationship should be recorded and used to classify access rather than to permit it. Access with a relationship is normal. Access without one is not forbidden, it is exceptional, and exceptional access needs a route.

Break-glass has to cost something and be seen

Break-glass access is the route: the clinician is told plainly that this patient is not linked to them, is asked to select or type a reason, is warned that the access will be reviewed, and is then let through. The design details are what separate a real control from an interstitial nobody reads.

The reason has to be structured enough to triage and free enough to be truthful, which usually means a short list plus a text box. The warning must be unambiguous that a named person will look, because the deterrent is social rather than technical. The access should be scoped and time-boxed rather than opening the whole estate indefinitely. And the event must be routed to a queue that is genuinely worked, because break-glass with no review is a click-through that trains people to click. Emergency departments and intensive care will use it constantly and legitimately; a ward clerk using it once is a different signal entirely, and the queue has to be tuned to make that visible rather than drowning in the former.

Detection over reads, not writes

Answering the interviewer's question after the fact requires something many systems do badly: the audit log must record reads. Writes are usually captured well because the clinical record demands attribution, but a person who looks and does not touch leaves no trace in a write-only audit trail, and looking is the whole offence here. The read event needs the identity, the patient, the timestamp, the workstation or location, the part of the record opened, and the relationship or break-glass reason that applied at the time. That last field is what makes review possible without a re-investigation of each case.

Detection then splits into two complementary halves, and answering with only one is the most common gap.

The specific tests are cheap, well understood and catch a large share of real cases: a member of staff accessing their own record, or a record sharing their surname, address or registered contact details; access to a colleague's record; access to a record flagged as sensitive or high-profile; access to a patient at a site the user has never worked at; access to a discharged patient long after any care episode ended. These are rules, they are explainable in an investigation, and each can be tuned by department.

The behavioural half is baselines. Compare a user against their own history and against their peer group on the volume of distinct patients opened, the proportion of accesses without a relationship, the time of day, and the ratio of reads to any corresponding clinical action. A nurse who normally opens twenty records a shift and opens four hundred is worth a question regardless of whether any single access broke a rule. Behavioural detection produces false positives constantly, which is exactly why it feeds a human queue and never an automatic sanction.

Reading in bulk looks the same as a legitimate query

In early 2015 the US health insurer Anthem disclosed that attackers using stolen credentials had reached an internal data store and exfiltrated member records covering tens of millions of people. The credentials were legitimate, so nothing at the perimeter was breached in the way an architecture diagram would show it.

That case belongs in this answer because it collapses the distinction between the curious insider and the external attacker: both arrive as an authenticated identity doing something the authorisation model allows. It also shifts the emphasis of the design. Per-record detection tuned to a nurse opening one extra chart will not see a service account or an analyst reading a million rows, because those paths often bypass the application audit trail entirely. Anything that can read at volume — reporting databases, extracts, integration accounts, direct database access — needs its own accounting, with a stated expected volume, and an alert when the volume is exceeded rather than when a rule is broken.

What happens after a detection

The technical answer is not finished until you say who acts. A confirmed inappropriate access is a personnel matter and, depending on jurisdiction and scale, a notifiable one, which means the process needs a named owner, an evidence standard, a route to information governance and human resources, and a decision about telling the patient. That is also why the audit trail has to be tamper-evident and retained long enough to be usable, and why the reviewers' own access to it is itself audited.

Access you have to allow is access you have to account for. If reads are not logged with the relationship that justified them, and nobody's job description includes reading the exception queue, then the honest answer to how you would know is that you would not.