(content on separate page)

2 Introduction to CDA Technical Artifacts

A complete understanding of CDA requires an understanding of the normative artifacts used to define the specification. The CDA Hierarchical Description 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. The CDA Hierarchical Description is derived from the CDA R-MIM, which in turn is derived from the HL7 Reference Information Model (RIM). The HL7 RIM is 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.

2.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 Release-4 of the ANSI Normative RIM I.e. 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.

2.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.

2.3 HL7 Vocabulary Domains

Change to: Vocabulary Use in CDA

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 systems to be used when creating a CDA document.

Value sets referenced in CDA R2.1 can be found here. An alternative to Concept Domain binding, the value set binding allows for a defined set of codes from one or more code systems 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 that the value set is defined as a given code and all of it's descendant (subtype) coded concepts within the specified code system. In Section 5, those bindings include a reference to the value set specification for the reader's convenience..

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] wire cardinality reference. In the cases where the code is fixed and the minimum wire cardinality is zero, instances of CDA conformant documents are not required to include the attribute in a document instance. See 1.3.1 Recipient Responsibilities for more information.

Vocabulary domains have a coding strength that can be "Closed", in which case the only allowable values for the CDA component are those in stated value set; or "Open", 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 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 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.

2.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.

2.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_HD000040UV02". 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.

2.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.

2.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:

CDA R2 errata will be included
Extensions previously required and cited by CDA Implementation Guides
Attributes omitted from the classes derived from the RIM, where use cases exist for their inclusion
Additional values to value sets such as Mood codes, will be considered to ensure consistency with modeling from other committees
The inclusion of tables within tables in the narrative block will be considered as a minor presentation markup change.
Include current language about bindings if appropriate
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 and Closed binding types}. 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 (in Release 2.1), a translation from Release 2.0 to Release 2.1 CDA document will require a dummy value or 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 : Where a value in a Closed 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 : When an Open 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 to Closed : 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 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 implementations adopting CDA R2.1 (with legacy extension references) with no loss of machine processable content or loss of attested, human-readable content.

As a result two versions of the CDA R2.1 schema are planned to be made available by HL7.

The first will include only local extensions approved specifically by Structured Documents Work Group (SDWG) for CDA R2.1.
The second will additionally include the legacy CDA R2.0 approved extensions, to better support processing of both CDA R2.0 & R2.1 document instances. Note that implementers choosing to process both CDA R2.1 and CDA R2.0 documents using the second scheme will need to manage information appearing in both CDA R2.1 elements and legacy extensions defined for CDA R2.0.