DraftCDAR2.1.a

HL7 Clinical Document Architecture, Release 2.1

For Comment Only Ballot May 2017

Role	HL7 Member	Role	HL7 Member
Co-Chair / Primary Editor	Calvin Beebe Mayo Clinic cbeebe@mayo.edu	Co-chair / Co-Editor / Modeling Facilitator	Austin Kreisler Leidos, Inc. AUSTIN.J.KREISLER@leidos.com
Co-chair	Benjamin Flessner Epic Benjamin@epic.com	Co-chair	Brett Marquard River Rock Associates brett@riverrockassociates.com
Co-chair	Gay Dolin MSN RN Intelligent Medical Objects (IMO) gdolin@imo-online.com	Co-chair	Rick Geimer Lantana Consulting Group rick.geimer@lantanagroup.com
Co-Editor / Vocabulary Facilitator	Robert Hausam MD Hausam Consulting LLC<br. rrhausam@gmail.com	Co-Editor	Jeff Brown American Society of Clinical Oncology's CancerLinQ jeff.brown@CancerLinQ.org
Co-Editor / Publication Facilitator	Andy Stechishin CANA Software & Services andy.stechishin@gmail.com

Return to master table of contents

1 CDA Overview

1.1 What is the CDA

The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is a documentation of clinical observations and services, with the following characteristics:

• Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document instance).
• Stewardship – A clinical document is maintained by an organization entrusted with its care.
• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
• Context - A clinical document establishes the default context for its contents.
• Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
• Human readability – A clinical document is human readable.

A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.

1.1.1 Key aspects of the CDA

Key aspects of the CDA include:

• CDA documents are encoded in Extensible Markup Language (XML). (NOTE: When alternate implementations are feasible, suitable conformance requirements will be issued so that in future the syntax may not be limited to XML.)
• CDA documents derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types Release 1.0.
• The CDA specification is richly expressive and flexible. Document-level, section-level and entry-level templates can be used to constrain the generic CDA specification (see The "A" in "CDA" and Section 4 CDA Implementation Guides .

1.1.2 Scope of the CDA

The scope of the CDA is the standardization of clinical documents for exchange.

The data format of clinical documents outside of the exchange context (e.g., the data format used to store clinical documents) is not addressed in this specification.

CDA documents can be transmitted using a variety of techniques, E.g. HL7 2.x messages, V3.0 messages, FHIR messages, Direct and Exchange solutions, etc. While the detailed specification for such messages and solutions are outside of the scope of the CDA, this specification does impose requirements upon the packaging of CDA documents in all of these and other contexts (see CDA Document Exchange).

The CDA does not specify the creation or management of documents, only their exchange markup. While it may be possible to directly use the CDA Schema in a document authoring environment, such use is not the primary purpose of the CDA specification.

Document management is critically interdependent with the CDA specifications, but the specification of document management messages is outside the scope of the CDA. (For more on this, see Relationship of the CDA to HL7 Messaging Standards).

NOTE: Several committees are developing structured document specifications that overlap in part with the CDA specification. The Structured Documents Technical Committee, in collaboration with Publishing and these other committees, is developing a Structured Documents Infrastructure chapter to clarify these relationships which should be available in upcoming editions.

1.1.3 Goals and Design Principles

The goals of the CDA are:

• Give priority to delivery of patient care.
• Allow cost effective implementation across as wide a spectrum of systems as possible.
• Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
• Promote longevity of all information encoded according to this architecture.
• Enable a wide range of post-exchange processing applications.
• Be compatible with a wide range of document creation applications.
• Promote exchange that is independent of the underlying transfer or storage mechanism.
• Prepare the design reasonably quickly.
• Enable policy-makers to control their own information requirements without extension to this specification.

A number of design principles follow from consideration of the above goals:

• This architecture must be compatible with XML and the HL7 RIM.
• This architecture must be compatible with representations of clinical information arising from other HL7 committees.
• Technical barriers to use of the architecture should be minimized.
• The architecture specifies the representation of instances required for exchange.
• The architecture should impose minimal constraints or requirements on document structure and content required for exchange.
• The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data.
• Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies.
• Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture.
• CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet language.
• Use open standards.

1.2 General CDA Concepts

1.2.1 Major Components of a CDA Document

This section serves as a high-level introduction to the major components of a CDA document, all of which are described again and in greater detail later on. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow.

Major components of a prototypic CDA document are shown in the following skeletal example. (Note that many required components are missing to simplify the example. See Samples for a detailed conformant example).

A CDA document is wrapped by the <ClinicalDocument> element, and contains a header (see Header) and a body (see Body). The header lies between the <ClinicalDocument> and the <structuredBody> elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers.

The body contains the clinical report, and can be either an unstructured blob, or can be comprised of structured markup. The example shows a structured body, which is wrapped by the <structuredBody> element, and which is divided up into recursively nestable document sections.

A CDA document section is wrapped by the <section> element. Each section can contain a single narrative block (see Section Narrative Block), and any number of CDA entries (see Entry Acts) and external references.

The CDA narrative block is wrapped by the <text> element within the <section> element, and must contain the human readable content to be rendered. See also Human Readability and Rendering CDA Documents and CDA Conformance for principles governing the representation of the narrative block, and conformance requirements on the part of originators when populating the block, and recipients when rendering it.

Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for further computer processing (e.g. decision support applications). CDA entries typically encode content present in the narrative block of the same section. The example shows two <observation> CDA entries, and a <substanceAdministration> entry containing a nested <supply> entry, although several other CDA entries are defined.

CDA entries can nest and they can reference external objects. CDA external references always occur within the context of a CDA entry. External references refer to content that exists outside this CDA document - such as some other image, some other procedure, or some other observation (which is wrapped by the <externalObservation> element). Externally referenced material is not covered by the authentication of the document referencing it.

Example X

<ClinicalDocument>
  ... CDA Header ...
  <structuredBody>
    <section>
      <text>...</text>
      <observation>...</observation>
      <substanceAdministration>
        <supply>...</supply>
      </substanceAdministration>
      <observation>
        <externalObservation>...
        </externalObservation>
      </observation>
    </section>
    <section>
        <section>...</section>
    </section>
  </structuredBody>
</ClinicalDocument>

1.2.2 The "A" in "CDA"

The notion of CDA "levels" in CDA, Release One anticipated a hierarchical set of XML DTDs or XML Schemas to achieve the goals enumerated above (see Goals and Design Principles). This hierarchy formed an "architecture", hence the "A" in "CDA".

While the notion of levels in CDA, Release Two remains constant, the approach to representing the hierarchies has changed. The current specification consists of a single CDA XML Schema, and the architecture arises from the ability to apply one or more of a hierarchical set of HL7 Templates, which serve to constrain the richness and flexibility of CDA.

The RIM's InfrastructureRoot class contains an attribute, templateId, which is available for use in CDA. Where templateId(s) have been defined within a CDA document instance, the constraints contained within the template are assumed to be imposed. See Section 4 CDA Templating for more details.

There is no requirement that CDA must be constrained, however implementations that use structured data elements to drive automated processes will typically reference templates found in CDA Implementation Guide(s). The use of entry-level templates enables the semantic interoperability of any structured content found in documents exchanged.

There are many kinds of HL7 Templates that might be created. Among them, three are particularly relevant for clinical documents: (1) those that constrain the document content or document-level templates, (2) those that constrain content expected in sections or section-level templates and (3) those that constrain the entries within document sections or entry-level templates. Additional templates can be defined as needed to enable consistency in demographic data found within a document of names, addresses and telecom references or phone numbers.

Table X: Evolution of CDA "levels" from CDA, Release One to CDA, Release Two

CDA, Release One	CDA, Release Two
CDA Level One	The unconstrained CDA.
CDA Level Two	The CDA specification with section-level templates applied.
CDA Level Three	The CDA specification with entry-level (and optionally section-level) templates applied.

An illustration of one possible hierarchy of CDA plus HL7 Templates is shown here:

Example X

• CDA Schema
  • CDA Schema :: Progress Note section-level template applied.
    • CDA Schema :: Progress Note section-level and Vital Signs entry-level template applied.
      • CDA Schema :: Endocrinology Progress Note section-level and Vital Signs entry-level template applied.
      • CDA Schema :: Progress Note section-level and ICU Vital Signs entry-level template applied.
  • CDA Schema :: Cardiology Progress Note section-level template applied
  • CDA Schema :: Cardiology Progress Note section-level and Cardiac Exam entry-level template applied.
  • CDA Schema :: Endocrinology Progress Note section-level template applied.
  • CDA Schema :: Endocrinology Progress Note section-level and Vital Signs entry-level template applied.

1.2.3 Human Readability and Rendering CDA Documents

The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser. CDA, Release 2.1, with its blend of narrative and CDA entries, presents challenges to this requirement. Among the requirements affecting the design of CDA Release 2.1 are the following:

• There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content.
  • Authenticated documents, need to convey with fidelity the clinical content reviewed by the legal and other authenticator(s).
  • Documents which are not authenticated, (e.g. Continuity of Care Document, other generated documents) need to ensure that receivers are able to accurately interpret the clinical content contained in the document and its associated entries.
• Human readability shall not require a sender to transmit a special style sheet along with a CDA document. It must be possible to render all CDA documents with a single style sheet and general-market display tools.
• Human readability applies to the authenticated narrative content. There may be additional information conveyed in the document that is there primarily for machine processing that is not authenticated and need not be rendered.
• When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative.
• When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data.

These principles and requirements have led to the current approach, where the material to be rendered is placed into the Section.text field (see Section Narrative Block). The content model of this field is specially hand crafted to meet the above requirements, and corresponds closely to the content model of sections in CDA, Release One. Structured observations can reference narrative content in the Section.text field. Multimedia observations are encoded outside the Section.text field, and the <renderMultiMedia> tag within the Section.text field provides an outgoing pointer that indicates where the referenced multimedia should be rendered.

1.2.4 XML Markup of CDA Documents

XML markup of CDA documents is prescribed in this specification. CDA instances are valid against the CDA Schema and may be subject to additional validation (see CDA Conformance). There is no prohibition against multiple schema languages (e.g., W3C, DTD, RELAXNG), as long as conforming instances are compatible.

Design Principles of the CDA Schema include:

• General Requirements: The design of the CDA Schema follows the more general requirements for CDA (see Goals and Design Principles).
• CDA Schema and V3 Implementation Technology Specification (ITS) : The CDA Schema will follow the general V3 XML ITS.
• RIM Mapping: The CDA Schema describes the style of XML markup of CDA instances for the purpose of exchange. It cannot be understood outside the context of this defining specification. At the same time, the CDA Schema is useful on its own for implementation purposes even though it is not intended to replicate or take the place of the R-MIM and HD. The CDA Schema, then, is not, in and of itself, an adequate map between conforming instance and the HL7 RIM. Semantic interoperability of CDA instances requires use and knowledge of the CDA Schema, R-MIM and HD as well as the corresponding RIM.
• Document Analysis: The CDA Schema and conformant instances should adhere to the requirements of document analysis in derivation of the content model.

  NOTE: Document analysis is a process that might be thought of as the document equivalent of a use case. Document analysis looks at a single instance or class of documents and analyzes their structure and content, often representing this as a tree structure "elm" notation. Document analysis also looks at the business rules for the lifecycle of that document or document class. Traditionally, document analysis determines the content model and overall structure and style of XML.

  Document analysis is an iterative step in content model derivation -- the "bottom up" approach to complement the "top down" derivation from the RIM. This will ensure that schemas and instances are not only RIM-derived, but represent recognizable artifacts in a simple manner.

• Forward and Backward Compatibility: The CDA Schema should adhere to the requirements for forward and backward compatibility. (See Backwards and Forwards Compatibility)
• Naming: While XML markup, by definition, is for machine processing, it should be optimized for human review, debug, and design. The CDA Schema is not "self-documenting", but meaning should be clear from tag name and documentation (e.g., mapping to RIM). The human-language sense of a tag name should not be counterintuitive.
• Vocabulary: Vocabulary can be enumerated within the CDA Schema or in an external, referenced source. It is preferable to enumerate it when the vocabulary terms are both limited (not too large in number) and stable (not subject to change between ballot cycles). Where vocabulary is either too large or is subject to change, it is preferable to maintain it external to the CDA Schema and incorporate it by reference. In these cases, XML schema validation will not suffice for conformance.

1.2.5 Security, Confidentiality, and Data Integrity

Application systems sending and receiving CDA documents are responsible for meeting all legal requirements for document authentication, confidentiality, and retention. For communications over public media, cryptographic techniques for source/recipient authentication and secure transport of encapsulated documents may be required, and should be addressed with commercially available tools outside the scope of this standard.

The CDA does provide confidentiality status information to aid application systems in managing access to sensitive data. Confidentiality status may apply to the entire document or to specified segments of the document.

1.2.6 Relationship of the CDA to HL7 Messaging Standards

A CDA document is a defined and complete information object that can exist outside of a messaging context and/or can be a payload within an HL7 message (see CDA Document Exchange in HL7 Messages). Thus, the CDA complements HL7 messaging specifications.

Clinical documents can be revised, and they can be appended to existing documents. Ideally, an updated document would declare itself as obsolete, and would contain an explicit pointer to a more recent version. This would lessen the chances of a healthcare provider basing treatment decisions on erroneous or incomplete data.

In practice, however, it is impossible to guarantee an explicit forward pointer from an outdated version to the newer version. Without a process that tracks the chain of custody of clinical documents and all of their copies, there can be no way to guarantee that a clinical document being viewed has not been subsequently revised.

To minimize the risk of viewing superseded information, there is a critical interdependence between clinical documents and document management systems. If CDA documents are viewed outside the context of a document management system, it cannot be known with certainty whether or not the viewed document has been revised. HL7 messages that carry CDA documents (such as the MDM messages in HL7 V2.x and the HL7 V3 Medical Records messages) convey critical contextual information that ensures accurate viewing of clinical data.

1.3 CDA Conformance

NOTE: See HL7 V3 Refinement and Localization for a complete discussion of V3 conformance.

A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains. However a computer cannot validate every aspect of conformance. The focus of this section is to highlight these aspects of CDA that cannot be machine validated - particularly those aspects related to the CDA human readability requirements.

A document originator is an application role that creates a CDA document. CDA documents can be created via transformation from some other format, as a direct output of an authoring application, etc. The document originator often is responsible for communicating with a persistent storage location, often using HL7 V2 MDM or HL7 V3 Medical Records messages. The document originator is responsible for ensuring that generated CDA documents are fully conformant to this specification.

A document recipient is an application role that receives status updates and documents from a document originator or document management system. The document recipient is responsible for ensuring that received CDA documents are rendered in accordance to this specification.

Because CDA is an exchange standard and may not represent the original form of a document, there are no persistent storage requirements for CDA documents defined in this standard. However, as noted above (see Relationship of the CDA to HL7 Messaging Standards), document management is critically interdependent with the CDA specification. The custodian identified in the CDA header (see custodian) is the participant charged with maintaining the original document, which may be in some form other than CDA.

1.3.1 Recipient Responsibilities

• Assume default values where they are defined in this specification, and where the instance does not contain a value : Where CDA defines default values, the recipient must assume these values in the event that no value is contained in a CDA instance. (NOTE: These values have been identified as having Minimum Cardinality = 0 and code binding = "Fixed" or "Closed w/ Default".)
• Parse and interpret the complete CDA header : A recipient of a CDA document must be able to parse and interpret the complete CDA header. Because applications may choose to display demographic and other CDA header data drawn from a central master directory, the rendering of the CDA document header is at the discretion of the recipient. In addition, rendering of the CDA document header can be dependent on local business practice and context of use (e.g. electronic health record, de-identified scenario). Where a document originator wants to suggest a rendering, they can include one or more XML style sheets with an exchanged CDA document. Use of these style sheets is at the discretion of the recipient.
• Parse and interpret the CDA body sufficiently to be able to render it : A recipient of a CDA document must be able to parse and interpret the body of a CDA document sufficiently to be able to render it, using the following rendering rules:
  • If the CDA Body is non-XML, it will need to be rendered with a software tool that recognizes its particular MIME media type.
  • If the CDA Body is structured, the label of a section, as conveyed in the Section.title component, must be rendered. The absence of the Section.title component signifies an unlabeled section.
  • If the CDA Body is structured, the contents of the Section.text field must rendered per the rules defined in Section Narrative Block.
• A recipient of a CDA document is not required to parse and interpret the complete set of CDA entries contained within the CDA body. Within a local implementation, trading partners may ascribe additional recipient responsibilities to parse and interpret various entries.
• A recipient of a CDA document is not required to validate a CDA document against referenced templates. Within a local implementation, trading partners may ascribe additional recipient responsibilities for template validation.

1.3.2 Originator Responsibilities

• Properly construct CDA Narrative Blocks : An originator of a CDA document must ensure that the attested portion of the document body is structured such that a recipient, adhering to the recipient responsibilities above, will correctly render the document. This includes:
  • If the CDA Body is structured, the label of a section must be conveyed in the Section.title component. The absence of the Section.title component signifies an unlabeled section.
  • If the CDA Body is structured, the attested narrative contents of a section must be placed in the Section.text field, regardless of whether information is also conveyed in CDA entries. Attested multimedia referenced in the narrative must be added as ObservationMedia and/or RegionOfInterest CDA entries.
  • If the CDA Body is structured, the contents of the Section.text field must be created per the rules defined in Section Narrative Block.
• An originator of a CDA document is not required to fully encode all narrative into CDA entries within the CDA body. Within a local implementation, trading partners may ascribe additional originator responsibilities to create various entries.

1.4 CDA Extensibility

NOTE: See XML ITS - Informal Extensions for a complete discussion of V3 XML Extensibility rules.

Locally-defined markup may be used when local semantics have no corresponding representation in the CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging meaning that is not shared. In order to support local extensibility requirements, it is permitted to include additional XML elements and attributes that are not included in the CDA schema. These extensions should not change the meaning of any of the standard data items, and receivers must be able to safely ignore these elements. Document recipients must be able to faithfully render the CDA document while ignoring extensions.

Extensions may be included in the instance in a namespace other than the HL7v3 namespace, but must not be included within an element of type ED (e.g., <text> within <procedure>) since the contents of an ED datatype within the conformant document may be in a different namespace. Since all conformant content (outside of elements of type ED) is in the HL7 namespace, the sender can put any extension content into a foreign namespace (any namespace other than the HL7 namespace). Receiving systems must not report an error if such extensions are present.

When these extension mechanisms mark up content of general relevance, HL7 encourages users to get their requirements formalized in a subsequent version of the standard so as to maximize the use of shared semantics.

2 CDA Overview

(content on separate page)

3 Introduction to CDA Technical Artifacts

A complete understanding of CDA requires an understanding of the normative artifacts used to define the specification. For CDA R2.1, "Section 5 - CDA Design" will be considered the definitive source for CDA conformance rules. With this revision, the contents of Section 5 have been created based on the the CDA R2.1 RMIM and the CDA specific conformance strategy that allows some attributes to be assumed by receivers, thus reducing document size. Readers are encouraged to reference the CDA RMIM (diagram) and the CDA Hierarchical Description (spreadsheet), as well as other sections of the CDA standard, to better understand CDA and best practices using CDA. Implementers need to understand that while a CDA instance must validate against the CDA Schema, it must also need to adhere to the conformance rules called out in Section 5. Be aware that not all rules can be defined for CDA are found in it's W3C schema; requirements for human readability, and appropriate representation of clinical content, are just some examples. As in CDA R2, the HL7 RIM remains the definitive source for class and attribute definitions.

The following sections summarize the artifacts used by CDA, and how they can be used by those seeking to implement or understand the CDA specification.

3.1 HL7 Reference Information Model

The definitive description of the HL7 Reference Information Model can be found here.

The HL7 RIM is the definitive reference source for class and attribute definitions. The CDA specification does not exhaustively replicate RIM definitions, but instead refers the reader to the RIM for complete definitions. While CDA may further constrain RIM definitions, at no time will CDA definitions conflict with those in the RIM.

CDA, Release Two is derived from HL7 RIM, Version 2.35.

Where a reader needs to see the complete definition of a RIM attribute or class, they should refer to the HL7 RIM.

3.2 HL7 V3 Data Types

HL7 defines both an abstract data type specification, which is the definitive reference, and an XML-specific data type representation.

Data types define the structural format of the data carried within a RIM attribute and influence the set of allowable values an attribute may assume. Some data types have very little intrinsic semantic content. However HL7 also defines more extensive data types such as the one for an entity's name. Every attribute in the RIM is associated with one and only one data type.

CDA, Release Two uses the HL7 V3 Data Types, Release One abstract and XML-specific specification.

A reader will often find that the XML-specific description of a data type is sufficient for implementation, but at times will want to refer to the abstract data type specification for a more comprehensive discussion.

3.3 HL7 Vocabulary Domains

The definitive description of HL7 V3 Vocabulary Domains can be found here.

Vocabulary domains represent value sets for coded CDA components. These domains can include HL7-defined concepts or can be drawn from HL7-recognized coding systems such as LOINC or SNOMED. The HL7 Vocabulary chapter is the definitive reference source for the definitions of HL7-defined concepts. In this specification, references to code bindings using "D:concept-domain" indicates that a concept domain has been specified and the documentation defined in the RIM Vocabulary chapter should be referenced for an understanding of the code system9s) to be used when creating a CDA document.

