Supercompliance with HL7 CCDA Versions

I've written several times about C-CDA Release 2.0 and issues with template versioning which are pretty close to resolution, and I've also written previously about the 2015 Certification criteria and backwards compatibility with 2014 criteria.

What I'd like to expand upon now is an issue that could occur if C-CDA Release 2.0 was adopted as optional criteria for 2015 and how we could arrange things so that a 2014 system could receive it.  It draws in part on what I described previously as a Dual Compatible CCD, but is slightly different because CCDA 2.0 is largely backwards compatible with CCDA 1.1.

The issue is that when System N (for new) sends a CCDA 2.0 document to System O (for old) that understands CCDA 1.1 there are three things that could happen:

1. System O would correctly identify the fact that the CCDA 2.0 document did NOT comply with CCDA 1.1 and would reject it.
2. System O would NOT correctly identify this fact because the template identifiers are similar enough, and some don't understand the details of how to match identifier values in HL7 Version 3 and CDA, and so it would incorrectly try to process it.  System O would handle these as follows: 
1. Where these templates are backwards compatible:, System O would handle the 2.0 templates correctly where they are backwards compatible with 1.1, BUT, 
2. Where they are not, System O would have issues with interpretation of the content.

There are FEW cases where 2.b. would occur based on a preliminary analysis of CCDA 2.0, BUT, we need to spend more time looking into those details.  One case that has been identified is the templates for Smoking Status, where there are differences in interpretation of the effectiveTime element on the observation.

What I would propose that systems using CCDA 2.0 do is be "Super Compliant" (this is really independent of what my thoughts are on the 2015 certification rule).  Super Compliant means that they send documents which conform to both CCDA 2.0 rules, and CCDA 1.1 rules, and only send the same information twice when ABSOLUTELY NECESSARY (as in the case for Smoking Status), and only in very controlled ways.

It would mean that a sector or entry could declare conformance to both CCDA 1.1 and 2.0 except where that wasn't feasible (e.g., Smoking Status).  That last little note also means that we need to examine more carefully where backwards compatibility isn't the case. 

The benefit of this is that systems which understand CCDA 1.1 will, if properly interpreting the guide and underlying CDA Release 2.0 standards, work correctly.  Even if they don't fully interpret the CDA Release 2.0 standard properly (e.g., get confused about the Instance Identifier data type and similar but not identical identifiers), could and likely would still get the correct result.

This allows systems supporting CCDA 2.0 to work with systems only understanding 1.1.  It does mean that newer systems supporting CCDA 2.0 would still have to support CCDA 1.1 as input, because not every system available would be able to send CCDA 2.0, but that is already pretty likely to be the case for MOST Certified EHR products in use today.

I'll talk a little bit more tomorrow about flavors of compatibility and breaking changes (also called substantive changes) and how we could develop some policies for advancing standards that allows new features to be created, and problems to be fixed but still ensure that systems