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:

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

NullFlavor

Code	Print Name	Definition / Description
NI	No Information	No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the de-fault exceptional value.
OTH	other	The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
NINF	negative infinity	Negative infinity of numbers.
PINF	positive infinity	Positive infinity of numbers.
UNK	unknown	A proper value is applicable, but not known.
ASKU	asked but unknown	Information was sought but not found (e.g., patient was asked but didn't know)
NAV	temporarily unavailable	Information is not available at this time but it is expected that it will be available later.
NASK	not asked	This information has not been sought (e.g., patient was not asked)
TRC	trace	The content is greater than zero, but too small to be quantified.
MSK	masked	There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information. Note: using this null flavour does provide information that may be a breach of confi-dentiality, even though no detail data is pro-vided. Its primary purpose is for those cir-cumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
NA	not applicable	No proper value is applicable in this context (e.g., last menstrual period for a male).
NP	not present	Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.

ANY as the generic data type

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see "Missing values: nullFlavors"). The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type is known and ANY is always replaced by a particular data type in an instance. One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute @xsi:type. This infor-mation can be used by the receiver to validate and process the value. Attributes of an element with this data type are

Attribute	DT	Conf	Description
@nullFlavor	CS	-	Classification of the missing value, see 3.3.

dtr1-1-ANY

If there is a nullFlavor, there shall be no other attribute or element, unless it's nullFlavor="OTH". In that case @codeSystem or originalText (see “code” data types) may have a value.

XML Example snippet

A value of data type ANY in the model, instantiated as CE
<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>

A value of data type ANY in the model, instantiated as PQ
<value xsi:type="PQ" value="12" unit="mL"/>

A value of data type ANY in the model, instantiated as ED
<value xsi:type="ED">this is text</value>

Intervals (IVL)

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

• a lower <low> and an upper boundary <high> (a),
• a lower <low> boundary and width <width> (b)
• an upper boundary and width <width> (c) or
• the middle of the interval <center> and a width <width> (d).

Several possibilities to determine closed intervals

Identification mechanisms

Object Identifiers (OIDs)

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily. It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used. An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo. In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples. OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes. Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

• www.oid-info.com,
• www.hl7.org,
• HL7 OID registry in the UK,
• OID registry Germany.

All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Reg-istration is regulated by a set of rules, described in the corresponding chapter of this document. Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 .

HL7 International has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org. From a policy perspective it is common practice in several healthcare related OID regis-tries (HL7 International at hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/ OID_Frontend) to distinguish at least between the fol-lowing types of OIDs:

Recommended OID sub-branches for different artefacts

Arc	Description
.3	organizational bodies and groups
.4	identifier systems and namespaces
.5	code systems
.7	document artefacts
.9	conformance profiles
.10	templates
.11	value sets
.19	examples
.99	experimental

Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

Recommended OID sub-branches for different artefacts

Artefact code Description	Recommended	OID suffix
DS	dataset	.77.1
DE	dataset concept	.77.2
SC	scenario	.77.3
TR	transaction in scenario	.77.4
CS	code system	.77.5
IS	issue	.77.6
AC	actor in scenario	.77.7
CL	concept list in dataset	.77.8
EL	element in template	.77.9
TM	template	.77.10
VS	value set	.77.11
RL	rule for instances	.77.12
SX	test/example scenario	.77.18
EX	test/example instance	.77.19
QX	qualification test/example	.77.20
TX	test/example data element	.77.21
CM	community	.77.22
MP	concept map	.77.24

In ART-DECOR a newly created project uses these OID branches automatically.

Instance identification

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient num-ber can be represented as

• 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
• 67543242 as the @extension, representing the patient number within the sys-tem defined by the @root attribute.

Coding scheme identification

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the @codeSystem attribute of coded elements. Both attributes @code and @codeSystem together allows a correct interpretation of concept and code.

List of identification schemes

The following are OIDs for commonly used identification schemes.

Commonly used identification scheme OIDs

OID	Identification System Name	Description	Issuer
1.2.276.0.76.4.8	KV-Nummer	Krankenversichertennummer
1.2.276.0.76.4.17	BSNR	Betriebsstättennummer
1.2.276.0.76.4.16	LANR	lebenslange Arztnummer

List of code systems

The following are OIDs for code systems.

Commonly used code system OIDs

OID	Code System Name	Description	Issuer
2.16.840.1.113883.6.1	LOINC	Logical Observation Identifiers Names and Codes (LOINC)	Regenstrief Institute
2.16.840.1.113883.6.96	SNOMED CT	Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT)	SNOMED International
1.0.3166.1.2	ISO 3166-1 (second edition)	Country codes as per ISO 3166-1:2007	ISO

Vocabulary

Code Systems

Within HL7, a Code System is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC. To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings. For example, “M” in the administrative gender table (AdministrativeGender, OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (MaritalStatus, OID 2.16.840.1.113883.5.2) means “married”. In this specification, code system tables are not presented in detail.

Value Sets

A Value Set represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set. Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated ex-pressions drawn from multiple code systems. Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

Example presentation of the value set “MaritalStatus”

Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides. In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed. An example, in the implementation specification the constraint on the model element maritalStatusCode is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 MaritalStatus”. To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say: <maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>

In this specification, value set tables are not presented in detail.

Binding strength

There is an optional vocabulary strength for data types that support that feature (cod-ed concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Speci-fication CNE is handled as required and CWE is handled as extensible.

Binding Strengths

Strength	Description
required	Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
extensible	Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
preferred	Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
example	Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.

Mismatches with required lead to validation errors (SHALL logic). Mismatches with ex-tensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.