HL7 Electronic Health Record System Functional Model, Release 2.1.1
2.1.1 - Normative

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/HL7/ehrsfm-ig/ and changes regularly. See the Directory of published versions

## Requirements: RI.1.1.4 Attest Record Lifecycle Event (Function)

Official URL: http://hl7.org/ehrs/uv/ehrsfmr2/Requirements/EHRSFMR2-RI.1.1.4 | Version: 2.1.1
Standards status: Normative Active as of 2025-12-13 | Computable Name: RI_1_1_4_Attest_Record_Lifecycle_Event

Attest Record Entries (1 or more instances)

Description I:

Occurs when an agent causes the system to capture the agent’s digital signature (or equivalent indication) during formal validation of record entry content.

Reference: ISO 21089-2018, Section 15.4.

Criteria N:

RI.1.1.4#01 | SHALL | The system SHALL conform to function TI.1.1 (Entity Authentication).
RI.1.1.4#02 | SHALL | The system SHALL conform to function TI.1.2 (Entity Authorization).
RI.1.1.4#03 | SHALL | The system SHALL provide the ability to attest (approve and apply signature to) Record Entry content by the author.
RI.1.1.4#04 | SHALL | The system SHALL capture the signature event (e.g., digital signature) of the Attesting Author, binding signature to Record Entry content.
RI.1.1.4#05 | SHALL | The system SHALL provide the ability to maintain any attestable Record Entry content added or changed with the content's author
RI.1.1.4#06 | SHALL | The system SHALL present the status of attestable Record Entry content which has not been attested, conforming to function RI.1.3.1 (Record Pending State).
RI.1.1.4#07 | SHALL dependent conditional | IF the attester is different than the author(s), THEN the system SHALL provide the ability to maintain Record Entry content by properly authenticated and authorized users different from the author (e.g., counter-signature) according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.1.4#08 | SHOULD | The system SHOULD provide the ability to manage digital signatures as the means for attestation.
RI.1.1.4#09 | SHALL conditional | IF more than one author contributed to the Record Entry content, THEN the system SHALL provide the ability to maintain all authors/contributors associated with their content.
RI.1.1.4#10 | SHALL conditional | IF Record Entry content is attested by someone other than the author, THEN the system SHALL maintain and display the author(s) and attester.
RI.1.1.4#11 | SHALL dependent | The system SHALL provide the ability to present a minimum set of information that identifies the author of Record Entry content according to scope of practice, organizational policy, and/or jurisdictional law (e.g., name, credential, and/or role (such as Karen Smith, RN)).
RI.1.1.4#12 | SHALL | The system SHALL capture the signature type of the entity (individual, EHR or other system, or organization) sending Record Entry content.
RI.1.1.4#13 | SHALL | The system SHALL capture the signature type of the entity (individual, EHR or other system, or organization) receiving Record Entry content.
RI.1.1.4#14 | SHALL | The system SHALL capture all signature types of the entities through which Record Entry content has passed.