HL7 v2+ Specification, published by HL7 International. This guide is not an authorized publication; it is the continuous build for version 0.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/v2ig/ and changes regularly. See the Directory of published versions

• Content
• Detailed Descriptions
• Mappings
• XML
• JSON
• TTL

Logical Model: HL7 v2 HD Data Type

Official URL: http://hl7.org/v2/StructureDefinition/HD				Version: 0.0.0
Standards status: Informative				Computable Name: HD

The HD is designed to be a more powerful and more general replacement for the application identifier of HL7 versions 2.1 and 2.2. It adds two additional components, the and the to the former application ID (which is renamed more generically to be the namespace ID).

In the case where an HD identifies an entity that assigns/creates instance identifiers such as a particular patient registration system, it defines an "assigning authority". In the case where an HD identifies a location where instance identifiers are given out (although they may be created by another entity at another location) such as a particular "department of motor vehicles office location," it defines an "assigning facility". These two different uses of the HD appear in many of the extended data types.

The "assigning authority" defined by the HD is similar in its role to the coding system (and version) part of the coded element data types: both identify a set of more discrete instance identifiers. The difference is that the set of HD-defined discrete instances contain identifiers of "real-world" things such as patient or clinical orders, while the coded element-defined set of discrete instances contains concept identifiers (codes).

The HD is designed to be used either as a local identifier (with only the valued) or a publicly-assigned identifier, a UID ( and both valued). Syntactically, the HD is a group of two identifiers: a local identifier defined by the first component and a universal identifier defined by the second and third components. HDs that have defined third components (defined UID types) must have a second component that is unique within the series of IDs defined by that component.

Note: The HD is used in fields that in earlier versions of HL7 used the IS data type. Thus, a single component HD (only the first component valued) will look like a simple IS data type for older systems expecting a single component in the place of the HD data type.

If the first component for the HD data type is present, the second and third components are optional. If the third component is present, then the second must also be present (although in this case the first is optional). The second and third components must either both be valued (both non-null), or both be not valued (both null).

This means that if all three components of the HD are valued, the entity identified by the first component is the same as the entity identified by components two and three taken together. However, implementers may choose, by site agreement, to specify that if all three components of the HD are valued, the first component defines a member in the set defined by the second and third components.

Examples:

Example 1: ISO example with only the 2^nd^ and 3^rd^ components valued:

^2.16.840.1.113883.19^ISO

The syntax of the second component is defined by the ISO standard for object identifiers, not by HL7 (for which the second component is of the ST data type). Thus the periods (".") in the second component are part of the ISO syntax, and are legal by the definition of the HL7 ST data type.

Example 2: A UUID example

^478A0114-EBF0-7701-A023-6841FF05731A^UUID

Example 3: A DNS example

^falcon.iupui.edu^DNS

Local examples:

Example 4: Local use only: a HD that looks like an IS data type

LAB1

RX.PIMS.SystemB.KP.CA.SCA

Note that the syntax of the first component is not defined by HL7 but by the site according to its own needs: the only requirement is that the first component’s structure is allowed by the HL7 string (ST) data type, which is used for values by the IS data type.

Example 5: Local identifier using components 2 and 3 only [.underline]#(Deprecated as of v2.8 and will be withdrawn in V2.10)#

^RX.PIMS.SystemB.CA.SCA^M

An alternate way to encode the previous example, illustrating the use of the third component value of "M" (see file:///E:\V2\v2.9%20final%20Nov%20from%20Frank\V29CH02C_Tables.docx#HL70301[_HL7 Table 0301 - Universal ID type] below) to identify a locally-defined identifier set. The second component has the same value as the previous example but is now defined to be a member of a set of allowable values defined by a site for the identifier set “M”. [.underline]#The use of local coding schemes as Universal ID Types is deprecated as of v 2.8; assigning authorities should be identified with true Universal IDs.#

Example 6: local identifier and universal ID types:

LAB1^2.16.840.1.113883.19.1.2.3.3.4.6.7^ISO

A HD with an ISO "object Identifier" as a UID and a locally defined system name. Both the first component and the second and third (taken together) refer to the same entity. This example shows that the local value and the universal ID value may be transmitted with a single HD field.

Usage:

• Use this Logical Model Profile: HL7 v2 CX Data Type, HL7 v2 ED Data Type, HL7 v2 NDL Data Type, HL7 v2 PL Data Type... Show 4 more, HL7 v2 PPN Data Type, HL7 v2 RP Data Type, HL7 v2 XCN Data Type and HL7 v2 XON Data Type

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

 

Other representations of profile: CSV, Excel