0920-0234 EHR Implementation Guide

Attachment H- EHR Implementation Guide

CDAR2_IG_NHCS_R1_DSTU1.2_2016AUG_Vol1

HL7 CDA® R2 Implementation Guide:
National Health Care Surveys Release 1,
DSTU Release 1.2 –
US Realm
HL7 Draft Standard for Trial Use (DSTU)
August 2016
Volume 1 — Introductory Material
Sponsored by:
Public Health and Emergency Response Work Group
Structured Documents Work Group
Publication of this draft standard for trial use and comment has been approved by Health Level Seven
International (HL7). This draft standard is not an accredited American National Standard. The comment
period for use of this draft standard shall end 12 months from the date of publication. Suggestions for
revision should be submitted at http://www.hl7.org/dstucomments/index.cfm.
Following this 12 month evaluation period, this draft standard, revised as necessary, will be submitted to
a normative ballot in preparation for approval by ANSI as an American National Standard.
Implementations of this draft standard shall be viable throughout the normative ballot process and for up
to six months after publication of the relevant normative standard.
Copyright © 2016 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this
material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health
Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of this material is governed by HL7's IP Compliance Policy

IMPORTANT NOTES:
HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this
document, you are not authorized to access or make any use of it. To obtain a free license, please visit
http://www.HL7.org/implement/standards/index.cfm.
If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed
work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material.
A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms
of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell
products and services that implement, but do not directly incorporate, the Specified Material in whole or in part
without paying license fees to HL7.
INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of
Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7
ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.
B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without
additional charge, on a perpetual (except as provided for in the full license terms governing the Material), nonexclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material
with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing,
making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise
distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant
patent and other intellectual property rights of third parties (which may include members of HL7). No other license,
sublicense, or other rights of any kind are granted under this Agreement.
C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized,
without additional charge, to read and use the Specified Material for evaluating whether to implement, or in
implementing, the Specified Material, and to use Specified Material to develop and sell products and services that
implement, but do not directly incorporate, the Specified Material in whole or in part.
NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and
services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above,
must become ORGANIZATIONAL MEMBERS of HL7.
Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the
Trademark. Licensee shall take no action contrary to, or inconsistent with, the foregoing.
Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the
Materials and that the Materials may contain and/or reference intellectual property owned by third parties
(“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to
Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or
authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or
suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the
Licensee’s liability.
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
Terminology
Owner/Contact
Current Procedures Terminology (CPT)
American Medical Association
code set
http://www.ama-assn.org/ama/pub/physician-resources/solutionsmanaging-your-practice/coding-billing-insurance/cpt/cpt-productsservices/licensing.page?
SNOMED CT
International Healthcare Terminology Standards Developing
Organization (IHTSDO) http://www.ihtsdo.org/snomed-ct/getsnomed-ct or info@ihtsdo.org
Logical Observation Identifiers Names &
Regenstrief Institute
Codes (LOINC)
International Classification of Diseases
World Health Organization (WHO)
(ICD) codes
NUCC Health Care Provider Taxonomy
American Medical Association. Please see 222.nucc.org. AMA
code set
licensing contact: 312-464-5022 (AMA IP services)

Structure of This Guide
Two volumes comprise this HL7 CDA® R2 Implementation Guide: National Health Care
Surveys Release 1, DSTU Release 1.2 - US Realm. Volume 1 provides narrative
introductory and background material pertinent to this implementation guide, including
information on how to understand and use the templates in Volume 2. Volume 2
contains the Clinical Document Architecture (CDA) templates for this guide along with
lists of templates, code systems, and value sets used.

Primary
Editor:

Sarah Gaunt
Lantana Consulting Group
sarah.gaunt@lantanagroup.com

CoEditor:

Michelle Williamson, MS, RN
CDC/NCHS
zup9@cdc.gov

PHER WG
Co-Chair:

Joginder Madra
Gordon Point Informatics Ltd.
joginder.madra@gpinformatics.com

CoEditor:

Brian Gugerty, DNS, RN
CDC/NCHS
vaz6@cdc.gov

PHER WG
Co-Chair:

Erin Holt Coyne, MPH
Tennessee Department of Health
kpool@oz-systems.com

CoEditor:

Kristi Eckerson, MSPH
Emory University IPA to CDC/NCHS
kee8@cdc.gov

PHER WG
Co-Chair:

John Roberts
Tennessee Department of Health
john.a.roberts@tn.gov

CoEditor:

Hetty Khan, MGA, MS, RN
CDC/NCHS
hdk1@cdc.gov

PHER WG
Co-Chair:

Rob Savage, MS
Rob Savage Consulting
robsavage@att.net

CoEditor:

Ryan Murphy
Lantana Consulting Group
ryan.murphy@lantanagroup.com

SDWG CoChair:

Calvin Beebe
Mayo Clinic
cbeebe@mayo.edu

CoEditor:

Tammara Jean Paul, PhD
CDC/NCHS
wro9@cdc.gov

SDWG CoChair:

Rick Geimer
Lantana Consulting Group
rick.geimer@lantanagroup.com

CoEditor:

Sabrina Ridley
Global Evaluation & Applied Research
Solutions
sridley@getingears.com

SDWG CoChair:

Austin Kreisler
SAIC Consultant to CDC/NHSN
duz1@cdc.gov

CoEditor:

Clarice Brown
CDC/NCHS
crb6@cdc.gov

CoEditor/SD
WG CoChair:

Gaye Dolin, MSN, RN
Intelligent Medical Objects, Inc.
gdolin@imo-online.com

CoEditor:

Arsed Joseph
Global Evaluation & Applied Research
Solutions
ajoseph@getingears.com

SDWG CoChair:

Brett Marquard
River Rock Associates
brett@riverrockassociates.com

Technical
Editor:

Diana Wright
Lantana Consulting Group
diana.wright@lantanagroup.com

Co-Editor

Ryan Murphy
Lantana Consulting Group
ryan.murphy@lantanagroup.com

Acknowledgments
This guide was developed and produced under the guidance of the Centers for Disease
Control and Prevention/National Center for Health Statistics (CDC/NCHS) through the
collaboration of the Division of Health Care Statistics (DHCS) and the Classifications
and Public Health Data Standards Staff (CPHDSS).
The editors appreciate the support and sponsorship of the Health Level Seven (HL7)
Structured Documents Working Group (SDWG) and the HL7 Public Health and
Emergency Response Work Group (PHER WG).
This material contains content from SNOMED CT® (http://www.ihtsdo.org/snomedct/). SNOMED CT is a registered trademark of the International Health Terminology
Standard Development Organisation (IHTSDO).
This material contains content from LOINC® (http://loinc.org). The LOINC table, LOINC
codes, and LOINC panels and forms file are copyright © 1995-2016, Regenstrief
Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC)
Committee and available at no cost under the license at http://loinc.org/terms-of-use.

Contents
1

INTRODUCTION .............................................................................................................. 9
1.1

Note to Update Readers—Items for Comment .......................................................... 9

Clinical Note and External Document Reference ............................................................... 9
Chief Complaint and Reason for Visit Section ................................................................... 9
1.2

Purpose .................................................................................................................. 9

1.3

Background .......................................................................................................... 10

1.4

Audience .............................................................................................................. 12

1.5

Organization of the Guide ..................................................................................... 13

1.5.1

Volume 1 Introductory Material ........................................................................ 13

1.5.2

Volume 2 CDA Templates and Supporting Material ........................................... 13

1.6

Contents of the Package ........................................................................................ 14

2

CDA R2 BACKGROUND ................................................................................................ 15

3

DESIGN CONSIDERATIONS .......................................................................................... 17

4

3.1

CDA Participations ............................................................................................... 17

3.2

Rendering Header Information for Human Presentation ......................................... 17

3.3

Unknown and No Known Information .................................................................... 18

3.4

Use of Qualifiers ................................................................................................... 22

USING THIS IMPLEMENTATION GUIDE ........................................................................ 24
4.1

Levels of Constraint .............................................................................................. 24

4.2

Conformance Conventions Used in This Guide ...................................................... 24

4.2.1

Errata or Enhancements .................................................................................. 24

4.2.2

Templates and Conformance Statements .......................................................... 25

4.2.3

Template Versioning ......................................................................................... 27

4.2.4

Open and Closed Templates.............................................................................. 28

4.2.5

Conformance Verbs (Keywords) ......................................................................... 28

4.2.6

Cardinality ....................................................................................................... 29

4.2.7

Optional and Required with Cardinality ............................................................ 30

4.2.8

Vocabulary Conformance .................................................................................. 30

4.2.9

Containment Relationships ............................................................................... 32

4.2.10

Data Types ....................................................................................................... 33

4.2.11

Document-Level Templates "Properties" Heading ............................................... 33

4.3
4.3.1

XML Conventions Used in This Guide ................................................................... 33
XPath Notation ................................................................................................. 33

4.3.2
5

XML Examples and Sample Documents ............................................................ 34

REFERENCES .............................................................................................................. 35

APPENDIX A —

ACRONYMS AND ABBREVIATIONS ........................................................... 36

APPENDIX B —

HIGH-LEVEL CHANGES FROM PREVIOUS RELEASES ............................. 39

APPENDIX C —

EXTENSIONS TO CDA R2 ......................................................................... 40

APPENDIX D —

MIME MULTIPART/RELATED MESSAGES ................................................ 42

RFC-2557 MIME Encapsulation of Aggregate Documents, Such as HTML (MHTML) ............ 42
Referencing Supporting Files in Multipart/Related Messages ............................................. 42
Referencing Documents from Other Multiparts within the Same X12 Transactions ............. 43

Figures
Figure 1: Templated CDA ..................................................................................................... 15
Figure 2: nullFlavor Example ............................................................................................... 18
Figure 3: Attribute Required (nullFlavor not allowed) ............................................................ 19
Figure 4: Allowed nullFlavors When Element is Required (with xml examples) ....................... 19
Figure 5: Unknown Medication Example ............................................................................... 20
Figure 6: Unknown Medication Use of Anticoagulant Drug Example ...................................... 20
Figure 7: No Known Medications Example ............................................................................ 21
Figure 8: Value Known, Code for Value Not Known ............................................................... 21
Figure 9: Value Completely Unknown ................................................................................... 21
Figure 10: Value Known, Code in Required, Code System Not Known but Code from Another
Code System is Known.................................................................................................. 22
Figure 11: Qualifier Example ................................................................................................ 23
Figure 12: Context Table Example: Asthma Diagnosis Observation ....................................... 25
Figure 13: Constraints Overview Example: Asthma Diagnosis Observation ............................ 26
Figure 14: Constraints Format Example ............................................................................... 27
Figure 15: Constraints Format – only one allowed ................................................................. 30
Figure 16: Constraints Format – only one like this allowed .................................................... 30
Figure 17: Binding to a Single Code ...................................................................................... 31
Figure 18: XML Expression of a Single-code Binding ............................................................. 31
Figure 19: Translation Code Example ................................................................................... 32
Figure 20: Example Value Set Table (Language) .................................................................... 32
Figure 21: XML Document Example ..................................................................................... 34
Figure 22: XPath Expression Example .................................................................................. 34
Figure 23: ClinicalDocument Example .................................................................................. 34

Tables
Table 1: Contents of the Package .......................................................................................... 14

1 INTRODUCTION
1.1 Note to Update Readers—Items for Comment
This update contains two volumes. Below are descriptions of items that may be
commented on in each volume.
Volume 1:
1. The body of the document up until the appendices MAY be commented on.
Volume 2: Templates that are new or changed MAY be commented on; templates that
are unchanged from the previous release MAY NOT be commented on.
2. Templates that are new or substantially revised are signified by “Draft as part of
National Health Care Surveys Release 1, DSTU Release 1.2 – US Realm” under
the template name. These MAY be commented on.
EXAMPLE:

Clinical Note and External Document Reference
[externalDocument: identifier
urn:hl7ii:2.16.840.1.113883.10.20.34.3.44:2016-07-01 (open)]
Draft as part of National Health Care Surveys Release 1, DSTU Release 1.2 US Realm
3. Templates that have been brought in unchanged from the previous release have
“Published as part of ” under the template name. These MAY NOT
be commented on.
EXAMPLE:

Chief Complaint and Reason for Visit Section
[section: identifier urn:oid:2.16.840.1.113883.10.20.22.2.13
(open)]
Published as part of Consolidated CDA Templates for Clinical Notes (US
Realm) DSTU R1.1
Changes made in this release are summarized in the Appendix in High-Level Changes
from Previous Releases. Volume 2 of this guide contains a detailed section on “Changes
from Previous Version”.

1.2 Purpose
This two-volume implementation guide contains an overview of Clinical Document
Architecture (CDA) markup standards, design, and use (Volume 1) and a collection of
CDA templates for the Centers for Disease Control and Prevention (CDC), National
Center for Health Statistics (NCHS), National Health Care Surveys applicable to the US
Realm (Volume 2). These two volumes constitute a Draft Standard for Trial Use (DSTU).
CDA templates included in Volume 2 represent healthcare data collected by the CDC
NCHS within the Division of Health Care Statistics (DHCS). The data are collected

through three surveys of ambulatory, inpatient, and outpatient care services in the
United States: the National Ambulatory Medical Care Survey (NAMCS), the National
Hospital Care Survey (NHCS) and the National Hospital Ambulatory Medical Care
Survey (NHAMCS).1 These surveys produce nationally representative data to answer key
questions about health care usage, quality, and disparities that are of interest to public
health professionals, researchers, and health care policy makers.
This implementation guide specifies National Health Care Surveys with three document
types:


Emergency Department Encounter, for data collected by NHCS and NHAMCS



Inpatient Encounter, for data collected by NHCS



Outpatient Encounter, for data collected NHCS, NAMCS, and NHAMCS

1.3 Background
The NAMCS collect objective, reliable information about the provision and use of
ambulatory medical care services in the United States. Findings are based on a sample
of visits to non-federally employed, office-based physicians, as well as visits to health
care providers at community health centers.
The NHCS provides accurate and reliable health care statistics on the latest use of
hospitals and hospital-based care organizations in the United States. Findings are
based on all inpatient discharges and all emergency department and outpatient
department visits at a sample of non-federal, non-institutional hospitals with six or
more staffed inpatient beds.
The NHAMCS collects data on the use and provision of ambulatory care services in
hospital emergency, outpatient departments, and ambulatory surgery centers. Findings
are based on a national sample of visits to the emergency departments, outpatient
departments of general and short-stay hospitals, and ambulatory surgery centers.
While there are some differences (detailed in the guide), all three surveys capture
information about the patient, the visit, signs and symptoms, diagnoses, procedures,
medications, and discharge disposition.
Traditionally, human abstractors have collected NAMCS and NHAMCS data, while
NHCS data have been obtained by the electronic submission of administrative claims
(X12N Health Care Claim: Institutional Implementation Guide (837I)). This
implementation guide builds on the standard CDA visit report to allow:

1



Data from a greater number of visits to be collected



More complete data, especially clinical data, to be obtained by electronic means
than can be obtained by human abstractors or administrative claims



Enhancement of the surveys by incorporating readily available data such as the
patient problem list, and vital statistics measures including height and weight



Significantly more standardized data to be collected than previously

CDC, National Health Care Surveys. http://www.cdc.gov/nchs/dhcs.htm

The NAMCS and NHAMCS have traditionally required manual data abstraction. In the
NAMCS data collection in physician offices, U.S. Census field representatives (Field
Reps) visit physician practice locations to obtain the data. The Field Reps ask
physicians practice context and practice management questions. These "Physician
Induction" questions are at the practice level and are outside of the scope of this
implementation guide. Physicians are assigned a randomly-selected, one-week reporting
period, during which data for a random sample of patient visits are recorded by the
visiting Field Reps on an encounter form. Data captured include information on patient
symptoms, diagnoses, and medications. The form also includes information on
diagnostic procedures, patient management, and planned future treatment. Data are
entered into a computer-assisted tool and are later aggregated and sent back to NCHS
for data processing. The NAMCS data collection in community health centers is
conducted in a similar manner (e.g., induction questions, and visit data abstraction and
transmission) except that Field Reps collect information on visits seen by three
randomly-selected health care providers (including physicians, nurse practitioners,
physician assistants, and certified nurse midwives) practicing at the sampled
community health center. In NHAMCS, Field Reps conduct induction interviews with
the sampled hospitals and collect sampled visit data over a four-week reporting period
from randomly selected emergency services areas, outpatient department clinics, and
affiliated ambulatory surgery centers. Visit data captured on the patient and services
used are largely similar between NHAMCS and NAMCS. This manual data abstraction
process is cumbersome, resource intensive, costly, and effectively limits the data pool.
Automating the survey process using CDA streamlines data collection and facilitates
survey participation by providing all physicians and hospitals with a familiar and
standard process. Templates included in this guide align with the CDA R2 (Release 2)
implementation guide, which is the standard indicated by Meaningful Use
requirements. The templates in this guide expand on the scope of the original survey
data elements in that they do not constrain the data collected to the narrow lists on the
survey instruments, allowing data collection of any service, procedure, or diagnosis
recorded.
Implementers use this guide to submit data to fulfill requirements of the National
Health Care Surveys covered under this guide by automatic extraction of the data from
a practice's electronic health record (EHR) system or clinical data repository. In cases
where there is only partial fulfillment of the requirements of the National Health Care
Surveys covered under this guide by a practice’s use of this guide, Field Reps may be
sent into the practice to complete the requirements. In these cases, Field Rep data
collection forms will be pre-populated with the data enabled by this guide, thus
significantly reducing the data collection burden.
Although EHR extraction offers new potential for automating the survey process or
parts thereof, the challenges of automating data extraction are acknowledged in
literature. For example, according to Garrido T, et. al (2013) 2, "Even with improved
standardization of terminologies and codes, EHR content, structure, and data format
vary, as do local data capture and extraction procedures." NCHS is and has been
dealing with EHR content, structure, and data format challenges already, even with
Garrido T, et. al. "e-Measures: insight into the challenges and opportunities of automating publicly
reported quality measures." J Am Med Inform Assoc. Jan 2014; 21(1):181-184 doi: 10.1136/amiajnl2013-001789. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3912717/
2

manual abstraction. We believe that this implementation guide will promote movement
towards standardization of EHR content, structure, data format, and data capture and
extraction procedures for data elements of interest to the surveys—such as diagnoses,
medication, and procedures. Such data are also of interest to a wide variety of other
stakeholders.
We agree with Garrido that "Within a single institution, significant differences in
denominators, numerators, and rates arise from different electronic data sources, and
documentation habits of providers vary. Data entered into the EHR may not be
interpreted or recognized, resulting in substantial numerator loss and underestimates
of the delivery of clinical preventive services." It is important, however, to note that the
National Health Care Surveys are not used to evaluate quality of care within single
institutions or via clinical quality measures within single or multiple institutions. These
concerns are, therefore, not relevant to the National Health Care Surveys. NCHS already
deals with varying provider documentation habits in the current process via paper and
EHR manual abstraction and will closely monitor the effects of varying provider
documentation habits during EHR extraction. This implementation guide is published
as a DSTU, allowing users to comment during the trial period (see Errata or
Enhancements). Instructions for submitting comments are available on the Health Level
Seven (HL7) STU Comments site at: http://www.hl7.org/dstucomments/. The data
collection process will be reviewed for accuracy of automated reporting and to ensure
that new extraction procedures do not excessively burden clinicians or their supporters.
NCHS will do this through planned implementation and collection trials. NCHS plans to
submit the results of this evaluation for publication.
The intent of this implementation guide is to obtain as much survey information as
possible from data currently available in EHRs. It is understood that not all of the data
items indicated on the surveys may be captured by EHR systems at this time.
Submission of survey data from EHRs that do not contain all of the desired data
elements specified in this implementation guide can be accepted, but each survey
submission must include all of the required data elements specified in the
implementation guide. Some of the survey data elements that are not common in EHRs
at present have been included in a Health Statistics profile of the HL7 EHR-S Public
Health Functional profile. Future EHR functionality will address this gap. If participants
in these surveys wish to document additional details to meet the survey requirements
now by configuring encounter forms or other templates in the EHR, they may do so;
however, this is not required for submission and this implementation guide does not
give a site guidance on how to do so.

1.4 Audience
The audience for this implementation guide includes the architects and developers of
healthcare information technology (HIT) systems in the US Realm that exchange patient
clinical data in ambulatory care settings.

1.5

Organization of the Guide
This implementation guide is organized into two volumes. Volume 1 contains primarily
narrative text describing this guide to the three National Health Care Surveys, whereas
Volume 2 contains normative CDA template definitions.

1.5.1 Volume 1 Introductory Material
This document, Volume 1, provides an overview of CDA and information on how to
understand and use the CDA templates provided in Volume 2.


Chapter 1—Introduction



Chapter 2—CDA R2 Background. This chapter contains selected background
material on the CDA Release 2 (CDA R2) base standard, to aid the reader in
conceptualizing the "templated CDA" approach to implementation guide
development.



Chapter 3—Design Considerations. This chapter includes design considerations
that describe overarching principles applied across the CDA templates in this
guide. Material in this chapter can be thought of as "heuristics", as opposed to
the formal and testable constraints found in Volume 2 of this guide.



Chapter 4—Using This Implementation Guide. This chapter describes the rules
and formalisms used to constrain the CDA R2 base standard. It describes the
formal representation of CDA templates, the mechanism by which templates are
bound to vocabulary, and additional information necessary to understand and
correctly implement the normative content found in Volume 2 of this guide.



Appendices. The Appendices include an overview of changes from the previous
release, a summary of extensions to CDA R2, and an excerpt of the Health Level
Seven (HL7) Additional Information Specification Implementation Guide covering
MIME Multipart/Related Messages.

1.5.2 Volume 2 CDA Templates and Supporting Material
Volume 2 includes CDA templates and prescribes their use for a set of specific
document types representing the National Health Care Surveys. The main chapters are:


Chapter 1—Document-Level Templates. This chapter defines the US Realm
Header template that applies across three document types representing the
Emergency Department Encounter (NHCS-ED, NHAMCS-ED), Inpatient
Encounter (NHCS-IP), and Outpatient Encounter (NHCS-OPD, NAMCS,
NHAMCS-OPD). It defines each of the document types and header constraints
specific to each, as well as the section-level templates (required and optional) for
each.



Chapter 2—Section-Level Templates. This chapter defines the section templates
referenced within the document types. Sections are atomic units, and can be
reused by future specifications.



Chapter 3—Entry-Level Templates. This chapter defines entry-level templates,
called clinical statements. Machine-processable (coded) data are sent in the

entry templates. The entry templates are referenced by one or more section
templates. Entry-level templates are always contained in section-level templates,
and section-level templates are always contained in a document.

1.6



Chapter 4—Participation and Other Templates. This chapter defines templates
for CDA participants (e.g., author, performer) and other fielded items (e.g.,
address, name) that cannot stand on their own without being nested in another
template.



Chapters 5-7 include template IDs, value sets, and code systems used in this
guide.



Chapter 8—Changes from Previous Version. This chapter provides detailed
change logs.

Contents of the Package
The following files comprise the implementation guide package:
Table 1: Contents of the Package
Filename

Description

Standards
Applicability

CDAR2_IG_NHCS_R1_DSTU1.2_2016JUL
_V1_Introductory_Material.docx

Implementation Guide
Introductory Material

Normative

CDAR2_IG_NHCS_R1_DSTU1.2_2016JUL
_V2_Templates_and_Supporting.docx

Implementation Guide
Template Library and
Supporting Material

Normative

CDAR2_IG_NHCS_R1_DSTU1.2_2016JUL
_IPE.xml

Inpatient Encounter
Sample

Informative

CDAR2_IG_NHCS_R1_DSTU1.2_2016JUL
_OPE.xml

Outpatient Encounter
Sample

Informative

CDAR2_IG_NHCS_R1_DSTU1.2_2016JUL
_EDE.xml

Emergency Department
Sample

Informative

CDA.xsl

Stylesheet for rendering

Informative

_readme.txt

Text file describing
contents of the package

Informative

2 CDA R2 BACKGROUND
CDA is "… a document markup standard that specifies the structure and semantics of
‘clinical documents’ for the purpose of exchange" [CDA R2, Section 1.1].3 Clinical
documents, according to CDA, have the following characteristics:


Persistence



Stewardship



Potential for authentication



Context



Wholeness



Human readability

CDA defines a header for classification and management and a document body that
carries the clinical record. While the header metadata are prescriptive and designed for
consistency across all instances, the body is highly generic, leaving the designation of
semantic requirements to implementation.
CDA R2 can be constrained by mechanisms defined in the "Refinement and
Localization"4 section of the HL7 Version 3 Interoperability Standards. The mechanism
most commonly used to constrain CDA is referred to as "templated CDA". In this
approach, a library is created containing modular CDA templates such that the
templates can be reused across any number of CDA document types, as shown in the
following figure.
Figure 1: Templated CDA

There are many different kinds of templates that might be created. Among them, the
most common are:


Document-level templates: These templates constrain fields in the CDA
header, and define containment relationships to CDA sections. For example, an

HL7 CDA Release 2. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
HL7 Version 3 Standard.
http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm (Login required.)
3
4

NAMCS document-level template might require that the provider’s ID be present,
and that the document contain a Services section.


Section-level templates: These templates constrain fields in the CDA section,
and define containment relationships to CDA entries. For example, a Services
section-level template might require that the section/code be fixed to a
particular LOINC code, and that the section contain a Provided Service
Observation.



Entry-level templates: These templates constrain the CDA clinical statement
model in accordance with real world observations and acts. For example, a
Provided Service Observation entry-level template defines how the CDA
Observation class is constrained (how to populate observation/code, how to
populate observation/value, etc.) to represent the notion of a particular
observation.

A CDA implementation guide (such as this one) includes reference to those templates
that are applicable. On the implementation side, a CDA instance populates the template
identifier (templateId) field where it wants to assert conformance to a given template.
On the receiving side, the recipient can both test the instance for conformance against
the CDA XML (Extensible Markup Language) schema and test the instance for
conformance against asserted templates.

3 DESIGN CONSIDERATIONS
Design considerations describe overarching principles that have been developed and
applied across the CDA templates in this guide. Material in this chapter can be thought
of as "heuristics", as opposed to the formal and testable constraints found in Volume 2
of this guide.

3.1 CDA Participations
A CDA participant (e.g., Author, Informant), per the Reference Information Model (RIM),
is "an association between an Act and a Role with an Entity playing that Role. Each
Entity (in a Role) involved in an Act in a certain way is linked to the act by one
Participation-instance. The kind of involvement in the Act is specified by the
Participation.typeCode".
CDA principles when asserting participations include:


Participation persistence: An object's participations (and participation time
stamps) don't change just because that object is reused. For instance,
authorship of an object doesn't change just because that object is now included
in a summary document.



Participation evolution: Additional participations (and participation time
stamps) can be ascribed to an object over its lifetime.



Device participation: Devices do not participate as legally responsible entities,
but can participate as authors in some scenarios.

Meaningful Use Stage 2 criterion §170.314(b)(4) Clinical Information Reconciliation
requires a system to "simultaneously display (i.e., in a single view) the data from at least
two list sources in a manner that allows a user to view the data and their attributes,
which must include, at a minimum, the source and last modification date".5
CDA requires that Author and Author time stamp be asserted in the document header.
From there, authorship propagates to contained sections and contained entries, unless
explicitly overridden. Thus, all entries in CDA implicitly include Author and Author time
stamp.

3.2

Rendering Header Information for Human Presentation
Good practice recommends that the following be present whenever the document is
viewed:


Document title and document dates



Service and encounter types, and date ranges as appropriate



Names of all persons along with their roles, participations, participation date
ranges, identifiers, address, and telecommunications information

HHS, Standards, Implementation Specifications, and Certification Criteria for EHR Technology (Final
Rule). http://www.gpo.gov/fdsys/pkg/FR-2012-09-04/pdf/2012-20982.pdf
5



Names of selected organizations along with their roles, participations,
participation date ranges, identifiers, address, and telecommunications
information



Date of birth for recordTarget(s)

3.3 Unknown and No Known Information
Information technology solutions store and manage data, but sometimes data are not
available. An item may be unknown, not relevant, or not computable or measureable,
such as where a patient arrives at an emergency department unconscious and with no
identification.
In many cases, the implementation guide will stipulate that a piece of information is
required (e.g., via a SHALL conformance verb). However, in most of these cases, the
standard provides an "out", allowing the sender to indicate that the information isn’t
known.
Here, we provide guidance on representing unknown information. Further details can
be found in the HL7 V3 Data Types, Release One specification that accompanies the
CDA R2 base standard. However, it should be noted that the focus is on the
unambiguous representation of known data, and that in general, the often subtle
nuances of unknown information representation are less relevant to the recipient.
Many fields contain an "@nullFlavor" attribute, used to indicate an exceptional value.
Some flavors of Null are used to indicate that the known information falls outside of
value set binding constraints. Not all uses of the @nullFlavor attribute are associated
with a case in which information is unknown. Allowable values for populating the
attribute give more details about the reason the information is unknown, as shown in
the following example.
Figure 2: nullFlavor Example

Use null flavors for unknown, required, or optional attributes:
NI

No information. This is the most general and default null flavor.

NA

Not applicable. Known to have no proper value (e.g., last menstrual
period for a male).

UNK

Unknown. A proper value is applicable, but is not known.

ASKU

Asked, but not known. Information was sought, but not found (e.g.,
the patient was asked but did not know).

NAV

Temporarily unavailable. The information is not available, but is
expected to be available later.

NASK

Not asked. The patient was not asked.

MSK

There is information on this item available but it has not been provided
by the sender due to security, privacy, or other reasons. There may be
an alternate mechanism for gaining access to this information.

OTH

The actual value is not an element in the value domain of a variable.
(e.g., concept not provided by required code system).

The list above contains those null flavors that are commonly used in clinical
documents. For the full list and descriptions, see the nullFlavor vocabulary domain
in the CDA R2 normative edition.
Any SHALL, SHOULD and MAY conformance statement may use nullFlavor, unless the
nullFlavor is explicitly disallowed (e.g., through another conformance statement
which includes a SHALL conformance for a vocabulary binding to the @code attribute, or
through an explicit SHALL NOT allow use of nullFlavor conformance).
Figure 3: Attribute Required (nullFlavor not allowed)

contain exactly one [1..1] code (CONF:15407).
a. This code SHALL contain exactly one [1..1] @code="11450-4" Problem List
(CodeSystem: LOINC 2.16.840.1.113883.6.1) (CONF:15408) .

1. SHALL

or
2. SHALL contain exactly one [1..1] effectiveTime/@value (CONF:5256).

Figure 4: Allowed nullFlavors When Element is Required (with xml examples)
1. SHALL contain at least one [1..*] id
2. SHALL contain exactly one [1..1] code
3. SHALL contain exactly one [1..1] effectiveTime

New Grading system

Spiculated mass grade 5

If a sender wants to state that a piece of information is unknown, the following
principles apply:
1. If the sender doesn’t know an attribute of an act, that attribute can be null.
Figure 5: Unknown Medication Example

patient was given a medication but I do not know what it was

2. If the sender doesn’t know if an act occurred, the nullFlavor is on the act
(detail could include specific allergy, drug, etc.).
Figure 6: Unknown Medication Use of Anticoagulant Drug Example

I do not know whether or not patient received an anticoagulant
drug

3. If the sender wants to state "no known", a negationInd can be used on the
corresponding act (substanceAdministration, Procedure, etc.)
Previously, the Continuity of Care Document (CCD), Integrating the Healthcare
Enterprise (IHE), and the Health Information Technology Standards Panel
(HITSP) recommended using specific codes to assert no known content, for
example 160244002 No known allergies or 160245001 No current
problems or disability. Specific codes are still allowed; however, use of
these codes is not recommended.
These next examples illustrate nuances of representing information in coded
fields when information is a negative assertion, for example it is not the case

that the patient has an allergy or it is not the case that a patient takes a
medication. The phrases "no known allergies" or "no known medications" are
typically associated with this type of negative assertion.
Figure 7: No Known Medications Example

No known medications

Figure 8: Value Known, Code for Value Not Known

…

Spiculated mass grade 5

Figure 9: Value Completely Unknown

…

Figure 10: Value Known, Code in Required, Code System Not Known but Code from
Another Code System is Known

…

Spiculated mass grade 5
/>

3.4 Use of Qualifiers
Post-coordination in a code system is when two or more codes are used to represent a
single concept. When using a code system (such as SNOMED CT) that supports postcoordination it is possible to build up terms from combinations of codes.
For example, the Consolidated CDA (C-CDA) Medication Activity template has an
element approachSiteCode which is the CD data type and is bound to the Body Site
(2.16.840.1.113883.3.88.12.3221.8.9) value set. While most of the terms in the Body
Site value set are pre-coordinated, it is likely that all possible combinations of body site
are not accounted for. In these cases, post-coordination becomes necessary and allows,
for example, the SNOMED code for “back of left hand” to be represented by the
combination of a code for “hand”, a code for “left”, and a code for “back of”.
The CD data type has a qualifier element that consists of a name/value pair. Name is
the CV data type and value is the CD data type. Value is used to hold the qualifying
code (“left” or “back of” in our example above) and name is used to describe the
relationship between the value and the parent element.
The following is an example of the use of qualifier:

Figure 11: Qualifier Example

4 USING THIS IMPLEMENTATION GUIDE
This chapter describes the rules and formalisms used to constrain the CDA R2
standard. It describes the formal representation of CDA templates, the mechanism by
which templates are bound to vocabulary, and additional information necessary to
understand and correctly implement the normative content found in Volume 2 of this
guide.

4.1

Levels of Constraint
The CDA standard describes conformance requirements in terms of three general levels
corresponding to three different, incremental types of conformance statements:


Level 1 requirements impose constraints upon the CDA Header. The body of a
Level 1 document may be XML or an alternate allowed format. If XML, it must be
CDA-conformant markup.



Level 2 requirements specify constraints at the section level of a CDA XML
document: most critically, the section code and the cardinality of the sections
themselves, whether optional or required.



Level 3 requirements specify constraints at the entry level within a section. A
specification is considered "Level 3" if it requires any entry-level templates.

Note that these levels are rough indications of what a recipient can expect in terms of
machine-processable coding and content reuse. They do not reflect the level or type of
clinical content, and many additional levels of reusability could be defined.
The contexts table for each document type lists the required and optional sections.

4.2 Conformance Conventions Used in This Guide
4.2.1 Errata or Enhancements
Comments regarding errata or enhancements may be noted on the HL7 DSTU
Comments page: http://www.hl7.org/dstucomments/.

4.2.2 Templates and Conformance Statements
Conformance statements within this implementation guide are presented as constraints
from Trifolia Workbench, a template repository.6 An algorithm converts constraints
recorded in Trifolia to a printable presentation. Each constraint is uniquely identified by
an identifier at or near the end of the constraint (e.g., CONF:86-7345). The digits in the
conformance number before the hyphen identify which implementation guide the
template belongs to and the number after the hyphen is unique to the owning
implementation guide. Together, these two numbers uniquely identify each constraint.
These identifiers are persistent but not sequential. Conformance numbers in this guide
associated with a conformance statement that is carried forward from a previous
version of this guide will carry the same conformance number from the previous
version. This is true even if the previous conformance statement has been edited. If a
conformance statement is entirely new it will have a new conformance number.
Bracketed information following each template title indicates the template type (section,
observation, act, procedure, etc.), the object identifier (OID) or uniform resource
name (URN), and whether the template is open or closed. The identifier OID is the
templateId/@root value; all templateIds have an @root value. Versioned templates
also have an @extension value, which is a date identifying the version of this template;
such templates are identified by URN and the HL7 version (urn:hl7ii). The URN
identifier includes both the @root and @extension value for the templateId (for
example, identifier urn:hl7ii:2.16.840.1.113883.10.20.5.5.41:2014-06-09).
Each section and entry template in Volume 2 of this guide includes a context table. The
"Contained By" column indicates which templates use this template, and if the template
is optional or required in the containing template. The "Contains" column indicates any
templates that this template uses.
Figure 12: Context Table Example: Asthma Diagnosis Observation
Contained By:

Contains:

Diagnoses Section (optional)

Condition Control Observation
Severity Observation (V2)

Each entry template also includes a constraints overview table to summarize the
constraints in the template.

6

Trifolia Workbench, https://trifolia.lantanagroup.com/

Figure 13: Constraints Overview Example: Asthma Diagnosis Observation
XPath

Card.

Verb

Data
Type

CONF#

Fixed Value

observation[templateId/@root = '2.16.840.1.113883.10.20.34.3.5']
@classCode

1..1

SHALL

1106-334

2.16.840.1.113883.5.6 (HL7ActClass) =
OBS

@moodCode

1..1

SHALL

1106-335

2.16.840.1.113883.5.1001 (ActMood) =
EVN

templateId

1..1

SHALL

1106-443

1..1

SHALL

1106-444

2.16.840.1.113883.10.20.34.3.5

1..1

SHALL

1106-336

2.16.840.1.114222.4.11.7432 (Asthma
(NCHS))

@root
value

CD

...

The expression “such that it” at the end of one conformance statement links that
conformance statement to the following subordinate conformance statement to further
constrain the first conformance statement. To understand the full effect of this
conformance construct, the two conformances must be considered as a single
compound requirement. The subordinate conformance statement functions as a
subordinate clause (like a "where" clause), which is being applied on the first
conformance statement.
The following example shows a compound conformance statement made up of two
conformance statements joined by a "such that it" clause. The effect of this syntax can
be interpreted as a "where" clause. Thus...
1. SHALL contain exactly one [1..1] templateId (CONF:81-7899) such that it
a. SHALL contain exactly one [1..1]
@root="2.16.840.1.113883.10.20.22.4.31" (CONF:81-10487).
...is understood as:
This template SHALL contain exactly one [1..1] templateId where it contains exactly
one [1..1] @root="2.16.840.1.113883.10.20.22.4.31".
This means that you must have a template id with
@root="2.16.840.1.113883.10.20.22.4.31", but you can also have other template
ids with different valued attributes.
The following figure shows a typical template’s set of constraints presented in this
guide. The next chapters describe specific aspects of conformance statements—open vs.
closed statements, conformance verbs, cardinality, vocabulary conformance,
containment relationships, and null flavors.

Figure 14: Constraints Format Example

Asthma Diagnosis Observation
[observation: templateId 2.16.840.1.113883.10.20.34.3.5 (open)]
1. Conforms to Diagnosis Observation template (identifier:
urn:oid:2.16.840.1.113883.10.20.34.3.1).
2. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem:
HL7ActClass 2.16.840.1.113883.5.6) (CONF:1106-334).
3. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) (CONF:1106-335).
4. SHALL contain exactly one [1..1] templateId (CONF:1106-443) such that it
a. SHALL contain exactly one [1..1]
@root="2.16.840.1.113883.10.20.34.3.5" (CONF:1106-444).
5. SHALL contain exactly one [1..1] value with @xsi:type="CD", where the code
SHALL be selected from ValueSet Asthma (NCHS)
2.16.840.1.114222.4.11.7432 DYNAMIC (CONF:1106-336).
6. ...

