4/2/2019 HL7 Clinical Document Architecture, Release 2.

HL7 Clinical Document Architecture, Release 2.0

ANSI/HL7 CDA, R2-2005

4/21/2005

Chair/Editor Robert H. Dolin, MD

[email protected]
Kaiser Permanente
Chair/Editor Liora Alschuler
[email protected]
alschuler.spinosa
Chair/Editor Sandy Boyer, BSP
[email protected]
Consultant
Chair/Editor Calvin Beebe
[email protected]
Mayo Clinic
Editor Fred M. Behlen, PhD
[email protected]
American College of Radiology
Editor Paul V. Biron
[email protected]
Kaiser Permanente
Editor Amnon Shabo (Shvo), PhD
[email protected]
IBM Research Lab in Haifa
Last Published: 09/25/2005 9:14 PM

HL7® Version 3 Standard, © 2005 Health Level Seven®, Inc. All Rights Reserved.

HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off

Table of Contents
1 CDA Overview
1.1 What is the CDA
1.1.1 Key aspects of the CDA
1.1.2 Scope of the CDA
1.1.3 Goals and Design Principles
1.2 General CDA Concepts
1.2.1 Major Components of a CDA Document
1.2.2 The "A" in "CDA"
1.2.3 Human Readability and Rendering CDA Documents
1.2.4 XML Markup of CDA Documents
1.2.5 Security, Confidentiality, and Data Integrity
1.2.6 Relationship of the CDA to HL7 Messaging Standards
1.3 CDA Conformance
1.3.1 Recipient Responsibilities
1.3.2 Originator Responsibilities
1.4 CDA Extensibility
1.5 Backwards and Forwards Compatibility
2 Introduction to CDA Technical Artifacts
2.1 HL7 Reference Information Model
2.2 HL7 V3 Data Types
2.3 HL7 Vocabulary Domains
2.4 HL7 CDA R-MIM
2.5 HL7 CDA Hierarchical Description
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 1/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

2.6 HL7 CDA XML Implementation

3 CDA Document Exchange in HL7 Messages
4 CDA R-MIM
4.1 Clinical Document
4.2 Header
4.2.1 Header Attributes
4.2.2 Header Participants
4.2.3 Header Relationships
4.3 Body
4.3.1 Body Choice
4.3.2 Section Attributes
4.3.3 Section Participants
4.3.4 Section Relationships
4.3.5 Section Narrative Block
4.3.6 Entry Acts
4.3.7 Entry Participants
4.3.8 Entry Relationships
4.4 CDA Context
4.4.1 Overview of CDA Context
4.4.2 Technical Aspects of CDA Context
5 CDA Hierarchical Description
6 CDA XML Implementation

Appendices

A Samples
A.1 Sample Document
A.2 Sample CDA Instance
A.3 Sample CDA Style Sheet
B Implementation Notes
B.1 Creating CDA Documents
B.2 LOINC Document Codes
B.3 CDA and Semantic Interoperability
B.4 Changes from CDA Release 1
B.4.1 Deprecated Components
B.4.2 CDA R1 to CDA R2 Correspondence

1 CDA Overview

1.1 What is the CDA

The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the
structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is a
documentation of clinical observations and services, with the following characteristics:

Persistence – A clinical document continues to exist in an unaltered state, for a time period
defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence
for a clinical document, independent of the persistence of any XML-encoded CDA document
instance).
Stewardship – A clinical document is maintained by an organization entrusted with its care.
Potential for authentication - A clinical document is an assemblage of information that is
intended to be legally authenticated.
Context - A clinical document establishes the default context for its contents.
Wholeness - Authentication of a clinical document applies to the whole and does not apply to
portions of the document without the full context of the document.
Human readability – A clinical document is human readable.

A CDA document is a defined and complete information object that can include text, images, sounds,
and other multimedia content.

1.1.1 Key aspects of the CDA

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 2/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Key aspects of the CDA include:

CDA documents are encoded in Extensible Markup Language (XML). (NOTE: When alternate
implementations are feasible, suitable conformance requirements will be issued so that in
future the syntax may not be limited to XML.)
CDA documents derive their machine processable meaning from the HL7 Reference
Information Model (RIM) and use the HL7 Version 3 Data Types.
The CDA specification is richly expressive and flexible. Document-level, section-level and
entry-level templates can be used to constrain the generic CDA specification (see The "A" in
"CDA" (§ 1.2.2 )).

1.1.2 Scope of the CDA

The scope of the CDA is the standardization of clinical documents for exchange.

The data format of clinical documents outside of the exchange context (e.g., the data format used to
store clinical documents) is not addressed in this specification.

CDA documents can be transmitted in HL7 messages designed to transfer clinical documents. While
the detailed specification for such messages is outside of the scope of the CDA, this specification does
impose requirements upon the packaging of CDA documents in HL7 messages (see CDA Document
Exchange in HL7 Messages (§ 3 )).

The CDA does not specify the creation or management of documents, only their exchange markup.
While it may be possible to directly use the CDA Schema in a document authoring environment, such
use is not the primary purpose of the CDA specification.

Document management is critically interdependent with the CDA specifications, but the specification
of document management messages is outside the scope of the CDA. (For more on this, see
Relationship of the CDA to HL7 Messaging Standards (§ 1.2.6 )).

NOTE: Several committees are developing structured document specifications that

overlap in part with the CDA specification. The Structured Documents Technical
Committee, in collaboration with Publishing and these other committees, is
developing a Structured Documents Infrastructure chapter to clarify these
relationships which should be available in upcoming editions.
1.1.3 Goals and Design Principles

The goals of the CDA are:

Give priority to delivery of patient care.

Allow cost effective implementation across as wide a spectrum of systems as possible.
Support exchange of human-readable documents between users, including those with
different levels of technical sophistication.
Promote longevity of all information encoded according to this architecture.
Enable a wide range of post-exchange processing applications.
Be compatible with a wide range of document creation applications.
Promote exchange that is independent of the underlying transfer or storage mechanism.
Prepare the design reasonably quickly.
Enable policy-makers to control their own information requirements without extension to this
specification.

A number of design principles follow from consideration of the above goals:

This architecture must be compatible with XML and the HL7 RIM.
This architecture must be compatible with representations of clinical information arising from
other HL7 committees.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 3/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Technical barriers to use of the architecture should be minimized.

The architecture specifies the representation of instances required for exchange.
The architecture should impose minimal constraints or requirements on document structure
and content required for exchange.
The architecture must be scalable to accommodate fine-grained markup such as highly
structured text and coded data.
Document specifications based on this architecture should accommodate such constraints
and requirements as supplied by appropriate professional, commercial, and regulatory
agencies.
Document specifications for document creation and processing, if intended for exchange,
should map to this exchange architecture.
CDA documents must be human readable using widely-available and commonly-deployed
XML-aware browsers and print drivers and a generic CDA style sheet written in a standard
style sheet language.
Use open standards.

1.2 General CDA Concepts

1.2.1 Major Components of a CDA Document

This section serves as a high-level introduction to the major components of a CDA document, all of
which are described again and in greater detail later on. The intent here is to familiarize the reader
with the high-level concepts to facilitate an understanding of the sections that follow.

Major components of a prototypic CDA document are shown in the following skeletal example. (Note
that many required components are missing to simplify the example. See Samples (§ A ) for a
detailed conformant example).

A CDA document is wrapped by the <ClinicalDocument> element, and contains a header (see Header
(§ 4.2 )) and a body (see Body (§ 4.3 )). The header lies between the <ClinicalDocument> and the
<structuredBody> elements, and identifies and classifies the document and provides information on
authentication, the encounter, the patient, and the involved providers.

The body contains the clinical report, and can be either an unstructured blob, or can be comprised of
structured markup. The example shows a structured body, which is wrapped by the
<structuredBody> element, and which is divided up into recursively nestable document sections.

A CDA document section is wrapped by the <section> element. Each section can contain a single
narrative block (see Section Narrative Block (§ 4.3.5 )), and any number of CDA entries (see Entry
Acts (§ 4.3.6 )) and external references.

The CDA narrative block is wrapped by the <text> element within the <section> element, and must
contain the human readable content to be rendered. See also Human Readability and Rendering CDA
Documents (§ 1.2.3 ) and CDA Conformance (§ 1.3 ) for principles governing the representation of
the narrative block, and conformance requirements on the part of originators when populating the
block, and recipients when rendering it.

Within a document section, the narrative block represents content to be rendered, whereas CDA
entries represent structured content provided for further computer processing (e.g. decision support
applications). CDA entries typically encode content present in the narrative block of the same section.
The example shows two <observation> CDA entries, and a <substanceAdministration> entry
containing a nested <supply> entry, although several other CDA entries are defined.

CDA entries can nest and they can reference external objects. CDA external references always occur
within the context of a CDA entry. External references refer to content that exists outside this CDA
document - such as some other image, some other procedure, or some other observation (which is
wrapped by the <externalObservation> element). Externally referenced material is not covered by
the authentication of the document referencing it.

Example 1
<ClinicalDocument>
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 4/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0
<C ca ocu e t>
... CDA Header ...
<structuredBody>
<section>
<text>...</text>
<observation>...</observation>
<substanceAdministration>
<supply>...</supply>
</substanceAdministration>
<observation>
<externalObservation>...
</externalObservation>
</observation>
</section>
<section>
<section>...</section>
</section>
</structuredBody>
</ClinicalDocument>

1.2.2 The "A" in "CDA"

The notion of CDA "levels" in CDA, Release One anticipated a hierarchical set of XML DTDs or XML
Schemas to achieve the goals enumerated above (see Goals and Design Principles (§ 1.1.3 )). This
hierarchy formed an "architecture", hence the "A" in "CDA".

While the notion of levels in CDA, Release Two remains constant, the approach to representing the
hierarchies has changed. The current specification consists of a single CDA XML Schema, and the
architecture arises from the ability to apply one or more of a hierarchical set of HL7 Templates, which
serve to constrain the richness and flexibility of CDA.

NOTE: The CDA can be constrained by mechanisms defined in HL7 V3 Refinement

and Localization. HL7 technical formalisms (e.g. HL7 Template specifications, HL7
Model Interchange Format) to constrain CDA are still in development at the time of
writing this standard.

The RIM's InfrastructureRoot class contains an attribute, templateId, which is

available for use in CDA. Thus, while HL7 Templates are in flux at this time, CDA
provides a mechanism to reference a template or implementation guide that has been
assigned a unique identifier. Until there is a formal HL7 Template specification, there
is no standardized process to test conformance against referenced templates.

There is no requirement that CDA must be constrained. Implementations that use

structured data elements to drive automated processes will typically require that they
be either: (1) constrained by an appropriately refined model or other HL7 approved
constraint language; or (2) comply with a detailed implementation guide that details
the manner in which structured elements are to be represented and their intended
interpretation to a level sufficient to ensure a degree of clinical safety that is
appropriate to the use case that it is designed to address.

There are many kinds of HL7 Templates that might be created. Among them, two are particularly
relevant for clinical documents: (1) those that constrain the document sections based on the type of
document (section-level templates); (2) those that constrain the entries within document sections
(entry-level templates). In fact, a comparison can be made between the prior notion of CDA levels
and the current notion of CDA with these two kinds of HL7 Templates:

Table 1: Evolution of CDA "levels" from CDA, Release One to CDA, Release Two
CDA, Release
CDA, Release Two
One

CDA Level One The unconstrained CDA specification.

CDA Level Two The CDA specification with section-level templates applied.

CDA Level The CDA specification with entry-level (and optionally section-level)
Three templates applied.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 5/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

An illustration of one possible hierarchy of CDA plus HL7 Templates is shown here:

Example 2

CDA Schema
CDA Schema :: Progress Note section-level template applied.
CDA Schema :: Progress Note section-level and Vital Signs
entry-level template applied.
CDA Schema :: Endocrinology Progress Note section-
level and Vital Signs entry-level template applied.
CDA Schema :: Progress Note section-level and ICU
Vital Signs entry-level template applied.

CDA Schema :: Cardiology Progress Note section-level template

applied
CDA Schema :: Cardiology Progress Note section-level and
Cardiac Exam entry-level template applied.
CDA Schema :: Endocrinology Progress Note section-level
template applied.
CDA Schema :: Endocrinology Progress Note section-level
and Vital Signs entry-level template applied.

1.2.3 Human Readability and Rendering CDA Documents

The CDA requirement for human readability guarantees that a receiver of a CDA document can
algorithmically display the clinical content of the note on a standard Web browser. CDA, Release Two,
with its blend of narrative and CDA entries, presents new challenges to this requirement.

Among the requirements affecting the design of CDA Release 2 are the following:

There must be a deterministic way for a recipient of an arbitrary CDA document to render the
attested content.
Human readability shall not require a sender to transmit a special style sheet along with a CDA
document. It must be possible to render all CDA documents with a single style sheet and
general-market display tools.
Human readability applies to the authenticated content. There may be additional information
conveyed in the document that is there primarily for machine processing that is not
authenticated and need not be rendered.
When structured content is derived from narrative, there must be a mechanism to describe
the process (e.g. by author, by human coder, by natural language processing algorithm, by
specific software) by which machine-processable portions were derived from a block of
narrative.
When narrative is derived from structured content, there must be a mechanism to identify the
process by which narrative was generated from structured data.

These principles and requirements have led to the current approach, where the material to be rendered
is placed into the Section.text field (see Section Narrative Block (§ 4.3.5 )). The content model of this
field is specially hand crafted to meet the above requirements, and corresponds closely to the content
model of sections in CDA, Release One. Structured observations can reference narrative content in the
Section.text field. Multimedia observations are encoded outside the Section.text field, and the
<renderMultiMedia> tag within the Section.text field provides an outgoing pointer that indicates where
the referenced multimedia should be rendered.

1.2.4 XML Markup of CDA Documents

XML markup of CDA documents is prescribed in this specification. CDA instances are valid against the
CDA Schema and may be subject to additional validation (see CDA Conformance (§ 1.3 )). There is no
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 6/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

prohibition against multiple schema languages (e.g., W3C, DTD, RELAXNG), as long as conforming
instances are compatible.

Design Principles of the CDA Schema include:

General Requirements: The design of the CDA Schema follows the more general
requirements for CDA (see Goals and Design Principles (§ 1.1.3 )).
CDA Schema and V3 Implementation Technology Specification (ITS) : The CDA
Schema will follow the general V3 XML ITS.
RIM Mapping: The CDA Schema describes the style of XML markup of CDA instances for the
purpose of exchange. It cannot be understood outside the context of this defining
specification. At the same time, the CDA Schema is useful on its own for implementation
purposes even though it is not intended to replicate or take the place of the R-MIM and HD.
The CDA Schema, then, is not, in and of itself, an adequate map between conforming instance
and the HL7 RIM. Semantic interoperability of CDA instances requires use and knowledge of
the CDA Schema, R-MIM and HD as well as the corresponding RIM.
Document Analysis: The CDA Schema and conformant instances should adhere to the
requirements of document analysis in derivation of the content model.

NOTE: Document analysis is a process that might be thought of as the document equivalent
of a use case. Document analysis looks at a single instance or class of documents and
analyzes their structure and content, often representing this as a tree structure "elm"
notation. Document analysis also looks at the business rules for the lifecycle of that document
or document class. Traditionally, document analysis determines the content model and overall
structure and style of XML.

Document analysis is an iterative step in content model derivation -- the "bottom up"
approach to complement the "top down" derivation from the RIM. This will ensure that
schemas and instances are not only RIM-derived, but represent recognizable artifacts in a
simple manner.

Forward and Backward Compatibility: The CDA Schema should adhere to the
requirements for forward and backward compatibility. (See Backwards and Forwards
Compatibility (§ 1.5 ))
Naming: While XML markup, by definition, is for machine processing, it should be optimized
for human review, debug, and design. The CDA Schema is not "self-documenting", but
meaning should be clear from tag name and documentation (e.g., mapping to RIM). The
human-language sense of a tag name should not be counterintuitive.
Vocabulary: Vocabulary can be enumerated within the CDA Schema or in an external,
referenced source. It is preferable to enumerate it when the vocabulary terms are both limited
(not too large in number) and stable (not subject to change between ballot cycles). Where
vocabulary is either too large or is subject to change, it is preferable to maintain it external to
the CDA Schema and incorporate it by reference. In these cases, XML schema validation will
not suffice for conformance.

1.2.5 Security, Confidentiality, and Data Integrity

Application systems sending and receiving CDA documents are responsible for meeting all legal
requirements for document authentication, confidentiality, and retention. For communications over
public media, cryptographic techniques for source/recipient authentication and secure transport of
encapsulated documents may be required, and should be addressed with commercially available tools
outside the scope of this standard.

The CDA does provide confidentiality status information to aid application systems in managing access
to sensitive data. Confidentiality status may apply to the entire document or to specified segments of
the document.

1.2.6 Relationship of the CDA to HL7 Messaging Standards

A CDA document is a defined and complete information object that can exist outside of a messaging
context and/or can be a payload within an HL7 message (see CDA Document Exchange in HL7
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 7/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Messages (§ 3 )). Thus, the CDA complements HL7 messaging specifications.

Clinical documents can be revised, and they can be appended to existing documents. Ideally, an
updated document would declare itself as obsolete, and would contain an explicit pointer to a more
recent version. This would lessen the chances of a healthcare provider basing treatment decisions on
erroneous or incomplete data.

In practice, however, it is impossible to guarantee an explicit forward pointer from an outdated version
to the newer version. Without a process that tracks the chain of custody of clinical documents and all of
their copies, there can be no way to guarantee that a clinical document being viewed has not been
subsequently revised.

To minimize the risk of viewing superseded information, there is a critical interdependence between
clinical documents and document management systems. If CDA documents are viewed outside the
context of a document management system, it cannot be known with certainty whether or not the
viewed document has been revised. HL7 messages that carry CDA documents (such as the MDM
messages in HL7 V2.x and the HL7 V3 Medical Records messages) convey critical contextual
information that ensures accurate viewing of clinical data.

1.3 CDA Conformance

NOTE: See HL7 V3 Refinement and Localization for a complete discussion of V3

conformance.

A conformant CDA document is one that at a minimum validates against the CDA Schema, and that
restricts its use of coded vocabulary to values allowable within the specified vocabulary domains.
However a computer cannot validate every aspect of conformance. The focus of this section is to
highlight these aspects of CDA that cannot be machine validated - particularly those aspects related to
the CDA human readability requirements.

A document originator is an application role that creates a CDA document. CDA documents can be
created via transformation from some other format, as a direct output of an authoring application, etc.
The document originator often is responsible for communicating with a persistent storage location,
often using HL7 V2 MDM or HL7 V3 Medical Records messages. The document originator is responsible
for ensuring that generated CDA documents are fully conformant to this specification.

A document recipient is an application role that receives status updates and documents from a
document originator or document management system. The document recipient is responsible for
ensuring that received CDA documents are rendered in accordance to this specification.

Because CDA is an exchange standard and may not represent the original form of a document, there
are no persistent storage requirements for CDA documents defined in this standard. However, as noted
above (see Relationship of the CDA to HL7 Messaging Standards (§ 1.2.6 )), document management is
critically interdependent with the CDA specification. The custodian identified in the CDA header (see
custodian (§ 4.2.2.3 )) is the participant charged with maintaining the original document, which may
be in some form other than CDA.

1.3.1 Recipient Responsibilities

Assume default values where they are defined in this specification, and where the
instance does not contain a value : Where CDA defines default values, the recipient must
assume these values in the event that no value is contained in a CDA instance. (NOTE:
Default values are indicated in the body of this document by flagging them as "[default]".)
Parse and interpret the complete CDA header : A recipient of a CDA document must be
able to parse and interpret the complete CDA header. Because applications may choose to
display demographic and other CDA header data drawn from a central master directory, the
rendering of the CDA document header is at the discretion of the recipient. In addition,
rendering of the CDA document header can be dependent on local business practice and
context of use (e.g. electronic health record, de-identified scenario). Where a document
originator wants to suggest a rendering, they can include one or more XML style sheets with
an exchanged CDA document. Use of these style sheets is at the discretion of the recipient.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 8/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Parse and interpret the CDA body sufficiently to be able to render it : A recipient of a
CDA document must be able to parse and interpret the body of a CDA document sufficiently to
be able to render it, using the following rendering rules:
If the CDA Body is non-XML, it will need to be rendered with a software tool that
recognizes its particular MIME media type.
If the CDA Body is structured, the label of a section, as conveyed in the Section.title
component, must be rendered. The absence of the Section.title component signifies an
unlabeled section.
If the CDA Body is structured, the contents of the Section.text field must rendered per
the rules defined in Section Narrative Block (§ 4.3.5 ).
A recipient of a CDA document is not required to parse and interpret the complete set of CDA
entries contained within the CDA body. Within a local implementation, trading partners may
ascribe additional recipient responsibilities to parse and interpret various entries.
A recipient of a CDA document is not required to validate a CDA document against referenced
templates. Within a local implementation, trading partners may ascribe additional recipient
responsibilities for template validation.

1.3.2 Originator Responsibilities

Properly construct CDA Narrative Blocks : An originator of a CDA document must ensure
that the attested portion of the document body is structured such that a recipient, adhering to
the recipient responsibilities above, will correctly render the document. This includes:
If the CDA Body is structured, the label of a section must be conveyed in the
Section.title component. The absence of the Section.title component signifies an
unlabeled section.
If the CDA Body is structured, the attested narrative contents of a section must be
placed in the Section.text field, regardless of whether information is also conveyed in
CDA entries. Attested multimedia referenced in the narrative must be added as
ObservationMedia and/or RegionOfInterest CDA entries.
If the CDA Body is structured, the contents of the Section.text field must be created per
the rules defined in Section Narrative Block (§ 4.3.5 )
An originator of a CDA document is not required to fully encode all narrative into CDA entries
within the CDA body. Within a local implementation, trading partners may ascribe additional
originator responsibilities to create various entries.

1.4 CDA Extensibility

NOTE: See XML ITS - Informal Extensions for a complete discussion of V3 XML
Extensibility rules.

Locally-defined markup may be used when local semantics have no corresponding representation in the
CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a
clean and standard mechanism for tagging meaning that is not shared. In order to support local
extensibility requirements, it is permitted to include additional XML elements and attributes that are
not included in the CDA schema. These extensions should not change the meaning of any of the
standard data items, and receivers must be able to safely ignore these elements. Document recipients
must be able to faithfully render the CDA document while ignoring extensions.

Extensions may be included in the instance in a namespace other than the HL7v3 namespace, but must
not be included within an element of type ED (e.g., <text> within <procedure>) since the contents of
an ED datatype within the conformant document may be in a different namespace. Since all
conformant content (outside of elements of type ED) is in the HL7 namespace, the sender can put any
extension content into a foreign namespace (any namespace other than the HL7 namespace).
Receiving systems must not report an error if such extensions are present.

When these extension mechanisms mark up content of general relevance, HL7 encourages users to get
their requirements formalized in a subsequent version of the standard so as to maximize the use of
shared semantics.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 9/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

1.5 Backwards and Forwards Compatibility

NOTE: A detailed list of all changes between CDA, Release One and CDA, Release Two
can be found in the appendix (see Changes from CDA Release 1 (§ B.4 )).

The basic model of CDA, Release Two is essentially unchanged. A CDA document has a header and a
body. The body contains nested sections. These sections can be coded using standard vocabularies,
and can contain CDA entries. The main evolutionary steps in CDA, Release Two are that both header
and body are fully RIM-derived, and there is a much richer assortment of entries to use within CDA
sections. CDA, Release Two enables clinical content to be formally expressed to the extent that it is
modeled in the RIM.

