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.