Data Types - Implementation Technology Specification for XML

HL7 Version 3 Standard, Copyright Health Level Seven, Inc.© 2002. All Rights Reserved.

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 it's own for the purpose of this ballot.

This document is based on the Data Types Abstract Specification, which is defines the data types on an abstract layer independent from representation. Because data types are very close to implementation technology (many even believe data types are nothing else then "formats" for data fields), the truly ITS independent specification was felt to be too abstract to serve as a commonly understood, primary reference ' for data types. Therefore it was decided at this point in tome to make the data type ITS the primary normative specification.

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.

This standard is the result of several years of intense work through e-mail, telephone conferences and meeting discussions. Gunther Schadow (Regenstrief Institute for Health Care) chaired this task force, and is the main author of this document. Major contributions are from Mark Tucker (Regenstrief Institute), Paul V. Biron (Kaiser Permanente), Lloyd McKenzie (IBM), George Beeler, Douglas Pratt (Siemens), and Stan Huff (Intermountain Health Care), as well as Mike Henderson (Kaiser Permanente, now Eastern Informatics), Anthony Julian (Mayo), Joann Larson (Kaiser Permanente), Mark Shafarman (Oacis Healthcare Systems, now Oracle), Wes Rishel (Gartner Group), and Robin Zimmerman (Kaiser Permanente). Acknowledgements for their critical review and infusion of ideas go to Bob Dolin (Kaiser Permanente), Clem McDonald (Regenstrief Institute), Kai Heitmann (HL7 Germany), Rob Seliger (Sentillion), and Harold Solbrig (Mayo Clinic). Vital support came from the members of the task force, Laticia Fitzpatrick (Kaiser Permanente), Matt Huges, Randy Marbach (Kaiser Permanente), Larry Reis (Wizdom Systems), Carlos Sanroman (Kaiser Permanente), Greg Thomas (Kaiser Permanente). Thanks James Case (University of California, Davis), Norman Daoust (Partners HealthCare Systems), Irma Jongeneel (HL7 The Netherlands), Michio Kimura (HL7 Japan), John Molina (SMS), Richard Ohlmann (McKessonHBOC), David Rowed (HL7 Australia), and Klaus Veil (Macquarie Health Corp., HL7 Australia), for sharing their expertise in critical questions. This work was made possible by the Regenstrief Institute for Health Care.

Table of contents

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, a 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 propertics 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.

NOTE: At the time this ballot is released, the Data Types Abstract Specification is still undergoing revisions. An earlier draft of the Data Types Abstract Specification is included in this ballot package, but it is at times inconsistent with the present specification. The editors apologize for this unfortunate inconsistency. Once a consistent draft of the Data Types Abstract Specification is finalized, we will link the new draft to the ballot material.

This specification is divided in two major parts:

1. Basic data types.



2. Generic data type (templates).

The fully specified data types are organized approximately in the same order in which they appear in the Data Types Abstract Specification, devided 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.

In XML, several of the data types listed above are specified in two forms:

1. The common XML element form, usually encountered for high-level HL7 content derived from the Reference Information Model (RIM). Their XML schema data type names are the common all-caps abbreviations shown in the table above.



2. A more compact special XML attribute form, only used in special cases such as when representing certain components of other data types. Their XML schema data type names are the abbreviations in lower case.

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.

In the XML schema we use an abstract complex data type ANY. All other complex XML schema data types are extensions of this base data type.

NOTE: The above schema defines the ANY data type as mixed content which is not actually appropriate. This is only a workaround some of the errors of certain XML schema validators. It is an error for just ANY value to carry text nodes if not explicitly allowed in the schema of the specific data type.

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.

The NULL flavors are defined in XML as an enumeration.

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.

The XML representation of a Boolean can be either as a simple XML schema type (suitable for use in an XML attribute) or as a complex XML schema type preferred for use as an XML element. The simple type is used only in the HL7 data type schema (including defining the complex type.) The simple type cannot distinguish the different flavors of null.

By convention, simple types have a schema name that uses the lower case form of the HL7 data type short name.

Normally the Boolean is used as a complex XML schema type that has all the common data type components, such as the null flavor available. The simple Boolean value itself appears as the XML-attribute value.

By convention, complex XML types have a schema name that uses the upper case form of the HL7 data type short name.

Although the use of the XML-attribute value is optional, the constraint (expressed as an XPath predicate), specifies that there must be either an XML-attribute value or the ANY.nullFlavor attribute, but not both.

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

The XML representation of binary data exists in two forms, a simple type and a complex type. The simple type is used for certain data type components represented as XML attributes carrying arbitrary binary values. Simple binary data is always base 64 encoded

The complex type 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 BIN that property is represented as character data (e.g., #PCDATA) in the content model of the data type in question.

Definition:      The data itself represented in the XML instance encoding according to the binary data encoding element (text or base64 form.) Character strings and derived types use only the text encoding, which is the same encoding as the overall XML instance.

Definition:      Specifies the encoding of the binary data that is the content of the binary data complex XML schema data type.

The Data Types Abstract Specification does not recognize an encoding property for the BIN data type. The XML-attribute encoding is a component that only specifies the representation of the data in the XML rendition. The encoding is not a meaningful property of the data, only its encoding This means, application need not retain the encoding of the data.

Binary content can either appear as TEXT (in the encoding of the overall message) or as base 64 data

"TXT" indicates that the character data of the ED 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.

Definition:      Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in 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 the ED data type when the ED media type is text/plain.

Encapsulated data can be present in 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.

The XML schema for ED is a complex type that is an extension of BIN. Inline binary data is conveyed as character content.

ED (and its restricted form, ST) are encoded as character data, resulting in a mixed content model for ED. Because of this mixed content model, the text content could be split into several text nodes. Only XML encodings are valid that produce at most one text node.

EDITORIAL NOTE: Perhaps this is not correct, we may want to allow any content here (open content) so that another XML document (most likely XHTML or HL7 CDA) could be enclosed here effortlessly.

Definition:      Identifies the encoding 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.isi.edu/in-notes/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 Table 5 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.

In XML mediaType is represented with the XML-attribute mediaType. The default value for the XML-attribute mediaType is "text/plain".

The ED charset semantic property is is not explicitly represented in the XML ITS. Rather, the value of charset is to be infered from the value of the XML-attribute encoding in the XML-Declaration of the XML entity containing the instance. If the XML-Declaration or the XML-attribute encoding is not present in the instance, then defaults to UTF-8.

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 1766, Tags for the Identification of Languages [http://www.isi.edu/in-notes/rfc1766.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.

In XML a special language setting can be conveyed with the common XML-attribute xml:lang, which has no specific default value.

The XML-attribute xml:lang is defined in as being designed for exactly the same purpose as the language property, and hence, it has been adopted for use in the XML ITS.

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

This component is represented as the XML-attribute compression. There is no compression by default.

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.

The reference component in XML is the XML-element reference.

Receivers must ignore all occurances of the XML-element reference after the first occurance following the first text node.

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.

In XML, the integrity check component is represented with the XML-attribute integrityCheck, which has no specific default value.

When generating instances, applications must base-64 encode the integrity check prior to populating the XML-attribute integrityCheck. When receiving instances, applications must base-64 decode the value of the XML-attribute integrityCheck to obtain the integrity check value.

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

The integrity check algorithm is represented in XML with the XML-attribute integrityCheckAlgorithm, whose value is (currently) fixed to be "SHA-1" and cannot be changed in an instance.

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 in XML is represented with the child XML-element thumbnail which is a restriction on ED itself.

Receivers must ignore all occurences of the XML-element thumbnail after the first occurance following the first text node.

Text content is only allowed in non-NULL values.

The media type attribute is only allowed for non-NULL values.

The first example is a simple case of a character string.

<someED>cellulitis of the left foot</someED> 

A more complex 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.

<someED mediaType="image/png" encoding="B64" integrityCheck="aA5mb7c8TXtu392KMsaSa2MKkAwL5LKAo2d99azAs3MdUdw"><reference value="http://radiology.iumc.edu/xrays/128s8d9ej229se32s.png" validTime="200007200845-0820845"/><thumbnail mediaType="image/jpeg" encoding="B64">
      MNYD83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83
      6edjzMMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir
      ...
      omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu83
      4zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83==
   </thumbnail></someED> 

Lastly, we show a Microsoft Word document that has been compressed using the GZip compression algorithm.

<someED mediaType="application/msword" encoding="B64" COMPN="GZ">
   omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu83
   6edjzMMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir
   ...
   MNYD83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83
   4zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83==
</someED> 

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. Byte encoding is an ITS issue and is not relevant on the application layer.

The character string (ST) data type 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').

The HL7 character string data type in XML is essentially just that: the simple schema data type string.

However, because as any HL7 data value can be NULL, when the string is used by HL7 elements other than data type components, the string data is packaged as the text content of a complex XML schema type.

In the normative schema, the complex XML schema type for ST is formally a restriction of the ED data type which corresponds with the conceptualization set forth by the Data Types Abstract Specification. However, essentially we arrive at the ST schema type by disabling or fixing all ED components. The media type is fixed to text/plain, and the data encoding (inherited from BIN) is fixed to TXT. This effectively leaves very simple schema type that only allows one text node or the NULL value shown above. The effect of this form of specializing the ST from the ED is that HL7 instances can always replace a simple ST value instead of an element of ED data type.

Text content is only allowed in non-NULL values.

Definition:      Specifies the encoding of the binary data that is the content of the binary data complex XML schema data type.

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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.

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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.

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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.

This component is inherited from a generalization data type but its use in this specialization is prohibited.

Definition:      Coded data in its simplest form, consists of a code and display name. 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.

The XML schema for CS exists in two forms, as a simple schema type and as a complex schema type. The simple schema type only contains the code component and no display name. This simple form is used mostly as HL7 data type components so they can appear as XML attributes.

For the simple form, the CS code value is a restriction of the XML schema data type "token" that may not contain any white space character anywhere. This means, it may not contain leading or trailing white space, tabs or line feed characters.

The normal use of the CS data type in HL7 elements is as a complex XML schema type, such that the common NULL properties (null flavor) can be communicated.

According to both the Data Types Abstract Specification and the XML schema, the CS data type is formally defined as a restriction of the more complex coded data type CV (discussed below), using the following constraints.

This apparently more complicated definition by restriction is done to allow substituting a simple CV data value in a more complex CD or CE data element. The substitution of a CS for a CD, CE, or CV requires that the HL7 element specification defines at least a default coding system.

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.

Definition:      Specifies the code system that defines the code.

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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 HL7 element being declared of the CS data type.

Definition:      A common name of the coding system.

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

The XML schema for CV is effectively the following complex schema type.

According to both the Data Types Abstract Specification and the XML schema, the CV data type is formally defined as a restriction of the more complex coded data type CE (discussed below), using the following constraints.

This apparently more complicated definition by restriction is done to allow substituting a simple CV data value in a more complex CD or CE data element.

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.

Definition:      Specifies the code system that defines the code.

Definition:      A common name of the coding system.

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

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

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

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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.

The XML schema for CE is effectively the following complex schema type.

According to both the Data Types Abstract Specification and the XML schema, the CE data type is formally defined as a restriction of the more complex coded data type CD (discussed below), using the following constraints.

This apparently more complicated definition by restriction is done to allow substituting a simple CE data value in a more complex CD data element.

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.

Definition:      Specifies the code system that defines the code.

Definition:      A common name of the coding system.

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

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

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

This component is inherited from a generalization data type but its use in this specialization is prohibited.

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

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

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.

The normative XML schema for CD is defined as the following complex schema type.

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.

Definition:      Specifies the code system that defines the code.

Definition:      A common name of the coding system.

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

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

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

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

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

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

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 the CR.name.

If a coding system allows postcoordination but no role names the name attribute can be NULL.

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 the CR.value.

This component is of type concept descriptor 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.

A value component is required or else the code role is NULL.

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.

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, 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 any other form 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 are literally identical, they are assumed to denote to the same object. If two UIDs are not literally identical they may not denote to the same object (and in general are assumed to denote to different objects.)

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.

The XML representation of an UID is only as a simple XML schema type (suitable for use in an XML attribute.) The simple type is used only in the HL7 data type schema. As UID is a protected type, it can only be used as the component of other data types.

Even though this specification recognizes no semantic difference between the different forms of the unique identifier we use several simple XML schema types to make the definition more readable.

A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.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.

A DCE Universal Unique Identifier is a globally unique string consisting of 5 groups of 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 HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objectd describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme.

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.

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.

Leading zeroes in identifiers are deprecated. They frequently lead to confusion because some applications may or may not strip those zeroes. They are also sometimes used to indicate a certain maximum number of digits. This is in itself to be discouraged, because it the notion of a maximum identifier leads to overflow conditions which make identifiers non-unique and thus violate this specification.

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

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

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. Note: no automated processing must depend on the assigning authority name to be present in any form.

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

Definition:      If applicable, specifies during what time the identifier is valid. By default, the identifier is valid indefinitely. Any specific interval may be undefined on either side indicating unknown effective or expiry time.

NOTE: identifiers for information objects in computer systems should not have restricted valid times, but should be globally unique at all times. The identifier valid time is provided mainly for real-world identifiers, whose maintenance policy may include expiry (e.g., credit card numbers.)

Definition:      A telecommunications address specified according to Internet standard RFC 1738 [http://www.isi.edu/in-notes/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 "<scheme>:<address>" where the most common schemes are listed in Table 14. The address portion of the URL is a character string whose format is entirely defined by the URL scheme.

Telephone and FAX Numbers. There is no special data type for telephone numbers. Telephone numbers are telecommunication addresses and are specified as a URL. The 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.isi.edu/in-notes/rfc2806.txt] URLs for Telephone Calls. For examples, "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.

The URL data type in XML is essentially represented as a simple XML schema data type xsd:anyURI.

By convention, simple types have a schema name that uses the lower case form of the HL7 data type short name.

However, the only use of URL is allowed as its extension TEL that adds additional attributes. Therefore we define the URL as a complex schema type capsule, that has the simple URL type as it's XML attribute called "value".

By convention, complex XML types have a schema name that uses the upper case form of the HL7 data type short name.

Although the use of the XML-attribute value is optional, the constraint (expressed as an XPath predicate), specifies that there must be either an XML-attribute value or the ANY.nullFlavor attribute, but not both.

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 Universal Resource Locator (URL) qualified by time specification and use codes that help deciding which address to use for a given time and purpose.

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.

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.

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.

The use code domain in XML is represented as a specialization of the simple XML schema type 'cs'.

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

The address part in XML is, like the character string, a complex type with a character context model. The text content is the address part value and the type attribute is the address part type.

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 18

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.

The address part type is represented in XML as a specialization of the simple XML schema type 'cs'.

Because the model of addresses is similar to an XML markup, XML schema elements are defined to represent the address part types, such that address parts can be directly represented as XML markup. For example, a the elements country (CNT), state (STA), county (CPA), city (CTY), postalCode (ZIP), streetName (STR), houseNumber (HNR), streetAddressLine (SAL), direction (DIR), postBox (POB), etc. are defined.

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

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

The data content of the address value is a sequence of address part elements (which, in XML, can be plain text nodes.)

Definition:      The data content of the address value is a sequence of address part elements (which, in XML, can be plain text nodes.)

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 HL7 domain PostalAddressUse.

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.

The use code domain in XML is represented as a specialization of the simple XML schema type 'cs'.

Definition:      A General Timing Specification (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.

The following are examples of addresses in an XML encoded form, where the XML tag is the address part role 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.:

<addr use="WP">
  1050 W Wishard Blvd,
  RG 5th floor,
  Indianapolis, IN 46240
</addr>
 

The second form is more specific about the role of the address parts than the first one:

<addr use="WP">
  <streetAddressLine>1050 W Wishard Blvd</streetAddressLine>,
  <streetAddressLine>RG 5th floor</streetAddressLine>,
  <city>Indianapolis</city>, <state>IN</state> <postalCode>46240</postalCode>
</addr>
 

This form 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:

<addr use="WP">
  <houseNumber>1050</houseNumber> <direction>W</direction> <streetName>Wishard Blvd</streetName>,
  <additionalLocator>RG 5th floor</additionalLocator>,
  <city>Indianapolis</city>, <state>IN</state> <postalCode>46240</postalCode>
</addr>
 

The latter form above is not 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:

<addr use="HP">
  <streetName>Windsteiner Weg</streetName> <houseNumber>45a</houseNumber>,
  <country>D</country>-<postalCode>14165</postalCode> <CTY>Berlin</CTY>
</addr>
 

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 qualifyer code for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc.

The entity name part in XML is, like the character string, a complex type with a character context model. The text content is the address part value and the type attribute is the address part type.

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

Entity name part types are as defined in Table 22

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 first 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 break the address into lines and 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.

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

The entity name part type code is represented in XML as a specialization of the simple XML schema type 'cs'.

Because the model of names is similar to an XML markup, XML schema elements are defined to represent the name part types, such that name parts can be directly represented as XML markup. For example, family (FAM), given (GIV), prefix (PFX), and suffix (SFX) elements are defined.

Definition:      The 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 22

This is represented in XML as a specialization of the simple XML schema type 'cs'.

Definition:      A name for a person, organization, place or thing. A sequence of name parts, such as first 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.

Definition:      The data content of the entity name value is a sequence of entity name part elements (which, in XML, can be plain text nodes.)

Definition:      A set of codes advising a system or user which name in a set of like addresses 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 HL7 domain EntityNameUse.

The use code domain in XML is represented as a specialization of the simple XML schema type 'cs'.

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.

The following shows examples of entity names in an XML encoded form, where the XML tag is the entity name part type and the data content is the entity name part value. The use of XML in these examples does not preempt any XML implementation technology specification; it is solely for the purpose of this example.

A very simple encoding of "John W. Doe" would be:

<name>
  <given>John</given> <given>W.</given> <family>Doe</family>
</name>
 

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.

<name>
  <prefix qualifier="AC">Dr. phil. </prefix>
  <given>Regina</given>
  <given>Johanna</given>
  <given>Maria</given>
  <prefix qualifier="NB">Gräfin </prefix>
  <prefix qualifier="VV">von </prefix>
  <family qualifier="BR">Hochheim</family>-<family qualifier="SP">Weilenfels</family>
  <suffix qualifier="PR">NCFSA</suffix>
</name>
 

The next example is an organization name, "Health Level Seven, Inc." in simple string form:

  <name>Health Level Seven, Inc.</name>
 

and as a fully parsed name

<name>Health Level Seven, <suffix qualifier="LS">Inc.</suffix></name>
 

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

  <name use="IDE"><family>木村</family> <given>道男</given></name>
  <name use="SYL"><family>きもら</family> <given>みちお</given></name>
  <name use="ABC"><family>KIMURA</family> <given>MICHIO</given></name>
 

Definition:      A restriction of entity name part that only allows those entity name parts qualifiers applicable to person names. Since the structure of entity name is mostly determined by the requirements of person name, the restriction is very minor.

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

The domain of person name part type is a restriction of the entity name part type domain (although it is currently identical.)

Definition:      The 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

The domain of person name part qualifiers comprises all concepts of the entity name qualifier domain but the legal status.

Definition:      A name for a person. A sequence of name parts, such as first name or family name, prefix, suffix, etc.

Definition:      A restriction of entity name part that only allows those entity name parts qualifiers applicable to organization names.

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

The domain of organization name part type is a restriction of the entity name part type domain.

Definition:      The 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

The domain of organization name part qualifiers comprises all concepts of the entity name qualifier domain but the legal status.

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

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

<name>Health Level Seven, Inc.</name>;
 

And with the legal status "Inc." as a distinguished name part:

<name>Health Level Seven, <suffix qualifier="L">Inc.</suffix></name> 

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

Definition:      The quantity data type 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.)

The diff property described above is carried in the QTY type's annotation. All specializations of QTY will have such a diff element in their xsd:annotation, which is required by the IVL generic data type to define its width element.

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.

The XML representation of an integer can be either as a simple XML schema type (suitable for use in an XML attribute) or as a complex XML schema type preferred for use as an XML element. The simple type is used only in the HL7 data type schema (including defining the complex type.) The simple type cannot distinguish the different flavors of null.

By convention, simple types have a schema name that uses the lower case form of the HL7 data type short name.

Normally the integer is used as a complex XML schema type that has all the common data type components, such as the null flavor available. The simple integer value itself appears as the XML-attribute value.

By convention, complex XML types have a schema name that uses the upper case form of the HL7 data type short name.

Although the use of the XML-attribute value is optional, the constraint (expressed as an XPath predicate), specifies that there must be either an XML-attribute value or the ANY.nullFlavor, but not both.

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.

The XML representation of an real number can be either as a simple XML schema type (suitable for use in an XML attribute) or as a complex XML schema type preferred for use as an XML element. The simple type is used only in the HL7 data type schema (including defining the complex type.) The simple type cannot distinguish the different flavors of null.

By convention, simple types have a schema name that uses the lower case form of the HL7 data type short name.

Normally the real is used as a complex XML schema type that has all the common data type components, such as the null flavor available. The simple real value itself appears as the XML-attribute value.

By convention, complex XML types have a schema name that uses the upper case form of the HL7 data type short name.

Although the use of the XML-attribute value is optional, the constraint (expressed as an XPath predicate), specifies that there must be either a XML-attribute value or the ANY.nullFlavor, but not both.

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

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

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 Appendix B of this specification.

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

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.

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.

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

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.

Definition:      The magnitude of the monetary amount in terms of the currency unit.

Definition:      The currency unit as defined in ISO 4217.

A subset of the ISO 4217 currency codes are defined as an XML enumeration schema type. The limitations of this selection is arbitrary and not normative. All ISO 4217 currencies are permitted values.

Definition:      A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and denominator are not automatically cancelled out. The RTO data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios. In many cases the REAL should be used instead of the RTO.

NOTE: This data type is not defined to generally represent rational numbers. It is used only if common factors in numerator and denominator are not supposed to cancel out. This is only rarely the case. For observation values, ratios occur almost exclusively with titers.

The default value for both numerator and denominator is the integer number 1 (one.) The denominator may not be zero.

NOTE: This data type is defined as a generic data type but discussed in the context of the other quantity-related data types. The reason for defining RTO as a generic data type is so that it can be constrained precisely as to what the numerator and denominator types should be. See Section (§ ) for more detail about generic data types and how they are defined in XML.

Definition:      The quantity that is being devided in the ratio. The default is the integer number 1 (one.)

Definition:      The quantity that devides the numerator in the ratio. The default is the integer number 1 (one.) The denominator must not be zero.

XML instances must use the xsi:type schema type assertion mechanism to specify the particular restriction of QTY being used for numerator and denominator respectively.

We also define a complete data type RTO instantiated to the most general, unconstrained form of ratio, RTO<QTY,QTY>

<observation>
  ...
  <code code="22497-2" codeSystem="&LN;" displayName="RUBELLA VIRUS AB"/>
  ...
  <value><numerator value="1"/><denominator value="64"/></value>  
  ...
</observation> 

<gasprice><numerator value="1.15" currency="USD"/><denominator value="1" unit="[gal_us]"/></gasprice> 

<ingredient>
  ...
  <qty><numerator xsi:type="PQ" value="25" unit="mg"/><denominator xsi:type="PQ" value="5" unit="mL"/></qty>
  ...
</ingredient> 

Definition:      A a quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression.

In XML points in time are represented using the ISO 8601 complient form traditionally in use with HL7. This is the form that has no decorating dashes, colons and no "T" between the date and time. In short, the syntax is "YYYYMMDDHHMMSS.UUUU[+|-ZZzz]" where digits can be left off from the right side to express less precision. Common forms are "YYYYMMDD" and "YYYYMMDDHHMM", but the ability to truncate on the right side is not limited to these two variants. See the Data Types Abstract Specification for detail.

This is not the W3C Schema form for dateTime. The W3C Schema time data types do not lend themselves as well to representing the varying precision as well as the simpler ISO 8601 variant that is well established in HL7.

The XML representation of a Point in Time can be either as a simple XML schema type (suitable for use in an XML attribute) or as a complex XML schema type preferred for use as an XML element. The simple type is used only in the HL7 data type schema (including defining the complex type.) The simple type cannot distinguish the different flavors of null.

By convention, simple types have a schema name that uses the lower case form of the HL7 data type short name.

Normally the Point in Time is used as a complex XML schema type that has all the common data type components, such as the null flavor available. The simple Boolean value itself appears as the XML-attribute value.

By convention, complex XML types have a schema name that uses the upper case form of the HL7 data type short name.

The Data Types Abstract Specification defined generic types, also called "parameterized types" (UML), "generics" (ADA) or "templates" (C++). Generic types are incomplete types with parameters such that they define actual types (sometimes called "instantiated" types) when their parameters are specified. For example, a LIST<T> is a generic sequence of any values of a parameter type T. Given this generic type we can specify specific types such as LIST<CE> as sequences of codes or LIST<PQ> for a sequences of physical quantities.

The Data Types Abstract Specification specifies two different kinds of generic types, "generic collections" and "generic type extensions". Generic collections specify sets, sequences or other groups of data values. Generic type extensions provide extensions to normal types that are of general use, such as a valid-time for a "history item" or a probability for an "uncertain value".

In this XML specification, however, we will present these two kinds of types together. The reason is that enumerated collection types do not exist in the common use of XML. Instead it is common practice in XML to represent enumerated collections as a sequence of XML elements with the same name (repeated element). Therefore we define all such enumerated collection types as generic type extensions of their element type. For example, instead of having an XML element that stands for a whole BAG, we have generic type extension for bag-item (BXIT) so that the XML-element of type BAG is defined in the schema as a bag-item that can repeat.

Because XML schema has no mechanism for defining generic types, this specification uses an extension of the XML Schema Definition (XSD), the "Generic Schema Definition" (GSD). The GSD contains all of XSD plus extension elements for defining and using generic schema types. A XSL transform is included as Appendix (§ ) that transforms GSD into XSD, expanding all references to generic types into normal schema types.

We describe the generic schema definition language in an example. The following schema fragment shows a possible definition of the bag item (BXIT) generic data type extension using the Generic Schema Definition (GSD) language.

The XML-element gsd:template with only an XML-attribute name indicates a generic data type being defined. The GSD template is, not unlike an XSLT template, a template for an XML output generating the real XML Schema data type as an instantiation of the GSD template.

A generic type has at least one parameter defined by the XML-element gsd:param. A parameter has a name and may be constrained to any specialization of the type indicated by the XML-attribute type.

After the parameter sequence follows an XSD type definition, however the XML-element xsd:complexType (or the XML-element xsd:simpleType) has no XML-attribute name. The name of generic type instantiations is generated using the name of the generic type and all the supplied actual parameter types in the order defined in the gsd:template's parameter sequence, all separated by underscores. Thus, BXIT<CD> becomes BXIT_CD in the XML schema.

An XML-element gsd:attribute inserts an XML attribute into its containing element (similar to an XSLT XML-element xsl:attribute). The purpose is to insert actual parameters of the template instantiation as an attribute named by the XML-attribute name. In this case the XML-attribute base is added to the XML-element xsd:extension as this is a generic type extension, that extends its parameter type.

When this generic type is instantiated with, for example, the CD type, the generic type instantiation BXIT<CD> generates the following schema fragment.

A generic type is instantiated using the XML-element gsd:template with an XML-attribute as (e.g., within an XML-element xsd:element.) The local effect is that an attribute of the name given in the XML-attribute as will be generated in the element enclosing the XML-element gsd:template whose value is the name of the instantiated generic type. So, for example:

will generate the following XML Schema element definition

Definition:      A value that contains other discrete values in a defined sequence.

In XML, a LIST<T> is represented in two ways. Some sequences that are components of other data types and whose item type T has a literal form are represented as an XML attribute whose XML attribute type is "list of xsd:token".

If, however, the base data type T cannot be represented as an XML attribute of XML schema type xsd:token or if the LIST<T> is instantiated as the data type of a RIM class or attribute, LIST<T> is represented as a sequence of XML elements by the tag name of that attribute or component.

Definition:      An unordered collection of values, where each value can be contained more than once in the bag.

In XML, a BAG<T> is represented in two ways. Some bags that are components of other data types and whose item type T has a literal form are represented as an XML attribute whose XML attribute type is "list of xsd:token".

If, however, the base data type T cannot be represented as an XML attribute of XML schema type xsd:token or if the BAG<T> is instantiated as the data type of a RIM class or attribute, BAG<T> is represented as a sequence of XML elements by the tag name of that attribute or component and of the ITS-defined type "bag item".

Definition:      A generic data type extension that represents a collection of a certain number of identical items in a bag.

A bag item allows a "compressed" representation of a bag, where the same bag items need not be represented repeatedly, but can be quantified by a number. This representation of a bag is useful if relatively few different items occur in relatively large numbers, as it is the case in statistical data collections.

The bag item type, although it is fully consistent with the Data Types Abstract Specification, is only defined in the ITS, because it only specifies a certain form in which a bag of values can be represented more efficiently without adding any special semantics that was not already given in the definition of the bag data type.

Definition:      The quantity in which the bag item occurs in its containing bag.

This atribute's default value is 1, i.e., the qty attribute need not be specified if items are not quantified but simply repeated.

Definition:      A value that contains other distinct values in no particular order.

Exceptional values (NULL-values) can not be elements of a set.

The empty set is a set without any elements. The empty set is a proper set value, not an exceptional value (NULL-value).

In XML, a SET<T> is represented in two ways. Some sets that are components of other data types and whose item type T has a literal form are represented as an XML attribute whose XML attribute type is "list of xsd:token".

If, however, the base data type T cannot be represented as an XML attribute of XML schema type xsd:token or if the SET<T> is instantiated as the data type of a RIM class or attribute, SET<T> is represented as a sequence of XML elements by the tag name of that attribute or component.

The XML ITS in its XML schema definition does not formally constrain elements of a set to be unique and non-NULL. Applications may raise an error if they encounter an instance with non-unique or NULL elements.

Definition:      An ITS-defined generic type extension for the base data type of a set, representing a component of a general set over a discrete or continuous value domain. It's use is mainly for continuous value domains. Discrete (enumerable) set components are the individual elements of the base data type.

Definition:      A code specifying whether the set component is included (union) or excluded (set-difference) from the set, or other set operations with the current set component and the set as constructed from the representation stream up to the current point.

The domain for set operator is defined in XML as an enumeration.

Definition:      A set of consecutive values of an ordered base data type.

Some examples:

• There is an interval between the integers 2 and 4



• There is an interval between the real numbers 2.01 and 3.95



• There is an interval between 2.8 and 4.6 meter.



• There is an interval between December 4, 2000, 10:00 am and 10:30 am the same day.



• There is an interval between mile markers 210 and 225 on the Pennsylvania Turnpike.

Note that the interval boundaries must be of comparable types. It makes no sense to specify the interval between 2 meters and 4 seconds.

In any interval representation only two of the four properties high, low, width and center need to be stated and the other two can be derived. Incomplete intervals exist, where only one property is values, particularly, when no boundary or center is known, the width may still be known. For example, one knows that an activity takes about 30 minutes, but one may not yet know when that activity is started.

Because XML schema has no generic type facility, and generic types are incomplete types, there is no normative schema fragment for Interval in general. However, the following fragment defines a template used to instantiate a specific Interval of type T.

Definition:      The low limit of the interval.

Definition:      The high limit of the interval.

Definition:      Specifies whether the low limit is included in the interval (interval is closed) or excluded from the interval (interval is open).

Definition:      Specifies whether the high limit is included in the interval (interval is closed) or excluded from the interval (interval is open).

Definition:      The arithmetic mean of the interval (low plus high divided by 2). The purpose of distinguishing the center as a semantic property is for conversions of intervals from and to point values.

Note that a center doesn't always exist for every interval. Notably intervals that are infinite on one side do not have a center. Also intervals of discrete base types with an even number of elements do not have a center. If an interval is unknown on one (or both) boundaries, the center can still be asserted. In fact, the main use case for the center is to be asserted when no boundary is known.

Definition:      The difference between high and low boundary. The purpose of distinguishing a width property is to handle all cases of incomplete information symmetrically. In any interval representation only two of the three properties high, low, and width need to be stated and the third can be derived.

When both boundaries are known, width can be derived as high minus low. When one boundary and the width is known, the other boundary is also known. When no boundary is known, the width may still be known. For example, one knows that an activity takes about 30 minutes, but one may not yet know when that activity is started.

Note that the data type of the width is not always the same as for the boundaries. For ratio scale quantities (REAL, PQ, MO) it is the same. For difference scale quantities (e.g., TS) is is the data type of the difference (e.g., PQ in the dimension of time for TS). For discrete elements (INT) the width may be a REAL indicating the number of elements in the interval divided by 2.

Definition:      A generic data type extension that tags a time range to any data value of any data type. The time range is the time in which the information represented by the value is (was) valid.

For example, a value of type HXIT<CS> extended from a Coded Simple Value (CS) data type has all of the properties of the original CS value, plus a time range indicating when that code is or was valid.

Data types that already have a valid time range property (i.e., II, AD, TEL) obviously do not need these extensions. Their valid time range property can be mapped to the valid time property of the HXIT, in fact, those data types are considered history items by themselves. For example, II is the same data type as HXIT<II>.

Because XML schema has no generic type facility, and generic types are incomplete types, there is no normative schema fragment for History Item in general. However, the following fragment defines a template used to instantiate a specific History Item of type T.

Definition:      The time interval during which the given information was, is, or is expected to be valid. The interval can be open or closed infinite or undefined on either side.

Definition:      A set of data values that conform to the history item (HXIT) type, (i.e., that have a valid-time property). The history information is not limited to the past; expected future values can also appear.

The history information is not limited to the past; expected future values can also appear.

HIST<T> is represented as a sequence of XML elements by the tag name of the attribute or component and the type of HXIT<T>. That element can be repeated to represent the different values that attribute or component assumed at different time intervals.

Definition:      A generic data type extension to specify one uncertain value tagged with a coded confidence qualifier.

Definition:      A coded representation of the confidence as used in narrative utterances, such as "probably", "likely", "may be", "would be supported", "consistent with", "approximately", etc.

No standard terminology of confidence qualifiers exists, and it is unclear whether it can ever possibly exist. For instance, is "probably" more or less confidant than "could be"? The use of the confidence qualifier is thus only suited to communicate information between humans.

Definition:      A set of uncertain values with probabilities (also known as histogram.)

The easiest way to visualize this is a bar chart as shown in

This example illustrates the probability of selected major league baseball teams winning the World Series (prior to the season start). Each team is mutually exclusive, and were we to include all of the teams, the sum of the probabilities would equal 1 (i.e., it is certain that one of the teams will win).

Semantically, a non-parametric probability distribution contains all possible values and assigns probabilities to each of them. Our example has left out quite a few teams. The rules for this data type tell us that the other teams would share the "leftover" probability equally. The 8 teams in the example have a collective probability of winning the World Series of 0.47. If there were a total of 24 teams in the league, then 16 are not shown. Each of these teams would be assigned a probability of (1.00 - 0.47) / 16 = 0.033125.

Definition:      A generic data type extension used to specify a probability expressing the information producer's belief that the given value holds.

Probabilities are subjective and (as any data value) must be interpreted in their individual context, for example, when new information is found the probability might change. Thus, for any message (document, or other information representation) the information - and particularly the probabilities - reflect what the information producer believed was appropriate for the purpose and at the time the message (document) was created.

For example, at the beginning of the 2000 baseball season (May), the Las Vegas odds makers may have given the New York Yankees a probability of 1 in 10 (0.100) of winning the World Series. At the time of this writing, the Yankees and Mets have won their respective pennants, but the World Series has yet to begin. The probability of the Yankees winning the World Series is obviously significantly greater at this point in time, perhaps 6 in 10 (0.600). The context, and in particular the time of year, made all the difference in the world.

Since probabilities are subjective measures of belief, they can be stated without being "correct" or "incorrect" per se, let alone "precise" or "imprecise". Notably, one does not have to conduct experiments to measure a frequency of some outcome in order to specify a probability. In fact, whenever statements about individual people or events are made, it is not possible to confirm such probabilities with "frequentists" experiments.

Returning to our example, the Las Vegas odds makers can not insist on the Yankees and Mets playing 1000 trial games prior to the Series; even if they could, they would not have the fervor of the real Series and therefore not be accurate. Instead, the odds makers must derive the probability from past history, player statistics, injuries, etc.

Definition:      The probability assigned to the value, a decimal number between 0 (very uncertain) and 1 (certain).

Definition:      A generic data type extension specifying uncertainty of quantitative data using a distribution function and its parameters. Aside from the specific parameters of the distribution, a mean (expected value) and standard deviation is always given to help maintain a minimum layer of interoperability if receiving applications cannot deal with a certain probability distribution.

For example, the most common college entrance exam in the United States is the SAT, which is comprised of two parts: verbal and math. Each part has a minimum score of 400 (no questions answered correctly) and a perfect score of 800. In 1998, according to the College Board, 1,172,779 college-bound seniors took the test. The mean score for the math portion of the test was 512, and the standard deviation 112. These parameter values (512, 112), tagged as the normal distribution parameters, paint a pretty good picture of test score distribution. In most cases, there is no need to specify all 1-million+ points of data when just 2 parameters will do!

Note that the normal distribution is only one of several distributions defined for HL7.

Since a PPD extends its parameter type T, a simple T value is the mean (expected value or first moment) of the probability distribution. Applications that cannot deal with distributions will take the simple T value neglecting the uncertainty. That simple value of type T is also used to standardize the data for computing the distribution.

Probability distributions are defined over integer or real numbers and normalized to a certain reference point (typically zero) and reference unit (e.g., standard deviation = 1). When other quantities defined in this specification are used as base types, the mean and the standard deviation are used to scale the probability distribution. For example, if a PPD<PQ> for a length is given with mean 20 ft and a standard deviation of 2 in, the normalized distribution function f(x) that maps a real number x to a probability density would be translated to f′(x′) that maps a length x′ to a probability density as f′(x′) = f((x′ - μ ) / σ).

Where applicable, the PPD specification conforms to as reflected by . The PPD specification does not describe how uncertainty is to be evaluated but only how it is expressed. The concept of "standard uncertainty" as set forth by the ISO GUM corresponds to the "standard deviation" property of the PPD.

Because XML schema has no generic type facility, and generic types are incomplete types, there is no normative schema fragment for probabilistic uncertain values in general. However, the following fragment defines a template used to instantiate a specific PPD<T>.

Definition:      The primary measure of variance/uncertainty of the value (the square root of the sum of the squares of the differences between all data points and the mean). The standard deviation is used to normalize the data for computing the distribution function. Applications that cannot deal with probability distributions can still get an idea about the confidence level by looking at the standard deviation.

Definition:      A code specifying the type of probability distribution. Possible values are as shown in the attached table. The NULL value (unknown) for the type code indicates that the probability distribution type is unknown. In that case, the standard deviation has the meaning of an informal guess.

Table 43 lists the defined probability distributions. Many distribution types are defined in terms of special parameters (e.g., the parameters α and β for the γ-distribution, number of degrees of freedom for the t-distribution, etc.) For all distribution types, however, the mean and standard deviation are defined. The PPD data type is specified with the parameters mean and standard distribution only. The definition column contains the relationship between the special parameters and the mean μ and standard deviation σ.

The three distribution-types unknown (NULL), uniform and normal must be supported by every system that claims to support PPD. All other distribution types are optional. When a system interpreting a PPD representation encounters an unknown distribution type, it maps this type to the unknown (NULL) distribution-type.

NOTE: an ITS does not need to represent any of the specialized parameters for the distribution types. As it turns out, all of these specialized parameters can be calculated from the mean and standard deviation.

The timing specification suite of data types is used to specify the complex timing of events and actions such as those that occur in order management and scheduling systems. It also supports the cyclical validity patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing in the south during winter and north during summer) and office hours.

The timing specification data types include point in time (TS) and the interval of time (IVL<TS>) and add types that are specifically suited to repeated schedules. These additional types include periodic interval, event-related periodic interval, and finally the general timing specification types itself. All these timing types describe the time distribution of repeating states or events.

Definition:      An interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the "interval prototype" that is repeated every period.

For example, "every eight hours for two minutes" is a periodic interval where the interval's width equals two minutes and the period at which the interval recurs equals eight hours.

The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past.

Definition:      A prototype of the repeating interval specifying the duration of each occurrence and anchors the periodic interval sequence at a certain point in time.

The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no begin or end but is infinite in both future and past. A phase must be specified for every non-NULL periodic interval. The width of the phase must be less or equal the period.

Definition:      A time duration specifying as a reciprocal measure of the frequency at which the periodic interval repeats.

The period is a physical quantity in the dimension of time (TS.diff.) For an uncertain periodic interval the period is a probability distribution over elapsed time.

Definition:      Specifies if and how the repetitions are aligned to the cycles of the underlying calendar (e.g., to distinguish every 30 days from "the 5th of every month".) A non-aligned periodic interval recurs independently from the calendar. An aligned periodic interval is synchronized with the calendar.

The calendar alignment specifies a calendar cycle to which the periodic interval is aligned. The even flow of time will then be partitioned by the calendar cycle. The partitioning is called the calendar "grid" generated by the aligned-to calendar cycle. The boundaries of each occurrence interval will then have equal distance from the earliest point in each partition. In other words, the distance from the next lower grid-line to the beginning of the interval is constant.

For example, with “every 5th of the month” the alignment calendar cycle would be month of the year (MY.) The even flow of time is partitioned in months of the year. The distance between the beginning of each month and the beginning of its occurrence interval is 4 days (4 days because day of month (DM) starts counting with 1.) Thus, as months differ in their number of days, the distances between the recurring intervals will vary slightly, so that the interval occurs always on the 5th.

Definition:      Indicates whether the exact timing is up to the party executing the schedule (e.g., to distinguish "every 8 hours" from "3 times a day".)

For example, with a schedule "three times a day" the average time between repetitions is 8 hours, however, with institution specified time indicator true, the timing could follow some rule made by the executing person or organization ("institution"), that, e.g., three times a day schedules are executed at 7 am, noon, and 7 pm.

Three times a day, i.e., every 8 hours at institution specified times.

<effective_time xsi:type="PIVL_TS" institutionSpecified="true"><period value="8" unit="h"/></effective_time> 

Three times a day, i.e., every 8 hours at institution specified times.

<effective_time xsi:type="PIVL_TS" institutionSpecified="true"><period value="8" unit="h"/></effective_time> 

Twice a day for ten minutes.

<effective_time xsi:type="PIVL_TS"><phase><width value="10" unit="min"/></phase><period value="12" unit="h"/></effective_time> 

September, the entire month, every year (note that in the year 1987 in the generic form is irrelevant since the periodic interval recurs every year past and future.)

<effective_time xsi:type="PIVL_TS" alignment="MY"><phase><low value="1987-09" inclusive="true"/><high value="1987-10" inclusive="false"/></phase><period value="1" unit="a"/></effective_time> 

Every other Saturday.

<effective_time xsi:type="PIVL_TS" alignment="DW"><phase><low value="2000-12-02" inclusive="true"/><high value="2000-12-03" inclusive="false"/></phase><period value="2" unit="wk"/></effective_time> 

Definition:      Specifies a periodic interval pf time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time.

For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time.

Such events qualify for being adopted in the domain of this attribute for which all of the following is true:

• the event commonly occurs on a regular basis,



• the event is being used for timing activities, and



• the event is not entirely determined by time.

Definition:      An interval of elapsed time (duration, not absolute point in time) that marks the offsets for the beginning, width and end of the event-related periodic interval measured from the time each such event actually occurred.

For example: if the specification is "one hour before breakfast for 10 minutes" the offset's low boundary is (1 h and the offset's width is 10 min (consequently the offset's high boundary is (50 min.)

Definition:      A set-component that is itself made up of set-components that are evaluated as one value.

Definition:      A component of a parenthetic set expression.

Definition:      A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing in the south during winter and north during summer) and office hours.

NOTE: A GTS is nothing else than a SET<TS>.

A GTS is represented in XML as a sequence of XML elements of type SXCM<TS> or its specializations, including IVL<TS>, PIVL<TS>, EIVL<TS>.