HL70354 enumerates the abstract message structures of HL7 v2 — the named segment grammars such as ADT_A01, ORU_R01, and SIU_S12. It lives in MSH-9.3 Message Structure (the third component of the MSG composite in MSH-9) and tells the receiver exactly which arrangement of segments to expect, independent of the message type (HL70076) and trigger event (HL70003) in MSH-9.1 and MSH-9.2. This is one of the largest tables in the standard: it enumerates every abstract message structure defined in HL7 v2, and many trigger events deliberately share one structure (for example ADT_A01 covers A01, A04, A08, and A13).
Purpose
MSH-9 carries three components: message code (ADT), trigger event (A01), and message structure (ADT_A01). The first two describe what happened and why; the third — HL70354 — describes how the message is laid out on the wire. Because HL7 reuses one abstract structure across many trigger events, MSH-9.3 is the value a parser actually keys its segment grammar to. A receiver that reads ADT_A08 in MSH-9.3 knows to expect the A01-family segment arrangement even though the trigger event is A08.
Because the table is HL7-defined, each structure code corresponds to a formally published abstract message definition in the v2 standard. A conformant sender populates MSH-9.3 with the exact structure that matches the segments it actually serialized; a receiver uses it to validate segment order and cardinality.
Where it's used
- MSH-9.3 Message Structure — the canonical home of HL70354, the third component of the MSG composite.
- Parser grammar selection — the structure code selects the abstract segment layout the receiver validates against.
- Routing and transformation — interface engines route and pick a transformation map based on the structure, not merely the message code.
Code list
The table enumerates all HL7 v2 abstract message structures — several hundred entries across every message family. The Display column in the HL7 Terminology source lists the trigger events that share each structure. Below is a representative, verbatim set drawn from the official CodeSystem page (it is not the complete enumeration — consult the source for every code):
| Code | Display | Comment/Description |
|---|---|---|
| ACK | Varies | General acknowledgment message structure; used for ACK responses across trigger events. |
| ADT_A01 | A01, A04, A08, A13 | Admit/visit notification family; shared by admit, registration, update, and cancel-discharge events. |
| ADT_A02 | A02 | Transfer a patient. |
| ADT_A03 | A03 | Discharge/end visit. |
| ADT_A05 | A05, A14, A28, A31 | Pre-admit / add-update person information family. |
| ADT_A06 | A06, A07 | Change outpatient/inpatient class family. |
| ADT_A09 | A09, A10, A11 | Patient departing / arriving / cancel-admit tracking family. |
| ADT_A12 | A12 | Cancel transfer. |
| ADT_A15 | A15 | Pending transfer. |
| ADT_A16 | A16 | Pending discharge. |
| ADT_A17 | A17 | Swap patients. |
| ADT_A20 | A20 | Bed status update. |
| ADT_A21 | A21, A22, A23, A25, A26, A27, A29, A32, A33 | Leave-of-absence / cancel family. |
| ADT_A24 | A24 | Link patient information. |
| ADT_A37 | A37 | Unlink patient information. |
| ADT_A38 | A38 | Cancel pre-admit. |
| ADT_A39 | A39, A40, A41, A42 | Merge person / patient identifier family. |
| ADT_A43 | A43 | Move patient information — patient identifier list. |
| ADT_A44 | A44 | Move account information. |
| ADT_A45 | A45 | Move visit information. |
| BAR_P01 | P01 | Add patient account. |
| BAR_P02 | P02 | Purge patient account. |
| BAR_P05 | P05 | Update account. |
| BAR_P06 | P06 | End account. |
| BAR_P10 | P10 | Transmit ambulatory payment classification. |
| BAR_P12 | P12 | Update diagnosis/procedure. |
| DFT_P03 | P03 | Post detail financial transaction. |
| DFT_P11 | P11 | Post detail financial transactions — expanded. |
| MDM_T01 | T01, T03, T05, T07, T09, T11 | Original document / addendum notification family. |
| MDM_T02 | T02, T04, T06, T08, T10 | Original document / addendum notification and content family. |
| MFN_M02 | M02 | Master file — staff/practitioner. |
| MFN_M04 | M04 | Master file — charge description. |
| MFN_M05 | M05 | Master file — patient location. |
| OMG_O19 | O19 | General clinical order. |
| ORU_R01 | R01 | Unsolicited observation result. |
| ORU_R30 | R30 | Unsolicited point-of-care observation. |
| ORU_R31 | R31 | Unsolicited new point-of-care observation. |
| ORU_R32 | R32 | Unsolicited pre-ordered point-of-care observation. |
| ORU_W01 | W01 | Waveform result, unsolicited transmission of requested information. |
| QBP_Q11 | Q11 | Query by parameter requiring segment-pattern response. |
| QBP_Q13 | Q13 | Query by parameter requiring tabular response. |
| QBP_Q15 | Q15 | Query by parameter requiring display response. |
| RDE_O01 | O01 | Pharmacy/treatment encoded order. |
| RDE_O11 | O11, O25 | Pharmacy/treatment encoded order family. |
| RSP_K11 | K11 | Segment-pattern response (in response to QBP_Q11). |
| RSP_K21 | K21 | Get person demographics response. |
| RSP_K22 | K22 | Find candidates response. |
| SIU_S12 | S12, S13, S14, S15, S16, S17, S18, S19, S20, S21, S22, S23, S24, S26 | Scheduling notification family. |
| SSU_U03 | U03 | Specimen container status. |
| VXU_V04 | V04 | Unsolicited vaccination record update. |
Code system OID
- OID:
2.16.840.1.113883.18.214 - Canonical URI:
http://terminology.hl7.org/CodeSystem/v2-0354
The OID resolves on the HL7 Terminology server. Vorro emits it in CWE.14 when a downstream profile carries MSH-9.3 as an OID-bound coded element (uncommon; most profiles keep the MSG composite as ID components).
HL7-defined vs user-defined
HL70354 is HL7-defined. Each structure code corresponds to a formally published abstract message definition, and the table number is inside the HL7-reserved range. Sites may not mint private structures inside HL70354; a locally invented layout must be expressed through the message-profile mechanism (MSH-21) rather than by inventing an MSH-9.3 value. Z-segments may be added to a standard structure without changing the HL70354 code.
Version differences
- v2.1 – v2.2 — MSH-9 carried only message code and trigger event; the abstract-structure concept was informal.
- v2.3.1 — MSH-9.3 Message Structure was formalized as the third component of the MSG composite, and HL70354 was introduced to enumerate the structures.
- v2.4 – v2.6 — New message families (waveforms, blood-bank, clinical genomics precursors) added their structures; existing structures gained new shared trigger events.
- v2.7 – v2.8.1 — Continued growth; MSH-9.3 became effectively required for reliable parsing as more trigger events were folded into shared structures.
- v2.9 — Additional structures added; the reuse pattern (many events → one structure) is unchanged. The exact enumeration differs slightly by release, so the structure list is version-specific — always resolve against the CodeSystem for the version in MSH-12.
Common mistakes
- Leaving MSH-9.3 empty and expecting the receiver to derive the structure from message code + trigger event. Many events share structures and some events map to more than one; the explicit MSH-9.3 value removes the ambiguity.
- Populating MSH-9.3 with the trigger event (
A08) instead of the structure code (ADT_A08→ actuallyADT_A01). The structure code uses the underscore form and is often not the same string as the trigger event. - Assuming
ADT_A08is a distinct structure. A08 is carried by theADT_A01structure; sendingADT_A08may fail validation against a strict receiver. - Hard-coding one structure per message code.
ADTalone maps to dozens of structures; routing must key on MSH-9.3, not MSH-9.1. - Treating the table as stable across versions. The enumeration grows release to release; a structure valid in v2.8.1 may not exist in v2.3.1.
Examples
An ADT^A08 (update patient) that uses the shared A01 structure:
MSH|^~&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20260701130000||ADT^A08^ADT_A01|MSG10001|P|2.8.1
EVN|A08|20260701130000
PID|1||10456^^^MRN^MR||DOE^JANE^A||19850412|F
An unsolicited lab result carrying the ORU_R01 structure:
MSH|^~&|LAB|HOSP|EHR|CLINIC|20260701131000||ORU^R01^ORU_R01|MSG10002|P|2.8.1
PID|1||10456^^^MRN^MR||DOE^JANE^A||19850412|F
OBR|1|||CBC^Complete Blood Count^L
OBX|1|NM|WBC^White Blood Cell^L||7.2|10*3/uL|4.0-11.0|N|||F
A scheduling notification using the shared SIU_S12 structure for an S14 (appointment modification) event:
MSH|^~&|SCHED|HOSP|EHR|CLINIC|20260701132000||SIU^S14^SIU_S12|MSG10003|P|2.8.1
SCH|1|A100^SCHED||||ROUTINE|OFFICE^Office Visit|30|min|^^^20260705090000^20260705093000
Structure-mismatch rejection — MSH-9.3 does not match the segments actually present:
MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701133000||ACK^R01^ACK|MSG10004|P|2.8.1
MSA|AE|MSG10002
ERR||MSH^1^9^3|100^Segment sequence error^HL70357|E
FHIR mapping
There is no official ConceptMap published for HL70354 in the HL7 v2-to-FHIR Implementation Guide. HL70354 identifies a v2 wire grammar, not clinical content, so there is no coded FHIR value set that mirrors it one-to-one.
In FHIR Messaging the analogous concept is the combination of MessageHeader.eventCoding (which event occurred) and the message Bundle profile the sender conforms to (which shape the bundle takes). The v2 structure code is what an engine uses to select the correct v2-to-FHIR structure map (e.g., the ADT_A01-to-Bundle map), so it governs the transformation rather than being transformed itself.
| HL7 v2 (HL70354) | FHIR target |
|---|---|
| ADT_A01 (and family) | (none — selects the ADT structure map; drives MessageHeader.eventCoding + Bundle shape) |
| ORU_R01 | (none — selects the ORU structure map producing an Observation/DiagnosticReport Bundle) |
| SIU_S12 (and family) | (none — selects the scheduling structure map producing Appointment/Schedule/Slot resources) |
Engine considerations
- Grammar keying — Validate segment order and cardinality against the structure named in MSH-9.3, not against a per-message-code default.
- Version-scoped tables — Load the HL70354 enumeration for the version in MSH-12; a code valid in one release may be absent in another.
- Trigger-vs-structure discipline — Do not conflate MSH-9.2 (trigger) with MSH-9.3 (structure); the shared-structure design means they are frequently different strings.
- Empty MSH-9.3 fallback — If MSH-9.3 is absent (older senders), derive the structure from message code + trigger via a lookup table, and log that a fallback was used.
- Z-segment tolerance — Accept local Z-segments appended to a standard structure without rejecting on structure mismatch, provided the standard segments remain conformant.
How Vorro handles HL70354
Vorro reads MSH-9.3 to select the segment grammar it validates against and the transformation map it applies for a channel. When MSH-9.3 is present, it takes precedence over any structure inferred from the message code and trigger event. When MSH-9.3 is absent — common from older v2.3.x senders — Vorro derives the structure from MSH-9.1 and MSH-9.2 using a version-scoped lookup and records that a fallback occurred so integration engineers can spot senders that omit the component.
Structures that are unrecognized for the declared MSH-12 version are rejected with a 200 "Unsupported message type" or 100 "Segment sequence error" (see HL70357) depending on where the mismatch surfaces, and the message is held for review rather than best-effort parsed. On transformation to FHIR, the structure code selects which structure map runs; the original MSH-9 MSG composite is preserved in message provenance.
