In an earlier post Mark reviewed some proposed requirements for the syntax of FHIR extensions and how the previously considered alternatives align with those goals. In this post I’m going to describe an additional alternative that I’d like to submit for consideration. I’m going to focus on the XML syntax in this post but a subsequent post will address the JSON representation.

As a reminder here is an example of the current syntax extracted from the example used in Grahame’s original request for feedback:

<Patient xmlns="http://hl7.org/fhir">
  <id value="patient-example"/>
  ...
  <extension url="http://hl7.org/fhir/StructureDefinition/patient-clinicalTrial">
    <extension url="clinicalTrialNCT">
      <valueString value="NCT01647425"/>
    </extension>
    <extension url="clinicalTrialPeriod">
      <valuePeriod>
        <start value="2012-04-01"/>
        <end value="2013-09-30"/>
      </valuePeriod>
    </extension>
    <extension url="clinicalTrialReason">
      <valueCodeableConcept>
        <coding>
          <system value="http://snomed.info/sct"/>
          <code value="254637007"/>
          <display value="NSCLC - Non-small cell lung cancer"/>
        </coding>
      </valueCodeableConcept>
    </extension>
  </extension>
  ...
</Patient>

Here’s the proposed alternative:

<Patient
    xmlns="http://hl7.org/fhir"
    xmlns:fhir="http://hl7.org/fhir">
  <id value="patient-example"/>
  ...
  <ct:clinicalTrial
      xmlns:ct="http://hl7.org/fhir/StructureDefinition/patient-clinicalTrial"
      fhir:isModifier="false">
    <ct:NCT>
      <valueString value="NCT01647425"/>
    </ct:NCT>
    <ct:Period>
      <valuePeriod>
        <start value="2012-04-01"/>
        <end value="2013-09-30"/>
      </valuePeriod>
    </ct:Period>
    <ct:Reason>
      <valueCodeableConcept>
        <coding>
          <system value="http://snomed.info/sct"/>
          <code value="254637007"/>
          <display value="NSCLC - Non-small cell lung cancer"/>
        </coding>
      </valueCodeableConcept>
    </ct:Reason>
  </ct:clinicalTrial>
  ...
</Patient>

How this would work:

• The FHIR schema would include wildcards at appropriate points that allow extension elements from other namespaces with lax validation.
• FHIR extensions would still be defined via a StructureDefinition but would also optionally be defined via an XML schema to permit standard XML schema validation of both the base resource and the extension.
• The FHIR schema would define a boolean attribute, isModifier or something similar, that can be included on the root element of extensions to flag those that modify the semantics of the parent.

At this point you may be thinking “this is all well and good for XML, where namespaces are natively supported, but what about JSON?” No worries, we’ll cover that in a subsequent post.

How does this use of XML Schema differ with the goals stated in the XML Schema section of the FHIR specification?

• Unlike the current syntax, processors may encounter unknown extension elements while parsing. However, the location of such elements is defined as part of the schema and the value of the isModifier attribute would allow a processor to determine if the unknown content can be safely ignored.
• The FHIR schema would not include the structure of extensions. However the current extension structure (essentially a map of names as URIs to either nested extensions or FHIR-defined types) provides minimal value to processors.
• Code generation still works, tools like JAXB have no problem with XML schemas that include extensions defined elsewhere.

Finally, how does this approach line up with the requirements outlined earlier?

1. Supports distributed extensibility: Yes, anybody can define an extension in their own URI-defined namespace
2. Explicitly identifies modifying extensions: Yes via the FHIR-defined isModifier attribute
3. Includes extension URI: Yes, as the value of the XML namespace attribute
4. Parsing without reference to definition: Yes, use of XML schema wildcard with lax validation
5. Links to StructureDefinition: Yes, as the value of the XML namespace attribute (and links to any applicable profiles in metadata)
6. Improved readability: Yes, use local namespaced names for elements rather than everything being an extension
7. Leverages existing standards: Yes, XML namespaces and XML schema
8. Leverages validation standards: Yes, XML schema
9. Treats extensions and core elements equivalently: Yes, with the exception that extensions must be defined in a different XML namespace to the FHIR core