Use AuditEvent to record that an event happened, such as a login, a read or a policy change. Use Provenance to record how a specific version of a resource was created, revised or signed. They overlap, and many systems write both, but AuditEvent is for accountability and Provenance is for origin.
What AuditEvent is for
The FHIR R5 AuditEvent resource records an event relevant to operations, privacy, security, maintenance and performance. It is based on IHE ATNA audit record definitions. It captures:
- Who: the agent, which may be a person, organization, software or device.
- What: the entities used, created or updated.
- When, where and why: time, location and purpose or authorization.
Security relevant events include software start and shutdown, login and logout, access control decisions, configuration changes, software installation, policy rule changes and data manipulation. They are not limited to RESTful calls.
Key fields include category and code, action, severity, when it occurred and was recorded, the outcome, the agents with a required who, a required source with an observer, and entities with roles and security labels.
What Provenance is for
Provenance records the activity that created, revised, deleted or signed a version of a resource, with the entities and agents involved. It helps assess quality, reliability and trustworthiness. It has a target, which is usually version specific, an agent list, optional entity inputs and an optional signature. The signer should match a Provenance agent.
One Provenance record covers one activity, so a target can have several.
Who writes them
The Provenance resource is prepared by the application that initiates a create or update. AuditEvent is often, but not always, created by the application handling a create, read, update, delete or execute event, and it is generated as events occur.
Handling duplicates and tampering
The AuditEvent page makes two useful points. Multiple actors may record events about the same activity, so duplicates are expected, and mismatches between records can indicate a security or privacy problem. Servers also typically do not accept update or delete operations on audit events, to preserve integrity.
Treat that as a design rule: make audit storage append only, and give the people who run the clinical system no ability to edit it.
Quick selection guide
- A clinician opened a chart: AuditEvent.
- A lab result was corrected and the old version superseded: Provenance, plus an AuditEvent for the update call.
- A document was digitally signed: Provenance with a signature.
- An administrator changed an access policy: AuditEvent.
Remember the FHIR security page says HTTP logs, even URL only logs, should be treated as sensitive as the resources. Audit records that quote search parameters can leak identifiers in the same way.
For the wider checklist, see FHIR is not a security protocol.
Quick check
Do I need both resources?
Not always. If you only need an accountability trail, AuditEvent is enough. Add Provenance when you need to show how a particular version of a resource was produced or signed.
Sources
Last reviewed: 19 October 2026.