4.2.3 Template Versioning
Under the "templated CDA" approach a new implementation guide can use existing CDA
templates from previously published implementation guides. A new version of an
existing implementation guide reuses templates from the previous version. During the
ballot phase or update phase, templates carry the designation "Published" to indicate
the template is unchanged from the previous version or "Draft" to indicate a new or
revised template. Substantial revisions to previously published templates are indicated
by the version number (V2, V3, etc.) in all phases: ballot, update, and published guides.
If there are no substantive changes to a template that has been successfully published,
the template will carry the same templateId/@root (identifier oid) and
templateId/@extension as in the previous implementation guide. (In the case of older
templates, the @extension attribute will not be present.) During a new ballot or update
phase, "Published" is appended to the main heading for the template to indicate that
the template cannot be commented on in the ballot or update. The "Published"
designation is removed in the final publication versions.
A revised version of a previously published template keeps the same
templateId/@root as the previous version but is assigned a new
templateId/@extension. The notation "(Vn)" (V2, V3, etc.) is also added to the
template name. Versions are not necessarily forward or backward compatible. A
versioning may be due to substantive changes in the template or because a contained
template has changed. The "(Vn)" designation is persistent; it appears with that
template when it is used in subsequent guides. During a new ballot or update phase,
"Draft" is appended to the main heading for the template to indicate that it may be

