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

Publication Build: This will be filled in by the publication tooling

## Requirements: RI.1.2.1 Manage Record Entries (Function)

Page standards status: Informative

Statement N:

Manage/Persist Record Entries (Multiple instances)

Description I:

Occurs upon Record Entry origination/retention and thereafter on a continuous and uninterrupted basis for lifespan of each Record Entry.

- Ensures long-term retention and preservation of EHR Record Entries, without alteration.

Reference: ISO 21089, Section 12.2.2

Actors:
ehr Criteria N:

RI.1.2.1#01 | SHALL | The system SHALL manage each Record Entry as a persistent, indelible (unalterable) data object, including its revision history.
RI.1.2.1#02 | dependent SHALL | The system SHALL manage (persist) each Record Entry for its applicable retention period according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#03 | SHALL | The system SHALL manage (persist) the full set of identity, event and provenance Audit Metadata for each Record Entry, conforming to lifecycle events in function RI.1.1 (Record Lifecycle) and metadata requirements in function TI.2.1.1 (Record Entry Audit Triggers).
RI.1.2.1#04 | SHALL | The system SHALL manage (persist) the attestation/signature event (e.g., digital signature) of each Record Entry conforming to function RI.1.1.4 (Attest Record Entry Content).
RI.1.2.1#05 | SHALL | The system SHALL manage Record Entries with data content in standard and non-standard formats.
RI.1.2.1#06 | SHALL | The system SHALL manage Record Entries containing both structured and unstructured data.
RI.1.2.1#07 | SHOULD | The system SHOULD manage Record Entry content with tagged or delimited elements including data formatted as text, documents, images, audio, waveforms, in ASCII, binary and other encodings.
RI.1.2.1#08 | SHOULD | The system SHOULD manage Record Entries in clinical and business contexts.
RI.1.2.1#09 | SHOULD | The system SHOULD provide the ability to manage sets of clinical and business context data, to be captured in or linked to Record Entries.
RI.1.2.1#10 | dependent SHOULD | The system SHOULD provide the ability to extract all available elements included in the definition of a legal medical record (including Audit Log Entries and the decoded translation of anything stored only in code form) according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#11 | dependent MAY | The system MAY provide the ability to tag specific Record Entries for deletion according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#12 | dependent conditional SHALL | IF allowing tags for specific Record Entry deletion, THEN the system SHALL provide the ability to manage the set of tagged Entries, allowing review and confirmation before actual deletion occurs according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#13 | dependent conditional SHALL | IF allowing tags for specific Record Entry deletion, THEN the system SHALL provide the ability to delete Entries according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#14 | dependent conditional SHALL | IF allowing tags for specific Record Entry deletion, THEN the system SHALL provide the ability to render confirming notification that the destruction occurred according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#15 | dependent MAY | The system MAY provide the ability to maintain Record Entries by undeleting the Record Entries according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#16 | MAY | The system MAY transmit record destruction date information along with existing data when transmitting Record Entries (or extracts) to another entity.
RI.1.2.1#17 | dependent SHOULD | The system SHOULD manage health care information for organizations that have multiple facilities according to scope of practice, organizational policy, and/or jurisdictional law.
RI.1.2.1#18 | MAY | The system MAY tag and render patient information that has been not been previously presented to the clinician.
RI.1.2.1#19 | dependent conditional MAY | IF the system tags patient information from internal or external systems that has not been previously presented to the clinician, THEN the system MAY present a notification to that clinician in accordance with user role and according to scope of practice, organizational policy, and/or jurisdictional law.