Oh dear.
I didn’t really expect the rise and fall of HL7 to go viral. Now it seems I’m about to go down in history as the guy who said HL7 should be done in JSON.
Oops.
I do not actually think re-encoding version 2 HL7 in JSON is a good idea.
Oh technically it’s quite doable. Probably could do it in a dozen lines of code with the translator It would not be hard.
But would it improve the state of interoperability in healthcare?
What value would it create?
It got me thinking about the encoding of version 2 HL7 in XML. I did make a buck or two out of that. So I guess it achieved some wealth transfer from healthcare to middleware vendors. But I don’t think it did much for interoperability.
It got me thinking of Bob who has been wrestling with an interface where a vendor had chosen the XML encoding of HL7 instead of using the classic | and ^ encoding.
HL7 version 2 is what it is. It’s ubiquitous. It’s known. It’s often the only way to get data in and out of many healthcare IT systems.
But just because everyone had FAX machines hasn’t stopped email from superseding the use of most FAXes. Nothing goes away. I have friends my age that work with COBOL. But there are less new COBOL projects. Metcalfe’s law only goes so far.
Putting version 2 HL7 in any different kind of encoding is not going to work any better than:
- Porting windows to run on ARM based tablet computers
- Word Perfect making the shift from DOS to Windows
When platforms and paradigms shift it’s important to re-examine your core assumptions. Remember the joke about the guy who always cut his pot roast in half? That’s why when I re-invented our mapping technology for the web platform I did not simply port over Chameleon over. The solution needed to change with the new market.
HL7 2.x has a lot of implicit assumptions and problems that would not make sense to carry forward into the all pervasive, always connected model of the web. There are opportunities here to make something simpler, more elegant and powerful. Compromises that had to be made with HL7 2.x are not necessary now.
For new standards to really succeed and gain traction they have to solve problems that HL7 today does not solve. They need to make more money or save more money than HL7 2.x.
Putting HL7 V2 into JSON or any other non classical format has no added value.
It will only cost more money. Therefore it is not a good idea.
I have a lot more to say. But right now it’s late and I have a lot to do. Keep listening.
