ISO/HL7 10781 - Electronic Health Record System Functional Model, Release 2.1
2.1.0 - CI Build
ISO/HL7 10781 - Electronic Health Record System Functional Model, Release 2.1
2.1.0 - CI Build
Publish Box goes here
| Active as of 2024-11-23 |
<Requirements xmlns="http://hl7.org/fhir">
<id value="EHRSFMR2.1-RI.3"/>
<meta>
<profile value="http://hl7.org/ehrs/StructureDefinition/FMFunction"/>
</meta>
<text>
<status value="extensions"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<span id="description"><b>Statement <a href="https://hl7.org/fhir/versions.html#std-process" title="Normative Content" class="normative-flag">N</a>:</b> <div><p>Manage Record Archive and Restore</p>
</div></span>
<span id="purpose"><b>Description <a href="https://hl7.org/fhir/versions.html#std-process" title="Informative Content" class="informative-flag">I</a>:</b> <div><p>EHR Record Entries must be transitioned over its lifecycle from online data structures to near-line or off-line data structures. The archive function performs this transition of Record Entries from an online, production EHR-S to offline storage for information that is not being purged/destroyed. The system must provide such archive and restore functions to extract and preserve indefinitely, Record Entries selected to be removed from the live production EHR-S database and retained.</p>
<p>Record Entries must be archived and restored in such a manner as to permit them to be returned to their original or similar information structures. Archived Record Entries must also include corresponding metadata to ensure logical and semantic consistency of the information for subsequent access upon restoration.</p>
<p>The archive function should provide both an automated, configurable capability as well as a user-invoked archival function to enable selected Record Entries to be preserved, or flagged for preservation.</p>
<p>In the first instance, rules are specified to enable the system to conduct archiving in an unattended fashion. This is often the case for periodic system maintenance requirements (e.g., nightly processing where archival, data summarization and possibly purging of information occurs). In the second instance the system should provide the ability to select Record Entries to be preserved for future reference and access, such as in the case where selected Entries need to be preserved and retained for litigation.</p>
<p>In restoring information, it may occur that Record Entries being restored are a subset of the Entries originally archived. For example, when all Record Entries for a patient encounter were archived and only a particular set of Record Entries related to a study or result are to be restored. The system may provide for such finer granularity of restoration.</p>
<p>Archiving and restoring of Record Entries must be performed in a timely fashion, consistent with the operational requirements of both EHR users and system and technology capabilities.</p>
<p>The system must enable compliance with records retention according to scope of practice, organizational policy or jurisdictional law.</p>
</div></span>
<span id="requirements"><b>Criteria <a href="https://hl7.org/fhir/versions.html#std-process" title="Normative Content" class="normative-flag">N</a>:</b></span>
<table id="statements" class="grid dict">
<tr>
<td style="padding-left: 4px;">
<span>RI.3#01</span>
</td>
<td style="padding-left: 4px;">
<i>dependent</i>
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHALL provide the ability to archive and restore Record Entries according to scope of practice, organizational policy, and/or jurisdictional law (e.g., to/from off-line or near-line media).</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>RI.3#02</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHALL provide the ability for an authorized user to tag and untag Record Entries to be archived.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>RI.3#03</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHALL provide the ability to archive or restore metadata that is associated with Record Entries that have been archived or restored.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>RI.3#04</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHOULD provide the ability to enter a target destination when restoring Record Entries (e.g., original data location, temporary user storage, or a research/analysis database).</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>RI.3#05</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHOULD provide the ability to tag Record Entries that will be retained or archived during the archival process.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>RI.3#06</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHOULD provide the ability to enter a schedule for archive and restore processing.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>RI.3#07</span>
</td>
<td style="padding-left: 4px;">
<span>MAY</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system MAY provide the ability to restore selected portions of archived Record Entries.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>RI.3#08</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHALL provide the ability to manage (configure) archival parameters for Record Entries (e.g., what and when to archive).</p>
</div></span>
</td>
</tr>
</table>
</div>
</text>
<url value="http://hl7.org/ehrs/Requirements/EHRSFMR2.1-RI.3"/>
<version value="2.1.0"/>
<name value="RI_3_Record_Archive_and_Restore"/>
<title value="RI.3 Record Archive and Restore (Function)"/>
<status value="active"/>
<date value="2024-11-23T08:20:40+00:00"/>
<publisher value="EHR WG"/>
<contact>
<telecom>
<system value="url"/>
<value value="http://www.hl7.org/Special/committees/ehr"/>
</telecom>
</contact>
<description value="Manage Record Archive and Restore"/>
<purpose
value="EHR Record Entries must be transitioned over its lifecycle from online data structures to near-line or off-line data structures. The archive function performs this transition of Record Entries from an online, production EHR-S to offline storage for information that is not being purged/destroyed. The system must provide such archive and restore functions to extract and preserve indefinitely, Record Entries selected to be removed from the live production EHR-S database and retained.
Record Entries must be archived and restored in such a manner as to permit them to be returned to their original or similar information structures. Archived Record Entries must also include corresponding metadata to ensure logical and semantic consistency of the information for subsequent access upon restoration.
The archive function should provide both an automated, configurable capability as well as a user-invoked archival function to enable selected Record Entries to be preserved, or flagged for preservation.
In the first instance, rules are specified to enable the system to conduct archiving in an unattended fashion. This is often the case for periodic system maintenance requirements (e.g., nightly processing where archival, data summarization and possibly purging of information occurs). In the second instance the system should provide the ability to select Record Entries to be preserved for future reference and access, such as in the case where selected Entries need to be preserved and retained for litigation.
In restoring information, it may occur that Record Entries being restored are a subset of the Entries originally archived. For example, when all Record Entries for a patient encounter were archived and only a particular set of Record Entries related to a study or result are to be restored. The system may provide for such finer granularity of restoration.
Archiving and restoring of Record Entries must be performed in a timely fashion, consistent with the operational requirements of both EHR users and system and technology capabilities.
The system must enable compliance with records retention according to scope of practice, organizational policy or jurisdictional law."/>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="true"/>
</extension>
<key value="EHRSFMR2.1-RI.3-01"/>
<label value="RI.3#01"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL provide the ability to archive and restore Record Entries according to scope of practice, organizational policy, and/or jurisdictional law (e.g., to/from off-line or near-line media)."/>
</statement>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="false"/>
</extension>
<key value="EHRSFMR2.1-RI.3-02"/>
<label value="RI.3#02"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL provide the ability for an authorized user to tag and untag Record Entries to be archived."/>
</statement>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="false"/>
</extension>
<key value="EHRSFMR2.1-RI.3-03"/>
<label value="RI.3#03"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL provide the ability to archive or restore metadata that is associated with Record Entries that have been archived or restored."/>
</statement>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="false"/>
</extension>
<key value="EHRSFMR2.1-RI.3-04"/>
<label value="RI.3#04"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to enter a target destination when restoring Record Entries (e.g., original data location, temporary user storage, or a research/analysis database)."/>
</statement>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="false"/>
</extension>
<key value="EHRSFMR2.1-RI.3-05"/>
<label value="RI.3#05"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to tag Record Entries that will be retained or archived during the archival process."/>
</statement>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="false"/>
</extension>
<key value="EHRSFMR2.1-RI.3-06"/>
<label value="RI.3#06"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to enter a schedule for archive and restore processing."/>
</statement>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="false"/>
</extension>
<key value="EHRSFMR2.1-RI.3-07"/>
<label value="RI.3#07"/>
<conformance value="MAY"/>
<conditionality value="false"/>
<requirement
value="The system MAY provide the ability to restore selected portions of archived Record Entries."/>
</statement>
<statement>
<extension
url="http://hl7.org/ehrs/StructureDefinition/requirements-dependent">
<valueBoolean value="false"/>
</extension>
<key value="EHRSFMR2.1-RI.3-08"/>
<label value="RI.3#08"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL provide the ability to manage (configure) archival parameters for Record Entries (e.g., what and when to archive)."/>
</statement>
</Requirements>