It is interesting that so many people are keen to rubbish the encoding of HL7 V2 data. “It old and outdated” is a common comment. After a serious amount of time playing with it and experimenting with many encodings I am now convinced its brilliant.
The “xml will solve everything” mantra is fading as people realise its inefficient, and bloated and in my experimentation it works, but really offers few advantages. I use and like JSON and this is a no brainer when working with javascript. I have recently also been playing with erlang term encoding. This is used heavily in some pretty impressive scalable applications.
I have now converted clinical data into all three formats and it has made me realise the absolute brilliance of HL7 V2 encoding. Bloat with xml is a scalability issue, and the DOM structure holds up processing data as a stream, although this is not a serious issue. The human readability aspects of it is a joke. If you are going to process medical data then having it humanly readable is the last priority, especially as humans are so fallible. It is also not backward or forward compatible and no easy mechanisms exist to overcome these issues. In contrast HL7 V2 encoding, when parsed according to the rules, allows great flexibility. A field can be made repeating, or, eg. expanded from a simple string (IS) to a coded value with good backward and forward compatibility. The lack of field names is not an issue as the computer knows where the data should be. It reduces bloat significantly. It is also possible to process the data as a stream as you don’t have to wait for a closing tag. Absent values can just be omitted, further saving space. New values can be appended to the data types or segments without breaking parsers.
JSON is much better than xml, but still bloats because of field names and changing a string into an object causes significant issues. Erlang terms omit the field names, but require absent values to be encoded as blank and are inflexible when new fields are appended, making backward and forward compatibility problematic.
While free of off the shelf parsers are available for the other formats I think this up front advantage quickly fades once the other issues appear. HL7 V2 encoding does at first seem old hat, but it was developed in an age when most people in the industry were computer science gurus as the resources available were so limited, and things had to be efficient to actually run. After actually implementing transforms into the common alternatives and realising that these formats are likely to cause problems when version changes appear I have a new respect for the HL7 V2 encoding. I suspect the critics have not really used it in anger, as it just keeps on keeping on. xml might be great for a quick and dirty data exchange format where efficiency is not high on the list. Its also essential when astronaut architects are at the helm! JSON is very efficient talking to a html/javascript front end. However for the core backbone of health messaging that has to cope with multiple version of data and be efficient and not consume vast quantities of disc space I still think that well implemented HL7 V2 is simply brilliant. Despite being the poor cousin of the modern formats, its position as the most used medical messaging format does not surprise me. The tortoise might yet win the race!