HL7 Table HL70104: Version ID

HL70104 is the version-identifier table that appears in MSH-12 Version ID on every HL7 v2 message ever sent. It answers a single, foundational question: which release of the HL7 v2 standard does this message claim to conform to. Every parser reads MSH-12 before anything else, because the version determines segment definitions, field cardinality, data-type shapes, and which of the other code tables (like HL70354 Message Structure) are in force. The codes are drawn from the VID composite's first component and run from 2.0 through the draft 2.9.

Purpose

HL70104 lets a receiver know exactly which grammar to apply when parsing the rest of the message. A PID segment in v2.3 does not have the same field list as a PID in v2.8.1; the receiver must key its structure definitions to MSH-12. The value is also used for conformance negotiation: a receiver that only understands v2.5 can reject a v2.8.1 message with a 203 "Unsupported version id" error (see HL70357) rather than mis-parse it.

Because the table is HL7-defined, the code is the official release designator assigned by HL7 International when each version was published. Senders must not invent version strings; a message claiming version 2.10 or HL7v2 is non-conformant and cannot be reliably parsed.

Where it's used

• MSH-12 Version ID — the canonical and effectively only home of HL70104, present on the header of every v2 message and ACK.
• Conformance rejection logic — receivers compare MSH-12 against their supported-version list and emit 203 in an ERR segment when the version is unsupported.
• Engine routing — interface engines select the correct segment/field grammar and the correct downstream mapping ruleset based on this value.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.41
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0104

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile carries MSH-12 as a coded element with OID binding.

HL7-defined vs user-defined

HL70104 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and each code is the official release designator assigned by HL7 International at publication time. Local extension is not permitted — sites cannot mint a private 2.5.1-local version. Site-specific profiling is expressed through MSH-21 (Message Profile Identifier), not by altering MSH-12.

Version differences

• v2.1 – v2.2 — Early releases; MSH-12 was a simple string. 2.0, 2.0D, 2.1, 2.2 are the historical codes.
• v2.3 — The VID (version identifier) composite was formalized so MSH-12 could optionally carry an internationalization code (component 2) and international version ID (component 3) alongside the version literal.
• v2.3.1 – v2.5.1 — Incremental releases; each added its own code to HL70104 as it was published.
• v2.6 – v2.8.1 — The releases most widely deployed in production interfaces today. 2.8.1 (April 2014) is the last of the "2.8.x" normative family for the purposes of this table set.
• v2.8.2 — A maintenance release (May 2015); code 2.8.2 present in the table.
• v2.9 — Carried in HL70104 as Draft 2.9 (September 2017 draft designation). Messages claiming 2.9 should be treated as the 2.9 grammar.

Common mistakes

• Sending a marketing string like HL7v2 or 2.x in MSH-12. Only the exact release codes in the table are valid; anything else should be rejected with 203.
• Assuming MSH-12 is a plain string and ignoring the VID composite. In v2.3+ profiles MSH-12 may carry 2.8.1^ANS^X3.4 where components 2 and 3 are the internationalization code and international version ID.
• Emitting 2.10 in anticipation of a future release. There is no 2.10; HL7 uses 2.9 and would continue with further dotted designators only as published.
• Down-converting a v2.8.1 payload but leaving MSH-12 at 2.8.1. If a bridge strips v2.8.1-only fields to feed a v2.3 receiver, MSH-12 must be rewritten to the actual grammar emitted.
• Treating 2.0D as a production version. It is a demonstration-only designator and should never appear on live clinical traffic.

Examples

A minimal MSH declaring version 2.8.1:

MSH|^~&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20260701120000||ADT^A01^ADT_A01|MSG00001|P|2.8.1

MSH-12 carried as a full VID composite in a v2.5+ profile (version, internationalization code, international version ID):

MSH|^~&|LAB|HOSP|EHR|CLINIC|20260701120500||ORU^R01^ORU_R01|MSG00002|P|2.5.1^ANS^X3.4

An unsupported-version rejection: a v2.5-only receiver returns a 203 when it receives a v2.8.1 message (see HL70357):

MSH|^~&|EHR|CLINIC|SENDING_APP|SENDING_FAC|20260701120600||ACK^A01^ACK|MSG00003|P|2.5
MSA|AR|MSG00001
ERR||MSH^1^12|203^Unsupported version id^HL70357|E

Mapping/parse failure — invalid version literal:

MSH|^~&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20260701120700||ADT^A01^ADT_A01|MSG00004|P|2.10

2.10 is not a member of HL70104. A conformant engine should reject with 203 and route the message to a curation queue rather than guess at the intended grammar.

FHIR mapping

There is no official ConceptMap published for HL70104 in the HL7 v2-to-FHIR Implementation Guide, and none is expected: HL70104 describes the serialization version of the source message, not clinical or administrative content that flows into a FHIR resource.

The conceptually analogous idea in FHIR is the profile a resource claims conformance to (Resource.meta.profile) or, in FHIR Messaging, MessageHeader.definition — but these identify FHIR artifacts, not the originating v2 release. In practice the v2 version drives which set of ConceptMaps and structure maps an engine applies, so it is metadata that governs the transformation rather than a value that is itself transformed.

Engines that need to record provenance should stash the original MSH-12 value in a Provenance resource or a MessageHeader.source extension rather than attempting to coerce it into a code element.

Engine considerations

• Parse-order primacy — MSH-12 must be read before segment-level parsing, because it selects the grammar. Engines that hard-code a single version will mis-parse cross-version traffic.
• VID composite handling — In v2.3+ profiles MSH-12 is a VID composite; parse only component 1 for the version literal but preserve components 2 and 3 for round-trip.
• Supported-version negotiation — Maintain an explicit allow-list of supported versions; reject others with 203 rather than best-effort parsing.
• Down/up-conversion integrity — When a bridge changes the grammar of the payload, rewrite MSH-12 to match what is actually emitted; never leave a stale version claim.
• Case and exactness — Codes are exact literals (2.8.1, not 2.8.01 or V2.8.1); normalize and validate on ingest.

How Vorro handles HL70104

Vorro reads MSH-12 first on every inbound message and uses it to select the segment/field grammar and the correct downstream mapping ruleset for that channel. Values outside HL70104 — marketing strings, invented 2.10-style literals, or empty MSH-12 — are rejected at the envelope layer with a 203 error in the ERR segment and an AR/CR acknowledgment, and the original value is preserved in the audit log.

On outbound, Vorro sets MSH-12 to the exact release its target channel is configured to emit. When a channel down-converts a payload (for example, stripping v2.8.1-only fields to satisfy a v2.3 receiver), Vorro rewrites MSH-12 to the grammar actually produced so the receiver never sees a version claim it cannot honor. The original inbound MSH-12 is carried into FHIR provenance metadata when messages are transformed to FHIR resources.

Related pages

• MSH segment — Message Header
• HL70103 code table — Processing ID
• HL70354 code table — Message Structure

Sources

• HL7 Terminology — CodeSystem v2-0104 Version ID
• HL7 v2 product brief