CDAR2_IG_SUPPLEMENT_TO_IHE_CONSOL
Implementation Guide for CDA Release 2.0
Supplement to Consolidated CDA Templates
(US Realm)
DRAFT
September 2012
© 2012 Health Level Seven, Inc.
Ann Arbor, MI
All rights reserved.
Primary
Editor/
Co-Chair:
Jim McKinley
Blue Cross and Blue Shield of
Alabama
jbmckinley@bcbsal.org
Co-Editor:
Co-Editor/
Co-Chair:
Durwin Day
Co-Editor:
Co-Editor/
Co-Chair:
Craig Gabron
Co-Editor:
Co-Editor:
???
Technical
Editor:
???
???
NOTES FOR DISCUSSION WITH CO-CHAIRS

Should we include a different list of acceptable media types? We can use
CCDATG’s list, however it includes MS Word and we recall some reluctance to
include for attachments.
Value Set: SupportedFileFormats 2.16.840.1.113883.11.20.7.1 STATIC 20100512
Word Processing/Narrative Formats
Code
MSWord
application/msword*
PDF
application/pdf
Plain Text
text/plain
RTF Text
text/rtf
HTML
text/html
Graphic Formats
Code
GIF Image
image/gif
TIF Image
image/tiff
JPEG Image
image/jpeg
PNG Image
image/png

What about New Attachment Type acquisition?
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 2
Sept 2012
Acknowledgements
The writers and editors of this document want to acknowledge the years of hard work
and dedicated efforts of the current and past members of the Attachments Special
Interest Group (ASIG), the Structured Documents and Attachments Work Groups at HL7
in building forward the research and development needed to achieve the goal of
information exchange between the provider community and health plans/healthcare
insurance companies.
The information needs of the industry that were identified and developed over the years
became key input into the foundational content found in the CCDATG. This standard is
expected to be widely used in the exchange of clinical information between providers as
well as providers and patients in satisfying many exchange criteria established under the
Medicare/Medicaid EHR Incentive Program (aka, Meaningful Use).
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 3
Sept 2012
Table of Contents
1
PREFACE ....................................................................................................................... 7
1.1
2
INTRODUCTION .............................................................................................................. 8
2.1
Audience ................................................................................................................ 8
2.2
Purpose .................................................................................................................. 8
2.3
Scope ..................................................................................................................... 8
2.4
Approach................................................................................................................ 9
2.5
Organization of This Guide ..................................................................................... 9
2.6
Consolidated CDA Templated Guide (CCDATG) ....................................................... 9
2.7
Additional Attachment Information Requesting and Responding ............................ 10
2.7.1
Additional Attachment Information Request ...................................................... 12
2.7.2
Additional Attachment Information Response .................................................... 12
2.7.3
Solicited Reponse ............................................................................................. 13
2.7.4
Unsolicited Reponse ......................................................................................... 13
2.7.5
Understanding attachment activities ................................................................. 13
2.8
4
Definitions, Glossary and Acronyms ...................................................................... 15
2.8.1
Definitions ....................................................................................................... 15
2.8.2
Acronyms ......................................................................................................... 16
2.9
3
Revision History ..................................................................................................... 7
Health Level Seven Organization ........................................................................... 16
UNDERSTANDING CCDATG .......................................................................................... 17
3.1
What is Clinical Document Architecture (CDA)?..................................................... 17
3.2
Taking Advantage of Structured/Unstructured Content ......................................... 18
3.2.1
Structured Content .......................................................................................... 18
3.2.2
Unstructured Content ...................................................................................... 19
3.2.3
Mobile Devices? ................................................................................................ 19
3.2.4
Explanation of Levels 1, 2 and 3 ....................................................................... 19
3.3
What is CCDATG? ................................................................................................ 19
3.4
Human Readable and Computer Processable Content............................................ 20
ADDITIONAL INFORMATION (ATTACHMENTS) GENERAL .............................................. 22
4.1
Standards to accomplish information exchange of the request and response .......... 22
4.2
LOINC (Logical Observable Identifiable Names and Codes) ..................................... 22
4.2.1
LOINC Codes for Electronic Supporting Documentation .................................... 22
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 4
Sept 2012
4.2.2
LOINC Names and Identifiers ............................................................................ 25
4.2.3
The LOINC Committee ...................................................................................... 26
4.2.4
Obtaining the LOINC Database ......................................................................... 26
4.3
Requesting Attachment Information ...................................................................... 26
4.3.1
Using LOINC Code to request electronic documents .......................................... 26
4.3.2
Using “Modifiers” LOINC Code to constrain the request. .................................... 26
4.4
Responding with Attachment Information .............................................................. 27
4.5
Solicited and Unsolicited Attachment Information ................................................. 27
4.6
Using the LOINC Database to Identify Valid Attachment Types .............................. 27
4.7
ISO Object Identifiers (OID’s) ................................................................................ 27
5
ADDITIONAL INFORMATION (ATTACHMENTS)USE CASES ............................................ 29
6
IMPORTANT INFORMATION NOT ADDRESSED IN THIS SUPPLEMENT .......................... 30
6.1
7
STUBB ................................................................................................................. 31
OBTAINING NEW ATTACHMENT TYPES ........................................................................ 32
7.1.1
Placeholder language (if needed) ....................................................................... 34
APPENDIX A — USINESS REQUIREMENTS FOR TRANSPORT (ENVELOP) MESSAGE
OR TRANSACTION. ....................................................................................................... 36
APPENDIX B — BUSINESS REQUIREMENTS FOR REQUEST, RESPONSE AND
ACKNOWLEDGEMENT STANDARDS. ............................................................................ 37
APPENDIX C — ASC X12 STANDARDS THAT SATISFY THE BUSINESS
REQUIREMENTS LISTED IN APPENDIX A. .................................................................... 38
APPENDIX D —
PLACEHOLDER ........................................................................................ 39
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 5
Sept 2012
Table of Figures
Figure 1: Constraints format example ................................................................................... 33
Table of Tables
No table of figures entries found.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 6
Sept 2012
1
PREFACE
1.1 Revision History
The following provides a historical view of the iterations for this document and why each major
revision was made.
Date
September 2012
Purpose
Version 1.0
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 7
Sept 2012
2
INTRODUCTION
This guide is intended to be used in conjunction with the Consolidated CDA Templated
Guide (CCDATG) to describe to HealthCare industry stakeholders how to implement
components of the CCDATG for the purposes described in this guide in section 2.2
below.
2.1
Audience
The audiences for this implementation supplement are the architects, developers and
implementors responsible for the exchange of supporting/attachment information
between a provider and a healthcare entity such as a health plan or a health insurance
company (hereafter known as ‘payers’).
2.2
Purpose
This guide is intended to be used as a supplement to the CCDATG. It endeavors to
provide guidance to implementors as they exchange “supporting information” typically
needed by payers from providers.
Examples of healthcare activities requiring this supporting information include but are
not limited too additional information:
 In support of a healthcare claim or encounter
 In support of healthcare services review (e.g., Prior authorizations/precertifications, referrals)
 Needed for post adjudicated claim audits
For the purposes of this supplement, healthcare “supporting/attachment information”
will be referred too as “Attachments”.
Attachments are a means of electronically exchanging supporting information to
augment each of the examples above. The ultimate goal of Attachments
standardization in providing structured, standardized electronic data is to enable the
fully automated exchange and processing of supplemental information in the various
health care activities shown above. While some processes will always require human
intervention, use of fully structured attachments may significantly reduce human
intervention and turnaround time for adjudication or resolution.
2.3
Scope
This supplement is limited in scope to those functions which support the exchange of
healthcare information between providers and payers in support of administrative
business functions of both as identied in section 2.2 of this supplement.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 8
Sept 2012
2.4
Approach
INFORMATION SHOULD BE INSERTED HERE REGARDING THE INDUSTRY
OUTREACH TO DEVELOP THE ATTACHMENTS CONTENT TO DATE.
The Attachments Work Group (AWG) at HL7 had been developing the needed
supporting information content for the purposes of claims attachments ever since the
HIPAA Transactions and Codeset regulations were implemented. As well, they had
spent many of those years writing additional information specifications focused to that
end.
With the advent of “Meaningful Use” and its clinical document exchange requirements
between providers and other legally permitted entities, along with it’s similarity to the
business model for clinical document exchange previously described in the Attachments
model, a re-assessment of the attachments model was undertaken. It revealed that the
CCDATG was going to be the standard for this exchange, and that the content found in
the CCDATG was largely consistent with that needed for Attachments purposes.
After much discussion, the AWG decided that it just did not make sense for providers
and/or their vendors to have multiple formats for this exchange based on who the
recipient was. Rather than having one standard format for the provider-to-provider
information exchange and another (the additional information specifications) for
provider-to-payer information exchange, the AWG agreed to adapt their approach to
leverage and be consistent with that of the CCDATG with respect to formatting of
clinical documentation.
Next, the AWG set about making a comparison of the content found in the CCDATG and
that found in the additional information specifications, which was the original
Attachments specifications that were initially developed. Supporting information found
in the additional information specifications needed for purposes described in section 2.2
and not already in the CCDATG was identified and passed to the Structured Document
Work Group for inclusion into the CCDATG. Information found in the CCDATG but
not in the additional information specifications was evaluated and found to be
acceptable for the purposes of claims attachments.
The result was information from the original additional information specifications being
added to the CCDATG. Because CCDATG was intended to have a broad industry
footprint, it did not make sense to include any information specific to implementations
as described in section 2.2, hence the reason this supplement being prepared.
2.5
Organization of This Guide
PLACE HOLDER (complete when guide finalized)
2.6
Consolidated CDA Templated Guide (CCDATG)
FILL IN INFORMATION ABOUT “WHY” CCDATG, OVERALL CONTENT (8 structured, 1
unstructured), ETC.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 9
Sept 2012
2.7
Additional Attachment Information Requesting and Responding
Typically, in the course of doing business payers occasionally will need additional
information from a provider to determine if the level of service being performed or
requested is consistent with the patients insurance benefits. As well, payers have
general medical policies established that also must be checked for consistency with the
patients insurance benefits. There must be a consistent method for requesting the
additional information from the provider, and one for the provider to respond with or
convey this information to the payer.
The request of attachments information is always triggered by a business event of
some kind which involves the recognition/awareness of the need for additional
information. That triggering event may happen in a variety of ways and may occur in
electronic or non-electronic form. Examples include, but are not lmited too, the
following:
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 10
Sept 2012
Table 01: Attachments Activity Table
Business Event
Triggering Request
Request
Response
Business
Description
Event
Type
Type
Case Type
Electronic
Electronic
Solicited
A payers receipt of a
claim that requires
additional information
prior to adjudication.
A payers receipt of a
claim that requires
additional information
prior to adjudication.
The receipt of the claim
needing additional
information
The receipt of the claim
needing additional
Electronic
information
Non-
Out of
electronic
Scope1
Electronic
Unsolicited
Electronic
Unsolicited
Electronic
Unsolicited
A payers medical policy
requirements/rules
The providers
where the providers
awareness that
knows at the time of the
additional information
claim billing that they
is required when
must provide additional
submitting a certain
information with the
type of claim.
Nonelectronic
billing
A payers medical policy
requirements/rules
where the provider
knows in advance they
must provide additional
information to the payer
before rendering the
service or delivering the
supply/product to the
patient without using an
The providers decision
to render a service or
deliver a
supply/product to the
Non-
patient for which they
electronic
knew a payer
requirement/rule
existed
electronic request
A payer and provider
mutually agree at any
Anything from a phone
time to provide
conversation, a postal
additional information
letter, patient
without using an
communication, etc
Nonelectronic
electronic request
It is important to note that in all cases the request for additional attachment
information comes in one of two forms, electronic or non-electronic. This supplement
takes no position regarding the requirement to use electronic requests or responses,
rather it simply addresses how to accomplish the information exchange when electronic
requests or responses are used.
1
This is out of scope because this supplement only addresses scenario’s involving electronic responses.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 11
Sept 2012
For the purposes of this supplement, we will use the terms “Solicited” and “Unsolicited”
to help clarify the scenarios (business cases) for which one or more standards are to be
used. A response, whether Solicited or Unsolicited, refers to the act of providing
additional attachment information needed.
A Solicited Response is in response to an electronic request. An Unsolicited Response
is in response to a non-electronic request. In both the Solicited and Unsolicited
scenarios, the primary differentiator is whether an electronic standard request was
what triggered the response, where Solicited is triggered and unsolicited is not triggered
by an electronic standard request.
Scenario
Request mechanism
Response Mechanism
N/A (Not in Scope)
Non-electronic
Non-electronic
Unsolicited
Non-electronic
Electronic
Solicited
Electronic
Non-electronic
Solicited
Electronic
Electronic
NPRM LANGUAGE
In general, health care providers will submit their electronic health care claims attachment information to the health plan for
certain claim types, upon request, after the health plan has received and reviewed the claim. This follows the course of claims
adjudication today.
Health plans may also request, in advance, that additional documentation (the attachment) accompany a certain type of claim for
a specific health care provider, procedure, or service. The ASIG refers to this scenario, of sending attachment information with
the initial claim, as an unsolicited attachment because a request was not made after the fact, using the standard request
transaction.
We are proposing that health care providers may submit an unsolicited electronic attachment with a claim only when a health
plan has given them specific advance instructions pertaining to that type of claim or service.
We are proposing such a restriction around ‘‘unsolicited’’ electronic attachments, because we believe that there are legal,
business, and technical implications for health care providers, health plans, and their business associates for handling and
processing unsolicited attachments without prior direction. If health care providers were permitted to submit unsolicited
electronic attachments with any claim without prior arrangement with the health plan, there would be a number of issues,
including compliance with the Privacy Rule’s minimum necessary standards, and identifying the new business and technical
procedures health plans would need to develop to review, evaluate, store, return, or destroy the unsolicited documents.
Similarly, health care providers would need systems and processes to track submissions and returns.
2.7.1 Additional Attachment Information Request

