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

What about New Attachment Type acquisition?

Add clarfiying boundaries for how to include the CCDATG for specific clinical
exchange.
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 ................................................................................... 10
2.6
Consolidated CDA Templated Guide (CCDATG) ..................................................... 10
2.7
Additional Attachment Information - Request and Response .................................. 10
2.7.1
Solicited and Unsolicited Attachments .............................................................. 10
2.7.2
Request Attachment Activity ............................................................................. 10
2.7.3
Response Attachment Activity ........................................................................... 12
2.7.4
Understanding attachment activities ................................................................. 12
2.7.5
Attachment Re-Association ID .......................................................................... 15
2.8
4
Definitions, Glossary and Acronyms ...................................................................... 16
2.8.1
Definitions ....................................................................................................... 16
2.8.2
Acronyms ......................................................................................................... 16
2.9
3
Revision History ..................................................................................................... 7
Health Level Seven Organization ........................................................................... 17
UNDERSTANDING CCDATG .......................................................................................... 18
3.1
What is Clinical Document Architecture (CDA)?..................................................... 18
3.2
Taking Advantage of Structured/Unstructured Content ......................................... 19
3.2.1
Structured Content .......................................................................................... 20
3.2.2
Unstructured Content ...................................................................................... 20
3.2.3
Mobile Devices? ................................................................................................ 20
3.2.4
Explanation of Levels 1, 2 and 3 ....................................................................... 20
3.3
What is CCDATG? ................................................................................................ 20
3.4
Human Readable and Computer Processable Content............................................ 21
ADDITIONAL INFORMATION (ATTACHMENTS) GENERAL .............................................. 23
4.1
Standards to accomplish information exchange of the request and response .......... 23
4.2
LOINC (Logical Observable Identifiable Names and Codes) ..................................... 23
4.2.1
LOINC Codes for Electronic Supporting Documentation .................................... 23
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 ............................................................................ 26
4.2.3
The LOINC Committee ...................................................................................... 27
4.2.4
Obtaining the LOINC Database ......................................................................... 27
4.3
Requesting Attachment Information ...................................................................... 27
4.3.1
Using LOINC Code to request electronic documents .......................................... 27
4.3.2
Using “Modifiers” LOINC Code to constrain the request. .................................... 27
4.4
Responding with Attachment Information .............................................................. 28
4.5
Solicited and Unsolicited Attachment Information ................................................. 28
4.6
Using the LOINC Database to Identify Valid Attachment Types .............................. 28
4.7
ISO Object Identifiers (OID’s) ................................................................................ 28
5
ADDITIONAL INFORMATION (ATTACHMENTS)USE CASES ............................................ 30
6
IMPORTANT INFORMATION NOT ADDRESSED IN THIS SUPPLEMENT .......................... 31
6.1
7
STUBB ................................................................................................................. 32
OBTAINING NEW ATTACHMENT TYPES ........................................................................ 33
7.1.1
Placeholder language (if needed) ....................................................................... 35
APPENDIX A — USINESS REQUIREMENTS FOR TRANSPORT (ENVELOP) MESSAGE
OR TRANSACTION. ....................................................................................................... 37
APPENDIX B — BUSINESS REQUIREMENTS FOR REQUEST, RESPONSE AND
ACKNOWLEDGEMENT STANDARDS. ............................................................................ 38
APPENDIX C — ASC X12 STANDARDS THAT SATISFY THE BUSINESS
REQUIREMENTS LISTED IN APPENDIX A. .................................................................... 39
APPENDIX D —
PLACEHOLDER ........................................................................................ 40
APPENDIX E — INFORMATION FROM SOLICITED / UNSOLICITED TEMPORARY
RELOCATED WHILE REVISIONS ARE MADE. ............................................................... 41
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 ................................................................................... 34
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 supplement are implementators, such as architects and
developers, responsible for the exchange of supporting/attachment information between
a provider and a healthcare entity such as a health plan, UMO, TPA, 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’. Additionally, throughout this supplement,
‘healthcare activities’ will include any or all of the activities listed above.
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 the 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
This supplement is limited in focus to address primarily how to format clinical
information into a single clinical document for exchange between entities. It will also
offer guidance as to how to re-associate that single clinical document with the
healthcare activity for which additional information was originally needed. It may
describe scenario’s for those business events which could be broader than the intended
scope of this supplement to assist the audience in understanding the context how the
single clinical document exchange fits into the overall picture.
While the single clincal document can exist entirely on it’s own, for the purposes of this
supplement we will be focused on the transporting (moving?) of that document from one
point to another electronically. This supplement will present examples of that
transport (movement?) and may use existing standards that accomplish that movement
in those examples. However, in depicting those examples the authors of this
supplement acknowledge the use of those standards as examples does not limit
implementations to only those standards.
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 has been developing the needed supporting
information content for the purposes of claims attachments since the HIPAA
Transactions and Codeset regulations were implemented. In addition, many years were
spent writing Additional Information Specifications (AIS) 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 would to be the standard for this exchange, and that the content found in the
CCDATG is largely consistent with that needed for Attachments purposes.
After much discussion, the AWG determined that it was not in the best interest of
providers and/or their vendors to support multiple formats for this exchange based on
the recipient. Rather than one standard format for the provider-to-provider
information exchange and another (i.e., the original 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.
The AWG then performed a gap analysis between the CCDATG content and that found
in the AIS content. The AIS’s were the original Attachments specifications. Information
needed for purposes described in section 2.2 that was present in the AIS but not in the
CCDATG was identified and passed to the Structured Document Work Group for
inclusion into the CCDATG. In some cases, this resulted in the addition of information
from the original AIS to the CCDATG. Information present in the CCDATG but not in
the AIS 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.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 9
Sept 2012
The CCDATG was intended to have a broad industry footprint and not to be
implementation specific. Information specific to implementations as described in section
2.2 is not included in the CCDATG. This supplement was created to capture the
Attachments specifications not available in the CCDATG.
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.
2.7
Additional Attachment Information - Request and Response
Typically, in the course of doing business payers will occasionally need additional
information from a provider (as an information source) to determine if the level of
service being performed or requested is consistent with the patients insurance benefits.
Payers also have general medical policies established that must be checked for
consistency with the patients insurance benefits.
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. However, while this supplement by necessity must
define the complete attachment activity scenario, it only addresses attachment
scenarios where an standard electronic response is involved.
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. The response, whether Solicited or Unsolicited, refers to the act of providing
additional attachment information needed.
Solicited and Unsolicited scenarios are tied closely to the response side of the
attachment activity without regard to the mode of the request. They are also aligned
closely with who establishes the attachment re-association ID that is used to match the
attachment itself with either the claim, referral, or prior authorization attachment
activity (more about asttachment re-association ID in section 2.7.5).
2.7.1 Solicited and Unsolicited Attachments
A solicited attachment refers to the act of exchanging attachment information which
was requested after a healthcare activity was receivedand determined to require
additional information to complete the activity.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 10
Sept 2012
An unsolicited attachment refers to the act of exchanging attachment information that
conforms to a set of rules-based criteria envoked at the time of the submittal of a
healthcare aactivity. This information is based on advance knowledge of rules defined
by the information receiver.. An unsolicited attachment would never be sent in response
to a standard electronic request.
A key component of both scenarios is the entity establishing the linkage to re-associate
the healthcare activity with the corresponding attachment information.
In the solicited scenario, the entity creating the request would establish an
attachment control ID that would be passed to the receiving entity (information
source) of the request. The receiving entity would then return that attachment
control ID along with the attachment information so that the requestor can reassociate the attachment information with the initial request.
In the unsolicitated scenario, the entity that is the source for the attachment
information would assign an attachment control ID. This attachment control ID
would be sent with both the attachment information and the healthcare activity so
that the receiver can re-associate the attachment information with the healthcare
activity.
This supplement takes no position with respect to the business reasons that initiate
unsolicited attachments. However, industry best practices suggest that in the absence
of business rules established in advance, the sending of attachment information
should not be done.
2.7.2 Request Attachment Activity
A request for additional information can originate in numerous ways and may be
initiated by unique triggering business events depending on the originating actor. The
table below reflects some of the more common scenarios for illustrative purposes:
Table ??: Request Attachment Activity Table
Request
HealthCare
Request Re-Association ID
Attachment
Activity
Assigning
Mode
Standard Electronic
Timing
After claim receipt
and review
Actor
Service, Patient
After claim receipt
request, etc)
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
and review
Activity
Linkage
Basis
Payer request
Payer
and provider
Solicited
response
Claim
Phone call, US Postal
Attachment
Payer request
Payer
Consolidated CDA Templates
and provider
Solicited
response
Page 11
Sept 2012
Provider claim
Rules Based
At time of claims
submital1
Provider
and additional
information
Unsolicited
submittal
After prior
Standard Electronic
authorization
Payer request
Payer
receipt and review
Prior
Authorization
Phone call, US Postal
After prior
Service, Patient
authorization
request, etc)
receipt and review
and provider
Solicited
response
Payer request
Payer
and provider
Solicited
response
Provider Prior
Authorization
At time of prior
Rules Based
authorization
Provider
request2
request and
additional
Unsolicited
information
submittal
Referral
2.7.3 Response Attachment Activity
The act of exchanging attachment information from an information source to an
information receiver is considered a response. The information source is considered
the entity that posesses the attachment information needed by the payer to support the
healthcare activity.
The solicited and unsolicited scenarios are explained in section 2.7.1 and help close the
loop in request and response.
2.7.4 Understanding attachment activities
Because this supplement addresses all facets of the process in the 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 that activity. As well, each row will
call for a unique set of electronic exchange 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 purposes of this
supplement, example scenarios and use cases will reference those ASC X12 standards
previously developed to accomplish attachments information exchange.
Payers request criteria (rules based) forcertain certain type of claim for a specific health care provider, procedure, or
service is known in advance to the provider .
2 Payers request criteria (rules based) for a certain types of prior authorizations is known in advance to
the provider.
1
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 12
Sept 2012
Table ?? (Attachments Activity Table) below describes all scenarios addressed by this
supplement for attachment exchange purposes. Column headings and table values are
described below:

