This question came up on the HL7 mailing lists recently so I thought I would give a business perspective on it. I would say that less than 0.5% of the market implements the XML encoding of HL7 2.X in XML. I gave some of my perspective already with my article on why a JSON encoding of HL7 2.X is not a great idea.
There are two business cases I know of for which it makes excellent sense to implement the XML encoding of HL7 2.X.
- If you are large medical software vendor that wants to shut out your competition by making integration difficult, yet you need to maintain the appearance of being open and HL7 compliant then only supporting the HL7 2.X XML encoding is a brilliant idea. I would suggest you go the whole hog and do the ACKnowledgements in XML and exploit any ambiguity you can find in the HL7 standard too since that will make it particularly hard for your competitors.
- If you are a small medical software vendor that has no choice but to try and integrate with the 800 pound gorilla from point 1 then you may have no choice but to implement support for the XML encoding of HL7 2.X. Suck up the cost – that’s what it takes to compete with the big boys.
If you are a health care provider that merely sees interoperability as a cost then it probably is better to discourage vendors from only supporting the XML encoding of 2.X HL7. For you the only impact will be to increase costs and reduce your choice of available solutions since you already will need to be spending money interfacing with the traditional format of HL7.
Either way if you are using Iguana you’re good – it’s quite easy to support both traditional HL7 2.x and the XML variants. We’ve supported the XML encoding of HL7 2.X since the first version came out and the Translator is even better since it parses XML natively.