HL7 ID Data Type: Coded Value for HL7-Defined Tables

The ID data type has existed since HL7 v2.1 and represents a single coded value drawn from an HL7-defined table. The defining property of ID — as distinct from its sibling IS — is that the value set is governed by HL7, not by the local implementation. ID is the underlying type for many of the standard's most stable fields: PID-8 Administrative Sex (HL70001), MSH-11 Processing ID (HL70103), MSH-15 / MSH-16 Accept and Application Acknowledgment Type (HL70155), and the Y/N flags such as DON-9 Donor Eligibility (HL70136) on the DON segment.

Purpose

ID delivers a single token whose meaning is fixed by an HL7 user table. There is no human-readable display name, no code-system component, and no triplet — just the code itself. Display text and richer code systems live in the composite types (CWE, CNE), which were added in v2.5 to handle situations where ID and IS were too thin.

Format and constraints

ID is a primitive: no components, no sub-components.

The value is a short coded token from an HL7-defined table. Tokens are typically 1–6 characters.
The legal value set is identified by the HL7 table number referenced in the field's profile (e.g. [HL70001]).
Case sensitivity is profile-specific; many HL7 tables are uppercase by convention (M, F, U, A, N, O), and receivers typically uppercase before comparing.
No display name and no code system are carried — ID is only the code.
Length: historically 1..2 to 1..20 depending on the table; v2.7 deprecated fixed maximum lengths in favour of conformance-profile constraints.
An empty field is null; a sent value that is not in the referenced table is a conformance error.

ID vs IS vs CWE / CNE

ID — code from an HL7-defined table. Stable across implementations.
IS — code from a user-defined table. Same wire format, different governance.
CWE / CNE — composite triplets (code + text + system) introduced in v2.5; many fields formerly typed ID/IS were promoted to CWE/CNE.

Where it's used

PID-8 Administrative Sex (ID, HL70001).
MSH-11 Processing ID (ID, HL70103) — P, D, T.
MSH-15 Accept Acknowledgment Type (ID, HL70155) — AL, NE, ER, SU.
MSH-16 Application Acknowledgment Type (ID, HL70155).
EVN-4 Event Reason Code (ID in older versions; CWE in v2.7+).
DON-9 Donor Eligibility Flag (ID, HL70136) — see DON.
DON-15 Intended Recipient Blood Relative (ID, HL70136).
DON-27 Donor Reaction (ID, HL70136).
ABS-7 Sterilization Type (ID) in surgical-abstract messages.
BHS-9 Batch Acknowledgment Type (ID, HL70155).

Version differences

v2.1 through v2.4: ID widely used as a primitive coded type alongside IS.
v2.5: CWE and CNE introduced; many ID-typed fields promoted to CWE/CNE in subsequent revisions to allow display text and external code systems.
v2.7 through v2.8.2: ID retained for stable HL7-table-bound fields (Y/N flags, processing IDs, acknowledgment types). Length governed by conformance profile.

Common mistakes

Sending a code from a user-defined table where an HL7-defined table is expected — that should be IS, not ID. The wire shape is identical, which is exactly why this slips through silently.
Sending a display name (Male) instead of the code (M). ID carries the token only.
Sending mixed case (m vs M) when the receiver compares case-sensitively. Uppercase is the safe default for HL7 tables.
Sending a CWE triplet (M^Male^HL70001) into an ID field — the ^ is interpreted as a component delimiter and the receiver rejects the whole segment.
Sending a code that is not in the referenced table and expecting the receiver to fall back to free text. ID has no escape hatch for unknown values; use CWE if you need one.

Examples

Minimal:

Acknowledgment-type value:

AL

Y/N flag:

In context — PID-8 Administrative Sex as an ID from HL70001:

PID|1||MR884412^^^MERCY^MR||TESTPATIENT^ALEX^Q||19720508|F

In context — MSH-11 Processing ID and MSH-15 Accept Acknowledgment Type:

MSH|^~&|EMR|MERCY|LIS|MERCY|20260610090000||ADT^A08^ADT_A01|MSG00091|P|2.8.1|||AL|NE

Common pitfalls:

WRONG:  PID|1||MR1^^^MERCY^MR||DOE^JANE||19800101|Female
        `Female` is display text, not the coded value from HL70001.
RIGHT:  PID|1||MR1^^^MERCY^MR||DOE^JANE||19800101|F

FHIR mapping

A primitive's FHIR target is dictated by the containing element. The v2-to-FHIR IG publishes several ConceptMaps for ID:

ID → CodeableConcept — used when the FHIR target accepts a coded concept and the ID's HL7 table is mapped to a FHIR code system.
ID → Coding — used when only a single Coding is needed.
ID → code — used when the FHIR target is a bare code primitive (e.g. status fields).
ID → boolean — used for Y/N flags backed by HL70136.
ID → string — used when the FHIR target is plain text and no concept mapping exists.

The containing element's FHIR type — not the ID itself — determines which ConceptMap applies.

Engine considerations

Validate every ID against its referenced HL7 table at ingress; ID has no "other" escape value, so unknown codes are conformance errors, not warnings.
Uppercase normalize before comparison unless the profile explicitly requires case-sensitive matching.
Many HL7 tables (e.g. HL70001 Administrative Sex) have been extended in v2.7+; engines pinned to a v2.3 table set will reject newer codes like A (Ambiguous) or N (Not applicable).
Y/N ID fields (HL70136) are excellent boolean candidates in downstream models, but treat empty / unknown distinctly from N.
Do not coerce an ID into a CWE on egress to "enrich" it — receivers expecting an ID will reject a triplet.

How Vorro parses and produces ID

Vorro's parser validates each ID-typed field against the table referenced by the field's profile and surfaces unmapped values as conformance errors rather than passing them through. We uppercase-normalize on ingress to absorb common case drift, but the original lexical form is retained for audit replay. Y/N HL70136 fields are exposed both as raw Y / N tokens and as typed booleans so downstream consumers can pick the representation that suits them.

On outbound, Vorro emits ID fields as bare uppercase codes with no display text, no caret, and no embedded code system. Where the source model carries richer metadata, we drop it deliberately at the wire boundary — emitting a triplet into an ID slot would break receivers that parse strictly.

Sources

← Back to HL7 v2 Guide