This section describes the types of changes that can be introduced to a new release of CDA and CDA
principles of forward and backward compatibility. In general, changes can include the addition of new
components; a renaming of components (including XML element and attribute names in the CDA
Schema); a deprecation of components defined in a prior release; a change in cardinality of a
component (either to tighten or to loosen); or a change in a vocabulary domain of a component (to add
or change values, to change between CWE and CNE). The following set of guiding principles defines
how CDA can continue to evolve, while protecting the investment implementers have made through
their adoption of earlier releases.

Documentation : A new release of CDA will enumerate all substantive changes from the
previous release.
Attested content: Attested, human readable content must be completely loss-less across
CDA releases. Backwards and forwards compatibility on the attested content will be supported
such that it will be possible for an automated transformation script to translate the human
readable content in both directions.
New components : A new release of CDA can introduce new components. To preserve
roundtrip translation capability, a translation from the new release to a prior release must
represent the new components as extensions (e.g. local markup or local namespace).
Renaming : A new release of CDA can rename components (including XML element and
attribute names). Where this occurs, a mapping table will list all changes. Renaming will
adhere to the naming convention articulated above (see XML Markup of CDA Documents (§
1.2.4 )).
Deprecated components : A new release of CDA can deprecate components defined in a
prior release. Deprecated components will be removed from the subsequent release of the
standard, and therefore their use is not recommended.
Cardinality : A new release of CDA can change the cardinality of a component. Where an
optional component becomes required, a translation between releases requires a dummy
value or a null value.
Changes to vocabulary domain : A new release of CDA can change the vocabulary domain
of a component. Where this occurs, a mapping table will list changes.
Change within CNE : Where a value in a CNE domain in a prior release is no longer present
or has been renamed, a mapping table will indicate what the current value should be.
Change within CWE : When a CWE domain is expanded, users should begin using the new
codes in addition to any equivalent local codes they may already be using.
Change from CWE to CNE : To preserve roundtrip translation capability, a translation
between releases must represent unrecognized components as extensions (e.g. local markup
or local namespace). Ideally these situations will surface during a ballot cycle, allowing the
CNE domain to be sufficiently inclusive.

These guiding principles have lead to the current approach, defined in this Release Two of the CDA
standard. The goal is to ensure that the documents created using Release One can be transformed into
minimally compliant Release Two instances and that Release Two documents received can be down-
translated to Release One instances using automated means (transformations) with no loss of attested,
human-readable content and known limitation on loss of universal processing semantics.

2 Introduction to CDA Technical Artifacts

A complete understanding of CDA requires an understanding of the normative artifacts used to define
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 10/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

the specification. The CDA Hierarchical Description is the definitive source for CDA
conformance rules, and serves as the source from which the CDA Schema is derived. While a CDA
instance must validate against the CDA Schema, it must also adhere to the conformance rules stated in
the CDA Hierarchical Description. The CDA Hierarchical Description is derived from the CDA R-MIM,
which in turn is derived from the HL7 Reference Information Model (RIM). The HL7 RIM is the definitive
source for class and attribute definitions.

The following sections summarize the artifacts used by CDA, and how they can be used by those
seeking to implement or understand the CDA specification.

2.1 HL7 Reference Information Model

The definitive description of the HL7 Reference Information Model can be found here.

The HL7 RIM is the definitive reference source for class and attribute definitions. The CDA specification
does not exhaustively replicate RIM definitions, but instead refers the reader to the RIM for complete
definitions. While CDA may further constrain RIM definitions, at no time will CDA definitions conflict
with those in the RIM.

CDA, Release Two is derived from HL7 RIM, Version 2.07.

Where a reader needs to see the complete definition of a RIM attribute or class, they should refer to
the HL7 RIM.

2.2 HL7 V3 Data Types

HL7 defines both an abstract data type specification, which is the definitive reference, and an XML-
specific data type representation.

Data types define the structural format of the data carried within a RIM attribute and influence the set
of allowable values an attribute may assume. Some data types have very little intrinsic semantic
content. However HL7 also defines more extensive data types such as the one for an entity's name.
Every attribute in the RIM is associated with one and only one data type.

CDA, Release Two uses the HL7 V3 Data Types, Release One abstract and XML-specific specification.

A reader will often find that the XML-specific description of a data type is sufficient for implementation,
but at times will want to refer to the abstract data type specification for a more comprehensive
discussion.

2.3 HL7 Vocabulary Domains

The definitive description of HL7 V3 Vocabulary Domains can be found here.

Vocabulary domains represent value sets for coded CDA components. These domains can include HL7-
defined concepts or can be drawn from HL7-recognized coding systems such as LOINC or SNOMED. The
HL7 Vocabulary chapter is the definitive reference source for the definitions of HL7-defined concepts.
While CDA may further constrain these definitions, at no time will CDA definitions conflict with those in
the Vocabulary chapter.

Vocabulary domains have a coding strength that can be "Coded, No Extensions" (CNE), in which case
the only allowable values for the CDA component are those in stated value set; or "Coded, With
Extensions" (CWE), in which case values outside the stated value set can be used if necessary. Every
vocabulary domain has a unique HL7-assigned identifier, and every concept within a vocabulary domain
has a unique code.

Where a coded CDA component is associated with a CNE value set, the allowable values are fixed by
the standard, and are enumerated as shown in the following example:

Table 2: Value set for relatedDocument.typeCode (CNE)

Code Definition

APND (append) The current document is an addendum to the ParentDocument.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 11/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

RPLC (replace) The current document is a replacement of the ParentDocument.

XFRM (transform) The current document is a transformation of the ParentDocument.

A number of vocabulary domains and coding systems already in existence (e.g., LOINC, SNOMED) may
be used to encode concepts in CDA documents (e.g., Section.code, Observation.code). These domains
are referenced as external domains according to HL7 V3 processes. Where a coded CDA component is
associated with a CWE vocabulary domain, a preferred value set may be specified by the standard
(such as for ClinicalDocument.code or for ClinicalDocument.confidentialityCode). Where the standard
does not enumerate any values, the implementor is free to choose from any external source, such as
LOINC or SNOMED or some other realm-specific vocabulary.

Where a reader needs to see the complete definition of an HL7-defined value, they should refer to the
HL7 Vocabulary chapter.

2.4 HL7 CDA R-MIM

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

The CDA R-MIM is described below (see CDA R-MIM (§ 4 )).

HL7 specifications derived from the HL7 RIM use a process known as "cloning" to refine domain specific
models from the base HL7 RIM. When a refined model makes use of a specialization of an HL7 RIM
class, the new class in the refined model is known as a clone of the HL7 RIM class. These
specializations may further constrain the base class, for example, by specifying more restrictive
attribute cardinality or by further constraints on the allowed vocabulary values. Multiple clones of a
particular HL7 RIM class may appear in a refined model, each representing a different specialization.

The CDA R-MIM is a graphical representation of the CDA specification. It is presented using
diagramming conventions and notations that were developed by HL7 to represent the specific semantic
constructs contained in the critical, "back-bone" classes of the RIM. Although it could be represented in
UML notation, as the RIM is, the HL7 notation provides more details about the specific constraints and
class clones being represented. The HL7 diagramming convention abbreviates some relationship
conventions, enabling diagrams to be smaller and more concise and to convey more information
visually.

The CDA R-MIM is a graphical aid to understanding the specification. Because the CDA Hierarchical
Description, and subsequently the CDA Schema, are derived from the R-MIM, the R-MIM serves as a
good basis for describing the standard. The narrative description of the specific clones used by CDA is
organized to correspond with the R-MIM.

2.5 HL7 CDA Hierarchical Description

The definitive description of developing and interpreting HL7 Hierarchical Descriptions can be found
here.

The CDA HD is described below (see CDA Hierarchical Description (§ 5 )).

A Hierarchical Description is a tabular representation of the sequence of elements (i.e., classes,

attributes and associations) represented in an R-MIM and that define the structure of the instance
without reference to XML or any other implementation technology.

The CDA HD is the definitive source for CDA conformance rules, and serves as the source from which
the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also
adhere to the conformance rules stated in the CDA Hierarchical Description. For CDA, Release Two, the
CDA HD is uniquely identified by the string "POCD_HD000040". As described below (see Clinical
Document (§ 4.1 )), this value must be included in a CDA instance to serve as an unambiguous
reference to the CDA, Release Two specification.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 12/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

2.6 HL7 CDA XML Implementation

The CDA Schema is derived through the use of the HL7 XML Implementation Technology Specification
(ITS). The definitive description of HL7 XML ITS and the process used to go from Hierarchical
Description to Schema can be found here.

The CDA Schema is described below (see CDA XML Implementation (§ 6 )).

CDA, Release Two is based on the HL7 V3 XML Implementable Technology Specification for V3
Structures, Release One.

Specific enhancements to the CDA Schema, above and beyond those defined in the HL7 V3 XML ITS,
are described below in CDA XML Implementation (§ 6 ).

Looking at the CDA R-MIM, a reader familiar with the RIM, the HL7 Development Framework and its
rules for XML implementations, can identify the corresponding XML elements and attributes. Due to
algorithmic generation of some of the element names, the correspondence may be unclear, and the
reader should refer to the HL7 V3 XML ITS for more details.

3 CDA Document Exchange in HL7 Messages

NOTE: The exact method by which a CDA instance is packaged and exchanged is
outside the scope of this standard. While the MIME packaging method described here is
not normative, it does illustrate one mechanism that meets the document exchange
requirements described below.

Any CDA exchange strategy must accommodate the following requirements:

All components of a CDA document that are integral to its state of wholeness (such as
attested multimedia) are able to be included in a single exchange package.
Content needing to be rendered if exchanging across a firewall where the links won't be
traversable, must be able to be included in a single exchange package.
Additional files associated with a CDA document to provide the recipient with the sender's
rendering suggestions (such as one or more style sheets) are able to be included in a single
exchange package.
There is no need to change any of the references (e.g., a reference to attested multimedia in a
separate file) within the base CDA document when creating the exchange package.
There is no need to change any of the references (e.g., a reference to attested multimedia in a
separate file) within the base CDA document when extracting the contents of an exchange
package.
There is no need to change any values of attributes of type XML ID when creating the
exchange package.
There are no restrictions on the directory structure used by receivers. Receivers can place the
components of the CDA document into directories of their choosing.
Critical metadata about the CDA instance needed for document management (e.g. document
state, document archival status) must be included in the exchange package. (For a complete
discussion of clinical document metadata, document management, and HL7 V3 document
states and state transitions, refer to the HL7 V3 Medical Records specification).

From the perspective of a V2.x or V3 message, a CDA document can be thought of as a multimedia
object that can be exchanged as a Multipurpose Internet Mail Extensions (MIME, RFC 2046) package,
encoded as an encapsulated data type (ED).

The current MIME recommendation is to follow the approach described in the Internet standard RFC
2557 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", which is the approach
for the MIME encapsulations of aggregate documents used by ebXML and DICOM.

In V2.x, CDA documents are to be exchanged in the OBX segment, in any message that can exchange
documents (such as MDM). Within the OBX segment, the MIME package is placed in OBX.5 (Field
00573 Observation value), encoded as a V2.x encapsulated data type. The value of OBX.2 (Field 00570
Value Type) should be set to "ED". The value of OBX.3 should be the same as ClinicalDocument.code.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 13/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Many fields in the message will overlap in meaning with fields in the CDA document. The following table
shows the correspondence between the HL7 V2 MDM message's TXA segment and components of CDA.

Table 3: HL7 V2 TXA Segment :: CDA Mapping

TXA Field CDA Component

TXA-2 Document type ClinicalDocument.code

TXA-4 Activity date/time ServiceEvent.effectiveTime

TXA-5 Primary activity provider code/name ServiceEvent performer

TXA-6 Origination date/time ClinicalDocument.effectiveTime

TXA-7 Transcription date/time dataEnterer.time

TXA-9 Originator code/name author

TXA-11 Transcriptionist code/name dataEnterer

TXA-12 Unique document number ClinicalDocument.id

TXA-13 Parent document number ParentDocument.id

TXA-14 Placer order number Order.id

TXA-18 Document confidentiality status ClinicalDocument.confidentialityCode

TXA-22 Authentication person, time stamp authenticator, legalAuthenticator

TXA-23 Distributed copies informationRecipient

The following example shows a non-normative, valid use of RFC 2557 in a V2 message. Several other
valid representations are possible.

Example 3
MSH|...
EVN|...
PID|...
PV1|...
TXA|...
OBX|1|ED|11492-6^History and Physical^LN||
^multipart^related^A^
MIME-Version: 1.0
Content-Type: multipart/related; boundary="HL7-CDA-boundary";
type="text/xml"; start="10.12.45567.43"
Content-Transfer-Encoding: BASE64

--HL7-CDA-boundary
Content-Type: text/xml; charset="US-ASCII"
Content-ID: &lt;10.12.45567.43>

... Base 64 of base CDA document, which contains

...
<observationMedia classCode="OBS" moodCode="EVN">
<id root="10.23.4567.345"/>
<value mediaType="image/jpeg">
<reference value="left_hand_image.jpeg"/>
</value>
</observationMedia>
...

--HL7-CDA-boundary

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 14/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0
Content-ID: &lt;10.23.4567.345>
Content-Location: canned_left_hand_image.jpeg
Content-Type: image/JPEG

... Base64 image ...

--HL7-CDA-boundary--

...

In V3, CDA documents can be exchanged in any message that can exchange documents (such as the
HL7 V3 Medical Records messages). The Act.text RIM attribute contains the MIME package, encoded as
an encapsulated data type.

As is the case with V2, many fields in the V3 message will overlap in meaning with fields in the CDA
document. Since CDA and V3 Medical Records messages derive from a common model, the
correspondence is clear, as shown in the following table.

Table 4: HL7 V3 Medical Records :: CDA Mapping

HL7 V3 Medical
Records CDA Component Comments
Component

Medical Records includes attributes not

present in CDA (text, statusCode,
availabilityTime, reasonCode,
ClinicalDocument ClinicalDocument
completioncode, storageCode, copyTime);
CDA includes attributes not present in
Medical Records (title).

authenticator authenticator

legalAuthenticator legalAuthenticator

dataEnterer dataEnterer

encompassingEncounter
EncounterEvent / / encounterParticipant; The Medical Records encounterPerformer
encounterPerformer serviceEvent / is split into two CDA participants.
performer

responsibleParty responsibleParty

custodian custodian

participant participant

informationRecipient informationRecipient

recordTarget recordTarget

author author

The Medical Records subject is a directory

subject subject
of all subjects listed in the document.

relatedDocument / relatedDocument /
ParentDocument parentDocument

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 15/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

HL7 V3 Medical
Records CDA Component Comments
Component

documentationOf / documentationOf /
Event serviceEvent

inFulfillmentOf /
inFulfillmentOf / order
Order

componentOf / componentOf /
EncounterEvent encompassingEncounter

The following example shows a non-normative, valid use of RFC 2557 in a V3 message. Several other
valid representations are possible.

Example 4
<someMessage>
<Act.Code code="11488-4"
codeSystem="2.16.840.1.113883.6.1"
displayName="Consultation note"/>
<Act.text type="multipart/related">
MIME-Version: 1.0
Content-Type: multipart/related; boundary="HL7-CDA-boundary";
type="text/xml"; start="10.12.45567.43"
Content-Transfer-Encoding: BASE64

--HL7-CDA-boundary
Content-Type: text/xml; charset="US-ASCII"
Content-ID: &lt;10.12.45567.43>

... Base 64 of base CDA document, which contains

...
<observationMedia classCode="OBS" moodcode="EVN">
<id root="10.23.4567.345"/>
<value mediaType="image/jpeg">
<reference value="left_hand_image.jpeg"/>
</value>
</observationMedia>
...

--HL7-CDA-boundary
Content-ID: &lt;10.23.4567.345>
Content-Location: canned_left_hand_image.jpeg
Content-Type: image/JPEG

... Base64 image ...

--HL7-CDA-boundary--

</Act.text>
</someMessage>

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

The CDA R-MIM POCD_RM000040 can be found here: Link to wide graphic (opens in a new window)

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.

4.1 Clinical Document

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 16/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

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.

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.

The ClinicalDocument class inherits various attributes from the InfrastructureRoot class of the RIM,
including ClinicalDocument.templateId and ClinicalDocument.typeId. When
ClinicalDocument.templateId is valued in an instance, it signals the imposition of a set of template-
defined constraints. In addition, the templateId attribute is available in all other CDA classes, thus
enabling the imposition of a set of template-defined constraints at any level of granularity. The value of
this attribute provides a unique identifier for the template(s) in question.

ClinicalDocument.typeId is a technology-neutral explicit reference to this CDA, Release Two

specification, and must be valued as follows: ClinicalDocument.typeId.root = "2.16.840.1.113883.1.3"
(which is the OID for HL7 Registered models); ClinicalDocument.typeId.extension =
"POCD_HD000040" (which is the unique identifier for the CDA, Release Two Hierarchical Description).

4.2 Header

The purpose of the CDA header is to enable clinical document exchange across and within institutions;
facilitate clinical document management; and facilitate compilation of an individual patient's clinical
documents into a lifetime electronic patient record.

4.2.1 Header Attributes

This section describes attributes of the root ClinicalDocument class.

Table 5: Value set for ClinicalDocument.classCode (CNE)

Code Definition

DOCCLIN A clinical document is a documentation of clinical observations and

[default] services, as defined above.

Table 6: Value set for ClinicalDocument.moodCode (CNE)

Code Definition

EVN
An actual occurrence of an event (i.e., the documentation act already
(event)
happened and is not just a request, intent, plan or promise to document).
[default]

4.2.1.1 ClinicalDocument.id

Represents the unique instance identifier of a clinical document.

4.2.1.2 ClinicalDocument.code

The code specifying the particular kind of document (e.g. History and Physical, Discharge Summary,
Progress Note). The value set is drawn from LOINC, and has a CWE coding strength.

Within the LOINC database, beginning with version 2.09, May 2003, document type codes are those
that have a value of "DOC" in the Scale component. This subset of LOINC is included in the appendix
(see LOINC Document Codes (§ B.2 )).

NOTE: The hierarchical relationship among LOINC document codes is in evolution. Per
the LOINC version 2.14 (December 2004) manual: As soon as possible, the component
terms used in the creation of the names of document type codes will be mapped to
either the UMLS Metathesaurus or SNOMED CT. This mapping will help to establish the
meaning of the terms and will allow aggregation and classification of document type

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 17/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

codes based on definitions, computable relationships, and subsumption hierarchies that

exist in the reference terminology.
4.2.1.3 ClinicalDocument.title

Represents the title of the document. It's commonly the case that clinical documents do not have a
title, and are collectively referred to by the display name of ClinicalDocument.code (e.g. a
"consultation" or "progress note"). Where these display names are rendered to the clinician, or where
the document has a unique title, the ClinicalDocument.title component should be used. In the example
document in the appendix (see Sample Document (§ A.1 )), the value of ClinicalDocument.title =
"Good Health Clinic Consultation Note".

4.2.1.4 ClinicalDocument.effectiveTime

Signifies the document creation time, when the document first came into being. Where the CDA
document is a transform from an original document in some other format, the
ClinicalDocument.effectiveTime is the time the original document is created. The time when the
transform occurred is not currently represented in CDA.

4.2.1.5 ClinicalDocument.ConfidentialityCode

Confidentiality is a required contextual component of CDA, where the value expressed in the header
holds true for the entire document, unless overridden by a nested value (as further described in CDA
Context (§ 4.4 )).

Table 7: Value set for ClinicalDocument.confidentialityCode (CWE)

Code * Definition

Normal confidentiality rules (according to good health care

N (normal) (codeSystem
practice) apply. That is, only authorized individuals with a
2.16.840.1.113883.5.25)
legitimate medical or business need may access this item.

R (restricted)
Restricted access, e.g. only to providers having a current care
(codeSystem
relationship to the patient.
2.16.840.1.113883.5.25)

V (very restricted)
Very restricted access as declared by the Privacy Officer of the
(codeSystem
record holder.
2.16.840.1.113883.5.25)

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must
carry both a code and a codeSystem.

4.2.1.6 ClinicalDocument.languageCode

Specifies the human language of character data (whether they be in contents or attribute values). The
values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force)
RFC 3066 for the Identification of Languages, ed. H. Alvestrand. 1995, which obsoletes RFC 1766. The
HL7 code system for these values is "2.16.840.1.113883.6.121". Language is a contextual component
of CDA, where the value expressed in the header holds true for the entire document, unless overridden
by a nested value (as further described in CDA Context (§ 4.4 )).

4.2.1.7 ClinicalDocument.setId

Represents an identifier that is common across all document revisions.

4.2.1.8 ClinicalDocument.versionNumber

An integer value used to version successive replacement documents.

4.2.1.9 ClinicalDocument.copyTime (Deprecated)

Represents the time a document is released (i.e. copied or sent to a display device) from a document

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 18/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

management system that maintains revision control over the document. Once valued, it cannot be
changed. The intent is to give the viewer of the document some notion as to how long the document
has been out of the safe context of its document management system.

Included for backwards compatibility with CDA, Release One. ClinicalDocument.copyTime has been
deprecated because it is not part of the document at the time it is authenticated, but instead
represents metadata about the document, applied at some variable time after authentication. Further
use is discouraged.

4.2.2 Header Participants

This section describes classes related to the root ClinicalDocument class via a Participation.

4.2.2.1 authenticator

Represents a participant who has attested to the accuracy of the document, but who does not have
privileges to legally authenticate the document. An example would be a resident physician who sees a
patient and dictates a note, then later signs it. (See also legalAuthenticator (§ 4.2.2.8 ))

A clinical document can have zero to many authenticators. While electronic signatures are not captured
in a CDA document, both authentication and legal authentication require that a document has been
signed manually or electronically by the responsible individual. An authenticator has a required
authenticator.time indicating the time of authentication, and a required authenticator.signatureCode,
indicating that a signature has been obtained and is on file.

Table 8: Value set for authenticator.typeCode (CNE)

Code Definition

AUTHEN
A verifier who attests to the accuracy of an act, but who does not
(authenticator)
have privileges to legally authenticate the act.
[default]

Table 9: Value set for authenticator.signatureCode (CNE)

Code Definition

S (signed) Signature has been affixed and is on file.

CDA Release One represented either an intended ("X") or actual ("S")

X (required)
authenticator. CDA Release Two only represents an actual authenticator, so
(Deprecated)
has deprecated the value of "X".

An authenticator is a person in the role of an assigned entity (AssignedEntity class). An assigned entity
is a person assigned to the role by the scoping organization. The entity playing the role is a person
(Person class). The entity scoping the role is an organization (Organization class). (See here for a
description of "player" and "scoper" role associations.)

Table 10: Value set for AssignedEntity.classCode (CNE)

Code Definition

ASSIGNED An agent role in which the agent is an entity acting in the employ of an
(Assigned) organization. The focus is on the functional role on behalf of the
[default] organization.

Table 11: Value set for Person.classCode (CNE)

Code Definition

PSN (person) [default] A living subject of the species homo sapiens.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 19/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0
Table 12: Value set for Person.determinerCode (CNE)
Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(instance)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

Table 13: Value set for Organization.classCode (CNE)

Code Definition

ORG (organization) [default] A social or legal structure formed by human beings.

Table 14: Value set for Organization.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(Assigned)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

A scoping organization can be part of a larger organization. Where there is a need to include whole-
part relationships, the OrganizationPartOf role can be used. OrganizationPartOf.statusCode indicates
the state of the whole-part relationship (e.g. "active", "terminated"). OrganizationPartOf.effectiveTime
is an interval of time specifying the period during which the whole-part relationhship is in effect, if such
time limit is applicable and known.

Table 15: Value set for OrganizationPartOf.classCode (CNE)

Code Definition

PART (part) An association between two Entities where the playing Entity is part of
[default] the scoping entity.

Table 16: Value set for OrganizationPartOf.statusCode (CNE)

Code Definition

normal The 'typical' state. Excludes "nullified" which represents the termination
(normal) state of a Role instance that was created in error.

