The Rise and Fall of HL7

Interfaceware is a Toronto-based HL7 solutions provider whose customers include the CDC, Cerner, GE Medical Systems, IBM, Johns Hopkins Medical, the Mayo Foundation, MD Anderson Cancer Center, Mount Sinai Hospital, Partners Healthcare Systems, Philips, Quest Diagnostics,  the VA, and Welch Allyn.

At 2.57pm EDT today, March 31, 2011 -- on what will surely prove to be a historic day in the advance of healthcare information technology in the direction of reason and light -- Eliot Muir, founder and CEO of Interfaceware, posted the following comment, which I here reproduce in full:

The Rise and Fall of HL7

The title of this post might seem unusual might seem an unusual comment 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.

1. 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.
2. The EDI format of HL7 with it's classic | and ^ separators meant vendors could write standard HL7 parsers.
3. 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:

1. 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.
2. There is substantial academic criticism of RIM that points to the semantic inconsistency within the model itself.
3. It is creating complicated standards which are expensive to implement.

The only organisations 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:

1. HTTPS with authentication is analogous to LLP - only it comes with authentication and security baked in.
2. JSON - the simplest format imaginable with free parsers in every language and environment, including Javascript which is strategic as the language of the web.
3. JSON data names and values give good suggestions on places to look for data.

Hmmm. Notice something? The value is more than 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. 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




Update April 5, 2011


A new comment on "The Rise and Fall of HL7" has appeared at http://blog.interfaceware.com/hl7/the-rise-and-fall-of-hl7/ responding to Elliot's assertion to the effect that "The only organisations spending money on v3 are governments and some big corporations like Oracle":

Rik Smithies

APRIL 5, 2011 AT 10:07 AM

Eliot,

plenty of companies apart from Oracle are “spending money” on the V3 RIM. Here are just a few that are basing their strategy on it (and not just their interfaces):

http://wiki.hl7.org/index.php?title=Category:RIMBAA

Rik

As one might respond: this means that after more than ten years there are some 22 companies with RIM-based products. Are any of these products particularly impressive in nature? Have they demonstrated some exceptional power of the RIM?

An Australian View on HL7 V3

The Australian Health Information Technology blog has posted here a valuable discussion of the item headed Cries for Help published earlier in these pages. This discussion is interesting not least because of the large number of contributions it contains which -- unusually -- are signed by their authors. It seems that, in Australia at least, there are individuals who are willing to commit themselves publicly to a critical position as concerns the HL7 project (where the vast majority of my US informants are willing to have their views communicated only anonymously).

As David More points out in his introduction to the discussion, the implementation success of V3 thus far (and this means after some 14 years of development work) "has been somewhat patchy, with at least some proponents scaling back their enthusiasm for full adoption of the V3 Standard as some see it is lacking the necessary robustness and internal consistency for ongoing use." Dr More goes on to point out that, "While I am not sufficiently across the details of some of this to be able to form a trustworthy opinion a number of very smart people I have chatted with have expressed similar concerns."

In a comment, Grahame Grieve writes on behalf of HL7:

There's no reason for anyone to be afraid to comment. HL7 is not a police state, and there's an endless list of people who criticise and carp. They can expect a vigorous in kind response, but nothing more.

v3/RIM is not perfect. But it's not intended to be an ontology of everything. If only Barry would understand. It's just a model that has some use for interoperability. It's got some go-down-with-the ship type supporters, of course.

As does v2 (and all the other standards - they all have the folks who are going to go down with the ship). It's not enough to say it's simpler. There's more to it than that. The discussion is being had elsewhere, and here is not the place for it. HL7 continues to produce v2 (v2.7 is coming) but the community that is HL7 is switching to v3 because of it's power.

v3 itself does have a patchy record. I'm on record as saying that there won't be another full v3 implementation. People will cherry pick the parts that work - like CDA - and use them as they want.

I've got more to say but it's starting to rain and I'm out in the bush camping. Have a good weekend."

These remarks raise many interesting questions. Grahame asserts that commentators -- whom he divides into critics and carpers -- can expect nothing more than a "vigorous in kind response". Why, then, are so many people reluctant to use their names when commenting critically on HL7? I also fully understand that HL7 V3 is not intended to be an "ontology of everything". Indeed its scope is a tiny, tiny fraction even of the healthcare domain. The problem, as I see it, lies rather on the part of HL7's own advocates when they advance claims for example to the effect that HL7 is "the data standard for biomedical informatics". Such claims give rise in turn to multiple efforts to reinvent various well-functioning wheels in somewhat less-well-functioning proprietary versions inside the walls of HL7. Over time, in result, HL7 becomes ever more complicated, ever more difficult to teach, and ever more difficult to apply successfully. Raising the inevitable question: who benefits from such developments? The following remarks were sent to me by the Asian health IT specialist (henceforth 'S') who was the author of the Cries for Help which originally provoked Grahame's comments:

Grahame (henceforth: G): "v3/RIM is not perfect. But it's not intended to be a ontology of everything. If only Barry would understand. It's just a model that has some use for interoperability. It's got some go-down-with-the ship type supporters, of course."

It's just a model that has some use for interoperability -- That's pretty lame! When a patient's life is on the line "some use for interoperability" is not good enough. The system has to be 100% perfect. Imagine using "some interoperability" to loosely move data across hospitals with the possibility of data errors. The more complex and opaque a system, the more are the chances of errors.And this is simply because it could be almost impossible to detect the tiny but fatal coding flaw that could be hidden under tons of code, trying to helplessly interpret overly complex V3 rules.

G: "the community that is HL7 is switching to v3 because of it's power."

S: What power?!! V2.6 can actually do every thing that V3 does - only more elegantly, simply and transparently.

G: "I'm on record as saying that there won't be another full v3 implementation." 

S: So does that mean that V3 is dead, long live V2? 

G: "People will cherry pick the parts that work - like CDA - and use them as they want" 

S: Why is HL7 diluting it's focus? It's main aim was to create and encourage a messaging standard for interoperability. Than why create a CDA? Why hijack a perfectly good CCR? The way it is going, tomorrow they may think of creating an EMR, EHR and later a HIS all of course based on the RIM!

S continues as follows:

I say, Focus dear friends, focus. Make HL7 simple enough to be easily implementable. And make the HL7 standards more open/accessible. 

On accessibility, this is what I have to say. Have you seen the latest restrictions on use of the HL7 standards? They were restrictive in the past, it has now gotten worse. Today the standard is totally commercialized. You cannot use it to create a professional, usable, realworld (aka 'commercial') app till you pay the HL7 group with a pound of your flesh. You cannot teach HL7 to any one - ditto, share it with a colleague in your hospital? - ditto .

So how does one spread the message of interoperability far and wide, how does one advocate use of the HL7 standard world wide, how does one make hospitals share records, when at each step you are told to cough up money! 

So let HL7 frankly admit that it is in it for the money or go truly open and offer the standards to all like say, LOINC or ICD.

So, in conclusion, here is the true (no hidden agendas) mantra to making HL7 (V2x) a truly international standard.

1. Drop V3, simplify V2x and make it easily implementable

2. Make the HL7 standard truly open by offering it free for use.

Amen...

Readers of this blog are warmly recommended to read the further comments at Australian Health Information Technology, which are of interest especially as concerns the views expressed on the potential implications of HL7 standards for the Australian National E-Health Transition Authority.

Postscript: March 27, 2011

Graham Grieve posted a comment here parts of which are addressed to the above-mentioned A>sian healthcare specialist, specifically:

S: HL7 becomes ever more complicated, ever more difficult to teach, and ever more difficult to apply successfully.

G: Yes. These are all true, and concerning. But complexity is complex. As are committee designed standards. Name a standard that hasn't got more complex over time... 

S: That's pretty lame! When a patient's life is on the line "some use for interoperability" is not good enough

G: oh? Patient's lives are on the line? I'd never thought!

S: Imagine using "some interoperability" to loosely move data across hospitals with the possibility of data errors.

G: To be serious, it's hard to know how to respond to this. There's no context, no ground rules. As for this... "V2.6 can actually do every thing that V3 does - only more elegantly, simply and transparently" I can only assume that the "expert" hasn't implemented both CDA and v2. Perhaps not even read them. Or they have a very peculiar definition of "everything". 

S: Have you seen the latest restrictions on use of the HL7 standards? 

G: Errr, I've not heard that anything changed. What, specifically, has changed? I'm personally against charging for the standards, but developing standards is a costly business that has to be funded somehow. (Do I need to repeat for slow readers that I do *not* speak for HL7?) 

S: So in conclusion here is the true (no hidden agendas)... 

G: No hidden agendas? from an anonymous contributer? I don't even know why I'm bothering to respond.

S himself has now responded, as follows:

This is what I was afraid of ...I have deep respect for every individual who has worked on HL7(including Grahame), but what I have stated is based on 30 plus years of experience, both as a clinician and Healthcare informatician. Further, my knowledge, certification and work on HL7 over the last decade+ qualifies me, I think, to speak on this topic. This kind of blistering "who the hell do you think you are!" kind of a retort, including personal aspersions, are not conducive to scientific progress. If this is not a police state, then what is? This is the very reason for the cloak of anonymity. I have, very simply presented a point of view, and if one were in a responsible position, one should accept criticism and examination of how we could work at improving the usability of the standard.

Please convey to Mr. Grahame my respect for his point of view.I do assure all that I am just as eager as any HL7er to grow HL7 to be a highly usable standard (especially in a way that keeps costs under control. President Obama, I am sure, would appreciate this).I do hope HL7.org is also listening.Good bye. Over and out. End of transmission.

Two comments, received more or less simultaneously:

Dear "S",
Last I heard, police states involve imprisonment, torture and summary execution, whereas in free countries, we both say what we think. Which I do think is what is happening here. 
I'm sorry that you felt my comments were a blistering attack on yourself. I certainly was sarcastic. It's hard not to be, given the circumstances, but I will try hard not to from now on. I don't know how I could make personal aspersions regarding yourself, when I do not know who you are (though I expect that I know you). Now you claim 30+ years of experience, including a decade of HL7, but how could this have qualified your comments when made anonymously without even identifying that fact? You say my response was a "who the hell do you think you are?", when in fact, I want to know, "who are you?" 

Turning from that, I'm happy to work with you to accept criticism and examine how we could improve the standard. Where would you like to do that? Here, or at an HL7 meeting? Or somewhere else?
Grahame 

From S:

I can understand, and see, that Grahame is a true V3 loyalist (I respect that), but unfortunately to the degree that he is perhaps unable (or unwilling?) to look at its fundamental flaws. I really did not want to get into a slanging match with a respected colleague since I believe that is not right. End of the day, we both have strong beliefs - only in different directions. As a professional and a board certified clinician, I do believe that at such a juncture the right thing for gentlemen to do is to discuss and come to an agreement or respectfully agree to disagree.

Thank you Grahame for agreeing to listen to my critique:Here are a few issues that I have with the fundamentals of V3 messaging (CDA not included) vis-a-vis the V2.6 standard. I shall be happy if you can resolve my issues:

(1) One of the strong points of V3 is conformance. Why does V3 bring about 'Conformance' in an extremely opaque, convoluted and complex process (using multiple tools which are proprietary (some open source, some commercial)), when V2.6 can do the same with just use of the standards document and an ASCII editor?

(2) As a clinician I require my clinical message to be transferred accurately to the recipient. How does V3 do a better job as compared to V2.6? (Please do not bring in points like conformance, security, permissions, confidentiality and encryption, since all of this can easily be configured in V2.6)

(3) V3 XML vis-a-vis V2.6 XML is massive and convoluted. How is this better?

a) The human readable component is so deeply buried in the code that it requires super human effort to extract it manually (even for a small message) so is it really human readable? 

b) Coming to the next part, machine readable information - the effort required to human-engineer an application to ergonomically extract information from clinical data (as required by V3) puts a huge load on the end user (clinician). In fact there are studies that clearly show non-acceptance of HC IT apps by clinicians because of use of complex forms to input data in a way that is different from the normal flow of a clinician's writings. These are some of the problems that reduce acceptance of Healthcare IT apps by clinicians. Do you not think that by trying to make data machine readable for V3 you would be actually reducing adoption of HC IT apps by clinicians? End of day there are other methods by which data can be extracted from free flowing text for BI, CDSS and EBM (evidence based medicine). So why complicate?

(4) V2.6 can easily transport any kind of media with lower overheads as compared to V3. So why V3?  

(5) V2.6 can, from the end user point of view, transfer the same clinical content as robustly as V3. So why V3?  

(6) V2.6 messages can be coded by nothing more than Notepad and the standards document. Why this complex process in V3? Since in the end after all this goes through the grinder (Funnel the RIM to a DMIM (actors, story boards, acts, moods....) to a RMIM, CMETs yada, yada, yada, run it through automated tools) we are finally handed over ready message templates for each domain - as is present in V2x. This message (from the end user point of view) is nothing more than the equivalent of a ready made message from one of the chapters of the V2.6 standard (it is as as simple as simply selecting the appropriate V2.6 message from the standard and going ahead). So why would one waste time, effort and scarce manpower to do the same thing in a more complex way?

(7) Has a study been done on the cost overheads of V3 (in $ terms) vis-a-vis V2.6 (including conversion of data, maintaining of 2 standards, training, new apps,etc)? If so what is it and are the costs commensurate?

(8) What are the time overheads of changing over to V3 (in man days) vis-a-vis say, V2.5 to V2.6 (including training)?

(9) How much time does it take to train a productive HL7 analyst in V3 vis-a-vis V2.6? Is the time/cost commensurate? 

(10) I am sure you agree that the more the parts, the more are the chances of a breakdown (or error or worse still a SILENT error). Complexity, if it improves outcomes to the end user, would be worth the risk. But how does V3, realistically, improve outcomes for the enduser (as compared to V2.6)?

(11) Do you think it would be a good idea to wrap up all the RIM based complexity into a black box (only to be handled by the WGs) and simply present ready message templates to the end user in the form of a 'V3Simplified' Standards Document, something similar to a V2x document? (This is, in any case, gradually happening.) These messages could be mapped to V2x messages for easy portability.

Grahame provides his responses here:
                   http://www.healthintersections.com.au/?p=33

NCI Report on caBIG

Just released:

AN ASSESSMENT OF THE IMPACT OF THE
NCI CANCER BIOMEDICAL INFORMATICS GRID

Report of the NCI Board of Scientific Advisors Ad Hoc Working Group

See: http://cancerletter.com/downloads/20110304_2/download

There is much that is of interest in this document, which does not however get to the heart of the reasons for the technical failures of so much of the caBIG software. About which more anon.

Update April 12, 2011

See now also here.