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, July 10, 2015

Comparing Template Versions in CCDA

One of the things that I'm doing right now is working on examples for C-CDA 2.1.  To evaluate these examples, I'm running them through both the 1.1 and 2.1 schematons produced by Trifolia, as well as a couple of other validators.  Sometimes the validators don't agree, as I've discussed previously.

To better address the compatibility issues and to verify that what I have is correct, I wanted to be able to compare requirements side by side.  So, I build an XSLT stylesheet to compare the output from Trifolia for two different template versions.  Here's how it works:

It processes an XML file containing the old XML Template in the format produced by Trifolia.  It accepts one parameter, the name of the new IG XML file (in that same format) to compare it to.  For each template in the input file, it attempts to find a matching template in the new IG, perhaps with a new version.  If there is no new version, it doesn't do anything.  If there is, it produces a table comparing the two templates.

The table displays the template metadata (IG Name, Title, Identifier, Version, Publication Status, Template Type, Open/Closed Status, Context, Previous Version, and Description).  If differences are found, the metadata name cell is highlighted in gray.

Then it traverses all the constraints within either template, sorted by context, and simply compares the narrative of each constraint, ignoring minor differences due to CONF: statement numbering in its comparison.  If a difference is found, it highlights the context cell with a background color of red, yellow or green depending on whether the original constraint was SHALL, SHOULD or MAY.

What appears below is a sample of the output.  There's still a bug or two in this, in that when two constraints apply to the same context (entryRelationship), the code doesn't correctly deal with that.  I have some work to do there yet.  When I get around to fixing that, I'll post the stylesheet.  You can see a sample of the output below.

This has proved to be very useful in comparing the CCDA 1.1 and 2.1 templates.  I wish I'd had the time to do this when we started on the compatibility work a few months back, as it would have made my life a lot easier.  However, I hadn't at that time figured out how to get a good comparison.  That's probably because I wasn't thinking about how a minimally viable comparison might work.  Now that I have that, I can actually get an even better comparison with a bit more work.

   Keith

US Realm Header

FeatureOriginalNew
IGConsolidationConsolidation V3
titleUS Realm HeaderUS Realm Header (V3)
identifier2.16.840.1.113883.10.20.22.1.12.16.840.1.113883.10.20.22.1.1
version2015-08-01:
publishStatusPublishedDraft
templateTypedocumentdocument
isOpentruetrue
contextTypeClinicalDocumentClinicalDocument
PreviousVersionUS Realm Header (V2) (urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2014-06-09)
DescriptionThis section describes constraints that apply to the header for all documents within the scope of this implementation guide. Header constraints specific to each document type are described in the appropriate document-specific section below.This template defines constraints that represent common administrative and demographic concepts for US Realm CDA documents. Further specification, such as ClinicalDocument/code, are provided in document templates that conform to this template.
ClinicalDocument/realmCodeSHALL contain exactly one [1..1] realmCode="US" (CONF:16791).SHALL contain exactly one [1..1] realmCode="US" (CONF:16791).
ClinicalDocument/typeIdSHALL contain exactly one [1..1] typeId (CONF:5361).SHALL contain exactly one [1..1] typeId (CONF:5361).
ClinicalDocument/typeId/​@rootThis typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250).This typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250).
ClinicalDocument/typeId/​@extensionThis typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251).This typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251).
ClinicalDocument/templateIdSHALL contain exactly one [1..1] templateId (CONF:5252) such that itSHALL contain exactly one [1..1] templateId (CONF:5252) such that it
ClinicalDocument/templateId/​@rootSHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).
ClinicalDocument/templateId/​@extensionSHALL contain exactly one [1..1] @extension="2015-08-01" (CONF:32503).
ClinicalDocument/idSHALL contain exactly one [1..1] id (CONF:5363).SHALL contain exactly one [1..1] id (CONF:5363).
ClinicalDocument/codeSHALL contain exactly one [1..1] code (CONF:5253).SHALL contain exactly one [1..1] code (CONF:5253).
ClinicalDocument/titleSHALL contain exactly one [1..1] title (CONF:5254).SHALL contain exactly one [1..1] title (CONF:5254).
ClinicalDocument/effectiveTimeSHALL contain exactly one [1..1] effectiveTime (CONF:5256).SHALL contain exactly one [1..1] US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4) (CONF:5256).
ClinicalDocument/confidentialityCodeSHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC 2010-04-21 (CONF:5259).SHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC (CONF:5259).


0 comments:

Post a Comment