voted on in the ballot or commented on in the update; the "Draft" designation is
removed in the final publication versions.
Structured Documents Working Group (SDWG) collaborated with Templates Working
Group to establish template versioning recommendations, recently published in the
following specification: HL7 Templates Standard: Specification and Use of Reusable
Information Constraint Templates, Release 1.7 SDWG will leverage that specification to
create guidance for template IDs and template versioning for future CDA
implementation guides, including future versions of C-CDA, but that work is still in
progress. The versioning approach used in this version of C-CDA is likely to be close to
the final guidance, but has not been formally approved by SDWG for all implementation
guides at this time.

4.2.4 Open and Closed Templates
In open templates, all of the features of the CDA R2 base specification are allowed
except as constrained by the templates. By contrast, a closed template specifies
everything that is allowed and nothing further may be included.
Estimated Date of Delivery (templateId 2.16.840.1.113883.10.20.15.3.1) is an
example of a closed template in this guide.
Open templates allow HL7 implementers to develop additional structured content not
constrained within this guide. HL7 encourages implementers to bring their use cases
forward as candidate requirements to be formalized in a subsequent version of the
standard to maximize the use of shared semantics.

4.2.5 Conformance Verbs (Keywords)
The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT, and SHALL NOT in this
document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's
Guide.8


