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
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
| Feature | Original | New |
|---|---|---|
| IG | Consolidation | Consolidation V3 |
| title | US Realm Header | US Realm Header (V3) |
| identifier | 2.16.840.1.113883.10.20.22.1.1 | 2.16.840.1.113883.10.20.22.1.1 |
| version | 2015-08-01: | |
| publishStatus | Published | Draft |
| templateType | document | document |
| isOpen | true | true |
| contextType | ClinicalDocument | ClinicalDocument |
| PreviousVersion | US Realm Header (V2) (urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2014-06-09) | |
| Description | This 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/realmCode | SHALL contain exactly one [1..1] realmCode="US" (CONF:16791). | SHALL contain exactly one [1..1] realmCode="US" (CONF:16791). |
| ClinicalDocument/typeId | SHALL contain exactly one [1..1] typeId (CONF:5361). | SHALL contain exactly one [1..1] typeId (CONF:5361). |
| ClinicalDocument/typeId/@root | This 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/@extension | This 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/templateId | SHALL contain exactly one [1..1] templateId (CONF:5252) such that it | SHALL contain exactly one [1..1] templateId (CONF:5252) such that it |
| ClinicalDocument/templateId/@root | SHALL 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/@extension | SHALL contain exactly one [1..1] @extension="2015-08-01" (CONF:32503). | |
| ClinicalDocument/id | SHALL contain exactly one [1..1] id (CONF:5363). | SHALL contain exactly one [1..1] id (CONF:5363). |
| ClinicalDocument/code | SHALL contain exactly one [1..1] code (CONF:5253). | SHALL contain exactly one [1..1] code (CONF:5253). |
| ClinicalDocument/title | SHALL contain exactly one [1..1] title (CONF:5254). | SHALL contain exactly one [1..1] title (CONF:5254). |
| ClinicalDocument/effectiveTime | SHALL 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/confidentialityCode | 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 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