A proposal for HL7 XML Extensibility

I'm in the process of finishing the CDA Book, and was writing the chapter on extensions.  As I was writing it, the following idea came up.

The HL7 XML Implementation Technology Specification, or ITS, defines how HL7 message elements are to be sent using XML.  Section 2.5 of the XML ITS: XML Structures (Release 1) specification allows for the include of extension elements.  The only real requirement is that they come from a namespace other than urn:hl7-org:v3.

As part of the best practices for CDA templates created by the Structured Documents Workgroup, we determined that:

1. All CDA extensions should be RIM derived, and
2. They should be placed where they would have been placed had the CDA standard included that RIM attribute.

This is a nice idea, but has some  unfortunate consequences when validating CDA content that contains extensions.  Each possible extension can appear in a different place in the CDA schema, and it becomes nearly impossible to modify the CDA schema to support validation of  CDA containing extensions. 

I propose a new rule:  All extension elements must appear after all content defined by the standard. This rule has a great benefit.  Take a look at the following revised definition for POCD_MT000040.ObservationRange for CDA Release 2:

‹xs:complexType name="POCD_MT000040.ObservationRange"›

  ‹xs:sequence›

    ‹xs:element name="realmCode" type="CS" minOccurs="0" maxOccurs="unbounded"/›

    ‹xs:element name="typeId" type="POCD_MT000040.InfrastructureRoot.typeId"

                minOccurs="0"/›

    ‹xs:element name="templateId" type="II" minOccurs="0" maxOccurs="unbounded"/›

    ‹xs:element name="code" type="CD" minOccurs="0"/›

    ‹xs:element name="text" type="ED" minOccurs="0"/›

    ‹xs:element name="value" type="ANY" minOccurs="0"/›

    ‹xs:element name="interpretationCode" type="CE" minOccurs="0"/›

    ‹xs:any namespace="##other" processContents="skip"

  minOccurs="0" maxOccurs="unbounded"›

  ‹/xs:sequence›

  ‹xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/›

  ‹xs:attribute name="classCode" type="ActClassObservation" 

    use="optional" default="OBS"/›

  ‹xs:attribute name="moodCode" type="ActMood" use="optional" fixed="EVN.CRT"/›

  ‹xs:anyAttribute namespace="##other"/›

‹/xs:complexType›

This schema supports extension following that rule, and furthermore, the HL7 tooling can be modified to easily add these statements to any existing schema.  Thus, we can, with the addition of this rule, have our XML extensions, and validate the message too.