Consolidated CDA Release 2.2, published by Health Level Seven. This is not an authorized publication; it is the continuous build for version 2.2). This version is based on the current content of https://github.com/HL7/CDA-ccda-2.2/ and changes regularly. See the Directory of published versions
Acronym | Description |
---|---|
ADL | Activities of Daily Living |
C-CDA R1, R1.1, R2 | Consolidated CDA (Release 1, 1.1, and 2) |
CCD | Continuity of Care Document |
CDA, CDA R2 | Clinical Document Architecture (Release 2) |
CDC | Centers for Disease Control and Prevention |
CFR | Code of Federal Regulations |
CID | content identifier |
CPT | Current Procedural Terminology |
CVX | Codes for Vaccine Administered |
DAM | Domain Analysis Model |
DI | device identifier |
DICOM | Digital Imaging and Communications in Medicine |
CMET | Common Message Element Type |
DIR | Diagnostic Imaging Report |
DME | durable medical equipment |
DRIV | is derived from |
DSTU | Draft Standard for Trial Use |
EHR | electronic health record |
EMR | electronic medical record |
EVN | event |
FDA | Food and Drug Administration |
FIPS | Federal Information Processing Standards |
GOL | goal |
H&P | History and Physical |
HCT/P | Human Cell & Tissue Products |
HHPoC | Home Health Plan of Care |
HIBCC | Health Industry Business Communications Council |
HIE | health information exchange |
HISP | health information service provider |
HIT | healthcare information technology |
HITSP | Health Information Technology Standards Panel |
HL7 | Health Level Seven |
HTML | Hypertext Markup Language |
IADL | Instrumental Activities of Daily Living |
ICCBBA | International Council for Commonality in Blood Banking Automation, Inc. |
ICD | International Classification of Diseases |
ICF | International Classification of Functioning, Disability and Health |
IG | implementation guide |
IHE | Integrating the Healthcare Enterprise |
PCC | Patient Care Coordination |
IHTSDO | International Health Terminology Standard Development Organisation |
RFC | Request for Comments |
ITI | information technology infrastructure |
LCC | Longitudinal Care Coordination |
LCP | Longitudinal Care Plan |
LOINC | Logical Observation Identifiers Names and Codes |
LTPAC | Long-Term Post-Acute Care |
MHTML | MIME HTML |
MIME | Multipurpose Internet Mail Extensions |
MPHO | Medical Products of Human Origin |
NA | not applicable |
NDC | National Drug Code |
NDFRT | National Drug File Reference Terminology |
NEMA | National Electrical Manufacturers Association |
NHSN | National Healthcare Safety Network |
NI | no information |
NLM | National Library of Medicine |
NPI | National Provider Identifier |
NPO | nothing by mouth |
NPP | non-physician provider |
NUBC | National Uniform Billing Committee |
NUCC | National Uniform Claim Committee |
OID | object identifier |
ONC | Office of National Coordinator |
OTH | not an element in the value domain |
PCDATA | Parsed Character Data |
PCWG | Patient Care Work Group |
Portable Document Format | |
PGD | Patient Generated Document |
PGP | Pretty Good Privacy |
PHQ | Patient Health Questionnaire |
PHR | personal health record |
PI | Production Identifier |
PKCS#7 | public-key cryptography standard seven (Cryptographic Message Syntax Standard |
RFC | request for comment |
RIM | Reference Information Model |
RMIM | Refined Message Information Model |
RQO | request |
RSNA | Radiological Society of North America |
S&I | Standards and Interoperability |
sdtc | Standard Duty Title Code |
SDWG | Structured Documents Working Group |
SMART | Substitutable Medical Applications & Reusable Technology |
SNF | Skilled Nursing Facility |
SNOMED CT | Systemized Nomenclature for Medicine – Clinical Terms |
SOP | Service Object Pair |
SPL | Structured Product Labeling |
SR | Structured Report |
SSN | Social Security Number |
SWG | Sub Work Group |
TPN | Total Parenteral Nutrition |
UCUM | Unified Code for Units of Measure |
UD | Unstructured Document |
UDI | Unique Device Identification |
UML | Unified Modeling Language |
UNII | Unique Ingredient identifier |
UNK | unknown |
URL | uniform resource locator |
URN | uniform resource name |
UUID | universally unique identifier |
VIS | Vaccine Information Statement |
WADO | Web Access to Persistent DICOM Objects |
XDS-SD | Cross Enterprise Sharing of Scanned Documents |
XML | eXtensible Markup language |
XML-DSIG | XML digital signature |
XPath | XML Path Language |
This implementation guide builds on HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Release 2.0. (NOV 2014).
Where there is a need to communicate information for which there is no suitable representation in CDA R2, extensions to CDA R2 have been developed. These extensions are described above in the context of the section where they are used. This section serves to summarize the extensions and provide implementation guidance. Extensions created for this guide include:
To resolve issues that need to be addressed by extension, the developers of this guide chose to approach extensions as follows:
The following text is taken from the Claims Attachments Implementation Guide (AIS00000) in Section 2.4.15 For up-to-date guidance, refer to the latest edition of that specification.
MIME Multipart/Related Messages
An attachment is comprised of the CDA document, including any supporting files necessary to render the attested content of the document. Two Internet request for comments (RFCs) are needed to properly construct the mime multipart message. When supporting files are needed, the collection of information shall be organized using a MIME multipart/related package constructed according to RFC 2557. Within the MIME package, supporting files must be encoded using Base-64. RFC-4648 should be used when encoding the contents of the MIME package using Base-64. Finally, RFC-2392 may be used to reference other content that appears in the same X12 transaction to use the same content to answer multiple questions for a single claim. Internet RFCs can be downloaded from the RFC editor page at http://www.rfc-editor.org.
RFC-2557 MIME Encapsulation of Aggregate Documents, Such as HTML (MHTML)
This RFC describes how to construct a MIME multipart/related package, and how URLs are resolved within content items of that package. RFC-2557 can be obtained at: http://www.rfc-editor.org/rfc/rfc2557.txt
A MIME multipart/related package is made up of individual content items. Each content item has a MIME header identifying the item. Each content item is delimited from other content items using a string of application specified text. In addition, there must be an ending boundary. The actual content is recorded between these delimiter strings using a BASE-64 encoding of the content item. There is also a MIME header for the entire package.
The first content item of a multipart/related message supporting attachments is the CDA document, containing the header and structured or non-structured body. Subsequent content items included in this package will contain additional content that appears within the body of the document. The CDA document will reference these additional content items by their URLs.
Referencing Supporting Files in Multipart/Related Messages
Because the CDA document and its supporting files may have already existed in a clinical information system, references may already exist within the CDA document to URLs that are not accessible outside of the clinical information system that created the document. When the CDA document is sent via attachments, these URLs may no longer be accessible by the receiving information system. Therefore, each content item that is referenced by a URL within the CDA document must be included as a content item in the MIME package. Each content item may specify the URL by which it is known using the Content-Location header. The receiver of this MIME package shall translate URL references according the RFC-2557. This will ensure resolution of the original URL to the correct content item within the MIME package. Thus, URL references contained within an original document need not be rewritten when the CDA package is transmitted. Instead, these URLs are simply supplied as the value of the Content-Location header in the MIME package.
This capability allows for the same content item to be referred to more than once in a MIME multipart/related package without requiring the content item to be supplied twice. However, it does not allow a separate MIME multipart/related package to contain references to information sent in a previously recorded package.
Referencing Documents from Other Multiparts within the Same X12 Transactions
RFC-2392 is used when referencing content across MIME package boundaries, but still contained within the same X12 transaction (ST to SE). This can occur when the same document answers multiple questions for a single claim. Each component of a MIME package may be assigned a content identifier using the Content-ID header for the content item. For example, this header would appear as:
Content-ID: <07EE4DAC-76C4-4a98-967E-F6EF9667DED1>
This content identifier is a unique identifier for the content item, which means it must never be used to refer to any other content item. RFC-2392 defines the cid: URL scheme (http: and ftp: are two other URL schemes). This URL scheme allows for references by the Content-ID header to be resolved. The URL for the content item identified above would be:
cid:07EE4DAC-76C4-4a98-967E-F6EF9667DED1
Receivers of the MIME multipart message must be able to resolve a cid: URL to the content item that it identifies. Senders must ensure that they only refer to items that have already been transmitted to the receiver by their cid: URL. Thus, this implementation guide prohibits forward URL references using the cid: URL scheme.
Content items shall not be referenced across X12 transactions using the cid: URL scheme. For example, if the payer previously requested information using a 277, and the provider returned that information in a MIME multipart/related package in a 275, and then the payer requested additional information in another 277, the provider may not refer to the content item previously returned in the prior 275 transaction.