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 |
@prefix fhir: <http://hl7.org/fhir/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
# - resource -------------------------------------------------------------------
a fhir:Requirements ;
fhir:nodeRole fhir:treeRoot ;
fhir:id [ fhir:v "EHRSFMR2.1-TI.5.2"] ; #
fhir:meta [
( fhir:profile [
fhir:v "http://hl7.org/ehrs/StructureDefinition/FMFunction"^^xsd:anyURI ;
fhir:link <http://hl7.org/ehrs/StructureDefinition/FMFunction> ] )
] ; #
fhir:text [
fhir:status [ fhir:v "extensions" ] ;
fhir:div "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <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>Support various versions of an interchange standard.</p>\n</div></span>\n\n \n <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>Interchange standards characteristically change throughout their lifecycles; those changes are often tagged with "version" numbers. EHR systems need to control the various versions of interchange standards that are used within an EHR implementation and accommodate changes that arise with each version.</p>\n<p>For example, if an organization migrates to version 2.5 of HL7's messaging standard, it may choose to utilize that version's specimen or blood bank information capabilities. The organization may also find that certain fields have been retained for backwards compatibility only or withdrawn altogether. The EHR-S needs to be able to handle all of these possibilities.</p>\n<p>Standards typically evolve in such a way as to protect backwards compatibility.</p>\n<p>On the other hand, sometimes there is little, or no, backwards compatibility when an organization may need to replace an entire standard with a new methodology. An example of this is migrating from HL7 v2 to HL7 v3. Interchange standards that are backward compatible support exchange among senders and receivers who are using different versions. Version control ensures that those sending information in a later version of a standard consider the difference in information content that can be interchanged effectively with receivers, who are capable of processing only earlier versions. That is, senders need to be aware of the information that receivers are unable to capture and adjust their business processes accordingly.</p>\n<p>Version control enables multiple versions of the same interchange standard to exist and be distinctly recognized over time. Since interchange standards are usually periodically updated, concurrent use of different versions may be required.</p>\n<p>Large (and/or federated) organizations typically need to use different versions of an interchange standard to meet internal organizational interoperability requirements.</p>\n<p>For example, the enterprise-wide standard might use HL7 v2.5 for laboratory messages, but some regions of the enterprise might be at a lower level.</p>\n<p>It should be possible to retire deprecated interchange standards versions when applicable business cycles are completed while maintaining obsolete versions. An example use of this is for possible claims adjustment throughout the claim's life cycle.</p>\n<p>When interchange standards change over time, it is important that retrospective analysis and research correlate and note gaps between the different versions' information structures to support the permanence of concepts over time.\nExample:\nAn example use of this is the calculation of outcome or performance measures from persisted data stores where one version of a relevant interchange standard, e.g., CDA Release 1 captures the relevant data, e.g., discharge data, differently than CDA Release 2.</p>\n</div></span>\n \n\n \n\n \n <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>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.5.2#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to exchange information with other systems that use different versions of interchange standards.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.5.2#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to exchange information based on updated (or reconfigured) interchange standards and/or based on updated business needs.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.5.2#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to tag an interchange standard as being deprecated.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.5.2#04</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to integrate with other systems that use previously-supported versions of an interoperability standard according to scope of practice, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
] ; #
fhir:url [ fhir:v "http://hl7.org/ehrs/Requirements/EHRSFMR2.1-TI.5.2"^^xsd:anyURI] ; #
fhir:version [ fhir:v "2.1.0"] ; #
fhir:name [ fhir:v "TI_5_2_Interchange_Standards_Versioning_and_Maintenance"] ; #
fhir:title [ fhir:v "TI.5.2 Interchange Standards Versioning and Maintenance (Function)"] ; #
fhir:status [ fhir:v "active"] ; #
fhir:date [ fhir:v "2024-11-23T08:20:40+00:00"^^xsd:dateTime] ; #
fhir:publisher [ fhir:v "EHR WG"] ; #
fhir:contact ( [
( fhir:telecom [
fhir:system [ fhir:v "url" ] ;
fhir:value [ fhir:v "http://www.hl7.org/Special/committees/ehr" ] ] )
] ) ; #
fhir:description [ fhir:v "Support various versions of an interchange standard."] ; #
fhir:purpose [ fhir:v "Interchange standards characteristically change throughout their lifecycles; those changes are often tagged with \"version\" numbers. EHR systems need to control the various versions of interchange standards that are used within an EHR implementation and accommodate changes that arise with each version.\n\nFor example, if an organization migrates to version 2.5 of HL7's messaging standard, it may choose to utilize that version's specimen or blood bank information capabilities. The organization may also find that certain fields have been retained for backwards compatibility only or withdrawn altogether. The EHR-S needs to be able to handle all of these possibilities.\n\nStandards typically evolve in such a way as to protect backwards compatibility. \n\nOn the other hand, sometimes there is little, or no, backwards compatibility when an organization may need to replace an entire standard with a new methodology. An example of this is migrating from HL7 v2 to HL7 v3. Interchange standards that are backward compatible support exchange among senders and receivers who are using different versions. Version control ensures that those sending information in a later version of a standard consider the difference in information content that can be interchanged effectively with receivers, who are capable of processing only earlier versions. That is, senders need to be aware of the information that receivers are unable to capture and adjust their business processes accordingly.\n\nVersion control enables multiple versions of the same interchange standard to exist and be distinctly recognized over time. Since interchange standards are usually periodically updated, concurrent use of different versions may be required.\n\nLarge (and/or federated) organizations typically need to use different versions of an interchange standard to meet internal organizational interoperability requirements.\n\nFor example, the enterprise-wide standard might use HL7 v2.5 for laboratory messages, but some regions of the enterprise might be at a lower level.\n\nIt should be possible to retire deprecated interchange standards versions when applicable business cycles are completed while maintaining obsolete versions. An example use of this is for possible claims adjustment throughout the claim's life cycle.\n\nWhen interchange standards change over time, it is important that retrospective analysis and research correlate and note gaps between the different versions' information structures to support the permanence of concepts over time.\nExample:\nAn example use of this is the calculation of outcome or performance measures from persisted data stores where one version of a relevant interchange standard, e.g., CDA Release 1 captures the relevant data, e.g., discharge data, differently than CDA Release 2."] ; #
fhir:statement ( [
( fhir:extension [
fhir:url [ fhir:v "http://hl7.org/ehrs/StructureDefinition/requirements-dependent"^^xsd:anyURI ] ;
fhir:value [ fhir:v "false"^^xsd:boolean ] ] ) ;
fhir:key [ fhir:v "EHRSFMR2.1-TI.5.2-01" ] ;
fhir:label [ fhir:v "TI.5.2#01" ] ;
( fhir:conformance [ fhir:v "SHALL" ] ) ;
fhir:conditionality [ fhir:v "false"^^xsd:boolean ] ;
fhir:requirement [ fhir:v "The system SHALL provide the ability to exchange information with other systems that use different versions of interchange standards." ] ;
fhir:derivedFrom [ fhir:v "EHR-S_FM_R1.1 IN.5.2#1" ]
] [
( fhir:extension [
fhir:url [ fhir:v "http://hl7.org/ehrs/StructureDefinition/requirements-dependent"^^xsd:anyURI ] ;
fhir:value [ fhir:v "false"^^xsd:boolean ] ] ) ;
fhir:key [ fhir:v "EHRSFMR2.1-TI.5.2-02" ] ;
fhir:label [ fhir:v "TI.5.2#02" ] ;
( fhir:conformance [ fhir:v "SHALL" ] ) ;
fhir:conditionality [ fhir:v "false"^^xsd:boolean ] ;
fhir:requirement [ fhir:v "The system SHALL provide the ability to exchange information based on updated (or reconfigured) interchange standards and/or based on updated business needs." ] ;
fhir:derivedFrom [ fhir:v "EHR-S_FM_R1.1 IN.5.2#2" ]
] [
( fhir:extension [
fhir:url [ fhir:v "http://hl7.org/ehrs/StructureDefinition/requirements-dependent"^^xsd:anyURI ] ;
fhir:value [ fhir:v "false"^^xsd:boolean ] ] ) ;
fhir:key [ fhir:v "EHRSFMR2.1-TI.5.2-03" ] ;
fhir:label [ fhir:v "TI.5.2#03" ] ;
( fhir:conformance [ fhir:v "SHOULD" ] ) ;
fhir:conditionality [ fhir:v "false"^^xsd:boolean ] ;
fhir:requirement [ fhir:v "The system SHOULD provide the ability to tag an interchange standard as being deprecated." ] ;
fhir:derivedFrom [ fhir:v "EHR-S_FM_R1.1 IN.5.2#3" ]
] [
( fhir:extension [
fhir:url [ fhir:v "http://hl7.org/ehrs/StructureDefinition/requirements-dependent"^^xsd:anyURI ] ;
fhir:value [ fhir:v "true"^^xsd:boolean ] ] ) ;
fhir:key [ fhir:v "EHRSFMR2.1-TI.5.2-04" ] ;
fhir:label [ fhir:v "TI.5.2#04" ] ;
( fhir:conformance [ fhir:v "SHOULD" ] ) ;
fhir:conditionality [ fhir:v "false"^^xsd:boolean ] ;
fhir:requirement [ fhir:v "The system SHOULD provide the ability to integrate with other systems that use previously-supported versions of an interoperability standard according to scope of practice, organizational policy, and/or jurisdictional law." ] ;
fhir:derivedFrom [ fhir:v "EHR-S_FM_R1.1 IN.5.2#4" ]
] ) . #
IG © 2024 EHR WG. Package hl7.ehrs.ehrsfmr21#2.1.0 based on FHIR 5.0.0. Generated 2024-11-23
Links: Table of Contents |
QA Report