For people outside of healthcare what HL7 does with your data seems quite crazy -- and it is!

Eliot Muir, responding to a comment to a recent post on his own Interfaceware blog, makes a number of interesting points on the difference between what you can do with a database, and what you are allowed to do with what he calls 'traditional HL7' :

The biggest thing about interfacing is that one way or another you want to get ‘random access’ to 100% of the data contained in any given application.
    Your data – when you want, how you want it, where you want it.
    For hospitals that have IT systems that only offer HL7 interfaces, the smartest way to get data in and out of those things is usually to ignore the HL7 interfaces and just query their databases directly. That’s extremely common for many health care providers I know of – it’s far less complicated. The problem is that the HL7 interfaces often only give access to a subset of the data contained in the database of any given application.
    A second problem is the issue of coupling the data which is exposed to work flow events. i.e. admit, discharge, transfer etc. We’re so used to it in healthcare that it becomes second nature – we think that it’s normal to have to mirror data by always listening for events and faithfully recording the data – heaven forbid we should ever miss a message! Coupling data to events also leads to another headache with HL7 – so called ‘gap analysis’ where people pour over HL7 messages trying to determine for a given desired workflow sequence if a given message has the required data.
    For people outside of healthcare this all seems quite crazy – and it is!
    If I want to look up the demographics of a patient XYZ then I should just be able to query that information anytime I like. You can do that with a database – although that makes most application vendors squirm when you do that. Partly the reasons for that are legitimate technical concerns of violating the integrity of the application. Partly it’s for business reasons as alluded to above.
    ... I personally have no confidence that the IHE HL7 profiles will do anything of significance to improve actual integration outcomes in healthcare. It’s pretty crazy how much money has been put into IHE and how little it’s produced in terms of outcomes in real hospitals.
    I think there are several reasons for this. One reason is that version 2.X HL7 has the above flaws. IHE HL7 doesn’t fix the flaws – instead it erects a shrine to the whole thing and puts a bow on it.
    A second problem is that vendors cobble together all sorts of things with string and rubber bands to participate in the IHE connect-a-thons and then go back home and continue to sell the same systems they have been selling for years which don’t comply to the IHE profiles.
    A third problem is that IHE only tells us about things that committees have gotten together and agreed upon.   That tells us about the past – but it doesn’t tell us about the future. One of the privileges I have from running a company like INTERFACEWARE is that I get a fantastic view into the future of medical IT with respect to integration. I get to talk to dozens of start ups that are thinking of new imaginative ways to leverage the data we have already today to improve healthcare and reduce costs. For those startups RESTful APIs are a lot more convenient.
    Incidentally in the US in the physician practice EMR space over 80% of integration is done using web based APIs – HL7 is more or less dead in that space already – it’s just a few older legacy applications that still use traditional HL7.

Why FHIR will burn CDA

An interesting post with this title from Eliot Muir a friend of this blog. (See, for example, "The Rise and Fall of the RIM" from 2011.)

As Eliot points out:

CDA/CCD documents amalgamate lots of data together. There are too many data points. That makes these documents extremely impractical for solving real world integration problems. They tend to be very brittle and difficult to accomodate changes. It’s one of many reasons why the cost associated with using CDA/CCDs for integration are so high with a low return on investment. I have seen the blood in the field.

FIHR, in contrast, has a much better design and is much more modular  (A nice overview is here.) "The FHIR train has left the station.  It’s picking up speed and no one, not I, not the HL7 organization, nor even Grahame Grieve who invented the thing can stop it.  The concepts behind FHIR will have a life of their own. This train is going to be disruptive.  If you run an organization in healthcare you need to know about it. Your only choice at this time is to get on the train, or step in front of it."

We remain sceptical. First, FIHR is owned by HL7. Second, FIHR is still based on the RIM -- which is what caused all the problems in the first place.