FHIR AuditEvent: an audit trail that survives review

FHIR AuditEvent is the resource that records security-relevant activity on a FHIR surface: who accessed what, when, from where, with what outcome, and under which authority. It is the FHIR-native building block for the access trail that HIPAA audit controls, info-blocking reviews, and partner security assessments all end up examining.

Most teams meet AuditEvent's requirements backwards: an external review finds that the trail cannot answer basic questions, and the gaps turn out to be architectural, not cosmetic. That was the state of the platform we were brought into before building the FHIR interoperability layer: logs leaked PHI across three subsystems, and reads were not scoped to the consent that authorized them, gaps an info-blocking review surfaced and the team could not close incrementally. The rebuilt audit layer passed the next external review without remediation. The difference was treating the trail as a designed system rather than a logging afterthought.

What AuditEvent records

An AuditEvent instance captures a security event in structured form: the type and subtype of action (read, create, update, query, export), the outcome, the timestamp, the agents involved (which user, which app, which system, from which network address), the source that reported it, and the entities touched, typically references to the resources that were read or written.

Structure is the point. A grep through application logs can eventually answer "who read this record," given luck and log discipline. An AuditEvent store answers it as a query, because actor, action, entity, and time are fields, not substrings. The same structure makes the trail exchangeable: a partner system or a review tool can consume AuditEvents without learning your log format.

Three practical rules keep the resource useful. Record both directions: writes are obvious, but access reviews care mostly about reads, including searches that returned nothing. Record failures: denied requests are security signal, often the most important kind. And record system actors honestly: batch jobs and background services touch more PHI than any human, and a trail that only covers interactive users is a partial trail.

AuditEvent vs Provenance

FHIR has two resources that sound alike, and conflating them produces trails that satisfy neither purpose. AuditEvent records access: who touched a resource. Provenance records origin: where a resource came from and what transformed it. An Observation imported from a partner EHR should carry Provenance saying so; every read of that Observation afterwards should emit an AuditEvent.

The two answer different reviewers. A data-quality investigation walks Provenance to find out why a value is what it is. A security review walks AuditEvents to find out who saw it. A mature platform emits both, but if you are sequencing work, AuditEvent comes first: review findings almost always concern the access side, and Provenance without an access trail helps nobody under audit.

Linking access to Consent

The requirement that separates a compliant trail from a complete one: every access should trace to the authority that permitted it. On a FHIR surface that authority is representable as a Consent resource, and the AuditEvent for a read can reference the Consent under which the read was allowed.

This linkage is what makes info-blocking questions answerable. "Show me every access to this patient's record and the basis for each" becomes a join, not an investigation. It also changes engineering behavior upstream: if emitting an audit event requires naming the authorizing consent, then authorization logic has to actually resolve one, which surfaces the requests that were running on assumption rather than authority. On our platform that property, every read and write scoped to its Consent, was the specific thing the external review verified.

Keeping PHI out of the trail

The audit trail has a paradox: it must prove access to sensitive data without becoming a copy of it. A trail that quotes names, diagnoses, or document contents is itself a PHI store, with all the retention, access-control, and breach-surface consequences, and it usually has broader internal visibility than the data it describes.

The resolution is references, not contents. AuditEvent entities point at resources by opaque ID; request correlation uses generated request IDs; actor identity is a user or client identifier, not a patient detail. Enforce it mechanically: a redaction filter at the logging layer, in our build a filter at the log enricher itself, means PHI cannot reach a log line even when a developer forgets. Policy that depends on nobody ever forgetting is not policy.

The same principle extends beyond the FHIR surface. File delivery, report generation, document pipelines: every subsystem that touches PHI needs the same reference-only discipline in its logs. Our HIPAA audited file proxy applies it to downloads, one audit record per read, per expiry, per token use, and our automated reporting system applies it to generated documents, recording who generated what from which source query.

Tamper evidence and replay

An audit trail that can be silently edited proves nothing. The fix is cheap and structural: hash-link the events, each record carrying a hash of its predecessor, so any modification or deletion breaks the chain visibly, and store the chain in write-once storage. Tampering then requires rewriting everything after the edit, in storage designed to refuse exactly that.

The step most teams skip is exercising the chain. A trail you never replay is a trail you discover is broken during an audit. We wired chain replay into CI as a regression check, every release proves the audit history still verifies end to end, which converts audit posture from an annual assertion into a continuously tested property. HIPAA posture that is not tested bit-rots like any other untested code path.

None of this is exotic engineering. It is a handful of decisions, structured events, both directions, consent linkage, reference-only content, hash-linked storage, replay in CI, made early and enforced mechanically. Made late, each one becomes a migration project under review pressure. The standards context around this trail, TEFCA exchange purposes and USCDI's expanding data surface, is covered in our TEFCA vs FHIR and USCDI and FHIR breakdowns; the engineering practice that builds them is on the healthcare integration page.