With very few exceptions*, HL7 Version 3 standards are models of interactions and information exchanges using messages between various applications acting in different roles in the system. The HL7 Development Framework then automatically applies rules about how the interactions identified by the model are expressed in XML Schema using the HL7 Version 3 Implementation Technology Specification. That specification relies a bit further on the HL7 Version 3 Data Types (pick any of three releases) for expression of the basic data types in the message.
So when a committee like Patient Care or Orders and Observations creates an HL7 Version 3 standard, they are defining the information content of the exchange, NOT THE XML SCHEMA. In fact, the XML is NOT the normative definition of the standard that they are producing.
As the XML ITS (Release 1) says of itself:
This document describes how HL7 V3 compliant messages can be expressed using XML. It describes how the definition of the set of valid XML instance documents is derived from a specific HL7 Message Type. It covers ISO levels 5 and 6. Those familiar with V2 might call these the "XML encoding rules" for HL7 Version 3 messages.
So, if need be, someone could create a JSON ITS, or a UML ITS (it used to exist), or a JSON ITS, or a Python ITS. If you don't like the XML, the opportunity exists to improve it, but the XML itself isn't the standard. The artifacts you will find in a V3 standard include:
Thus, the HMD is the "normative" description of the messages being defined by the standard, and it is another HL7 standard (the XML ITS) which turns the HMD into something that can be used in an implementation. If you don't like the HL7 XML, you could develop another ITS. Some work groups are trying to do so and just not figuring out how to make their ad-hoc XML content actually be algorithmically derived from a RIM-based model. I'm not too worried about these efforts, or efforts to create a JSON based ITS or any other ITS for that matter. From my perspective, that's the old way of doing things, and I want to see how we could do it on FHIR.
Keith
* One HL7 Standard is a big exception to this rule, and that is CDA Release 2.0, which in its conformance section says: A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains.
So when a committee like Patient Care or Orders and Observations creates an HL7 Version 3 standard, they are defining the information content of the exchange, NOT THE XML SCHEMA. In fact, the XML is NOT the normative definition of the standard that they are producing.
As the XML ITS (Release 1) says of itself:
This document describes how HL7 V3 compliant messages can be expressed using XML. It describes how the definition of the set of valid XML instance documents is derived from a specific HL7 Message Type. It covers ISO levels 5 and 6. Those familiar with V2 might call these the "XML encoding rules" for HL7 Version 3 messages.
So, if need be, someone could create a JSON ITS, or a UML ITS (it used to exist), or a JSON ITS, or a Python ITS. If you don't like the XML, the opportunity exists to improve it, but the XML itself isn't the standard. The artifacts you will find in a V3 standard include:
- Story Boards
- Application Roles (which are Informative rather than Normative at this time [still])
- Trigger Events
- Interactions
- Domain Message Information Model (D-MIM)
- Restricted Message Information Models (R-MIMs)
- Hierarchical Message Descriptors (HMD)
- XML Schema (which are not Normative!)
Thus, the HMD is the "normative" description of the messages being defined by the standard, and it is another HL7 standard (the XML ITS) which turns the HMD into something that can be used in an implementation. If you don't like the HL7 XML, you could develop another ITS. Some work groups are trying to do so and just not figuring out how to make their ad-hoc XML content actually be algorithmically derived from a RIM-based model. I'm not too worried about these efforts, or efforts to create a JSON based ITS or any other ITS for that matter. From my perspective, that's the old way of doing things, and I want to see how we could do it on FHIR.
Keith
* One HL7 Standard is a big exception to this rule, and that is CDA Release 2.0, which in its conformance section says: A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains.
And having to write explanations like the one above is one reason why I like FHIR.
ReplyDeleteAFAIK it's the MIF expression of the model that's the normative artefact - an HMD is pretty close however, see http://www.ringholm.com/docs/03060_en_HL7_MIF.htm for details of MIF.
ReplyDeleteThe fact that the XSDs are (with the exception of CDA) not normative, and that the XSD language is much too weak to express all of the requirements as expressed in a v3 model, does already indicate that there are many implementation issues around the validation of v3 artefacts.
You live and learn - FHIR is certainly a lot more implementation friendly.
According to "HL7 Version 3 Substantive Change" (itself a non-normative document), the following artifacts are normative:
ReplyDeleteTrigger Event
CMET
RMIM
HMD
Message Type
Interactions
It lists several other artifacts as being non-normative, but note that neither the XML Schema NOR the MIF are mentioned.