View source for Consolidated CDA R2.1 DSTU Update

The purpose of this project is to quickly develop an update to the existing Consolidated CDA DSTU 2.0 specification to support  compatibility with C-CDA 1.1.  The requirements are that an existing EHR certified under 2014 or 2015 ONC Standards and Certification criteria be able to correctly interpret the content of a C-CDA 2.1 without requiring change to the product presuming that it has followed good development practices in interpretation of the CDA Standards and C-CDA 1.1 specifications.

The project builds on the work of the Dual-CDA Compatible Task Force to address the issues it found between C-CDA Release 1.1 and C-CDA Release 2.0.

[https://drive.google.com/drive/folders/0B44mVoChqHDtfjRvdHAyZFlaMk4wV2xHb0dKNmktVGJnc1B6b3JBODRON2VnSVZGbWpmeVk Google Drive with work products]
[https://docs.google.com/spreadsheets/d/1szhNiSHj8CSue7Il-dfVvF9_WYSim_xA0H6APQEBdZw/edit#gid=0 Google Sheet for IGs dependent on C-CDA R2.1]

=== Approved Compatibility Principles ===
HL7 will apply these compatibility principles against templates present in C-CDA R1.1 and C-CDA R2.0. The baseline for C-CDA R2.1 is C-CDA R2.0:
#When a SHALL constraint present in C-CDA Release 1.1 is relaxed to SHOULD or MAY in C-CDA Release 2.0, the C-CDA Release 2.1 specification will increase the strength of that constraint to SHALL when compatibility is asserted.
#When a SHALL constraint present is C-CDA Release 1.1. is removed in C-CDA Release 2.0, the C-CDA 2.1 specification will add that constraint when supporting  compatibility.
#When a SHOULD or MAY constraint present in C-CDA Release 1.1 is relaxed or removed in C-CDA Release 2.0, the C-CDA Release 2.1 specification will remain silent.  As these constraints are not strictly required in a C-CDA 1.1 instance, they are not necessary for backwards compatibility.   Implementers who wish to continue to convey data elements found in C-CDA 1.1. with a SHOULD or MAY constraint can still report this information as it was done in C-CDA 1.1 so long as these are also conformant with this specification [Are there any cases where we need to worry about this? Will see if anyone comes up with others by Thursday.]
#A SHALL, SHOULD or MAY constraint added in C-CDA R2.0 that is not explicitly prohibited in C-CDA R1.1 will be added to C-CDA R2.1.
#When a vocabulary or value set binding has changed for an element to a new coding system in C-CDA Release 2.0, C-CDA Release 2.1 will, when supporting backwards compatibility; require the use of the old value set or vocabulary in element/code, and the new value set or vocabulary in element/translation, and otherwise require the use of the new value set or vocabulary in code as it was constrained (with the same strength appearing) in C-CDA 2.0.

=== C-CDA R2.1 Compatibility Modes ===
#C-CDA R2.1 only supports compatibility mode 
#C-CDA R2.1 supports compatibility mode and ability to send requirements as specified in C-CDA R2.0

With either option, C-CDA R2.1 will include all of the new templates from C-CDA R2.0

=== Implementation guidelines ===
#If you assert compatibility at the document level then compatibility templates, where available, will be used throughout the entire document instance.
#New templates in C-CDA R2.0 that were not in C-CDA R1.1 are allowed in a C-CDA R2.1 instances.
#New templates in C-CDA R2.0 that were not in C-CDA R1.1 are not being evaluated for compatibility.

===[[C-CDA R2.1 Comment Submission]]===