HL7 Table HL70076: Message Type

HL70076 is the table that tells a receiver what a v2 message is for. It is the first component of MSH-9 Message Type, and every conformant v2 message — from a 1990s ADT^A01 admission feed to a modern OML^O21 lab order — carries one of these codes as the very first thing a parser sees after the encoding characters. The table has grown across versions as HL7 has added new domains (pharmacy, scheduling, blood bank, immunization, master files, queries), and v2.8.1 enumerates well over sixty active codes.

Purpose

HL70076 identifies the kind of event the message conveys. It is the dispatch key that tells a receiver which segments to expect, which handler to invoke, and which database tables to touch. ADT messages go to the patient registration pipeline; ORU messages go to the results inbox; SIU messages go to the scheduler; VXU messages go to the immunization registry. Without HL70076 a receiver would have to parse the entire message to guess its purpose — with it, the routing decision is made on the first segment.

The code is paired with two other components inside MSH-9 to form the full message identifier:

• MSH-9.1 — Message Code (this table, HL70076), e.g. ADT.
• MSH-9.2 — Trigger Event (HL70003), e.g. A01.
• MSH-9.3 — Message Structure (HL70354), e.g. ADT_A01.

Together they identify both the family of the message (HL70076) and the exact event and segment grammar (HL70003 / HL70354). All three must be populated in v2.3.1 and later.

Where it's used

• MSH-9.1 Message Code — the canonical home of HL70076, on every v2 message ever sent.
• MSA-2 Message Control ID echoes the original message's MSH-9 in acknowledgments, indirectly carrying HL70076.
• BHS-9 / FHS-9 Batch and File Header message types use the same code set when a batch envelopes multiple messages of one kind.

Code list

HL70076 in v2.8.1 contains over sixty active codes. The most widely deployed are:

Code system OID

• OID: 2.16.840.1.113883.18.25
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0076

HL7-defined vs user-defined

HL70076 is HL7-defined. The code set is normative — receivers must recognize every published code without local extension, and senders must not invent new three-letter codes inside this table. Vendors who need a message type that HL7 has not standardized must either propose a new code through the HL7 ballot process or carry the custom payload inside an existing message type (often MDM for documents or ORU for arbitrary observations).

Version differences

• v2.1 – v2.2 — A small initial set: ADT, ORM, ORU, QRY, ACK, BAR, DFT, MFN, plus a handful of master-file codes. No formal structure component (MSH-9.3 did not exist).
• v2.3 — Master files (MFK, MFQ, MFR) and document responses (DOC) added; MSH-9 grew the structure component (HL70354) to disambiguate trigger events.
• v2.3.1 — Scheduling (SIU, SRM, SRR), patient problem/goal (PPR, PGL, PPG), and personnel management (PMU) added.
• v2.4 — Vaccination (VXU, VXQ, VXR), patient referral (REF), and pharmacy-encoded orders (RDE, RGV, RAS, RDS, RRE, RRG, RRA, RRD) added.
• v2.5 — General clinical order family (OMG, OML, OMI, OMP, OMD, OMS, OMN, OMB and their OR* acks) added. ORM is withdrawn in favor of the new OM* codes, though virtually every production interface still uses ORM.
• v2.6 — Blood bank (BPS, BRP, BRT, BTS) and sterilization (SDR, SMD) added.
• v2.7 – v2.8.1 — Set stable; subscription messaging (QSB) and minor query refinements; no withdrawals.

Common mistakes