Additional attachment information requested by an originator and requested of an
information source
2.7.2 Additional Attachment Information Response

Additional attachment information responded with from the information source
back to the request originator
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 12
Sept 2012
2.7.3 Solicited Reponse

a response from one party to another for additional information to a Solicited
Request
2.7.4 Unsolicited Reponse

additional information provided from one party to another based on a rule
(condition/parameter) being met, where that rule was mutually agreed upon by the
two parties well in advance of the event, such as a claim or prior authorization
2.7.5 Understanding attachment activities
Because this supplement addresses all facets of the process in requesting of and
responding with attachments information, and because the actors role will vary
depending on the activity type, a table has been developed to help better understand
these activities. Each row in the table represents a unique attachment activity that
would require a unique business flow to describe the activity. As well, each row will
call for a unique set of electronic standards to be used for each.
As described later in Section 4.1 of this supplement, there are multiple standards
available in the industry to accomplish the exchange of information for attachment
purposes (i.e., request, response, acknowledgement, etc). For the purpuses of this
supplement and the anticipated attachments regulation, example scenarios and use
cases will reference those ASC X12 standards previously developed to accomplish
attachments information exchange.
Table 02 (Attachments Activity Table) below describes all scenarios addressed by this
supplement for attachment exchange purposes. Column headings and table values are
described below:

Business Need – The need of the originating actor for the ‘request’ activity type
within the Business Need entry

Activity ID – A symbolic ID used to express, in abrieviated form, the attachment
activity. (NOTE: This ID will be used to uniquely determine the standard(s)
necessary to accomplish the attachments activity described in the row of the table)

Activity Type – Describes the type of activity of the originating actor

o
Request – electronically requested attachment information
o
Response – attachment information provided in response to an electronic
request
o
“Requested in Advance” Response – attachment information provided in
response to an “advance” non-electronic request for attachment information
typically based on a “rules based” request (i.e., mutually known rules, policy
or guidelines).
Basis for Activity
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 13
Sept 2012

o
Solicited – attachments information that is electronically requested or the
response to a electronic request.
o
Unsolicited – attachments information provided from the originator to the
receiver based ONLY on an “rules based” request and in the absence of an
electronic request. It is important to understand that an “rules based”
request is not in scope for this supplement since it is typically known to the
receiver and not in electronic form. This is NOT meant to imply that
attachment information should ever be exchanged without some form of a
request.
Actor
o
Originator – the actor originating or initiating the attachments activity
o
Receiver – the actor receiving the attachments activity
Table 02: Attachments Activity Table2
Basis for Activity
Business Need
Claims
Attachment
Prior Auth
Attachment
Referral
Attachment
Activity
ID
Originator
Activity Type
#1
#2
Request
Response
“Requested in
Advance”
Response
Request
Response
“Requested in
Advance”
Response
X
X
#7
Request
X
#8
Response
X
#9
“Requested in
Advance”
Response
#3
#4
#5
#6
Solicited
Unsolicited
Actor
Originator
Receiver
Payer
Provider
Provider
Payer
Provider
Payer
Payer
Provider
Provider
Payer
Provider
Payer
Referred to
provider
Referred
from provider
Referred from
provider
Referred to
provider
Referred
from provider
Referred to
provider
X
X
X
X
X
To better understand the relationship of the row values for each attachment activity, a
“table interpretation template” was developed:
Table interpretation template:
Activity “Activity ID” represents the information exchange for the “business need”
“Solicited / Unsolicited” “Originator Activity Type” for additional information from
the “Originator” to the “receiver”.
For the purposes of this supplement, assumes all Originators Activity Types are electronic and that
Activity ID’s 1&2, 4&5, and 7&8 are done in pairs
2
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 14
Sept 2012
By substituting the row values found for each of the heading column identified in
“BOLD” type, a high level use case description can be created. The following examples
are derived from the table using the template above:

Activity #1 represents the information exchange for the Claims Attachment Solicited
request for additional information from the payer to the provider

Activity #2 represents the information exchange for the Claims Attachment Solicited
response for additional information from the provider to the payer

Activity #3 represents the information exchange for the Claims Attachment
unsolicited “requested in advance” response for additional information from the
provider to the payer

Activity #4 represents the information exchange for the prior auth attachment
solicited request for additional information from the payer to the provider.

Activity #5 represents the information exchange for the prior auth attachment
solicited response for additional information from the provider to the payer.

Activity #6 represents the information exchange for the Prior Auth attachment
unsolicited “requested in advance” response for additional information from the
provider to the payer.

Activity #7 represents the information exchange for the Referral Attachment
solicited request for additional information from the referred to provider to the
referred from provider.

Activity #8 represents the information exchange for the Referral Attachment
solicited response for additional information from the referred from provider to the
referred to provider.

Activity #9 represents the information exchange for the referral attachment
unsolicited “requested in advance” response for additional information from the
referred from provider to the referred to provider.
The purpose of doing this will be to allow for standards correlation to each of the
activity ID’s with a current X12 standard….and later, if regulation expands to include it,
other standards like IHE Profiles, HL7 Messaging Standards, etc.
2.8
Definitions, Glossary and Acronyms
2.8.1 Definitions
Attachment Document. The CDA document that is part of an Attachment Package.
Attachment Package. The combination of a CDA document and any adjunct files (e.g., images) that are
transmitted together in fulfillment of an administrative transaction (e.g., included in the BGN segment of
an ASC X12 275 transaction as transmitted from a provider to a payer). For HIPAA, the Attachment
Package defines the full requirements of the required administrative transaction.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 15
Sept 2012
Computer-decision variant. An instance of a CDA attachment with enough structure and coding so
that it can be rendered with detailed data suitable for a computer decision algorithm. Attachments in the
computer-decision variant can also be rendered so that a person can make a decision based on its
contents. Contrast with human-decision variant.
Human-decision variant. An instance of a CDA attachment intended solely for rendering so that a
person can make a decision based on its contents. Contrast with computer-decision variant.
Object Identifier (OID). An ISO Object Identifier (OID) is a globally unique string consisting of
numbers and dots (e.g., 2.16.840.1.113883.3.1). This string expresses a tree data structure, with the leftmost number representing the root and the right-most number representing a leaf.
2.8.2 Acronyms
To aid the implementer, this section will restate any acronyms used in this supplements
in one common place.
2.9

CCDATG

Attachments

