CDA Design

Editing tips and notes

Return to master table of contents

1 CDA Overview

(content on separate page)

2 Introduction to CDA Technical Artifacts

(content on separate page)

3 CDA Document Exchange in HL7 Messages

(content on separate page)

4 CDA Templating

(content on separate page)

5 CDA Design

NOTE: The definitive description of HL7 V3 model refinement, R-MIM development and interpretation can be found here.

The CDA R-MIM POCD_RM000040UV can be found here:

CDA R-MIM

A CDA document is comprised of a header and a body. The header identifies and classifies the document; provides information on authentication, the encounter, the patient, and the provider; and sets the context for the document as a whole. The body contains the clinical report, and is conceptually divided up into nested sections, each containing a narrative block to be rendered along with structured entries and external references.

5.1 Clinical Document

The ClinicalDocument class is the entry point into the CDA R-MIM, and corresponds to the <ClinicalDocument> XML element that is the root element of a CDA document instance. This section will outline the CDA Document's physical design, first in the header and then the body.

A CDA document is logically broken up into a CDA Header and a CDA Body. The CDA Header is comprised of ClinicalDocument attributes, participants, and act relationships. The CDA Body is the target of the ClinicalDocument component act relationship.

5.2 Header

(content on separate page)

5.3 Body

(content on separate page)

5.4 CDA Context

CDA context is set in the CDA header and applies to the entire document. Context can be overridden at the level of the body, section, and/or CDA entry.

5.4.1 Overview of CDA Context

A document, in a sense, is a contextual wrapper for its contents. Assertions in the document header are typically applicable to statements made in the body of the document, unless overridden. For instance, the patient identified in the header is assumed to be the subject of observations described in the body of the document, unless a different subject is explicitly stated, or the author identified in the header is assumed to be the author of the entire document, unless a different author is explicitly identified on a section. The objective of the CDA context rules are to make these practices explicit with relationship to the RIM, such that a computer will understand the context of a portion of a document the same way that a human interprets it.

At the same time, there is no guarantee that machine processing will identify a mistaken application of contextual rules. If a physician records an "outside diagnosis" in narrative but does not nullify the "informant" context, machine processing will not identify the switch in attribution. This is a special case illustrating the limits of automated validation of electronic records and would apply regardless of the context inheritance mechanism. In other words, from some errors of encoding, there is no recovery other than human review.

CDA's approach to context, and the propagation of that context to nested document components, follows these design principles:

• CDA uses the RIM context mechanism (contextControlCode for Participations; contextConductionInd for ActRelationships), and assigns fixed values to these attributes to accomplish the design objectives below, thus constraining the RIM context model. CDA extends the context propagation property to designated attributes of the CDA Header, which also propagate through any ActRelationship for which contextConductionInd="true".
• The CDA Header sets context for the entire document. A propagating value specified in the document header holds true throughout the document, unless explicitly overridden. This principal applies to both Participations and to designated attributes of the CDA Header. Contextual header components (i.e., those that have propagating values) include:
  • Author
  • Confidentiality
  • Data enterer
  • Human language
  • Informant
  • Legal authenticator
  • Participant
  • Record target
• Context components that can be overridden at the level of the document body include:
  • Confidentiality
  • Human language
• Context components that can be overridden at the level of a document section include:
  • Author
  • Confidentiality
  • Human language
  • Informant
  • Subject
• Context components that can be overridden at the level of a CDA entry include:
  • Author
  • Human language
  • Informant
  • Participant
  • Subject
• Context propagates from outer tags to nested tags. Context that is specified on an outer tag holds true for all nested tags, unless overridden on a nested tag. Context specified on a tag within the CDA body always overrides context propagated from an outer tag. For instance, the specification of authorship at a document section level overrides all authorship propagated from outer tags.
• Context is sometimes known precisely, and is sometimes unknown, such as in the case where a document is comprised of a large unparsed narrative block that potentially includes statements that contradict outer context. Because CDA context always propagates unless overridden, the representation of unknown context is achieved by overriding with a null value.

