HL7 Table HL70363: Assigning Authority

HL70363 is the HL7 v2 code table for Assigning Authority — the namespace identifier that names the organization, application, or system that issued a given identifier. It populates the first component of the HD (Hierarchic Designator) data type, which in turn appears inside virtually every identifier composite in v2: MSH-3, MSH-4, MSH-5, MSH-6, CX.4, XCN.9, XON.6, EI.2, PL.6, and dozens more. The table has existed since v2.3 and remains user-defined through v2.8.1.

Purpose

HL70363 answers the question "who issued this identifier?" so a downstream receiver can disambiguate two MRNs that share a numeric value but were assigned by different facilities. Without an Assigning Authority, MRN 10456 from Mercy Hospital is indistinguishable from MRN 10456 from a sister hospital across town. With MRN 10456^^^MERCY^MR, the receiver knows whose patient record this refers to.

Because the table is user-defined, sites populate it with their own application and facility identifiers — there is no HL7-published master list. Common entries cover the EHR, the LIS, the radiology system, the clinical data repository, and any external authority that issues identifiers consumed by the integration channel.

Where it's used

• HD.1 Namespace ID — every HD-typed field in v2: MSH-3 Sending Application, MSH-4 Sending Facility, MSH-5 Receiving Application, MSH-6 Receiving Facility, EVN-7, PV1-3.4, PV1-6.4, PL.6.
• CX.4 Assigning Authority — the HD component inside the CX (Extended Composite ID with Check Digit) data type used for PID-3 Patient Identifier List, IN1-49 Insured's ID, GT1-2 Guarantor Number, and other patient and account identifiers.
• XCN.9, XPN, XON.6, XAD.12 — assigning authority for clinician IDs, person names with IDs, organization IDs, and address parts.
• EI.2 Namespace ID — the EI (Entity Identifier) data type used for placer and filler order numbers (ORC-2, ORC-3, OBR-2, OBR-3), specimen IDs (SPM-2), and shipment IDs.

Code list

HL70363 is user-defined and ships empty in the HL7 standard. The table below is an illustrative example showing the kind of entries a typical hospital integration team adds locally. Your site's table will look different.

In a fully-populated HD composite, the Namespace ID (HL70363) is paired with a Universal ID and a Universal ID Type from HL70301:

EHR&2.16.840.1.113883.19.5&ISO

Code system OID

• OID: 2.16.840.1.113883.18.272
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0363

The OID and canonical URI identify the table itself (the namespace of namespace IDs), not the values inside it. Because the values are site-specific, no global registry of HL70363 codes exists — only the table identifier is universal.

HL7-defined vs user-defined

HL70363 is user-defined. The HL7 standard reserves the table number and the table name ("Assigning Authority") but explicitly does not enumerate values. Every implementing site is expected to publish its own list and circulate it to trading partners.

This is the single most important property of HL70363 to internalize: the codes are not interoperable across facilities. Mercy Hospital's EHR may be its Epic instance; a neighboring hospital's EHR may be its Cerner instance. Two messages from different senders that both carry ^^^EHR^MR in CX.4 are not talking about the same authority. Receivers must either negotiate a shared namespace list with each trading partner, or rely on the Universal ID + Universal ID Type components (HD.2 + HD.3, bound to HL70301) for cross-site disambiguation.

Version differences

• v2.3 — Table introduced as IS-typed Assigning Authority for the early HD data type.
• v2.3.1 – v2.5 — Table number stabilized at 0363, still IS, still user-defined. HD becomes the universal identifier composite across all segments.
• v2.5.1 — HD grew the Universal ID (HD.2) and Universal ID Type (HD.3) components, allowing OID/ISO/UUID values to coexist with the user-defined namespace ID. HL70363 itself unchanged.
• v2.6 – v2.7 — Many fields previously typed as HD are restated as CWE-wrapped HD or upgraded to CWE entirely; HL70363 remains the source for HD.1.
• v2.8 – v2.8.1 — No semantic change. Stronger guidance in the conformance chapters that senders should populate HD.2/HD.3 whenever they expect a cross-organization receiver.

Common mistakes

