Ringholm-Logo Ringholm Ringholm page header
Training    |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact
Home > Current column | Ringholm bv | Tel. +31 33 7 630 636| rene.spronk@ringholm.com

Renovate HL7 version 3

Publication date: Aug 03, 2012

It's time to renovate HL7 version 3 in such a manner that it is optimized for the kind of HL7 v3 implementations that we actually see in use today.

It's time to renovate HL7 version 3 because its original goals haven’t been achieved. It was the intent of HL7 v3 to tackle the very same EDI-messaging space as HL7 version 2 (at which it has failed), but to add object oriented modeling principles to achieve a much higher degree of consistency between the various message structures (at which it has succeeded).

HL7 v3 has been implemented in a sizable number of projects. Most of the software implementations of HL7 v3 either focus on something that originally wasn’t envisioned (CDA documents), or they choose to go for a full model driven software development approach, thereby moving away from the EDI-messaging concept that the model for interoperability is a different one than the business data model as used by the application.

HL7 should “follow the implementers” and renovate the HL7 v3 standard in such a manner that it is optimized for the kind of HL7 v3 implementations that we actually see in use today.

HL7 v3: Refinement by Constraint

The HL7 v3 methodology is based on refinement by constraint; all models (various layers thereof, e.g. DIM, SIM) are specializations of the Reference Information Model (RIM). However, refinement by constraint has it problems. Amongst other things it leads to 1000s of different models, some of which are much more granular than others.

HL7 v3: Re-use

HL7 version 3, using the XML ITS which exposes clone class names in the on the wire format, causes models that are semantically the same to have different XML element names. On hindsight the XML ITS was a terrible choice - mind you: not that we should blame its developers, way back in 1998 (when XML was still quite new) there was simply no way of knowing how XML schema would be used today, e.g. for code generation. The choices as made in the XML ITS lead to a very low re-use factor at the XML schema level.

Whereas the main element of re-use (from an implementers perspective) in HL7 v2 is the segment there is no such element of re-use in HL7 v3. Data type definitions are re-usable, as are RIM classes, but there is nothing in between. The Hl7 v3 methodology (refinement by constraint) leads to 100s of different message types .. without any re-usable component.

HL7 v3: Scalability

In the Message Types per system blogpost I argued that there are two peaks in the diagram: most applications are either used to support a smallish part of the workflow (and support relatively few message types) or they provide some kind of EHR-like functionality (a large number of message types). The implementers of HL7 v3, depending on the number of message types they initially have to support, typcially choose a dramatically different architectural approach to their implementations.

  • Low number of message types: use a HL7 v3 XML is ‘just another XML format’ approach (see also Grahame Grieve's blogpost v3 has succeeded). This doesn't scale - it typically just gets 'too painful' when there are more than just a couple of message types.
  • High number of message types: fully embrace the HL7 version 3 modeling stack and use a MDD approach. To fully embrace the HL7 version 3 model stack one has to let go of one of the basic principles underlying EDI-messaging: the Model for interoperability is separate from the data model as used internally within the application (see section 2.1 of the RIM history whitepaper).
The ‘just another XML format’ approach is implicitly suggested by the HL7 version 3 publication - all examples are XML based (and XML ITS based), and a set of XML schema has been published. The use of XML techniques and tools (XML schema, Schematron, Schema based code generation) is therefore a logical one - however one that doesn't scale up to a large number of message types.

The latter approach, whilst most beneficial when one has to deal with a high number of message types, also works for a low number of message types. Effectively this leads to the conclusion that currently the only viable implementation strategy, the one that scales up and down, is to fully embrace the HL7 v3 models and to use MDD. That approach however implies a steep learning curve and a serious investment of time and money.

If we look at CDA implementations, which have to support just 1 message type we tend to see the same kind of architectural approaches: deal with CDA as 'just another XML document', or use MDD to deal with template validation (see the Software Implementation of CDA whitepaper.)


HL7 is very much aware of most of the issues listed above. Grahame Grieve, as an active HL7 member and HL7 v3 implementer, has written a number of blogposts about the need for a Fresh Look when it comes to HL7 v3, ultimately leading up to him suggesting the core principles of a new standard (FHIR). FHIR tackles all of the issues identified above, and combines the best features of HL7 v3 with a modern cross industry architrecture - but could we renovate HL7 v3 as well, using similar principles?


So how could we renovate HL7 version 3 to be much more successful and easier to implement ? I see a couple of options:
  1. Renovate HL7 v3 by adding three new key principles:
    • Increase re-use of the wire format: the wire format for model 1, which is a specialization of model 2, SHALL be compatible with the wire format of model 2. Given that the RIM is the most abstract model in the hierarchy the RIM ITS is an obvious candidate. The XML ITS should cease to be a normative standard and be obsoleted sooner rather than later. Migration can be facilitated by providing automatically generated transformations of XML ITS based instances to RIM ITS based instances.
    • Add a layer of re-usable elements (i.e. re-usable for the implementer) to HL7 v3, getting rid of the 100s of different R-MIMs. The aim is to create a list of mandatory modeling elements that can't be redefined/constrained. This is mostly an issue of governance, and there will be resistance to it - this will require tough decisions, and it will get rid of some models that some groups within HL7 regard as absolutely essential. Choosing not to create such re-usable elements efectively means having to rely on MDD (as an implementation architecture) even more.
    • Change the published artefacts so they can be directly used for MDD using standard tools. If we regard MDD (as I do) as the only viable way to implement HL7 v3 then it follows that MDD style implementations should be facilitated.
  2. Renovate HL7 v3 by moving everything to CDA R3, and to cease development related to HL7 v3 messaging. This is effectively what the US seems to be doing. The wire format issue is solved by the fact that CDA is based on one single normative schema. Re-usable elements have been defined in the form of a series of 'consolidated templates' (part of C-CDA specification). MDD processing has been enabled by there being a couple of tools that allow for code generation based on CDA template definitions.
  3. Innovate by moving everything to FHIR, and to cease development of HL7 v3. FHIR can be implemented by the 'Just another XML format' approach, which does scale in the FHIR context. Re-usable components exist in the form of a limited set of Resource definitions.
I've been working on the HL7 version 3 standard for about 10 years - but based on experiences gained during consultancy projects with implementers, and based on experiences of implementers as detailed during presentations in the HL7 RIMBAA Workgroup, I see no other way forward for HL7 v3 then to embark on a renovation project.



  • "Step #1 probably isn't sufficient" - well, it probably isn't, but it would already make life as an implementer a lot easier.
  • FWIW, one of Barry Smith's HL7 Watch blogposts refers to this one.

PermaLink to this page: http://www.ringholm.com/column/Renovate_HL7_v3.htm

Index of columns:

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.
Rene's Column (English) Rene is the Tutor-in-chief of Ringholm.