HL7 Electronic Health Record System Functional Model, Release 2.1.1
2.1.1 - International flag

HL7 Electronic Health Record System Functional Model, Release 2.1.1, published by HL7 International / Electronic Health Records. This guide is not an authorized publication; it is the continuous build for version 2.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/mvdzel/ehrsfm-fhir-r5/ and changes regularly. See the Directory of published versions

Requirements: TI.2.1 Audit Triggers (Function)

Official URL: http://hl7.org/ehrs/uv/ehrsfmr2/Requirements/EHRSFMR2-TI.2.1 Version: 2.1.1
Standards status: Normative Active as of 2025-10-31 Computable Name: TI_2_1_Audit_Triggers

Manage Audit Triggers

Statement N:

Manage Audit Triggers

Description I:

EHR Systems have built in audit triggers to capture key events in real-time. Audit triggers signal key:

  • Record management and lifecycle events;
  • Security events related to system and data safeguards, both routine and exceptional;
  • System events related to performance and operations, both routine and exceptional.
  • Clinical events with special log requirements.
Criteria N:
TI.2.1#01
 dependent
SHALL

The system SHALL audit key events, as specified in function TI.2.1 (Audit Triggers) and child functions, according to scope of practice, organizational policy, and/or jurisdictional law.
TI.2.1#02
 dependent
SHALL

The system SHALL capture key Audit Metadata at each Audit Trigger, as specified in TI.2.1 (Audit Triggers) and child functions, according to scope of practice, organizational policy, and/or jurisdictional law.
TI.2.1#03
 dependent
SHALL

The system SHALL capture an Audit Log Entry at each Audit Trigger as specified in TI.2.1 (Audit Triggers) according to scope of practice, organizational policy, and/or jurisdictional law.
TI.2.1#04
SHALL

The system SHALL capture the current master clock time to establish valid record date and time metadata.
TI.2.1#05
MAY

The system MAY manage Audit Trigger logging using a common audit engine (e.g., using schema and transports such as specified in the Audit Log specification of IHE Audit Trails and Node Authentication (ATNA) Profile).