Consolidated CDA Release 2.2, published by Health Level Seven. This is not an authorized publication; it is the continuous build for version 2.2). This version is based on the current content of https://github.com/HL7/CDA-ccda-2.2/ and changes regularly. See the Directory of published versions
Design considerations describe overarching principles that have been developed and applied across the CDA templates in this guide. Material in this section can be thought of as “heuristics,” as opposed to the formal, testable constraints found in Volume 2 of this guide.
This release contains new versions of templates included in C-CDA Release 2.0. Templates in this specification provide compatibility for software that supports template versions in the C-CDA R1.1 Implementation Guide. The new compatible template versions contain constraint modifications which enable compatibility with C-CDA 1.1. The constraints updated for C-CDA R2.1 are identified in the appendix Volume 2 Summary of Changes.
C-CDA Release 2.0 includes several templates not previously present in C-CDA Release 1.1. Software designed to support C-CDA Release 1.1 template versions may not support the new templates introduced in C-CDA Release 2.0. Except where explicitly prohibited by the C-CDA 1.1 specification, use of templates first released as part of C-CDA Release 2.0 is permitted.
New systems that wish to support C-CDA R1.1, R2.0, and R2.1, should review all specifications. A system developed strictly to the R2.1 version might not automatically support receiving R1.1 documents without additional development. Support for R2.0 conformant documents will require additional generation and import effort since different vocabulary requirements apply in several places.
Compatibility Principles
The baseline for C-CDA Release 2.1 is C-CDA Release 2.0. HL7 has applied these principles against templates present in C-CDA Release 1.1 and C-CDA R2.0 to create compatible template versions:
There are two options for other specifications that have built upon C-CDA Release 2.0:
The SDWG strongly encourages specifications built on C-CDA R2.0 to adopt option 1 since option 2 increases variability across implementations. After final publication of R2.1 SDWG will contact developers of prior specifications, which reference C-CDA R2.0, to discuss migration plans.
Volume 2 of this guide includes a requirement that all C-CDA R2.1 conformant instances:
By including both templateIds the sending application is asserting conformance with C-CDA R2.1 and C-CDA R1.1. This requirement (CONF:32936) is included in the US Realm Header (V3):
SHALL contain exactly one [1..1] templateId (CONF:1198-5252) such that it a. SHALL contain exactly one [1..1] @root=”2.16.840.1.113883.10.20.22.1.1” (CONF:1198-10036). b. SHALL contain exactly one [1..1] @extension=”2015-08-01” (CONF:1198-32503). c. When asserting this templateId, all document, section, and entry templates SHALL include a templateId root without an extension. See C-CDA R2.1 Volume 1 - Design Considerations for additional detail (CONF:1198-32936).
C-CDA R2.1 Discharge Summary header example
<ClinicalDocument xmlns="urn:hl7-org:v3">
<!-- ** CDA Header ** -->
<realmCode code="US"/>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- US General Header Template -->
<templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2015-08-01"/>
<!--Critical Change for backwards compatibility-->
<templateId root="2.16.840.1.113883.10.20.22.1.1"/>
<!-- *** Note: The next templateId, code and title will differ depending on what type of document is being sent. *** -->
<templateId root="2.16.840.1.113883.10.20.22.1.8" extension="2015-08-01"/>
<!--For backwards compatibility-->
<templateId root="2.16.840.1.113883.10.20.22.1.8"/>
...
C-CDA R2.1 Problem List Section example
<section>
<templateId root="2.16.840.1.113883.10.20.22.2.5.1" extension="2014-06-09"/>
<!--For backwards compatibility-->
<templateId root="2.16.840.1.113883.10.20.22.2.5.1"/>
<code code="11450-4" codeSystem="2.16.840.1.113883.6.1" displayName="Problem List"/>
<title>Problem List</title>
...
C-CDA R2.1 Problem Concern Entry example
<entry>
<act classCode="ACT" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.3" extension="2014-06-09"/>
<!--For backwards compatibility-->
<templateId root="2.16.840.1.113883.10.20.22.4.3"/>
<id root="102ca2e9-884c-4523-a2b4-1b6c3469c397"/>
<code code="CONC" codeSystem="2.16.840.1.113883.5.6"/>
...
A CDA participant (e.g., Author, Informant), per the Reference Information Model (RIM), is “an association between an Act and a Role with an Entity playing that Role. Each Entity (in a Role) involved in an Act in a certain way is linked to the Act by one Participation-instance. The kind of involvement in the Act is specified by the Participation.typeCode.”
CDA principles when asserting participations include:
Meaningful Use Stage 29 criterion §170.314(b)(4) Clinical Information Reconciliation requires a system to “simultaneously display (i.e., in a single view) the data from at least two list sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date.”
CDA addresses this requirement via the Author Participation and its time stamp. CDA requires that Author and Author time stamp be asserted in the document header. From there, authorship propagates to contained sections and contained entries, unless explicitly overridden. Thus, all entries in CDA implicitly include Author and Author time stamp.
In this version of CDA, we have added a new Author Participation template (templateId 2.16.840.1.113883.10.20.22.4.119) to better ensure consistent representation. This template should be used to explicitly assert authorship and author time stamps, unless the values propagated from the document header hold true.
A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modeling between different objects.
The following principles apply when representing or interpreting a clinical statement’s status.
The Problem Concern Act (V2) (templateId 2.16.840.1.113883.10.20.22.4.3:2014-06-09) reflects an ongoing concern on behalf of the provider who placed the concern on a patient’s problem list. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have resolved or not — the statusCode of the Problem Concern Act is “active.” When the underlying condition is no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.” The effectiveTime of a Problem Concern Act reflects the time that the concern about an underlying condition — as such, the effectiveTime of the concern may not correspond to the effectiveTime of the condition. For example, a patient may have suffered a heart attack 5 years ago, but a physician may continue to have an active concern about the patient’s cardiac condition.
A Problem Concern Act can contain one or more Problem Observations (templateId 2.16.840.1.113883.10.20.22.4.4:2014-06-09). Each Problem Observation is a discrete observation of a condition and therefore has a statusCode of “completed.” The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. The effectiveTime of the Problem Observation is the definitive indication of whether the underlying condition is resolved. This is shown graphically in the following figure.
C-CDA 1.1 included several optional “status” observation templates such as Problem Status Observation and Allergy Status Observation. These “status” observation templates were deprecated when C-CDA R2.0 was released. (For more about deprecated templates, see the section titled Use of Deprecated Template Versions). In C-CDA R2.1, the “status” observation templates remain deprecated. To support backward compatibility, systems that consume CDA documents need to address the possibility that a “status” observation template may also be present. The following guidance should be followed if a CDA document includes a deprecated status observation:
Deprecated “status” observation template | Implementer Guidance |
---|---|
A status of “active” | If the parent Observation has an effectiveTime/high, the content contains conflicting information. |
A status of “resolved” | If the parent Observation does not have an effectiveTime/high, the content contains conflicting information. |
A status of “inactive” | If the parent Observation does not have an effectiveTime/high, the content has the potential to contain conflicting information. |
Metadata carried in the header may already be available for rendering from EHRs or other sources external to the document. An example of this would be a doctor using an EHR that already contains the patient’s name, date of birth, current address, and phone number. When a CDA document is rendered within that EHR, those pieces of information may not need to be displayed since they are already known and displayed within the EHR’s user interface.
Good practice recommends that the following be present whenever the document is viewed:
In Operative and Procedure Notes, the following information is typically displayed in the EHR and/or rendered directly in the document:
The C-CDA R1.1 release recommended that clinical statements include a link between the narrative (section.text) and coded clinical data (entry). Rather than repeat these constraints in every applicable entry, SDWG agreed in R2.0 to apply the following constraint to all entry templates, unless explicitly prohibited.
SHOULD contain zero or one [0..1] text (CONF:XXXX). a. The text, if present, SHOULD contain zero or one [0..1] reference/@value (CONF: XXXX). i. This reference/@value SHALL begin with a ‘#’ and SHALL point to its corresponding narrative (using the approach defined in CDA R2.0, section 4.3.5.1) (CONF: XXXX). MAY contain zero or one [0..1] originalText (CONF:XXXX). a. The originalText, if present, SHOULD contain zero or one [0..1] reference/@value (CONF:XXXX). i. This reference/@value SHALL begin with a ‘#’ and SHALL point to its corresponding narrative (using the approach defined in CDA R2.0, section 4.3.5.1) (CONF:XXXX).
Information technology solutions store and manage data, but sometimes data are not available. An item may be unknown, not relevant, or not computable or measureable, such as where a patient arrives at an emergency department unconscious and with no identification.
In many cases, the C-CDA standard will stipulate that a piece of information is required (e.g., via a SHALL conformance verb). However, in most of these cases, the standard provides an “out”, allowing the sender to indicate that the information isn’t known.
Here, we provide guidance on representing unknown information. Further details can be found in the HL7 V3 Data Types Release 1 specification that accompanies the CDA R2 normative standard. However, it should be noted that the focus of Consolidated CDA is on the unambiguous representation of known data, and that in general, the often subtle nuances of unknown information representation are less relevant to the recipient.
Many fields in C-CDA contain a “@nullFlavor” attribute, used to indicate an exceptional value. Some flavors of Null are used to indicate that the known information falls outside of value set binding constraints. Not all uses of the @nullFlavor attribute are associated with a case in which information is unknown. Allowable values for populating the attribute give details about the reason the information is unknown, as shown in the following example.
nullFlavor Example
<birthTime nullFlavor=”UNK”/> <!--Sender does not know the birthTime, but a proper value is applicable -->
Use null flavors for unknown, required, or optional attributes:
NI | No information. This is the most general and default null flavor. |
NA | Not applicable. Known to have no proper value (e.g., last menstrual period for a male). |
UNK | Unknown. A proper value is applicable, but is not known. |
ASKU | Asked, but not known. Information was sought, but not found (e.g., the patient was asked but did not know). |
NAV | Temporarily unavailable. The information is not available, but is expected to be available later. |
NASK | Not asked. The patient was not asked. |
MSK | There is information on this item available but it has not been provided by the sender due to security, privacy, or other reasons. There may be an alternate mechanism for gaining access to this information. |
OTH | The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system). |
The list above contains those null flavors that are commonly used in clinical documents. For the full list and descriptions, see the nullFlavor vocabulary domain in the CDA R2 normative edition.10
Any SHALL, SHOULD or MAY conformance statement may use nullFlavor, unless the nullFlavor is explicitly disallowed (e.g., through another conformance statement which includes a SHALL conformance for a vocabulary binding to the @code attribute, or through an explicit SHALL NOT allow use of nullFlavor conformance).
Attribute Required (nullFlavor not allowed)
Allowed nullFlavors When Element is Required (with xml examples)
<entry>
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NI"/>
<code nullFlavor="OTH">
<originalText>New Grading system</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime nullFlavor="UNK"/>
<value xsi:type="CD" nullFlavor="OTH">
<originalText>Spiculated mass grade 5</originalText>
</value>
</observation>
</entry>
If a sender wants to state that a piece of information is unknown, the following principles apply:
Unknown Medication Example
<entry>
<text>patient was given a medication but I do not know what it was</text>
<substanceAdministration moodCode="EVN" classCode="SBADM">
<consumable>
<manufacturedProduct>
<manufacturedLabeledDrug>
<code nullFlavor="NI"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
</substanceAdministration>
</entry>
Unknown Medication Use of Anticoagulant Drug Example
<entry>
<substanceAdministration moodCode="EVN" classCode="SBADM" nullFlavor="NI">
<text>I do not know whether or not patient received an anticoagulant drug</text>
<consumable>
<manufacturedProduct>
<manufacturedLabeledDrug>
<code code="81839001" displayName="anticoagulant drug" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
</substanceAdministration>
</entry>
No Known Medications Example
<entry>
<substanceAdministration moodCode="EVN" classCode="SBADM" negationInd=”true”>
<text>No known medications</text>
<consumable>
<manufacturedProduct>
<manufacturedLabeledDrug>
<code code="410942007" displayName="drug or medication" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
</substanceAdministration>
</entry>
Value Known, Code for Value Not Known
<entry>
<observation classCode="OBS" moodCode="EVN">
…
<value xsi:type="CD" nullFlavor="OTH">
<originalText>Spiculated mass grade 5</originalText>
</value>
</observation>
</entry>
Value Completely Unknown
<entry>
<observation classCode="OBS" moodCode="EVN">
…
<value xsi:type="CD" nullFlavor="UNK"/>
</observation>
</entry>
Value Known, Code in Required Code System Not Known But Code from Another Code System is Known
<entry>
<observation classCode="OBS" moodCode="EVN">
…
<value xsi:type="CD" nullFlavor="OTH">
<originalText>Spiculated mass grade 5</originalText>
<translation code="129742005" displayName="spiculated lesion" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
</value>
</observation>
</entry>