Publish Box goes here

• Narrative Content
• XML
• JSON
• TTL

: RI.1 Record Lifecycle and Lifespan (Header) - XML Representation

Active as of 2024-11-26

Raw xml | Download

<Requirements xmlns="http://hl7.org/fhir">
  <id value="EHRSFMR2.1-RI.1"/>
  <meta>
    <profile value="http://hl7.org/ehrs/StructureDefinition/FMHeader"/>
  </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 Lifecycle and Lifespan</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>Actions are taken to support patient health. Actions are taken in provision of healthcare to individuals. Actions are taken as the result of rules-based EHR System algorithms. Actors (i.e., patients, providers, users, systems) take Actions. (Actions broadly encompass tasks, acts, procedures or services performed or provided.) The EHR System captures Actions taken and creates corresponding Record Entries. Record Entries provide persistent evidence of Action occurrence, context, disposition, facts, findings and observations. From the point of Record Entry origination to the end of its lifespan, the EHR System manages each Entry consistent with and according to scope of practice, organizational policy, and jurisdictional law. In support of individual health and in provision of healthcare to individuals, Actors perform Actions and Actions have corresponding Entries in the EHR Record, (i.e., Action instances are documented by Record Entry instances). Record Entries may be captured during the course of the Action or sometime thereafter. The Actor (author/source) of the Record Entry may be the same as an Actor performing the Action or not. The EHRS Functional Model does not specify a particular relationship of Actions and corresponding Record Entries. It may be one to one, many to one or even one to many. Actions have associated metadata (e.g., who, what, when, where, why, how, under what conditions, in what context). The corresponding Record Entry captures this metadata along with other Action and Record Entry related information.</p>
<p>Each Record Entry also includes its own provenance metadata such as who (authoring Actor) and when (documented). Record Entries may be encapsulated to bind Actor (individual, organization, and/or system) signatures to data and metadata content and data/time of occurrence. Actions and related Record Entries capture a chronology of patient health and healthcare and also a chronology of operations and services provided in/by a healthcare enterprise. Record Entries reflect changes in health information from the time it was created, to the time it was amended, sent, received, etc. In this manner, each Record Entry serves as persistent evidence of an Action taken, enabling providers to maintain comprehensive information that may be needed for legal, business, and disclosure purposes. To satisfy these purposes, Record Entries must also be retained and persisted without alteration. Record Entries have both a lifecycle and a lifespan. Lifecycle Events include originate, retain, amend, verify, attest, access/view, de-identify, transmit/receive, and more. Lifecycle Events occur at various points in a Record Entry lifespan, always starting with a point of origination and retention (i.e., when the Entry is first created and stored). A Record Entry may have a pre and post Event state if content is modified. In this case, the original Record Entry is preserved (with signature binding) and a new Entry is created (with new signature binding). A Record Entry contains data and metadata, in multiple formats, following various conventions and standards. Included data may be tagged, and/or delimited, structured (concise, encoded, computable), or unstructured (free form, non-computable). Data may be encoded as text, document, images, audio, waveforms, in ASCII, binary or other encoding. Structured data may be characterized as being concise, encoded, computable, and may be divided into discrete fields.</p>
<p>Examples of structured health information include:</p>
<ul>
<li>patient residence (non-codified, but discrete field)</li>
<li>diastolic blood pressure (numeric)</li>
<li>coded laboratory result or observation</li>
<li>coded diagnosis</li>
<li>patient risk assessment questionnaire with multiple-choice answers.</li>
</ul>
<p>Unstructured data may be characterized as being free form, and/or non-computable. Unstructured health record information is information that is not divided into discrete fields AND not represented as numeric, enumerated or codified data.</p>
<p>Examples of unstructured health record information include:</p>
<ul>
<li>text (text message to physician) - word processing document (a letter from a family member) - image (photograph of a patient or a scanned image of insurance card) - multimedia (dictated report or a voice recording).</li>
</ul>
<p>Context may determine whether data are structured or unstructured. For example, a progress note might be standardized and structured in some systems (e.g., Subjective/Objective/Assessment/Plan) but unstructured in other systems. The EHR System manages Record Lifecycle Events for each Record Entry, including pre and post Event record states, continuity, persistence and related Record Audit Logs.
Example:
Action examples include:
(1) In the direct care of a patient, a healthcare professional creates or amends health information to be contained in a history and physical;
(2) A medical device can supply the EHR system with a test result;
(3) The EHR system can alert the healthcare professional of a potential drug-drug interaction.</p>
<p>Record Lifecycle Events (as per Section RI.1.1) are those required to manage Record Entries in persistent storage over the full course of Record Lifespan (as per Section RI.1.2).</p>
</div></span>
    

    

    
    <table id="statements" class="grid dict">
        
    </table>