SHALL:



SHALL NOT:



SHOULD/SHOULD NOT:



MAY/NEED NOT:

an absolute requirement
an absolute prohibition against inclusion

best practice or recommendation. There may be valid
reasons to ignore an item, but the full implications must be understood and
carefully weighed before choosing a different course
truly optional; can be included or omitted as the author decides
with no implications

The keyword "SHALL" allows the use of nullFlavor unless the requirement is on an
attribute or the use of nullFlavor is explicitly precluded.
When conformance statements are nested (or have subordinate clauses) the
conformance statements are to be read and interpreted in hierarchical order. These
hierarchical clauses can be interpreted as "if then, else" clauses. Thus...

7
8

HL7 Templates Standards. http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=132
HL7, Version 3 Publishing Facilitator's Guide. http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm

a. This structuredBody SHOULD contain zero or one [0..1] component
(CONF:1098-29066) such that it
i.

contain exactly one [1..1] Plan of Treatment Section (V2)
(identifier:
urn:hl7ii:2.16.840.1.113883.10.20.22.2.10:2014-06-09)
(CONF:1098-29067).
SHALL

...is understood as:
a. It is recommended (SHOULD) that the structureBody contains a component.
i.

If the component exists, then it must contain a Plan of Treatment
Section (V2),

ii. else the component does not exist, and the conformance statement
about the Plan of Treatment Section (V2) should be skipped.
In the case where the higher level conformance statement is a SHALL, there is no
conditional clause. Thus...
a. This structuredBody SHALL contain exactly one [1..1] component
(CONF:1098-29086) such that it
i.

