Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Saturday, October 30, 2010

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:element name="realmCode" type="CS" minOccurs="0" maxOccurs="unbounded"/›
    ‹xs:element name="typeId" type="POCD_MT000040.InfrastructureRoot.typeId"
    ‹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: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"/›

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.


  1. Sounds good to me...

    -- des

  2. Hi Keith,

    UBL uses a different approach (which I like better). They produce an XSLT with each schema version, which removes unknown content. Then you can have 3-step processing on incoming xml:
    1. validate
    2. if not valid, remove unknown content with xslt
    3. validate again

    This allows for any kind of new content (also in HL7 namespace) at any location. Don't know off-hand if this would work for HL7 schemas (seems a lot of work), but seems worth considering.


  3. Actually, the stylesheet is about 10 lines long, and is not a lot of work, just an extra process in a pipeline that could be processing hundreds of thousand or more documents or more a day in a national program. My proposal means that you could skip that extra step, which could save a lot of time in high throughput environments.