</div>
  </text>
  <url value="http://hl7.org/ehrs/Requirements/EHRSFMR2.1-RI.1"/>
  <version value="2.1.0"/>
  <name value="RI_1_Record_Lifecycle_and_Lifespan"/>
  <title value="RI.1 Record Lifecycle and Lifespan (Header)"/>
  <status value="active"/>
  <date value="2024-11-26T16:30:50+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 Lifecycle and Lifespan"/>
  <jurisdiction>
    <coding>
      <system value="http://unstats.un.org/unsd/methods/m49/m49.htm"/>
      <code value="001"/>
      <display value="World"/>
    </coding>
  </jurisdiction>
  <purpose
           value="Actions are taken to support patient health. Actions are taken in provision of healthcare to individuals. Actions are taken as the result of rules-based EHR System algorithms. Actors (i.e., patients, providers, users, systems) take Actions. (Actions broadly encompass tasks, acts, procedures or services performed or provided.) The EHR System captures Actions taken and creates corresponding Record Entries. Record Entries provide persistent evidence of Action occurrence, context, disposition, facts, findings and observations. From the point of Record Entry origination to the end of its lifespan, the EHR System manages each Entry consistent with and according to scope of practice, organizational policy, and jurisdictional law. In support of individual health and in provision of healthcare to individuals, Actors perform Actions and Actions have corresponding Entries in the EHR Record, (i.e., Action instances are documented by Record Entry instances). Record Entries may be captured during the course of the Action or sometime thereafter. The Actor (author/source) of the Record Entry may be the same as an Actor performing the Action or not. The EHRS Functional Model does not specify a particular relationship of Actions and corresponding Record Entries. It may be one to one, many to one or even one to many. Actions have associated metadata (e.g., who, what, when, where, why, how, under what conditions, in what context). The corresponding Record Entry captures this metadata along with other Action and Record Entry related information. 

Each Record Entry also includes its own provenance metadata such as who (authoring Actor) and when (documented). Record Entries may be encapsulated to bind Actor (individual, organization, and/or system) signatures to data and metadata content and data/time of occurrence. Actions and related Record Entries capture a chronology of patient health and healthcare and also a chronology of operations and services provided in/by a healthcare enterprise. Record Entries reflect changes in health information from the time it was created, to the time it was amended, sent, received, etc. In this manner, each Record Entry serves as persistent evidence of an Action taken, enabling providers to maintain comprehensive information that may be needed for legal, business, and disclosure purposes. To satisfy these purposes, Record Entries must also be retained and persisted without alteration. Record Entries have both a lifecycle and a lifespan. Lifecycle Events include originate, retain, amend, verify, attest, access/view, de-identify, transmit/receive, and more. Lifecycle Events occur at various points in a Record Entry lifespan, always starting with a point of origination and retention (i.e., when the Entry is first created and stored). A Record Entry may have a pre and post Event state if content is modified. In this case, the original Record Entry is preserved (with signature binding) and a new Entry is created (with new signature binding). A Record Entry contains data and metadata, in multiple formats, following various conventions and standards. Included data may be tagged, and/or delimited, structured (concise, encoded, computable), or unstructured (free form, non-computable). Data may be encoded as text, document, images, audio, waveforms, in ASCII, binary or other encoding. Structured data may be characterized as being concise, encoded, computable, and may be divided into discrete fields. 

Examples of structured health information include:
- patient residence (non-codified, but discrete field)
- diastolic blood pressure (numeric) 
- coded laboratory result or observation
- coded diagnosis 
- patient risk assessment questionnaire with multiple-choice answers. 

Unstructured data may be characterized as being free form, and/or non-computable. Unstructured health record information is information that is not divided into discrete fields AND not represented as numeric, enumerated or codified data. 

Examples of unstructured health record information include:
- text (text message to physician) - word processing document (a letter from a family member) - image (photograph of a patient or a scanned image of insurance card) - multimedia (dictated report or a voice recording). 

Context may determine whether data are structured or unstructured. For example, a progress note might be standardized and structured in some systems (e.g., Subjective/Objective/Assessment/Plan) but unstructured in other systems. The EHR System manages Record Lifecycle Events for each Record Entry, including pre and post Event record states, continuity, persistence and related Record Audit Logs.
Example:
Action examples include: 
(1) In the direct care of a patient, a healthcare professional creates or amends health information to be contained in a history and physical; 
(2) A medical device can supply the EHR system with a test result;
(3) The EHR system can alert the healthcare professional of a potential drug-drug interaction. 

Record Lifecycle Events (as per Section RI.1.1) are those required to manage Record Entries in persistent storage over the full course of Record Lifespan (as per Section RI.1.2)."/>
</Requirements>