Valuesets referenced in CDA R2.1 can be found here. An alternative to Concept Domain binding, the Valueset binding allows for a subset of codes to be bound to a CDA coded attribute. In this specification references to using "V:value set" indicates that a value set has been specified. Note: A number of value set bindings have been specified using "<= code", where the "<=" binding indicates a given code and all subordinate coded concepts defined as "type of" that code, within the code system referenced, are allowed. In Section 5, those bindings are mapped to the equivalent valueset for the readers reference.

Lastly, single code bindings can also be found in CDA R2.1 specification. Where a single code binding is being specified, the specification will indicate "= code" syntax. In Section 5, single code bindings are defined as Fixed bindings, as only the code specified can be used in CDA document instances. A number of these code bindings have a minimum cardinality of zero, as indicated by the [0..1] cardinality reference. In the cases were the code is fixed and the minimum cardinality is zero, instances of CDA conformant documents are not required to include the attribute and code in the instance, as receivers are required to interpret the document instance as though the coded attribute had been sent.

Vocabulary domains have a coding strength that can be "Closed" or "Coded, No Extensions" (CNE), in which case the only allowable values for the CDA component are those in stated value set; or "Open" or "Coded, With Extensions" (CWE), in which case values outside the stated value set can be used if necessary. Every vocabulary domain has a unique HL7-assigned identifier, and every concept within a vocabulary domain has a unique code.

