XML Implementation Technology Specification - Data Types

Preface

This document specifies the HL7 Version 3 Data Types in the context of their XML Implementation Technology Specification (ITS). Although ITS dependent, this document can stand on its own for the purpose of this ballot.

This document is based on the Data Types Abstract Specification, which defines the data types on an abstract layer independent from representation.

Vocabulary tables within this specification list the current contents of vocabulary domains for ease of reference by the reader. However, at any given time the normative source for these domains is the vocabulary tables in the RIM database. For some large domains, only a sample of possible values is shown. The complete domains can be referenced in the vocabulary tables by looking up the domain name associated with the table in the RIM vocabulary tables.

Acknowledgements

The following persons served as co-editors of this document or have otherwise made major contributions to this specification. Wes Rishel (Gartner Group) has driven the initial forumlation of the approach. Paul V. Biron (Kaiser Permanente) has prepared the first ballot draft and continued to be a major support in all XML matters. Douglas Pratt (Siemens) has contributed the initial distillation of the abstract definitions. Gunther Schadow (Regenstrief Institute, Inc.) has done most of the editing, document automation, and maintenance during the many ballot cycles. Major contributions of thought are from Mark Tucker (Regenstrief Institute). Lloyd McKenzie (IBM), and Grahame Grieve (Kestral Computing Pty. Ltd.) have helped in the cleaning up of many aspects of the recent ballot draft.

Introduction

What is a Data Type? Data types are the basic building blocks used to construct messages, computerized patient record documents, business objects and their transactions. Data types define the meaning of any given field's value. Without knowing a field's data type, it is impossible to interpret the field's value.

Representation of Data Values. On an abstract layer, independent from representation, data types define properties of values. When values are represented, some of their properties are directly represented as atomic literal forms or as data structures. At that point we call those properties "components". On the representation layer we can also distinguish simple data types, represented as atomic literal forms, from complex ones, represented as structures with components. For the implementor, it is important to realize that data types have more properties than shown as components, and that it only depends on the implementation technology and ITS specification what data types are simple or complex and which of their properties are represented as "components" and which are inferred from those components.

This specification defines standard representations for data values in XML only. Other ITS, and programming environments may choose different representations and data structures, all of which must be consistent with the Data Types Abstract Specification.

Organization of this Specification

This specification is divided in two major parts:

1. Basic data types
2. Generic data types (templates)

The fully specified data types are organized approximately in the same order in which they appear in the Data Types Abstract Specification, divided in roughly three categories: (1) boolean, binary, text and multimedia, (2) codes and identifiers, and (3) quantitative data types.

Generic types are about collections (sets, lists, etc.) and common data type extensions to deal with uncertainty, time-dependency and other qualifications of data values. Finally, the framework of specifying complex timing patterns (e.g., for scheduling periodic activities) is mostly specified in terms of generic data types.

The following table lists all data types specified in the XML ITS.

Element and Attibute Forms

Data types may be represented in either an Element form or an abbreviated Attribute form. The context where the data type is used will define which form is to be used.

In the Element form, which is the normal case, the data type is represented using an XML elment. This is usually encountered for high-level HL7 content derived from the Reference Information Model (RIM).

In the abbreviated Attribute form, the data type is represented by a single XML attribute. This form is used when the data type is a property of other data types or when the data type is used in a Stuctutral RIM attribute. If an Attribute form is allowed, it is defined in the narrative.

Any data types represented in an Attribute form cannot convey any form of null flavor. If the attribute is not present in the XML instance then the data type has a null flavor of NI.

Defining the XML Representation of Data Types

This standard specifies the XML representation for the HL7 data types. The XML representation is described in several different ways:

• Narrative
• Template

XML Templates

The XML Template format used in this document has been adapted from the format used in the W3C XML Schema specification.

This example template shows the attributes and elements for the ED and EN types. The template describes a set of XML attributes and elements that may be used to represent the semantics of the data type described in the Data Types Abstract Specification. There may not be a direct mapping between the XML attributes and elements and the properties of the type described in the Data Types Abstract Specification. If the name of the XML attribute or element matches a property name in the Data Types Abstract Specification then the semantics of the content will be as described in the Data Types Abstract Specification, otherwise the narrative will explain the use of the attribute or element.

This specification describes types, not elements, so the element name for a given type is not known. The character x is used in place of the element name, which will be determined by the context in which the type is used, either in this specification, or the name of the RIM attribute.

For each attribute, the XML name of the attribute is shown, followed by either a set of possible values or a type name. Allowed values are shown separated by vertical bars between parentheses. A default value, if applicable, is specified following a colon. If the attribute is assigned a type, then it is represented using the Attribute format described for the specified type. Some attributes are given the type CS*. For these attributes, the valid content is a whitespace separated list of CS codes.

For the element and text content, only the element names are shown. The type of the elements is described in the narrative associated with the type. The presence of a * denotes that the element or set of elements grouped by parentheses may appear more than once.

Some types may contain text data. This is represented using #PCDATA. Any text content must be properly escaped character content with no markup.

All attributes and elements are optional. If an attribute or element is not present, then the data type property it represents has the nullFlavor NI. Although all attributes and elements are optional, the datatype represented in the XML instance must be a valid instance of the datatype - it must meet all the constraints and specifications from the Data Types Abstract Specification.

The rules which determine which data types can be substituted for other data types are defined in the Data Types Abstract Specification.

Validation against Schema and Predicates

HL7 artefact processing systems are not required to validate any HL7 XML data type representations against any schema or XPath predicates. Systems may wish to perform schema validation to gain access to the Post Schema Validation Instance [http://www.w3.org/TR/xmlschema-1#key-psvi], but there will be no requirement to do this in order to properly understand the message, though all systems must be aware of the default values that are not represented in the instance by some means.

NOTE: All XML data type representations must conform to this specification irrespective of whether validation by schema or any other method is being performed.

NOTE: No existing technology for validating XML is able to completely validate the HL7 data types as represented in XML.

Namespaces used in this document

Use of attributes from XML specifications

The W3C XML specifications define several attributes in w3c namespaces that carry particular meaning when processing XML documents. This section documents the usage for several such attributes. Other attributes not described in this section may be used but HL7 artefact processing systems are not required to attach any meaning to them beyond that required in the context of processing the XML containing the HL7 artefacts.

xml:lang is not used. HL7 uses it's own attribute to convey the HL7 langauge property. This is done for several reasons. Many existing tools do not properly support xml:lang, and using xml:lang provides no useful outcomes. In addition, using a CS instead of xml:lang provides clear support for the realm variation by international HL7 affiliates. Note that at present, the codeset of language is identical to that of xml:lang so it is possible to transform from one to the other.

xsi:schemaLocation must not be used in an instance to point to a schema document to be used for validation. Instance processors are expected to provide their own schemas.

xsi:type is required when:

• The type of the RIM attribute is ANY, RTO, or QTY
• An instance of an SC is being sent as a promotion of an ST

xsi:type may be used at other times according to the XML Schema specification.

When xsi:type is used to describe a data type defined in this specification, the correct type name is the value of the "Symbol" column for the type as given in Table 1 in the hl7 namespace.

For generic types, the type names of the parameter types are appended to the generic type with an underscore between, so that an IVL<TS> becomes IVL_TS. No ambiguities arise with this naming scheme due to the way that the data types have been defined.

Basic Data Types

Data Value (ANY)

Definition:      Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type.

ANY is an abstract datatype and may not be used directly; hence, ANY has no XML representation.

Null Flavor : CS

Definition:      An exceptional value expressing missing information and possibly the reason why the information is missing.

Every data element has either a proper value or it is considered NULL. If and only if it is NULL, a "null flavor" provides more detail as to in what way or why no proper value is supplied.

nullFlavor is represented by the XML attributenullFlavor whose value, if present, must be a valid value from the NullFlavor domain (Table 2).

Boolean (BL)

Definition:      The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL.

All Boolean values obey the common operators negation, conjunction, and disjunction. With the NULL value these common Boolean operations are extended as shown in the following tables.

BL is represented by both Element and Attribute forms. In the Element form, the name of the element is determined by the context in which it is used. The element has attributes as described in the template and the sub-sections below.

XML instances may carry either a nullFlavor or a value, but not both.

The Attribute form of BL is used when properties of other data types have type BL. The name of the attribute is determined by the context in which it is used. The attribute must have the value true or false.

Examples

The first example shows true and false negation and context conduction indicators.

The second example shows the use of true and false inclusive interval boundaries.

BooleanNonNull (BN)

Definition:      The BooleanNonNull type is used where a Boolean cannot have a null value. A Boolean value can be either true or false.

BN is represented by both Element and Attribute forms. In the Element form, the name of the element is determined by the context in which it is used. The element has attributes as described in the template and the sub-sections below.

XML instances must carry a value.

The Attribute form of BN is used when properties of other data types have type BN. The name of the attribute is determined by the context in which it is used and whose value is either true or false. Unless the value has a default property the attribute must be present.

Binary Data (BIN)

Definition:      Binary data is a raw block of bits. Binary data is a protected type that MUST not be used outside the data type specification.

BIN is represented by both Element and Attribute forms. The Element form serves as the basis of the encapsulated data type, used for both written text and multimedia (binary data). When an element is defined to be of type that property is represented as the character data (e.g., #PCDATA) content of the element in question.

The Attribute form of BIN is used when properties of other data types have type BIN (e.g., ED.integrityCheck). The name of the XML attribute is determined by the name of the property in question. The value of the XML attribute must be the base64 encoding [http://www.ietf.org/rfc/rfc2045.txt] of the binary data.

Data : XML Text Content

Definition:      The data itself represented in the XML instance encoding according to the binary data representation element (text or base64 form.) ST and types that specialize ST use only the text representation.

data is represented as the text content of the XML element representing the BIN value, whose value, if present must be the base64 encoding of the actual value.

Representation : CS

Definition:      Specifies the representation of the binary data that is the content of the binary data value.

BIN in the Data Types Abstract Specification does not have a representation property since, for HL7's purposes, representation is not a meaningful property of data. Therefore applications need not retain the representation.

representation is represented by the XML attributerepresentation whose value, if present, must be TXT or B64. The default value is TXT.

TXT indicates that the character data of the BIN is to be interpreted directly as characters; B64 indicates that the BIN data has been base64 encoded and must be decoded in order to recover the original data.

Encapsulated Data (ED) specializes BIN

Definition:      Data that is primarily intended for human interpretation or for further machine processing is outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an ED may contain only a reference (see TEL.) Note that the ST data type is a specialization of ED when the mediaType is text/plain.

Encapsulated data can be present in one of two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote.

ED is always represented in Element form as described in the template and sub-sections below. The binary data is conveyed as inline character content. Alternatively addition ED can contain the data as XML markup. In these cases the mediaType is expected to describe some form of XML markup, and the content must be well-formed XML contained in a single element in the ED content. If the in-line content is HTML or SGML, it must be well-formed XML or it must be represented as escaped or base64 encoded character content.

Markup contained in an ED can come from any namespace other than the HL7 V3 namespace (urn:hl7-org:v3) without restriction. Additionally, any element in the HL7 namespace that represents an interaction or the root of a CDA document may also appear. The reason for this restriction on elements from the HL7 namespace is to help support those who choose to do optional XML Schema processing. It would not be possible to write a schema definition that would allow arbitrary content from the HL7 namespace since that would result in a violation of Schema Component Constraint: Unique Particle Attribution.

Because inline data for ED (and its restricted form, ST) may be encoded as character data, and the content model also includes a thumbnail and reference element, ED has mixed content. An instance of ED may only contain at most one text node.

Data : XML Text Content (inherited from BIN)

Definition:      The data itself represented in the XML instance encoding according to the binary data representation element (text or base64 form.) ST and types that specialize ST use only the text representation.

data is represented as the text content of the XML element representing the ED value.

Representation : CS (inherited from BIN)

Definition:      Specifies the representation of the binary data that is the content of the binary data value.

representation is represented by the XML attributerepresentation whose value must either TXT or B64.

Media Type : CS

Definition:      Identifies the type of the encapsulated data and identifies a method to interpret or render the data.

The IANA defined domain of media types is established by the Internet standard RFC 2046 [http://www.ietf.org/rfc/rfc2046.txt].

To promote interoperability, this specification prefers certain media types to others. This is to define a greatest common denominator on which interoperability is not only possible, but that is powerful enough to support even advanced multimedia communication needs.

Table 6 below assigns a status to certain MIME media types, where the status means one of the following:

required: Every HL7 application must support at least the required media types if it supports a given kind of media. One required media-type for each kind of media exists. Some media types are required for a specific purpose, which is then indicated as "required for ..."

recommended: Other media types are recommended for a particular purpose. For any given purpose there should be only very few additionally recommended media types and the rationale, conditions and assumptions of such recommendations must be made very clear.

indifferent: This status means, HL7 does neither forbid nor endorse the use of this media type. All media types not mentioned here by default belong into the indifferent category. Since there is one required and several recommended media types for most practically relevant use cases, media types of this status should be used very conservatively.

deprecated: Deprecated media types should not be used, because these media types are flawed, because there are better alternatives, or because of certain risks. Such risks could be security risks, for example, the risk that such a media type could spread computer viruses. Not every flawed media type is marked as deprecated, though. A media type that is not mentioned, and thus considered other by default, may well be flawed.

The set of required media types is very small so that no undue requirements are forced on HL7 applications, especially legacy systems. In general, no HL7 application is forced to support any given kind of media other than written text. For example, many systems just do not want to receive audio data, because those systems can only show written text to their users. It is a matter of application conformance statements to say: "I will not handle audio". Only if a system claims to handle audio media, it must support the required media type for audio.

mediaType is represented by the XML attributemediaType whose value, if present, must be a valid mediaType as specified by the Internet standard RFC 2046 [http://www.ietf.org/rfc/rfc2046.txt]. The default value is text/plain.

Charset : CS

Definition:      For character-based encoding types, this property specifies the character set and character encoding used. The charset shall be identified by an Internet Assigned Numbers Authority (IANA) Charset Registration [http://www.iana.org/assignments/character-sets] in accordance with RFC 2978 [http://www.ietf.org/rfc/rfc2978.txt].

charset is not explicitly represented in the XML ITS. Rather, the value of charset is to be inferred from the encoding used in the XML entity in which the ED value is contained.

Language : CS

Definition:      For character based information the language property specifies the human language of the text.

The HL7 table for human languages is based on RFC 3066, Tags for the Identification of Languages [http://www.ietf.org/rfc/rfc3066.txt]. It is a set of pre-coordinated pairs of one 2-letter ISO 639 language code and one 2-letter ISO 3166 country code (e.g., en-us [English, United States]).

Language tags do not modify the meaning of the characters found in the text; they are only an advice on if and how to present or communicate the text. For this reason, any system or site that does not deal with multilingual text or names in the real world can safely ignore the language property.

language is represented by the XML attributelanguage whose value, if present, must be a valid language tag as defined by RFC 3066 [http://www.ietf.org/rfc/rfc3066.txt].

Compression : CS

Definition:      Indicates whether the raw byte data is compressed, and what compression algorithm was used.

compression is represented as the XML attributecompression whose value, if present, must be a valid value from the CompressionAlgorithm domain (Table 7). There is no compression by default.

Reference : TEL

Definition:      A telecommunication address (TEL), such as a URL for HTTP or FTP, which will resolve to precisely the same binary data that could as well have been provided as inline data.

The semantic value of an encapsulated data value is the same, regardless whether the data is present inline data or just by-reference. However, an encapsulated data value without inline data behaves differently, since any attempt to examine the data requires the data to be downloaded from the reference.

An encapsulated data value may have both inline data and a reference. The reference must point to the same data as provided inline.

reference is represented as the XML elementreference which, if present, must be a valid TEL.

Integrity Check : BIN

Definition:      The integrity check is a short binary value representing a cryptographically strong checksum that is calculated over the binary data. The purpose of this property, when communicated with a reference is for anyone to validate later whether the reference still resolved to the same data that the reference resolved to when the encapsulated data value with reference was created.

The integrity check is calculated according to the integrity check algorithm. By default, the Secure Hash Algorithm-1 (SHA-1) shall be used. The integrity check is binary encoded according to the rules of the integrity check algorithm.

The integrity check is calculated over the raw binary data that is contained in the data component, or that is accessible through the reference. No transformations are made before the integrity check is calculated. If the data is compressed, the Integrity Check is calculated over the compressed data.

integrityCheck is represented by the XML attributeintegrityCheck whose value, if present, must be a valid BIN. There is no default value.

When generating instances, applications must base64 encode the integrity check prior to populating the XML attributeintegrityCheck. When receiving instances, applications must base64 decode the value of the XML attributeintegrityCheck to obtain the integrity check value.

Integrity Check Algorithm : CS

Definition:      Specifies the algorithm used to compute the integrityCheck value.

integrityCheckAlgorithm is represented by the XML attributeintegrityCheckAlgorithm whose value must be a valid value from the IntegrityCheckAlgorithm domain (Table 8). The default value is SHA-1.

Thumbnail : ED

Definition:      A thumbnail is an abbreviated rendition of the full data. A thumbnail requires significantly fewer resources than the full data, while still maintaining some distinctive similarity with the full data. A thumbnail is typically used with by-reference encapsulated data. It allows a user to select data more efficiently before actually downloading through the reference.

For example, a large image may be represented by a small image; a high quality audio sequence by a shorter low-quality audio; a movie may be represented by a shorter clip (or just an image); text may be summarized to an abstract.

A thumbnail may not itself contain a thumbnail.

thumbnail is represented as the XML elementthumbnail which, if present, is a restricted form of ED that does not allow thumbnail children.

Examples

The first example shows an Adobe Acrobat document that has been compressed using the GZip compression algorithm.

The next example contains a reference to an image, stored at particular URL and available for the next month. An integrity check is provided for the image, as well as in inline thumbnail.

Character String (ST) specializes ED

Definition:      The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions.

A character string must at least have one character or else it is NULL. The length of a string is the number of characters, not the number of encoded bytes.

ST interprets the encapsulated data as character data (as opposed to bits), depending on the charset property. In other words, the string S1 "Rose" is equal to the string S2 "Rose" even if S1 is ASCII encoded (hex '526f7365') and S2 is EBCDIC encoded (hex 'd996a285') or UTF-16 encoded (hex '0052006f00730065').

ST is represented by both Element and Attribute forms. In the Element form, the name of the XML element is determined by the context in which it is used. The element has attributes as described in the template and sub-sections below.

The Attribute form of ST is used when properties of other data types have type ST. The name of the attribute is determined by the context in which it is used. The value of the attribute is the content of the string.

Data : XML Text Content (inherited from BIN)

Definition:      The data itself represented in the XML instance encoding.

data is represented as the text content of the XML element representing the ST value.

Representation : CS (inherited from BIN)

Definition:      Specifies the representation of the binary data that is the content of the binary data value.

representation is represented by the XML attributerepresentation whose value, if present, must be TXT. Since the representation always has a fixed value, it is not normally present in the XML instance.

Media Type : CS (inherited from ED)

Definition:      Identifies the type of the encapsulated data and identifies a method to interpret or render the data.

mediaType is represented by the XML attributemediaType whose value, if present, must be text/plain. Since the media type always has a fixed value, it is not normally present in the XML instance.

Charset : CS (inherited from ED)

Definition:      For character-based encoding types, this property specifies the character set and character encoding used. The charset shall be identified by an Internet Assigned Numbers Authority (IANA) Charset Registration [http://www.iana.org/assignments/character-sets] in accordance with RFC 2978 [http://www.ietf.org/rfc/rfc2978.txt].

charset is not explicitly represented in the XML ITS. Rather, the value of charset is to be inferred from the encoding used in the XML entity in which the ST value is contained.

Language : CS (inherited from ED)

Definition:      For character based information the language property specifies the human language of the text.

language is represented by the XML attributelanguage whose value, if present, must be a valid language tag as defined by RFC 3066 [http://www.ietf.org/rfc/rfc3066.txt].

Compression : CS (fixed)

Definition:      Indicates whether the raw byte data is compressed, and what compression algorithm was used.

compression is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Reference : TEL (fixed)

Definition:      A telecommunication address (TEL), such as a URL for HTTP or FTP, which will resolve to precisely the same binary data that could as well have been provided as inline data.

reference is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Integrity Check : BIN (fixed)

Definition:      The integrity check is a short binary value representing a cryptographically strong checksum that is calculated over the binary data. The purpose of this property, when communicated with a reference is for anyone to validate later whether the reference still resolved to the same data that the reference resolved to when the encapsulated data value with reference was created.

integrityCheck is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Integrity Check Algorithm : CS (fixed)

Definition:      Specifies the algorithm used to compute the integrityCheck value.

integrityCheckAlgorithm is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Thumbnail : ED (fixed)

Definition:      A thumbnail is an abbreviated rendition of the full data. A thumbnail requires significantly fewer resources than the full data, while still maintaining some distinctive similarity with the full data. A thumbnail is typically used with by-reference encapsulated data. It allows a user to select data more efficiently before actually downloading through the reference.

thumbnail is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Examples

This example shows a simple case of a character string for Act.text.

Coded Simple Value (CS) specializes CV

Definition:      Coded data in its simplest form, consists of a code. The code system and code system version is fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set.

CS is represented by both Element and Attribute forms. In the Element form, the type is represented by an XML element whose name is determined by the context in which it is used. The code value is represented by an XML attributecode, whose value, if present, must be a valid xs:token with no internal whitespace.

In the Attribute form, code is represented as an XML attribute whose name is determined by the context in which it is used, and whose value, if present, must be a valid xs:token with no internal whitespace.

Code : ST (inherited from CD)

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

code is represented by the XML attributecode whose value, if present, must be a valid xs:token with no internal whitespace.

Code System : UID (fixed)

Definition:      Specifies the code system that defines the code.

codeSystem is inherited from an ancestor data type but does not appear in the XML representation of this data type.

The fact that a sending system is prohibited from specifying a code system for an CS data value should not be misconstrued as if such codes would not have any code system. Rather, the code system in CS values is fixed by the context. That context is defined by the model in which CS is used.

Code System Name : ST (fixed)

Definition:      A common name of the coding system.

codeSystemName is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Code System Version : ST (fixed)

Definition:      If applicable, a version descriptor defined specifically for the given code system.

codeSystemVersion is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Display Name : ST (fixed)

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

displayName is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Original Text : ED (fixed)

Definition:      The text or phrase used as the basis for the coding.

originalText is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Examples

This example shows a US realmCode.

This example shows a ControlAct with a classCode of CACT and a moodCode of EVN, both of which are CS.

Coded Value (CV) specializes CE

Definition:      Coded data, consists of a code, display name, code system, and original text. Used when a single code value must be sent.

CV is always represented in Element form as described in the template and sub-sections below.

Code : ST (inherited from CD)

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

code is represented by the XML attributecode whose value, if present, must be a valid xs:token with no internal whitespace.

Code System : UID (inherited from CD)

Definition:      Specifies the code system that defines the code.

codeSystem is represented by the XML attributecodeSystem whose value, if present, must be a valid UID.

Code System Name : ST (inherited from CD)

Definition:      A common name of the coding system.

codeSystemName is represented by the XML attributecodeSystemName whose value, if present, must be a valid ST.

Code System Version : ST (inherited from CD)

Definition:      If applicable, a version descriptor defined specifically for the given code system.

codeSystemVersion is represented by the XML attributecodeSystemVersion whose value, if present, must be a valid ST.

Display Name : ST (inherited from CD)

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

displayName is represented by the XML attributedisplayName whose value, if present, must be a valid ST.

Original Text : ED (inherited from CD)

Definition:      The text or phrase used as the basis for the coding.

originalText is represented by the XML elementoriginalText which, if present, must be a valid ED.

Translation : SET<CD> (fixed)

Definition:      A set of other concept descriptors that translate this concept descriptor into other code systems.

translation is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Examples

The first example shows the LOINC code for "consultation note".

The second example shows a SNOMED-CT code with CD.originalText for "osteoarthritis of the right knee".

The final example shows the use of nullFlavor='OTHER' to indicate that a code does not exist in a coding system.

Coded Ordinal (CO) specializes CV

Definition:      Coded data, where the domain from which the codeset comes is ordered. The Coded Ordinal data type adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain.

CO is always represented in Element form as described in the template and sub-sections below.

Code : ST (inherited from CD)

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

code is represented by the XML attributecode whose value, if present, must be a valid xs:token with no internal whitespace.

Code System : UID (inherited from CD)

Definition:      Specifies the code system that defines the code.

codeSystem is represented by the XML attributecodeSystem whose value, if present, must be a valid UID.

Code System Name : ST (inherited from CD)

Definition:      A common name of the coding system.

codeSystemName is represented by the XML attributecodeSystemName whose value, if present, must be a valid ST.

Code System Version : ST (inherited from CD)

Definition:      If applicable, a version descriptor defined specifically for the given code system.

codeSystemVersion is represented by the XML attributecodeSystemVersion whose value, if present, must be a valid ST.

Display Name : ST (inherited from CD)

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

displayName is represented by the XML attributedisplayName whose value, if present, must be a valid ST.

Original Text : ED (inherited from CD)

Definition:      The text or phrase used as the basis for the coding.

originalText is represented by the XML elementoriginalText which, if present, must be a valid ED.

Translation : SET<CD> (fixed)

Definition:      A set of other concept descriptors that translate this concept descriptor into other code systems.

translation is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Coded with Equivalents (CE) specializes CD

Definition:      Coded data, consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist.

CE is always represented in Element form as described in the template and sub-sections below.

Code : ST (inherited from CD)

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

code is represented by the XML attributecode whose value, if present, must be a valid xs:token with no internal whitespace.

Code System : UID (inherited from CD)

Definition:      Specifies the code system that defines the code.

codeSystem is represented by the XML attributecodeSystem whose value, if present, must be a valid UID.

Code System Name : ST (inherited from CD)

Definition:      A common name of the coding system.

codeSystemName is represented by the XML attributecodeSystemName whose value, if present, must be a valid ST.

Code System Version : ST (inherited from CD)

Definition:      If applicable, a version descriptor defined specifically for the given code system.

codeSystemVersion is represented by the XML attributecodeSystemVersion whose value, if present, must be a valid ST.

Display Name : ST (inherited from CD)

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

displayName is represented by the XML attributedisplayName whose value, if present, must be a valid ST.

Qualifier : LIST<CR> (fixed)

Definition:      Specifies additional codes that increase the specificity of the primary code.

qualifier is inherited from an ancestor data type but does not appear in the XML representation of this data type.

Original Text : ED (inherited from CD)

Definition:      The text or phrase used as the basis for the coding.

originalText is represented by the XML elementoriginalText which, if present, must be a valid ED.

Translation : SET<CD> (inherited from CD)

Definition:      A set of other concept descriptors that translate this concept descriptor into other code systems.

translation is represented by 0 or more XML elementstranslation each of which must be a valid CD.

Examples

This example shows an observation whose value is the SNOMED-CT code for "asthma" as well as a translation of that code in ICD9CM.

For additional examples see Examples (§ 2.8.8 ).

Concept Descriptor (CD)

Definition:      A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In exceptional cases, the concept descriptor need not contain a code but only the original text describing that concept.

CD is always represented in Element form as described in the template and sub-sections below.

Code : ST

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

code is represented by the XML attributecode whose value, if present, must be a valid xs:token with no internal whitespace.

Code System : UID

Definition:      Specifies the code system that defines the code.

codeSystem is represented by the XML attributecodeSystem whose value, if present, must be a valid UID.

Code System Name : ST

Definition:      A common name of the coding system.

codeSystemName is represented by the XML attributecodeSystemName whose value, if present, must be a valid ST.

Code System Version : ST

Definition:      If applicable, a version descriptor defined specifically for the given code system.

codeSystemVersion is represented by the XML attributecodeSystemVersion whose value, if present, must be a valid ST.

Display Name : ST

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

displayName is represented by the XML attributedisplayName whose value, if present, must be a valid ST.

Original Text : ED

Definition:      The text or phrase used as the basis for the coding.

originalText is represented by the XML elementoriginalText which, if present, must be a valid ED.

Translation : SET<CD>

Definition:      A set of other concept descriptors that translate this concept descriptor into other code systems.

translation is represented by a 0 or more XML elementstranslation each which must be a valid CD.

Qualifier : LIST<CR>

Definition:      Specifies additional codes that increase the specificity of the primary code.

qualifier is represented by a 0 or more XML elementsqualifer each of which must be a valid CR.

Examples

The first example shows the SNOMED-CT code with qualifier for "skin of palmer surface of left index finger".

The second example shows an observation whose value is the SNOMED-CT code with qualifier and originalText for "osteoarthritis of the right knee".

Concept Role (CR)

Definition:      A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg".

The use of qualifiers is strictly governed by the code system used. The CD data type does not permit using qualifiers with code systems that do not provide for qualifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.)

CR is represented in Element form as described in the template and sub-sections below.

Name : CV

Definition:      Specifies the manner in which the concept role value contributes to the meaning of a code phrase. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". In this example "has-laterality" is name.

The name component can be NULL if a coding system allows postcoordination but no role names.

name is represented by the XML elementname which, if present, must be a valid CV.

Value : CD

Definition:      The concept that modifies the primary code of a code phrase through the role relation. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows adding the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". In this example "left" is value.

value is of type CD and thus can be in turn have qualifiers. This allows qualifiers to nest. Qualifiers can only be used as far as the underlying code system defines them. It is not allowed to use any kind of qualifiers for code systems that do not explicitly allow and regulate such use of qualifiers.

value is represented by the XML elementvalue which, if present, must be a valid CD.

Inversion Indicator : BN

Definition:      Indicates if the sense of the role name is inverted. This can be used in cases where the underlying code system defines inversion but does not provide reciprocal pairs of role names. By default, inverted is false.

For example, a code system may define the role relation "causes" besides the concepts "Streptococcus pneumoniae" and "Pneumonia". If that code system allows its roles to be inverted, one can construct the post-coordinated concept "Pneumococcus pneumonia" through "Pneumonia - causes, inverted - Streptococcus pneumoniae."

Roles may only be inverted if the underlying coding systems allows such inversion. Notably, if a coding system defines roles in inverse pairs or intentionally does not define certain inversions, the appropriate role code (e.g. "caused-by") must be used rather than inversion. It must be known whether the inverted property is true or false, if it is NULL, the role cannot be interpreted.

inverted is represented by the XML attributeinverted whose value, if present, must be either true or false. The default value is false.

Examples

See the examples using CD.qualifier in Examples (§ 2.11.9 ).

Character String with Code (SC) specializes ST

Definition:      An ST that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.

SC is represented in Element form as described in the template and sub-sections below.

Code : ST (inherited from CD)

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

code is represented by the XML attributecode whose value, if present, must be a valid xs:token with no internal whitespace.

Code System : UID (inherited from CD)

Definition:      Specifies the code system that defines the code.

codeSystem is represented by the XML attributecodeSystem whose value, if present, must be a valid UID.

Code System Name : ST (inherited from CD)

Definition:      A common name of the coding system.

codeSystemName is represented by the XML attributecodeSystemName whose value, if present, must be a valid ST.

Code System Version : ST (inherited from CD)

Definition:      If applicable, a version descriptor defined specifically for the given code system.

codeSystemVersion is represented by the XML attributecodeSystemVersion whose value, if present, must be a valid ST.

Display Name : ST (inherited from CD)

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

displayName is represented by the XML attributedisplayName whose value, if present, must be a valid ST.

Unique Identifier String (UID)

Definition:      A unique identifier string is a character string which identifies an object in a globally unique and timeless manner. The allowable formats and values and procedures of this data type are strictly controlled by HL7. At this time, user-assigned identifiers may be certain character representations of ISO Object Identifiers (OID) and DCE Universally Unique Identifiers (UUID). HL7 also reserves the right to assign other forms of UIDs (RUID, such as mnemonic identifiers for code systems.

The sole purpose of the UID is to be a globally and timelessly unique identifier. The form of the UID, whether it is an OID, an UUID or RUID is entirely irrelevant. As far as HL7 is concerned, the only thing one can do with an UID is denote to the object for which it stands. Comparison of UIDs is literal, i.e. if two UIDs have the same character sequence, they are assumed to denote the same object. If two UIDs are not literally identical they may not denote to the same object.

No difference in semantics is recognized between the different allowed forms of the UID. The different forms are not distinguished by a component within or aside from the identifier string itself.

UID is only represented in Attribute form, where the value must be a valid OID, UUID, or HL7 reserved identifier as defined in the sections below.

ISO Object Identifier (OID) Scheme

Definition:      A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of non-negative numbers with no leading zeros and dots (e.g., "2.16.840.1.113883.19.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf.

Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree.

OIDs are the preferred scheme for unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply.

DCE Universal Unique Identifier (UUID) Scheme

Definition:      A DCE Universal Unique Identifier is a globally unique string consisting of 5 groups of upper- or lower-case hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. UUIDs are assigned using Ethernet MAC addresses, the point in time of creation and some random components. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.)

UUIDs are not the preferred identifier scheme for use as UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme.

HL7 Reserved Identifier Scheme

Definition:      HL7 reserved identifiers are strings consisting only of (US-ASCII) letters, digits and hyphens, where the first character must be a letter. HL7 may assign these reserved identifiers as mnemonic identifiers for major concepts of interest to HL7.

Examples

See the examples in Examples (§ 2.15.5 ).

Instance Identifier (II)

Definition:      An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers.

Some identifier schemes define certain style options to their code values. For example, the U.S. Social Security Number (SSN) is normally written with dashes that group the digits into a pattern "123-12-1234". However, the dashes are not meaningful and a SSN can just as well be represented as "123121234" without the dashes.

In the case where identifier schemes provide for multiple representations, HL7 shall make a ruling about which is the preferred form. HL7 shall document that ruling where that respective external identifier scheme is recognized. HL7 shall decide upon the preferred form based on criteria of practicality and common use. In absence of clear criteria of practicality and common use, the safest, most extensible, and least stylized (the least decorated) form shall be given preference.

From practical experience it is recommended that extension be an alphanumeric identifier not containing leading zero digits, for these are often erroneously stripped. "000123" and "123" would be different extension values, but this is prone to be misunderstood, leading to false non-matches and duplicate record entries. However applications should maintain any leading zero digits encountered in extension. Leading zero digits are prohibited in OIDs, but may occur in UUIDs, where they must be maintained.

There is no separate check digit property. Check digits are used for human purpose and work best if kept completely transparent. extension MAY contain check digits anywhere, and the particular check digit scheme (if any) would be implied by the root. However, a separate check digit property is intentionally not recognized by this specification.

II is represented in Element form as described in the template and sub-sections below.

Root : UID

Definition:      A unique identifier that guarantees the global uniqueness of the instance identifier. The root alone may be the entire instance identifier.

root is represented by the XML attributeroot whose value, if present, must be a valid UID.

Extension : ST

Definition:      A character string as a unique identifier within the scope of the identifier root.

extension is represented by the XML attributeextension whose value, if present, must be a valid ST.

Assigning Authority Name : ST

Definition:      A human readable name or mnemonic for the assigning authority. This name may be provided solely for the convenience of unaided humans interpreting an II value and can have no computational meaning. Note: no automated processing must depend on the assigning authority name to be present in any form.

assigningAuthorityName is represented by the XML attributeassigningAuthorityName whose value, if present, must be a valid ST.

Displayable : BL

Definition:      Specifies if the identifier is intended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false).

displayable is represented by the XML attributedisplayable whose value, if present, must be a valid BL.

Examples

The first example shows a root that is an OID.

The next example shows a root that is a UUID.

The final example shows a root that is a RUID.

Universal Resource Locator (URL)

Definition:      A telecommunications address specified according to Internet standard RFC 1738 [http://www.ietf.org/rfc/rfc1738.txt]. The URL specifies the protocol and the contact point defined by that protocol for the resource. Notable uses of the telecommunication address data type are for telephone and telefax numbers, e-mail addresses, Hypertext references, FTP references, etc.

URLs have a standard representation as a character string, formatted as "<code><scheme>:<address>;</code>" where the most common schemes are listed in Table 18. The address portion of the URL is a character string whose format is entirely defined by the URL scheme.

Similar to the ED.mediaType, HL7 makes suggestions about values classifying them as required, recommended, other, and deprecated. Any scheme not mentioned has status other.

URL is a protected type and is represented only in Attribute form in the value component of TEL; the XML attributevalue must be a valid xs:anyURI.

Telephone and FAX Numbers

Telephone and FAX Numbers. There is no special data type for telephone numbers. Telephone numbers are telecommunication addresses and are specified as a URL. Voice telephone URLs begin with "tel:" and fax URLs begin with "fax:".

The telephone number URL is defined in the Internet RFC 2806 [http://www.ietf.org/rfc/rfc2806.txt] URLs for Telephone Calls. For example, "tel:+1(317)630-7960" is a phone number, and "fax:+49(30)8101-724" is a FAX number. The global absolute telephone numbers starting with the "+" and country code are preferred. Separator characters serve as decoration but have no meaning for the telephone number, thus "tel:+13176307960" and "fax:+49308101724" are the same telephone and FAX numbers as the previous respective examples.

Examples

See the examples in Examples (§ 2.17.3 ).

Telecommunication Address (TEL) specializes URL

Definition:      A telephone number (voice or fax), e-mail address, or other locator for a resource (information or service) mediated by telecommunication equipment. The address is specified as a URL qualified by time specification and use codes that help in deciding which address to use for a given time and purpose.

TEL is represented in Element form as described in the template and sub-sections below.

Useable Period : GTS

Definition:      Specifies the periods of time during which the telecommunication address can be used. For a telephone number, this can indicate the time of day in which the party can be reached on that telephone. For a web address, it may specify a time range in which the web content is promised to be available under the given address.

useablePeriod is represented by 0 or more XML elementsuseablePeriod each of which must be a valid GTS.

Use : SET<CS>

Definition:      One or more codes advising a system or user which telecommunication address in a set of like addresses to select for a given telecommunication need.

The telecommunication address use codes are defined by the HL7 domain TelecommunicationAddressUse (Table 20).

The telecommunication use code is not a complete classification for equipment types or locations. Its main purpose is to suggest or discourage the use of a particular telecommunication address. The use code should not be considered in isolation. The data element in which the telephone number appears (class and attribute) and the context to other data may express the precise nature and use of the telecommunication address more appropriately than a use code.

use is represented by the XML attributeuse whose value, if present, must be 0 or more valid values from the TelecommunicationAddressUse (Table 20) separated by whitespace.

Examples

The first example shows a work email address.

The second example shows a PNG file that is only accessible between 08:45 and 09:45 on July 20, 2000.

The final example shows a home phone number of 555-555-5001.

Address Part (ADXP)

Definition:      A character string that may have a type-tag signifying its role in the address. Typical parts that exist in about every address are street, house number, or post box, postal code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses). Addresses are usually broken up into lines, which are indicated by special line-breaking delimiter elements (e.g., DEL).

ADXP is represented as an XML element whose name is derived from the address part type code (see table below) and whose content is just like an ST, except that it also has an XML attributepartType as described above, whose value is fixed to the appropriate address part type. The XML attributepartType is generally not used.

Data : XML Text Content (inherited from BIN)

Definition:      The data itself represented in the XML instance encoding.

is represented as the text content of the XML element representing the ADXP value.

Address Part Type : CS

Definition:      Specifies whether an address part names the street, city, country, postal code, post box, etc. If the type is NULL the address part is unclassified and would simply appear on an address label as is.

Address part types are as defined in Table 22

Addresses are conceptualized as text with added mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The model is similar to HTML or XML markup of text.

partType is represented simultaneously in Element and Attribute forms. In the Element form, the name of the element is determined by the part type, as specified in Table 23 below. Additionally, each such element has an XML attributepartType whose value, if present, must be a valid value from the domain AddressPartType (Table 22) corresponding to the part type represented by the element on which it appears. Since the XML attributepartType always has a fixed value, it is not normally present in the XML instance.

Examples

See the examples in Examples (§ 2.19.4 ).

Postal Address (AD)

Definition:      Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc.

AD is primarily used to communicate data that will allow printing mail labels, that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information is captured by other, more appropriate HL7 elements.

Structurally, the postal address data type is a sequence of address part values with an added "use" code and a valid time range for information about if and when the address can be used for a given purpose.

Applications are not required to preserve the ordering of the address parts.

AD is represented by an XML element whose name is determined by the context in which it is used. The element has attributes and child elements as described in the template and the sub-sections below.

Any non whitespace text in the AD content is interpreted as ADXP parts with a null partType. Refer to the the Formatting Address section (2.21.1.5) in Abstract Data Types Specification for full details on interpretation of AD content.

Use : SET<CS>

Definition:      A set of codes advising a system or user which address in a set of like addresses to select for a given purpose.

The postal address use codes are defined by the PostalAddressUse domain (Table 25).

The postal address use code is not a complete classification for locations or activities that take place at these locations. Its main purpose is to suggest or discourage the use of a particular address. The use code should not be considered in isolation. The data element in which the address appears (class and attribute) and the context to other data may express the precise nature and use of the address more appropriately than a use code.

use is represented by the XML attributeuse whose value, if present, must be 0 or more valid values from the PostalAddressUse domain (Table 25) separated by whitespace.

Useable Period : GTS

Definition:      A GTS specifying the periods of time during which the address can be used. This is used to specify different addresses for different times of the year or to refer to historical addresses.

useablePeriod is represented by 0 or more XML elementsuseablePeriod each of which must be a valid GTS.

Is Not Ordered : BL

Definition:      A boolean value specifying whether the order of the address parts is known or not. While the address parts are always a Sequence, the order in which they are presented may or may not be known. Where this matters, isNotOrdered can be used to convey this information.

isNotOrdered is represented by the XML attributeisNotOrdered whose value, if present, must be a valid BL.

Examples

The following are examples of addresses in an XML encoded form, where the XML tag is the address part type and the data content is the address part value.

The address:

1050 W Wishard Blvd,
RG 5th floor,
Indianapolis, IN 46240

can be encoded in any of the following forms:

The first form would result from a system that only stores addresses as free text or in a list of fields line1, line2, etc.:

The second form is more specific about the role of the address parts than the first one and is the typical form seen in the U.S., where street address is sometimes separated, and city, state and ZIP code are always separated.

The third is even more specific:

The latter form above is not often used in the USA. However, it is useful in Germany, where many systems keep house number as a distinct field. For example, the German address:

Windsteiner Weg 54a,
D-14165 Berlin

would most likely be encoded as follows:

Entity Name Part (ENXP)

Definition:      A character string token representing a part of a name. May have a type code signifying the role of the part in the whole entity name, and a qualifier code for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc.

ENXP is represented as an XML element whose name is derived from the entity name part type code (see table below) and whose content is just like an ST, except that it also has XML attributepartType and XML attributequalifier as described above. The value of the XML attributepartType is fixed to the appropriate name part type. The XML attributepartType is generally not used.

Data : XML Text Content (inherited from BIN)

Definition:      The data itself represented in the XML instance encoding.

is represented as the text content of the XML element representing the ENXP value.

Name Part Type : CS

Definition:      Indicates whether the name part is a given name, family name, prefix, suffix, etc.

Entity name part types are as defined in Table 27

Not every name part must have a type code, if the type code is unknown, not applicable, or simply undefined this is expressed by a null value (type.isNull). For example, a name may be "Rogan Sulma" and it may not be clear which one is a given name or which is a last name, or whether Rogan may be a title.

Entity names are conceptualized as text with added mark-up. The mark-up may describe in detail the role of each name part if it is known. Name parts occur in the order in which they would be printed on a mailing label. The model is similar to HTML or XML markup of text.

partType is represented simultaneously in Element and Attribute forms. In the Element form, the name of the element is determined by the part type, as specified in Table 28 below. Additionally, each such element has an XML attributepartType whose value, if present, must be a valid value from the domain EntityNamePartType (Table 27) corresponding to the part type represented by the element on which it appears. Since the XML attributepartType always has a fixed value, it is not normally present in the XML instance.

Qualifier : SET<CS>

Definition:     qualifier is a set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type. For example, a given name may be flagged as a nickname, a family name may be a pseudonym or a name of public records.

Entity name part qualifiers are as defined in Table 29

qualifier is represented as the XML attributequalifier whose value, if present, must be 0 or more values from the EntityNamePartQualifier domain (Table 29) separated by whitespace.

Examples

See the examples in Examples (§ 2.22.3 ), Examples (§ 2.23.3 ) and Examples (§ 2.24.3 ).

Entity Name (EN)

Definition:      A name for a person, organization, place or thing. A sequence of name parts, such as given name or family name, prefix, suffix, etc. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe".

Structurally, the entity name data type is a sequence of entity name part values with an added "use" code and a valid time range for information about if and when the name can be used for a given purpose.

EN is represented by an XML element whose name is determined by the context in which it is used. The element has attributes and child elements as described in the template and the sub-sections below.

Any non whitespace text in the EN content is interpreted as ENXP parts with a null partType. Refer to the the Formatting Name section (2.23.1.4) in Abstract Data Types Specification for full details on interpretation of EN content.

Use : SET<CS>

Definition:      A set of codes advising a system or user which name in a set of like names to select for a given purpose. A name without specific use code might be a default name useful for any purpose, but a name with a specific use code would be preferred for that respective purpose.

The entity names use codes are defined by the EntityNameUse domain (Table 31).

use is represented by the XML attributeuse whose value, if present, must be 0 or more valid values from the EntityNameUse domain (Table 31) separated by whitespace.

Valid Time : IVL<TS>

Definition:      An interval of time specifying the time during which the name is or was used for the entity. This accomodates the fact that people change names for people, places and things.

validTime is represented by 0 or more XML elementsvalidTime each of which must be a valid IVL<TS>.

Examples

See the examples in Examples (§ 2.22.3 ), Examples (§ 2.23.3 ) and Examples (§ 2.24.3 ).

Person Name (PN) specializes EN

Definition:      A name for a person. A sequence of name parts, such as given name or family name, prefix, suffix, etc. PN differs from EN because the qualifier type cannot include LS (Legal Status).

PN is represented by an XML element whose name is determined by the context in which it is used. The element has attributes and child elements as described in the template and the sub-sections below.

Any non whitespace text in the PN content is interpreted as ENXP parts with a null partType. Refer to the the Formatting Name section (2.23.1.4) in Abstract Data Types Specification for full details on interpretation of PN content.

Use : SET<CS> (inherited from EN)

Definition:      A set of codes advising a system or user which name in a set of like names to select for a given purpose. A name without specific use code might be a default name useful for any purpose, but a name with a specific use code would be preferred for that respective purpose.

use is represented by the XML attributeuse whose value, if present, must be 0 or more valid values from the EntityNameUse domain (Table 31) separated by whitespace.

Valid Time : IVL<TS> (inherited from EN)

Definition:      An interval of time specifying the time during which the name is or was used for the entity. This accomodates the fact that people change names for people, places and things.

validTime is represented by 0 or more XML elementsvalidTime each of which must be a valid IVL<TS>.

Examples

A very simple encoding of "Adam A. Everyman" would be:

None of the special qualifiers need to be mentioned if they are unknown or irrelevant. The next example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, vorvoegsels ("van"), and professional designations.

The following example shows a Japanese name in the three forms: ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji).

Organization Name (ON) specializes EN

Definition:      A name for an organization. A sequence of name parts.

ON is represented by an XML element whose name is determined by the context in which it is used. The element has attributes and child elements as described in the template and the sub-sections below.

Any non whitespace text in the ON content is interpreted as ENXP parts with a null partType. Refer to the the Formatting Name section (2.23.1.4) in Abstract Data Types Specification for full details on interpretation of ON content.

Use : SET<CS> (inherited from EN)

Definition:      A set of codes advising a system or user which name in a set of like names to select for a given purpose. A name without specific use code might be a default name useful for any purpose, but a name with a specific use code would be preferred for that respective purpose.

use is represented by the XML attributeuse whose value, if present, must be 0 or more valid values from the EntityNameUse domain (Table 31) separated by whitespace.

Valid Time : IVL<TS> (inherited from EN)

Definition:      An interval of time specifying the time during which the name is or was used for the entity. This accomodates the fact that people change names for people, places and things.

validTime is represented by 0 or more XML elementsvalidTime each of which must be a valid IVL<TS>.

Examples

The following is the name of HL7 with the legal status "Inc." as a distinguished name part:

Trivial Name (TN) specializes EN

Definition:      A restriction of entity name that is effectively a simple string used for a simple name for things and places.

TN is represented by an XML element whose name is determined by the context in which it is used. The element has attributes and child elements as described in the template and the sub-sections below.

Use : SET<CS> (inherited from EN)

Definition:      A set of codes advising a system or user which name in a set of like names to select for a given purpose. A name without specific use code might be a default name useful for any purpose, but a name with a specific use code would be preferred for that respective purpose.

use is represented by the XML attributeuse whose value, if present, must be 0 or more valid values from the EntityNameUse domain (Table 31) separated by whitespace.

Valid Time : IVL<TS> (inherited from EN)

Definition:      An interval of time specifying the time during which the name is or was used for the entity. This accomodates the fact that people change names for people, places and things.

validTime is represented by 0 or more XML elementsvalidTime each of which must be a valid IVL<TS>.

Examples

The following is the organization name, "Health Level Seven, Inc." in a simple string form:

Quantity (QTY)

Definition:     QTY is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution.

The Data Types Abstract Specification defines a diff property of a data type (not data value) that is the data type of the difference value between two data values of the quantity type. By default the diff property equals the same data type, but it may be overridden by a specialization of QTY. For instance, the difference between two TS values has the data type PQ (in the dimension of elapsed time.)

QTY is an abstract data type and cannot be used directly in the XML instance, so it has no XML representation. Instead, a specific descendent type must be used.

Integer Number (INT) specializes QTY

Definition:      Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity.

INT is represented by both Element and Attribute forms. In the Element form, the name of the element is determined by the context in which it is used. The element has attributes as described in the template and the sub-sections below.

XML instances may carry either a nullFlavor or a value, but not both.

The Attribute form of INT is used when properties of other data types have type INT. The name of the attribute is determined by the context in which it is used. The attribute value is the integer value.

Real Number (REAL) specializes QTY

Definition:      Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. Real numbers are needed beyond integers whenever quantities of the real world are measured, estimated, or computed from other real numbers. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers.

REAL is represented by both Element and Attribute forms. In the Element form, the name of the element is determined by the context in which it is used. The element has attributes as described in the template and the sub-sections below.

XML instances may carry either a nullFlavor or a value, but not both.

The Attribute form of REAL is used when properties of other data types have type REAL. The name of the attribute is determined by the context in which it is used. The attribute value is the real value.

For both the element and Attribute form, the value of the REAL as represented must conform to either of the XML Schema data types decimal or double.

Physical Quantity (PQ) specializes QTY

Definition:      A dimensioned quantity expressing the result of a measurement act.

PQ is represented by an XML element whose name is determined by the context in which it is used. The element has attributes and child elements as described in the template and the sub-sections below.

XML instances may carry either a nullFlavor or a value, but not both. The unit attribute must be populated if the value attribute is present, and cannot be present when the value attribute is not present.

Value : REAL

Definition:      The magnitude of the quantity measured in terms of the unit.

value is represented by the XML attributevalue whose value, if present, must be a valid REAL.

Unit of Measure : CS

Definition:      The unit of measure specified in the Unified Code for Units of Measure (UCUM) [http://aurora.rg.iupui.edu/UCUM].

More detail on the Unified Code for Units of Measure, and example tables of units commonly seen in practice with HL7 are provided in an appendix of the Data Types Abstract Specification.

The default unit of measure is 1 (the "unity").

unit is represented by the XML attributeunit whose value, if present, must be a valid unit of measure as defined in UCUM [http://aurora.rg.iupui.edu/UCUM].

Translation : PQR

Definition:      An alternative representation of the same physical quantity expressed in a different unit, of a different unit code system and possibly with a different value.

translation is represented by 0 or more XML elementstranslation each of which must be a valid PQR.

Examples

This example shows a value of 22.35 millimoles per milliliter.

The final example shows a value of 1.77 meters as well as a translation into inches.

Physical Quantity Representation (PQR) specializes CV

Definition:      A representation of a physical quantity in a unit from any code system. Used to show alternative representation for a physical quantity.

This is an extension of the coded value data type.

PQR is represented by an XML element whose name is determined by the context in which it is used. The element has attributes and child elements as described in the template and the sub-sections below.

Value : REAL

Definition:      The magnitude of the measurement value in terms of the unit specified in the code.

value is represented by the XML attributevalue whose value, if present, must be a valid REAL.

Code : ST (inherited from CD)

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

code is represented by the XML attributecode whose value, if present, must be a valid xs:token with no internal whitespace.

Code System : UID (inherited from CD)

Definition:      Specifies the code system that defines the code.

codeSystem is represented by the XML attributecodeSystem whose value, if present, must be a valid UID.

Code System Name : ST (inherited from CD)

Definition:      A common name of the coding system.

codeSystemName is represented by the XML attributecodeSystem whose value, if present, must be a valid ST.

Code System Version : ST (inherited from CD)

Definition:      If applicable, a version descriptor defined specifically for the given code system.

codeSystemVersion is represented by the XML attributecodeSystemVersion whose value, if present, must be a valid ST.

Display Name : ST (inherited from CD)

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

displayName is represented by the XML attributedisplayName whose value, if present, must be a valid ST.

Original Text : ED (inherited from CD)

Definition:      The text or phrase used as the basis for the coding.

originalText is represented by the XML elementoriginalText which, if present, must be a valid ED.

Examples

See the example using PQ.translation in Examples (§ 2.28.4 ).

Monetary Amount (MO) specializes QTY

Definition:      A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units.

MO is represented by an XML element whose name is determined by the context in which it is used. The element has attributes as described in the template and the sub-sections below.