This is part of series of posts looking in depth at the conceptual issues with HL7 2.x.
Level Seven in Health Level Seven (HL7) stands for the “Application Layer” of the Open Systems Interconnection Model (OSI). HL7 was founded with the idea that the protocol should agnostic about all the levels below the application layer such as presentation, session and transport layers.
The world is different from when the OSI was started in the seventies out of fear that big blue would control everything. Today with the triumph of internet with TCP/IP those fears are gone. Most standards organizations have moved past it. TCP/IP internet protocols are not rigidly designed into the strict layers of the OSI model. See RFC3439 which has a section layering considered harmful.
It’s easy to understand the appeal of the OSI model to the early pioneers of HL7. HL7 was started before the internet was as predominant as it is today. Many of the proprietary interfaces at the time were being sent via batch interfaces, serial link etc. Making HL7 only about the application layer in the OSI made it easier to get consensus between the vendors to support the new standard.
However as I argued in my rise and fall of HL7 article, in fact one of the most practical advantages of HL7 was in the manner it created the defacto LLP protocol. Suddenly to integrate you didn’t have to worry about writing custom low level socket or serial link code to get the data across the wire. It was one of the most compelling parts of the HL7 standard and yet it doesn’t get official recognition. I think we should have posthumous medal awarded to the humble LLP protocol for all it’s contribution to healthcare interoperability.
The OSI cultural history is a problem for HL7.
The issue is that people involved in the HL7 community feel compelled to manifest the holy ghost of HL7 in every new protocol vessel that comes along.
It’s led to some very bad standards that might have sounded good on paper but in practice were terrible ideas.
For instance in the late 90’s when ActiveX/COM/DCOM/CORBA were all the rage there was an effort to make a COM/CORBA version of HL7. Microsoft contributed a little bit to the effort and a few other enthusiasts and big companies got involved.
The idea was that you could generate out COM/CORBA apis based on the HL7 data model. But it was totally impractical. With the variability of HL7 it meant that to integrate vendors using these interfaces would have to regenerate stub code for each flavour of HL7 and then write new custom code in VB/C++/Java to get the data. It was not a standard that met the goals of saving or making money so it was no surprise that the effort went no where. I was surprised it didn’t die earlier.
The next time the OSI concept bit us in the proverbial was when HL7 decided to make an official encoding of HL7 version 2.X within XML (links to the old version 4 manual). That was just another bad idea. It has caused more damage than the COM/CORBA apis. At least with the COM/CORBA concept was so awful it didn’t get traction. But unfortunately the XML encoding of HL7 2.X was only slightly awful. Not awful enough to stop some big vendors from actually picking it up, implement and keep using it today.
That that creates pain for the counter-parties that have to interoperate with those vendors because as I pointed out in my post HL7 2 in JSON is not the answer they have to muck around doing additional work to handle this different flavour of HL7 with no added value. That hurts what I would argue is almost the only real value of HL7 was that you can use a standard parser to process HL7 data. By approving additional encodings, it diminishes the value of HL7.
Version 3.0 HL7 based on the RIM is taking the whole application layer thing to it’s nonsensical conclusion by attempting to have it’s own modelling tools to avoid being locked into any other technology. This is not helpful. Standards are more useful when there is less variability rather than more.
It’s time to stop being agnostic. HL7 version 2 was successful because through it’s format and the defacto LLP protocol it:
- Provided a standard way to handle the levels below level 7.
- Using a very simple approach.
HL7 could be a successful part of the future of healthcare interoperability again. The goal is to pick another standard and simple approach to handling the levels below 7
- Which means – endorse one standard way of handling the layers below level 7.
- Make sure that it is intrinsically simple in it’s own right – not just because you can get a some library which makes it easy to implement a complicated protocol. See SOAP is an oxymoron.
In todays world a good choice would be HTTPS with either XML or even better JSON over the top. Yes it might not be good in 20 years time. But it should be a good choice for the next ten years which is just fine for it’s purpose.
An intelligent way to validate that the approach is truly simple would be to construct a reference implementation in C – from scratch. No cheating using .NET or J2EE libraries – about the only library that should be used would be the openssl library since at this stage that is the defacto standard for SSL/TTS which everyone uses – SSL/TTS is too complicated to implement from scratch but it has become the standard for security. All the other parts like HTTP and JSON parsing are easy to implement by a capable programmer.
But picking this new standard simple approach is not enough.
You see I think it’s a huge misconception to think that level 7 is independent and agnostic about the lower levels it rides on.
Because HL7 has typically been sent over LLP in a broadcast mode it has distinctly shaped the protocol in certain ways. Namely it is:
- Not orthogonal.
- Highly coupled
- Has no good consideration of error messages
- Lacks role based authentication
If you change the foundation that healthcare interoperability protocols sit on and alter the cultural assumptions of the past then the resulting protocol should look very different.
My next article addresses the concept of orthogonality.
Eliot Muir – CEO of iNTERFACEWARE