Where a coded CDA component is associated with a Closed or CNE value set, the allowable values are fixed by the standard, and are enumerated as shown in the following example:

Table X: Value set for relatedDocument.typeCode

v:x_ActRelationshipDocument [2.16.840.1.113883.1.11.11610] (CLOSED)
Code	Display Name		Code	Display Name
APND	is appendage		RPLC	replaces
XFRM]	transformation
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

A number of vocabulary domains and coding systems already in existence (e.g., LOINC, SNOMED) may be used to encode concepts in CDA documents (e.g., Section.code, Observation.code). These domains are referenced as external domains according to HL7 V3 processes. Where a coded CDA component is associated with an Open or CWE vocabulary domain, a preferred value set may be specified by the standard (such as for ClinicalDocument.code or for ClinicalDocument.confidentialityCode). Where the standard does not enumerate any values, the implementor is free to choose from any external source, such as LOINC or SNOMED or some other realm-specific vocabulary.

Where a reader needs to see the complete definition of an HL7-defined value, they should refer to the HL7 Vocabulary chapter.

3.4 HL7 CDA R-MIM

The definitive description of the HL7 V3 model refinement process, R-MIM development and interpretation can be found here.

The CDA R-MIM is described below (see CDA R-MIM).

HL7 specifications derived from the HL7 RIM use a process known as "cloning" to refine domain specific models from the base HL7 RIM. When a refined model makes use of a specialization of an HL7 RIM class, the new class in the refined model is known as a clone of the HL7 RIM class. These specializations may further constrain the base class, for example, by specifying more restrictive attribute cardinality or by further constraints on the allowed vocabulary values. Multiple clones of a particular HL7 RIM class may appear in a refined model, each representing a different specialization.