contain exactly one [1..1] Problem Section (entries
required) (V2) (identifier:
urn:hl7ii:2.16.840.1.113883.10.20.22.2.5.1:2014-06-09)
(CONF:1098-29087).
SHALL

...means that the structuredBody is always required to have a component.

4.2.6 Cardinality
The cardinality indicator (0..1, 1..1, 1..*, etc.) specifies the allowable occurrences within
a document instance. The cardinality indicators are interpreted with the following
format "m…n" where m represents the least and n the most:


0..1 zero or one



1..1 exactly one



1..* at least one



0..* zero or more



1..n at least one and not more than n

When a constraint has subordinate clauses, the scope of the cardinality of the parent
constraint must be clear. In the next figure, the constraint says exactly one participant
is to be present. The subordinate constraint specifies some additional characteristics of
that participant.

Figure 15: Constraints Format – only one allowed
1. SHALL contain exactly one [1..1] participant (CONF:2777).
a. This participant SHALL contain exactly one [1..1] @typeCode="LOC"
(CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType)
(CONF:2230).

In the next figure, the constraint says only one participant "like this" is to be present.
Other participant elements are not precluded by this constraint.
Figure 16: Constraints Format – only one like this allowed
1. SHALL contain exactly one [1..1] participant (CONF:2777) such that it
a. SHALL contain exactly one [1..1] @typeCode="LOC" (CodeSystem:
2.16.840.1.113883.5.90 HL7ParticipationType) (CONF:2230).

