This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Consolidated CDA R2.1 DSTU Update"
Jump to navigation
Jump to search
Bamarquard (talk | contribs) |
Bamarquard (talk | contribs) |
||
| Line 10: | Line 10: | ||
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: | 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: | ||
| − | + | #When supporting backwards compatibility with C-CDA 1.1, constraint text | |
OR | OR | ||
| − | + | #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. | 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. | ||
| Line 27: | Line 27: | ||
#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 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. | #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. | + | #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). |
| − | 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. | |
| − | |||
| − | NOTE: Validators should report a warning for this second case, since these will usually require manual verification. | ||
Revision as of 15:22, 8 June 2015
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 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
Compatibility principles under discussion
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. 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:
- When supporting backwards compatibility with C-CDA 1.1, constraint text
OR
- 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.