The CDA R-MIM is a graphical representation of the CDA specification. It is presented using diagramming conventions and notations that were developed by HL7 to represent the specific semantic constructs contained in the critical, "back-bone" classes of the RIM. Although it could be represented in UML notation, as the RIM is, the HL7 notation provides more details about the specific constraints and class clones being represented. The HL7 diagramming convention abbreviates some relationship conventions, enabling diagrams to be smaller and more concise and to convey more information visually.

The CDA R-MIM is a graphical aid to understanding the specification. Because the CDA Hierarchical Description, and subsequently the CDA Schema, are derived from the R-MIM, the R-MIM serves as a good basis for describing the standard. The narrative description of the specific clones used by CDA is organized to correspond with the R-MIM.

3.5 HL7 CDA Hierarchical Description

The definitive description of developing and interpreting HL7 Hierarchical Descriptions can be found here.

The CDA HD is described below (see CDA Hierarchical Description).

A Hierarchical Description is a tabular representation of the sequence of elements (i.e., classes, attributes and associations) represented in an R-MIM and that define the structure of the instance without reference to XML or any other implementation technology

The CDA HD is the definitive source for CDA conformance rules, and serves as the source from which the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also adhere to the conformance rules stated in the CDA Hierarchical Description. For CDA, Release 2.1, the CDA HD is uniquely identified by the string "POCD_HD000040UV". As described below (see Clinical Document), this value must be included in a CDA instance to serve as an unambiguous reference to the CDA, Release 2.1 specification.

