Using XSD 1.1 with HL7 as a Schematron replacement

Several years ago, I posted an article on IBM developerWorks about using OASIS CAM and David Webber's CAM Processor tooling to extend HL7 v3 schemas to better handle the extra conformance levels required by the HL7 RIM, particularly dealing with null flavors. At that time, CAM Processor was relatively new, and CAM is now reaching a very good level of maturity in the NIEM community; however, I suspect that HL7 specifications will always be more demanding than NIEM, in part due to the complexities of the RIM. The best alternative has always proven to be XSD 1.0 + ISO Schematron. At the time, I had considered using XSD 1.1, which provides assertions, but at the time, XSD 1.1 was still in development, and the CAM tooling just worked.

Recently however, it dawned on me that XSD 1.1 is now a W3C Recommend, and it has evolved, much like CAM, to include features that originated in Schematron. Actually these ideas didn't originate in Schematron, but that's another story.

As opposed to OASIS CAM, which really combines the core strengths from Examplotron and Schematron - using a reduced instance XML instead of a hierarchical grammar, and using XPath to define assertions - XSD 1.1 retains the hierarchical grammar, adding Schematron-like assertions to the extension/restriction process which is already built into XSD. So, to test data-type assertions on an element, you restrict the type definition for the element; to test conformance assertions on an element, you extend the type of the element to include any necessary assertions.

For example, in the HL7 RIM, an element can be Optional, Required or Mandatory - with an extra level, Populated, in some realms. For Optional, Required or Populated elements, a nullFlavor attribute is permitted in place of absent valued information, to describe why the information was absent. The phrase null flavor is confusing, but really it's just a reason why the information is absent. For Mandatory elements the nullFlavor attribute is forbidden.

In an existing XSD schema, you can determine which elements are Mandatory because they have minOccurs which is greater than 0, and isMandatory is true [ed. this has been edited]:

<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
            <mif:annotations>
                <mif:appInfo>
                    <mif:mapping sourceName="Sample">
                        <mif:text>
                            <mif:p>[MSH-11.1]</mif:p>
                        </mif:text>
                    </mif:mapping>
                </mif:appInfo>
            </mif:annotations>
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
</xs:element>

In order to add an assertion using the new features in XSD 1.1, we need to remove the type attribute from the element, and extend it as a complex type:

<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
                    . . .
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
   <xs:complexType>
      <xs:complexContent>
         <xs:extension base="CS.CA">
            <xs:assert test="not(@nullFlavor)"/>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType></xs:element>

If additional assertions are required, they can be added to the same extension; however, in this case, the only assertion we require is to ensure that the Mandatory element does not have a null flavor when we validate an instance message. All that remains now is to change our XML editor so that it is using Xerces 2.11.0 or higher, which supports XSD 1.1, and when we validate a message, we will be alerted if there is a processingCode element which is null flavored.