The state representing the fact that the Entity is currently active in the
active (active)
Role.

cancelled The terminal state resulting from cancellation of the role prior to
(cancelled) activation.

pending
The state representing that fact that the role has not yet become active.
(pending)

suspended The state that represents a suspension of the Entity playing the Role. This
(suspended) state is arrived at from the "active" state.

terminated
The state representing the successful termination of the Role.
(terminated)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 20/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

nullified The state representing the termination of a Role instance that was created
(nullified) in error.

4.2.2.2 author

Represents the humans and/or machines that authored the document.

In some cases, the role or function of the author is inherent in the ClinicalDocument.code, such as
where ClinicalDocument.code is "Medical Student Progress Note". The role of the author can also be
recorded in the Author.functionCode or AssignedAuthor.code attribute. If either of these attributes is
included, they should be equivalent to or further specialize the role inherent in the
ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Physician Progress Note"
and the value of Author.functionCode is "rounding physician"), and shall not conflict with the role
inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

Table 17: Value set for author.typeCode (CNE)

Code Definition

AUT (author) A party that originates the Act and therefore has responsibility for the
[default] information given in the Act.

Table 18: Value set for author.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

An author is a person in the role of an assigned author (AssignedAuthor class). The entity playing the
role is a person (Person class) or a device (AuthoringDevice class). The entity scoping the role is an
organization (Organization class), and is the organization from which the document originates.

Table 19: Value set for AssignedAuthor.classCode (CNE)

Code Definition

ASSIGNED (assigned A role in which the playing entity is acting in the employ of or
entity) [default] on behalf of a scoping organization.

Table 20: Value set for AuthoringDevice.classCode (CNE)

Code Definition

DEV (device) An entity used in an activity, without being substantially changed

[default] through that activity.

Table 21: Value set for AuthoringDevice.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(Assigned)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 21/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

NOTE: In CDA, Release One, it was possible to specify those individuals responsible for
the device. This functionality has been deprecated in CDA, Release Two. The
MaintainedEntity class is present for backwards compatibility, and its use is
discouraged, except where needed to support the transformation of CDA, Release One
documents.
Table 22: Value set for MaintainedEntity.classCode(CNE)
Code Definition

MNT
An entity that is maintained by another entity. This is typically a role held
(maintained
by durable equipment. The scoper assumes responsibility for proper
entity)
operation, quality, and safety.
[default]

4.2.2.3 custodian

Represents the organization that is in charge of maintaining the document. The custodian is the
steward that is entrusted with the care of the document. Every CDA document has exactly one
custodian.

The custodian participation satisfies the CDA definition of Stewardship (see What is the CDA (§ 1.1 )).
Because CDA is an exchange standard and may not represent the original form of the authenticated
document, the custodian represents the steward of the original source document.

Table 23: Value set for custodian.typeCode (CNE)

Code Definition

CST (custodian) [default] An organization that is in charge of maintaining this document.

A custodian is a scoping organization in the role of an assigned custodian (AssignedCustodian class).

The steward organization (CustodianOrganization class) is an entity scoping the role of
AssignedCustodian, and has a required CustodianOrganization.id.

Table 24: Value set for AssignedCustodian.classCode (CNE)

Code Definition

ASSIGNED (assigned A role in which the playing entity is acting in the employ of or
entity) [default] on behalf of a scoping organization.

Table 25: Value set for CustodianOrganization.classCode (CNE)

Code Definition

ORG (organization) [default] A social or legal structure formed by human beings.

Table 26: Value set for CustodianOrganization.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(Assigned)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

4.2.2.4 dataEnterer (Transcriptionist)

Represents the participant who has transformed a dictated note into text.
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 22/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Table 27: Value set for dataEnterer.typeCode (CNE)

Code Definition

ENT A person entering the data into the originating system. The data entry
(transcriptionist) person is collected optionally for internal quality control purposes. This
[default] includes the transcriptionist for dictated text.

Table 28: Value set for dataEnterer.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

4.2.2.5 encounterParticipant

See EncompassingEncounter (§ 4.2.3.5 ) for a description of the encounterParticipant participant.

4.2.2.6 informant

An informant (or source of information) is a person that provides relevant information, such as the
parent of a comatose patient who describes the patient's behavior prior to the onset of coma.

Table 29: Value set for informant.typeCode (CNE)

Code Definition

INF A source of reported information (e.g., a next of kin who answers questions
(informant) about the patient's history). For history questions, unless otherwise stated,
[default] the patient is implicitly the informant.

Table 30: Value set for informant.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

An informant can be a person in one of two roles. The RelatedEntity role is used to represent an
informant without a role.id (e.g. a parent or guy on the street). The informant in this case bears some
formal or personal relationship to the patient. The role is unscoped, with the assumption that the
patient is always the implied scoper. RelatedEntity.code can be used to specify the nature of the
relationship. The AssignedEntity role is used for an identified informant, and is scoped by an
Organization.

Table 31: Value set for RelatedEntity.classCode (CNE)

Code Definition

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 23/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

A role of an entity that has some mutual relationship with

the patient. The basis of such relationship may be
agreements (e.g., spouses, contract parties) or they may be
de facto behavior (e.g. friends) or may be an incidental
Any subtype of involvement with each other (e.g. parties over a dispute,
RoleClassMutualRelationship siblings, children).

See vocabulary domain "RoleClassMutualRelationship" for

allowable values.

4.2.2.7 informationRecipient

Represents a recipient who should receive a copy of the document.

NOTE: The information recipient is an entity to whom a copy of a document is directed,

at the time of document authorship. It is not the same as the cumulative set of persons
to whom the document has subsequently been disclosed, over the life-time of the
patient. Such a disclosure list would not be contained within the document, and it
outside the scope of CDA.
Table 32: Value set for informationRecipient.typeCode (CNE)
Code Definition

PRCP (primary recipient)

Recipient to whom the document is primarily directed.
[default]

A secondary recipient to whom the document is

TRC (secondary recipient)
directed.

Where a person is the intended recipient (IntendedRecipient class), the playing entity is a person
(Person class), optionally scoped by an organization (Organization class). Where the intended recipient
is an organization, the IntendedRecipient.classCode is valued with "ASSIGNED", and the recipient is
reflected by the presence of a scoping Organization, without a playing entity. Where a health chart is
the intended recipient, the IntendedRecipient.classCode is valued with "HLTHCHRT" (health chart). In
this case there is no playing entity, and an optional scoping organization (Organization class).

Table 33: Value set for IntendedRecipient.classCode (CNE)

Code Definition

ASSIGNED (assigned A role in which the playing entity is acting in the employ of or
entity) [default] on behalf of a scoping organization.

HLTHCHRT (health A role in which the playing entity is a physical health chart
chart) belonging to the scoping organization.

4.2.2.8 legalAuthenticator

Represents a participant who has legally authenticated the document.

The CDA is a standard that specifies the structure of exchanged clinical documents. In the case where
a local document is transformed into a CDA document for exchange, authentication occurs on the local
document, and that fact is reflected in the exchanged CDA document. A CDA document can reflect the
unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when
no authentication information has been recorded (i.e., it is the absence of being either authenticated or
legally authenticated).

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 24/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

While electronic signatures are not captured in a CDA document, both authentication and legal
authentication require that a document has been signed manually or electronically by the responsible
individual. A legalAuthenticator has a required legalAuthenticator.time indicating the time of
authentication, and a required legalAuthenticator.signatureCode, indicating that a signature has been
obtained and is on file.

Table 34: Value set for legalAuthenticator.typeCode (CNE)

Code Definition

LA (legal A verifier who legally authenticates the accuracy of an act. An example

authenticator) would be a staff physician who sees a patient and dictates a note, then
[default] later signs it. Their signature constitutes a legal authentication.

Table 35: Value set for legalAuthenticator.signatureCode (CNE)

Code Definition

S (signed) Signature has been affixed and is on file.

CDA Release One represented either an intended ("X") or actual ("S") legal
X (required)
authenticator. CDA Release Two only represents an actual legal
(Deprecated)
authenticator, so has deprecated the value of "X".

Table 36: Value set for legalAuthenticator.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

A legalAuthenticator is a person in the role of an assigned entity (AssignedEntity class). An assigned

entity is a person assigned to the role by the scoping organization. The entity playing the role is a
person (Person class). The entity scoping the role is an organization (Organization class).

4.2.2.9 participant

Used to represent other participants not explicitly mentioned by other classes, that were somehow
involved in the documented acts.

Table 37: Value set for participant.typeCode (CNE)

Code Definition

Any ParticipationType See vocabulary domain "ParticipationType" for allowable

subtype values.

Table 38: Value set for participant.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

A participant is a person or organization in the role of a participating entity (AssociatedEntity class).

The entity playing the role is a person (Person class). The entity scoping the role is an organization

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 25/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

(Organization class).

Table 39: Value set for AssociatedEntity.classCode (CNE)

Code Definition

Any RoleClassAssociative See vocabulary domain "RoleClassAssociative" for allowable

subtype values.

When the participating entity is an organization, this is reflected by the presence of a scoping
Organization, without a playing entity.

4.2.2.10 performer

See ServiceEvent (§ 4.2.3.2 ) for a description of the performer participant.

4.2.2.11 recordTarget

The recordTarget represents the medical record that this document belongs to.

A clinical document typically has exactly one recordTarget participant. In the uncommon case where a
clinical document (such as a group encounter note) is placed into more than one patient chart, more
than one recordTarget participants can be stated.

The recordTarget(s) of a document are stated in the header and propagate to nested content, where
they cannot be overridden (see See CDA Context (§ 4.4 )).

Table 40: Value set for recordTarget.typeCode (CNE)

Code Definition

RCT (record target) The record target indicates whose medical record holds the
[default] documentation of this act.

Table 41: Value set for recordTarget.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

A recordTarget is represented as a relationship between a person and an organization, where the

person is in a patient role (PatientRole class). The entity playing the role is a patient (Patient class).
The entity scoping the role is an organization (Organization class). A patient is uniquely identified via
the PatientRole.id attribute.

CDA Release One allowed for additional person identifiers, corresponding to the Patient.id attribute in
CDA Release Two. This attribute is included for backwards compatibility and has been deprecated
because having two different ways to identify a patient can result in inconsistent usage. Further use of
Patient.id is discouraged.

Table 42: Value set for PatientRole.classCode (CNE)

Code Definition

PAT (patient) [default] A person that receives health care services from a provider.

Table 43: Value set for Patient.classCode (CNE)

Code Definition

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 26/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

PSN (person) [default] A living subject of the species homo sapiens.

Table 44: Value set for Patient.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(instance)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

A patient's language communication skills can be expressed in the associated LanguageCommunication

class. A Patient's birthplace is represented as a relationship between a patient and a place. The
Birthplace class is played by a place (Place class), and scoped by the patient (Patient class).

Table 45: Value set for Birthplace.classCode (CNE)

Code Definition

BIRTHPL (birthplace) Relates a place as the location where a living subject was
[default] born.

Table 46: Value set for Place.classCode (CNE)

Code Definition

PLC (place) [default] A physicial place or site with its containing structure.

Table 47: Value set for Place.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(instance)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

A patient's guardian is a person or organization in the role of guardian (Guardian class). The entity
playing the role of guardian is a person (Person class) or organization (Organization class). The entity
scoping the role is the patient (Patient class).

Where a guardian is not explicitly stated, the value should default to local business practice (e.g. the
patient makes their own health care decisions unless incapacitated in which case healthcare decisions
are made by the patient's spouse).

Table 48: Value set for Guardian.classCode (CNE)

Code Definition

GUARD (guardian) An entity (player) that acts or is authorized to act as the guardian
[default] of the patient.

4.2.2.12 responsibleParty

See EncompassingEncounter (§ 4.2.3.5 ) for a description of the responsibleParty participant.

4.2.2.13 Participant Scenarios

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 27/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Several CDA Header participations can be played by the same person. In such cases, the person should
be identified as the player for each appropriate participation. For instance, if a person is both the
author and the authenticator of a document, the CDA Header should identify that person as both the
author participant and the authenticator participant.

On other occasions, CDA Header participants are played by different people. The following table shows
a number of scenarios and the values for various participants.

Table 49: CDA participation scenarios

1. StaffPhysicianOne sees a patient as a consultant, dictates a note, and later signs it.

Author — StaffPhysicianOne
Encounter Participant — StaffPhysicianOne (typeCode="CONS")
Legal Authenticator — StaffPhysicianOne

2. StaffPhysicianOne sees a patient and dictates a note. StaffPhysicianTwo later signs the
note. *

Author — StaffPhysicianOne
Legal Authenticator — StaffPhysicianTwo

3. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and

later signs it. The note is co-signed by StaffPhysicianOne. *

Author — ResidentOne
Authenticator — ResidentOne
Encounter Participant — StaffPhysicianOne (typeCode="ATND")
Legal Authenticator — StaffPhysicianOne

4. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and

later signs it. The note is co-signed by StaffPhysicianTwo. *

Author — ResidentOne
Authenticator — ResidentOne
Encounter Participant — StaffPhysicianOne (typeCode="ATND")
Legal Authenticator — StaffPhysicianTwo

5. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, and

goes off on vacation. The note is signed by ResidentTwo and by StaffPhysicianOne. *

Author — ResidentOne
Authenticator — ResidentTwo
Encounter Participant — StaffPhysicianOne (typeCode="ATND")
Legal Authenticator — StaffPhysicianOne

6. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, which

is later signed by ResidentTwo and StaffPhysicianTwo. *

Author — ResidentOne
Authenticator — ResidentTwo
Encounter Participant — StaffPhysicianOne (typeCode="ATND")
Legal Authenticator — StaffPhysicianTwo

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 28/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

7. StaffPhysicianOne receives an abnormal lab result, attempts to contact patient but

can't, and writes and signs a progress note.

Author — StaffPhysicianOne
Legal Authenticator — StaffPhysicianOne

8. ResidentSurgeonOne is operating on a patient with StaffSurgeonOne. StaffSurgeonOne

dictates an operative report and later signs it.

Author — StaffSurgeonOne
Authenticator — null (need not be included)
Legal Authenticator — StaffSurgeonOne
Performer — StaffSurgeonOne (typeCode="PPRF")
Performer — ResidentSurgeonOne (typeCode="SPRF")

* Note that the ability of one clinician to co-sign or to sign on behalf of another clinician is subject to
regulatory and local practice constraints.

4.2.3 Header Relationships

This section describes classes related to the root ClinicalDocument class via an ActRelationship.

4.2.3.1 ParentDocument

The ParentDocument represents the source of a document revision, addenda, or transformation.

ParentDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of
the parent document. It is not to be used to embed the related document, and thus
ParentDocument.text.BIN is precluded from use.

Allowable values for the intervening relatedDocument.typeCode are shown in the following table.

Table 50: Value set for relatedDocument.typeCode (CNE)

Code Definition

APND (append) The current document is an addendum to the ParentDocument.

RPLC (replace) The current document is a replacement of the ParentDocument.

XFRM (transform) The current document is a transformation of the ParentDocument.

A conformant CDA document can have a single relatedDocument with typeCode "APND"; a single
relatedDocument with typeCode "RPLC"; a single relatedDocument with typeCode "XFRM"; a
combination of two relatedDocuments with typeCodes "XFRM" and "RPLC"; or a combination of two
relatedDocuments with typeCodes "XFRM" and "APND". No other combinations are allowed.

Table 51: Value set for ParentDocument.classCode (CNE)

Code Definition

DOCCLIN (clinical document) [default] A clinical document.

Table 52: Value set for ParentDocument.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 29/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Document Identification, Revisions, and Addenda

A clinical document can be replaced by a new document and/or appended with an addendum.

A replacement document is a new version of the parent document. The parent document is considered
superseded, but a system may retain it for historical or auditing purposes. The parent document being
replaced is referenced via act relationship relatedDocument, where relatedDocument.typeCode is set to
equal "RPLC" (for "replaces"). An example is a report found to contain an error that is subsequently
replaced by the corrected report.

An addendum is a separate document that references the parent document, and may extend or alter
the observations in the prior document. The parent document remains a current component of the
patient record, and the addendum and its parent are both read by report recipients. The parent report
(represented by the ParentDocument class) being appended is referenced via act relationship
relatedDocument, where relatedDocument.typeCode is set to equal "APND" (for "appends").

Every CDA document must have a unique ClinicalDocument.id, and thus the replacement or addendum
documents each have ClinicalDocument.id that is different from that of the parent document.

CDA documents may also contain a ClinicalDocument.setId and a ClinicalDocument.versionNumber,

which together support a document identification and versioning scheme used in some document
management systems. In this scheme, all documents in a chain of replacements have the same
ClinicalDocument.setId and are distinguished by an incrementing ClinicalDocument.versionNumber. The
initial version of a document gets, in addition to a new unique value for ClinicalDocument.id, a new
value for ClinicalDocument.setId, and has the value of ClinicalDocument.versionNumber set to equal
"1". A replacement document gets a new globally unique ClinicalDocument.id value, and uses the same
value for ClinicalDocument.setId as the parent report being replaced, and increments the value of
ClinicalDocument.versionNumber by 1. (Note that version number must be incremented by one when a
report is replaced, but can also be incremented more often to meet local requirements.)

These relationships are illustrated in the following exhibit "Document Identification, Revisions, and
Addenda Scenarios". Typical scenarios are a simple relacement (e.g. ClinicalDocument.id
"1.2.345.6789.266" replacing ClinicalDocument.id "1.2.345.6789.123") and a simple append (e.g.
ClinicalDocument.id "1.2.345.6789.456" appends ClinicalDocument.id "1.2.345.6789.123"). More
complex scenarios that might be anticipated include: [1] replacement of an addendum (e.g.
ClinicalDocument.id "1.2.345.6789.224" replaces ClinicalDocument.id "1.2.345.6789.456", which itself
is an addendum to ClinicalDocument.id "1.2.345.6789.123") - expected behavior would be to render
the replacement as the addendum (e.g. render ClinicalDocument.id "1.2.345.6789.224" as the
addendum to ClinicalDocument.id "1.2.345.6789.123"); [2] addendum to a replaced document (e.g.
ClinicalDocument.id "1.2.345.6789.456" appends ClinicalDocument.id "1.2.345.6789.123", which has
been replaced by ClinicalDocument.id "1.2.345.6789.266") - expected behavior would be to render the
addendum along with the replacement (e.g. render ClinicalDocument.id "1.2.345.6789.456" as an
addendum to ClinicalDocument.id "1.2.345.6789.266").

Document transformations

A CDA document can be a transformation from some other format, meaning that it has undergone a
machine translation from some other format (such as DICOM SR). In this case,
relatedDocument.typeCode should be set to "XFRM".

A proper transformation must ensure that the human readable clinical content of the report is not
impacted. Local business rules determine whether or not a transformed report replaces the source, but
typically this would not be the case. If it is, an additional relationship of type "RPLC" is to be used. The
"XFRM" relationship can also be used when translating a document in a local format into CDA for the
purpose of exchange. In this case, the target of the "XFRM" relationship is the local document identifier.

Link to wide graphic (opens in a new window)

4.2.3.2 ServiceEvent

This class represents the main Act, such as a colonoscopy or an appendectomy, being documented.

In some cases, the ServiceEvent is inherent in the ClinicalDocument.code, such as where

ClinicalDocument.code is "History and Physical Report" and the procedure being documented is a
"History and Physical" act. A ServiceEvent can further specialize the act inherent in the
ClinicalDocument.code, such as where the ClinicalDocument.code is simply "Procedure Report" and the
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 30/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

procedure was a "colonoscopy". If ServiceEvent is included, it must be equivalent to or further

specialize the value inherent in the ClinicalDocument.code, and shall not conflict with the value
inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

ServiceEvent.effectiveTime can be used to indicate the time the actual event (as opposed to the
encounter surrounding the event) took place.

Table 53: Value set for documentationOf.typeCode (CNE)

Code Definition

DOC (documents) The current document is a documentation of the related

[default] ServiceEvent.

Table 54: Value set for ServiceEvent.classCode (CNE)

Code Definition

ACT (act) [default] A healthcare service.

Any ACT subtype See vocabulary domain "ActClassRoot" for allowable values.

Table 55: Value set for ServiceEvent.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

The performer participant represents clinicians who actually and principally carry out the ServiceEvent.
Performer.time can be used to specify the time during which the performer is involved in the activity.
Performer.functionCode can be used to specify addition detail about the function of the performer (e.g.
scrub nurse, third assistant). Its value set is drawn from the ParticipationFunction vocabulary domain,
and has a CWE coding strength.

Table 56: Value set for performer.typeCode (CNE)

Code Definition

PRF
A person who actually and principally carries out an action.
(performer)

PPRF
(primary The principal performer of the ServiceEvent.
performer)

SPRF A person assisting in the ServiceEvent through their substantial presence

(secondary and involvement. This may include assistants, technicians, associates, or
performer) other performers.

A performer is an entity in the role of assigned entity (AssignedEntity class). An assigned entity is a
person assigned to the role by the scoping organization. The entity playing the role is a person (Person
class). The entity scoping the role is an organization (Organization class).

4.2.3.3 Order

This class represents those orders that are fulfilled by this document. For instance, a provider orders an
X-Ray. The X-Ray is performed. A radiologist reads the X-Ray and generates a report. The X-Ray order
identifier is transmitted in the Order class, the performed X-Ray procedure is transmitted in the
ServiceEvent class, and the ClinicalDocument.code would be valued with "Diagnostic Imaging Report".

Table 57: Value set for InFulfillmentOf.typeCode (CNE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 31/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

FLFS (fulfills) [default] The current document fulfills the order stated in ActOrder.

Table 58: Value set for Order.classCode (CNE)

Code Definition

ACT (act) [default] A healthcare service.

Any ACT subtype See vocabulary domain "ActClassRoot" for allowable values.

Table 59: Value set for Order.moodCode (CNE)

Code Definition

RQO (request) [default] A request or order to perform the stated act.

4.2.3.4 Consent

This class references the consents associated with this document. The type of consent (e.g. a consent
to perform the related ServiceEvent, a consent for the information contained in the document to be
released to a third party) is conveyed in Consent.code. Consents referenced in the CDA Header have
been finalized (Consent.statusCode must equal "completed") and should be on file.

Table 60: Value set for authorization.typeCode (CNE)

Code Definition

AUTH (authorized by) The consent authorizes or certifies acts specified in the
[default] current document.

Table 61: Value set for Consent.classCode (CNE)

Code Definition

CONS (consent) The Consent class represents informed consents and medico-legal
[default] transactions.

Table 62: Value set for Consent.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

Table 63: Value set for Consent.statusCode (CNE)

Code Definition

The consent being referenced by the CDA document has been finalized and is
completed
on file.

4.2.3.5 EncompassingEncounter

This optional class represents the setting of the clinical encounter during which the documented act(s)
or ServiceEvent occurred. Documents are not necessarily generated during an encounter, such as when
a clinician, in response to an abnormal lab result, attempts to contact the patient but can't, and writes
a Progress Note.
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 32/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

In some cases, the setting of the encounter is inherent in the ClinicalDocument.code, such as where
ClinicalDocument.code is "Diabetes Clinic Progress Note". The setting of an encounter can also be
transmitted in the HealthCareFacility.code attribute. If HealthCareFacility.code is sent, it should be
equivalent to or further specialize the value inherent in the ClinicalDocument.code (such as where the
ClinicalDocument.code is simply "Clinic Progress Note" and the value of HealthCareFacility.code is
"cardiology clinic"), and shall not conflict with the value inherent in the ClinicalDocument.code, as such
a conflict would constitute an ambiguous situation.

EncompassingEncounter.dischargeDispositionCode can be used to depict the disposition of the patient

at the time of hospital discharge (e.g., discharged to home, expired, against medical advice, etc.).

Table 64: Value set for componentOf.typeCode (CNE)

Code Definition

COMP (component) The current document is a documentation of events that occurred

[default] during the EncompassingEncounter.

Table 65: Value set for EncompassingEncounter.classCode (CNE)

Code Definition

ENC An interaction between a patient and healthcare participant(s) for the

(encounter) purpose of providing patient service(s) or assessing the health status of a
[default] patient.

Table 66: Value set for EncompassingEncounter.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

The location participant (location class) relates a healthcare facility (HealthCareFacility class) to the
encounter to indicate where the encounter took place. The entity playing the role of HealthCareFacility
is a place (Place class). The entity scoping the HealthCareFacility role is an organization (Organization
class).

The setting of an encounter (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled
nursing facility) can be expressed in HealthCareFacility.code. Note that setting and physical location are
not the same. There is a many-to-many relationship between setting and the physical location where
care is delivered. Thus, a particular room can provide the location for cardiology clinic one day, and for
primary care clinic another day; and cardiology clinic today might be held in one physical location, but
in another physical location tomorrow.

When the location is an organization, this is indicated by the presence of a scoping Organization,
without a playing Place.

Table 67: Value set for location.typeCode (CNE)

Code Definition

LOC The location where the service is done. May be a static building (or room
(location) therein) or a moving location (e.g., ambulance, helicopter, aircraft, train,
[default] truck, ship, etc.)

Table 68: Value set for HealthCareFacility.classCode (CNE)

Code Definition

SDLOC (service delivery location) A role played by a place at which services may be
[default] provided.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 33/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

Any SDLOC See vocabulary domain

(RoleClassServiceDeliveryLocation) "RollClassServiceDeliveryLocation" for allowable
subtype values.

The responsibleParty participant represents the participant having primary legal responsibility for the
encounter. This differs from the legalAuthenticator participant in that the legalAuthenticator may or
may not be the responsible party, and is serving a medical records function by signing off on the
document, moving it into a completed state.

Table 69: Value set for responsibleParty.typeCode (CNE)

Code Definition

RESP The provider (person or organization) who has primary responsibility for the
(responsible encounter. The responsible provider is not necessarily present in an
party) encounter, but is accountable for the action through the power to delegate,
[default] and the duty to review actions with the performing participant.

A responsibleParty is a person or organization in the role of an assigned entity (AssignedEntity class).

An assigned entity is a person assigned to the role by the scoping organization. The entity playing the
role is a person (Person class). The entity scoping the role is an organization (Organization class).

When the responsible party is an organization, the value for AssignedEntity.classCode is "ASSIGNED",
and the responsible party is reflected by the presence of a scoping Organization, without a playing
entity.

The encounterParticipant participant represents clinicians directly associated with the encounter (e.g.
by initiating, terminating, or overseeing it).

Table 70: Value set for encounterParticipant.typeCode (CNE)

Code Definition

ADM
The practitioner who admits a patient to a hospital stay.
(admitter)

ATND
The primary practitioner that oversees a patient's care during an encounter.
(attender)

CONS An advising practioner participating in the encounter by performing

(consultant) evaluations and making recommendations.

DIS
The practitioner who discharges a patient from a hospital stay.
(discharger)

REF
A person having referred the patient for services resulting in the encounter.
(referrer)

An encounterParticipant is an entity in the role of assigned entity (AssignedEntity class). An assigned

entity is a person assigned to the role by the scoping organization. The entity playing the role is a
person (Person class). The entity scoping the role is an organization (Organization class).

4.3 Body

4.3.1 Body Choice

The CDA body can be either an unstructured blob, or can be comprised of structured markup. Every

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 34/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

CDA document has exactly one body, associated with the ClinicalDocument class through the
component relationship.

Table 71: Value set for component.typeCode (CNE)

Code Definition

COMP (component) The associated document body is a component of the

[default] document.

4.3.1.1 NonXMLBody

The NonXMLBody class represents a document body that is in some format other than XML.
NonXMLBody.text is used to reference data that is stored externally to the CDA document or to encode
the data directly inline.

Rendering a referenced non-XML body requires a software tool that recognizes the particular MIME
media type of the blob.

Table 72: Value set for NonXMLBody.classCode (CNE)

Code Definition

DOCBODY (document body) A context that distinguishes the body of a document from
[default] the document header.

Table 73: Value set for NonXMLBody.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of the event.

Table 74: Value set for NonXMLBody.confidentialityCode (CWE)

Code * Definition

Normal confidentiality rules (according to good health care

N (normal) (codeSystem
practice) apply. That is, only authorized individuals with a
2.16.840.1.113883.5.25)
legitimate medical or business need may access this item.

R (restricted)
Restricted access, e.g. only to providers having a current care
(codeSystem
relationship to the patient.
2.16.840.1.113883.5.25)

V (very restricted)
Very restricted access as declared by the Privacy Officer of the
(codeSystem
record holder.
2.16.840.1.113883.5.25)

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must
carry both a code and a codeSystem.

4.3.1.2 StructuredBody

The StructuredBody class represents a CDA document body that is comprised of one or more document
sections.

Table 75: Value set for StructuredBody.classCode (CNE)

Code Definition

DOCBODY (document body) A context that distinguishes the body of a document from
[default] the document header.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 35/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Table 76: Value set for StructuredBody.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

Table 77: Value set for StructuredBody.confidentialityCode (CWE)

Code * Definition

Normal confidentiality rules (according to good health care

N (normal) (codeSystem
practice) apply. That is, only authorized individuals with a
2.16.840.1.113883.5.25)
legitimate medical or business need may access this item.

R (restricted)
Restricted access, e.g. only to providers having a current care
(codeSystem
relationship to the patient.
2.16.840.1.113883.5.25)

V (very restricted)
Very restricted access as declared by the Privacy Officer of the
(codeSystem
record holder.
2.16.840.1.113883.5.25)

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must
carry both a code and a codeSystem.

The StructuredBody class is associated with one or more Section classes through a component
relationship.

Table 78: Value set for component.typeCode (CNE)

Code Definition

COMP (component) The associated section is a component of the document

[default] body.

4.3.2 Section Attributes

Document sections can nest, can override context propagated from the header (see CDA Context (§
4.4 ), and can contain narrative and CDA entries.

An XML attribute "ID" of type XML ID, is added to Section within the CDA Schema. This attribute serves
as the target of a <linkHtml> reference (see <linkHtml> (§ 4.3.5.2 )). All values of attributes of type
XML ID must be unique within the document (per the W3C XML specification).

Table 79: Value set for Section.classCode (CNE)

Code Definition

DOCSECT A context that subdivides the body of a document. Document sections are
(document typically used for human navigation, to give a reader a clue as to the expected
section) content. Document sections are used to organize and provide consistency to
[default] the contents of a document body.

Table 80: Value set for Section.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

4.3.2.1 Section.id

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 36/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

The unique instance identifier of a particular document section.

4.3.2.2 Section.code

The code specifying the particular kind of section (e.g. Chief Complaint, Review of Systems,
Assessment). The value set is drawn from LOINC, and has a CWE coding strength.

4.3.2.3 Section.title

Represents the label of a section. If valued, it is to be rendered as part of the narrative content of the
clinical document body.

4.3.2.4 Section.text

Used to store narrative to be rendered. Also referred to as the CDA Narrative Block. See Section
Narrative Block (§ 4.3.5 ) for details.

4.3.2.5 Section.confidentialityCode

A value for Section.confidentialityCode overrides the value propagated from StructuredBody. See CDA
Context (§ 4.4 ) for more details.

Table 81: Value set for Section.confidentialityCode (CWE)

Code* Definition

Normal confidentiality rules (according to good health care

N (normal) (codeSystem
practice) apply. That is, only authorized individuals with a
2.16.840.1.113883.5.25)
legitimate medical or business need may access this item.

R (restricted)
Restricted access, e.g. only to providers having a current care
(codeSystem
relationship to the patient.
2.16.840.1.113883.5.25)

V (very restricted)
Very restricted access as declared by the Privacy Officer of the
(codeSystem
record holder.
2.16.840.1.113883.5.25)

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must
carry both a code and a codeSystem.

4.3.2.6 Section.languageCode

Specifies the human language of character data (whether they be in contents or attribute values). The
values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force)
RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand. 1995 , which obsoletes RFC
1766. The HL7 code system for these values is "2.16.840.1.113883.6.121".

A value for Section.languageCode overrides the value propagated from StructuredBody. See CDA
Context (§ 4.4 ) for more details.

4.3.3 Section Participants

4.3.3.1 author

The author participant (described above, see author (§ 4.2.2.2 )), can be ascribed to a CDA section,
where it overrides the value(s) propagated from the CDA header.

4.3.3.2 informant

The informant participant (described above, see informant (§ 4.2.2.6 )), can be ascribed to a CDA
section where it overrides the value(s) propagated from the CDA header.

4.3.3.3 subject
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 37/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

The subject participant represents the primary target of the entries recorded in the document. Most of
the time the subject is the same as the recordTarget (see recordTarget (§ 4.2.2.11 )), but need not be,
for instance when the subject is a fetus observed in an obstetrical ultrasound.

The subject participant can be ascribed to a CDA section or a CDA entry. It propagates to nested
components, unless overridden. The subject of a document is presumed to be the patient.

A subject is a person playing one of several possible roles (RelatedSubject class). The entity playing the
role is a person (SubjectPerson class).

Table 82: Value set for subject.typeCode (CNE)

Code Definition

SBJ (subject) [default] The principle target that the service acts on.

Table 83: Value set for subject.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

Table 84: Value set for RelatedSubject.classCode (CNE)

Code Definition

PRS The subject has a personal relationship to the patient. The type of personal
(personal relationship is stated in SubjectRole.code, with a value drawn from the
relationship) extensible (CWE) PersonalRelationshipRoleType vocabulary domain. The
[default] scoper is always the patient, and is implied.

PAT The subject of an entry is the patient, who is identified in the recordTarget
(patient) participant in the CDA header.

Table 85: Value set for SubjectPerson.classCode (CNE)

Code Definition

PSN (person) [default] A living subject of the species homo sapiens.

Table 86: Value set for SubjectPerson.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(instance)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

4.3.4 Section Relationships

4.3.4.1 component

The "component" Act Relationship is used to nest a Section within a Section. Context propagates to
nested sections (see CDA Context (§ 4.4 )).

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 38/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0
Table 87: Value set for component.typeCode (CNE)
Code Definition

COMP (component) [default] The nested section is a component of the outer section.

4.3.4.2 entry

The relationship between a section and its entries is encoded in the intervening "entry" Act
Relationship.

NOTE: See Referencing in and out of the narrative block (§ 4.3.5.12 ) for a discussion
of referencing in and out of a section's narrative block.

The narrative of each Section, together with the multimedia content referenced in the narrative,
comprises the complete authenticated content of the Section. This multimedia content consists of
ObservationMedia and RegionOfInterest entries referenced by <renderMultimedia> tags in the
Section.text. This is the only case where the entries contain authenticated content that must be
rendered with the narrative.

In terms of the relationship between a section and its entries, CDA defines a default general case, and
a more specific case that can be used when applicable.

The entry relationship is defaulted to "COMP" (component), for the general case where the only
assertion is that the related entries are contained within the source section and no other semantics are
implied. In this case, the narrative is the original authenticated content. The CDA entries are created by
various techniques (e.g., natural language processing, a human coder, a structured data entry tool that
outputs both entries and a text report). The method of entry creation may be indicated by the entry
participants (e.g., by identifying the algorithm or person that generated them). Relationships between
various entries (such as two Observations or an Observation and an ObservationMedia) are encoded
using the relationship types defined in entryRelationship (§ 4.3.8.4 ).

A section may also have no narrative content in the case where the entries represent information that
is not part of the clinical content of the document. A report may embed information referencing
evidence data, reagents, calibration or other information that may be used for later processing but is
not part of the clinical content. Such entries are also linked to the Section with ActRelationships
possessing typeCode="COMP".

The entry relationship "DRIV" (is derived from) can be used in the special case where the narrative is
fully derived from CDA Entries. When a report consisting entirely of structured entries is transformed
into CDA, the encoding application must ensure that the authenticated content (narrative plus
multimedia) is a faithful and complete rendering of the clinical content of the structured source data.
This ensures that the narrative plus multimedia represents, as in all CDA documents, the complete
authenticated content of the Section. In this case, narrative plus multimedia does not contain any
clinical content that is not present in the Entries. An example of this case is a DICOM Structured
Reporting document of obstetrical measurements made by ultrasound, rendered into a tabular report
by a program converting it to CDA narrative block. If the typeCode of the ActRelationship linking these
Entries to the Section was "DRIV", it would indicate to a receiving application: 1) the source of the
narrative block is the Entries; 2) the contents of the two are equivalent.

