This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Consolidated CDA R2.1 DSTU Update"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
−
The purpose of this project is to quickly develop an update to the existing Consolidated CDA DSTU 2.0 specification to support backwards 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 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.
 
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.
Line 5: Line 5:
 
[https://drive.google.com/drive/folders/0B44mVoChqHDtfjRvdHAyZFlaMk4wV2xHb0dKNmktVGJnc1B6b3JBODRON2VnSVZGbWpmeVk Google Drive with work products]
 
[https://drive.google.com/drive/folders/0B44mVoChqHDtfjRvdHAyZFlaMk4wV2xHb0dKNmktVGJnc1B6b3JBODRON2VnSVZGbWpmeVk Google Drive with work products]
  
 +
=== Draft Compatibility Principles ===
 +
HL7 will apply these compatibility principles against templates present in C-CDA R1.1 and 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.
  
−
=== Compatibility principles under discussion  ===
+
=== C-CDA R2.1 Compatibility Modes ===
−
C-CDA Release 2.1 contains a number of templates not previously present in C-CDA Release 1.1.  These templates are not backwards compatible with software designed to support C-CDA Release 1.1 templates only.  These newer templates are permitted to be used in C-CDA 1.1 instances unless explicitly prohibited by the C-CDA 1.1 specification.
+
#C-CDA R2.1 only supports compatibility mode
−
This release also contains new versions of templates previously present in C-CDA Release 1.1.  These templates may contain constraints enabling backwards compatibility with C-CDA 1.1. These constraints are written as conditional constraints in the form:
+
#C-CDA R2.1 supports compatibility mode and ability to send requirements as specified in C-CDA R2.0
  
−
#When supporting backwards compatibility with C-CDA 1.1, constraint text
+
=== Draft Implementation guidelines ===
−
 
+
#If you assert compatibility at the document level then compatibility templates, where available, will be used throughout the entire document instance.
−
OR
+
#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.
−
#When supporting backwards compatibility with C-CDA 1.1
 
−
#*Subconstraint text
 
−
#*…
 
−
 
 
−
A C-CDA 2.1 document instance is said to be backwards compatible with C-CDA 1.1 when it applies all backwards compatible constraints to exchange information found in this specification, and is valid according to both the C-CDA 1.1 and C-CDA 2.1 template requirements.  A document instance that asserts compliance to the C-CDA 2.1 specification AND to the C-CDA 1.1 specification is also asserting that it has applied the backwards compatible rules of this specification appropriately.
 
−
Note: There may be cases where a C-CDA 2.1 template can convey information that cannot be contained within its C-CDA 1.1 predecessor.  In these cases only is it appropriate to use the new C-CDA 2.1 template without applying backwards compatibility constraints in the document that claims to be backwards compatible.
 
−
Examples are needed.
 
−
 
 
−
====Principles applied====
 
−
#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 backwards 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 backwards 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?]
 
−
#When a vocabulary or value set 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.
 
−
#Since support for backwards compatibility is an attribute of a document instance, this specification does not have additional requirements for backwards compatibility when references to new versions of C-CDA templates appear within another template.  For example, where Medication Administration (V2.1) section references the Medication Activity (V2.1) template, this specification does not explicitly state the requirement that a backwards compatible use of the Medication Administration (V2.1) section requires backwards compatible use of the Medication Activity (V2.1) template. There are two different cases. In the first case, the information can be (partially) represented in C-CDA 1.1.  In the second case, there is no overlap between the two representations, i.e., the C-CDA 2.1  representation describes information that could NOT previously be represented in C-CDA 1.1 (e.g., when a new concept is added to a value set in C-CDA 2.1).
 
−
#*When a backwards compatible representation of the information exists in C-CDA Release 1.1, the backwards compatible rendition shall be used.
 
−
#*When no backwards compatible representation of the information exists in C-CDA Release 1.1, the template in the instance shall NOT assert conformance to C-CDA Release 1.1 requirements. NOTE: Validators should report a warning for this second case, since these will usually require manual verification.
 

Revision as of 20:28, 9 June 2015

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.

Google Drive with work products

Draft Compatibility Principles

HL7 will apply these compatibility principles against templates present in C-CDA R1.1 and C-CDA R2.0:

  1. 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.
  2. 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.
  3. 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.]
  4. 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.
  5. 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

  1. C-CDA R2.1 only supports compatibility mode
  2. C-CDA R2.1 supports compatibility mode and ability to send requirements as specified in C-CDA R2.0

Draft Implementation guidelines

  1. If you assert compatibility at the document level then compatibility templates, where available, will be used throughout the entire document instance.
  2. New templates in C-CDA R2.0 that were not in C-CDA R1.1 are allowed in a C-CDA R2.1 instances.
  3. New templates in C-CDA R2.0 that were not in C-CDA R1.1 are not being evaluated for compatibility.
Retrieved from "https://wiki.hl7.org/w/index.php?title=Consolidated_CDA_R2.1_DSTU_Update&oldid=100965"