• Assuming HL70363 codes are interoperable. They are not. Two sites' EHR values mean two different things. Always pair the namespace ID with HD.2/HD.3 when crossing organizational boundaries.
• Populating HD.1 only and leaving HD.2/HD.3 empty for external sends. Internal traffic can survive on the namespace ID alone; external sends to a HIE, public-health registry, or FHIR endpoint generally cannot.
• Reusing the same Namespace ID for two different systems as the source IT landscape grows. EHR was unambiguous when the site had one EHR; it isn't after the merger. Plan for collisions before they happen.
• Sending the facility's display name (Mercy Hospital) in HD.1 instead of the short code (MERCY). HD.1 is a IS/ST short identifier, not a label.
• Treating HD.1 as case-insensitive. HL70363 values are case-sensitive; epic and EPIC are different codes on the wire and downstream lookups will miss.

Examples

A PID with a CX-typed patient identifier list carrying two MRNs from two different assigning authorities:

PID|1||10456^^^MERCY^MR~A9921^^^EPIC^MR||DOE^JANE^A||19850412|F

The first MRN was issued by MERCY (Mercy Hospital's facility authority); the second by EPIC (the Epic system's enterprise namespace). A naive receiver that treats both as the same identifier will silently merge two distinct numbering systems.

Fully-qualified HD composite with Universal ID and Universal ID Type from HL70301:

MSH|^~&|EHR^2.16.840.1.113883.19.5^ISO|MERCY^2.16.840.1.113883.19.4^ISO|LIS|MERCY|20260601120000||ADT^A01|MSG00001|P|2.8.1

Same MERCY namespace expressed as a FHIR Identifier:

{
  "resourceType": "Patient",
  "id": "10456",
  "identifier": [{
    "use": "usual",
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
        "code": "MR"
      }]
    },
    "system": "urn:oid:2.16.840.1.113883.19.4",
    "value": "10456",
    "assigner": {
      "display": "Mercy Hospital"
    }
  }]
}

Mapping failure example — namespace ID unknown to the receiver:

PID|1||10456^^^ACMECORP^MR||DOE^JANE||19850412|F

If the receiver's HL70363 vocabulary table does not contain ACMECORP, a conformant engine should hold the message in a curation queue, alert the integration team, and refuse to merge the MRN into the master patient index — silently accepting an unknown authority risks attaching the MRN to the wrong patient.

FHIR mapping

There is no single ConceptMap published for HL70363 because the codes are user-defined. The HL7 v2-to-FHIR Implementation Guide instead specifies a structural mapping for the HD data type:

When HD.2/HD.3 are populated, FHIR prefers them — they are globally unique. When only HD.1 is populated, the receiver must look up the namespace ID against a locally agreed mapping to produce an Identifier.system URI.

Engine considerations

• Trading-partner mapping table — every integration engine needs a per-channel HL70363 lookup so it can translate inbound namespace IDs to canonical OIDs and outbound canonical OIDs back to the trading partner's preferred short code.
• Collision detection — when two upstream sources send the same namespace ID for different actual authorities, the engine must surface the conflict rather than silently accept both.
• Round-trip preservation — when an inbound HD has HD.2/HD.3 but no HD.1, do not invent an HL70363 value on outbound; leave HD.1 empty and let the OID stand on its own.
• CWE upgrade — some v2.7+ profiles wrap HD inside CWE. Engines must handle both forms and preserve the namespace ID either way.

How Vorro handles HL70363

Vorro maintains a per-channel HL70363 vocabulary that maps each trading partner's namespace IDs to canonical OIDs. Inbound messages are validated against the channel's vocabulary: known namespace IDs pass through to downstream channels, optionally translated to a different short code if the destination expects one. Unknown namespace IDs are routed to the terminology curation queue, where the integration team either adds the code (and a canonical OID) or refuses the message.

On outbound, Vorro emits HD.1 from the destination's vocabulary while populating HD.2 (Universal ID) and HD.3 (Universal ID Type) whenever the destination profile supports them — protecting the receiver from the cross-site ambiguity that HL70363 codes alone cannot resolve. The canonical OID for each authority is always carried through the FHIR layer as Identifier.system.

Related pages

• HD data type — Hierarchic Designator
• CX data type — Extended Composite ID with Check Digit
• HL70301 code table — Universal ID Type

Sources

• Caristix — Table 0363 (HL7 v2.8.1) Assigning Authority
• HL7 v2 product brief
• HL7 v2-to-FHIR Implementation Guide