3.6 HL7 CDA XML Implementation

The CDA Schema is derived through the use of the HL7 XML Implementation Technology Specification (ITS). The definitive description of HL7 XML ITS and the process used to go from Hierarchical Description to Schema can be found here.

The CDA Schema is described below (see CDA XML Implementation).

CDA, Release 2.1 is based on the HL7 V3 XML Implementable Technology Specification for V3 Structures, Release One.

Specific enhancements to the CDA Schema, above and beyond those defined in the HL7 V3 XML ITS, are described below in CDA XML Implementation.

Looking at the CDA R-MIM, a reader familiar with the RIM, the HL7 Development Framework and its rules for XML implementations, can identify the corresponding XML elements and attributes. Due to algorithmic generation of some of the element names, the correspondence may be unclear, and the reader should refer to the HL7 V3 XML ITS for more details.

3.7 Backwards and Forwards Compatibility

NOTE: A detailed list of all changes between CDA, Release 2.0 and CDA, Release 2.1 can be found in the appendix (see Changes from CDA Release 2.0).

CDA Release 2.1 represents a minor dot release enhancement to the CDA Release 2.0 standard. As such, the changes introduced into the CDA R2.1 schema should not generate errors when processing a legacy CDA R2.0 document instance. However, with the inclusion of new RIM attributes and RIM structural vocabulary (Class Codes, Mood Codes and Type Codes) CDA R2.1 will likely require changes to implementation guides previsouly based on CDA R2.0, when citing CDA R2.1 as their base. The enhancements provided are intended to reduce the usage of previous extensions and improve the semantic modeling capabilities found in CDA.

The following updates have been made to the CDA document model, these include, but are not necessary limited to:

1. CDA R2 errata will be included
2. Extensions previously required and cited by CDA Implementation Guides
3. Attributes omitted from the classes derived from the RIM, where use cases exist for their inclusion
4. Additional values to value sets such as Mood codes, will be considered to ensure consistency with modeling from other committees
5. The inclusion of tables within tables in the narrative block will be considered as a minor presentation markup change.
6. Include current language about bindings if appropriate
7. Additional informative content will be considered for a number of topics:
   1. CDA Implementation Guides and Templating
   2. Vocabulary Binding Syntax in CDA
   3. Exchanging CDA documents

This section describes the types of changes that can be introduced to a new release of CDA and CDA principles of forward and backward compatibility. In general, changes can include the addition of new components; a renaming of components (including XML element and attribute names in the CDA Schema); a deprecation of components defined in a prior release; a change in cardinality of a component (to loosen); or a change in a vocabulary domain of a component {to add or change values, to change between Open (CWE) and Closed (CNE)}. The following set of guiding principles defines how CDA can continue to evolve, while protecting the investment implementers have made through their adoption of earlier releases.

