Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Monday, July 7, 2014

That XML Schema is NOT the HL7 Standard you are reading

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:
  • 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!)
The XML schema is derived from the HMD based on rules defined in the XML ITS.  The HMD is derived from the R-MIM, which are models used to implement an Interaction which is defined based on a set of application roles interacting according to a storyboard based on the occurence of a trigger event.

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.


* 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.