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.

Friday, October 19, 2012

A Dual Compatible CCD

On Wednesday I talked about template versioning.  This morning's post I'm going to expand on how to create a CCD 1.0 that is also a CCD 1.1.

Wes Rishel's Asynchronous Bilateral Cut-over applies here. The rationale for doing this is to enable systems which only understand the CCD 1.0 to understand your newer documents as well as best they can.

Normally, when you create a new version of a template, you would do so in a way that was backwards compatible with the old template.  That is to say, that none of the constraints in the new template would violate the constraints of the old template.  That's just not possible with some of the CCD 1.1 templates, because certain 1.1 templates violate constraints of the 1.0 templates.

So, the question is: How do  you create a document conforming to a particular template in such a way as to support systems that understood older versions and newer versions of the same template. But when you have a two versions which aren't compatible with each other (such as the CCDA Problem Act and the CCD Problem Act), what would you do?

One possible solution is to present the content using both versions of the template. This takes advantage of the "indirect containment rule".  In CCD, certain templates SHALL/SHOULD/MAY contain other templates.  But containment needn't be direct.  That was implicit in CCD 1.0, in the IHE PCC Technical Framework, and in the HITSP C32 (because it relied on those specifications).  This means that to meet the "contains" constraint, a template may be a descendant rather than a direct child of another template.

What we want to be able to do is represent the same content twice using two different versions of the same template. Because the templates are dealing with the same concept, we should be able to assume that the later version is functionally compatible as the earlier version, even if not "wire format" compatible. If they are functionally compatible, then one should be able to transform the newer template into the older format.  Note, that in doing so, it is possible that you could lose some information that isn't supported in the older version. The older version can be created via a transform, derived from the newer version. Given that there is some data loss, you could also consider it an an excerpt from the newer template. Transform (XFRM), derived (DRIV), and Excerpt (XCRPT) are all act relationship types in CDA R2.

So, to represent a CCD 1.1, in a way that was also interpretable as a CCD 1.0, you would include the "wire format" incompatible older templates as being excerpts of the newer template versions.  The example below shows the general structure that you would use.

<entry>
  <act ...>
    <templateId root='newTemplateId'/>
      ...
    <entryRelationship typeCode='XCRPT'>
      <act ...>
        <templateId root='oldTemplateId'/>
          ...
      </act>
    </entryRelationship>
  </act>
</entry>

When the entry templates require containment of other templates, you wind up creating a parallel structure under the first excerpt.

Because of the functional equivalences between the two templates, it should also be possible to create a transform from the CCD 1.0 template to its CCD 1.1 successor (and vice versa).  Developing such transforms isn't necessarily an academic exercise.  It allows systems which understood CCD 1.0 to be used with systems that generate only CCD 1.1, or alternatively, allows systems which generate a CCD 1.0 to be able to generate CCD 1.1 without significant retooling.

0 comments:

Post a Comment