• Documentation : A new release of CDA will enumerate all substantive changes from the previous release.
• Attested content : Attested, human readable content must be completely loss-less across CDA releases. Backwards and forwards compatibility on the attested content will be supported such that it will be possible for an automated transformation script to translate the human readable content in both directions.
• New components : A new release of CDA can introduce new components. To preserve roundtrip translation capability, a translation from the new release to a prior release must represent the new components as extensions (e.g. local markup or local namespace).
• Renaming : A new release of CDA can rename components (including XML element and attribute names). Where this occurs, a mapping table will list all changes. Renaming will adhere to the naming convention articulated above (see XML Markup of CDA Documents).
• Deprecated components : A new release of CDA can deprecate components defined in a prior release. Deprecated components will be removed from the subsequent release of the standard, and therefore their use is not recommended.
• Cardinality : A new release of CDA can change the cardinality of a component. Where an optional component becomes required, a translation between releases requires a dummy value or a null value.
• Changes to vocabulary domain : A new release of CDA can change the vocabulary domain of a component. Where this occurs, a mapping table will list changes.
• Change within Closed (CNE) : Where a value in a Closed (CNE) domain in a prior release is no longer present or has been renamed, a mapping table will indicate what the current value should be.
• Change within Open (CWE) : When a CWE domain is expanded, users should begin using the new codes in addition to any equivalent local codes they may already be using.
• Change from Open (CWE) to Closed (CNE) : To preserve roundtrip translation capability, a translation between releases must represent unrecognized components as extensions (e.g. local markup or local namespace). Ideally these situations will surface during a ballot cycle, allowing the Closed (CNE) domain to be sufficiently inclusive.

These guiding principles have lead to the current approach, defined in this Release 2.1 of the CDA standard. The goal is to ensure that the documents created using Release 2.0 can be processed by implementation adopting CDA R2.1 (with legacy extension references) with no loss of machine processable content or loss of attested, human-readable content.

4 CDA Document Exchange in HL7 Messages

NOTE: The exact method by which a CDA instance is packaged and exchanged is outside the scope of this standard. While the MIME packaging method described here is not normative, it does illustrate one mechanism that meets the document exchange requirements described below.

Any CDA exchange strategy must accommodate the following requirements:

• All components of a CDA document that are integral to its state of wholeness (such as attested multimedia) are able to be included in a single exchange package.
• Content needing to be rendered if exchanging across a firewall where the links won't be traversable, must be able to be included in a single exchange package.
• Additional files associated with a CDA document to provide the recipient with the sender's rendering suggestions (such as one or more style sheets) are able to be included in a single exchange package.
• There is no need to change any of the references (e.g., a reference to attested multimedia in a separate file) within the base CDA document when creating the exchange package.
• There is no need to change any of the references (e.g., a reference to attested multimedia in a separate file) within the base CDA document when extracting the contents of an exchange package.
• There is no need to change any values of attributes of type XML ID when creating the exchange package.
• There are no restrictions on the directory structure used by receivers. Receivers can place the components of the CDA document into directories of their choosing.
• Critical metadata about the CDA instance needed for document management (e.g. document state, document archival status) must be included in the exchange package. (For a complete discussion of clinical document metadata, document management, and HL7 V3 document states and state transitions, refer to the HL7 V3 Medical Records specification).

From the perspective of a V2.x, V3 message and FHIR, a CDA document can be thought of as a multimedia object that can be exchanged as a Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type (ED).

The current MIME recommendation is to follow the approach described in the Internet standard RFC 2557 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", which is the approach for the MIME encapsulations of aggregate documents used by ebXML and DICOM.

In V2.x, CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents (such as MDM). Within the OBX segment, the MIME package is placed in OBX.5 (Field 00573 Observation value), encoded as a V2.x encapsulated data type. The value of OBX.2 (Field 00570 Value Type) should be set to "ED". The value of OBX.3 should be the same as ClinicalDocument.code.

Many fields in the message will overlap in meaning with fields in the CDA document. The following table shows the correspondence between the HL7 V2 MDM message's TXA segment and components of CDA.

Table X: HL7 V2 TXA Segment :: CDA Mapping

TXA Field	CDA Component
TXA-2 Document type	ClinicalDocument.code
TXA-4 Activity date/time	ServiceEvent.effectiveTime
TXA-5 Primary activity provider code/name	ServiceEvent performer
TXA-6 Origination date/time	ClinicalDocument.effectiveTime
TXA-7 Transcription date/time	dataEnterer.time
TXA-9 Originator code/name	author
TXA-11 Transcriptionist code/name	dataEnterer
TXA-12 Unique document number	ClinicalDocument.id
TXA-13 Parent document number	ParentDocument.id
TXA-14 Placer order number	Order.id
TXA-18 Document confidentiality status	ClinicalDocument.confidentialityCode
TXA-22 Authentication person, time stamp	authenticator, legalAuthenticator
TXA-23 Distributed copies	informationRecipient

The following example shows a non-normative, valid use of RFC 2557 in a V2 message. Several other valid representations are possible.

Example X

