HL7 Electronic Health Record System Functional Model, Release 2.1.1
            
            2.1.1 - 
  
            
          
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
| Official URL: http://hl7.org/ehrs/uv/ehrsfmr2/Requirements/EHRSFMR2-RI.1.3.3 | Version: 2.1.1 | |||
| Standards status: Normative Active as of 2025-10-31 | Computable Name: RI_1_3_3_Manage_Record_Entry_Succession_and_Version_Control | |||
Manage successive Record Entry versions over time.
Manage successive Record Entry versions over time.
The system must have a mechanism to handle versions and succession of Record Entries (such as a preliminary and final laboratory reports, amended or corrected documents). Versioning and succession management is based on Record Entry content, and/or status change over time.
A version may be one of:1) A completed and attested Record Entry; 2) A Record Entry completed and attested which has been modified one or more times3) A Record Entry that has been viewed for clinical decision-making purposes by an individual other than the author4) A Record Entry that has been captured in an incomplete state per organization business rules and updated over time (i.e., a preliminary laboratory test). 5) A Record Entry that electively, according to the author, must be preserved in the current state at a given point in time (i.e., History and Physical). Certain types of Record Entries are typically handled in versions, for example: laboratory results (preliminary and final)- Dictated reports- Work ups (over course of days)The prior version of Record Entries should be retained for the legally prescribed timeframe as defined by scope of practice, organizational policy, and jurisdictional law.
| 
                
                 RI.1.3.3#01 
                
             | 
            
                
                
                
                 SHOULD 
                
             | 
            
                
                 The system SHOULD provide the ability to manage Record Entries that become new versions when their state changes (e.g., augmented, amended, corrected, etc.).  | 
        
| 
                
                 RI.1.3.3#02 
                
             | 
            
                
                
                
                 SHALL 
                
             | 
            
                
                 The system SHALL provide the ability to update a Record Entry and save it as a new version.  | 
        
| 
                
                 RI.1.3.3#03 
                
             | 
            
                
                
                
                 SHALL 
                
             | 
            
                
                 The system SHALL capture, maintain and render the date, time and user for the original and each updated version of the Record Entry.  | 
        
| 
                
                 RI.1.3.3#04 
                
             | 
            
                
                
                
                 SHALL 
                
             | 
            
                
                 The system SHALL manage the succession of Record Entries in chronological version order.  |