EHR audit logs: what they record, what research learned, and what AI agents change

The short answer

Picture asking your EHR’s log what an AI tool changed in a chart, and getting back only screens opened and notes signed. EHR audit logs were built to answer who looked at a chart, not what an automated tool meant to do. When AI tools act in the record, the log needs both what was intended and what actually changed.

An EHR audit log, also called an event log, captures and timestamps users’ detailed interactions with the record while they’re logged in: which screen they opened, which note they viewed, which order they signed.² It was originally designed to support access control, to answer “who looked at this chart?”.¹ Researchers have since used it to study how clinicians spend their time, how care teams work together and how workflows unfold.

A 2020 systematic review of 85 such studies found the data powerful and the methods inconsistent: only 22% of studies validated their measures, and only 11% against direct observation.¹ That gap matters more as AI agents start acting in the record. A log of clicks says what happened in the interface. For an agent, you also need what it was asked to do, what decided it could, and what actually changed.

What an audit log captures

The commentary that called audit logs “a new goldmine” for health services research describes them as a by-product of EHR adoption: granular, timestamped user activity that offers insights claims and clinical data can’t.² Typical entries look like this:

The FHIR standard has a resource for the same purpose. AuditEvent is defined as a record of an event made for maintaining a security log, with required elements for the event type, the recording time, the agent and the reporting source.³ ISO 27789 sets a minimum for health record audit trails: identify the user, the subject of care, the function performed and the time.⁴ In the US, HIPAA’s Security Rule requires audit controls that record and examine activity in systems containing electronic health information.⁵

What researchers did with them

The 2020 review by Rule, Chiang and Hribar sorted the 85 studies’ aims into examining EHR use, care team dynamics and clinical workflows, and found six recurring measures:¹

1. Counts of actions the log captured directly, such as “problem list viewed”.
2. Counts of higher-level activities that researchers inferred, such as “chart review”.
3. How long activities took.
4. The order activities happened in.
5. Clusters of activities that go together.
6. Networks of which users work on the same records.

Measures like these let researchers ask questions that no survey answers well, such as how long a task really takes and in what order work happens. The goldmine framing is fair: the commentary argues these data offer insights claims and clinical data can’t.²

The measurement problem

The same review is blunt about the weaknesses. Preprocessing varied from study to study: how to filter out extraneous actions, how to map raw actions onto activities, how to read repeated actions or gaps.¹ Only 19 studies (22%) validated their results, and only 9 (11%) by directly observing clinicians.¹ Most didn’t describe their measures in enough detail to replicate.¹

The root cause is that audit logs record interface events, not intentions. A gap of four minutes might be reading, a phone call, or a walk down the corridor. A “note viewed” event doesn’t say whether the note was read or the window was simply open. Researchers have to infer meaning, and different researchers infer differently.

When the user is an agent

AI agents and integrations increasingly read and write the record through APIs rather than screens. That changes what an audit log can tell you:

The table’s last three rows are where agents differ most. An agent’s intent is written down, in its tool call, which is better than inference from clicks, but only if someone keeps it. Approval is an event that matters and that interface logs weren’t built to hold. And a write that returned success may not have stored what was meant; our FHIR benchmark found that in 11 of 17 synthetic cases.

What to add for agent activity

For each agent action, keep alongside the usual audit entry:

1. The service identity and the person it acted for. ISO 27789’s “user” needs both.⁴
2. The request itself, or a digest of it, so intent isn’t inferred.
3. The decision: the rule or approver that allowed it, or the refusal.
4. The result as stored: the version id the server reported, and a read-back of it.
5. Integrity protection on the log, so the agent’s own credentials can’t edit it.

FHIR gives you two places to put this: AuditEvent for the security log of each event, and Provenance for where each resource version came from. Our AuditEvent vs Provenance post shows both for one agent write, and HIPAA audit controls and AI agents lays out a field list.

A checklist

1. Confirm agents have their own identities, not a shared integration account.
2. Record on whose behalf each agent action ran.
3. Keep the request and the decision, not only the event.
4. Check results after writes and log the check.
5. Protect the log from the actors it records; why logs aren’t evidence explains the difference.
6. Document your measures if you analyse the logs, so others can replicate them.¹

Nothing here is clinical; it’s about records. The audit trail for AI in healthcare entry gives the short version. To see actions recorded and checked on a real database in your browser, try the playground; to grade what an agent can reach on your machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.