4.2.7 Optional and Required with Cardinality
The terms optional and required describe the lower bound of cardinality as follows:
Optional means that the number of allowable occurrences of an element may be 0; the
cardinality will be expressed as [0..1] or [0..*] or similar. In these cases, the
element may not be present in the instance. Conformances formulated with MAY or
SHOULD are both considered "optional" conformances.
Required means that the number of allowable occurrences of an element must be at
least 1; the cardinality will be expressed as [m..n] where m >=1 and n >=1 for
example [1..1] or [1..*]. In these cases, the element must be present in the
instance. Conformance statements formulated with SHALL are required conformances. If
an element is required but is not known (and would otherwise be omitted if it were
optional), the @nullFlavor attribute must be used. See Unknown and No Known
Information.

4.2.8 Vocabulary Conformance
The templates in this document use terms from several code systems. These
vocabularies are defined in various supporting specifications and may be maintained by
other bodies, as is the case for the LOINC® and SNOMED CT® vocabularies.
Note that value-set identifiers (e.g., ValueSet 2.16.840.1.113883.1.11.78
Observation Interpretation (HL7) DYNAMIC) used in the binding definitions of
template conformance statements do not appear in the XML instance of a CDA
document.; The definition of the template must be referenced to determine or validate
the vocabulary conformance requirements of the template.
Value-set bindings adhere to HL7 Vocabulary Working Group best practices, and
include both an indication of stability and of coding strength for the binding. Value set
bindings can be STATIC, meaning that they bind to a specified version of a value set, or
DYNAMIC, meaning that they bind to the most current version of the value set. If a STATIC
binding is specified, a date SHALL be included to indicate the value set version. If a

binding is specified, the value set authority and link to the base definition of
the value set SHALL be included, if available, so implementers can access the current
version of the value set. When a vocabulary binding binds to a single code, the stability
of the binding is implicitly STATIC.
DYNAMIC

Figure 17: Binding to a Single Code

2. SHALL contain exactly one [1..1] code (CONF:15403).
a) This code SHALL contain exactly one [1..1] @code="11450-4" Problem List
(CONF:15408).
b) This code SHALL contain exactly one [1..1] @codeSystem="2.16.840.1.113883.6.1"
(CodeSystem: LOINC 2.16.840.1.113883.6.1 STATIC) (CONF: 31141).

The notation conveys the actual code (11450-4), the code’s displayName (Problem List),
the OID of the codeSystem from which the code is drawn (2.16.840.1.113883.6.1), and
the codeSystemName (LOINC).
HL7 Data Types Release 1 requires the codeSystem attribute unless the underlying
data type is "Coded Simple" or "CS", in which case it is prohibited. The displayName
and the codeSystemName are optional, but recommended, in all cases.
The above example would be properly expressed as follows.
Figure 18: XML Expression of a Single-code Binding

A full discussion of the representation of vocabulary is outside the scope of this
document; for more information, see the HL7 V3 Normative Edition 20109 sections on
Abstract Data Types and XML Data Types R1.
There is a discrepancy between the HL7 R1 Data Types and this guide in the in the
implementation of translation code versus the original code. The R1 data type requires
the original code in the root. The convention agreed upon for this implementation guide
specifies a code from the required value set be used in the element and other codes not
included in the value set are to be represented in a translation for the element. This
discrepancy is resolved in HL7 Data Types R2.
In the next example, the conformant code is SNOMED-CT code 206525008.

HL7 Version 3 Interoperability Standards, Normative Edition 2010.
http://www.hl7.org/memonly/downloads/v3edition.cfm - V32010
9

Figure 19: Translation Code Example