MSH|...
EVN|...
PID|...
PV1|...
TXA|...
OBX|1|ED|11492-6^History and Physical^LN||
   ^multipart^related^A^
   MIME-Version: 1.0
   Content-Type: multipart/related; boundary="HL7-CDA-boundary";
   type="text/xml"; start="10.12.45567.43"
   Content-Transfer-Encoding: BASE64

   --HL7-CDA-boundary
   Content-Type: text/xml; charset="US-ASCII"
   Content-ID: <10.12.45567.43>

   ... Base 64 of base CDA document, which contains 
      ...
      <observationMedia classCode="OBS" moodCode="EVN">
         <id root="10.23.4567.345"/> 
         <value mediaType="image/jpeg">
            <reference value="left_hand_image.jpeg"/>
         </value>
      </observationMedia>
      ...

   --HL7-CDA-boundary
   Content-ID: <10.23.4567.345>
   Content-Location: canned_left_hand_image.jpeg
   Content-Type: image/JPEG

   ... Base64 image ...

   --HL7-CDA-boundary--

   ...

In V3, CDA documents can be exchanged in any message that can exchange documents (such as the HL7 V3 Medical Records messages). The Act.text RIM attribute contains the MIME package, encoded as an encapsulated data type.

As is the case with V2, many fields in the V3 message will overlap in meaning with fields in the CDA document. Since CDA and V3 Medical Records messages derive from a common model, the correspondence is clear, as shown in the following table.

Table X: HL7 V3 Medical Records :: CDA Mapping

HL7 V3 Medical Records Component	CDA Component	Comments
ClinicalDocument	ClinicalDocument	Medical Records includes attributes not present in CDA (text, statusCode, availabilityTime, reasonCode, completioncode, storageCode, copyTime); CDA includes attributes not present in Medical Records (title).
authenticator	authenticator
legalAuthenticator	legalAuthenticator
dataEnterer	dataEnterer
EncounterEvent / encounterPerformer	encompassingEncounter / encounterParticipant; serviceEvent / performer	The Medical Records encounterPerformer is split into two CDA participants.
responsibleParty	responsibleParty
custodian	custodian
participant	participant
informationRecipient	informationRecipient
recordTarget	recordTarget
author	author
subject	subject	The Medical Records subject is a directory of all subjects listed in the document.
relatedDocument / ParentDocument	relatedDocument / parentDocument
documentationOf / Event	documentationOf / serviceEvent
inFulfillmentOf / Order	inFulfillmentOf / order
componentOf / EncounterEvent	componentOf / encompassingEncounter

The following example shows a non-normative, valid use of RFC 2557 in a V3 message. Several other valid representations are possible.

Example X

<someMessage>
  <Act.Code code="11488-4" 
    codeSystem="2.16.840.1.113883.6.1" 
    displayName="Consultation note"/>
  <Act.text type="multipart/related">
MIME-Version: 1.0
Content-Type: multipart/related; boundary="HL7-CDA-boundary";
type="text/xml"; start="10.12.45567.43"
Content-Transfer-Encoding: BASE64

--HL7-CDA-boundary
Content-Type: text/xml; charset="US-ASCII"
Content-ID: <10.12.45567.43>

 ... Base 64 of base CDA document, which contains 
  ...
  <observationMedia classCode="OBS" moodcode="EVN">
    <id root="10.23.4567.345"/> 
    <value mediaType="image/jpeg">
      <reference value="left_hand_image.jpeg"/>
    </value>
  </observationMedia>
  ...

--HL7-CDA-boundary
Content-ID: <10.23.4567.345>
Content-Location: canned_left_hand_image.jpeg
Content-Type: image/JPEG

 ... Base64 image ...

--HL7-CDA-boundary--

      </Act.text>
    </someMessage>

In FHIR DSTU 2, CDA documents are to be exchanged using the FHIR http://www.hl7.org/FHIR/documentreference.htmlDocumentReference resource. A DocumentReference resource is used to describe a document that is made available to a healthcare system. A document is some sequence of bytes that is identifiable, establishes its own context (e.g., what subject, author, etc. can be displayed to the user), and has defined update management. The DocumentReference resource can be used with any document format that has a recognized mime type and that conforms to this definition.

A client can ask a server to generate a document reference from a document. The server reads the existing document and generates a matching DocumentReference resource, or returns one it has previously generated. Servers may be able to return or generate document references for the following types of documents, FHIR Documents, CDA Documents, or Other Documents.

For CDA documents, the uri returned is a reference to a Binary end-point that returns either a CDA document, or some kind of CDA Package that the server knows how to process (e.g., an IHE .zip, Multipart Mime package)

The operation is initiated by a named query, using _query=generate on the /DocumentReference end-point:

 GET [service-url]/DocumentReference/?_query=generate&uri=:url&...

The "uri" parameter is a relative or absolute reference to one of the document types described above. Other parameters may be supplied:

Name	Meaning
persist	Whether to store the document at the document end-point (/Document) or not, once it is generated. Value = true or false (default is for the server to decide).