Payer
Health Level Seven Organization
Founded in 1987, Health Level Seven, Inc. (http://www.HL7.org) is a not-for-profit,
ANSI-accredited standards developing organization dedicated to providing a
comprehensive framework and related standards for the exchange, integration, sharing,
and retrieval of electronic health information that supports clinical practice and the
management, delivery and evaluation of health services.
HL7 complements ASC X12 in that its interests have been to support the clinical
processes, whereas Task Group 2, X12N (the Healthcare Task Group of the Insurance
Subcommittee of X12) focuses on administrative and financial processes within
healthcare.
For information on membership and obtaining HL7 standards, contact:
Health Level Seven
3300 Washtenaw Ave., Suite 227
Ann Arbor, MI 48104-4261
(734) 677-7777
mailto:hq@hl7.org
http://www.hl7.org
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 16
Sept 2012
3
UNDERSTANDING CCDATG
This Section will explain the CCDATG at a high level. Implementers should rely on the
detail found in the CCDATG itself to provide guidance as to how to utilize that
Standard. Below you will find the basics of CCDATG.
3.1
What is Clinical Document Architecture (CDA)?
CDA is a document markup standard that specifies the structure and semantics of a
clinical document (such as a discharge summary or progress note) for the purpose of
exchange. A CDA document is a defined and complete information object that can
include text, images, sounds, and other multimedia content.
It can be transferred within a message and can exist independently, outside the
transferring message. CDA documents are encoded in Extensible Markup Language
(XML), and they derive their machine processable meaning from the RIM (HL7’s
Reference Information Model), coupled with terminology.
The CDA R2 model is richly expressive, enabling the formal representation of clinical
statements (such as observations, medication administrations, and adverse events)
such that they can be interpreted and acted upon by a computer. On the other hand,
CDA R2 offers a low bar for adoption, providing a mechanism for simply wrapping a
non-XML document with the CDA header or for creating a document with a structured
header and sections containing only narrative content.
The intent is to facilitate widespread adoption, while providing a mechanism for
incremental semantic interoperability.
A CDA document has two primary groupings of information, a header and a body:

The header
o

Identifies and classifies the document and provides information on
authentication, the encounter, the patient, and the involved providers.
The body
o
Contains the clinical report, organized into sections whose narrative content
can be encoded using standard vocabularies.
o
Can be represented using a nonXMLBody or a structuredBody element.

nonXMLBody is used when the content is an external file such as a
TIFF image, MS RTF document, etc. The NonXMLBody class is
provided for those applications that can do no more than simply wrap
an existing non-XML document with the CDA Header.

structuredBody is used when the body will be XML structured
content. XML structured content is always inserted into the
structuredBody element, never as an external file. The
StructuredBody contains one or more Section components.
For the purposes of this supplement:
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 17
Sept 2012

A header paired with a structuredBody element will be referred too as a
“Structured Document”.

A header paired with a nonXMLBody will be referred too as an “Unstructured
Document”3.
More information about CDA can be found on the HL7 website (www.hl7.org).
3.2
Taking Advantage of Structured/Unstructured Content
Use of the CDA standard allows for a wide-range of implementation flexibility with
respect to the implementors (CDA originator and consumer) technical abilities.
For the most novice of implementations, in most cases a CDA document may simply be
rendered to a common internet XML aware brower using an XSL style sheet4, much like
one might view a PDF on a personal computer application. Even an unstructured
document may be rendered using a style sheet. The exception to this would be an
Unstructured Document where the body content contained a media type (i.e., JPEG,
GIF, PDF, etc) that would require additional software to interpret and render this
encapsulated data.
For move advanced implementations, that same CDA document may have its contents
examined and discrete information extracted and be made available for computer
usage/processing.
The approach of using a style sheet to render a CDA document to a browser sets a low
bar for originator and receiver of a CDA document. No matter what the technical level
of the originator, the receiver will have the choice of leveraging the originators highest
level of technical sophistication or simply chose to render using a browser. This may
help the payers initially as they aren’t as familiar with CDA as the provider community
is.
Initially the limited capability of participants to support fully structured attachments
and the need for further development of attachment content requires the use of the
unstructured content capability of the CCDATG. For attachment purposes, even
though a structured document format is defined in CCDATG, the use of the
unstructured document option for those same document types defined in structured
content is not expressly prohibited, provided that the required content defined for the
structured document content is present in the unstructured document representation.
3.2.1 Structured Content

Must follow conformance statements found in CCDATG.
Is is important to note that header in either structured or unstructured scenarios is always considered
structured and as such, available for computer processing to occur with it’s content.
3
The stylesheet provided by HL7 in the CCDATG is not required to be used by the implementer, instead
the implementer may choose to create their own customized stylesheet to render the information to a
browser.
4
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 18
Sept 2012
3.2.2 Unstructured Content

Must be limited to document types defined on Regenstrief database tab (XXX).

May include document content for document types already defined in CCDATG
as structured, but unstructured content must adhere to conformance
statements described in the structured content.

If the request was for sub-document level information (section or entry), the
unstructured format may be used for that section or entry. In this case,
conformance criteria for a given section or entry may or may not be identical
within structured documents those sections or entries are found. In this case,
conformance requirements would all be considered as optional with the
expectation that if the responder has the information that they should include it.
3.2.3 Mobile Devices?
????
3.2.4 Explanation of Levels 1, 2 and 3
????
3.3
What is CCDATG?
CCDATG is a guide defining clinical information format based on CDA, constrained by
conformance statements consistent with industry best practices for specific types of
clinical documents. Some broadly used document types have been more fully developed
in CDA than others. Examples of those document types include:
o
CCD
o
Consultation Note
o
Diagnostic Imaging Report
o
Discharge Summary
o
History and Physical
o
Operative Note
o
Procedure Note
o
Progress Note
Other clinical information not listed above may be also exchanged using CCDATG by
taking advantage of the unstructured content section, as described in Section 3.9 of the
CCDATG.
Throughout the CCDATG implementors will see references to sending and receiving
EHR systems. This is because the CCDATG was written from the perspective of
exchange between EHR systems. For the purposes of this supplment there is no
assumption that exchange will occur between 2 EHR systems. Instead, as you will see
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 19
Sept 2012
in the use case section (section ?.?) the additional information a payer is seeking may
exist in an providers electronic repository, such as an EHR system and may/maynot be
passed through a practice management system or be sourced directly from the EHR.
Section 1.5 of the CCDATG describes at a high level how templates are used to
represent the organization of CDA structure in a document. Metadata found in the
Header as well as specific clinical information found in the Body components as
Documents, Sections within those documents, and entries within those sections are
explained are described in sections 3.1 through 3.8 of the CCDATG.
3.4
Human Readable and Computer Processable Content
There are two variants of a CDA document when used as an attachment. These are as
follows:
The human-decision variant (HDV) is used solely for information that will be rendered
for a person to look at, in order to make a decision. HL7 provides a non-normative style
sheet for this purpose. The HDV is not required to have structured or coded answers.
The only LOINC value used in an HDV CDA document is the LOINC for the Attachment
Type Identifier. There are two further alternatives within the human-decision variant.
It can be a single <nonXMLBody> (e.g., an image or scanned image) element that is
embedded in the transaction or is a reference to an external file that provides the
content for the body of the document, or
It can contain a <structuredBody> element containing free text in XML elements that
organize the material into sections, paragraphs, tables and lists as described in the
subsequent sections of this document.
The computer-decision variant (CDV) has the same content as the human-decision
variant, but additional structured information and LOINC coded data is included so
that a computer could provide decision support based on the document. Attachments in
the CDV can be rendered for human decisions using the same style sheet that HL7
provides for rendering documents formatted according to the human-decision variant.
These variants do not differ in functional content. All variants of the same attachment
have required and optional content as specified in the Additional Information
Specification document for that attachment. The variants only differ with regard to
whether structured and coded data is mandated.
Both variants place constraints upon what information must be present in the CDA to
support the Attachment use case, described in Section 1.1 of each AIS document.
Additional CDA structures (document sections, entries, etc.), may be present to support
use cases other than those defined by this implementation guide. Anything not
explicitly prohibited by the AIS may be present in the CDA document to support use
cases other than those defined therein.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 20
Sept 2012
HL7 has provided one or more XML stylesheets as part of this implementation package;
however, these are neither balloted standards, nor are they required for use under
HIPAA. Use of HL7 provided stylesheets is entirely up to the implementer.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 21
Sept 2012
4
ADDITIONAL INFORMATION (ATTACHMENTS)
GENERAL
In general, the attachments request/response from between the provider and the payer
will be using a standard not developed by HL7 nor included in either this document or
the CCDATG. Business requirements of that standard will be specified in Appendix
“A”.
4.1
Standards to accomplish information exchange of the request
and response
The authors of this supplement realize that there may be more than one standard that
could accomplish the information exchange. They further acknowledge the
development of a full suite of standard transactions was developed by ASC X12
specifically for the requesting additional information, responding to that request, and
acknowledgment of either/both and conforming to the business requirements found in
Appendix “A”. Additional information regarding those transactions can be found in
Appendix “B” of this document.
For the purposes of this document, references to requests and responses to requests in
examples and/or use cases will include a reference to the specific ASC X12 transaction
that could be used5.
4.2
LOINC (Logical Observable Identifiable Names and Codes)
4.2.1 LOINC Codes for Electronic Supporting Documentation
LOINC codes are used to identify:
The implicit scope of a request in an ASC X12 277 transaction; e.g., to modify a request
for serology lab values to specify only the abnormal results for a period 30 days prior to
treatment, as a Modifier Code.
An electronic attachment in its entirety (e.g., a request for the Ambulance attachment in
support of a claim for ambulance services), as an Attachment Type Identifier.
A category of clinical report (e.g., send any reports of CAT scans of the head that are
related to the claim or a specific service), as an Attachment Type Identifier appearing
in the CDA Header.
One or more Attachment Components of an electronic attachment (e.g., a request for
the number of miles that the ambulance drove in support of a claim for ambulance
services).
It is anticipated that regulations for HIPAA Attachments will initially mandate the use of these ASC X12
Standards found in Appendix “A”. This supplement is written in a manner that will permit other
standards as the industry matures.
5
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 22
Sept 2012
A part or parts of a clinical report (e.g., the impression section of a radiology report in
support of a claim or a specific service), as the Attachment Component identifier
appearing in the <code> of the <section> in the CDA document.
A category of laboratory results (e.g., hematology results that are related to the claim or
a specific service), as the Attachment Component identifier appearing in the <code> of
the <section> in the CDA document.
A category of medication information (e.g., send the discharge medications that are
related to the claim or a specific service), as the Attachment Component identifier
appearing in the <code> of the <section> in the CDA document.
One of a set of observations that compose a single attachment component (e.g., in an
obstetrical study, one code identifies number of prior births, and another distinct code
provides the estimated date of delivery), as an Attachment Component Answer Part.
LOINC codes used in Additional Information Specifications are obtained by the HL7
ASIG attachment workgroup that developed the content for the specific attachment.
Table 4.2-1 below describes briefly the use of LOINC in the various attachment
components.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 23
Sept 2012
Table 4.2-1 Use of LOINC Codes, ASC X12 Transactions, and HL7 CDA Documents
ASC X12 277/278
Purpose of
Attachment
LOINC
Modifier
Codes
LOINC
Attachment
Type
Identifier
LOINC
Attachment
Component
LOINC
Attachment
Component
Answer Part
ASC X12 275
Additional
to
Request for additional information
information to support a support a health
health care claim OR care
claim
or
encounter
OR
Services Review
Services Review
Used in the STC segment
of the 277 or HI segment
of the 278 to limit the
scope or time frame of a
request for information.
e.g.,
 Send information for
up to 90 days before the
related encounter
Used in the STC
segment of the 277 or
HI segment of the 278
to request an attachment
in its entirety, e.g.,
 Send the cardiac
rehabilitation treatment
plan
Used in the STC
segment of the 277 or
the HI segment of the
278 to request a specific
attachment component
or part of a clinical
report, .e.g.,
 Send the rehab
treatment plan author
Not used in the 277
HL7 CDA
Provide controlled content
for ASC X12 275 BIN
segment
Reiterated in the STC
segment
Not used in the CDA
document
Reiterated in the
STC segment in
solicited method
Used in the <code> element
in the header of the CDA
document, e.g.
This is the cardiac
rehabilitation attachment
Reiterated in the
STC segment in
solicited method
Not used in the 275
Used in the computerdecision CDA variant in the
<code> element of a
<section> to identify the
attachment component
being provided, e.g.,
This is the diagnosis
information
Used in the computerdecision CDA variant in the
<code> element of a clinical
statement in an <entry> or
<section>, to identify the
answer part of an
attachment component
being provided, e.g.,
This is the name, identifier
and taxonomy
The 275 must repeat the LOINC codes used in the STC segment of the 277 or the HI
segment of the 278, but the heading of the CDA document need not. While LOINC
Codes are used for questions, answers, and document classification, the queries posed
by a LOINC code may be either more specific or more general than the LOINC codes
organizations use to classify clinical documents.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 24
Sept 2012
4.2.2 LOINC Names and Identifiers
Each LOINC record corresponds to a component. The LOINC record is a table entry in
the LOINC database maintained by the Regenstrief Institute and the LOINC Committee.
See section 4.2.4 for information on how to obtain the LOINC database. A LOINC
record includes attributes to specify:
The numeric code that identifies the component,
The component name — e.g., potassium, hepatitis C antigen, distance the patient was
transported (by an ambulance)
The property reported — e.g., a mass concentration, length (distance)
The time aspect — e.g., Whether the measurement is a momentary observation at a
point in time, or an observation made over a span of time
The source of the data used in the reported information — e.g., urine, blood, EMS
transport
The type of scale — e.g., whether the measurement is quantitative (a true
measurement), nominal (red, blue, green), or simply narrative text providing the
requested information
Where relevant, the method used to produce the result or other observation
A class code that associates the observation with others in a group, such as the
observations associated with an obstetric ultrasound procedure
Many medical concepts have multiple LOINC codes. The codes distinguish different
methods of making the observation. For example, there are different LOINC codes for
manual and automated leukocyte counts. Indeed, there are three codes for the patient’s
body weight according to whether it was measured, estimated, or the datum is the
weight that the patient reported.
Different LOINC codes are also used to distinguish different ways to report the
observation. For example, 10221-0 identifies the specimens taken during surgery when
reported using narrative text, whereas 8721-3 would identify coded descriptions of the
same specimens.
LOINC codes may also identify sets of observations. For example, the LOINC code
18674-2 (ALCOHOL-SUBSTANCE ABUSE REHABILITATION TREATMENT PLAN,
LONGEST PERIOD OF SOBRIETY FOR ABUSED SUBSTANCE) identifies a set of other
observations, identified by other LOINC codes, including 18676-7 (ALCOHOLSUBSTANCE ABUSE REHABILITATION TREATMENT PLAN, LONGEST PERIOD OF
SOBRIETY), and 18675-9 (ALCOHOL-SUBSTANCE ABUSE REHABILITATION
TREATMENT PLAN, ABUSED SUBSTANCE).
The LOINC codes are not intended to transmit all possible information about a test or
observation. They are only intended to identify the observation. The LOINC code for a
name is unique and permanent. The LOINC code has no intrinsic structure except that
the last character in the code is a mod-10 check digit.
LOINC codes must always be transmitted without leading zeroes and with a
hyphen before the check digit (e.g., "8709-8" and "10154-3").
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 25
Sept 2012
The LOINC Committee assigns LOINC codes upon request from various agencies. In the
context of attachments, the LOINC codes are obtained by the HL7 ASIG. The ASIG
forwards appropriate requests to the LOINC committee for consideration. Requests go
through a review process to ensure the concept has not been previously added and the
meaning is clear.
4.2.3 The LOINC Committee
LOINC is a committee of laboratories, system vendors, hospitals and
academic institutions organized by the Regenstrief Institute and supported
by grants from The John A. Hartford Foundation, Inc., the Agency for Health
Policy Research and Development and The National Library of Medicine to
create formal names and codes for laboratory results and clinical variables
with numeric, coded, or narrative text values. The LOINC codes were
designed specifically to provide a universal identifier for clinical
observations. It has since been adopted by DICOM as well. For identifying
observations in these "messages," the LOINC Committee distributes the over
50,000-record database and the Regenstrief LOINC Mapping Assistant
(RELMA) software for perpetual use free via the Internet. Widespread use
of LOINC will enable better and more efficient use of computer-stored
clinical data.
4.2.4 Obtaining the LOINC Database
LOINC codes are registered by Regenstrief Institute and the Logical Observation
Identifier Names and Codes (LOINC) Committee.
The LOINC database provides sets of universal names and ID codes for identifying
laboratory and clinical test results and other units of information meaningful in
attachments such as clinical report documents.
The LOINC database can be obtained from the Regenstrief Institute at
http://www.LOINC.org.
4.3
Requesting Attachment Information
4.3.1 Using LOINC Code to request electronic documents
????
Sender/receiver
4.3.2 Using “Modifiers” LOINC Code to constrain the request.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 26
Sept 2012
4.4
Responding with Attachment Information
4.5
Solicited and Unsolicited Attachment Information
4.6
Using the LOINC Database to Identify Valid Attachment Types
4.7
ISO Object Identifiers (OID’s)
OID is an acronym, used throughout HL7 specifications to mean ISO object identifier.
ISO is the International Organization for Standardization (http://www.iso.ch), and we
will see below that the International Telecommunications Union (ITU,
http://www.itu.int) is also relevant. The HL7 OID registry, mentioned below, can be
used to find, or create, OIDs for use in attachment implementations; and the mention of
ISO and ITU is for background information only.
The CDA uses OIDs to uniquely specify where to find more information regarding a
coded data value or an identifier for a person, organization, or other entity.
An OID is a globally unique string consisting of numbers and dots (e.g.,
2.16.840.1.113883.6.103). This string expresses a tree data structure, with the leftmost number representing the root and the right-most number representing a leaf.
Each branch under the root corresponds to an assigning authority. Each of these
assigning authorities may, in turn, designate its own set of assigning authorities that
work under its auspices, and so on down the line. Eventually, one of these authorities
assigns a unique (to it as an assigning authority) number that corresponds to a leaf
node on the tree. The leaf may represent an assigning authority (in which case the @S
attribute identifies the authority), or an instance of an object. An assigning authority
owns a namespace, consisting of its sub-tree.
Although OIDs look very obscure at first, they present a systematic way to identify the
organization responsible for issuing a code or entity identifier. HL7 is an assigning
authority, and has the OID prefix "2.16.840.1.113883." Any OID that begins with this
is further described by a registry maintained by the HL7 organization. For example, the
OID 2.16.840.1.113883.6.103 (above) was established by HL7 as a globally unique
identifier for the ICD-9-CM code set for diagnoses.
The numbers in the HL7 OID prefix "2.16.840.1.113883." indicate that:
The OID was assigned by a joint ISO-ITU (2.) assigning authority,
it is specific to the country (16.)
of the USA (840.)
and is specific to the organization (1.)
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 27
Sept 2012
known as Health Level Seven (113883.).
Beyond that, the HL7 organization assigns any numbers - and these are maintained in
a registry available on the HL7.org website. HL7 uses its registry to assign OIDs within
its branch for HL7 users and vendors upon their request. HL7 is also assigning OIDs to
public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver
license bureaus, U.S. Social Security Administration, US National Provider Identifier
(NPI) registry, etc.) and internationally (e.g., other countries' social security
administrations, citizen ID registries, etc.)
Additional reference information about OIDs, including the current directory of OIDs
assigned by HL7, is available at http://www.hl7.org/oid/index.cfm. Organizations
that wish to request an OID for their own use (e.g., to be able to create identifiers within
a CDA document), may also obtain one from HL7 at this site.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 28
Sept 2012
5
ADDITIONAL INFORMATION (ATTACHMENTS)USE
CASES
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 29
Sept 2012
6
IMPORTANT INFORMATION NOT ADDRESSED IN THIS
SUPPLEMENT
In Chapter 5, use cases are presented describing anticipated scenarios depicting
attachment activities. While business rules are not included in those scenarios, the
authors of this supplement believe there are some industry “best practices” that
enhance the attachment activity, and may be addressed in mutual trading partner
agreements, companion guides, operating rules or regulations.
Examples of these business rules include, but are not limited to the following:
1. The CCDATG offers specific document types in structured form along with
document types suitable for unstructured format. The unstructured format should
never be construed to include the patients entire medical record, unless specifically
asked for in the request activity.
2. Timeliness considerations for responses to requests for attachment information may
be unique to the stakeholders needs, scenario’s, etc., and establishing standard
timeliness guidance should be avoided. However, establishing reasonable
expectations minimum and maximum time between request and response may be
appropriate.
a. For solicited requests, consideration should be given to the request envelop
including a “respond-by” date for the response to be completed on or before
that date to successfully complete the attachment activity.
b. For unsolicited requests, policy should be developed to guide payers in
claims and prior auth attachment activities and providers in referral
attachment activities what to do if the attachment is received but the claim,
prior auth or referral never arrives and/or cannot be re-associated with the
claim, prior auth or referral itself.
c. Guidance should be developed to communicate the ‘in advance’ payer rules
for unsolicited attachment activity, which may include payers publishing on
their provider web-sites information or other routine provider
communications.
d. Proactively defined criteria and situations should be identified where nonconformance with ‘in advance’ rules for unsolicited attachment activity could
result in a HIPAA disclosure violation. Examples could include a response
attachment activity that exceeded the request (patient complete medical
record) or response attachment activity not consistent with ‘in advance’
rules.
3. Attachment information, by default, is considered at the clinical document level. In
some cases, the requestor of attachment information may be needing information at
the sub-document level (section or entry). In this case, development of guidance
based on scenarios may be helpful to identify the most appropriate document type
to request the needed information. Absent that guidance, it would be up to the
requestor of attachment information to determine the most appropriate document
type to request it.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 30
Sept 2012
4. Use of the unstructured document
6.1
STUBB
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 31
Sept 2012
7
OBTAINING NEW ATTACHMENT TYPES
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 32
Sept 2012
Figure 1: STUBBED IN EXAMPLE ONLY
Severity Observation
[observation: templateId 2.16.840.1.113883.10.20.22.4.8(open)]
Table xxx: Severity Observation Contexts
Used By:
Contains Entries:
Reaction Observation
Allergy Observation
This clinical statement represents the severity of the reaction to an agent. A person may
manifest many symptoms …
Table yyy: Severity Observation Contexts
Name
XPath
Green
Severity
Observation
observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.8']
severity
Coded
Verb
Data
Type
CONF#
Fixed Value
@classCode
1..1
SHALL
7345
2.16.840.1.113883.5.6
(HL7ActClass) = OBS
@moodCode
1..1
SHALL
7346
2.16.840.1.113883.5.1001
(ActMood) = EVN
templateId
1..1
SHALL
1..1
SHALL
code
1..1
SHALL
text
0..1
SHOULD
reference
/@value
0..1
SHOULD
statusCode
1..1
SHALL
CS
7352
2.16.840.1.113883.5.14 (ActStatus)
= completed
value
1..1
SHALL
CD
7356
2.16.840.1.113883.3.88.12.3221.6.8
(Problem Severity)
0..*
SHOULD
CE
9117
0..1
SHOULD
CE
9118
@root
severity
FreeText
Card.
interpretation
Code
code
SET<II>
7347
10525
2.16.840.1.113883.10.20.22.4.8
CE
7349
2.16.840.1.113883.5.4 (ActCode) =
SEV
ED
7350
7351
2.16.840.1.113883.1.11.78
(Observation Interpretation (HL7))
1. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem:
HL7ActClass 2.16.840.1.113883.5.6) (CONF:7345).
2. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) (CONF:7346).
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 33
Sept 2012
7.1.1 Placeholder language (if needed)
Placeholder languag
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 34
Sept 2012
HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
APPENDIX A — USINESS REQUIREMENTS FOR
TRANSPORT (ENVELOP) MESSAGE OR TRANSACTI ON.
Request Activity
Response Activity
Acknowledgement Activity
HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
APPENDIX B — BUSINESS REQUIREMENTS FOR REQUEST,
RESPONSE AND ACKNOWLEDGEMENT STANDARDS.
HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
APPENDIX C — ASC X12 STANDARDS THAT SATISFY THE
BUSINESS REQUIREMENTS LISTED IN APPENDIX A.
HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
APPENDIX D —
PLACEHOLDER
HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates