Thursday, June 21, 2012

Extending CDA for QRDA

One of the ballot comments I had made on QRDA was with respect to the mechanism that was being used to identify value sets which were being used inside a template.  We resolved that by pre-adopting the valueSet and valueSetVersion attributes as extensions to CDA which could be used with a QRDA submission.

I published an XSLT Stylesheet a couple of years ago that shows how you can remove all extensions to validate a CDA document against the normative schema.  I've updated it below to support use of the xsi:type attribute, which is often needed in observation/value to indicate the type used

<?xml version="1.0" encoding="UTF-8"?>

  <xsl:template match='cda:*'>
      <xsl:apply-templates select='@*|@xsi:type'/>  
      <xsl:apply-templates select='cda:*'/>  

As part of our discussion, we also agreed to publish a revised CDA schema with QRDA that would include not just this, but also any CCDA extensions used in QRDA, to enable others to use these schemas to validate instances.

The Consolidated CDA defined the a number of extensions in the urn:hl7-org:sdtc namespace.  These extensions are the same as were defined in the HITSP C83 specification.  NIST provides a modified CDA Schema on their downloads page that supports many of these extensions (see the second link on that page).

ExtensionWhere AllowedPurpose
sdtc:raceCodeAfter patient/raceCodeThe raceCode extension allows for multiple races to be reported for a patient.
sdtc:idAt the top of relatedSubject/subjectThe id extension in the family history organizer on the related subject allows for unique identificiation of the family member(s).
sdtc:deceasedIndAfter subject/birthTimeThe deceasedInd extension (= "true" or "false") in the family history organizer on the related subject is used inside to indicate if a family member is deceased.
sdtc:deceasedTimeAfter subject/sdtc:deceasedIndThe deceasedTime extension in the family history organizer on the related subject allows for reporting the date and time a family member died.
sdtc:birthTimeAfter associatedPerson/nameThe <sdtc:birthTime> element allows for the birth date of any person to be recorded. The purpose of this extension is to allow the recording of the subscriber or member of a health plan in cases where the health plan eligibility system has different information on file than the provider does for the patient.
sdtc:dischargeDispositionCodeAfter encounter/priorityCodeThe sdtc:dischargeDispositionCode element allows the provider to record a discharge disposition in an encounter activity.

These extensions affect four types defined in the CDA Schema :
POCD_MT000040.Patient, POCD_MT000040.SubjectPerson, POCD_MT000040.Person and POCD_MT000040.Encounter.

To incorporate these extensions into the CDA Schema, define a separate XSD file (e.g., extensions.xsd) as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="" xmlns="urn:hl7-org:sdtc"
    xmlns:sdtc="urn:hl7-org:sdtc" targetNamespace="urn:hl7-org:sdtc"
    xmlns:cda="urn:hl7-org:v3"  elementFormDefault="qualified">
   schemaLocation="POCD_MT000040.xsd" namespace="urn:hl7-org:v3"/>
 <xs:element name="raceCode" type="cda:CE" />
 <xs:element name="id" type="cda:II"/>
 <xs:element name="deceasedInd" type="cda:BL" />
 <xs:element name="deceasedTime" type="cda:TS" />
 <xs:element name="birthTime" type="cda:TS" />
 <xs:element name="dischargeDispositionCode" type="cda:CE"/>

In the CDA delivered POCD_MT000040.xsd, import the extension.xsd file in the appropriate place in the schema by adding this line after all other includes:
<xs:include schemaLocation="../../processable/coreschemas/datatypes.xsd"/>
<xs:include schemaLocation="../../processable/coreschemas/voc.xsd"/>
<xs:include schemaLocation="../../processable/coreschemas/NarrativeBlock.xsd"/>
<xs:import namespace="urn:hl7-org:sdtc" schemaLocation="extensions.xsd" />

Then add references to the extension elements in their appropriate locations.  For example, to support raceCode, make the following change to the POCD_MT000040.Patient type:

  <xs:element name="raceCode" type="CE" minOccurs="0"/>
  <xs:element ref="sdtc:raceCode" xmlns:sdtc="urn:hl7-org:sdtc" minOccurs="0"
      maxOccurs="unbounded" />

Similarly, for POCD_MT000040.SubjectPerson:

  <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 ref="sdtc:id" xmlns:sdtc="urn:hl7-org:sdtc" minOccurs="0"
      maxOccurs="unbounded" />
  <xs:element name="name" type="PN" minOccurs="0" maxOccurs="unbounded"/>
  <xs:element name="administrativeGenderCode" type="CE" minOccurs="0"/>
  <xs:element name="birthTime" type="TS" minOccurs="0"/>
  <xs:element ref="sdtc:deceasedInd" xmlns:sdtc="urn:hl7-org:sdtc" minOccurs="0"
      maxOccurs="1" />
  <xs:element ref="sdtc:deceasedTime" xmlns:sdtc="urn:hl7-org:sdtc" minOccurs="1"
      maxOccurs="1" />

I'll leave the remaining two as an exercise for the reader.  

To support the two extension attributes requires a quite a bit more work.  The challenge is that  they need to be used inside datatypes-base.xsd, and also use the simple types defined therein.  That requires a bit of re-factoring to clean it up.  What I expect will be needed is to split datatypes-based.xsd into two parts: datatypes-simple.xsd which contains the simple types we want to reuse, and datatypes-base.xsd which contains the complex types that we want to modify to support new attributes.

1 comment:

  1. How do i incorporate the sdtc:valueSet attributes