Contact Support
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.
alright. comments:
1. We are paying attention
2. I don’t think it’s “the answer” either. But it might be a useful thing.
3. I’m glad you’ve seen interfaces in the wild using v2.xml
4. I guess I figured it might cost less money for new entrants – they
can avoid the parsing step and just get it for free from JSON.
Wouldn’t that be good? (I guess the counter to this is that most
significant platforms have good solid free/open parsers already)
In this case the vendor has over 32,000 employees and is one of the 800 pound gorillas in the industry. They aren’t exactly a new entrant. They are a customer in some areas so I won’t mention them by name.
By doing things non-standardly (even though it was endorsed by HL7) it creates a new hurdle to be dealt with by counter parties that already had the capacity to deal with standard HL7 but not this variant of it. It just imposes more costs on those counter parties while giving them no additional value.
All –
I would concur. It can be done, you’ll run into some interesting problems, but it will not solve real world issues.
JSON is especially effective and useful in environments that are operating within a JavaScript interpreter environment, i.e. mostly browsers and similar user-facing agents. If I am not completely mistaken, HL7 v2 messages will rarely be displayed unprocessed within a browser, so the case for JSON is IMHO weak.
It would make a lot more sense to explore the use of JSON in the context of Robert’s work, especially when exchanging “exchangable goods” for direct user consumption.
Best,
Gerry
Eliot, Grahame
I agree with the argument that the cost/benefit needs to be carefully
weighed in light of the v2.xml experience — though I suggest that an
informative document that included the arguments for just using v2 out
of the box, but provided a json serialisation for those that really
wanted it would be justified. Using the HL7 consensus process to
endorse such a discussion document with or without the serialisation
may well save the industry money.
I suspect that Eliot is right that the most cost effective approach is
to say that if you are willing to use V2 lexical structures, then it
would be cheaper and easier to use the V2 serialisation in almost all
situations. That appears to be the decision that the market has taken
wrt v2.xml.
However – having a V2.json and a V2.xml spec for those that have
political/commercial/religious reasons that justify being a transform
away from the bulk of the v2 installed base will probably help the
industry to contain costs – even more so if the documents include a
discussion of these issues. When I say “the bulk of the V2 installed
base” I am aware that this installed base is a mat of systems and
local interface specifications that are localisations based on the
HL7v2 specifications.
These questions are a permathread in the XML ITS work group – as is
the suggestion that there cannot be a single fixed language for
healthcare, so HL7 adds no value by trying to standardise semantics in
a scalable way in V3. I agree that HL7 v3 is not the final answer.
However I have found mapping to the V3 RIM and derived models has
exposed ambiguities and mis-matched assumptions that would have taken
much longer to resolve if they came up in testing or later had an
isolated homegrown “Domain Specific Language” local schema been used.
So my view now is that mapping to the RIM and to standardised domain
analysis models adds value – but we need better decentralised ways to
do this and to establish and show where standardising semantics does
add value – and where standardising the mapped Domain Specific
Languages would add value.
I think that there is much more to be done for and by the healthcare
community to make standards and specifications that are easy to
implement and that have attractive configuration management — and
that will involve the HL7 community and HL7 standards, as well as
json, x12, linked data, and whatever other knowledge and information
management tools and frameworks emerge within and beyond healthcare.
I agree with Gerald (whose email I have just seen) – that json fits
most obviously in the microITS / greenCDA / mapped interface space -
rather than as a direct serialisation of the HL7v2 or HL7v3 structures
all the best
Charlie
When we develop standards, I think we also need to take into consideration these stakeholders
1) Commercial vendors who will develop and market the standards compliant products. So XML encoded HL7v2 message falls into this category, it helps HL7v2 MLLP gateway to easily integrate with SOA product using XML technology, as a result commercial vendors has implemented such capability to support XML encoding of HL7v2 message.
2) Developer communities who make uses of the standards for application development. JSON representation of CDA will fall into this category, it really helps developers implement more lightweight Web 2.0 applications to show human oriented document.
JSON representation of HL7v2 message does not seem fall into any of the above two categories since HL7v2 message is not really meant for direct human consumption, also from commercial vendors perspective, there does not seem any need to implement HL7v2 json.
Rgds
Victor Chai
Since interoperability is the primary purpose of messaging protocols such as HL7 creating a proprietary message format is self defeating. One can introduce a new format as long as you maintain the standard for backwards compatibility should it be needed. One can also perhaps leverage SOA and XML by wrapping the HL7 message in XML instead of changing the actual standard which causes more problems downstream.
There is a Dilbert for everything including this: http://dilbert.com/strips/comic/2010-11-25/