Healthcare Activity – The type of healthcare activity of the originating actor for the
‘request’ activity type.

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 attachment exchange 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).
Attachment Activity Basis
o
Solicited – attachments information that is explicitly requested or the
response to an explicit request.
o
Unsolicited – attachments information provided from the originator to the
receiver based ONLY on a “rules based” request and in the absence of an
electronic request. “Rules based” requests are not in scope for this
supplement because they are typically not explicit electronic requests.
Actor
o
Originator – the actor originating or initiating the attachments activity
o
Receiver – the actor receiving the attachments activity
Table ??: Attachments Activity Table3
HealthCare
Activity
Claims
Attachment
Prior Auth and
Activity
ID
Originator
Activity Type
#1
#2
Request
Response
“Requested in
Advance”
Response
Request
#3
#4
Attachment Activity
Basis
Solicited
Unsolicited
Actor
Originator
Receiver
Payer
Provider
Provider
Payer
Provider
Payer
Payer
Provider
X
X
X
X
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
3
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 13
Sept 2012
Referral
Attachment
Notification
Attachment
#5
Response
X
#6
“Requested in
Advance”
Response
#7
Request
X
#8
Response
X
#9
“Requested in
Advance”
Response
Provider
Payer
Provider
Payer
Referred to
provider
Referred
from provider
Referred from
provider
Referred to
provider
Referred
from provider
Referred to
provider
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 “Healthcare
Activity” “Solicited / Unsolicited” “Originator Activity Type” for additional
information from the “Originator” to the “receiver”.
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.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 14
Sept 2012

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.
This Allows for standards correlation to each of the activity ID’s with a current X12
standard. If future regulation expands to include other transport methodologies,the
correlation will be applicable to them as well.
The activities above are not meant to reflect and/or include business events activity
other then those directly related to the requesting and responding with attachment
information. For example, when a provider requests authorization from a Payer/UMO
prior to rendering a service the act of submitting the prior authorization request is not
included. Only the payer/UMO’s response for additional information and the provider
subsequent submittal of that additional information are included.
2.7.5 Attachment Re-Association ID
Another important component of an attachment activity is the ability to re-associate the
attachment response with the request.
Depending on the attachment activity, the
entity responsible for assigning an attachment re-association ID will vary. The table
below highlights more how the re-association ID will be integrated into the attachment
activity processes.
Table ??: Attachments Activity Table
Activity ID
Relationship
Attachment Activity
Re-association
Intended Re-association
ID creator
linkage
Activity #1 represents the information exchange for
Paired together as
a solicited request/
the Claims Attachment Solicited request for
Provider returns the ID
additional information from the payer to the provider
from the request (#1) in
response for claims
Payer
attachment
Activity #2 represents the information exchange for
infomation
the Claims Attachment Solicited response for
their claims attachment
information response (#2)
additional information from the provider to the payer
Activity #3 represents the information exchange for
Stand alone
the Claims Attachment unsolicited “requested in
advance” response for additional information from
Provider inserts ID into
Provider
both claim and attachment
information
the provider to the payer
Activity #4 represents the information exchange for
Paired together as
a solicited request/
response for prior
authorization
the prior auth attachment solicited request for
additional information from the payer to the
Provider returns the ID
provider.
from the request (#4) in
Payer
Activity #5 represents the information exchange for
attachment
the prior auth attachment solicited response for
infomation
additional information from the provider to the
their prior authorization
attachment information
response (#5)
payer.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 15
Sept 2012
Provider inserts ID into
Activity #6 represents the information exchange for
Stand alone
the Prior Auth attachment unsolicited “requested in
advance” response for additional information from
both prior authorization
Provider
the provider to the payer.
requestthe prior
authorization and
attachment information
REFERRALS
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.
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 left-most number representing the root and the right-most number representing a leaf.
Attachments
Payer
2.8.2 Acronyms
To aid the implementer, this section will restate any acronyms used in this supplements
in one common place.

CDA – Clinical Document Architecture

CCDATG – Consolidated CDA Templated Guide

OID – Object Identifier (See Definitions)

AIS – Additional Information Specification
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 16
Sept 2012
2.9

JPEG

PNG
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.
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 17
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.
Information about the components for CDA is being presented at a high level and is not
intended to substitute for anything other than what is necessary for the implementer to
understand its applications with respect to attachments. For technical guidance about
how to implement CDA for attachments, reliance on the CCDATG is expected.
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.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 18
Sept 2012

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:

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”4.
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 sheet5, 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
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.
4
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.
5
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 19
Sept 2012
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.
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
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 20
Sept 2012
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
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.
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 21
Sept 2012
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.
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 22
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 asknowledge 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 used6. As the technologies mature, we expect additional standards to be
developed and are open to adapting this supplement to include them as well.
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.
6
Supplement to HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
Page 23
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 24
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 25
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 26
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 27
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 28
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 29
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 30
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 31
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 32
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 33
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 34
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 35
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
APPENDIX E — INFORMATION FROM SOLICITED /
UNSOLICITED TEMPORARY RELOCATED WHILE
REVISIONS ARE MADE.
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
Scope7
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
7
This is out of scope because this supplement only addresses scenario’s involving electronic responses.
HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates
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.
HL7 Implementation Guide for CDA R2
© 2012 Health Level Seven, Inc. All rights reserved.
Consolidated CDA Templates