Value set tables are present below a template, or are referenced if they occur elsewhere
in the specification, when there are value set bindings in the template. The value set
table provides the value set identifier, a description, and a link to the source of the
value set when possible. Ellipses in the last row indicate the value set members shown
are examples and the true source must be accessed to see all members.
If a value set binding has a DYNAMIC stability, implementers creating a CDA document
must go to the location in the Uniform Resource Locator (URL) to check for the most
current version of the value set expansion.
Figure 20: Example Value Set Table (Language)
Value Set: Language 2.16.840.1.113883.1.11.11526
A value set of codes defined by Internet RFC 4646 (replacing RFC 3066). Please see ISO 639
language code set maintained by Library of Congress for enumeration of language codes.
Value Set Source: http://www.ietf.org/rfc/rfc4646.txt
Code

Code System

Code System OID

Print Name

aa

Language

2.16.840.1.113883.6.121

Afar

ab

Language

2.16.840.1.113883.6.121

Abkhazian

ace

Language

2.16.840.1.113883.6.121

Achinese

ach

Language

2.16.840.1.113883.6.121

Acoli

ada

Language

2.16.840.1.113883.6.121

Adangme

ady

Language

2.16.840.1.113883.6.121

Adyghe; Adygei

ae

Language

2.16.840.1.113883.6.121

Avestan

af

Language

2.16.840.1.113883.6.121

Afrikaans

...

4.2.9 Containment Relationships
Containment constraints between a section and its entry are indirect in this guide,
meaning that where a section asserts containment of an entry, that entry can either be
a direct child or a further descendent of that section.
For example, in the following constraint:
1. SHALL contain at least one [1..*] entry (CONF:8647) such that it

a. SHALL contain exactly one [1..1] Advance Directive Observation
(templateId:2.16.840.1.113883.10.20.22.4.48) (CONF:8801).
the Advance Directive Observation can be a direct child of the section (i.e.,
section/entry/AdvanceDirectiveObservation) or a further descendent of that
section (i.e., section/entry/…/AdvanceDirectiveObservation). Either of these are
conformant.
All other containment relationships are direct, for example:
1. SHALL contain exactly one [1..1]
templateId/@root="2.16.840.1.113883.10.20.22.2.21" (CONF:7928).
The templateId must be a direct child of the section (i.e., section/templateId).

4.2.10 Data Types
All data types used in a CDA document are described in the CDA R2 standard. All
attributes of a data type are allowed unless explicitly prohibited by this specification.

4.2.11 Document-Level Templates "Properties" Heading
In Volume 2 of this implementation guide, each document-level template has a
"Properties" heading for ease of navigation. The Properties heading is an organizational
construct, underneath which relevant CDA act-relationships and roles are called out as
headings in the document.

4.3

XML Conventions Used in This Guide

4.3.1 XPath Notation
Instead of the traditional dotted notation used by HL7 to represent RIM classes, this
document uses XML Path Language (XPath) notation10 in conformance statements and
elsewhere to identify the Extensible Markup Language (XML) elements and attributes
within the CDA document instance to which various constraints are applied. The
implicit context of these expressions is the root of the document. This notation provides
a mechanism that will be familiar to developers for identifying parts of an XML
document.
XPath statements appear in this document in a monospace font.
XPath syntax selects nodes from an XML document using a path containing the context
of the node(s). The path is constructed from node names and attribute names (prefixed
by a ‘@’) and concatenated with a ‘/’ symbol.

10

XML Path Language. http://www.w3.org/TR/xpath/

Figure 21: XML Document Example

...

...

In the above example, the code attribute of the code could be selected with the XPath
expression in the next figure.
Figure 22: XPath Expression Example
author/assignedAuthor/code/@code

4.3.2 XML Examples and Sample Documents
Extensible Mark-up Language (XML) examples appear in figures in this document in
this monospace font. XML elements (code, assignedAuthor, etc.) and attribute
names (SNOMED CT, 17561000, etc.) also appear in this monospace font. Portions of
the XML content may be omitted from the content for brevity, marked by an ellipsis
(...) as shown in the example below.
Figure 23: ClinicalDocument Example

...

This publication package includes complete XML sample documents as listed in the
Contents of the Package table.

5 REFERENCES


CDC, Ambulatory Health Care Data. http://www.cdc.gov/nchs/ahcd.htm



CDC, National Health Care Surveys. http://www.cdc.gov/nchs/dhcs.htm



Garrido T, et al. "e-Measures: Insight into the challenges and opportunities of
automating publicly reported quality measures." J Am Med Inform Assoc. Jan
2014; 21(1):181-184. doi: 10.1136/amiajnl-2013-001789.
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3912717/



HHS, Health Information Technology: Standards, Implementation Specifications,
and Certification Criteria for Electronic Health Record Technology, 2014 Edition;
Revisions to the Permanent Certification Program for Health Information
Technology. 45 CFR Part 170, Final rule, (September 4, 2012). .
http://www.gpo.gov/fdsys/pkg/FR-2012-09-04/pdf/2012-20982.pdf



HL7 Additional Information Specification Implementation Guide, Release 3.0 Draft
Standard (March 2007).
http://www.hl7.org/documentcenter/public/wg/ca/CDAR2AIS0000R030_Imple
mentationGuideDraft.pdf.



HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for
Clinical Notes (US Realm) DSTU Release 2. (Consolidated CDA, C-CDA R2).
(November 2014).
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379



HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation,
Release 1.1 - US Realm (Consolidated CDA, C-CDA). (July 2012).
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=258



HL7 Templates Standard: Specification and Use of Reusable Information
Constraint Templates, Release 1. (October 2014).
http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=132



HL7 Version 3 Clinical Document Architecture (CDA®) Release 2 (CDA R2),
Normative Edition. (May 2005).
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7



HL7 Version 3 Interoperability Standards, Normative Edition 2010.
http://www.hl7.org/memonly/downloads/v3edition.cfm - V32010



HL7 Version 3 Publishing Facilitator's Guide.
http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm



HL7 Version 3 Standard: Refinement, Constraint and Localization to Version 3
Messages, Release 2. (August 20, 2007).
http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.ht
m (Login required.)



Lantana Consulting Group, Trifolia Workbench.
https://trifolia.lantanagroup.com/



XML Path Language (XPath), Version 1.0. http://www.w3.org/TR/xpath/

APPENDIX A — ACRONYMS AND ABBREVIATIONS
BCG

Bacillus Calmette–Guérin

CCD

Continuity of Care Document

C-CDA

Consolidated CDA

CDA

Clinical Document Architecture

CDC

Centers for Disease Control and Prevention

cid

content-id field

CPHDSS

Classifications and Public Health Data Standards Staff

CPT

Current Procedural Terminology

CTAS

Canadian Triage and Acuity Scale

CVX

Codes for Vaccine Administered

DHCS

Division of Health Care Statistics

DI

Device Identifier

DSTU

Draft Standard for Trial Use

ED

emergency department

EHR

electronic health record

FDA

Food and Drug Administration

FIPS

Federal Information Processing Standards

HCPCS

Healthcare Common Procedure Coding System

HHS

Health and Human Services

HIBCC

Health Industry Business Communications Council

HIE

health information exchange

HIPAA

Health Insurance Portability and Accountability Act of 1996

HIT

healthcare information technology

HITSP

Health Information Technology Standards Panel

HL7

Health Level Seven

HTML

HyperText Markup Language

ICCBBA

International Council for Commonality in Blood Banking Automation,
Inc.

ICD

International Classification of Diseases

IHE

Integrating the Healthcare Enterprise

IHTSDO

International Health Terminology Standard Development Organization

INR

international normalized ratio

IP

inpatient

IP

intellectual property

LOINC

Logical Observation Identifiers Names and Codes

MHTML

MIME HTML

MIME

Multipurpose Internet Mail Extensions

MU

Meaningful Use

NAMCS

National Ambulatory Medical Care Survey

NCHS

National Center for Health Statistics

NDC

National Drug Code

NHAMCS

National Hospital Ambulatory Medical Care Survey

NHCS

National Hospital Care Survey

NHIS

National Health Interview Survey

NHSN

National Healthcare Safety Network

NUBC

National Uniform Billing Committee

OID

object identifier

OMB

Office of Management and Budget

OPD

outpatient department

OTC

over the counter

PDF

portable document format

PHER WG

Public Health and Emergency Response Working Group

PHIN VADS

Public Health Information Network, Vocabulary Access and Distribution
System

PI

Production Identifier

PQ

physical quantity

R1, R2

Release 1, Release 2, etc.

