io.connectedhealth_idaas.eventbuilder.dataobjects.clinical.hl7v3.cda.htm Maven / Gradle / Ivy
HL7 Clinical Document Architecture, Release 2.0
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.2 ?The "A" in "CDA"
1.2.4 ?XML Markup of CDA
Documents
1.3 ?CDA Conformance
1.3.1 ?Recipient
Responsibilities
1.3.2 ?Originator
Responsibilities
1.4 ?CDA Extensibility
2.2 ?HL7 V3 Data Types
2.4 ?HL7 CDA R-MIM
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
Appendices
A ?Samples
A.1 ?Sample Document
A.2 ?Sample CDA Instance
B.2 ?LOINC Document Codes
B.4.1 ?Deprecated Components
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
?
?
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.
- 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>
... 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 One
CDA, Release Two
CDA Level One
The unconstrained CDA specification.
CDA Level Two
The CDA specification with section-level
templates applied.
CDA Level Three
The CDA specification with entry-level (and
optionally section-level) templates applied.
?
?
?
?
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 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 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.
- 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.
?
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 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.
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.
?
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.
?
?
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: <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: <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 Component
CDA Component
Comments
ClinicalDocument
ClinicalDocument
Medical Records includes attributes not
present in CDA (text, statusCode, availabilityTime, reasonCode,
completioncode, storageCode, copyTime); CDA includes attributes
not present in Medical Records (title).
authenticator
authenticator
?
legalAuthenticator
legalAuthenticator
?
dataEnterer
dataEnterer
?
EncounterEvent / encounterPerformer
encompassingEncounter / encounterParticipant;
serviceEvent / performer
The Medical Records encounterPerformer is
split into two CDA participants.
responsibleParty
responsibleParty
?
custodian
custodian
?
participant
participant
?
informationRecipient
informationRecipient
?
recordTarget
recordTarget
?
author
author
?
subject
subject
The Medical Records subject is a directory of
all subjects listed in the document.
relatedDocument / ParentDocument
relatedDocument / parentDocument
?
documentationOf / Event
documentationOf / serviceEvent
?
inFulfillmentOf / Order
inFulfillmentOf / order
?
componentOf / EncounterEvent
componentOf / 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: <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: <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
?
?
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 [default]
A clinical document is a documentation of
clinical observations and services, as defined above.
?
?
?
?
Table 6: Value set for ClinicalDocument.moodCode (CNE)
Code
Definition
EVN (event) [default]
An actual occurrence of an event (i.e., the
documentation act already happened and is not just a request,
intent, plan or promise to document).
?
?
?
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 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
N (normal) (codeSystem 2.16.840.1.113883.5.25)
Normal confidentiality rules (according to
good health care practice) apply. That is, only authorized
individuals with a legitimate medical or business need may
access this item.
R (restricted) (codeSystem
2.16.840.1.113883.5.25)
Restricted access, e.g. only to providers
having a current care relationship to the patient.
V (very restricted) (codeSystem
2.16.840.1.113883.5.25)
Very restricted access as declared by the
Privacy Officer of the record holder.
?
?
* 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 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 (authenticator)
[default]
A verifier who attests to the accuracy of an
act, but who does not have privileges to legally authenticate
the act.
?
?
?
?
Table 9: Value set for authenticator.signatureCode (CNE)
Code
Definition
S (signed)
Signature has been affixed and is on file.
X (required) (Deprecated)
CDA Release One represented either an intended
("X") or actual ("S") authenticator. CDA Release Two only
represents an actual authenticator, so 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 (Assigned) [default]
An agent role in which the agent is an entity
acting in the employ of an organization. The focus is on the
functional role on behalf of the organization.
?
?
?
?
Table 11: Value set for Person.classCode (CNE)
Code
Definition
PSN (person) [default]
A living subject of the species homo sapiens.
?
?
?
?
Table 12: Value set for Person.determinerCode (CNE)
Code
Definition
INSTANCE (instance) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or 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
INSTANCE (Assigned) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or 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) [default]
An association between two Entities where the
playing Entity is part of the scoping entity.
?
?
?
?
Table 16: Value set for OrganizationPartOf.statusCode (CNE)
Code
Definition
normal (normal)
The 'typical' state. Excludes "nullified"
which represents the termination state of a Role instance that
was created in error.
active (active)
The state representing the fact that the
Entity is currently active in the Role.
cancelled (cancelled)
The terminal state resulting from cancellation
of the role prior to activation.
pending (pending)
The state representing that fact that the role
has not yet become active.
suspended (suspended)
The state that represents a suspension of the
Entity playing the Role. This state is arrived at from the
"active" state.
terminated (terminated)
The state representing the successful
termination of the Role.
nullified (nullified)
The state representing the termination of a
Role instance that was created 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) [default]
A party that originates the Act and therefore
has responsibility for the information given in the Act.
?
?
?
?
Table 18: Value set for author.contextControlCode (CNE)
Code
Definition
OP (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
?
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 entity)
[default]
A role in which the playing entity is acting
in the employ of or on behalf of a scoping organization.
?
?
?
?
Table 20: Value set for AuthoringDevice.classCode (CNE)
Code
Definition
DEV (device) [default]
An entity used in an activity, without being
substantially changed through that activity.
?
?
?
?
Table 21: Value set for AuthoringDevice.determinerCode (CNE)
Code
Definition
INSTANCE (Assigned) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or one can refer to cars in general (a car kind).
?
?
?
?
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 (maintained entity)
[default]
An entity that is maintained by another
entity. This is typically a role held by durable equipment. The
scoper assumes responsibility for proper operation, quality,
and safety.
?
?
?
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 entity)
[default]
A role in which the playing entity is acting
in the employ of or 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
INSTANCE (Assigned) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or 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.
?
?
Table 27: Value set for dataEnterer.typeCode (CNE)
Code
Definition
ENT (transcriptionist)
[default]
A person entering the data into the
originating system. The data entry person is collected
optionally for internal quality control purposes. This includes
the transcriptionist for dictated text.
?
?
?
?
Table 28: Value set for dataEnterer.contextControlCode (CNE)
Code
Definition
OP (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
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 (informant) [default]
A source of reported information (e.g., a next
of kin who answers questions about the patient's history). For
history questions, unless otherwise stated, the patient is
implicitly the informant.
?
?
?
?
Table 30: Value set for informant.contextControlCode (CNE)
Code
Definition
OP (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
?
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
Any subtype of RoleClassMutualRelationship
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
involvement with each other (e.g. parties over a dispute,
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)
[default]
Recipient to whom the document is primarily
directed.
TRC (secondary recipient)
A secondary recipient to whom the document is
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 entity)
[default]
A role in which the playing entity is acting
in the employ of or on behalf of a scoping organization.
HLTHCHRT (health chart)
A role in which the playing entity is a
physical health 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).
?
?
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 authenticator)
[default]
A verifier who legally authenticates the
accuracy of an act. An example would be a staff physician who
sees a patient and dictates a note, then 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.
X (required) (Deprecated)
CDA Release One represented either an intended
("X") or actual ("S") legal authenticator. CDA Release Two only
represents an actual legal authenticator, so has deprecated the
value of "X".
?
?
?
?
Table 36: Value set for
legalAuthenticator.contextControlCode (CNE)
Code
Definition
OP (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
?
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 subtype
See vocabulary domain "ParticipationType" for
allowable values.
?
?
?
?
Table 38: Value set for participant.contextControlCode (CNE)
Code
Definition
OP (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
?
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 (Organization class).
?
?
Table 39: Value set for AssociatedEntity.classCode (CNE)
Code
Definition
Any RoleClassAssociative subtype
See vocabulary domain "RoleClassAssociative"
for allowable 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) [default]
The record target indicates whose medical
record holds the documentation of this act.
?
?
?
?
Table 41: Value set for recordTarget.contextControlCode
(CNE)
Code
Definition
OP (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
?
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
PSN (person) [default]
A living subject of the species homo
sapiens.
?
?
?
?
Table 44: Value set for Patient.determinerCode (CNE)
Code
Definition
INSTANCE (instance) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or 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)
[default]
Relates a place as the location where a living
subject was 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
INSTANCE (instance) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or 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) [default]
An entity (player) that acts or is authorized
to act as the guardian 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
?
?
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
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.
?
?
?
?
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 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) [default]
The current document is a documentation of the
related 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 (performer)
A person who actually and principally carries
out an action.
PPRF (primary performer)
The principal performer of the
ServiceEvent.
SPRF (secondary performer)
A person assisting in the ServiceEvent through
their substantial presence and involvement. This may include
assistants, technicians, associates, or 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)
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)
[default]
The consent authorizes or certifies acts
specified in the current document.
?
?
?
?
Table 61: Value set for Consent.classCode (CNE)
Code
Definition
CONS (consent) [default]
The Consent class represents informed consents
and medico-legal 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
completed
The consent being referenced by the CDA
document has been finalized and is 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.
?
?
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) [default]
The current document is a documentation of
events that occurred during the EncompassingEncounter.
?
?
?
?
Table 65: Value set for EncompassingEncounter.classCode
(CNE)
Code
Definition
ENC (encounter) [default]
An interaction between a patient and
healthcare participant(s) for the purpose of providing patient
service(s) or assessing the health status of a 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 (location) [default]
The location where the service is done. May be
a static building (or room therein) or a moving location (e.g.,
ambulance, helicopter, aircraft, train, truck, ship, etc.)
?
?
?
?
Table 68: Value set for HealthCareFacility.classCode (CNE)
Code
Definition
SDLOC (service delivery location)
[default]
A role played by a place at which services may
be provided.
Any SDLOC (RoleClassServiceDeliveryLocation)
subtype
See vocabulary domain
"RollClassServiceDeliveryLocation" for allowable 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 (responsible party)
[default]
The provider (person or organization) who has
primary responsibility for the encounter. The responsible
provider is not necessarily present in an encounter, but is
accountable for the action through the power to delegate, 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 (admitter)
The practitioner who admits a patient to a
hospital stay.
ATND (attender)
The primary practitioner that oversees a
patient's care during an encounter.
CONS (consultant)
An advising practioner participating in the
encounter by performing evaluations and making
recommendations.
DIS (discharger)
The practitioner who discharges a patient from
a hospital stay.
REF (referrer)
A person having referred the patient for
services resulting in the encounter.
?
?
?
?
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 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) [default]
The associated document body is a component of
the 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)
[default]
A context that distinguishes the body of a
document from 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
N (normal) (codeSystem 2.16.840.1.113883.5.25)
Normal confidentiality rules (according to
good health care practice) apply. That is, only authorized
individuals with a legitimate medical or business need may
access this item.
R (restricted) (codeSystem
2.16.840.1.113883.5.25)
Restricted access, e.g. only to providers
having a current care relationship to the patient.
V (very restricted) (codeSystem
2.16.840.1.113883.5.25)
Very restricted access as declared by the
Privacy Officer of the record holder.
?
?
* 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)
[default]
A context that distinguishes the body of a
document from the document header.
?
?
?
?
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
N (normal) (codeSystem 2.16.840.1.113883.5.25)
Normal confidentiality rules (according to
good health care practice) apply. That is, only authorized
individuals with a legitimate medical or business need may
access this item.
R (restricted) (codeSystem
2.16.840.1.113883.5.25)
Restricted access, e.g. only to providers
having a current care relationship to the patient.
V (very restricted) (codeSystem
2.16.840.1.113883.5.25)
Very restricted access as declared by the
Privacy Officer of the record holder.
?
?
* 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) [default]
The associated section is a component of the
document 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 (document section)
[default]
A context that subdivides the body of a
document. Document sections are typically used for human
navigation, to give a reader a clue as to the expected content.
Document sections are used to organize and provide consistency
to 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
?
?
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
N (normal) (codeSystem 2.16.840.1.113883.5.25)
Normal confidentiality rules (according to
good health care practice) apply. That is, only authorized
individuals with a legitimate medical or business need may
access this item.
R (restricted) (codeSystem
2.16.840.1.113883.5.25)
Restricted access, e.g. only to providers
having a current care relationship to the patient.
V (very restricted) (codeSystem
2.16.840.1.113883.5.25)
Very restricted access as declared by the
Privacy Officer of the record holder.
?
?
* 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
?
?
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 (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
?
Table 84: Value set for RelatedSubject.classCode (CNE)
Code
Definition
PRS (personal relationship)
[default]
The subject has a personal relationship to the
patient. The type of personal relationship is stated in
SubjectRole.code, with a value drawn from the extensible (CWE)
PersonalRelationshipRoleType vocabulary domain. The scoper is
always the patient, and is implied.
PAT (patient)
The subject of an entry is the patient, who is
identified in the recordTarget 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
INSTANCE (instance) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or 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 )).
?
?
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 (component) [default]
The associated entry is a component of the
section. No semantic relationship is implied.
DRIV (is derived from)
The narrative was rendered from the CDA
Entries, and contains no 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 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>
?
?
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>
?
?
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
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.
?
?
?
?
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)
Code
Definition
ACT (act)
A healthcare service.
ACCM (accommodation)
An accommodation is a service provided for a
Person or other LivingSubject in which a place is provided for
the subject to reside for a period of time.
CONS (consent)
Represents informed consents and other
medico-legal transactions between the patient (or legal
guardian) and the provider.
CTTEVENT (clinical trial timepoint event)
An identified point during a clinical trial at
which one or more actions are scheduled to be performed
(definition mood), or are actually performed (event mood).
INC (incident)
An event that occurred outside of the control
of one or more of the parties involved. Includes the concept of
an accident.
INFRM (inform)
The act of transmitting information and
understanding about a topic (or requesting that such
information be transmitted) to a subject.
PCPR (care provision)
A patient care provision is the taking on of
the responsibility by a performer for the health care of a
patient or group of patients.
REG (registration)
Represents the act of maintaining information
about an entity or role in a registry.
SPCTRT (specimen treatment)
A procedure or treatment performed on a
specimen to prepare it for analysis
?
?
?
?
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.
?
?
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
ENC (encounter)
An interaction between a patient and
healthcare participant(s) for the purpose of providing patient
service(s) or assessing the health status of a 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 (observation)
Observations are actions performed in order to
determine an answer or result value.
Any OBS subtype
See vocabulary domain "ActClassObservation"
for allowable values.
?
?
?
?
Table 95: Value set for Observation.moodCode (CNE)
Code
Definition
EVN (event)
The entry defines an actual occurrence of an
event.
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 values)
[default]
Reference ranges are essentially descriptors
of a class of result values assumed to be "normal", "abnormal",
or "critical". This link type can act as a trigger in case of
alarms being triggered by critical results.
?
?
?
?
Table 97: Value set for ObservationRange.classCode (CNE)
Code
Definition
OBS (observation) [default]
Observations are actions performed in order to
determine an answer or result value.
Any OBS subtype
See vocabulary domain "ActClassObservation"
for allowable values.
?
?
?
?
Table 98: Value set for ObservationRange.moodCode (CNE)
Code
Definition
EVN.CRT (event criterion)
[default]
A criterion or condition over observations
that must apply for an 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, 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
BATTERY (battery)
A battery specifies a set of observations.
These observations typically have a logical or practical
grouping for generally accepted clinical or functional
purposes, such as observations that are grouped together
because of automation.
CLUSTER (cluster)
A group of entries that have a logical
association with one another. The 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
PROC (procedure)
An act whose immediate and primary outcome
(post-condition) is the 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 interest)
A Region of Interest specified for an image
using an 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)
Code
Definition
CIRCLE (circle)
A circle defined by two (column,row) pairs.
The first point is the center of the circle and the second
point is a point on the perimeter of the circle.
ELLIPSE (ellipse)
An ellipse defined by four (column,row) pairs,
the first two points specifying the endpoints of the major axis
and the second two points specifying the endpoints of the minor
axis.
POINT (point)
A single point denoted by a single
(column,row) pair, or multiple points each denoted by a
(column,row) pair.
POLY (polyline)
A series of connected line segments with
ordered vertices denoted by (column,row) pairs; if the first
and last vertices are the same, it is a closed 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>
</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 administration)
The act of introducing or otherwise applying a
substance to 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"/>
</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) [default]
A substance that is taken up or consumed as
part of the 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 (kind) [default]
The described determiner is used to indicate
that the given Entity is taken as a general description of a
kind of thing that can be taken in whole, in part, or in
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
KIND (kind) [default]
The described determiner is used to indicate
that the given Entity is taken as a general description of a
kind of thing that can be taken in whole, in part, or in
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) [default]
A material target that is brought forth (e.g.
dispensed) in the 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"/>
<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 subtype
See vocabulary domain "ParticipationType" for
allowable values.
?
?
?
?
Table 120: Value set for participant.contextControlCode
(CNE)
Code
Definition
OP (overriding propagating)
[default]
The participant overrides associations with
the same typeCode. This overriding association will propagate
to any descendant Acts reached by conducting ActRelationships.
(See section "CDA Context" below.)
?
?
?
?
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) subtype
See vocabulary domain "RoleClassRoot" for
allowable values.
?
?
?
?
Table 122: Value set for Device.classCode (CNE)
Code
Definition
DEV (device) [default]
An entity used in an activity, without being
substantially changed through that activity.
Any DEV subtype
See vocabulary domain "EntityClassDevice" for
allowable values.
?
?
?
?
Table 123: Value set for Device.determinerCode (CNE)
Code
Definition
INSTANCE (instance) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or one can refer to cars in general (a car kind).
?
?
?
?
Table 124: Value set for PlayingEntity.classCode (CNE)
Code
Definition
ENT (entity) [default]
A physical thing, group of physical things or
an organization capable of participating in Acts, while in a
role.
Any ENT subtype
See vocabulary domain "EntityClassRoot" for
allowable values.
?
?
?
?
Table 125: Value set for PlayingEntity.determinerCode (CNE)
Code
Definition
INSTANCE (instance) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or one can refer to cars in general (a car kind).
?
?
?
?
Table 126: Value set for Entity.classCode (CNE)
Code
Definition
ENT (entity) [default]
A physical thing, group of physical things or
an organization capable of participating in Acts, while in a
role.
Any ENT subtype
See vocabulary domain "EntityClassRoot" for
allowable values.
?
?
?
?
Table 127: Value set for Entity.determinerCode (CNE)
Code
Definition
INSTANCE (instance) [default]
The INSTANCE determiner indicates an actual
occurrence of an entity, as opposed to the KIND determiner,
which refers to the general description of a kind of entity.
For example, one can refer to a specific car (a car instance),
or 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 (performer) [default]
A person who actually and principally carries
out or will carry out the action. The traditional order filler
is a performer.
?
?
?
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) [default]
The subject of non-clinical (e.g. laboratory)
observation services.
?
?
?
?
Table 130: Value set for SpecimenRole.classCode (CNE)
Code
Definition
SPEC (specimen) [default]
A role played by a material entity that is a
specimen for an 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.
?
?
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) [default]
Observations are actions performed in order to
determine an answer or result value.
Any OBS subtype
See vocabulary domain "ActClassObservation"
for allowable values.
?
?
?
?
Table 134: Value set for Criterion.moodCode (CNE)
Code
Definition
EVN.CRT (event criterion)
[default]
A criterion or condition that must apply for
an associated 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 Type
Reasonable Source and Target entries
Comments
CAUS (is etiology for)
[Act | Observation | Procedure |
SubstanceAdministration] CAUS [Observation]
Used to show that the source caused the target
observation (for instance, source "diabetes mellitus" is the
cause of target "kidney disease").
COMP (has component)
[Act | Observation | Procedure |
SubstanceAdministration | Supply] COMP [Act |
Observation | Procedure | SubstanceAdministration | Suppply]
Used to show that the target is a component of
the source (for instance "hemoglobin measurement" is a
component of a "complete blood count").
GEVL (evaluates (goal))
[Observation] GEVL
[Observation]
Used to link an observation (intent or actual)
to a goal to indicate that the observation evaluates the goal
(for instance, a source observation of "walking distance"
evaluates a target goal of "adequate walking distance").
MFST (is manifestation of)
[Observation] MFST
[Observation]
Used to say that the source is a manifestation
of the target (for instance, source "hives" is a manifestation
of target "penicillin allergy").
REFR (refers to)
[Act | Observation | Procedure |
SubstanceAdministration | Supply] REFR [Act |
Observation | ObservationMedia | Procedure | RegionOfInterest |
SubstanceAdministration | Supply]
Used to show a general relationship between
the source and the target, when the more specific semantics of
the relationship isn't known.
RSON (has reason)
[Act | Encounter | Observation | Procedure |
SubstanceAdministration | Supply] RSON [Act |
Encounter | Observation | Procedure | SubstanceAdministration |
Supply]
Used to show the reason or rational for a
service (for instance source "treadmill test" has reason "chest
pain").
SAS (starts after start)
[Act | Encounter | Observation | Procedure |
SubstanceAdministration | Supply] SAS [Act |
Encounter | Observation | Procedure | SubstanceAdministration |
Supply]
The source Act starts after the start of the
target Act (for instance source "diaphoresis" starts after the
start of target "chest pain").
SPRT (has support)
[Observation] SPRT
[Observation | ObservationMedia | RegionOfInterest]
Used to show that the target provides
supporting evidence for the source (for instance source
"possible lung tumor" has support target "mass seen on
chest-x-ray").
SUBJ (has subject)
[Observation | RegionOfInterest]
SUBJ [Observation | ObservationMedia]
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 target "chest pain").
The ActRelationshipType "has subject" is 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.
XCRPT (is excerpt of)
[Act | Observation] XCRPT
[Act | Observation | Procedure | SubstanceAdministration |
Supply]
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").
The distinction between an excerpt and an informant
participant can be blurry — such as in the case of
recording a patient's medication history where the clinician
may obtain the information from an informant or 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 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 Type
Reasonable Source and Target classes
Comments
ELNK (episode link)
[Observation] ELNK
[ExternalObservation]
Used to show that the source and the target
are part of the same episode (for instance, a diagnosis of
"pneumonia" can be linked to an external problem list entry of
"pneumonia" to show that the current diagnosis is part of the
ongoing episode of pneumonia).
REFR (refers to)
[Act | Observation | Procedure |
SubstanceAdministration | Supply] REFR
[ExternalAct | ExternalDocument | ExternalObservation |
ExternalProcedure]
Used to show a general relationship between
the source and the target, when the more specific semantics of
the relationship isn't known.
RPLC (replace)
[Act | Encounter | Observation |
ObservationMedia | Organizer | Procedure |
SubstanceAdministration | Supply] RPLC
[ExternalAct | ExternalDocument | ExternalObservation |
ExternalProcedure]
Used to indicate that the source entry is a
replacement for the target external act.
SPRT (has support)
[Observation] SPRT
[ExternalDocument | ExternalObservation]
Used to show that the target provides
supporting evidence for the source.
SUBJ (has subject)
[Observation | RegionOfInterest]
SUBJ [ExternalObservation]
Used to relate a source region of interest to
a target image, or to relate an observation to its subject
observation.
XCRPT (is excerpt of)
[Act | Observation] XCRPT
[ExternalAct | ExternalDocument | ExternalObservation |
ExternalProcedure]
Used to show that the source is excerpted from
the target (for instance "the hemoglobin is 10.7" is an excerpt
of an externally referenced "complete 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)
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
DOC (document) [default]
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 to
their paper world counter-parts. Documents typically are meant
to be human-readable. HL7's notion of document differs from
that described in the 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 subtype
See vocabulary domain "ActClassDocument" for
allowable values.
?
?
?
?
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) [default]
Observations are actions performed in order to
determine an answer or result value.
Any OBS subtype
See vocabulary domain "ActClassObservation"
for allowable 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 procedures.
?
?
Table 143: Value set for ExternalProcedure.classCode (CNE)
Code
Definition
PROC (procedure) [default]
An Act whose immediate and primary outcome
(post-condition) is the alteration of the physical condition of
the subject.
?
?
?
?
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
- 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
Participation.contextControlCode
1..1
Mandatory (NULL values not permitted)
"OP" (overriding, propagating)
ActRelationship.contextConductionInd
1..1
Mandatory (NULL values not permitted)
"true"*
?
?
* The one exception to this is
entryRelationship.contextConductionInd, which is defaulted to "true",
but can be changed to "false". See entryRelationship (? 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.
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
- 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 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
?
?
?
?
- 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.
- 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
?
?
?
A.3
Sample CDA Style Sheet
?
?
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.
?
?
?
B
Implementation Notes
?
B.1
Creating CDA Documents
?
?
Introduction
?
?
There are an ever-increasing variety of tools and
techniques for creating CDA documents:
?
?
- 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.
- 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.
- XML forms: a new generation of XML tools for forms generation can
create CDA on output.
- Knowledge base: at least one major US provider has built a CDA
editor on top of a knowledge base for guided, structured entry.
- 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 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 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
LOINC_NUM
COMPONENT (Type of Service)
SYSTEM (Setting)
METHOD_TYPE (Subject Matter Domain and/or
Training / Professional Level)
34862-3
ADMISSION EVALUATION NOTE
INPATIENT
ATTENDING PHYSICIAN.GENERAL MEDICINE
34744-3
ADMISSION EVALUATION NOTE
{SETTING}
NURSING
34873-0
ADMISSION EVALUATION NOTE
{SETTING}
SURGERY
34094-3
ADMISSION HISTORY AND PHYSICAL NOTE
HOSPITAL
CARDIOLOGY
34763-3
ADMISSION HISTORY AND PHYSICAL NOTE
{SETTING}
GENERAL MEDICINE
28615-3
AUDIOLOGY STUDY
{SETTING}
?
18743-5
AUTOPSY NOTE
{SETTING}
{PROVIDER}
33720-4
BLOOD BANK CONSULT
{SETTING}
?
34095-0
COMPREHENSIVE HISTORY & PHYSICAL NOTE
{SETTING}
{PROVIDER}
34096-8
COMPREHENSIVE HISTORY AND PHYSICAL
NURSING HOME
?
34098-4
CONFERENCE EVALUATION NOTE
{SETTING}
{PROVIDER}
34097-6
CONFERENCE EVALUATION NOTE
NURSING HOME
{PROVIDER}
24611-6
CONFIRMATORY CONSULTATION NOTE
OUTPATIENT
{PROVIDER}
34807-8
CONSULTATION NOTE
{SETTING}
OPHTHALMOLOGY
34100-8
CONSULTATION NOTE
CRITICAL CARE UNIT
{PROVIDER}
34810-2
CONSULTATION NOTE
{SETTING}
OPTOMETRY
34812-8
CONSULTATION NOTE
{SETTING}
OROMAXILLOFACIAL SURGERY
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
34822-7
CONSULTATION NOTE
{SETTING}
PHYSICAL MEDICINE AND 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
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
34869-8
COUNSELING NOTE
{SETTING}
PHARMACY
34864-9
COUNSELING NOTE
{SETTING}
MENTAL HEALTH
28622-9
DISCHARGE ASSESSMENT NOTE
{SETTING}
NURSING
28574-2
DISCHARGE NOTE
{SETTING}
{PROVIDER}
11490-0
DISCHARGE SUMMARIZATION NOTE
{SETTING}
PHYSICIAN
28655-9
DISCHARGE SUMMARIZATION NOTE
{SETTING}
ATTENDING PHYSICIAN
18842-5
DISCHARGE SUMMARIZATION NOTE
{SETTING}
{PROVIDER}
34105-7
DISCHARGE SUMMARIZATION NOTE
HOSPITAL
{PROVIDER}
29761-4
DISCHARGE SUMMARIZATION NOTE
{SETTING}
DENTISTRY
34745-0
DISCHARGE SUMMARIZATION NOTE
{SETTING}
NURSING
34106-5
DISCHARGE SUMMARIZATION NOTE
HOSPITAL
PHYSICIAN
34902-7
EDUCATION NOTE
OUTPATIENT
GERONTOLOGY
34897-9
EDUCATION NOTE
{SETTING}
DIABETOLOGY
34895-3
EDUCATION NOTE
{SETTING}
{PROVIDER}
34107-3
EDUCATION PROCEDURE NOTE
HOME HEALTH
{PROVIDER}
34108-1
EVALUATION AND MANAGEMENT
OUTPATIENT
{PROVIDER}
34836-7
EVALUATION AND MANAGEMENT NOTE
{SETTING}
REHABILITATION
34111-5
EVALUATION AND MANAGEMENT NOTE
EMERGENCY DEPARTMENT
{PROVIDER}
34834-2
EVALUATION AND MANAGEMENT NOTE
{SETTING}
RECREATIONAL THERAPY
34759-1
EVALUATION AND MANAGEMENT NOTE
{SETTING}
DERMATOLOGY
34842-5
EVALUATION AND MANAGEMENT NOTE
{SETTING}
SOCIAL WORK
34113-1
EVALUATION AND MANAGEMENT NOTE
NURSING HOME
{PROVIDER}
34762-5
EVALUATION AND MANAGEMENT NOTE
{SETTING}
GASTROENTEROLOGY
34840-9
EVALUATION AND MANAGEMENT NOTE
{SETTING}
RHEUMATOLOGY
34757-5
EVALUATION AND MANAGEMENT NOTE
{SETTING}
DENTISTRY
34112-3
EVALUATION AND MANAGEMENT NOTE
INPATIENT
{PROVIDER}
34746-8
EVALUATION AND MANAGEMENT NOTE
{SETTING}
NURSING
34754-2
EVALUATION AND MANAGEMENT NOTE
{SETTING}
CRITICAL CARE
34772-4
EVALUATION AND MANAGEMENT NOTE
{SETTING}
GENERAL SURGERY
34753-4
EVALUATION AND MANAGEMENT NOTE
OUTPATIENT
CARDIOLOGY
34752-6
EVALUATION AND MANAGEMENT NOTE
{SETTING}
CARDIOLOGY
34832-6
EVALUATION AND MANAGEMENT NOTE
{SETTING}
RADIATION ONCOLOGY
34750-0
EVALUATION AND MANAGEMENT NOTE
{SETTING}
ANESTHESIA
34773-2
EVALUATION AND MANAGEMENT NOTE
{SETTING}
ATTENDING PHYSICIAN.GENERAL SURGERY
34830-0
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PULMONARY
34778-1
EVALUATION AND MANAGEMENT NOTE
{SETTING}
GYNECOLOGY
34838-3
EVALUATION AND MANAGEMENT NOTE
{SETTING}
RESPIRATORY THERAPY
34780-7
EVALUATION AND MANAGEMENT NOTE
{SETTING}
HEMATOLOGY+ONCOLOGY
34109-9
EVALUATION AND MANAGEMENT NOTE
{SETTING}
{PROVIDER}
34854-0
EVALUATION AND MANAGEMENT NOTE
OUTPATIENT
VASCULAR SURGERY
34765-8
EVALUATION AND MANAGEMENT NOTE
{SETTING}
GENERAL MEDICINE
34819-3
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PATHOLOGY
34801-1
EVALUATION AND MANAGEMENT NOTE
{SETTING}
NUTRITION+DIETETICS
34823-5
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PHYSICAL MEDICINE AND REHABILITATION
34825-0
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PHYSICAL THERAPY
34827-6
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PLASTIC SURGERY
34829-2
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PODIATRY
34846-6
EVALUATION AND MANAGEMENT NOTE
{SETTING}
SPEECH THERAPY+AUDIOLOGY
34848-2
EVALUATION AND MANAGEMENT NOTE
{SETTING}
SURGERY
34815-1
EVALUATION AND MANAGEMENT NOTE
{SETTING}
ORTHOPEDICS
34852-4
EVALUATION AND MANAGEMENT NOTE
{SETTING}
UROLOGY
34817-7
EVALUATION AND MANAGEMENT NOTE
{SETTING}
OTORHINOLARYNGOLOGY
34856-5
EVALUATION AND MANAGEMENT NOTE
{SETTING}
ANTICOAGULATION
34857-3
EVALUATION AND MANAGEMENT NOTE
{SETTING}
SUBSTANCE ABUSE
34858-1
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PAIN MANAGEMENT
34859-9
EVALUATION AND MANAGEMENT NOTE
{SETTING}
HYPERLIPIDEMIA
34860-7
EVALUATION AND MANAGEMENT NOTE
{SETTING}
HYPERTENSION
34861-5
EVALUATION AND MANAGEMENT NOTE
{SETTING}
DIABETOLOGY
34878-9
EVALUATION AND MANAGEMENT NOTE
{SETTING}
EMERGENCY MEDICINE
34898-7
EVALUATION AND MANAGEMENT NOTE
{SETTING}
ENDOCRINOLOGY
34905-0
EVALUATION AND MANAGEMENT NOTE
{SETTING}
NEUROLOGY
34850-8
EVALUATION AND MANAGEMENT NOTE
OUTPATIENT
THORACIC SURGERY
34792-2
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PSYCHOLOGY
34766-6
EVALUATION AND MANAGEMENT NOTE
OUTPATIENT
GENERAL MEDICINE
34767-4
EVALUATION AND MANAGEMENT NOTE
{SETTING}
MEDICAL STUDENT.GENERAL MEDICINE
34768-2
EVALUATION AND MANAGEMENT NOTE
{SETTING}
NURSE.GENERAL MEDICINE
34769-0
EVALUATION AND MANAGEMENT NOTE
{SETTING}
ATTENDING PHYSICIAN.GENERAL MEDICINE
34782-3
EVALUATION AND MANAGEMENT NOTE
{SETTING}
INFECTIOUS DISEASE
34784-9
EVALUATION AND MANAGEMENT NOTE
{SETTING}
KINESIOTHERAPY
34786-4
EVALUATION AND MANAGEMENT NOTE
{SETTING}
MENTAL HEALTH
34821-9
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PHARMACY
34789-8
EVALUATION AND MANAGEMENT NOTE
{SETTING}
PSYCHIATRY
34813-6
EVALUATION AND MANAGEMENT NOTE
{SETTING}
OROMAXILLOFACIAL SURGERY
34802-9
EVALUATION AND MANAGEMENT NOTE
{SETTING}
OCCUPATIONAL HEALTH
34811-0
EVALUATION AND MANAGEMENT NOTE
{SETTING}
OPTOMETRY
34808-6
EVALUATION AND MANAGEMENT NOTE
{SETTING}
OPHTHALMOLOGY
34806-0
EVALUATION AND MANAGEMENT NOTE
{SETTING}
ONCOLOGY
34804-5
EVALUATION AND MANAGEMENT NOTE
{SETTING}
OCCUPATIONAL THERAPY
34794-8
EVALUATION AND MANAGEMENT NOTE
{SETTING}
MULTIDISCIPLINARY
34110-7
EVALUATION AND MANAGEMENT NOTE
OUTPATIENT
DIABETOLOGY
34799-7
EVALUATION AND MANAGEMENT NOTE
{SETTING}
NEUROSURGERY
34796-3
EVALUATION AND MANAGEMENT NOTE
{SETTING}
NEPHROLOGY
34787-2
GROUP COUNSELING NOTE
{SETTING}
MENTAL HEALTH
34790-6
GROUP COUNSELING NOTE
{SETTING}
PSYCHIATRY
34843-3
GROUP COUNSELING NOTE
{SETTING}
SOCIAL WORK
34114-9
GROUP COUNSELING NOTE
HOSPITAL
{PROVIDER}
34793-0
GROUP COUNSELING NOTE
{SETTING}
PSYCHOLOGY
34774-0
HISTORY & PHYSICAL NOTE
{SETTING}
GENERAL SURGERY
28626-0
HISTORY & PHYSICAL NOTE
{SETTING}
PHYSICIAN
11492-6
HISTORY & PHYSICAL NOTE
HOSPITAL
{PROVIDER}
34116-4
HISTORY & PHYSICAL NOTE
NURSING HOME
PHYSICIAN
34115-6
HISTORY & PHYSICAL NOTE
HOSPITAL
MEDICAL STUDENT
34117-2
HISTORY AND PHYSICAL NOTE
{SETTING}
{PROVIDER}
18841-7
HOSPITAL CONSULTATIONS
{SETTING}
?
28572-6
INITIAL EVALUATION NOTE
{SETTING}
DENTISTRY
28654-2
INITIAL EVALUATION NOTE
{SETTING}
ATTENDING PHYSICIAN
18735-1
INITIAL EVALUATION NOTE
{SETTING}
PHYSICAL THERAPY
18736-9
INITIAL EVALUATION NOTE
{SETTING}
PHYSICIAN
18737-7
INITIAL EVALUATION NOTE
{SETTING}
PODIATRY
18738-5
INITIAL EVALUATION NOTE
{SETTING}
PSYCHOLOGY
18739-3
INITIAL EVALUATION NOTE
{SETTING}
SOCIAL SERVICE
18734-4
INITIAL EVALUATION NOTE
{SETTING}
OCCUPATIONAL THERAPY
28581-7
INITIAL EVALUATION NOTE
{SETTING}
CHIROPRACTOR
29753-1
INITIAL EVALUATION NOTE
{SETTING}
NURSING
28636-9
INITIAL EVALUATION NOTE
{SETTING}
{PROVIDER}
28635-1
INITIAL EVALUATION NOTE
{SETTING}
PSYCHIATRY
28621-1
INITIAL EVALUATION NOTE
{SETTING}
NURSE PRACTITIONER
18763-3
INITIAL EVALUATION NOTE
{SETTING}
CONSULTING PHYSICIAN
18740-1
INITIAL EVALUATION NOTE
{SETTING}
SPEECH THERAPY
34120-6
INITIAL EVALUATION NOTE
OUTPATIENT
{PROVIDER}
34119-8
INITIAL EVALUATION NOTE
NURSING HOME
{PROVIDER}
34118-0
INITIAL EVALUATION NOTE
HOME HEALTH
{PROVIDER}
34121-4
INTERVENTIONAL PROCEDURE NOTE
{SETTING}
?
34896-1
INTERVENTIONAL PROCEDURE NOTE
{SETTING}
CARDIOLOGY
34899-5
INTERVENTIONAL PROCEDURE NOTE
{SETTING}
GASTROENTEROLOGY
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
34122-2
PATHOLOGY PROCEDURE NOTE
{SETTING}
PATHOLOGY
34880-5
POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
NURSE.SURGERY
34875-5
POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
SURGERY
34863-1
POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
GENERAL SURGERY
34867-2
POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE
OUTPATIENT
OPHTHALMOLOGY
34881-3
PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
NURSE.SURGERY
34123-0
PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE
HOSPITAL
ANESTHESIA
34775-7
PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
GENERAL SURGERY
34876-3
PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
SURGERY
34751-8
PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
ANESTHESIA
34809-4
PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
OPHTHALMOLOGY
34747-6
PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE
{SETTING}
NURSING
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
18744-3
STUDY REPORT
RESPIRATORY SYSTEM
BRONCHOSCOPY
11510-5
SUBSEQUENT EVALUATION NOTE
{SETTING}
PSYCHOLOGY
11508-9
SUBSEQUENT EVALUATION NOTE
{SETTING}
PHYSICAL THERAPY
11509-7
SUBSEQUENT EVALUATION NOTE
{SETTING}
PODIATRY
11506-3
SUBSEQUENT EVALUATION NOTE
{SETTING}
{PROVIDER}
11507-1
SUBSEQUENT EVALUATION NOTE
{SETTING}
OCCUPATIONAL THERAPY
11512-1
SUBSEQUENT EVALUATION NOTE
{SETTING}
SPEECH THERAPY
15507-7
SUBSEQUENT EVALUATION NOTE
EMERGENCY DEPARTMENT
{PROVIDER}
18733-6
SUBSEQUENT EVALUATION NOTE
{SETTING}
ATTENDING PHYSICIAN
34904-3
SUBSEQUENT EVALUATION NOTE
{SETTING}
MENTAL HEALTH
34901-9
SUBSEQUENT EVALUATION NOTE
OUTPATIENT
GENERAL MEDICINE
18764-1
SUBSEQUENT EVALUATION NOTE
{SETTING}
NURSE PRACTITIONER
34129-7
SUBSEQUENT EVALUATION NOTE
HOME HEALTH
{PROVIDER}
34132-1
SUBSEQUENT EVALUATION NOTE
OUTPATIENT
PHARMACY
34131-3
SUBSEQUENT EVALUATION NOTE
OUTPATIENT
{PROVIDER}
28656-7
SUBSEQUENT EVALUATION NOTE
{SETTING}
SOCIAL SERVICE
34130-5
SUBSEQUENT EVALUATION NOTE
HOSPITAL
{PROVIDER}
28617-9
SUBSEQUENT EVALUATION NOTE
{SETTING}
DENTISTRY
34128-9
SUBSEQUENT EVALUATION NOTE
OUTPATIENT
DENTISTRY
34127-1
SUBSEQUENT EVALUATION NOTE
OUTPATIENT
DENTAL HYGIENIST
34126-3
SUBSEQUENT EVALUATION NOTE
CRITICAL CARE UNIT
{PROVIDER}
34900-1
SUBSEQUENT EVALUATION NOTE
{SETTING}
GENERAL MEDICINE
34125-5
SUBSEQUENT EVALUATION NOTE
HOME HEALTH CARE
CASE MANAGER
28569-2
SUBSEQUENT EVALUATION NOTE
{SETTING}
CONSULTING PHYSICIAN
18762-5
SUBSEQUENT EVALUATION NOTE
{SETTING}
CHIROPRACTOR
34124-8
SUBSEQUENT EVALUATION NOTE
OUTPATIENT
CARDIOLOGY
28627-8
SUBSEQUENT EVALUATION NOTE
{SETTING}
PSYCHIATRY
28623-7
SUBSEQUENT EVALUATION NOTE
{SETTING}
NURSING
34133-9
SUMMARIZATION OF EPISODE NOTE
{SETTING}
{PROVIDER}
34134-7
SUPERVISORY NOTE
OUTPATIENT
ATTENDING PHYSICIAN
34135-4
SUPERVISORY NOTE
OUTPATIENT
ATTENDING PHYSICIAN.CARDIOLOGY
34136-2
SUPERVISORY NOTE
OUTPATIENT
ATTENDING PHYSICIAN.GASTROENTEROLOGY
28624-5
SURGICAL OPERATION NOTE
{SETTING}
PODIATRY
28573-4
SURGICAL OPERATION NOTE
{SETTING}
PHYSICIAN
11504-8
SURGICAL OPERATION NOTE
{SETTING}
{PROVIDER}
28583-3
SURGICAL OPERATION NOTE
{SETTING}
DENTISTRY
34137-0
SURGICAL OPERATION NOTE
OUTPATIENT
{PROVIDER}
34138-8
TARGETED HISTORY AND PHYSICAL NOTE
{SETTING}
{PROVIDER}
34139-6
TELEPHONE ENCOUNTER NOTE
{SETTING}
NURSING
34844-1
TELEPHONE ENCOUNTER NOTE
OUTPATIENT
SOCIAL WORK
34748-4
TELEPHONE ENCOUNTER NOTE
{SETTING}
{PROVIDER}
34140-4
TRANSFER OF CARE REFERRAL NOTE
{SETTING}
{PROVIDER}
34770-8
TRANSFER SUMMARIZATION NOTE
{SETTING}
GENERAL MEDICINE
18761-7
TRANSFER SUMMARIZATION NOTE
{SETTING}
{PROVIDER}
28651-8
TRANSFER SUMMARIZATION NOTE
{SETTING}
NURSING
28616-1
TRANSFER SUMMARIZATION NOTE
{SETTING}
PHYSICIAN
34755-9
TRANSFER SUMMARIZATION NOTE
{SETTING}
CRITICAL CARE
28568-4
VISIT NOTE
EMERGENCY DEPARTMENT
PHYSICIAN
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 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
CDA R1 vocabulary
Corresponding CDA R2 vocabulary
Comments
clinical_document_header / document_type_cd
<= DocumentType (2.16.840.1.113883.6.1.10870) (CWE)
ClinicalDocument / code <= DocumentType
(2.16.840.1.113883.6.1) (CWE)
?
clinical_document_header / confidentiality_cd
<= ServiceConfidentiality (2.16.840.1.113883.5.10228) (CWE)
ClinicalDocument / confidentialityCode <=
x_BasicConfidentialityKind (2.16.840.1.113883.5.25) (CWE)
- Removed "C", "D", "I", "S", "T" from value set.
- Added "V" to value set.
clinical_document_header /
document_relationship / document_relationship.type_cd <=
ServiceRelationship (2.16.840.1.113883.5.10317) (CNE)
ClinicalDocument / relatedDocument / @typeCode
<= x_ActRelationshipDocument (2.16.840.1.113883.5.1002)
(CNE)
- Added "XFRM" to value set.
clinical_document_header / fulfills_order /
fulfills_order.type_cd <= ServiceRelationship
(2.16.840.1.113883.5.10317) (CNE)
ClinicalDocument / inFulfillmentOf / @typeCode
<= FLFS (2.16.840.1.113883.5.1002) (CNE)
- No change in value set.
clinical_document_header / patient_encounter /
practice_setting_cd <= PracticeSetting
(2.16.840.1.113883.5.10588) (CWE)
ClinicalDocument / componentOf /
encompassingEncounter / location / healthCareFacility / code
<= ServiceDeliveryLocationRoleType (2.16.840.1.113883.5.111)
(CWE)
?
clinical_document_header / authenticator /
authenticator.type_cd <= ServiceActor
(2.16.840.1.113883.5.10246) (CNE)
ClinicalDocument / authenticator / @typeCode
<= AUTHEN (2.16.840.1.113883.5.90) (CNE)
- Fixed value changed from "VRF" to "AUTHEN".
clinical_document_header / authenticator /
signature_cd <= ServiceActorSignature
(2.16.840.1.113883.5.10282) (CNE)
ClinicalDocument / authenticator /
signatureCode <= ParticipationSignature
(2.16.840.1.113883.5.89) (CNE)
- Value of "X" has been deprecated.
clinical_document_header / authenticator /
person / person_name / person_name.type_cd <=
PersonNamePurpose (2.16.840.1.113883.5.200) (CWE)
ClinicalDocument / authenticator /
assignedEntity / assignedPerson / name / @use <=
PersonNameUse (2.16.840.1.113883.5.45) (CNE)
- Vocabulary domain has changed from CWE to CNE. The CDA R2
value set includes enumerated CDA R1 values ("A", "C", "I",
"L", "R"). CDA R1 to CDA R2 translations may require local
markup where the CDA R1 value set was extended.
clinical_document_header / legal_authenticator
/ authenticator.type_cd <= ServiceActor
(2.16.840.1.113883.5.10246) (CNE)
ClinicalDocument / legalAuthenticator /
@typeCode <= LA (2.16.840.1.113883.5.90) (CNE)
- Fixed value changed from "SPV" to "AUTHEN".
clinical_document_header / legal_authenticator
/ signature_cd <= ServiceActorSignature
(2.16.840.1.113883.5.10282) (CNE)
ClinicalDocument / legalAuthenticator /
signatureCode <= ParticipationSignature
(2.16.840.1.113883.5.89) (CNE)
- Value of "X" has been deprecated.
clinical_document_header / intended_recipient
/ intended_recipient.type_cd <= ServiceActor
(2.16.840.1.113883.5.10246) (CNE)
ClinicalDocument / intendedRecipient /
@typeCode <= x_InformationRecipient (2.16.840.1.113883.5.90)
(CNE)
- Added "PRCP" to value set.
clinical_document_header / originator /
originator.type_cd <= ServiceActor
(2.16.840.1.113883.5.10246) (CNE)
ClinicalDocument / author / @typeCode <=
AUT (2.16.840.1.113883.5.90) (CNE)
- No change to value set.
clinical_document_header /
originating_organization / originating_organization.type_cd
<= ServiceActor (2.16.840.1.113883.5.10246) (CNE)
ClinicalDocument / custodian / @typeCode <=
CST (2.16.840.1.113883.5.90) (CNE)
- No change to value set.
clinical_document_header / transcriptionist /
transcriptionist.type_cd <= ServiceActor
(2.16.840.1.113883.5.10246) (CNE)
ClinicalDocument / dataEnterer / @typeCode
<= ENT (2.16.840.1.113883.5.90) (CNE)
- No change to value set.
clinical_document_header / provider /
provider.type_cd <= ServiceActor (2.16.840.1.113883.5.10246)
(CNE) (Value set "ASS", "CON", "PRF")
ClinicalDocument / serviceEvent / performer /
@typeCode <= x_ServiceEventPerformer
(2.16.840.1.113883.5.90) (CNE) (Value set "PRF", "PPRF",
"SPRF")
ClinicalDocument / encompassingEncounter / responsibleParty
/ @typeCode <= RESP (2.16.840.1.113883.5.90) (CNE)
ClinicalDocument / encompassingEncounter /
encounterParticipant / @typeCode <= x_EncounterParticipant
(2.16.840.1.113883.5.90) (CNE) (Value set "ADM", "ATND", "CON"
, "DIS" , "REF")
- CDA R1 provider has been split into three distinct
participants. Local use of CDA R1 can be used to determine
the exact correspondence.
- CDA R1 value "ASS" correlates with CDA R2 value
"SPRF".
clinical_document_header / provider /
function_cd <= ServiceActorFunction
(2.16.840.1.113883.5.10267) (CWE)
ClinicalDocument / serviceEvent / performer /
functionCode <= ParticipationFunction
(2.16.840.1.113883.5.88) (CWE)
?
clinical_document_header / service_actor /
service_actor.type_cd <= ServiceActor
(2.16.840.1.113883.5.10246) (CWE)
ClinicalDocument / participant / @typeCode
<= ParticipationType (2.16.840.1.113883.5.90) (CNE)
- Vocabulary domain has changed from CWE to CNE. CDA R1 to
CDA R2 translations may require local markup where the CDA
R1 value set was extended.
clinical_document_header / service_actor /
signature_cd <= ServiceActorSignature
(2.16.840.1.113883.5.10282) (CNE)
ClinicalDocument / authenticator /
signatureCode <= ParticipationSignature
(2.16.840.1.113883.5.89) (CNE)
- Value of "X" has been deprecated.
clinical_document_header / patient /
administrative_gender_cd <= AdministrativeGender
(2.16.840.1.113883.5.1) (CWE)
ClinicalDocument / recordTarget / patientRole
/ patient / administrativeGenderCode <= AdministrativeGender
(2.16.840.1.113883.5.1) (CWE)
?
clinical_document_header / originating_device
/ originating_device.type_cd <= ServiceTargetType
(2.16.840.1.113883.5.10285) (CNE)
ClinicalDocument / author / @typeCode <=
AUT (2.16.840.1.113883.5.90) (CNE)
- CDA R1 "ODV" maps to CDA R2 "AUT".
clinical_document_header / originating_device
/ device / responsibility / responsibility.type_cd <=
MaterialResponsibility (2.16.840.1.113883.5.10416) (CWE)
ClinicalDocument / author / assignedAuthor /
assignedAuthoringDevice / asMaintainedEntity / @classCode <=
MNT (2.16.840.1.113883.5.110) (CNE)
- Vocabulary domain has changed from CWE to CNE. The CDA R2
value set includes enumerated CDA R1 values ("MNT"). CDA R1
to CDA R2 translations may require local markup where the
CDA R1 value set was extended.
clinical_document_header / service_target /
service_target.type_cd <= ServiceTargetType
(2.16.840.1.113883.5.10285) (CWE)
ClinicalDocument / participant / @typeCode
<= ParticipationType (2.16.840.1.113883.5.90) (CNE)
- Vocabulary domain has changed from CWE to CNE. CDA R1 to
CDA R2 translations may require local markup where the CDA
R1 value set was extended.
section / caption / caption_cd (CWE)
section / code <= DocumentSectionType
(2.16.840.1.113883.6.1) (CWE)
- See also caption/caption_cd in the next row. The caption
of a section corresponds to CDA R2 differently than other
captions.
caption / caption_cd (CWE)
@styleCode <= StyleType
(2.16.840.1.113883.19.5.1) (CWE)
- See also section/caption/caption_cd in the row above. The
caption of a section corresponds to CDA R2 differently than
other captions.
?
?
?
?
Table 149: CDA R1 to CDA R2 Header Correspondence
CDA R1 component
Corresponding CDA R2 component
Comments
levelone
ClinicalDocument
?
levelone / clinical_document_header
NOT PRESENT
- Wrapping header tag no longer present.
clinical_document_header / id
ClinicalDocument / id
?
clinical_document_header / set_id
ClinicalDocument / setId
?
clinical_document_header / version_nbr
ClinicalDocument / versionNumber
?
clinical_document_header / document_type_cd
ClinicalDocument / code
?
clinical_document_header / service_tmr
ClinicalDocument / documentationOf /
serviceEvent / effectiveTime
- The GTS data type in CDA R1 has been constrained to a
time interval in CDA R2. Local markup can be used where it
is necessary to convey additional complexity.
clinical_document_header / origination_dttm
ClinicalDocument / effectiveTime
?
clinical_document_header / copy_dttm
ClinicalDocument / copyTime
?
clinical_document_header /
confidentiality_cd
ClinicalDocument / confidentialityCode
- Cardinality changed from [0..*] to [0..1]. CDA R1
expressed all confidentiality flags in the header, which
were then referenced from within the body. CDA R2 expresses
confidentiality in the header, and allows it to be
overridden in the body.
clinical_document_header /
document_relationship
ClinicalDocument / relatedDocument
?
document_relationship /
document_relationship.type_cd
relatedDocument / @typeCode
?
document_relationship / related_document
relatedDocument / parentDocument
?
document_relationship / related_document /
id
relatedDocument / parentDocument / id
?
document_relationship / related_document /
set_id
relatedDocument / parentDocument / setId
?
document_relationship / related_document /
version_nbr
relatedDocument / parentDocument /
versionNumber
?
clinical_document_header / fulfills_order
ClinicalDocument / inFulfillmentOf
?
fulfills_order / fulfills_order.type_cd
inFulfillmentOf / @typeCode
?
fulfills_order / order
inFulfillmentOf / order
?
fulfills_order / order / id
inFulfillmentOf / order / id
?
clinical_document_header /
patient_encounter
ClinicalDocument / componentOf /
encompassingEncounter
?
patient_encounter / id
encompassingEncounter / id
?
patient_encounter / practice_setting_cd
encompassingEncounter / location /
healthCareFacility / code
?
patient_encounter / encounter_tmr
encompassingEncounter / effectiveTime
?
patient_encounter / service_location
encompassingEncounter / location /
healthCareFacility
?
patient_encounter / service_location / id
encompassingEncounter / location /
healthCareFacility / id
?
patient_encounter / service_location / addr
encompassingEncounter / location /
healthCareFacility / location / addr
?
clinical_document_header / authenticator
ClinicalDocument / authenticator
- The time interval data type in CDA R1 has been
constrained to a point in time in CDA R2. Local markup can
be used where it is necessary to convey additional
complexity.
authenticator / authenticator.type_cd
authenticator / @typeCode
?
authenticator / participation_tmr
authenticator / time
?
authenticator / signature_cd
authenticator / signatureCode
- CDA R1 represented either an intended (signature code
"X") or actual (signature code "S") authenticator. CDA R2
only represents an actual authenticator, so has deprecated
the value of "X".
authenticator / person
authenticator / assignedEntity /
assignedPerson
?
authenticator / person / id
authenticator / assignedEntity / id
?
authenticator / person / person_name
authenticator / assignedEntity /
assignedPerson / name
?
authenticator / person / person_name /
effective_tmr
authenticator / assignedEntity /
assignedPerson / name / validTime
?
authenticator / person / person_name / nm
authenticator / assignedEntity /
assignedPerson / name
?
authenticator / person / person_name /
person_name.type_cd
authenticator / assignedEntity /
assignedPerson / name / @use
?
authenticator / person / addr
authenticator / assignedEntity / addr /
?
authenticator / person / telecom
authenticator / assignedEntity / telecom
?
clinical_document_header /
legal_authenticator
ClinicalDocument / legalAuthenticator
?
legal_authenticator /
legal_authenticator.type_cd
legalAuthenticator / @typeCode
?
legal_authenticator / participation_tmr
legalAuthenticator / time
- The time interval data type in CDA R1 has been
constrained to a point in time in CDA R2. Local markup can
be used where it is necessary to convey additional
complexity.
legal_authenticator / signature_cd
legalAuthenticator / signatureCode
- CDA R1 represented either an intended (signature code
"X") or actual (signature code "S") legal authenticator.
CDA R2 only represents an actual legal authenticator, so
has deprecated the value of "X".
legal_authenticator / person
legalAuthenticator / assignedEntity /
assignedPerson
?
clinical_document_header / intended_recipient
ClinicalDocument / intendedRecipient
?
intended_recipient /
intended_recipient.type_cd
intendedRecipient / @typeCode
?
clinical_document_header / originator
ClinicalDocument / author
?
originator / originator.type_cd
author / @typeCode
?
originator / participation_tmr
author / time
- The time interval data type in CDA R1 has been
constrained to a point in time in CDA R2. Local markup can
be used where it is necessary to convey additional
complexity.
clinical_document_header /
originating_organization
ClinicalDocument / author
ClinicalDocument / custodian
- The CDA R1 originating_organization corresponds to the
scoper of the author AND the custodian organization,
because it served both purposes in R1.
originating_organization /
originating_organization.type_cd
custodian / @typeCode
?
originating_organization / organization
author / assignedAuthor /
representedOrganization
custodian / assignedCustodian /
representedCustodianOrganization
?
originating_organization / organization /
id
author / assignedAuthor /
representedOrganization / id
custodian / assignedCustodian /
representedCustodianOrganization / id
?
originating_organization / organization /
organization.nm
author / assignedAuthor /
representedOrganization / name
custodian / assignedCustodian /
representedCustodianOrganization / name
?
originating_organization / organization /
addr
author / assignedAuthor /
representedOrganization / addr
custodian / assignedCustodian /
representedCustodianOrganization / addr
?
clinical_document_header / transcriptionist
ClinicalDocument / dataEnterer
?
transcriptionist / transcriptionist.type_cd
dataEnterer / @typeCode
?
transcriptionist / participation_tmr
dataEnterer / time
- The time interval data type in CDA R1 has been
constrained to a point in time in CDA R2. Local markup can
be used where it is necessary to convey additional
complexity.
clinical_document_header / provider
ClinicalDocument / serviceEvent / performer
ClinicalDocument / encompassingEncounter /
responsibleParty
ClinicalDocument / encompassingEncounter /
encounterParticipant
- CDA R1 provider has been split into three distinct
participants. Local use of CDA R1 can be used to determine
the exact correspondence.
clinical_document_header / service_actor
ClinicalDocument / participant
- Alternatively, could correspond to one of the new more
specific participants (e.g. informant, performer,
responsibleParty, encounterParticipant) depending on local
use.
service_actor / service_actor.type_cd
participant / @typeCode
?
service_actor / participation_tmr
participant / time
?
service_actor / signature_cd
authenticator / signatureCode
- Local use of CDA R1 can determine whether service actor
signatures can be reflected as additional CDA R2
authenticators.
clinical_document_header / patient
ClinicalDocument / recordTarget
?
patient / patient.type_cd
recordTarget / @typeCode
?
patient / participation_tmr
NOT PRESENT
- Local markup can be used to accommodate mapping if
necessary.
patient / person
recordTarget / patientRole / patient
?
patient / person / id
recordTarget / patientRole / patient / id
?
patient / is_known_by
recordTarget / patientRole
?
patient / is_known_by / id
recordTarget / patientRole / id
?
patient / is_known_by / is_known_to
recordTarget / patientRole /
providerOrganization
- 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 listed
multiple organizations, the one that is also the custodian
organization corresponds to providerOrganization. Other
values can be modeled using local markup.
patient / is_known_by / is_known_to / id
recordTarget / patientRole /
providerOrganization / id
?
patient / birth_dttm
recordTarget / patientRole / patient /
birthTime
?
patient / administrative_gender_cd
recordTarget / patientRole / patient /
administrativeGenderCode
?
clinical_document_header /
originating_device
ClinicalDocument / author
?
originating_device /
originating_device.type_cd
author / @typeCode
?
originating_device / participation_tmr
author / time
- The time interval data type in CDA R1 has been
constrained to a point in time in CDA R2. 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
?
originating_device / device /
responsibility
author / assignedAuthor /
assignedAuthoringDevice / asMaintainedEntity
?
originating_device / device / responsibility /
responsibility.type_cd
author / assignedAuthor /
assignedAuthoringDevice / asMaintainedEntity / @classCode
?
originating_device / device / responsibility /
responsibility_tmr
author / assignedAuthor /
assignedAuthoringDevice / asMaintainedEntity / effectiveTime
?
clinical_document_header / service_target
ClinicalDocument / participant
- Alternatively, could correspond to one of the new more
specific participants (e.g. informant, performer,
responsibleParty, encounterParticipant) depending on local
use.
service_target / service_target.type_cd
participant / @typeCode
?
service_target / participation_tmr
participant / time
?
?
?
?
?
Table 150: CDA R1 to CDA R2 Body Correspondence
CDA R1 component
Corresponding CDA R2 component
Comments
levelone / body / non_xml
ClinicalDocument / component / nonXMLBody
?
levelone / body / section
ClinicalDocument / component / structuredBody
/ section
?
section / @originator
section / author
- In CDA R1, all authors are listed in the header, and then
referenced from the body. In CDA R2, authors listed in the
header propagate to the body where they can be overridden
(as described in "CDA Context").
section / @confidentiality
section / confidentialityCode
- In CDA R1, all confidentiality values are listed in the
header, and then referenced from the body. In CDA R2,
confidentiality listed in the header propagates to the body
where it can be overridden (as described in "CDA Context").
section / @xml:lang
section / languageCode
?
section / caption
section / title
?
section / caption / link
NOT PRESENT
- Local use can determine whether to map to linkHtml in the
narrative block of CDA R2.
section / caption / caption_cd
section / code
- See also caption/caption_cd in the row below. The caption
of a section corresponds to CDA R2 differently than other
captions.
@originator
SEE COMMENTS
- In CDA R2, section authorship applies to the narrative
block. Nested entries with an associated author participant
can reference into the narrative block where it is
necessary to ascribe authorship to a particular statement.
@confidentiality
NOT PRESENT
- Confidentiality cannot be ascribed below the section
level.
@xml:lang
@language
- The language attribute functions as it did in CDA R1.
content
content
?
link
linkHtml
- The CDA R1 link tag no longer exists. It had a required
child element, link_html, which corresponds to CDA R2
linkHtml.
coded_entry
section / entry / act
?
coded_entry / coded_entry.id
section / entry / act / id
?
coded_entry / coded_entry.value
section / entry / act / code
?
observation_media
section / entry / observationMedia
- Use the renderMultiMedia tag in the narrative block to
reference an observationMedia entry.
observation_media / observation_media.id
section / entry / observationMedia / id
observation_media / observation_media.value
section / entry / observationMedia / value
local_markup
SEE COMMENTS
- Local markup is precluded from use in the CDA R2
narrative block particularly if they would interfere with
the ability of those not 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
?
caption / caption_cd
@styleCode
- See also section/caption/caption_cd in the row above. The
caption of a section corresponds to CDA R2 differently than
other captions.
paragraph
paragraph
?
list
list
?
table
table
- CDA R2 table content model no longer contains a "tr"
element. This element is now wrapped in a "tbody"
element.
?
?