Audit Logging for Clinical Systems

Picture an electronic health record system used by a large group of clinicians. Each clinician needs to open the records of the patients in their own care, but nobody should be able to open the records of a colleague's patients simply because they happen to be logged into the same system. Deciding who may see what, and keeping that decision enforced automatically, is the job of access control.

This article follows one concrete implementation in which every clinician received a dedicated software identity that acted on their behalf. As you read, keep one question in mind: when a clinician asks the system for a patient record, what must the system check, and what must it refuse?

In this implementation, the thing being restricted is not only the human clinician but also an agent identity created for that clinician. The agent is the software identity that acts inside the system, and it is the identity the system checks when a request arrives. The clinician's role therefore determines what the agent can reach, and the system evaluates the agent, not the clinician's typing, when deciding whether to allow a request.

Creating the identity is not the same as granting access. The agent's reach was set by scoping it through the EHR's role-based access controls. Scoping is the step where the abstract role becomes a concrete boundary: this clinician's agent can work with this clinician's patient panel and nothing beyond it. The identity exists first; the scope is then attached to it.

An agent identity does not stay in one unchanging state. It moves through a small set of stages that the source describes: it is created at onboarding, it is scoped, it is reviewed on a recurring schedule, and it is eventually revoked when the clinician leaves. Read the diagram below as a map of what can happen to an identity over time, not as a description of any particular software screen.

Follow the stages in order. The identity is created when the clinician is onboarded, and it is then scoped so that its reach matches the clinician's role. While the clinician is employed, the identity is in use. At a recurring interval, the identity is reviewed. The source's standard access-review cadence was ninety days, so an identity that remains in use is checked again on that schedule rather than being trusted indefinitely. In the diagram, the review loops back to the in-use state because a review that finds nothing wrong does not end the identity's life.

Notice what does not end the identity. The review step does not end it; the only event the source ties to ending it is offboarding, when the clinician leaves. Revocation is therefore the terminal state in the diagram, and no other transition leads there.

Creating and scoping an identity protects the system while the clinician is employed. The harder question is what happens when the clinician leaves. The implementation handled this through its offboarding process, which automatically revoked the departing clinician's agent identity. The source reports a specific case: two months after go-live, a clinician left the system, and the identity was auto-revoked within four hours.

The timeline shows that the gap between departure and cut-off is the revocation window. The source states that the customer's security team chose this window deliberately to limit misuse. A departed clinician's identity remains usable during that interval, which is why the window is kept short. Every hour of delay is an hour in which an identity belonging to someone no longer on staff could still act, so the design goal is to make that interval as small as the offboarding process allows.

Scoping and revocation control who may act. A third requirement controls how actions are recorded. The audit log had to connect every agent action to a specific human clinician and to a specific timestamp. A record of activity is useful only if someone can answer which clinician's agent did something and when.

The diagram follows one action from request to record. The agent's action carries the identity of the clinician it belongs to. The audit log stores that action with a timestamp. Because the identity is individual, the log entry points to a person rather than to a generic account. The source states that this traceability depends on giving each clinician their own identity, so the design choice at onboarding is what makes the later record useful.

This example is generated for teaching and is not a case from the source. It applies the source's three requirements in order: the scope limits what the identity can reach, the identity is individual, and the audit log records the action against a specific clinician and timestamp.