Healthcare Interoperability Blog

interfaceware.com
  • Iguana Integration Engine
  • Resource Center
  • Blog
Home Version 2 HL7 in JSON is not the answer

Version 2 HL7 in JSON is not the answer

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.Why You Need A Modern Integration Engine

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.


Why You Need A Modern Integration Engine

Apr 2, 2011Eliot
  • Email
  • LinkedIn
  • More
  • Facebook
  • Twitter

Related

The Rise and Fall of HL7My Dad Mervyn Muir - A pioneer meta integration engineer
April 2, 2011 HL7
Enjoying this blog?

Sign up to receive healthcare integration news, just like this, from iNTERFACEWARE Inc.

iNTERFACEWARE needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Privacy Policy.

Resources

Integration Resources & Guides

HL7 Resources

Iguana Case Studies

Iguana Integration Engine

Overview: Integration Engine

Features: Building HL7 Interfaces

Benefits: Why Choose Iguana

Company

About Us

Integration Services

Contact Us

Connect

LinkedIn

Twitter

YouTube

© - iNTERFACEWARE Inc.
loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.