The entries sourced from a Section may have a mix of ActRelationship typeCodes. In such a case, the
union of the targets with a "DRIV" relationship are those used to generate the narrative block, and are
those that, taken in total, are equivalent to the narrative block. Additional entries with "COMP"
relationships are contained within the same section, with no implied semantics.

Table 88: Value set for entry.typeCode (CNE)

Code Definition

COMP
The associated entry is a component of the section. No semantic
(component)
relationship is implied.
[default]

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 39/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

DRIV (is derived The narrative was rendered from the CDA Entries, and contains no
from) clinical content not derived from the entries.

4.3.5 Section Narrative Block

The Section.text field is used to store narrative to be rendered, as described above in CDA
Conformance (§ 1.3 ), and is therefore referred to as the CDA Narrative Block.

The CDA Narrative Block schema can be found here.

The content model of the CDA Narrative Block schema is specially hand crafted to meet the
requirements outlined above (see Human Readability and Rendering CDA Documents (§ 1.2.3 )). The
schema is registered as a MIME type (text/x-hl7-text+xml), which is the fixed media type for
Section.text. Components of the schema are described in the sections that follow.

4.3.5.1 <content>

The CDA <content> element is used to wrap a string of text so that it can be explicitly referenced, or
so that it can suggest rendering characteristics. The <content> element can nest recursively, which
enables wrapping a string of plain text down to as small a chunk as desired.

The <content> element contains an optional identifier, that can serve as the target of a reference. All
values of attributes of type XML ID must be unique within the document (per the W3C XML
specification). The originalText component of a RIM attribute present in any CDA entry can make
explicit reference to the identifier, thereby indicating the original text associated with the attribute in
the CDA entry.

Example 5
<section>
<code code="10153-2"
codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
<title>Past Medical History</title>
<text>
There is a history of <content ID="a1">Asthma</content>
</text>
<entry>
<observation classCode="OBS" moodCode="EVN">
<code code="195967001"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Asthma">
<originalText>
<reference value="#a1"/>
</originalText>
</code>
<statusCode code="completed"/>
</observation>
</entry>
</section>

There is no requirement that CDA entries must reference into the CDA Narrative Block. The referencing
mechanism can be used where it is important to represent the original text component of a coded CDA
entry.

The <content> element contains an optional "revised" attribute that can be valued with "insert" or
"delete", which can be used to indicate narrative changes from the last version of a CDA document. The
attribute is limited to a single generation, in that it only reflects the changes from the preceding version
of a document. If applied, it needs to be used in conjunction with standard CDA revision tracking.
Changes to a CDA document that has been released for patient care still require a formal versioning
and revision, and the revised document can optionally carry the "revised" attribute to show the delta in
the narrative. Receivers are required to interpret the "revised" attribute when rendering by visually
distinguishing or suppressing deleted narrative.

4.3.5.2 <linkHtml>

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 40/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

The CDA <linkHtml> is a generic referencing mechanism, similar, but not identical, to the HTML anchor
tag. It can be used to reference identifiers that are either internal or external to the document.

Multimedia that is integral to a document, and part of the attestable content of the document requires
the use of the ObservationMedia CDA entry, which is referenced by the <renderMultiMedia> element
(see <renderMultiMedia> (§ 4.3.5.6 )). Multimedia that is simply referenced by the document and not
an integral part of the document can use <linkHtml>.

The source of a link uses the linkHtml.href attribute. The target of an internal reference is an identifier
of type XML ID, which can exist on other elements in the same or a different narrative block, or XML ID
attributes that have been added to the <section>, <ObservationMedia>, or <renderMultiMedia>
elements of the CDA Schema. The linkHtml.name attribute is deprecated, because attributes of type
XML ID provide an alternative and more consistent target for referencing. Following the conventions of
HTML, an internal link is prefaced with the pound sign, as shown in the following example.

Example 6
<section ID="SECT001">
<code code="10164-2" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
<title>History of Present Illness</title>
<text>Mr. Smith is a 57 year old male presenting with
chest pain. He sustained a myocardial infarction 3 years
ago, ...
</text>
</section>

...

<section ID="SECT003">
<code code="10153-2" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
<title>Past Medical History</title>
<text>History of coronary artery disease, as noted
<linkHtml href="#SECT001">above</linkHtml>.</text>
</section>

CDA links do not convey shareable meaning. Shareable semantics are only achieved by the inclusion of
CDA entries and their associated formalized relationships. There is no requirement that a receiver
render an internal or external link, or the target of an external link.

4.3.5.3 <sub> and <sup>

The CDA <sub> and <sup> elements are used to indicate subscripts and superscripts, respectively.

Receivers are required to interpret these elements when rendering by visually distinguishing
subscripted and superscripted characters.

4.3.5.4 <br>

The CDA <br/> element is used to indicate a hard line break. It differs from the CDA <paragraph>
element in that the <br/> element has no content. Receivers are required to interpret this element
when rendering so as to represent a line break.

4.3.5.5 <footnote> and <footnoteRef>

The CDA <footnote> element is used to indicate a footnote. The element contains the footnote, inline
with the flow of text to which it is applied.

The <footnoteRef> element can reference an existing footnote in the same or different CDA Narrative
Block of the same document. It can be used when the same footnote is being used multiple times. The
value of the footnoteRef.IDREF must be an footnote.ID value in the same document.