5.4.2 Technical Aspects of CDA Context

The RIM defines the "context" of an act as those participants of the act that can be propagated to nested acts. In the RIM, whether or not contextual participants do propagate to nested acts depends on whether or not the intervening act relationship between parent and child act allows for conduction of context. The explicit representation of context, and whether or not the context on an act can propagate to nested acts, is expressed via the RIM attributes Participation.contextControlCode and ActRelationship.contextConductionInd. CDA constrains the general RIM context mechanism such that context always overrides and propagates, as shown in the following table.

Table X: CDA constraints on RIM context attributes

RIM attribute	Cardinality	Conformance	Fixed Value
Participation.contextControlCode	1..1	Mandatory (NULL values not permitted)	"OP" (overriding, propagating)
ActRelationship.contextConductionInd	1..1	Mandatory (NULL values not permitted)	"true"†

†The one exception to this is entryRelationship.contextConductionInd, which is defaulted to "true", but can be changed to "false". See entryRelationship for details.

Where the context of a nested component is unknown, the propagated context must be overridden with a null-valued component, as shown in the following table.

Table X: Blocking context propagation with null values

Context	Null value representation
Author	AssignedAuthor.id = NULL; No playing entity; No scoping entity.
Confidentiality	confidentialityCode = NULL.
Human language	languageCode = NULL.
Informant	AssignedEntity.id = NULL; No playing entity; No scoping entity.
Participant	ParticipantRole.id = NULL; No playing entity; No scoping entity.

The following exhibit illustrates the CDA context model. ClinicalDocument has an author participant, a confidentialityCode, and a languageCode, all of which will propagate to nested acts. The component act relationship going from ClinicalDocument to bodyChoice has contextConductionInd fixed as "true", thus allowing for the propagation of context. The bodyChoice classes, NonXMLBody and StructuredBody, contain a confidentialityCode and languageCode which can be used to override the value specified in the header. The component act relationship going from StructuredBody to Section has contextConductionInd fixed at "true", thus the context on StructuredBody will propagate through to Section. Section can override confidentialityCode, languageCode, and author. A null value for the Section's author participant indicates that the author for that particular section is unknown.

Context Example

Because context is always overriding and propagating, one can compute the context of a given node by looking for the most proximate assertion. The following example is a sample XPath expression that can be used to identify the <author> context of a section or entry:

Example X

(ancestor-or-self::*/author)[position()=last()]

5.4.3 InfrastructureRoot and CDA Classes

All of CDA classes inherits 1 attribute and 3 element from InfrastructureRoot. Infrastructure Root provides a set of infrastructure attributes that may be used in instances of HL7-specified, RIM-based classes. When valued in an instance, these attributes indicate whether the information structure is being constrained by specifically defined templates, realms or common element types.

• An optional nullFlavor attribute has been added to each CDA class. When the class is null, this code can be used to indicate the flavor of null that is intended.

The following 3 optional elements have been added at the beginning of each CDA class:

• realmCode, is vocabulary domain qualifier that allows the vocabulary domain of coded attributes to be specialized according to the geographical, organizational, or political environment where the HL7 standard is being used. It is defined as a SET<CS>data type.
• typeId, is a unique identifier for an HL7 static structure that imposes constraints on an artifact. In CDA it must be defined at the root element, to indicate a CDA R2.1 document,with ClinicalDocument.typeId.root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models); ClinicalDocument.typeId.extension = "POCD_HD000040UV02" (which is the unique identifier for the CDA, Release Two Hierarchical Description). As CMETs are not used in CDA, this element will not be used in other classes. It is defined as a II data type.
• templateId, is an optional unique identifier, which indicates to a receiver that a set of constraints have been defined for a given class and it's attributes. See section 4 on templates in CDA.

6 CDA Hierarchical Description

(content on separate page)

7 CDA XML Implementation

(content on separate page)

8 Appendix

(content on separate page)