What should an audit record for an AI action contain? A field-by-field list

The short answer

An audit record for an AI agent’s action should contain the four basics every health audit record needs, who, whose record, what and when, plus seven more: the agent’s identity and version, the person or service it acted for, the rule decision before the action, who approved it if anyone did, what the agent said it did, what the system of record shows afterwards, and the resource versions before and after. Add a signature or hash chain so changes to the record can be detected. Without the claim-versus-observed pair, a record tells you what the agent reported, not what happened.

The baseline standards already set

ISO 27789:2021, the audit trail standard for electronic health records, says each audit record should at minimum identify the user, the subject of care, the function performed and the date and time.¹ India’s EHR Standards from NRCeS list ISO 27789 as the advisory standard, ask that all actions on health information be recorded, “including viewing”³, and require date, time, record and user identification, with alterations to records and audit logs detected.³

In the US, HIPAA’s Security Rule requires audit controls: mechanisms that record and examine activity in systems holding ePHI.⁶ IHE’s Basic Audit Log Patterns (BALP) 1.1.4 profiles FHIR AuditEvent for create, read, update, delete and query, each with a patient-specific variant.²

None of these were written with AI agents in mind. They’re still the floor.

What changes when the actor is an AI agent

Four things break the “user did X” model:

1. The actor is software acting for someone. “User” now has two parts: the agent and the person or service it acted on behalf of.
2. Rules decide before the action. A policy may allow, hold or refuse the call. That decision is part of what happened.
3. Approval is a separate event. When a person approves a held write, that’s a second actor with a different role.
4. The agent’s report can be wrong. An agent says “updated the record”. The server may have stored something else, or nothing. The record needs both the claim and an independent observation.

The field list

Fields 1 to 4 meet the baseline. Fields 5 to 8 describe the decision chain. Fields 9 to 12 separate what the agent said from what happened. Field 13 lets someone check the record wasn’t altered.

A worked example

An agent proposes correcting a lab value. The rule holds it; a nurse approves; the agent writes; a read-back shows the server stored the value with a unit dropped.

Code Data in JSON, the format software uses to pass records and settings.

{
  "time": "2026-10-27T10:44:31+05:30",
  "subject": "Patient/p-12",
  "function": "update Observation/obs-17",
  "on_behalf_of": "Practitioner/dr-rao",
  "agent": { "id": "lab-agent", "model": "model-x 2026-09" },
  "decision": { "result": "held", "rule": "lab-correction v3" },
  "approver": { "who": "Practitioner/nurse-iyer", "at": "10:44:02" },
  "claimed": "value 7.2 mmol/L",
  "observed": "value 7.2, unit missing, version 5",
  "versions": { "before": "4", "after": "5" },
  "outcome": "mismatch",
  "prev_hash": "…", "signature": "…"
}

The agent’s own log would say “success”. This record says what a reviewer needs: approved, written, and stored differently from what was approved.

Where the fields live in FHIR

FHIR R4 splits the job. AuditEvent is a security log entry with type, recorded time, agents (each flagged as requestor or not) and the reporting source; servers that support it generally don’t accept updates or deletes to it.⁴ Provenance tracks the activity that created, revised or signed a specific version of a resource, with agents that each have a type, role, who and onBehalfOf, and an optional signature.⁵

So fields 1 to 6 sit naturally in AuditEvent, the decision chain and versions in Provenance, and the claim-versus-observed pair needs an extension or an envelope, because neither resource has a slot for “what the agent said happened”. Our open draft, AAP-H, is FHIR R4 Provenance and AuditEvent profiles plus a JSON envelope that holds the agent, the rule decision, the approver, the claim and what the system of record shows afterwards.⁹ More on the split in AuditEvent vs Provenance.

Retention and tamper evidence

How long to keep records depends on the rule that applies. HIPAA requires its required documentation to be kept six years from creation or from when it was last in effect, whichever is later.⁷ India’s DPDP Rules ask data fiduciaries to keep the logs they list for one year.⁸ Hospital and state rules often ask for longer; set retention per jurisdiction with your legal team.

For tamper evidence, a database row anyone with admin rights can edit isn’t enough. Sign each record and chain it to the previous one. In AAP-H each record is signed and chained so a hospital, payer or auditor can check it offline with the issuer’s public keys.⁹ A valid record shows the issuer wrote those values and nothing covered by the signature changed since; it doesn’t show the AI was right, or that the issuer saw every action.⁹

Questions people ask

Is a FHIR AuditEvent enough for AI actions?

It covers the security-log basics. It has no place for the rule decision or for the difference between what the agent claimed and what was stored, so add Provenance and an extension or envelope.

Should we log reads by AI agents?

India’s EHR Standards ask for all actions including viewing to be recorded³, and BALP profiles reads and queries.² Agents read far more than people, so plan storage for it.

Who should hold the signing keys?

The organisation running the system, not the AI vendor alone, and with the public keys shared with auditors.

The spec page has full examples, and the FHIR write integrity study shows why the observed-result field matters. Hospitals can start from our healthcare overview. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.