The XML encoding of HL7 has some backward compatibility issues. In some ways it's more awkward than traditional HL7 2.X, as far as backward compatibility is concerned.

The nature of the official XML encoding of HL7 is that the DTDs you would produce from the HL7 2.X grammars of 2.1, 2.2, 2.3, 2.3.1, and 2.4 are not backwards compatible.

The official schema for determining the DTD to use to express HL7 in XML, depends closely on the segment grammar and the field definitions of each field in each segment. This means that each DTD for each version of HL7 is incompatible. For example, consider the patient ID field. Under an early version of HL7, the field would come out like:

<PID.3>
   1244356
</PID.3>

Under the newer version of HL7 the field would come out like:

<PID.3>
   <CX.1>1244356<CX.1>
</PID.3>

XML encoding of HL7 actually loses one of the useful attributes of the older style of encoding HL7. By the book, if you have an XML parser set up to read the 2.4 XML encoding of HL7, it will reject a message which has been encoded using the 2.1 XML encoding of HL7. This is not a good design in our opinion.

However, all is not lost. Because of the backwardly compatible nature of traditional HL7, you can do this transformation:

2.2 XML encoded HL7 --> 2.2 HL7 2.X encoding --> 2.4 XML encoded HL7

Basically, if you're converting HL7 2.X into XML, as long as you use a DTD from a more recent version of HL7, i.e. HL7 2.Y where Y >= X , you'll be fine.

One more complication is that the XML encoding of HL7 makes site-specific custom Z-segments a bigger headache than before. The standard makes it necessary to generate a custom DTD which includes the site specific Z segments.

This might lead the more observant readers to note that this is one way that dealing with HL7 in XML format is actually somewhat harder than the older 2.X format.