(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. For CDA R2.1, "Section 5 - CDA Design" will be considered the definitive source for CDA conformance rules, this differs from CDA R2.0 where the HMD was considered the source. We believe this change has no impact on backwards/forwards compatibility. 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.

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

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

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

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.