• Forgetting the structure component (MSH-9.3). Sending ADT^A01 without ^ADT_A01 leaves a v2.4+ receiver unable to disambiguate ADT_A01 (admission) from ADT_A04 (registration), since both share trigger event family A01/A04/A08/A13 and a single segment grammar. MSH-9 in v2.3.1+ must carry all three components.
• Using legacy ORM^O01 on v2.5+ profiles. The general clinical order was split in v2.5 into domain-specific messages — OML^O21 for lab, OMG^O19 for general clinical, OMI^O23 for imaging, OMP^O09 for pharmacy. ORM is withdrawn; new interfaces should pick the correct OM* code. ORM persists in the wild only because vendor inertia is enormous.
• Putting the display string in MSH-9.1. ADT message is not the code; ADT is. MSH-9.1 is a three-letter (occasionally two- or four-letter) symbol from this table.
• Inventing local codes. XYZ^Z01^XYZ_Z01 is not conformant. HL7 reserves Z* trigger events for local use (HL70003), but the message code (MSH-9.1) must be HL7-defined.
• Routing on MSH-9.1 alone. ADT covers everything from admission to bed swap to demographic update; the trigger event (MSH-9.2) and structure (MSH-9.3) are what tell the receiver which downstream handler to invoke. Routing on the code alone collapses thirty distinct workflows into one.

Examples

A v2.5 ADT admission — all three MSH-9 components populated:

MSH|^~&|EPIC|MGH|RHIO|STATE|20260625120000||ADT^A01^ADT_A01|MSG00001|P|2.5
EVN|A01|20260625120000
PID|1||10456^^^MRN^MR||DOE^JANE^A||19850412|F
PV1|1|I|2N^201^A|R|||DR123^SMITH^J|||MED

A v2.5 lab order using the modern OML^O21 instead of the legacy ORM^O01:

MSH|^~&|CPOE|MGH|LAB|MGH|20260625120000||OML^O21^OML_O21|MSG00002|P|2.5
PID|1||10456^^^MRN^MR||DOE^JANE
ORC|NW|ORD001^CPOE
OBR|1|ORD001^CPOE||CBC^Complete Blood Count|||20260625120000

A v2.5.1 unsolicited vaccination update:

MSH|^~&|EHR|CLINIC|IIS|STATE|20260625120000||VXU^V04^VXU_V04|MSG00003|P|2.5.1
PID|1||N99821^^^MRN^MR||DOE^BABY||20260101|F
RXA|0|1|20260625||08^Hep B^CVX|0.5|mL

FHIR projection of an ADT^A01 into MessageHeader:

{
  "resourceType": "MessageHeader",
  "event": {
    "system": "http://terminology.hl7.org/CodeSystem/v2-0003",
    "code": "A01",
    "display": "Admit/visit notification"
  }
}

FHIR mapping

FHIR does not provide a one-to-one ValueSet for HL70076. The v2-to-FHIR Implementation Guide instead maps the structure code (MSH-9.3, e.g. ADT_A01) onto MessageHeader.event.coding, using HL70003 trigger events as the FHIR event code system. The HL70076 message family (MSH-9.1) is used to select the correct FHIR Bundle profile (admission, results, order, etc.) rather than to populate a single FHIR field.

Engine considerations

• Validate all three MSH-9 components. A conformant engine rejects MSH-9 if .1 is absent, if .3 is absent on v2.3.1+ profiles, or if the trio is internally inconsistent (e.g. ADT^O01^ADT_A01).
• Honor legacy ORM. Even in v2.8.1 channels, real-world senders still emit ORM^O01. Engines should accept ORM on inbound and translate to the appropriate OM* family on outbound when the downstream destination is strict.
• Three-letter assumption is wrong. Most codes are three letters, but the table also contains two-letter (none in current set) and longer codes; parsers must not hard-code length.
• Case sensitivity. Codes are uppercase. adt^a01 is not valid; normalize on ingest.

How Vorro handles HL70076

Vorro validates MSH-9.1 against the published HL70076 set on every inbound message and rejects unknown codes at the port boundary rather than risk silent mishandling downstream. Legacy ORM^O01 is accepted and, where the destination is a v2.5+ strict endpoint, translated to OML^O21 or OMG^O19 with the original ORM preserved in the audit log.

On outbound, Vorro emits the structure component (MSH-9.3) unconditionally for v2.3.1 and later destinations, even if the upstream sender omitted it — the engine reconstructs it from MSH-9.1 + MSH-9.2 using the HL70354 lookup table.

Related pages

• MSH segment — Message Header
• HL70003 code table — Trigger Event
• HL70354 code table — Message Structure

Sources

• HL7 Terminology — CodeSystem v2-0076 Message Type
• HL7 v2 product brief