HL7 HD Hierarchic Designator
HL7 datatype components HD components from HL7 v2.5.1 Hide components
These are the generated components for the version selected at the top of the page. The article stays practical, and this panel follows the chosen HL7 version.
Components
HD is the HL7 v2 datatype for a hierarchic designator. In real interface work, it is the little structure that says which application, facility, assigning authority, assigning facility, or identifier namespace you are talking about.
You see HD directly in message headers such as MSH-3 Sending Application, MSH-4 Sending Facility, MSH-5 Receiving Application, and MSH-6 Receiving Facility. You also see it inside other datatypes: CX assigning authorities, XCN provider authorities, XON organization authorities, PL facility and location authority, and the authority pieces inside EI.
The practical job of HD is simple: turn a local-looking label into a governed identity. LAB may be enough inside one interface. LAB^2.16.840.1.113883.19.3.2^ISO is much clearer when messages cross organizations, databases, migration boundaries, or enterprise routing rules.
This example carries a local namespace ID and a universal OID-style ID for the same authority. Some feeds send only the first component. Some send only the universal pair. Both patterns can be valid if the interface agreement is clear.
HD-1: Namespace ID
HD-1 is the local namespace ID. This is the short name people usually recognize: CITYHOSP, EHR, LIS, LAB1, RAD, or another locally governed code.
Local does not mean casual. The namespace should be stable and agreed. If LAB means the lab application in one message and the lab facility in another, every downstream rule built on that value becomes fragile. For MSH fields, decide whether the value identifies an application, an application instance, a facility, a department, or a routing endpoint.
HD-1 is also the piece that keeps older/simple interfaces readable, because a single-component HD looks a lot like the older single-component application or facility identifiers. That backward-friendly shape is useful, but it is not a license to let everyone invent their own spelling.
HD-2 to HD-3: Universal ID and Universal ID Type
HD-2 is the universal ID. HD-3 is the universal ID type. The two belong together. If HD-3 is populated, HD-2 needs to be populated too; an ID type without the ID is not meaningful.
Common universal ID types include ISO for OIDs, UUID or GUID for UUID-style identifiers, DNS for domain names, and other values defined by the universal ID type table. The value in HD-2 must follow the rules of the type in HD-3. An OID-style value with ISO is not the same thing as a DNS name with DNS.
The universal pair is what helps across enterprise and cross-organization boundaries. Local namespace values collide. OIDs, UUIDs, DNS names, and other universal identifiers give you a stronger way to say "this is the exact authority I mean."
Where HD Shows Up Most
HD shows up in message routing first. MSH-3 through MSH-6 identify the sending and receiving applications and facilities. Batch and file headers use the same idea. Master file and network status segments use HD when an application or facility identity matters.
HD also shows up wherever HL7 needs an assigning authority or assigning facility. In CX-4, it names the authority for a patient or visit identifier. In XCN-9, it names the authority for a provider identifier. In XON-6, it names the authority for an organization ID. In PL-4, it identifies the facility part of a patient location.
That spread is why sloppy HD values are so expensive. One unclear namespace can affect patient matching, order matching, provider matching, facility routing, acknowledgements, location feeds, billing handoffs, and master data reconciliation.
Assigning Authority versus Assigning Facility
Assigning authority and assigning facility are related, but they are not the same. The assigning authority owns the identifier namespace. The assigning facility is the place or facility context where the identifier was assigned or is locally meaningful.
In a small hospital, those may be the same value and nobody notices. In an enterprise with one MPI, several hospitals, historical account systems, and outside labs, the difference matters. A patient identifier can be assigned by an enterprise authority while the encounter or bed belongs to one facility. A provider ID can be nationally assigned while the provider's local facility context is separate.
If the profile gives you both authority and facility, use them intentionally. Do not copy the same value into both fields just because the receiver accepted it once.
Local Namespace versus Universal Identity
A local namespace is fast and familiar. A universal ID is stronger and more portable. The right answer depends on the workflow. A simple internal feed may only need EHR. A regional HIE, public health report, lab network, or shared master-data flow should usually carry a universal identifier where the guide defines one.
When all three components are populated, they should identify the same authority unless the implementation guide has a special rule. Do not pair a local namespace from one system with an OID for another just because both are close enough in a spreadsheet.
Universal ID types that represent local coding schemes have become less attractive over time. If you need cross-organization certainty, prefer true universal IDs rather than a local string dressed up as universal.
Practical Implementation Advice
Build HD values from configuration or lookup tables, not from whatever label happened to be on a screen. Decide the application/facility/authority constants before the transform goes live, then keep them stable. Changing an HD value can be a migration event, because receivers may use it for routing, matching, and identity ownership.
In Integration Soup transformations, general string helpers are less important for HD than disciplined constants. Default() is risky here: a defaulted assigning authority can make missing identity governance look real. If an authority is required for matching and the source does not provide it, route or flag the message rather than quietly manufacturing trust.
HD components should be clean identifier values. If you find yourself needing HL7Encode() because a namespace contains a delimiter, step back and question the namespace. Encoding can protect syntax, but it will not turn a messy display label into a good authority.
When you inspect an HD in HL7 Soup Web, the interpretation view can show exactly which namespace, universal ID, and universal ID type you are looking at and jump back to that spot in the raw message. For MSH-3 through MSH-6, that makes application and facility routing mistakes much easier to spot before they become acknowledgement or matching problems.
Official Description and References
The HL7 v2+ HD detailed definition says HD identifies an administrative, system, application, or other entity responsible for managing or assigning a defined set of instance identifiers, such as placer/filler numbers, patient identifiers, and provider identifiers. The logical model also explains that HD can be local-only with namespace ID, or universal with a universal ID and universal ID type, and that if the third component is present the second component must also be present.
For formal reference, compare the generated component panel above with the HL7 v2+ HD logical model, the HL7 v2+ HD detailed definitions, and HL7 table 0301 universal ID type terminology.
Related Datatypes and Segments
For nearby datatype work, look at CX for patient-style identifiers, EI for entity identifiers, PL for locations, XCN for provider/person identifiers, and XON for organization identifiers. For common segment uses, start with MSH-3, MSH-4, MSH-5, MSH-6, EVN-7, and PID-34.