HL7 CDA Core Principles

Introduction

This implementation guide specifies the Core Principles of using the Clinical Document Architecture .

Scope

This guide focuses on Data Types Release 1 . Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another im-plementation guide that will be published when ISO data types are used.

Focus of this document: HL7 Version 3 Data Types for CDA

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.

• Common aspects: explains common aspects of use of CDA and XML
• Data types: gives an overview and detailed specification of all data types used in CDA
• Identification schemes: explains major aspects of identification and the use in CDA
• Use of vocabulary: explains major aspects of vocabulary use in CDA.

Background

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

Legend of symbols

In this document several symbols are used.

	This is an important item
	This is a known open issue
	This is a frequently asked question (FAQ) with answer
	This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.

Version history

Version	Date	Description	Author
1.1	2019-04-24	Refurnished guide based on earlier work	Kai U. Heitmann

Common aspects

Use of XML

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange for-mat. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

Character Set

XML Example snippet

<?xml version="1.0" encoding="utf-8"?>

CDA document structure

The XML namespace for CDA Release 2 documents is urn:hl7-org:v3. This must be correctly mentioned in every XML instance. CDA XML documents starts with the root element ClinicalDocument.

XML Example snippet

<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
    xmlns:xsi="http://www.w3.org/2001/XMLSchemma-instance">

    <!-- CDA Header --> 
          ...
    <!-- CDA Body -->
    <component>
        <structuredBody>
           ...
        </structuredBody>
    </component>

</ClinicalDocument>

Data types

Introduction

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:

• Abstract Data type definition
• XML ITS for data types

Data types are properties of model class attributes and the basic building blocks of in-formation in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

CDA structure (left) and the data type specification (right)

XML representation of data types

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses. The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

Attributte	DT	Conf	Description
(name of the model attribute or XML el-ement)	Data type	Conformance, i.e. O, R, M	Textual description

XML attributes (data type properties) are denoted as @attribute in order to distinguish their names from XML elements. Example: in the example model above, the data type of the id attribute's is II (Instance Identifier). The corresponding XML attributes for that data type include @root and @extension.

XML Example snippet

<id   root="…"   extension="..." />

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

Exceptions using XML element content

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content. Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

XML Example snippet

<addr>
    <streetAddressLine>Thormøhlens gate 12</streetAddressLine>
    <postalCode>5006</postalCode>
    <city>Bergen</city>
</addr>

Combined data types

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value. In combined data types the substructure (e.g. <low> <high> in an interval) are repre-sented as child elements of the relevant data type element.

XML Example snippet

<effectiveTime>
    <low value="20110701"/>
    <high value="20110729"/>
</effectiveTime>

Conformance information

The conformance indicators distinguish kinds of conformance information described shortly here.

• O: An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
• R: For required items, lower cardinality is always zero or 1.

- Elements must be present and populated with data if present in the send-ing system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).

- Attribute flagged as required must be present in the instance and populated.

• M: For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
• NP: no data may be present at all (not permitted)
• C: conditional conformance; typically a conformance table shows the circum-stances (conditions) derived from information in the instance and the corre-sponding cardinalities and conformance statements.

Missing values (null flavor)

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a @nullFlavor attribute expresses the omission of data. Note that missing data is not al-lowed for mandatory elements (see above).

XML Example snippet

<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

The codes for the @nullFlavor attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute @codeSystem) specified.