Audit trail for AI in healthcare

What health standards already ask an audit trail to hold

Audit trails in health records are not new. ISO 27789:2021 is the second edition of the ISO standard on audit trails for electronic health records. It says each audit record should at least name the user, the patient, the action and the date and time.¹ India’s EHR Standards say every action on health information, including viewing, should be recorded. They point to ISO 27789 for audit trails, and separately ask for SHA-256 or stronger hashing to protect data.² The NABH Digital Health Standards include an element for a digital system that “captures the audit trails of each transaction”.³ In the US, the HIPAA Security Rule asks for audit controls that record and examine activity in systems that hold electronic protected health information (ePHI).⁴

Those rules were written with people in mind: a nurse opens a chart, a coder edits a claim. When the actor is an AI agent, the same questions need a few more answers.

What changes when the actor is an AI agent

• Two actors, not one. An agent acts for someone: a clinician, a coder, a patient. The record has to name the agent, and the software key it used, and the person it acted for. Otherwise nobody can say later whose decision it was.
• The agent’s summary isn’t the record. Agents report what they did in their own words. A pilot published in 2026 reviewed 356 notes drafted by an AI scribe that listens to the visit. It found omissions in 18% and made-up content in 11.5%, and 5.3% of notes held an error rated as a serious or immediate risk.⁵ That study is about clinical content, which a person has to review. The same caution applies to an agent’s report of its own writes.
• Writes, not just suggestions. Epic says its AI Charting drafts the clinician’s note and “queues up orders”.⁶ Once agents put entries into orders, notes and claims, the trail needs to show who signed off before each one took effect.
• What was saved. After a problem, the useful question is what the system holds now. A trail that records only the agent’s request can’t answer it. A trail that also records a read-back, or the database’s own change log, can.

Formats: AuditEvent, BALP and Provenance

FHIR has two resources for this. AuditEvent is “a record of an event made for purposes of maintaining a security log”.⁷ Provenance describes who and what took part in making a resource, with roles such as author, verifier and assembler.¹² IHE’s Basic Audit Log Patterns (BALP) 1.1.4 set out how to use AuditEvent for create, read, update, delete and search, each with a version for a single patient.⁸ HL7’s AI Transparency on FHIR guide went to its first ballot in January 2026 and isn’t published yet. It adds an AI Provenance profile for marking data an AI system influenced.⁹

Six things to record for each agent action

1. Who acted and for whom: the agent, its key, and the person it acted for.
2. What it asked for: the tool, the kind of record and its id, and a fingerprint of the request.
3. Which rule decided: allowed, refused or held, and why.
4. Who approved: the named people, when, and what they saw.
5. What the system saved: the check of the record after the write, and whether it matched.
6. A seal: a signature and a link to the record before it, so a changed or missing entry shows.

What an audit trail can’t do

An audit trail records what passed through it. It doesn’t judge whether a dose, a code or a diagnosis was right. That stays with clinicians. It doesn’t see actions taken by other routes into the same system. And it should not become one more copy of patient data. Record ids and fingerprints, and keep any full requests for the shortest time that works (see PHI and health data).