RFC

request for comments

RIM

Reference Information Model

Rx

prescription

sdtc

Standard Duty Title Code

SDWG

Structured Documents Working Group

SNOMED CT Systemized Nomenclature for Medicine – Clinical Terms
STU

Standard for Trial Use

UCUM

Unified Code for Units of Measure

UDI

Unique Device Identification

UNII

Unique Ingredient identifier

URL

Uniform Resource Locator

URN

uniform resource name

V1, V2

Version 1, Version 2, etc.

VIS

vaccine information statement

XML

Extensible Markup Language

XPath

XML Path Language

APPENDIX B —
RELEASES

HIGH-LEVEL CHANGES FROM PREVIOUS

This appendix summarizes the main changes in this release. The majority of the
changes were made in response to approved DSTU comments located here:
http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=179.

2nd Update to Release 1 DSTU 1
Volume 1
One new section was added: “Use of Qualifiers”.

Volume 2
Many templates were versioned due to the versioning of contained templates (see the
section “Changes from Previous Version” in Volume 2 of this guide for a detailed view of
these changes).

Document-Level Templates
No new document-level templates were added.
Several document-level templates were updated due to the versioning of contained
template.

Section-Level Templates
No new section-level templates were added.
Several section-level templates were updated due to the versioning of contained
templates.
The following section-level templates were updated with changes:
•
•
•
•

Inpatient Encounters Section (V2)
Patient Information Section (V2)
Problems Section (V3)
Reasons for Visit Section (V2) (was Patient’s Reason for Visit Section)

Entry-Level Templates
One new entry-level template was added:
•

Clinical Note and External Document Reference

The following entry-level templates were retired:
•
•

Asthma Diagnosis Observation
Co-Morbid Condition Observation

Value Sets
Many of the value sets were updated with current URLs.

APPENDIX C — EXTENSIONS TO CDA R2
Extensions to CDA R2 have been developed for cases where there is a need to
communicate information for which there is no suitable representation in CDA R2. (See
http://wiki.hl7.org/index.php?title=CDA_R2_Extensions for further details about CDA
R2 extensions.) This section serves to itemize the extensions that are used in the guide
and provide implementation guidance.
Extensions used in this guide include:


sdtc:raceCode - The sdtc:raceCode extension allows for multiple races to be
reported for a patient.



sdtc:ethnicGroupCode – The sdtc:ethnicGroupCode extension is used to
record additional ethnicity groups for the recordTarget or subjectPerson.



sdtc:birthTime - The sdtc:birthTime element allows for the birth date of
any person to be recorded. The purpose of this extension is to allow the
recording of the subscriber or member of a health plan in cases where the health
plan eligibility system has different information on file than the provider does for
the patient.



sdtc:dischargeDispositionCode - The sdtc:dischargeDispositionCode
element allows the provider to record a discharge disposition in an encounter
activity.



sdtc:signatureText - The sdtc:signatureText element provides a location
in CDA for a textual or multimedia depiction of the signature by which the
participant endorses and accepts responsibility for his or her participation in the
Act as specified in the Participation.typeCode. Details of what goes in the
field are described in the HL7 CDA Digital Signature Standard balloted in Fall of
2013.

To resolve issues that need to be addressed by extensions, the developers of this guide
chose to approach extensions as follows:


An extension is a collection of element or attribute declarations and rules for
their application to the CDA Release 2.0.



All extensions are optional. An extension may be used, but it is not necessary to
use an extension.



A single namespace for all extension elements or attributes that may be used by
this guide will be defined.



The namespace for extensions created by the HL7 Structured Documents
Working Group (formerly Structured Documents Technical Committee) shall be
urn:hl7-org:sdtc.



This namespace shall be used as the namespace for any extension elements or
attributes that are defined by this implementation guide.



Each extension element shall use the same HL7 vocabularies and data types
used by CDA Release 2.0.



Each extension element shall use the same conventions for order and naming as
is used by the current HL7 tooling.



An extension element shall appear in the XML where the expected RIM element
of the same name would have appeared had that element not been otherwise
constrained from appearing in the CDA XML schema.

APPENDIX D —

MIME MULTIPART/RELATED MESSAGES

Note: The following text is taken from the HL7 Additional Information Specification
Implementation Guide (AIS00000), Section 2.4.11 For up-to-date guidance, refer to the
latest edition of that specification.
An attachment is comprised of the CDA document, including any supporting files
necessary to render the attested content of the document. Two Internet request for
comments (RFCs) are needed to properly construct the MIME multipart message. When
supporting files are needed, the collection of information shall be organized using a
MIME multipart/related package constructed according to RFC 2557. Within the MIME
package, supporting files must be encoded using Base-64. RFC-4648 should be used
when encoding the contents of the MIME package using Base-64. Finally, RFC-2392
may be used to reference other content that appears in the same X12 transaction to use
the same content to answer multiple questions for a single claim. Internet RFCs can be
downloaded from the RFC editor page at http://www.rfc-editor.org.

RFC-2557 MIME Encapsulation of Aggregate Documents, Such as HTML (MHTML)
This RFC describes how to construct a MIME multipart/related package, and how URLs
are resolved within content items of that package. RFC-2557 can be obtained at:
http://www.rfc-editor.org/rfc/rfc2557.txt
A MIME multipart/related package is made up of individual content items. Each
content item has a MIME header identifying the item. Each content item is delimited
from other content items using a string of application specified text. In addition, there
must be an ending boundary. The actual content is recorded between these delimiter
strings using a BASE-64 encoding of the content item. There is also a MIME header for
the entire package.
The first content item of a multipart/related message supporting attachments is the
CDA document, containing the header and structured or non-structured body.
Subsequent content items included in this package will contain additional content that
appears within the body of the document. The CDA document will reference these
additional content items by their URLs.

Referencing Supporting Files in Multipart/Related Messages
Because the CDA document and its supporting files may have already existed in a
clinical information system, references may already exist within the CDA document to
URLs that are not accessible outside of the clinical information system that created the
document. When the CDA document is sent via attachments, these URLs may no longer
be accessible by the receiving information system. Therefore, each content item that is
referenced by a URL within the CDA document must be included as a content item in
the MIME package. Each content item may specify the URL by which it is known using
the Content-Location header. The receiver of this MIME package shall translate URL
references according the RFC-2557. This will ensure resolution of the original URL to
the correct content item within the MIME package. Thus, URL references contained
HL7 Additional Information Specification Implementation Guide.
http://www.hl7.org/documentcenter/public/wg/ca/CDAR2AIS0000R030_ImplementationGuideDraft.pdf
11

within an original document need not be rewritten when the CDA package is
transmitted. Instead, these URLs are simply supplied as the value of the ContentLocation header in the MIME package.
This capability allows for the same content item to be referred to more than once in a
MIME multipart/related package without requiring the content item to be supplied
twice. However, it does not allow a separate MIME multipart/related package to contain
references to information sent in a previously recorded package.

Referencing Documents from Other Multiparts within the Same X12 Transactions
RFC-2392 is used when referencing content across MIME package boundaries, but still
contained within the same X12 transaction (ST to SE). This can occur when the same
document answers multiple questions for a single claim. Each component of a MIME
package may be assigned a content identifier using the Content-ID header for the
content item. For example, this header would appear as:
Content-ID: <07EE4DAC-76C4-4a98-967E-F6EF9667DED1>
This content identifier is a unique identifier for the content item, which means it must
never be used to refer to any other content item. RFC-2392 defines the cid: URL scheme
(http: and ftp: are two other URL schemes). This URL scheme allows for references by
the Content-ID header to be resolved. The URL for the content item identified above
would be:
cid:07EE4DAC-76C4-4a98-967E-F6EF9667DED1
Receivers of the MIME multipart message must be able to resolve a cid: URL to the
content item that it identifies. Senders must ensure that they only refer to items that
have already been transmitted to the receiver by their cid: URL. Thus, this
implementation guide prohibits forward URL references using the cid: URL scheme.
Content items shall not be referenced across X12 transactions using the cid: URL
scheme. For example, if the payer previously requested information using a 277, and
the provider returned that information in a MIME multipart/related package in a 275,
and then the payer requested additional information in another 277, the provider may
not refer to the content item previously returned in the prior 275 transaction.