Receivers are required to interpret these elements when rendering by visually distinguishing footnoted
text. The exact rendition is at the discretion of the recipient, and might include a mark at the location
of the footnote with a hyperlink to the footnoted text, a simple demarcation (such as "This is the text
[this is the footnote] that is being footnoted"), etc.

4.3.5.6 <renderMultiMedia>

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 41/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

The CDA <renderMultiMedia> element references external multimedia that is integral to a document,
and part of the attestable content of the document, and serves to show where the referenced
multimedia is to be rendered.

The <renderMultiMedia> element has an optional <caption>, and contains a required referencedObject
attribute (of type XML IDREFS), the values of which must equal the XML ID value(s) of
ObservationMedia or RegionOfInterest CDA entries within the same document.

Example 7
<section>
<code code="8709-8" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
<title>Skin exam</title>
<text>Erythematous rash, palmar surface, left index
finger.<renderMultiMedia referencedObject="MM1"/>
</text>
<entry>
<observationMedia classCode="OBS" moodCode="EVN" ID="MM1">
<id root="2.16.840.1.113883.19.2.1"/>
<value xsi:type="ED" mediaType="image/jpeg">
<reference value="left_hand_image.jpeg"/>
</value>
</observationMedia>
</entry>
</section>

Multimedia that is simply referenced by the document and not an integral part of the document must
use <linkHtml>.

The expected behavior is that the referenced multimedia should be rendered or referenced at the point
of reference. Where a caption is present, it must also be rendered. <renderMultiMedia> can either
reference a single ObservationMedia, or one or more RegionOfInterest. If <renderMultiMedia>
references a single ObservationMedia, that ObservationMedia should be rendered or referenced at the
point of reference. If <renderMultiMedia> references one or more RegionOfInterest, all
RegionOfInterests should be rendered or referenced at the point of reference, atop the multimedia they
are regions of. If <renderMultiMedia> references more than one RegionOfInterest, each
RegionOfInterest must be a region on the same multimedia.

4.3.5.7 <paragraph>

A CDA <paragraph> is similar to the HTML paragraph, which allows blocks of narrative to be broken up
into logically consistent structures. A CDA <paragraph> element contains an optional caption, which if
present must come first before any other character data.

4.3.5.8 <list>

A CDA <list> is similar to the HTML list. A CDA <list> has an optional caption, and contains one or
more <item> elements. A CDA <item> element contains an optional caption, which if present must
come first before any other character data. The required listType attribute specifies whether the <list>
is ordered or unordered (with unordered being the default). Unordered lists are typically rendered with
bullets, whereas ordered lists are typically rendered with numbers, although this is not a requirement.

4.3.5.9 <table>

The CDA <table> is similar to the HTML table. The table markup is for presentation purposes only and,
unlike a database table, does not possess meaningful field names.

CDA modifies the strict XHTML table model by removing formatting tags and by setting the content
model of cells to be similar to the contents of other elements in the CDA Narrative Block.

The table.border, table.cellspacing, and table.cellpadding attributes are deprecated, because the
styleCode attribute (see styleCode attribute (§ 4.3.5.11 ) provides a more consistent way for senders
to suggest rendering characteristics.

4.3.5.10 <caption>

The CDA <caption> is a label for a paragraph, list, list item, table, or table cell. It can also be used
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 42/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

within the <renderMultiMedia> element to indicate a label for referenced ObservationMedia and
RegionOfInterest entries. A <caption> contains plain text and may contain links and footnotes.

4.3.5.11 styleCode attribute

The styleCode attribute is used within the CDA Narrative Block to give the instance author the ability to
suggest rendering characteristics of the nested character data. Receivers are not required to render
documents using the style hints provided and can present stylized text in accordance with their local
style conventions.

The value set is drawn from the HL7 styleType vocabulary domain, and has a CWE coding strength.

Table 89: Value set for styleCode (CWE)

Code Definition

Font style (Defines font rendering characteristics.)

Bold Render with a bold font.

Underline Render with an underlines font.

Italics Render italicized.

Emphasis Render with some type of emphasis.

Table rule style (Defines table cell rendering characteristics.)

Lrule Render cell with left-sided rule.

Rrule Render cell with right-sided rule.

Toprule Render cell with rule on top.

Botrule Render cell with rule on bottom.

Ordered list style (Defines rendering characteristics for ordered lists.)

Arabic List is ordered using Arabic numerals: 1, 2, 3.

LittleRoman List is ordered using little Roman numerals: i, ii, iii.

BigRoman List is ordered using big Roman numerals: I, II, III.

LittleAlpha List is ordered using little alpha characters: a, b, c.

BigAlpha List is ordered using big alpha characters: A, B, C.

Unordered list style (Defines rendering characteristics for unordered lists.)

Disc List bullets are simple solid discs.

Circle List bullets are hollow discs.

Square List bullets are solid squares.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 43/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Local extensions to the styleType vocabulary domain must follow the following convention: [x][A-Za-z]
[A-Za-z0-9]* (first character is "x", second character is an upper or lower case A-Z, remaining
characters are any combination of upper and lower case letters or numbers).

The styleCode attribute can contain multiple values, separated by white space. Where an element
containing a styleCode attribute is nested within another element containing a styleCode attribute, the
style effects are additive, as in the following example:

Example 8
<section>
<text><content styleCode="Bold">This is rendered bold,
<content styleCode="Italics">this is rendered bold and
italicized,</content> this is rendered bold. </content>
<content styleCode="Bold Italics">This is also rendered
bold and italicized.</content>
</text>
</section>
4.3.5.12 Referencing in and out of the narrative block

NOTE: See entry (§ 4.3.4.2 ) for a discussion of the relationships between a section
and its contained entries.

To summarize the mechanisms for referencing in and out of the CDA Narrative Block:

CDA entries can point in to the <content> element of the CDA Narrative Block (see <content>
(§ 4.3.5.1 )).
The <linkHtml> element of the CDA Narrative Block can reference targets that are either
internal or external to the document (see <linkHtml> (§ 4.3.5.2 )).
The <footnoteRef> element of the CDA Narrative Block can reference a <footnote> element in
the same or different CDA Narrative Block of the same document (see <footnote> and
<footnoteRef> (§ 4.3.5.5 )).
The <renderMultiMedia> element of the CDA Narrative Block can point out to CDA
ObservationMedia and RegionOfInterest entries of the same document (see
<renderMultiMedia> (§ 4.3.5.6 )).

4.3.6 Entry Acts

CDA entries represent the structured computer-processable components within a document section.
Each section can contain zero to many entries.

Clinical documents contain a wide breadth of content, requiring much of the RIM to enable a full and
complete encoding. The current set of CDA entries have been developed in response to identified
requirements and scenarios that are in CDA's scope. Rather than creating specific entries for each
scenario, similar requirements are merged to create broader entries, which can then be constrained
within a particular realm or implementation. This approach is consistent with the approach taken by
CEN, DICOM, and OpenEHR.

The model for CDA entries is derived from the shared HL7 Clinical Statement model, which is a
collaborative project between several committees striving to provide a consistent representation of
clinical observations and acts across various V3 specifications.

4.3.6.1 Act

A derivative of the RIM Act class, to be used when the other more specific classes aren't appropriate.

Act.negationInd, when set to "true", is a positive assertion that the Act as a whole is negated. Some
properties such as Act.id, Act.moodCode, and the participations are not affected. These properties
always have the same meaning: i.e., the author remains the author of the negative Act. An act
statement with negationInd is still a statement about the specific fact described by the Act. For
instance, a negated "finding of wheezing on July 1" means that the author positively denies that there
was wheezing on July 1, and that he takes the same responsibility for such statement and the same
requirement to have evidence for such statement than if he had not used negation.

Table 90: Value set for Act.classCode (CNE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 44/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

ACT (act) A healthcare service.

An accommodation is a service provided for a Person or other

ACCM
LivingSubject in which a place is provided for the subject to reside for a
(accommodation)
period of time.

Represents informed consents and other medico-legal transactions

CONS (consent)
between the patient (or legal guardian) and the provider.

CTTEVENT An identified point during a clinical trial at which one or more actions
(clinical trial are scheduled to be performed (definition mood), or are actually
timepoint event) performed (event mood).

An event that occurred outside of the control of one or more of the

INC (incident)
parties involved. Includes the concept of an accident.

The act of transmitting information and understanding about a topic (or

INFRM (inform)
requesting that such information be transmitted) to a subject.

PCPR (care A patient care provision is the taking on of the responsibility by a

provision) performer for the health care of a patient or group of patients.

REG Represents the act of maintaining information about an entity or role in

(registration) a registry.

SPCTRT
A procedure or treatment performed on a specimen to prepare it for
(specimen
analysis
treatment)

Table 91: Value set for Act.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event.

INT (intent) The entry is intended or planned.

APT (appointment) The entry is planned for a specific time and place.

ARQ (appointment request) The entry is a request for the booking of an appointment.

PRMS (promise) A commitment to perform the stated entry.

PRP (proposal) A proposal that the stated entry be performed.

RQO (request) A request or order to perform the stated entry.

DEF (definition) The entry defines a service (master).

4.3.6.2 Encounter

A derivative of the RIM PatientEncounter class, used to represent related encounters, such as follow-up
visits or referenced past encounters.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 45/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

NOTE: The EncompassingEncounter class in the CDA Header (see Header Relationships
(§ 4.2.3 )) represents the setting of the clinical encounter during which the
documented act occurred. The Encounter class in the CDA Body is used to represent
other related encounters.
Table 92: Value set for Encounter.classCode (CNE)
Code Definition

An interaction between a patient and healthcare participant(s) for the

ENC
purpose of providing patient service(s) or assessing the health status of a
(encounter)
patient.

Table 93: Value set for Encounter.moodCode (CNE)

Code Definition

INT (intent) The entry is intended or planned.

EVN (event) The entry defines an actual occurrence of an event.

APT (appointment) The entry is planned for a specific time and place.

ARQ (appointment request) The entry is a request for the booking of an appointment.

PRMS (promise) A commitment to perform the stated entry.

PRP (proposal) A proposal that the stated entry be performed.

RQO (request) A request or order to perform the stated entry.

4.3.6.3 Observation

A derivative of the RIM Observation class, used for representing coded and other observations.

Observation.negationInd, when set to "true", is a positive assertion that the Observation as a whole is
negated. Some properties such as Observation.id, Observation.moodCode, and the participations are
not negated. These properties always have the same meaning: i.e., the author remains the author of
the negative Observation. An observation statement with negationInd is still a statement about the
specific fact described by the Observation. For instance, a negated "finding of wheezing on July 1"
means that the author positively denies that there was wheezing on July 1, and that he takes the same
responsibility for such statement and the same requirement to have evidence for such statement than
if he had not used negation.

Table 94: Value set for Observation.classCode (CNE)

Code Definition

OBS Observations are actions performed in order to determine an answer or

(observation) result value.

Any OBS
See vocabulary domain "ActClassObservation" for allowable values.
subtype

Table 95: Value set for Observation.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 46/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

DEF (definition) The entry serves to define an observation.

GOL (goal) The entry represents a goal or objective.

INT (intent) The entry is intended or planned.

PRMS (promise) A commitment to perform the stated entry.

PRP (proposal) A proposal that the stated entry be performed.

RQO (request) A request or order to perform the stated entry.

An Observation can have zero to many referenceRange relationships, which relate an Observation to
the ObservationRange class, where the expected range of values for a particular observation can be
specified.

Table 96: Value set for referenceRange.typeCode (CNE)

Code Definition

REFV (has
Reference ranges are essentially descriptors of a class of result values
reference
assumed to be "normal", "abnormal", or "critical". This link type can act as
values)
a trigger in case of alarms being triggered by critical results.
[default]

Table 97: Value set for ObservationRange.classCode (CNE)

Code Definition

OBS (observation) Observations are actions performed in order to determine an

[default] answer or result value.

See vocabulary domain "ActClassObservation" for allowable

Any OBS subtype
values.

Table 98: Value set for ObservationRange.moodCode (CNE)

Code Definition

EVN.CRT (event A criterion or condition over observations that must apply for an
criterion) [default] associated service to be considered.

4.3.6.4 ObservationMedia

A derivative of the RIM Observation class that represents multimedia that is logically part of the current
document. This class is only for multimedia that is logically part of the attested content of the
document. Rendering a referenced ObservationMedia requires a software tool that recognizes the
particular MIME media type.

An XML attribute "ID" of type XML ID, is added to ObservationMedia within the CDA Schema. This
attribute serves as the target of a <renderMultiMedia> reference (see <renderMultiMedia> (§ 4.3.5.6
)). All values of attributes of type XML ID must be unique within the document (per the W3C XML
specification).

The distinction between ObservationMedia and ExternalObservation is that ObservationMedia entries

are part of the attested content of the document whereas ExternalObservations are not. For instance,

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 47/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

when a clinician draws a picture as part of a progress note, that picture is represented as a CDA
ObservationMedia. If that clinician is also describing a finding seen on a chest-x-ray, the referenced
chest-x-ray is represented as a CDA ExternalObservation.

Table 99: Value set for ObservationMedia.classCode (CNE)

Code Definition

OBS (observation) A multimedia observation.

Table 100: Value set for ObservationMedia.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event.

4.3.6.5 Organizer

A derivative of the RIM Act class, which can be used to create arbitrary groupings of other CDA entries
that share a common context. An Organizer can contain other Organizers and/or other CDA entries, by
traversing the component relationship. An Organizer can refer to external acts by traversing the
reference relationship. An Organizer cannot be the source of an entryRelationship relationship.

NOTE: CDA entries such as Observation can also contain other CDA entries by
traversing the entryRelationship class. There is no requirement that the Organizer entry
be used in order to group CDA entries.
Table 101: Value set for Organizer.classCode (CNE)
Code Definition

A battery specifies a set of observations. These observations typically have a

BATTERY logical or practical grouping for generally accepted clinical or functional
(battery) purposes, such as observations that are grouped together because of
automation.

CLUSTER A group of entries that have a logical association with one another. The Cluster
(cluster) class permits aggregation into a compound statement.

Table 102: Value set for Organizer.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event

4.3.6.6 Procedure

A derivative of the RIM Procedure class, used for representing procedures.

Procedure.negationInd, when set to "true", is a positive assertion that the Procedure as a whole is
negated. Some properties such as Procedure.id, Procedure.moodCode, and the participations are not
affected. These properties always have the same meaning: i.e., the author remains the author of the
negative Procedure. A procedure statement with negationInd is still a statement about the specific fact
described by the Procedure. For instance, a negated "appendectomy performed" means that the author
positively denies that there was ever an appendectomy performed, and that he takes the same
responsibility for such statement and the same requirement to have evidence for such statement than
if he had not used negation.

Table 103: Value set for Procedure.classCode (CNE)

Code Definition

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 48/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

PROC An act whose immediate and primary outcome (post-condition) is the

(procedure) alteration of the physical condition of the subject.

Table 104: Value set for Procedure.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event.

INT (intent) The entry is intended or planned.

APT (appointment) The entry is planned for a specific time and place.

ARQ (appointment request) The entry is a request for the booking of an appointment.

PRMS (promise) A commitment to perform the stated entry.

PRP (proposal) A proposal that the stated entry be performed.

RQO (request) A request or order to perform the stated entry.

DEF (definition) The entry defines a service (master).

4.3.6.7 RegionOfInterest

A derivative of the RIM Observation class that represents a region of interest on an image, using an
overlay shape. RegionOfInterest is used to make reference to specific regions in images, e.g., to specify
the site of a physical finding by "circling" a region in a schematic picture of a human body. The units of
the coordinate values in RegionOfInterest.value are in pixels, expressed as a list of integers. The origin
is in the upper left hand corner, with positive X values going to the right and positive Y values going
down. The relationship between a RegionOfInterest and its referenced ObservationMedia or
ExternalObservation is specified by traversing the entryRelationship or reference class, respectively,
where typeCode equals "SUBJ". A RegionOfInterest must reference exactly one ObservationMedia or
one ExternalObservation. If the RegionOfInterest is the target of a <renderMultimedia> reference, then
it shall only reference an ObservationMedia and not an ExternalObservation.

An XML attribute "ID" of type XML ID, is added to RegionOfInterest within the CDA Schema. This
attribute serves as the target of a <renderMultiMedia> reference (see <renderMultiMedia> (§ 4.3.5.6
)). All values of attributes of type XML ID must be unique within the document (per the W3C XML
specification).

Table 105: Value set for RegionOfInterest.classCode (CNE)

Code Definition

ROIOVL (overlay region of A Region of Interest specified for an image using an

interest) overlay shape.

Table 106: Value set for RegionOfInterest.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event.

Table 107: Value set for RegionOfInterest.code (CNE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 49/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

CIRCLE A circle defined by two (column,row) pairs. The first point is the center of the
(circle) circle and the second point is a point on the perimeter of the circle.

An ellipse defined by four (column,row) pairs, the first two points specifying the
ELLIPSE
endpoints of the major axis and the second two points specifying the endpoints
(ellipse)
of the minor axis.

POINT A single point denoted by a single (column,row) pair, or multiple points each
(point) denoted by a (column,row) pair.

A series of connected line segments with ordered vertices denoted by

POLY
(column,row) pairs; if the first and last vertices are the same, it is a closed
(polyline)
polygon.

The following example illustrates one sample use of RegionOfInterest. In this case, the clinician has
identified a rash upon physical examination of the skin, and indicates this by creating a region of
interest atop a hand image taken from an image library. The narrative block references the
RegionOfInterest via the <renderMultiMedia> tag, and the referenced RegionOfInterest references the
hand image.

Example 9
<section>
<code code="8709-8" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
<title>Skin Exam</title>
<text>Erythematous rash, palmar surface, left index
finger.<renderMultiMedia referencedObject="MM2"/>
</text>
<entry>
<observation classCode="OBS" moodCode="EVN">
<code code="271807003"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Rash"/>
<statusCode code="completed"/>
<targetSiteCode code="48856004"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Skin of palmer surface of index finger">
<qualifier>
<name code="78615007"
codeSystem="2.16.840.1.113883.6.96"
displayName="with laterality"/>
<value code="7771000"
codeSystem="2.16.840.1.113883.6.96"
displayName="left"/>
</qualifier>
</targetSiteCode>
<entryRelationship typeCode="SPRT">
<regionOfInterest classCode="ROIOVL" moodCode="EVN" ID="MM2">
<id root="2.16.840.1.113883.19.3.1"/>
<code code="ELLIPSE"/>
<value value="3"/>
<value value="1"/>
<value value="3"/>
<value value="7"/>
<value value="2"/>
<value value="4"/>
<value value="4"/>
<value value="4"/>
<entryRelationship typeCode="SUBJ">
<observationMedia classCode="OBS" moodCode="EVN">
<id root="2.16.840.1.113883.19.2.1"/>
<value mediaType="image/jpeg">
<reference value="lefthand.jpeg"/>
</value>
</observationMedia>
</entryRelationship>

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 50/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0
</regionOfInterest>
</entryRelationship>
</observation>
</entry>
</section>
4.3.6.8 SubstanceAdministration

A derivative of the RIM SubstanceAdministration class, used for representing medication-related events
such as medication history or planned medication administration orders.

SubstanceAdministration.negationInd, when set to "true", is a positive assertion that the

SubstanceAdministration as a whole is negated. Some properties such as SubstanceAdministration.id,
SubstanceAdministration.moodCode, and the participations are not affected. These properties always
have the same meaning: i.e., the author remains the author of the negative SubstanceAdministration.
A substance administration statement with negationInd is still a statement about the specific fact
described by the SubstanceAdministration. For instance, a negated "aspirin administration" means that
the author positively denies that aspirin is being administered, and that he takes the same
responsibility for such statement and the same requirement to have evidence for such statement than
if he had not used negation.

Table 108: Value set for SubstanceAdministration.classCode (CNE)

Code Definition

SBADM (substance The act of introducing or otherwise applying a substance to

administration) the subject.

Table 109: Value set for SubstanceAdministration.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event.

INT (intent) The entry is intended or planned.

PRMS (promise) A commitment to perform the stated entry.

PRP (proposal) A proposal that the stated entry be performed.

RQO (request) A request or order to perform the stated entry.

SubstanceAdministration.priorityCode categorizes the priority of a substance administration.

SubstanceAdministration.doseQuantity indicates how much medication is given per dose.
SubstanceAdministration.rateQuantity can be used to indicate the rate at which the dose is to be
administered (e.g., the flow rate for intravenous infusions). SubstanceAdministration.maxDoseQuantity
is used to capture the maximum dose of the medication that can be given over a stated time interval
(e.g., maximum daily dose of morphine, maximum lifetime dose of doxorubicin).
SubstanceAdministration.effectiveTime is used to describe the timing of administration. It is modeled
using the GTS data type to accommodate various dosing scenarios, as illustrated in the following
example.

Example 10
<section>
<text>Take captopril 25mg PO every 12 hours, starting on
Jan 01, 2002, ending on Feb 01, 2002.
</text>
<entry>
<substanceAdministration classCode="SBADM" moodCode="RQO">
<effectiveTime xsi:type="IVL_TS">
<low value="20020101"/>
<high value="20020201"/>
</effectiveTime>
<effectiveTime xsi:type="PIVL_TS" operator="A">
<period value="12" unit="h"/>

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 51/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0
</effectiveTime>
<routeCode code="PO"
codeSystem="2.16.840.1.113883.5.112"
codeSystemName="RouteOfAdministration"/>
<doseQuantity value="1"/>
<consumable>
<manufacturedProduct>
<manufacturedLabeledDrug>
<code code="318821008"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Captopril 25mg tablet"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
</substanceAdministration>
</entry>
</section>

The capture of medication-related information also involves the interrelationship of

SubstanceAdministration with several other classes. The consumable participation is used to bring in
the LabeledDrug or Material entity that describes the administered substance. The LabeledDrug class,
which is an Entity class playing the Role of Manufactured Product, identifies the drug that is consumed
in the substance administration. The medication is identified by means of the LabeledDrug.code or the
LabeledDrug.name. The Material entity is used to identify non-drug administered substances such as
vaccines and blood products.

Table 110: Value set for consumable.typeCode (CNE)

Code Definition

CSM (consumable) A substance that is taken up or consumed as part of the

[default] substance administration.

Table 111: Value set for ManufacturedProduct.classCode (CNE)

Code Definition

MANU (manufactured) [default] A manufactured product

Table 112: Value set for LabeledDrug.classCode (CNE)

Code Definition

MMAT (manufactured) [default] A manufactured material.

Table 113: Value set for LabeledDrug.determinerCode (CNE)

Code Definition

KIND The described determiner is used to indicate that the given Entity is taken as a
(kind) general description of a kind of thing that can be taken in whole, in part, or in
[default] multiples.

Table 114: Value set for Material.classCode (CNE)

Code Definition

MMAT (manufactured) [default] A manufactured material.

Table 115: Value set for Material.determinerCode (CNE)

Code Definition

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 52/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

KIND The described determiner is used to indicate that the given Entity is taken as a
(kind) general description of a kind of thing that can be taken in whole, in part, or in
[default] multiples.

4.3.6.9 Supply

A derivative of the RIM Supply class, used for representing the provision of a material by one entity to
another.

Table 116: Value set for Supply.classCode (CNE)

Code Definition

SPLY (supply) The act of dispensing or delivering a product.

Table 117: Value set for Supply.moodCode (CNE)

Code Definition

EVN (event) The entry defines an actual occurrence of an event.

INT (intent) The entry is intended or planned.

PRMS (promise) A commitment to perform the stated entry.

PRP (proposal) A proposal that the stated entry be performed.

RQO (request) A request or order to perform the stated entry.

The dispensed product is associated with the Supply act via a product participant, which connects to
the same ManufacturedProduct role used for SubstanceAdministration.

Table 118: Value set for product.typeCode (CNE)

Code Definition

PRD (product) A material target that is brought forth (e.g. dispensed) in the
[default] service.

The Supply class represents dispensing, whereas the SubstanceAdministration class represents
administration. Prescriptions are complex activities that involve both an administration request to the
patient (e.g. take digoxin 0.125mg by mouth once per day) and a supply request to the pharmacy (e.g.
dispense 30 tablets, with 5 refills). This should be represented in CDA by a SubstanceAdministration
entry that has a component Supply entry. The nested Supply entry can have Supply.independentInd set
to "false" to signal that the Supply cannot stand alone, without it's containing SubstanceAdministration.
The following example illustrates a prescription representation in CDA.

Example 11
<section>
<text>Digoxin 0.125mg, 1 PO qDay, #30, 5 refills.</text>
<entry>
<substanceAdministration classCode="SBADM" moodCode="RQO">
<effectiveTime xsi:type="PIVL_TS">
<period value="24" unit="h"/>
</effectiveTime>
<routeCode code="PO"
codeSystem="2.16.840.1.113883.5.112"
codeSystemName="RouteOfAdministration"/>
<doseQuantity value="1"/>

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 53/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0
<consumable>
<manufacturedProduct>
<manufacturedLabeledDrug>
<code code="317896006"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Digoxin 125micrograms tablet"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
<entryRelationship typeCode="COMP">
<supply classCode="SPLY" moodCode="RQO">
<repeatNumber>
<low value="0"/>
<high value="5"/>
</repeatNumber>
<independentInd value="false"/>
<quantity value="30"/>
</supply>
</entryRelationship>
</substanceAdministration>
</entry>
</section>

4.3.7 Entry Participants

CDA structures and entries can have various participants, some of which are also defined in the CDA
header. As described in the discussion of CDA context (see CDA Context (§ 4.4 )), participants
propagated from the header can be overridden within the body.

4.3.7.1 author

The author participant (described above, see author (§ 4.2.2.2 )), can be ascribed to a CDA section
where it overrides the value(s) propagated from the CDA header, or can be ascribed to a CDA entry,
where it overrides the value(s) propagated from a CDA section and propagates to nested entries.

4.3.7.2 consumable

The consumable participant is described above (see Entry Acts (§ 4.3.6 )).

4.3.7.3 informant

The informant participant (described above, see informant (§ 4.2.2.6 )), can be ascribed to a CDA
section where it overrides the value(s) propagated from the CDA header, or can be ascribed to a CDA
entry, where it overrides the value(s) propagated from a CDA section and propagates to nested entries.

4.3.7.4 participant

Can be used to represent any other participant that cannot be represented with one of the more
specific participants. The participant can be ascribed to a CDA entry, and propagates to nested CDA
entries, unless overridden.

Table 119: Value set for participant.typeCode (CNE)

Code Definition

Any ParticipationType See vocabulary domain "ParticipationType" for allowable

subtype values.

Table 120: Value set for participant.contextControlCode (CNE)

Code Definition

OP
The participant overrides associations with the same typeCode. This
(overriding
overriding association will propagate to any descendant Acts reached by
propagating)
conducting ActRelationships. (See section "CDA Context" below.)
[default]

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 54/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

A participant is an entity playing one of several possible roles (ParticipantRole class). The entity playing
the role is a device (Device class) or other entity (PlayingEntity class). The scoper is any entity (Entity
class).

Table 121: Value set for ParticipantRole.classCode (CNE)

Code Definition

Any ROL (RoleClassRoot) See vocabulary domain "RoleClassRoot" for allowable

subtype values.

Table 122: Value set for Device.classCode (CNE)

Code Definition

DEV (device) An entity used in an activity, without being substantially changed

[default] through that activity.

Any DEV subtype See vocabulary domain "EntityClassDevice" for allowable values.

Table 123: Value set for Device.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(instance)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

Table 124: Value set for PlayingEntity.classCode (CNE)

Code Definition

ENT (entity) A physical thing, group of physical things or an organization capable of

[default] participating in Acts, while in a role.

Any ENT
See vocabulary domain "EntityClassRoot" for allowable values.
subtype

Table 125: Value set for PlayingEntity.determinerCode (CNE)

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(instance)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

Table 126: Value set for Entity.classCode (CNE)

Code Definition

ENT (entity) A physical thing, group of physical things or an organization capable of

[default] participating in Acts, while in a role.

Any ENT
See vocabulary domain "EntityClassRoot" for allowable values.
subtype

Table 127: Value set for Entity.determinerCode (CNE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 55/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

The INSTANCE determiner indicates an actual occurrence of an entity, as

INSTANCE
opposed to the KIND determiner, which refers to the general description of a
(instance)
kind of entity. For example, one can refer to a specific car (a car instance), or
[default]
one can refer to cars in general (a car kind).

4.3.7.5 performer

The performer is a person who carries out or will carry out a particular act. The performer need not be
the principal responsible participant, e.g. a surgery resident operating under supervision of attending
surgeon is a performer.

Table 128: Value set for performer.typeCode (CNE)

Code Definition

PRF
A person who actually and principally carries out or will carry out the
(performer)
action. The traditional order filler is a performer.
[default]

4.3.7.6 product

The product participant is described above (see Entry Acts (§ 4.3.6 )).

4.3.7.7 specimen

A specimen is a part of some entity, typically the subject, that is the target of focused laboratory,
radiology or other observations. In many clinical observations, such as physical examination of a
patient, the patient is the subject of the observation, and there is no specimen. The specimen
participant is only used when observations are made against some substance or object that is taken or
derived from the subject.

Table 129: Value set for specimen.typeCode (CNE)

Code Definition

SPC (specimen) The subject of non-clinical (e.g. laboratory) observation

[default] services.

Table 130: Value set for SpecimenRole.classCode (CNE)

Code Definition

SPEC (specimen) A role played by a material entity that is a specimen for an

[default] act.

4.3.7.8 subject

The subject participant (described above, see subject (§ 4.3.3.3 )), can be ascribed to a CDA section,
or it can be ascribed to a CDA entry, where it overrides the value(s) propagated from a CDA section
and propagates to nested entries.

4.3.8 Entry Relationships

4.3.8.1 component

The component relationship has a source of Organizer (see Organizer (§ 4.3.6.5 ), and a target that is
another CDA entry, and is used to create groupings of CDA entries within an Organizer.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 56/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0
Table 131: Value set for component.typeCode (CNE)
Code Definition

COMP (component) [default] The associated CDA entry is a component of the organizer.

4.3.8.2 precondition

The precondition class, derived from the ActRelationship class, is used along with the Criterion class to
express a condition that must hold true before some over activity occurs.

Table 132: Value set for precondition.typeCode (CNE)

Code Definition

PRCN (precondition) [default] A requirement to be true before a service is performed.

Table 133: Value set for Criterion.classCode (CNE)

Code Definition

OBS (observation) Observations are actions performed in order to determine an

[default] answer or result value.

See vocabulary domain "ActClassObservation" for allowable

Any OBS subtype
values.

Table 134: Value set for Criterion.moodCode (CNE)

Code Definition

EVN.CRT (event criterion) A criterion or condition that must apply for an associated
[default] service to be considered.

4.3.8.3 referenceRange

The referenceRange relationship (described above, see Observation (§ 4.3.6.3 )), has a source of
Observation, and a target of ObservationRange.

4.3.8.4 entryRelationship

CDA has identified and modeled various link and reference scenarios. These scenarios enable CDA
entries to be semantically linked to entries that exist within the same document (by traversing the
entryRelationship class) or to objects external to it (by traversing the reference class).

NOTE: The CDA specification permits any CDA entry to relate to any CDA entry using
any of the following relationship types. In many cases, this would result in nonsensical
relationships. The following table is a guideline for reasonable relationships between
CDA entries, and is not a conformance constraint.
Table 135: CDA entryRelationship Types
ActRelationship Reasonable Source
Comments
Type and Target entries

[Act | Observation | Used to show that the source caused the

CAUS (is etiology Procedure | target observation (for instance, source
for) SubstanceAdministration] "diabetes mellitus" is the cause of target
CAUS [Observation] "kidney disease").

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 57/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

ActRelationship Reasonable Source

Comments
Type and Target entries

[Act | Observation |
Procedure |
SubstanceAdministration Used to show that the target is a
COMP (has | Supply] COMP [Act | component of the source (for instance
component) Observation | Procedure "hemoglobin measurement" is a component
| of a "complete blood count").
SubstanceAdministration
| Suppply]

Used to link an observation (intent or

actual) to a goal to indicate that the
GEVL (evaluates [Observation] GEVL observation evaluates the goal (for instance,
(goal)) [Observation] a source observation of "walking distance"
evaluates a target goal of "adequate
walking distance").

Used to say that the source is a

MFST (is [Observation] MFST manifestation of the target (for instance,
manifestation of) [Observation] source "hives" is a manifestation of target
"penicillin allergy").

[Act | Observation |
Procedure |
SubstanceAdministration
| Supply] REFR [Act | Used to show a general relationship
Observation | between the source and the target, when
REFR (refers to)
ObservationMedia | the more specific semantics of the
Procedure | relationship isn't known.
RegionOfInterest |
SubstanceAdministration
| Supply]

[Act | Encounter |
Observation | Procedure
|
SubstanceAdministration Used to show the reason or rational for a
RSON (has
| Supply] RSON [Act | service (for instance source "treadmill test"
reason)
Encounter | Observation has reason "chest pain").
| Procedure |
SubstanceAdministration
| Supply]

[Act | Encounter |
Observation | Procedure
|
SubstanceAdministration The source Act starts after the start of the
SAS (starts after
| Supply] SAS [Act | target Act (for instance source "diaphoresis"
start)
Encounter | Observation starts after the start of target "chest pain").
| Procedure |
SubstanceAdministration
| Supply]

[Observation] SPRT Used to show that the target provides

SPRT (has [Observation | supporting evidence for the source (for
support) ObservationMedia | instance source "possible lung tumor" has
RegionOfInterest] support target "mass seen on chest-x-ray").

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 58/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

ActRelationship Reasonable Source

Comments
Type and Target entries

Used to relate a source region of interest to

a target image, or to relate an observation
to its subject observation (for instance,
source "moderate severity" has subject
[Observation | target "chest pain").
SUBJ (has RegionOfInterest] SUBJ
subject) [Observation | The ActRelationshipType "has subject" is
ObservationMedia] similar to the ParticipationType "subject".
Entries that primarily operate on physical
subjects use the Participation, whereas
entries that primarily operate on other
entries use the ActRelationship.

Used to show that the source is excerpted

from the target (for instance source
"hemoglobin value of 12" is an excerpt of
target "complete blood count").

[Act | Observation] The distinction between an excerpt and an

XCRPT [Act | informant participant can be blurry — such
XCRPT (is Observation | Procedure as in the case of recording a patient's
excerpt of) | medication history where the clinician may
SubstanceAdministration obtain the information from an informant or
| Supply] may excerpt the information from another
computer system. An informant (or source
of information) is a person who provides
relevant information. An informant class is
in the header, and can be overridden in the
body. An excerpt is a sub portion of some
other act.

The entryRelationship.inversionInd can be set to "true" to indicate that the relationship should be
interpreted as if the roles of the source and target entries were reversed. In the example in the table
above, "treadmill test" RSON (has reason) "chest pain". Inverted, this would have "chest pain" as the
source and "treadmill test" as the target: "chest pain" RSON (inverted) "treadmill test". Inversion can
be useful when the current context is describing the target of an act relationship that needs to be
related back to the source.

The entryRelationship.contextConductionInd differs from the otherwise common use of this attribute
(see CDA Context (§ 4.4 )) in that in all other cases where this attribute is used, the value is fixed at
"true", whereas here the value is defaulted to "true", and can be changed to "false" when referencing
an entry in the same document. Setting the context conduction to false when referencing an entry in
the same document keeps clear the fact that the referenced object retains its original context.

4.3.8.5 reference

CDA entries can reference external objects such as external images and prior reports. These external
objects are not part of the authenticated document content. They contain sufficient attributes to enable
an explicit reference rather than duplicating the entire referenced object. The CDA entry that wraps the
external reference can be used to encode the specific portions of the external reference that are
addressed in the narrative block.

Each object allows for an identifier and a code, and contains the RIM Act.text attribute, which can be
used to store the URL and MIME type of the object. External objects always have a fixed moodCode of
"EVN".

The reference class contains the attribute reference.seperatableInd, which indicates whether or not the
source is intended to be interpreted independently of the target. The indicator cannot prevent an

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 59/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

individual or application from separating the source and target, but indicates the author's desire and
willingness to attest to the content of the source if separated from the target. Typically, where
seperatableInd is "false", the exchanged package should include the target of the reference so that the
recipient can render it.

A description of allowable reference.typeCode values are shown in the following table. As in the table
above (CDA entryRelationship Types), the following table is a guideline for reasonable relationships
between CDA entries and external objects, and is not a conformance constraint.

Table 136: CDA reference Types

ActRelationship Reasonable Source and
Comments
Type Target classes

Used to show that the source and the

target are part of the same episode (for
instance, a diagnosis of "pneumonia"
ELNK (episode [Observation] ELNK
can be linked to an external problem list
link) [ExternalObservation]
entry of "pneumonia" to show that the
current diagnosis is part of the ongoing
episode of pneumonia).

[Act | Observation |
Procedure |
Used to show a general relationship
SubstanceAdministration |
between the source and the target,
REFR (refers to) Supply] REFR [ExternalAct |
when the more specific semantics of the
ExternalDocument |
relationship isn't known.
ExternalObservation |
ExternalProcedure]

[Act | Encounter |
Observation |
ObservationMedia | Organizer
| Procedure | Used to indicate that the source entry is
RPLC (replace) SubstanceAdministration | a replacement for the target external
Supply] RPLC [ExternalAct | act.
ExternalDocument |
ExternalObservation |
ExternalProcedure]

[Observation] SPRT
SPRT (has Used to show that the target provides
[ExternalDocument |
support) supporting evidence for the source.
ExternalObservation]

Used to relate a source region of

[Observation |
SUBJ (has interest to a target image, or to relate
RegionOfInterest] SUBJ
subject) an observation to its subject
[ExternalObservation]
observation.

[Act | Observation] XCRPT Used to show that the source is

[ExternalAct | excerpted from the target (for instance
XCRPT (is
ExternalDocument | "the hemoglobin is 10.7" is an excerpt
excerpt of)
ExternalObservation | of an externally referenced "complete
ExternalProcedure] blood count").

Target classes of the reference relationship include ExternalAct, ExternalDocument,

ExternalObservation, and External Procedure.

ExternalAct is a derivative of the RIM Act class, to be used when the other more specific classes are not
appropriate.

Table 137: Value set for ExternalAct.classCode (CNE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 60/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Code Definition

ACT (act) [default] A healthcare service.

Any ACT subtype. See vocabulary domain "ActClassRoot" for allowable values.

Table 138: Value set for ExternalAct.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

ExternalDocument is a derivative of the RIM Document class, used for representing external
documents. ExternalDocument.text is modeled as an ED data type - allowing for the expression of the
MIME type of the external document.

Table 139: Value set for ExternalDocument.classCode (CNE)

Code Definition

The notion of a document comes particularly from the paper world, where it
corresponds to the contents recorded on discrete pieces of paper. In the
electronic world, a document is a kind of composition that bears resemblance
DOC
to their paper world counter-parts. Documents typically are meant to be
(document)
human-readable. HL7's notion of document differs from that described in the
[default]
W3C XML Recommendation, in which a document refers specifically to the
contents that fall between the root element's start-tag and end-tag. Not all
XML documents are HL7 documents.

Any DOC
See vocabulary domain "ActClassDocument" for allowable values.
subtype

Table 140: Value set for ExternalDocument.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

ExternalObservation is a derivative of the RIM Observation class, used for representing external coded
and other observations.

Table 141: Value set for ExternalObservation.classCode (CNE)

Code Definition

OBS (observation) Observations are actions performed in order to determine an

[default] answer or result value.

See vocabulary domain "ActClassObservation" for allowable

Any OBS subtype
values.

Table 142: Value set for ExternalObservation.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

ExternalProcedure is a derivative of the RIM Procedure class, used for representing external

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 61/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

procedures.

Table 143: Value set for ExternalProcedure.classCode (CNE)

Code Definition

PROC
An Act whose immediate and primary outcome (post-condition) is the
(procedure)
alteration of the physical condition of the subject.
[default]

Table 144: Value set for ExternalProcedure.moodCode (CNE)

Code Definition

EVN (event) [default] An actual occurrence of an event.

4.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.

4.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

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 62/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

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.

4.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 145: CDA constraints on RIM context attributes

RIM attribute Cardinality Conformance Fixed Value

Mandatory (NULL "OP"

Participation.contextControlCode 1..1 values not (overriding,
permitted) propagating)

Mandatory (NULL
ActRelationship.contextConductionInd 1..1 values not "true"*
permitted)

* The one exception to this is entryRelationship.contextConductionInd, which is defaulted to "true", but

can be changed to "false". See entryRelationship (§ 4.3.8.4 ) 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 146: Blocking context propagation with null values

Context Null value representation

Author AssignedAuthor.id = NULL; No playing entity; No scoping entity.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 63/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Context Null value representation

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.

Link to wide graphic (opens in a new window)

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 12
(ancestor-or-self::*/author)[position()=last()]

5 CDA Hierarchical Description

NOTE: The definitive description of HL7 Hierarchical Description development and
interpretation can be found here.

The CDA Hierarchical Description POCD_HD000040 as an Excel View can be found here.

The CDA HD is the definitive source for CDA conformance rules, and serves as the source from which
the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also
adhere to the conformance rules stated in the CDA Hierarchical Description, and to the rules expressed
in the narrative of this specification.

HL7 enables conformance specification at the level of each RIM attribute. RIM attributes can be defined
as "Required", in which case the originator must populate the attribute where a value is known even if
the cardinality is optional, and "Mandatory", in which case the originator must populate the attribute
with a non-NULL value in all cases.

In CDA, Release Two, the "Required" and "Mandatory" conformance indicators are applied as follows:

Required attributes:
Section.text
All attributes where lower cardinality is greater than 0.
Mandatory attributes:
ClinicalDocument.typeId
RIM Structural Attributes
ClassCode
MoodCode
TypeCode
DeterminerCode

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 64/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Context attributes
contextControlCode
ContextConductionInd

Note: Note that where Mandatory attributes have a default or fixed value supplied in the CDA HD, the
instance need not contain a value. In such cases, the receiver must assume the default value.

6 CDA XML Implementation

Note: The definitive description of HL7 XML Implementation Technology Specification and the process
used to go from Hierarchical Description to Schema can be found here.

The CDA Schema can be found here

The Datatypes.xsd file can be found here

The Datatypes-base.xsd file can be found here

The POCD_MT000040.xsd file can be found here

The CDA Narrative Block schema can be found here.

The voc.xsd file can be found here.

The CDA Schema is not itself a normative artifact. Rather, checking an instance against the CDA
Schema is a surrogate for validating conformance against the normative XML ITS.

The CDA Narrative Block, which is the XML content model of section.text, is manually crafted, as
described above (see Section Narrative Block (§ 4.3.5 )). Note that while the CDA Schema is not a
normative artifact, the CDA Narrative Block schema is.

A Samples

A.1 Sample Document

Good Health Clinic Consultation note

Consultant: Robert Dolin, MD

Date: April 7, 2000

Patient: Henry Levin, the 7th; MRN: 12345; Sex: Male

Birthdate: September 24, 1932

History of Present Illness

Henry Levin, the 7th is a 67 year old male referred for further asthma management. Onset of asthma
in his teens. He was hospitalized twice last year, and already twice this year. He has not been able to be
weaned off steroids for the past several months.

Past Medical History

Asthma
Hypertension (see HTN.cda for details)
Osteoarthritis, right knee

Medications

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 65/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Theodur 200mg BID

Albuterol inhaler 2puffs QID PRN
Prednisone 20mg qd
HCTZ 25mg qd

Allergies and Adverse Reactions

Penicillin - Hives
Aspirin - Wheezing
Codeine - Itching and nausea

Family History

Father had fatal MI in his early 50's.

No cancer or diabetes.

Social History

Smoking :: 1 PPD between the ages of 20 and 55, and then he quit.
Alcohol :: Rare

Physical Exam

Vital Signs

Date / Time April 7, 2000 14:30 April 7, 2000 15:30

Height 177 cm (69.7 in)

Weight 194.0 lbs (88.0 kg)

BMI 28.1 kg/m2

BSA 2.05 m2

Temperature 36.9 C (98.5 F)

Pulse 86 / minute 84 / minute

Rhythm Regular Regular

Respirations 16 / minute, unlabored 14 / minute

Systolic 132 mmHg 135 mmHg

Diastolic 86 mmHg 88 mmHg

Position - Cuff Left Arm Left Arm

Skin :: Erythematous rash, palmar surface, left index finger.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 66/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Lungs :: Clear with no wheeze. Good air flow.

Cardiac :: RRR with no murmur, no S3, no S4.

Labs

CXR 02/03/1999: Hyperinflated. Normal cardiac silhouette, clear lungs.

Peak Flow today: 260 l/m.

In-office Procedure

Suture removal, left forearm.

Assessment

Asthma, with prior smoking history. Difficulty weaning off steroids. Will try gradual taper.
Hypertension, well-controlled.
Contact dermatitis on finger.

Plan

Complete PFTs with lung volumes.

Chem-7 tomorrow
Teach peak flow rate measurement.
Decrease prednisone to 20qOD alternating with 18qOD.
Hydrocortisone cream to finger BID.
RTC 1 week.

Signed by: Robert Dolin, MD April 8, 2000

A.2 Sample CDA Instance

This is a valid and conformant CDA instance based on the sample document above.

NOTE: Readers should be aware of the evolving "Using SNOMED CT in HL7 Version 3"
implementation guide, currently in a draft state. The guide, co-developed by HL7 and
the College of American Pathologists, will be balloted by HL7 as an Informative
Document. Recommendations in the final published guide should usurp patterns of
SNOMED CT usage found in this sample instance

Open the Sample File

A.3 Sample CDA Style Sheet

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 67/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

This is a sample CDA XSLT style sheet that can be used to transform a CDA instance into HTML. It is
provided as a convenient starting point for local style sheet development, and has several known
limitations, including:

Local implementations may have different requirements for rendering the CDA header.
Does not support RegionOfInterest rendering.
Does not support rendering of inline multimedia (e.g. multimedia that is Base 64 encoded
within the CDA document).
Does not support rendering of deleted text within the CDA Narrative Block.

Open the Sample Style Sheet

B Implementation Notes
B.1 Creating CDA Documents

Introduction

There are an ever-increasing variety of tools and techniques for creating CDA documents:

1. Transcription: most clinical documents are created through a voice interface. CDA is available as
an output from transcription vendors large and small today. Some are integrating natural
language processing to provide coded structures within dictated CDAs.
2. EMR/EHR: many electronic medical record vendors have CDA output capability, although they
provide it on-demand, not as a standard feature. For EMRs, CDA is relatively simple type of
report.
3. XML forms: a new generation of XML tools for forms generation can create CDA on output.
4. Knowledge base: at least one major US provider has built a CDA editor on top of a knowledge
base for guided, structured entry.
5. Dynamic query: dynamic assembly of CDA documents is used in some distributed applications to
prepopulate documents from existing data stores, such as lab result databases. This method can
be used in conjunction with any of the others.

This appendix considers not the specific tools and technologies, but is intended as a general guide to
use of CDA in document creation.

Before you start: RIM compliance

structures, vocabulary, datatypes

Creating a CDA-compliant instance, by definition, means that the information contained within is
defined by the HL7 RIM. Regardless of your starting point or method of document generation, when
you are done, the computable semantics of the document will derive their meaning from the
relationship between RIM classes, controlled vocabulary and the V3 RIM datatypes. Any CDA-
generation implementation must start with an examination of how document requirements relate to the
RIM, the datatypes and vocabulary.

The RIM, however, is a highly abstract model and recognizes many extensive vocabulary domains.
While RIM-mapping is a necessary condition for CDA generation, it is not sufficient to determine the
method of generation or to drive a user interface for document creation.

An exchange specification, not an authoring specification

CDA is not deterministic for document creation

CDA is a specification for the exchange form of a clinical document. A CDA schema can validate many
of the conformance requirements, but will be too general for most authoring applications. In general,
standards for interoperability and broadbased exchange will not directly drive an authoring GUI. Given

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 68/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

the extent of the CDA domain – clinical care – the requirements for generalized exchange overlap with,
but don’t match, the requirements for driving an authoring interface.

For example, the CDA requirement for human readability demands that a single stylesheet render the
authenticated clinical content of any CDA document. If CDA elements were defined in the generic
schema that corresponds to the sections of a document, <historyOfPresentIllness> or <Subjective>,
for example, a stylesheet would need to recognize each of these tags as section-level tags and render
them accordingly. The CDA approach, defining <section> and asserting the type of section through
coded vocabulary means that not only is the CDA extensible through the externally-maintained
vocabulary domains, but that document designers have the flexibility to create hierarchies of sections
and to name and tag them according to local requirements, while maintaining compatibility for the
exchange context. Thus, while specific tagging that makes it easier to drive a GUI is fine locally, where
practice can be more tightly constrained, CDA needs to take a more general approach.

Both sets of requirements, for authoring and for exchange, should be recognized. Within a defined
community of interest, such as a single business enterprise, a professional society or in some cases,
local and regional health authorities, there can be tight agreement on the form of a document so that
the authoring definitions and the exchange definitions coincide. Unless and until there is universal
agreement, there can be no universal exchange unless the diversity of local requirements is
acknowledged. This is a long-winded way of saying that CDA will remain a general exchange standard,
and other approaches must be available to define data entry and document creation validation
requirements.

General approaches: constrain or transform

constrain: emit valid CDA directly from the authoring system using a schema that isn’t CDA
transform: example - emit local XML, map to CDA

Given that CDA is not an authoring schema, there are two logical alternatives to creating valid CDA
instances.

The first is to add constraints to the CDA schema so that the resulting specification defines a particular
document type (see the following exhibit "Creating a CDA through a local schema"). There are several
technologies available for adding constraints. One approach is to modify the CDA schema itself to a
local variant (local.cda.xsd below). Modifications could include limiting the levels of nesting;
constraining vocabulary and sequence, for example requiring that a section with a LOINC code for
"Subjective" initiate the document body and be followed by a section coded "Objective". These
modifications could be expressed in W3C Schema or as Xpath statements within the local schema.
Instances that validate against this constrained, local version of CDA are, by definition, also valid CDA
instances.

Link to wide graphic (opens in a new window)

Templates are one type of constraint. HL7 is in the process of defining a formal template mechanism
(see The "A" in "CDA" (§ 1.2.2 )).

The second approach is to create a local schema and then transform the local XML instance to CDA

Link to wide graphic (opens in a new window)

B.2 LOINC Document Codes

The following table is drawn from LOINC, version 2.14, December 2004, and equals the subset whose
scale = "DOC" (and whose status <> "DEL"). The LOINC document model includes a component for
"type of service" (conveyed in the Component field), "setting" (conveyed in the System field), "subject
matter domain" (conveyed in the Method_Type field), and "training / professional level" (also conveyed
in the Method_Type field).

The type of service characterizes the kind of service or activity that was provided to/for the patient (or
other subject of the service) as described in the note. Common subclasses of service would be
examinations, evaluations, and management. The notion of time sequence, e.g. at the beginning
(admission) at the end (discharge) and is subsumed in the axis.

The setting is a modest extension of the Centers for Medicare and Medicaid Services (CMS) coarse
definition of settings. Setting is not equivalent to location, which typically has more locally defined
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 69/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

meanings.

The subject matter domain characterized the subject matter or clinical categorization of a note. The
training / professional level characterizes the training or professional level of the author of the
document.

Table 147: LOINC document codes

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

ADMISSION ATTENDING PHYSICIAN.GENERAL

34862-3 INPATIENT
EVALUATION NOTE MEDICINE

ADMISSION
34744-3 {SETTING} NURSING
EVALUATION NOTE

ADMISSION
34873-0 {SETTING} SURGERY
EVALUATION NOTE

ADMISSION HISTORY
34094-3 HOSPITAL CARDIOLOGY
AND PHYSICAL NOTE

ADMISSION HISTORY
34763-3 {SETTING} GENERAL MEDICINE
AND PHYSICAL NOTE

28615-3 AUDIOLOGY STUDY {SETTING}

18743-5 AUTOPSY NOTE {SETTING} {PROVIDER}

33720-4 BLOOD BANK CONSULT {SETTING}

COMPREHENSIVE
34095-0 HISTORY & PHYSICAL {SETTING} {PROVIDER}
NOTE

COMPREHENSIVE
NURSING
34096-8 HISTORY AND
HOME
PHYSICAL

CONFERENCE
34098-4 {SETTING} {PROVIDER}
EVALUATION NOTE

CONFERENCE NURSING
34097-6 {PROVIDER}
EVALUATION NOTE HOME

CONFIRMATORY
24611-6 OUTPATIENT {PROVIDER}
CONSULTATION NOTE

34807-8 CONSULTATION NOTE {SETTING} OPHTHALMOLOGY

CRITICAL
34100-8 CONSULTATION NOTE {PROVIDER}
CARE UNIT

34810-2 CONSULTATION NOTE {SETTING} OPTOMETRY

34812-8 CONSULTATION NOTE {SETTING} OROMAXILLOFACIAL SURGERY

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 70/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

34814-4 CONSULTATION NOTE {SETTING} ORTHOPEDICS

34831-8 CONSULTATION NOTE {SETTING} RADIATION ONCOLOGY

34761-7 CONSULTATION NOTE {SETTING} GASTROENTEROLOGY

34099-2 CONSULTATION NOTE {SETTING} CARDIOLOGY

34833-4 CONSULTATION NOTE {SETTING} RECREATIONAL THERAPY

34820-1 CONSULTATION NOTE {SETTING} PHARMACY

PHYSICAL MEDICINE AND

34822-7 CONSULTATION NOTE {SETTING}
REHABILITATION

34835-9 CONSULTATION NOTE {SETTING} REHABILITATION

34824-3 CONSULTATION NOTE {SETTING} PHYSICAL THERAPY

34826-8 CONSULTATION NOTE {SETTING} PLASTIC SURGERY

34764-1 CONSULTATION NOTE {SETTING} GENERAL MEDICINE

34837-5 CONSULTATION NOTE {SETTING} RESPIRATORY THERAPY

34803-7 CONSULTATION NOTE {SETTING} OCCUPATIONAL HEALTH

34816-9 CONSULTATION NOTE {SETTING} OTORHINOLARYNGOLOGY

34783-1 CONSULTATION NOTE {SETTING} KINESIOTHERAPY

34756-7 CONSULTATION NOTE {SETTING} DENTISTRY

34788-0 CONSULTATION NOTE {SETTING} PSYCHIATRY

34102-4 CONSULTATION NOTE HOSPITAL PSYCHIATRY

34791-4 CONSULTATION NOTE {SETTING} PSYCHOLOGY

34103-2 CONSULTATION NOTE {SETTING} PULMONARY

34795-5 CONSULTATION NOTE {SETTING} NEPHROLOGY

34758-3 CONSULTATION NOTE {SETTING} DERMATOLOGY

34760-9 CONSULTATION NOTE {SETTING} DIABETOLOGY

34798-9 CONSULTATION NOTE {SETTING} NEUROSURGERY

34800-3 CONSULTATION NOTE {SETTING} NUTRITION+DIETETICS

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 71/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

34749-2 CONSULTATION NOTE OUTPATIENT ANESTHESIA

34781-5 CONSULTATION NOTE {SETTING} INFECTIOUS DISEASE

34828-4 CONSULTATION NOTE {SETTING} PODIATRY

34101-6 CONSULTATION NOTE OUTPATIENT GENERAL MEDICINE

34104-0 CONSULTATION NOTE HOSPITAL {PROVIDER}

34785-6 CONSULTATION NOTE {SETTING} MENTAL HEALTH

34805-2 CONSULTATION NOTE {SETTING} ONCOLOGY

34797-1 CONSULTATION NOTE {SETTING} NEUROLOGY

34879-7 CONSULTATION NOTE {SETTING} ENDOCRINOLOGY

34839-1 CONSULTATION NOTE {SETTING} RHEUMATOLOGY

34779-9 CONSULTATION NOTE {SETTING} HEMATOLOGY+ONCOLOGY

34777-3 CONSULTATION NOTE {SETTING} GYNECOLOGY

34776-5 CONSULTATION NOTE {SETTING} GERONTOLOGY

34855-7 CONSULTATION NOTE {SETTING} OCCUPATIONAL THERAPY

34853-2 CONSULTATION NOTE {SETTING} VASCULAR SURGERY

34771-6 CONSULTATION NOTE {SETTING} GENERAL SURGERY

34841-7 CONSULTATION NOTE {SETTING} SOCIAL WORK

34845-8 CONSULTATION NOTE {SETTING} SPEECH THERAPY+AUDIOLOGY

11488-4 CONSULTATION NOTE {SETTING} {PROVIDER}

34847-4 CONSULTATION NOTE {SETTING} SURGERY

34851-6 CONSULTATION NOTE {SETTING} UROLOGY

34849-0 CONSULTATION NOTE {SETTING} THORACIC SURGERY

34865-6 COUNSELING NOTE {SETTING} PSYCHIATRY

34866-4 COUNSELING NOTE {SETTING} PSYCHOLOGY

34872-2 COUNSELING NOTE {SETTING} SOCIAL WORK

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 72/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

34869-8 COUNSELING NOTE {SETTING} PHARMACY

34864-9 COUNSELING NOTE {SETTING} MENTAL HEALTH

DISCHARGE
28622-9 {SETTING} NURSING
ASSESSMENT NOTE

28574-2 DISCHARGE NOTE {SETTING} {PROVIDER}

DISCHARGE
11490-0 {SETTING} PHYSICIAN
SUMMARIZATION NOTE

DISCHARGE
28655-9 {SETTING} ATTENDING PHYSICIAN
SUMMARIZATION NOTE

DISCHARGE
18842-5 {SETTING} {PROVIDER}
SUMMARIZATION NOTE

DISCHARGE
34105-7 HOSPITAL {PROVIDER}
SUMMARIZATION NOTE

DISCHARGE
29761-4 {SETTING} DENTISTRY
SUMMARIZATION NOTE

DISCHARGE
34745-0 {SETTING} NURSING
SUMMARIZATION NOTE

DISCHARGE
34106-5 HOSPITAL PHYSICIAN
SUMMARIZATION NOTE

34902-7 EDUCATION NOTE OUTPATIENT GERONTOLOGY

34897-9 EDUCATION NOTE {SETTING} DIABETOLOGY

34895-3 EDUCATION NOTE {SETTING} {PROVIDER}

EDUCATION HOME
34107-3 {PROVIDER}
PROCEDURE NOTE HEALTH

EVALUATION AND
34108-1 OUTPATIENT {PROVIDER}
MANAGEMENT

EVALUATION AND
34836-7 {SETTING} REHABILITATION
MANAGEMENT NOTE

EVALUATION AND EMERGENCY

34111-5 {PROVIDER}
MANAGEMENT NOTE DEPARTMENT

EVALUATION AND
34834-2 {SETTING} RECREATIONAL THERAPY
MANAGEMENT NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 73/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

EVALUATION AND
34759-1 {SETTING} DERMATOLOGY
MANAGEMENT NOTE

EVALUATION AND
34842-5 {SETTING} SOCIAL WORK
MANAGEMENT NOTE

EVALUATION AND NURSING

34113-1 {PROVIDER}
MANAGEMENT NOTE HOME

EVALUATION AND
34762-5 {SETTING} GASTROENTEROLOGY
MANAGEMENT NOTE

EVALUATION AND
34840-9 {SETTING} RHEUMATOLOGY
MANAGEMENT NOTE

EVALUATION AND
34757-5 {SETTING} DENTISTRY
MANAGEMENT NOTE

EVALUATION AND
34112-3 INPATIENT {PROVIDER}
MANAGEMENT NOTE

EVALUATION AND
34746-8 {SETTING} NURSING
MANAGEMENT NOTE

EVALUATION AND
34754-2 {SETTING} CRITICAL CARE
MANAGEMENT NOTE

EVALUATION AND
34772-4 {SETTING} GENERAL SURGERY
MANAGEMENT NOTE

EVALUATION AND
34753-4 OUTPATIENT CARDIOLOGY
MANAGEMENT NOTE

EVALUATION AND
34752-6 {SETTING} CARDIOLOGY
MANAGEMENT NOTE

EVALUATION AND
34832-6 {SETTING} RADIATION ONCOLOGY
MANAGEMENT NOTE

EVALUATION AND
34750-0 {SETTING} ANESTHESIA
MANAGEMENT NOTE

EVALUATION AND ATTENDING PHYSICIAN.GENERAL

34773-2 {SETTING}
MANAGEMENT NOTE SURGERY

EVALUATION AND
34830-0 {SETTING} PULMONARY
MANAGEMENT NOTE

EVALUATION AND
34778-1 {SETTING} GYNECOLOGY
MANAGEMENT NOTE

EVALUATION AND
34838-3 {SETTING} RESPIRATORY THERAPY
MANAGEMENT NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 74/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

EVALUATION AND
34780-7 {SETTING} HEMATOLOGY+ONCOLOGY
MANAGEMENT NOTE

EVALUATION AND
34109-9 {SETTING} {PROVIDER}
MANAGEMENT NOTE

EVALUATION AND
34854-0 OUTPATIENT VASCULAR SURGERY
MANAGEMENT NOTE

EVALUATION AND
34765-8 {SETTING} GENERAL MEDICINE
MANAGEMENT NOTE

EVALUATION AND
34819-3 {SETTING} PATHOLOGY
MANAGEMENT NOTE

EVALUATION AND
34801-1 {SETTING} NUTRITION+DIETETICS
MANAGEMENT NOTE

EVALUATION AND PHYSICAL MEDICINE AND

34823-5 {SETTING}
MANAGEMENT NOTE REHABILITATION

EVALUATION AND
34825-0 {SETTING} PHYSICAL THERAPY
MANAGEMENT NOTE

EVALUATION AND
34827-6 {SETTING} PLASTIC SURGERY
MANAGEMENT NOTE

EVALUATION AND
34829-2 {SETTING} PODIATRY
MANAGEMENT NOTE

EVALUATION AND
34846-6 {SETTING} SPEECH THERAPY+AUDIOLOGY
MANAGEMENT NOTE

EVALUATION AND
34848-2 {SETTING} SURGERY
MANAGEMENT NOTE

EVALUATION AND
34815-1 {SETTING} ORTHOPEDICS
MANAGEMENT NOTE

EVALUATION AND
34852-4 {SETTING} UROLOGY
MANAGEMENT NOTE

EVALUATION AND
34817-7 {SETTING} OTORHINOLARYNGOLOGY
MANAGEMENT NOTE

EVALUATION AND
34856-5 {SETTING} ANTICOAGULATION
MANAGEMENT NOTE

EVALUATION AND
34857-3 {SETTING} SUBSTANCE ABUSE
MANAGEMENT NOTE

EVALUATION AND
34858-1 {SETTING} PAIN MANAGEMENT
MANAGEMENT NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 75/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

EVALUATION AND
34859-9 {SETTING} HYPERLIPIDEMIA
MANAGEMENT NOTE

EVALUATION AND
34860-7 {SETTING} HYPERTENSION
MANAGEMENT NOTE

EVALUATION AND
34861-5 {SETTING} DIABETOLOGY
MANAGEMENT NOTE

EVALUATION AND
34878-9 {SETTING} EMERGENCY MEDICINE
MANAGEMENT NOTE

EVALUATION AND
34898-7 {SETTING} ENDOCRINOLOGY
MANAGEMENT NOTE

EVALUATION AND
34905-0 {SETTING} NEUROLOGY
MANAGEMENT NOTE

EVALUATION AND
34850-8 OUTPATIENT THORACIC SURGERY
MANAGEMENT NOTE

EVALUATION AND
34792-2 {SETTING} PSYCHOLOGY
MANAGEMENT NOTE

EVALUATION AND
34766-6 OUTPATIENT GENERAL MEDICINE
MANAGEMENT NOTE

EVALUATION AND MEDICAL STUDENT.GENERAL

34767-4 {SETTING}
MANAGEMENT NOTE MEDICINE

EVALUATION AND
34768-2 {SETTING} NURSE.GENERAL MEDICINE
MANAGEMENT NOTE

EVALUATION AND ATTENDING PHYSICIAN.GENERAL

34769-0 {SETTING}
MANAGEMENT NOTE MEDICINE

EVALUATION AND
34782-3 {SETTING} INFECTIOUS DISEASE
MANAGEMENT NOTE

EVALUATION AND
34784-9 {SETTING} KINESIOTHERAPY
MANAGEMENT NOTE

EVALUATION AND
34786-4 {SETTING} MENTAL HEALTH
MANAGEMENT NOTE

EVALUATION AND
34821-9 {SETTING} PHARMACY
MANAGEMENT NOTE

EVALUATION AND
34789-8 {SETTING} PSYCHIATRY
MANAGEMENT NOTE

EVALUATION AND
34813-6 {SETTING} OROMAXILLOFACIAL SURGERY
MANAGEMENT NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 76/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

EVALUATION AND
34802-9 {SETTING} OCCUPATIONAL HEALTH
MANAGEMENT NOTE

EVALUATION AND
34811-0 {SETTING} OPTOMETRY
MANAGEMENT NOTE

EVALUATION AND
34808-6 {SETTING} OPHTHALMOLOGY
MANAGEMENT NOTE

EVALUATION AND
34806-0 {SETTING} ONCOLOGY
MANAGEMENT NOTE

EVALUATION AND
34804-5 {SETTING} OCCUPATIONAL THERAPY
MANAGEMENT NOTE

EVALUATION AND
34794-8 {SETTING} MULTIDISCIPLINARY
MANAGEMENT NOTE

EVALUATION AND
34110-7 OUTPATIENT DIABETOLOGY
MANAGEMENT NOTE

EVALUATION AND
34799-7 {SETTING} NEUROSURGERY
MANAGEMENT NOTE

EVALUATION AND
34796-3 {SETTING} NEPHROLOGY
MANAGEMENT NOTE

GROUP COUNSELING
34787-2 {SETTING} MENTAL HEALTH
NOTE

GROUP COUNSELING
34790-6 {SETTING} PSYCHIATRY
NOTE

GROUP COUNSELING
34843-3 {SETTING} SOCIAL WORK
NOTE

GROUP COUNSELING
34114-9 HOSPITAL {PROVIDER}
NOTE

GROUP COUNSELING
34793-0 {SETTING} PSYCHOLOGY
NOTE

HISTORY & PHYSICAL

34774-0 {SETTING} GENERAL SURGERY
NOTE

HISTORY & PHYSICAL

28626-0 {SETTING} PHYSICIAN
NOTE

HISTORY & PHYSICAL

11492-6 HOSPITAL {PROVIDER}
NOTE

HISTORY & PHYSICAL NURSING

34116-4 PHYSICIAN
NOTE HOME

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 77/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

HISTORY & PHYSICAL

34115-6 HOSPITAL MEDICAL STUDENT
NOTE

HISTORY AND
34117-2 {SETTING} {PROVIDER}
PHYSICAL NOTE

HOSPITAL
18841-7 {SETTING}
CONSULTATIONS

INITIAL EVALUATION
28572-6 {SETTING} DENTISTRY
NOTE

INITIAL EVALUATION
28654-2 {SETTING} ATTENDING PHYSICIAN
NOTE

INITIAL EVALUATION
18735-1 {SETTING} PHYSICAL THERAPY
NOTE

INITIAL EVALUATION
18736-9 {SETTING} PHYSICIAN
NOTE

INITIAL EVALUATION
18737-7 {SETTING} PODIATRY
NOTE

INITIAL EVALUATION
18738-5 {SETTING} PSYCHOLOGY
NOTE

INITIAL EVALUATION
18739-3 {SETTING} SOCIAL SERVICE
NOTE

INITIAL EVALUATION
18734-4 {SETTING} OCCUPATIONAL THERAPY
NOTE

INITIAL EVALUATION
28581-7 {SETTING} CHIROPRACTOR
NOTE

INITIAL EVALUATION
29753-1 {SETTING} NURSING
NOTE

INITIAL EVALUATION
28636-9 {SETTING} {PROVIDER}
NOTE

INITIAL EVALUATION
28635-1 {SETTING} PSYCHIATRY
NOTE

INITIAL EVALUATION
28621-1 {SETTING} NURSE PRACTITIONER
NOTE

INITIAL EVALUATION
18763-3 {SETTING} CONSULTING PHYSICIAN
NOTE

INITIAL EVALUATION
18740-1 {SETTING} SPEECH THERAPY
NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 78/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

INITIAL EVALUATION
34120-6 OUTPATIENT {PROVIDER}
NOTE

INITIAL EVALUATION NURSING

34119-8 {PROVIDER}
NOTE HOME

INITIAL EVALUATION HOME

34118-0 {PROVIDER}
NOTE HEALTH

INTERVENTIONAL
34121-4 {SETTING}
PROCEDURE NOTE

INTERVENTIONAL
34896-1 {SETTING} CARDIOLOGY
PROCEDURE NOTE

INTERVENTIONAL
34899-5 {SETTING} GASTROENTEROLOGY
PROCEDURE NOTE

34903-5 NOTE {SETTING} MENTAL HEALTH

34906-8 NOTE {SETTING} PASTORAL CARE

11536-0 NOTES {SETTING} NURSING

34871-4 OPERATIVE NOTE {SETTING} PODIATRY

34874-8 OPERATIVE NOTE {SETTING} SURGERY

34877-1 OPERATIVE NOTE {SETTING} UROLOGY

34870-6 OPERATIVE NOTE {SETTING} PLASTIC SURGERY

34868-0 OPERATIVE NOTE {SETTING} ORTHOPEDICS

34818-5 OPERATIVE NOTE {SETTING} OTORHINOLARYNGOLOGY

PATHOLOGY
34122-2 {SETTING} PATHOLOGY
PROCEDURE NOTE

POST-OPERATIVE
34880-5 EVALUATION AND {SETTING} NURSE.SURGERY
MANAGEMENT NOTE

POST-OPERATIVE
34875-5 EVALUATION AND {SETTING} SURGERY
MANAGEMENT NOTE

POST-OPERATIVE
34863-1 EVALUATION AND {SETTING} GENERAL SURGERY
MANAGEMENT NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 79/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

POST-OPERATIVE
34867-2 EVALUATION AND OUTPATIENT OPHTHALMOLOGY
MANAGEMENT NOTE

PRE-OPERATIVE
34881-3 EVALUATION AND {SETTING} NURSE.SURGERY
MANAGEMENT NOTE

PRE-OPERATIVE
34123-0 EVALUATION AND HOSPITAL ANESTHESIA
MANAGEMENT NOTE

PRE-OPERATIVE
34775-7 EVALUATION AND {SETTING} GENERAL SURGERY
MANAGEMENT NOTE

PRE-OPERATIVE
34876-3 EVALUATION AND {SETTING} SURGERY
MANAGEMENT NOTE

PRE-OPERATIVE
34751-8 EVALUATION AND {SETTING} ANESTHESIA
MANAGEMENT NOTE

PRE-OPERATIVE
34809-4 EVALUATION AND {SETTING} OPHTHALMOLOGY
MANAGEMENT NOTE

PRE-OPERATIVE
34747-6 EVALUATION AND {SETTING} NURSING
MANAGEMENT NOTE

28570-0 PROCEDURE NOTE {SETTING} {PROVIDER}

28625-2 PROCEDURE NOTE {SETTING} PODIATRY

28577-5 PROCEDURE NOTE {SETTING} DENTISTRY

11505-5 PROCEDURE NOTE {SETTING} PHYSICIAN

28575-9 PROGRESS NOTE {SETTING} NURSE PRACTITIONER

28580-9 PROGRESS NOTE {SETTING} CHIROPRACTOR

RESPIRATORY
18744-3 STUDY REPORT BRONCHOSCOPY
SYSTEM

SUBSEQUENT
11510-5 {SETTING} PSYCHOLOGY
EVALUATION NOTE

SUBSEQUENT
11508-9 {SETTING} PHYSICAL THERAPY
EVALUATION NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 80/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

SUBSEQUENT
11509-7 {SETTING} PODIATRY
EVALUATION NOTE

SUBSEQUENT
11506-3 {SETTING} {PROVIDER}
EVALUATION NOTE

SUBSEQUENT
11507-1 {SETTING} OCCUPATIONAL THERAPY
EVALUATION NOTE

SUBSEQUENT
11512-1 {SETTING} SPEECH THERAPY
EVALUATION NOTE

SUBSEQUENT EMERGENCY
15507-7 {PROVIDER}
EVALUATION NOTE DEPARTMENT

SUBSEQUENT
18733-6 {SETTING} ATTENDING PHYSICIAN
EVALUATION NOTE

SUBSEQUENT
34904-3 {SETTING} MENTAL HEALTH
EVALUATION NOTE

SUBSEQUENT
34901-9 OUTPATIENT GENERAL MEDICINE
EVALUATION NOTE

SUBSEQUENT
18764-1 {SETTING} NURSE PRACTITIONER
EVALUATION NOTE

SUBSEQUENT HOME
34129-7 {PROVIDER}
EVALUATION NOTE HEALTH

SUBSEQUENT
34132-1 OUTPATIENT PHARMACY
EVALUATION NOTE

SUBSEQUENT
34131-3 OUTPATIENT {PROVIDER}
EVALUATION NOTE

SUBSEQUENT
28656-7 {SETTING} SOCIAL SERVICE
EVALUATION NOTE

SUBSEQUENT
34130-5 HOSPITAL {PROVIDER}
EVALUATION NOTE

SUBSEQUENT
28617-9 {SETTING} DENTISTRY
EVALUATION NOTE

SUBSEQUENT
34128-9 OUTPATIENT DENTISTRY
EVALUATION NOTE

SUBSEQUENT
34127-1 OUTPATIENT DENTAL HYGIENIST
EVALUATION NOTE

SUBSEQUENT CRITICAL
34126-3 {PROVIDER}
EVALUATION NOTE CARE UNIT

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 81/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

SUBSEQUENT
34900-1 {SETTING} GENERAL MEDICINE
EVALUATION NOTE

SUBSEQUENT HOME
34125-5 CASE MANAGER
EVALUATION NOTE HEALTH CARE

SUBSEQUENT
28569-2 {SETTING} CONSULTING PHYSICIAN
EVALUATION NOTE

SUBSEQUENT
18762-5 {SETTING} CHIROPRACTOR
EVALUATION NOTE

SUBSEQUENT
34124-8 OUTPATIENT CARDIOLOGY
EVALUATION NOTE

SUBSEQUENT
28627-8 {SETTING} PSYCHIATRY
EVALUATION NOTE

SUBSEQUENT
28623-7 {SETTING} NURSING
EVALUATION NOTE

SUMMARIZATION OF
34133-9 {SETTING} {PROVIDER}
EPISODE NOTE

34134-7 SUPERVISORY NOTE OUTPATIENT ATTENDING PHYSICIAN

ATTENDING
34135-4 SUPERVISORY NOTE OUTPATIENT
PHYSICIAN.CARDIOLOGY

ATTENDING
34136-2 SUPERVISORY NOTE OUTPATIENT
PHYSICIAN.GASTROENTEROLOGY

SURGICAL OPERATION
28624-5 {SETTING} PODIATRY
NOTE

SURGICAL OPERATION
28573-4 {SETTING} PHYSICIAN
NOTE

SURGICAL OPERATION
11504-8 {SETTING} {PROVIDER}
NOTE

SURGICAL OPERATION
28583-3 {SETTING} DENTISTRY
NOTE

SURGICAL OPERATION
34137-0 OUTPATIENT {PROVIDER}
NOTE

TARGETED HISTORY
34138-8 {SETTING} {PROVIDER}
AND PHYSICAL NOTE

TELEPHONE
34139-6 {SETTING} NURSING
ENCOUNTER NOTE

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 82/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

METHOD_TYPE (Subject
COMPONENT (Type of SYSTEM
LOINC_NUM Matter Domain and/or
Service) (Setting)
Training / Professional Level)

TELEPHONE
34844-1 OUTPATIENT SOCIAL WORK
ENCOUNTER NOTE

TELEPHONE
34748-4 {SETTING} {PROVIDER}
ENCOUNTER NOTE

TRANSFER OF CARE
34140-4 {SETTING} {PROVIDER}
REFERRAL NOTE

TRANSFER
34770-8 {SETTING} GENERAL MEDICINE
SUMMARIZATION NOTE

TRANSFER
18761-7 {SETTING} {PROVIDER}
SUMMARIZATION NOTE

TRANSFER
28651-8 {SETTING} NURSING
SUMMARIZATION NOTE

TRANSFER
28616-1 {SETTING} PHYSICIAN
SUMMARIZATION NOTE

TRANSFER
34755-9 {SETTING} CRITICAL CARE
SUMMARIZATION NOTE

EMERGENCY
28568-4 VISIT NOTE PHYSICIAN
DEPARTMENT

28653-4 VISIT NOTE {SETTING} SOCIAL SERVICE

28618-7 VISIT NOTE {SETTING} DENTISTRY

28579-1 VISIT NOTE {SETTING} PHYSICAL THERAPY

28578-3 VISIT NOTE {SETTING} OCCUPATIONAL THERAPY

28571-8 VISIT NOTE {SETTING} SPEECH THERAPY

28628-6 VISIT NOTE {SETTING} PSYCHIATRY

B.3 CDA and Semantic Interoperability

A long term objective of CDA and other specifications in the V3 family is to achieve increasingly greater
and greater "semantic interoperability", which might be defined as the ability of two applications to
share data, with no prior negotiations, such that decision support within each application continues to
function reliably when processed against the received data.

CDA seeks to achieve the highest level of constraint that can exist in an international standard. Where
international consensus is lacking, and where uses cases in different realms currently preclude
consensus, CDA will need to be necessarily inclusive. In such areas, ongoing harmonization and
consensus building will further enable semantic interopability, which will be reflected in future iterations
of CDA.

While the framework provided by the RIM and by CDA and by the shared HL7 Clinical Statement Model
file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 83/97
4/2/2019 HL7 Clinical Document Architecture, Release 2.0

are a critical component of semantic interoperability, they are not currently sufficient, particularly given
the lack of global terminology solution, and the fact that each terminology overlaps with the RIM in
different ways. Such terminology solutions are outside the scope of CDA, and will need to be addressed
in various national and international forums.

B.4 Changes from CDA Release 1

CDA, Release One became an ANSI-approved HL7 Standard in November, 2000, representing the first
specification derived from the HL7 Reference Information Model (RIM). Since then, the RIM has
matured, as has the methodology used to derive RIM-based specifications. In addition, early adopters
are posing new use cases for incorporation.

The basic model of CDA, Release Two is essentially unchanged. A CDA document has a header and a
body. The body contains nested sections. These sections can be coded using standard vocabularies,
and can contain "entries". CDA, Release One entries included such things as character data, hyperlinks,
and multimedia.

The main evolutionary steps in CDA, Release Two are that both header and body are fully RIM-derived,
and there is a much richer assortment of entries to use within CDA sections. CDA, Release Two enables
clinical content to be formally expressed to the extent that is it modeled in the RIM.

CDA, Release Two takes advantage of HL7’s growing expertise in creating model-based XML standards.
Given the evolution of the RIM and the HL7 development methodology since November 2000, there are
a number of changes between the new and the old CDA.

B.4.1 Deprecated Components

The following components are retained for backwards compatibility with CDA, Release One, and have
been deprecated:

ClinicalDocument/copyTime.
ClinicalDocument/authenticator/signatureCode/@code="X".
ClinicalDocument/legalAuthenticator/signatureCode/@code="X".
ClinicalDocument/assignedAuthor/assignedAuthoringDevice/MaintainedEntity.
ClinicalDocument/recordTarget/patientRole/patient/id.
linkHtml.name.
table.border, table.cellspacing, table.cellpadding.

Further use of these components is discouraged.

B.4.2 CDA R1 to CDA R2 Correspondence

The following tables enumerate CDA R1 components and show the corresponding components in CDA
R2. In some cases, such as where CDA R1 was ambiguous or where a CDA R1 participant was split into
multiple CDA R2 participants, a formal mapping might need to take local usage into account. In such
cases guidance is provided rather than formal rules.

Table 148: CDA R1 to CDA R2 Vocabulary Correspondence

Corresponding CDA R2
CDA R1 vocabulary Comments
vocabulary

clinical_document_header /
document_type_cd <= ClinicalDocument / code <=
DocumentType DocumentType
(2.16.840.1.113883.6.1.10870) (2.16.840.1.113883.6.1) (CWE)
(CWE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 84/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 vocabulary Comments
vocabulary

clinical_document_header / ClinicalDocument /
confidentiality_cd <= confidentialityCode <= Removed "C", "D", "I",
ServiceConfidentiality x_BasicConfidentialityKind "S", "T" from value set.
(2.16.840.1.113883.5.10228) (2.16.840.1.113883.5.25) Added "V" to value set.
(CWE) (CWE)

clinical_document_header /
ClinicalDocument /
document_relationship /
relatedDocument / @typeCode Added "XFRM" to value
document_relationship.type_cd
<= x_ActRelationshipDocument set.
<= ServiceRelationship
(2.16.840.1.113883.5.1002)
(2.16.840.1.113883.5.10317)
(CNE)
(CNE)

clinical_document_header /
ClinicalDocument /
fulfills_order /
inFulfillmentOf / @typeCode <=
fulfills_order.type_cd <= No change in value set.
FLFS
ServiceRelationship
(2.16.840.1.113883.5.1002)
(2.16.840.1.113883.5.10317)
(CNE)
(CNE)

ClinicalDocument /
clinical_document_header / componentOf /
patient_encounter / encompassingEncounter /
practice_setting_cd <= location / healthCareFacility /
PracticeSetting code <=
(2.16.840.1.113883.5.10588) ServiceDeliveryLocationRoleType
(CWE) (2.16.840.1.113883.5.111)
(CWE)

clinical_document_header /
ClinicalDocument /
authenticator /
authenticator / @typeCode <= Fixed value changed from
authenticator.type_cd <=
AUTHEN "VRF" to "AUTHEN".
ServiceActor
(2.16.840.1.113883.5.90)
(2.16.840.1.113883.5.10246)
(CNE)
(CNE)

clinical_document_header / ClinicalDocument /
authenticator / signature_cd <= authenticator / signatureCode Value of "X" has been
ServiceActorSignature <= ParticipationSignature deprecated.
(2.16.840.1.113883.5.10282) (2.16.840.1.113883.5.89)
(CNE) (CNE)

Vocabulary domain has

changed from CWE to
clinical_document_header /
ClinicalDocument / CNE. The CDA R2 value
authenticator / person /
authenticator / assignedEntity / set includes enumerated
person_name /
assignedPerson / name / @use CDA R1 values ("A", "C",
person_name.type_cd <=
<= PersonNameUse "I", "L", "R"). CDA R1 to
PersonNamePurpose
(2.16.840.1.113883.5.45) CDA R2 translations may
(2.16.840.1.113883.5.200)
(CNE) require local markup
(CWE)
where the CDA R1 value
set was extended.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 85/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 vocabulary Comments
vocabulary

clinical_document_header /
ClinicalDocument /
legal_authenticator /
legalAuthenticator / @typeCode Fixed value changed from
authenticator.type_cd <=
<= LA "SPV" to "AUTHEN".
ServiceActor
(2.16.840.1.113883.5.90)
(2.16.840.1.113883.5.10246)
(CNE)
(CNE)

clinical_document_header / ClinicalDocument /
legal_authenticator / legalAuthenticator /
signature_cd <= signatureCode <= Value of "X" has been
ServiceActorSignature ParticipationSignature deprecated.
(2.16.840.1.113883.5.10282) (2.16.840.1.113883.5.89)
(CNE) (CNE)

clinical_document_header /
ClinicalDocument /
intended_recipient /
intendedRecipient / @typeCode Added "PRCP" to value
intended_recipient.type_cd <=
<= x_InformationRecipient set.
ServiceActor
(2.16.840.1.113883.5.90)
(2.16.840.1.113883.5.10246)
(CNE)
(CNE)

clinical_document_header /
ClinicalDocument / author /
originator / originator.type_cd
@typeCode <= AUT No change to value set.
<= ServiceActor
(2.16.840.1.113883.5.90)
(2.16.840.1.113883.5.10246)
(CNE)
(CNE)

clinical_document_header /
originating_organization / ClinicalDocument / custodian /
originating_organization.type_cd @typeCode <= CST No change to value set.
<= ServiceActor (2.16.840.1.113883.5.90)
(2.16.840.1.113883.5.10246) (CNE)
(CNE)

clinical_document_header /
transcriptionist / ClinicalDocument / dataEnterer
transcriptionist.type_cd <= / @typeCode <= ENT No change to value set.
ServiceActor (2.16.840.1.113883.5.90)
(2.16.840.1.113883.5.10246) (CNE)
(CNE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 86/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 vocabulary Comments
vocabulary

ClinicalDocument / serviceEvent
/ performer / @typeCode <=
x_ServiceEventPerformer
(2.16.840.1.113883.5.90)
(CNE) (Value set "PRF", "PPRF",
"SPRF")

CDA R1 provider has been

ClinicalDocument / split into three distinct
clinical_document_header / encompassingEncounter / participants. Local use of
provider / provider.type_cd <= responsibleParty / @typeCode CDA R1 can be used to
ServiceActor <= RESP determine the exact
(2.16.840.1.113883.5.10246) (2.16.840.1.113883.5.90) correspondence.
(CNE) (Value set "ASS", "CON", (CNE)
"PRF") CDA R1 value "ASS"
correlates with CDA R2
ClinicalDocument / value "SPRF".
encompassingEncounter /
encounterParticipant /
@typeCode <=
x_EncounterParticipant
(2.16.840.1.113883.5.90)
(CNE) (Value set "ADM",
"ATND", "CON" , "DIS" , "REF")

clinical_document_header / ClinicalDocument / serviceEvent

provider / function_cd <= / performer / functionCode <=
ServiceActorFunction ParticipationFunction
(2.16.840.1.113883.5.10267) (2.16.840.1.113883.5.88)
(CWE) (CWE)

Vocabulary domain has

clinical_document_header /
ClinicalDocument / participant / changed from CWE to
service_actor /
@typeCode <= CNE. CDA R1 to CDA R2
service_actor.type_cd <=
ParticipationType translations may require
ServiceActor
(2.16.840.1.113883.5.90) local markup where the
(2.16.840.1.113883.5.10246)
(CNE) CDA R1 value set was
(CWE)
extended.

clinical_document_header / ClinicalDocument /
service_actor / signature_cd <= authenticator / signatureCode Value of "X" has been
ServiceActorSignature <= ParticipationSignature deprecated.
(2.16.840.1.113883.5.10282) (2.16.840.1.113883.5.89)
(CNE) (CNE)

clinical_document_header / ClinicalDocument / recordTarget

patient / / patientRole / patient /
administrative_gender_cd <= administrativeGenderCode <=
AdministrativeGender AdministrativeGender
(2.16.840.1.113883.5.1) (CWE) (2.16.840.1.113883.5.1) (CWE)

clinical_document_header /
originating_device / ClinicalDocument / author /
originating_device.type_cd <= @typeCode <= AUT CDA R1 "ODV" maps to
ServiceTargetType (2.16.840.1.113883.5.90) CDA R2 "AUT".
(2.16.840.1.113883.5.10285) (CNE)
(CNE)

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 87/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 vocabulary Comments
vocabulary

Vocabulary domain has

changed from CWE to
clinical_document_header / ClinicalDocument / author /
CNE. The CDA R2 value
originating_device / device / assignedAuthor /
set includes enumerated
responsibility / assignedAuthoringDevice /
CDA R1 values ("MNT").
responsibility.type_cd <= asMaintainedEntity /
CDA R1 to CDA R2
MaterialResponsibility @classCode <= MNT
translations may require
(2.16.840.1.113883.5.10416) (2.16.840.1.113883.5.110)
local markup where the
(CWE) (CNE)
CDA R1 value set was
extended.

Vocabulary domain has

clinical_document_header /
ClinicalDocument / participant / changed from CWE to
service_target /
@typeCode <= CNE. CDA R1 to CDA R2
service_target.type_cd <=
ParticipationType translations may require
ServiceTargetType
(2.16.840.1.113883.5.90) local markup where the
(2.16.840.1.113883.5.10285)
(CNE) CDA R1 value set was
(CWE)
extended.

See also
caption/caption_cd in the
section / code <=
section / caption / caption_cd next row. The caption of a
DocumentSectionType
(CWE) section corresponds to
(2.16.840.1.113883.6.1) (CWE)
CDA R2 differently than
other captions.

See also
section/caption/caption_cd
@styleCode <= StyleType in the row above. The
caption / caption_cd (CWE) (2.16.840.1.113883.19.5.1) caption of a section
(CWE) corresponds to CDA R2
differently than other
captions.

Table 149: CDA R1 to CDA R2 Header Correspondence

Corresponding CDA R2
CDA R1 component Comments
component

levelone ClinicalDocument

levelone / Wrapping header tag no

NOT PRESENT
clinical_document_header longer present.

clinical_document_header / id ClinicalDocument / id

clinical_document_header /
ClinicalDocument / setId
set_id

clinical_document_header / ClinicalDocument /
version_nbr versionNumber

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 88/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 component Comments
component

clinical_document_header /
ClinicalDocument / code
document_type_cd

The GTS data type in

CDA R1 has been
constrained to a time
ClinicalDocument /
clinical_document_header / interval in CDA R2.
documentationOf / serviceEvent /
service_tmr Local markup can be
effectiveTime
used where it is
necessary to convey
additional complexity.

clinical_document_header /
ClinicalDocument / effectiveTime
origination_dttm

clinical_document_header /
ClinicalDocument / copyTime
copy_dttm

Cardinality changed
from [0..*] to [0..1].
CDA R1 expressed all
confidentiality flags in
the header, which were
clinical_document_header / ClinicalDocument / then referenced from
confidentiality_cd confidentialityCode within the body. CDA
R2 expresses
confidentiality in the
header, and allows it to
be overridden in the
body.

clinical_document_header / ClinicalDocument /
document_relationship relatedDocument

document_relationship /
relatedDocument / @typeCode
document_relationship.type_cd

document_relationship / relatedDocument /
related_document parentDocument

document_relationship / relatedDocument /
related_document / id parentDocument / id

document_relationship / relatedDocument /
related_document / set_id parentDocument / setId

document_relationship / relatedDocument /
related_document / version_nbr parentDocument / versionNumber

clinical_document_header /
ClinicalDocument / inFulfillmentOf
fulfills_order

fulfills_order /
inFulfillmentOf / @typeCode
fulfills_order.type_cd

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 89/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 component Comments
component

fulfills_order / order inFulfillmentOf / order

fulfills_order / order / id inFulfillmentOf / order / id

clinical_document_header / ClinicalDocument / componentOf /

patient_encounter encompassingEncounter

patient_encounter / id encompassingEncounter / id

patient_encounter / encompassingEncounter / location

practice_setting_cd / healthCareFacility / code

patient_encounter / encompassingEncounter /
encounter_tmr effectiveTime

patient_encounter / encompassingEncounter / location

service_location / healthCareFacility

patient_encounter / encompassingEncounter / location

service_location / id / healthCareFacility / id

encompassingEncounter / location
patient_encounter /
/ healthCareFacility / location /
service_location / addr
addr

The time interval data

type in CDA R1 has
been constrained to a
clinical_document_header / point in time in CDA R2.
ClinicalDocument / authenticator
authenticator Local markup can be
used where it is
necessary to convey
additional complexity.

authenticator /
authenticator / @typeCode
authenticator.type_cd

authenticator / participation_tmr authenticator / time

CDA R1 represented
either an intended
(signature code "X") or
actual (signature code
authenticator / signature_cd authenticator / signatureCode "S") authenticator. CDA
R2 only represents an
actual authenticator, so
has deprecated the
value of "X".

authenticator / assignedEntity /
authenticator / person
assignedPerson

authenticator / person / id authenticator / assignedEntity / id

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 90/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 component Comments
component

authenticator / person / authenticator / assignedEntity /

person_name assignedPerson / name

authenticator / assignedEntity /
authenticator / person /
assignedPerson / name /
person_name / effective_tmr
validTime

authenticator / person / authenticator / assignedEntity /

person_name / nm assignedPerson / name

authenticator / person /
authenticator / assignedEntity /
person_name /
assignedPerson / name / @use
person_name.type_cd

authenticator / assignedEntity /
authenticator / person / addr
addr /

authenticator / assignedEntity /
authenticator / person / telecom
telecom

clinical_document_header / ClinicalDocument /
legal_authenticator legalAuthenticator

legal_authenticator /
legalAuthenticator / @typeCode
legal_authenticator.type_cd

The time interval data

type in CDA R1 has
been constrained to a
legal_authenticator / point in time in CDA R2.
legalAuthenticator / time
participation_tmr Local markup can be
used where it is
necessary to convey
additional complexity.

CDA R1 represented
either an intended
(signature code "X") or
actual (signature code
legal_authenticator / legalAuthenticator / "S") legal authenticator.
signature_cd signatureCode CDA R2 only represents
an actual legal
authenticator, so has
deprecated the value of
"X".

legalAuthenticator /
legal_authenticator / person
assignedEntity / assignedPerson

clinical_document_header / ClinicalDocument /
intended_recipient intendedRecipient

intended_recipient /
intendedRecipient / @typeCode
intended_recipient.type_cd

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 91/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 component Comments
component

clinical_document_header /
ClinicalDocument / author
originator

originator / originator.type_cd author / @typeCode

The time interval data

type in CDA R1 has
been constrained to a
point in time in CDA R2.
originator / participation_tmr author / time
Local markup can be
used where it is
necessary to convey
additional complexity.

The CDA R1
originating_organization
ClinicalDocument / author corresponds to the
clinical_document_header / scoper of the author
originating_organization AND the custodian
ClinicalDocument / custodian organization, because it
served both purposes in
R1.

originating_organization /
custodian / @typeCode
originating_organization.type_cd

author / assignedAuthor /
representedOrganization
originating_organization /
organization
custodian / assignedCustodian /
representedCustodianOrganization

author / assignedAuthor /
representedOrganization / id
originating_organization /
organization / id custodian / assignedCustodian /
representedCustodianOrganization
/ id

author / assignedAuthor /
representedOrganization / name
originating_organization /
organization / organization.nm custodian / assignedCustodian /
representedCustodianOrganization
/ name

author / assignedAuthor /
representedOrganization / addr
originating_organization /
organization / addr custodian / assignedCustodian /
representedCustodianOrganization
/ addr

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 92/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 component Comments
component

clinical_document_header /
ClinicalDocument / dataEnterer
transcriptionist

transcriptionist /
dataEnterer / @typeCode
transcriptionist.type_cd

The time interval data

type in CDA R1 has
been constrained to a
transcriptionist / point in time in CDA R2.
dataEnterer / time
participation_tmr Local markup can be
used where it is
necessary to convey
additional complexity.

ClinicalDocument / serviceEvent /
performer
CDA R1 provider has
been split into three
ClinicalDocument /
distinct participants.
clinical_document_header / encompassingEncounter /
Local use of CDA R1
provider responsibleParty
can be used to
determine the exact
ClinicalDocument / correspondence.
encompassingEncounter /
encounterParticipant

Alternatively, could
correspond to one of
the new more specific
clinical_document_header / participants (e.g.
ClinicalDocument / participant
service_actor informant, performer,
responsibleParty,
encounterParticipant)
depending on local use.

service_actor /
participant / @typeCode
service_actor.type_cd

service_actor / participation_tmr participant / time

Local use of CDA R1

can determine whether
service actor signatures
service_actor / signature_cd authenticator / signatureCode
can be reflected as
additional CDA R2
authenticators.

clinical_document_header /
ClinicalDocument / recordTarget
patient

patient / patient.type_cd recordTarget / @typeCode

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 93/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 component Comments
component

Local markup can be

patient / participation_tmr NOT PRESENT used to accommodate
mapping if necessary.

recordTarget / patientRole /
patient / person
patient

recordTarget / patientRole /
patient / person / id
patient / id

patient / is_known_by recordTarget / patientRole

patient / is_known_by / id recordTarget / patientRole / id

CDA R1 allows for

multiple is_known_by
relationships, each with
its own is_known_to
relationship. CDA R2
has a single
providerOrganization.
Where CDA R1 has
patient / is_known_by / recordTarget / patientRole /
listed multiple
is_known_to providerOrganization
organizations, the one
that is also the
custodian organization
corresponds to
providerOrganization.
Other values can be
modeled using local
markup.

patient / is_known_by / recordTarget / patientRole /

is_known_to / id providerOrganization / id

recordTarget / patientRole /
patient / birth_dttm
patient / birthTime

recordTarget / patientRole /
patient /
patient /
administrative_gender_cd
administrativeGenderCode

clinical_document_header /
ClinicalDocument / author
originating_device

originating_device /
author / @typeCode
originating_device.type_cd

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 94/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding CDA R2
CDA R1 component Comments
component

The time interval data

type in CDA R1 has
been constrained to a
originating_device / point in time in CDA R2.
author / time
participation_tmr Local markup can be
used where it is
necessary to convey
additional complexity.

originating_device / device author / assignedAuthor

originating_device / device / id author / assignedAuthor / id

author / assignedAuthor /
originating_device / device /
assignedAuthoringDevice /
responsibility
asMaintainedEntity

originating_device / device / author / assignedAuthor /

responsibility / assignedAuthoringDevice /
responsibility.type_cd asMaintainedEntity / @classCode

originating_device / device / author / assignedAuthor /

responsibility / assignedAuthoringDevice /
responsibility_tmr asMaintainedEntity / effectiveTime

Alternatively, could
correspond to one of
the new more specific
clinical_document_header / participants (e.g.
ClinicalDocument / participant
service_target informant, performer,
responsibleParty,
encounterParticipant)
depending on local use.

service_target /
participant / @typeCode
service_target.type_cd

service_target /
participant / time
participation_tmr

Table 150: CDA R1 to CDA R2 Body Correspondence

Corresponding
CDA R1 component CDA R2 Comments
component

ClinicalDocument /
levelone / body /
component /
non_xml
nonXMLBody

ClinicalDocument /
component /
levelone / body / section
structuredBody /
section

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 95/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding
CDA R1 component CDA R2 Comments
component

In CDA R1, all authors are listed in

the header, and then referenced from
the body. In CDA R2, authors listed in
section / @originator section / author
the header propagate to the body
where they can be overridden (as
described in "CDA Context").

In CDA R1, all confidentiality values

are listed in the header, and then
referenced from the body. In CDA R2,
section / section /
confidentiality listed in the header
@confidentiality confidentialityCode
propagates to the body where it can
be overridden (as described in "CDA
Context").

section /
section / @xml:lang
languageCode

section / caption section / title

Local use can determine whether to

section / caption / link NOT PRESENT map to linkHtml in the narrative
block of CDA R2.

See also caption/caption_cd in the

section / caption / row below. The caption of a section
section / code
caption_cd corresponds to CDA R2 differently
than other captions.

In CDA R2, section authorship applies

to the narrative block. Nested entries
with an associated author participant
@originator SEE COMMENTS
can reference into the narrative block
where it is necessary to ascribe
authorship to a particular statement.

Confidentiality cannot be ascribed

@confidentiality NOT PRESENT
below the section level.

The language attribute functions as it

@xml:lang @language
did in CDA R1.

content content

The CDA R1 link tag no longer exists.

It had a required child element,
link linkHtml
link_html, which corresponds to CDA
R2 linkHtml.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 96/97

4/2/2019 HL7 Clinical Document Architecture, Release 2.0

Corresponding
CDA R1 component CDA R2 Comments
component

section / entry /
coded_entry
act

coded_entry / section / entry /

coded_entry.id act / id

coded_entry / section / entry /

coded_entry.value act / code

Use the renderMultiMedia tag in the

section / entry /
observation_media narrative block to reference an
observationMedia
observationMedia entry.

section / entry /
observation_media /
observationMedia /
observation_media.id
id

section / entry /
observation_media /
observationMedia /
observation_media.value
value

Local markup is precluded from use

in the CDA R2 narrative block
particularly if they would interfere
with the ability of those not
local_markup SEE COMMENTS recognizing the markup to properly
render the document. Foreign
namespace extensions can be used
outside the narrative block (as
described in "CDA Extensibility").

caption caption

See also section/caption/caption_cd

in the row above. The caption of a
caption / caption_cd @styleCode
section corresponds to CDA R2
differently than other captions.

paragraph paragraph

list list

CDA R2 table content model no

longer contains a "tr" element. This
table table
element is now wrapped in a "tbody"
element.

file:///D:/Work/Projects/Tech Docs/cda_r2_normativewebedition2010/infrastructure/cda/cda.htm 97/97