HL7 FHIR AuditEvent Resource: IHE BALP Patterns, DICOM ATNA Alignment, Provenance Comparison, and HIPAA 45 CFR § 164.312(b) Compliance

The HL7 FHIR AuditEvent resource is the normative security, privacy, and operational logging resource in Fast Healthcare Interoperability Resources (FHIR R4). Engineered to modernize the healthcare security audit model established by IETF RFC 3881 and DICOM Audit Trail and Node Authentication (ATNA), AuditEvent provides a standardized JSON and XML structure for recording every interaction with electronic Protected Health Information (ePHI)—answering who accessed or manipulated which patient record, what operation was performed, when it occurred, where the request originated and terminated, why (purpose of use), and whether the operation succeeded or failed.

What Is FHIR AuditEvent and How Is It Used in Clinical Research and Healthcare?

In hospital Electronic Health Records (EHRs), Health Information Exchanges (HIEs), and clinical trial eSource repositories, every API call, chart view, query, or administrative authentication event must leave an immutable, machine-queryable security trail. Within the catalog of HL7 FHIR resources, AuditEvent serves four distinct operational functions:

1. ePHI Access Surveillance and Snooping Detection: Logging every read, vread, search-type, and $export interaction against patient charts so hospital privacy officers can detect unauthorized employee access (such as viewing the medical record of a VIP, coworker, or family member without a treatment relationship).
2. HIPAA Accounting of Disclosures (45 CFR § 164.528): Recording external disclosures of ePHI—alongside the OAuth 2.0 / TEFCA / IHE PurposeOfUse code (such as TREAT, HPAYMT, HRESCH [healthcare research], or PUBHLTH)—so covered entities can produce a patient-specific disclosure report upon request.
3. Security Incident Forensics and Intrusion Detection: Capturing failed OAuth 2.0 / SMART on FHIR token validations, HTTP 401 Unauthorized and 403 Forbidden access denials, emergency “Break-the-Glass” privacy overrides, and system configuration changes for ingestion into Security Information and Event Management (SIEM) platforms.
4. Clinical Research eSource and 21 CFR Part 11 Inspection Readiness: Providing an append-only, timestamped log of all RESTful FHIR data pulls (`$populate` / `$extract`) between a hospital EHR and a sponsor’s Electronic Data Capture (EDC) system.

FHIR AuditEvent vs. FHIR Provenance: The Architectural Distinction

Health informatics architects frequently ask why FHIR defines both an AuditEvent resource and a FHIR Provenance resource when both record agents, timestamps, and target resources. In HL7 FHIR R4, the two resources serve fundamentally different audiences, lifecycles, and trigger conditions:

Architectural Dimension	HL7 FHIR AuditEvent	HL7 FHIR Provenance
Primary Purpose	Security, privacy, and operational surveillance: Tracks system activity, access control enforcement, and ePHI disclosures.	Clinical data lineage and epistemic trust: Tracks who authored, verified, transformed, or amended a clinical resource version.
Triggering Operations	Fires on all interactions: Create, Read, Update, Delete, Search, $export, login/logout, and failed attempts.	Fires only when data is created or modified (Create, Update, Patch, clinical sign-off, or AI transformation).
Does a Chart Read/Search Create One?	Yes: Every GET /Patient/123 or GET /Observation?patient=123 generates an AuditEvent.	No: Reading or searching a chart never alters clinical state and never generates a Provenance resource.
Storage & Access Control	Stored in a restricted, append-only Audit Record Repository (ARR) accessible only to security/privacy officers and auditors.	Stored alongside clinical resources on the FHIR server and returned to clinicians via _revinclude=Provenance:target.

Core Schema Elements of the FHIR R4 AuditEvent Resource

The structure of AuditEvent maps directly to the six canonical audit questions defined in IETF RFC 3881 and DICOM PS3.15 Annex A.5:

FHIR R4 Element Path	Cardinality	Value Set / Coding System	Audit Question & Technical Meaning
type	1..1	Coding (DICOM Audit Event ID / HL7 AuditEventType, e.g., rest, 110100 Application Activity, 110114 User Authentication)	What category of event occurred? High-level classification of the audited activity.
subtype	0..*	Coding (FHIR Restful Interaction: read, vread, update, create, delete, search-type)	Which specific interaction was invoked? Pinpoints the exact RESTful verb or operation.
action	0..1	code: C (Create) | R (Read/View/Print) | U (Update) | D (Delete) | E (Execute)	What CRUD+E action took place? Single-character indicator aligned with RFC 3881.
recorded	1..1	instant (ISO 8601 timestamp with timezone offset and millisecond precision)	When was the event recorded? Synchronized via Network Time Protocol (NTP).
outcome	0..1	code: 0 (Success) | 4 (Minor Failure, e.g., 4xx) | 8 (Serious Failure, e.g., 401/403/5xx) | 12 (Major Failure)	Did the operation succeed or fail? Essential for detecting brute-force or unauthorized access attempts.
purposeOfEvent	0..*	CodeableConcept (v3 PurposeOfUse: TREAT, ETREAT [Break-the-Glass], HPAYMT, HOPERAT, HRESCH)	Why was the access requested? Asserted purpose of use from the OAuth 2.0 / SAML token.
agent	1..*	BackboneElement: type, role, who (Practitioner/Patient/Device), requestor (boolean), network (IP/URI)	Who participated? Captures the human user, the calling SMART client app, and the network IP address.
source	1..1	BackboneElement: site, observer (Reference(Device|Organization)), type	Which system generated and reported the audit log? Identifies the reporting FHIR server or gateway.
entity	0..*	BackboneElement: what (Reference(Resource)), type, role (1 Patient, 4 Domain Resource, 24 Query), query (base64)	Which patient and data records were touched? Links the specific Patient and target resources or search query string.

What Standards or Regulatory Requirements Govern FHIR AuditEvent?

1. HIPAA Security Rule (45 CFR § 164.312(b)), ASTM E2147, and ONC Certification

Under the U.S. HIPAA Security Rule technical safeguards, 45 CFR § 164.312(b) (Audit Controls) requires covered entities and business associates to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Furthermore, under the ONC Health IT Certification Program (45 CFR § 170.315(d)(2) Auditable Events and Tamper-Resistance, § 170.315(d)(3) Audit Reports, and § 170.315(d)(10) Auditing Actions on Health Information), certified EHR technology must conform to ASTM E2147-18 (Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems), which mandates logging user ID, patient ID, timestamp, action type, and identification of the accessed data elements—all of which map directly to FHIR AuditEvent elements.

2. IHE BALP (Basic Audit Log Patterns) Implementation Guide

While the base HL7 FHIR R4 specification defines the AuditEvent resource structure, different vendors could populate agent and entity slices inconsistently without a profiling standard. To guarantee cross-vendor interoperability within Integrating the Healthcare Enterprise (IHE) architectures, the IHE IT Infrastructure Basic Audit Log Patterns (BALP v1.1.x) Implementation Guide defines normative FHIR StructureDefinitions for RESTful auditing:

• Basic Audit Patterns for RESTful Operations: Profiles for BasicAuditCreate, BasicAuditRead, BasicAuditUpdate, BasicAuditDelete, and BasicAuditQuery.
• Patient-Specific RESTful Audit Profiles (Privacy Auditing): Whenever a RESTful operation involves a patient’s clinical data, BALP requires an explicit AuditEvent.entity slice with entity.type = #1 (Person), entity.role = #1 (Patient), and entity.what = Reference(Patient/...). This guarantees that a privacy officer can execute a single query—GET /AuditEvent?patient=Patient/123—to retrieve every create, read, update, delete, or search that touched that patient’s data, satisfying HIPAA Breach Notification Rule forensic investigations and Accounting of Disclosures.
• IUA / OAuth 2.0 Access Token Auditing: BALP specifies how to log the OAuth 2.0 authorization server, client application ID, and user identity claims (`oAuth2` token slice in `AuditEvent.agent`) when a SMART on FHIR or IHE Internet User Authorization (IUA) client accesses a FHIR endpoint.

Worked JSON Example: IHE BALP Patient-Specific RESTful Read AuditEvent

The following JSON example shows an IHE BALP-conformant FHIR R4 AuditEvent generated when a physician (`Practitioner/dr-smith`) uses a SMART on FHIR application (`Device/smart-cds-app` from IP `10.24.18.92`) to read an `Observation` resource (`Observation/troponin-991`) belonging to `Patient/pat-402`:

{
  "resourceType": "AuditEvent",
  "id": "balp-patient-read-example",
  "meta": {
    "profile": [
      "https://profiles.ihe.net/ITI/BALP/StructureDefinition/IHE.BasicAudit.PatientRead"
    ]
  },
  "type": {
    "system": "http://terminology.hl7.org/CodeSystem/audit-event-type",
    "code": "rest",
    "display": "Restful Operation"
  },
  "subtype": [
    {
      "system": "http://hl7.org/fhir/restful-interaction",
      "code": "read",
      "display": "read"
    }
  ],
  "action": "R",
  "recorded": "2025-05-14T14:22:09.412Z",
  "outcome": "0",
  "purposeOfEvent": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
          "code": "TREAT",
          "display": "treatment"
        }
      ]
    }
  ],
  "agent": [
    {
      "type": {
        "coding": [
          {
            "system": "http://dicom.nema.org/resources/ontology/DCM",
            "code": "110153",
            "display": "Source Role ID"
          }
        ]
      },
      "who": {
        "reference": "Device/smart-cds-app"
      },
      "requestor": false,
      "network": {
        "address": "10.24.18.92",
        "type": "2"
      }
    },
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
            "code": "IRCP",
            "display": "information recipient"
          }
        ]
      },
      "who": {
        "reference": "Practitioner/dr-smith",
        "display": "Dr. Elena Smith, MD"
      },
      "requestor": true
    }
  ],
  "source": {
    "site": "Hospital Enterprise FHIR R4 Server",
    "observer": {
      "reference": "Device/fhir-server-prod-01"
    },
    "type": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/security-source-type",
        "code": "4",
        "display": "Application Server"
      }
    ]
  },
  "entity": [
    {
      "what": {
        "reference": "Patient/pat-402"
      },
      "type": {
        "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type",
        "code": "1",
        "display": "Person"
      },
      "role": {
        "system": "http://terminology.hl7.org/CodeSystem/object-role",
        "code": "1",
        "display": "Patient"
      }
    },
    {
      "what": {
        "reference": "Observation/troponin-991/_history/1"
      },
      "type": {
        "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type",
        "code": "2",
        "display": "System Object"
      },
      "role": {
        "system": "http://terminology.hl7.org/CodeSystem/object-role",
        "code": "4",
        "display": "Domain Resource"
      }
    }
  ]
}

Note on Search Queries and Base64 Encoding in AuditEvent.entity.query

When auditing a FHIR search-type operation (such as GET /Observation?patient=pat-402&category=laboratory), the IHE BALP BasicAuditQuery profile records the raw HTTP query string inside an AuditEvent.entity slice with entity.role = #24 (Query). Because FHIR defines AuditEvent.entity.query with data type base64Binary (inherited from DICOM ATNA to safely encapsulate arbitrary query syntax or SQL/CQL expressions without breaking XML/JSON escaping), the FHIR server Base64-encodes the request URL and HTTP query parameters before storing the AuditEvent.

Frequently Asked Questions

What is FHIR AuditEvent and how is it used in clinical research and healthcare?

In HL7 FHIR R4, AuditEvent is the normative infrastructure and security resource used to record immutable security, privacy, and operational event logs across health IT systems. It captures “who did what, to which resource, when, from what network node, under what authorization token, and with what outcome”—including data reads, searches, exports, creations, modifications, deletions, user logins, and Emergency “Break-the-Glass” overrides.

What standards or regulatory requirements govern FHIR AuditEvent?

FHIR AuditEvent is governed by the HL7 FHIR R4 specification, the Integrating the Healthcare Enterprise (IHE) Basic Audit Log Patterns (BALP v1.1.x) Implementation Guide, DICOM PS3.15 Annex A.5 (Audit Trail and Node Authentication [ATNA]), IETF RFC 3881, and ASTM E2147. Regulatorily, it is the primary FHIR mechanism used to satisfy the HIPAA Security Rule Audit Controls standard (45 CFR § 164.312(b)), the HIPAA Privacy Rule Accounting of Disclosures requirement (45 CFR § 164.528), ONC Health IT certification criteria (45 CFR § 170.315(d)(2), (d)(3), and (d)(10)), and FDA 21 CFR Part 11 audit trail requirements.

How does FHIR AuditEvent integrate with EHR and health informatics workflows?

Whenever an EHR, SMART on FHIR application, Health Information Exchange (HIE), or clinical research data repository executes a RESTful FHIR interaction (such as GET /Observation?patient=123 or POST /DocumentReference), the FHIR server or API gateway automatically generates an AuditEvent resource conforming to an IHE BALP profile. These AuditEvent records are stored in an append-only Audit Record Repository (ARR) and queried by privacy officers using FHIR RESTful search parameters (such as patient, agent, date, action, and outcome) or streamed to enterprise SIEM platforms.

What is the difference between FHIR AuditEvent and FHIR Provenance?

FHIR Provenance is a clinical record lineage resource created only when a resource is authored, updated, or transformed—answering the clinical question of who authored or verified a piece of medical data and why it can be trusted. FHIR AuditEvent is a security and privacy surveillance log created for every system interaction, including read-only views (GET), searches, exports ($export), failed authentication attempts, and permission denials that never modify clinical data and therefore never generate a Provenance resource.