The title of this post might seem unusual from what is supposed to be an HL7 middleware vendor. But times are changing and that is not where I see our future.
Standards do not exist in a vacuum. To be successful standards must address market needs and solve real problems so people can make or save money.
Writing code costs money. Less than 0.01% of code gets written for free. The majority of code is written by people that are being paid to solve problems with it.
There are plenty of standards which are not worth the paper they are printed on because are are not sufficiently useful or practical.
Complicated standards can be pushed for a while but ultimately markets reject them. Even governments will ultimately reject complicated standards, through a democratic correction process. Although they usually waste a fair amount of other people’s money along the way.
So back to HL7. Why was it successful?
Version 2.X of HL7 solved a very big problem for many people in healthcare IT back in the 90’s. It replaced a lot of adhoc data sharing mechanisms used in the industry at the time. It gave three points of value. Ironically the first point is one which is not even an official part of the standard.
The so called “defacto LLP standard” defined a uniform way to transport HL7 over a TCP/IP socket – this meant vendors could write standard socket implementations to exchange data.- The EDI format of HL7 with it’s classic | and ^ separators meant vendors could write standard HL7 parsers.
- The HL7 definitions gave some good suggestions on places to look for data.
And that is where the value stops.
It is a lie when a vendor tries to claim they are “HL7 compliant”.
The term is meaningless.
The best any vendor can ever do is provide a stream of messages with fields that map adequately to most of the data from their application. HL7 interfaces always end up being a thin wrapper around the structure of the database of the application which feeds them. The standardization comes about because there are common ways of structuring a lot of the data. The pain comes from areas where it is unclear how to structure the data.
There are good reasons for the lack of “standard data models”. Technology and society change which means data models must also be changed to best describe new data requirements. Medicine changes. New entrepreneurs come up with clever new solutions and invent ways of using data that improves on old models.
HL7 is working on creating the final solution for healthcare interoperability – the Reference Information Model (RIM) which underlies the structure of version 3 (v3) of HL7.
I think that effort is doomed to fail for these reasons:
- There is no such thing a single optimal data model to serve all purposes. A formal data model is always going be a square peg going into a round hole. Some problems are best solved by small simple models. There are approximations which work for certain problems but are not valid for others. If there was a single solution to everything then one person would invent it and the rest of us would be out of work.
- There is substantial academic criticism of the RIM that point to the semantic inconsistency within the model itself.
- It is creating complicated standards which are expensive to implement.
The only organizations spending money on v3 are governments and some big corporations like Oracle that based their health care transaction base (HTB) on it. Oracle salespeople can sell ice to Eskimos but I have not heard a lot of great success stories for that product.
Now let us fast forward to what I think will become the future. JSON based web services over HTTPS. Let us look at the benefits:
- HTTPS with authentication is analogous to LLP – only it comes with authentication and security baked in.
- JSON – the simplest format imaginable with free parsers in every language and environment, including Javascript which is strategic as the language of the web.
- JSON data names and values give good suggestions on places to look for data.
Hmmm. Notice something? The value is just what HL7 offers. In fact a lot more since these are very mainstream technologies that extend far beyond just the healthcare market.
That is why I am not betting the future of my company on HL7. Our value was never really as an HL7 implementation tool. The value our tools provide is the wiggle room we provide for our customers to handle the incompatibilities that occur with real world data. I do not plan to be positioned as an “HL7 company” for much longer.
The Iguana Translator is all about making it easy to grab data from anywhere – be it HL7, X12, XML, JSON, databases or web services and making it easy to munch, transform and consume that data.
That is the future I am betting on.
Eliot Muir – CEO of iNTERFACEWARE
Additional Resources:
