The HD (Hierarchic Designator) data type was introduced in HL7 v2.3 to identify an application, facility, or assigning authority in a way that is both human-readable and globally resolvable. It carries a local namespace name, an optional universal ID (OID, GUID, UUID, etc.), and a code that names the universal-ID scheme. HD appears at the top of every HL7 v2 message in MSH-3 (Sending Application), MSH-4 (Sending Facility), MSH-5 (Receiving Application), and MSH-6 (Receiving Facility), and it is the building block embedded inside EI.4 (Universal ID for an Entity Identifier) and CX.4 (Assigning Authority for an Extended Composite ID).
Purpose
HD is HL7 v2's answer to the question "who are you?" It lets a sender name itself with a friendly local string ("MERCY-LIS") while also providing a universally resolvable identifier (the OID 2.16.840.1.113883.19.5.1) so that the message can be routed, audited, and reconciled across organizations whose namespace strings collide. Where EI and CX identify a thing, HD identifies the issuing or operating authority — the application that produced a message, the facility that issued an MRN, the organization that assigned a driver's license number.
Component table
Source: HAPI HL7v2 v2.8.1 javadocs (HD). Length is shown as — because v2.7+ deprecated fixed maximum lengths in favour of conformance-profile constraints.
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| HD.1 | Namespace ID | is | — | O | Local namespace name from user-defined HL7 table [HL70363]. Human-readable string such as MERCY or MERCY-LIS. |
| HD.2 | Universal ID | st | — | C | Globally unique identifier — typically an OID (2.16.840.1.113883...), GUID, or UUID. Conditional with HD.3. |
| HD.3 | Universal ID Type | id | — | C | Code system for HD.2. Drawn from HL7 table [HL70301]: ISO, GUID, UUID, EUI64, DNS, URI, HCD, Random. Conditional with HD.2. |
HD is unusual in that either HD.1 or HD.2+HD.3 may be the primary identifier — but at least one of those two forms must be populated for HD to be meaningful.
Most-used components
- HD.1 Namespace ID — the readable string used by integration engineers in everyday troubleshooting and routing rules.
- HD.2 Universal ID — the rigorous, globally unique identifier (OID is most common in healthcare).
- HD.3 Universal ID Type — names the code system of HD.2 so the receiver can validate and resolve it.
Where it's used
- MSH-3 Sending Application — names the application that produced the message.
- MSH-4 Sending Facility — names the facility on whose behalf the application sent.
- MSH-5 Receiving Application — names the intended receiving application.
- MSH-6 Receiving Facility — names the receiving facility.
- MSH-22 Sending Responsible Organization — organization legally responsible for the message.
- MSH-23 Receiving Responsible Organization — organization legally responsible for receiving.
- MSH-24 Sending Network Address — network locator for sender.
- MSH-25 Receiving Network Address — network locator for receiver.
- Embedded inside EI.3 / EI.4 as Universal ID and Universal ID Type — used by every order number, message control ID, and entity identifier.
- Embedded inside CX.4 Assigning Authority — every PID-3 patient identifier carries an HD here.
- Embedded inside CX.6 Assigning Facility — facility-level scope for an identifier.
- PV1-19.4 Assigning Authority (HD inside the CX) — assigning authority for the visit number.
- OBR-3.4 Filler Order Number assigning authority (HD inside the EI) — names the filler system.
Version differences
- HL7 v2.3 — HD introduced with the three-component structure shown above.
- HL7 v2.4 / v2.5 / v2.5.1 — no structural changes; vocabulary refinement on [HL70301] added codes such as
GUIDandUUID. - HL7 v2.6 / v2.7 — no structural changes; conformance guidance strengthened cross-organizational use: HD.2 and HD.3 should be co-populated whenever the message crosses organizational boundaries.
- HL7 v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — structure stable; fixed maximum lengths deprecated. HAPI v2.8.1 javadoc shows the same three components.
Common mistakes
- Populating only HD.1 Namespace ID for messages that cross organizational boundaries — namespace strings collide across vendors and acquired facilities, so HD.2/HD.3 are needed for federated reconciliation.
- Conflating Namespace ID with the Application ID —
MERCYis not the same asMERCY-EHR; the former is the organization, the latter is a specific application. Use the right granularity for the field's semantics. - Sending HD.2 without HD.3 — the receiver cannot validate or resolve the universal ID without knowing its scheme.
- Putting an OID into HD.1 — HD.1 is a Namespace ID (an IS-typed table value), not a place for OIDs. Receivers that index HD.1 will store the OID as an opaque string.
- Reusing the same HD.2 OID across logically distinct applications or facilities — collapses provenance and breaks per-application audit trails.
Examples
Minimal value (namespace only — only acceptable for intra-organizational exchange):
MERCY
Three-component value (fully resolvable HD):
MERCY^2.16.840.1.113883.19.5^ISO
Variant using UUID rather than OID:
MERCY^9c4e1f88-7a3d-4c1f-9c2a-9a3d7d3f1a2b^UUID
Embedded inside a CX.4 Assigning Authority (note & sub-component separator because HD is one delimiter level below CX):
MR884412^^^MERCY&2.16.840.1.113883.19.5&ISO^MR
In context — MSH header carrying HD in fields 3, 4, 5, and 6:
MSH|^~&|MERCY-LIS^2.16.840.1.113883.19.5.1^ISO|MERCY^2.16.840.1.113883.19.5^ISO|MERCY-EHR^2.16.840.1.113883.19.5.2^ISO|MERCY^2.16.840.1.113883.19.5^ISO|20260610113000||ORU^R01^ORU_R01|MSG00211|P|2.8.1
In context — HD embedded inside a CX.4 inside PID-3:
PID|1||MR884412^^^MERCY&2.16.840.1.113883.19.5&ISO^MR||TESTPATIENT^ALEX^Q||19720508|F
Common pitfall — namespace string only, across organizations:
MSH|^~&|LIS|MERCY|EHR|MERCY|20260610113000||ORU^R01|MSG00212|P|2.8.1
LIS and EHR are not globally unique strings — a partner organization may use the same names for entirely different applications, and HIE-level routing fails silently.
FHIR mapping
The v2-to-FHIR IG publishes several HD ConceptMaps because HD has no single FHIR target — the surrounding context determines the resource:
- ConceptMap-datatype-hd-to-identifier — when HD acts as an assigning authority inside CX or EI.
- ConceptMap-datatype-hd-to-location — when HD names a facility (MSH-4, MSH-6).
- ConceptMap-datatype-hd-to-organization — when HD names a legally responsible organization (MSH-22, MSH-23).
- ConceptMap-datatype-hd-to-device — when HD names a sending or receiving application (MSH-3, MSH-5) modeled as a
Device. - ConceptMap-datatype-hd-to-uri — when HD becomes the
systemURI on anIdentifier. - ConceptMap-datatype-hd-name-to-messageheader-source — when HD becomes
MessageHeader.sourceorMessageHeader.destination.
Default Identifier-context mapping:
| HD component | FHIR element | Notes |
|---|---|---|
| HD.1 | Identifier.assigner.display or Organization.name | Human-readable namespace. |
| HD.2 | Identifier.system | Wrapped as urn:oid:... for ISO or urn:uuid:... for UUID. |
| HD.3 | drives URN scheme on Identifier.system | Universal ID Type. |
Because HD is the "assigning authority" building block embedded inside both EI.4 and CX.4, its FHIR target depends entirely on context — the same as EI.
Engine considerations
- HD-inside-CX.4 uses
&(sub-component delimiter), HD at the top of MSH uses^(component delimiter). The same data type, two delimiter levels, depending on nesting depth. Engines that hard-code^will fail to parse HD inside CX.4. - Universal ID Type validation: HD.3 must come from HL70301. Validate at parse time; reject free-text values like
OID(the correct token isISO). - OID syntax validation: when HD.3 is
ISO, HD.2 should match the dotted-decimal OID syntax (^[0-2](.d+)+$). Soft-validate and flag deviations rather than silently accept. - Sending Application vs Sending Facility: MSH-3 (application) and MSH-4 (facility) are different identifiers with different scopes — engines should not copy one to the other to fill gaps.
- HAPI HL7v2 v2.8.1 generates
ca.uhn.hl7v2.model.v281.datatype.HDwith strongly-typed accessors; when HD appears inside CX or EI, HAPI returns it as anHDinstance.
How Vorro parses and produces HD
Vorro maintains a canonical assigning-authority registry keyed by (HD.1, HD.2, HD.3). On inbound, every HD is resolved against the registry; unknown authorities are recorded with provenance and surfaced for curation rather than silently trusted. HD.3 is validated against HL70301; values outside the standard table are tagged as soft warnings. HD-inside-CX.4 and HD-inside-EI.4 are parsed via the proper delimiter level (&) and rendered as the same internal AssigningAuthority object that the top-level MSH HDs use, so downstream consumers see one type regardless of where the HD originated.
On outbound, Vorro always emits HD with all three components when the destination is cross-organizational, and prunes HD.2/HD.3 only for intra-application traffic where the namespace alone is sufficient and well-known to both endpoints. We never emit HD.2 without HD.3.
Related pages
- CX data type — Extended Composite ID with Check Digit
- EI data type — Entity Identifier
- MSH segment — Message Header
