NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Code Table9 min read

HL7 Table HL70354: Message Structure

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):

CodeDisplayComment/Description
ACKVariesGeneral acknowledgment message structure; used for ACK responses across trigger events.
ADT_A01A01, A04, A08, A13Admit/visit notification family; shared by admit, registration, update, and cancel-discharge events.
ADT_A02A02Transfer a patient.
ADT_A03A03Discharge/end visit.
ADT_A05A05, A14, A28, A31Pre-admit / add-update person information family.
ADT_A06A06, A07Change outpatient/inpatient class family.
ADT_A09A09, A10, A11Patient departing / arriving / cancel-admit tracking family.
ADT_A12A12Cancel transfer.
ADT_A15A15Pending transfer.
ADT_A16A16Pending discharge.
ADT_A17A17Swap patients.
ADT_A20A20Bed status update.
ADT_A21A21, A22, A23, A25, A26, A27, A29, A32, A33Leave-of-absence / cancel family.
ADT_A24A24Link patient information.
ADT_A37A37Unlink patient information.
ADT_A38A38Cancel pre-admit.
ADT_A39A39, A40, A41, A42Merge person / patient identifier family.
ADT_A43A43Move patient information — patient identifier list.
ADT_A44A44Move account information.
ADT_A45A45Move visit information.
BAR_P01P01Add patient account.
BAR_P02P02Purge patient account.
BAR_P05P05Update account.
BAR_P06P06End account.
BAR_P10P10Transmit ambulatory payment classification.
BAR_P12P12Update diagnosis/procedure.
DFT_P03P03Post detail financial transaction.
DFT_P11P11Post detail financial transactions — expanded.
MDM_T01T01, T03, T05, T07, T09, T11Original document / addendum notification family.
MDM_T02T02, T04, T06, T08, T10Original document / addendum notification and content family.
MFN_M02M02Master file — staff/practitioner.
MFN_M04M04Master file — charge description.
MFN_M05M05Master file — patient location.
OMG_O19O19General clinical order.
ORU_R01R01Unsolicited observation result.
ORU_R30R30Unsolicited point-of-care observation.
ORU_R31R31Unsolicited new point-of-care observation.
ORU_R32R32Unsolicited pre-ordered point-of-care observation.
ORU_W01W01Waveform result, unsolicited transmission of requested information.
QBP_Q11Q11Query by parameter requiring segment-pattern response.
QBP_Q13Q13Query by parameter requiring tabular response.
QBP_Q15Q15Query by parameter requiring display response.
RDE_O01O01Pharmacy/treatment encoded order.
RDE_O11O11, O25Pharmacy/treatment encoded order family.
RSP_K11K11Segment-pattern response (in response to QBP_Q11).
RSP_K21K21Get person demographics response.
RSP_K22K22Find candidates response.
SIU_S12S12, S13, S14, S15, S16, S17, S18, S19, S20, S21, S22, S23, S24, S26Scheduling notification family.
SSU_U03U03Specimen container status.
VXU_V04V04Unsolicited 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 → actually ADT_A01). The structure code uses the underscore form and is often not the same string as the trigger event.
  • Assuming ADT_A08 is a distinct structure. A08 is carried by the ADT_A01 structure; sending ADT_A08 may fail validation against a strict receiver.
  • Hard-coding one structure per message code. ADT alone 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.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides