HL70296 is a user-defined HL7 v2 code table — meaning HL7 reserved the table number and the field that carries it, but the value set itself defers to an external standard: ISO 639. It carries the patient's primary language in PID-15 Primary Language on every patient demographic message. Because the value set is ISO 639, there is no fixed "code list" to enumerate; receivers must accept any valid ISO 639 code.
Purpose
HL70296 records the language the patient prefers to use for communication with the health care system. It drives interpreter requests, translated patient education material, translated discharge instructions, and language-tagged outbound notifications. It is not a statement about the patient's fluency, literacy, or proficiency — those belong to richer profiles (PID-15 is a single language code; profiles that need proficiency level use additional fields or extensions).
Because the table is user-defined and defers to ISO 639, the question is not "what codes are valid" (any ISO 639 code is valid) but "which ISO 639 variant does the site use." Most US healthcare uses ISO 639-1 two-letter codes (en, es, fr, zh), modern profiles increasingly use BCP-47 tags (en-US, zh-Hant), and some legacy interfaces still use ISO 639-2 three-letter codes (eng, spa, fre).
Where it's used
- PID-15 Primary Language — the canonical home of HL70296, populated on ADT, ORM, ORU, and SIU messages that carry a patient.
- LAN-2 Language Code on the LAN (Language Detail) segment, when a person has multiple languages with proficiency levels.
- Some profiles echo PID-15 into outbound notification segments to trigger language-tagged routing.
Code list
HL70296 does not enumerate codes; the value set is ISO 639. The codes below are the most common values seen on US healthcare interfaces, but any valid ISO 639 code is acceptable:
| Code | Display | Comment |
|---|---|---|
| en | English | ISO 639-1 |
| es | Spanish | ISO 639-1 |
| fr | French | |
| de | German | |
| zh | Chinese | |
| ja | Japanese | |
| ko | Korean | |
| ar | Arabic | |
| ru | Russian | |
| hi | Hindi | |
| pt | Portuguese | |
| vi | Vietnamese | |
| (many more) | Full set = ISO 639-1/639-2/639-3 |
For a complete and authoritative list of language codes, consult the ISO 639 registry at the Library of Congress.
Code system OID
- OID:
2.16.840.1.113883.18.211 - Canonical URI:
http://terminology.hl7.org/CodeSystem/v2-0296
The OID is registered on the HL7 Terminology server but resolves to a deferral notice rather than an enumeration. When sites send ISO 639-1 codes they typically populate CWE.14 with the ISO 639-1 OID (2.16.840.1.113883.6.99); ISO 639-2 has its own OID (2.16.840.1.113883.6.100).
HL7-defined vs user-defined
HL70296 is user-defined, meaning the table number is HL7-reserved but the content is the site's responsibility. In practice, almost every site chooses ISO 639 as its value set, but the ISO 639 variant (-1 vs -2 vs -3) and the optional BCP-47 region suffix (en-US vs en) are site choices. Receivers must publish their value set choice in their interface specification; senders that guess wrong will see their language tags either rejected or mis-routed.
Version differences
- v2.3 – v2.4 — PID-15 added; HL70296 reserved as a user-defined slot pointing at ISO 639.
- v2.5 — PID-15 elevated to
CE(Coded Element), permitting explicit code system identification in CE.3. - v2.6 – v2.8.1 — PID-15 elevated to
CWE(Coded with Exceptions), allowing OID metadata in CWE.14 and alternate codes in CWE.4–6. - v2.9 — HL70296 unchanged; PID-15 may now carry BCP-47 tags in the primary identifier slot.
Common mistakes
- Sending the display word in PID-15 —
Englishinstead ofen. PID-15 isCEorCWE; the code value belongs in component 1, and the display name in component 2. - Mixing ISO 639-1 and ISO 639-2 in the same feed without identifying the code system.
enandengboth mean English, but downstream systems cannot tell which variant they are reading without CWE.3. - Using locale strings like
en_US(underscore) instead of BCP-47en-US(hyphen). Receivers that strictly parse BCP-47 will reject the underscore form. - Defaulting unknown language to
enbecause the EHR demands a non-null value. Leaving PID-15 empty is allowed; usingund(undetermined, ISO 639-2) is also acceptable and is preferable to defaulting English on a non-English-speaking patient. - Treating PID-15 as a proficiency field. PID-15 says "primary language is Spanish"; it does not say "needs interpreter." Use LAN-3 Language Ability or a flag elsewhere in the profile to capture interpreter need.
Examples
A PID with primary language Spanish, ISO 639-1:
PID|1||10456^^^MRN^MR||GARCIA^MARIA^A||19850412|F|||123 MAIN ST^^BOSTON^MA^02118|||||S||10456|||||||es^Spanish^ISO639-1
Same patient with ISO 639-2 codes (some legacy interfaces):
PID|1||10456^^^MRN^MR||GARCIA^MARIA||19850412|F|||123 MAIN ST||||S||10456|||||||spa^Spanish^ISO639-2
A BCP-47 tag for a Traditional Chinese speaker:
PID|1||10456^^^MRN^MR||WONG^LI||19850412|F|||123 MAIN ST||||S||10456|||||||zh-Hant^Chinese (Traditional)^urn:ietf:bcp:47
Same es value translated to a FHIR Patient.communication snippet:
{
"resourceType": "Patient",
"id": "10456",
"communication": [{
"language": {
"coding": [{
"system": "urn:ietf:bcp:47",
"code": "es",
"display": "Spanish"
}]
},
"preferred": true
}]
}
Mapping failure example — invalid language code:
PID|1||10456^^^MRN^MR||GARCIA^MARIA||19850412|F|||123 MAIN ST||||S||10456|||||||SPANISH
SPANISH is the display string, not an ISO 639 code. A conformant engine should route the message to a curation queue, preserve the original SPANISH in the audit log, and either remap to es (and create a remap rule) or pass through with a soft warning so downstream systems can decide.
FHIR mapping
Patient.communication.language is a CodeableConcept bound to the BCP-47 language tag system (urn:ietf:bcp:47). Because BCP-47 is itself built on ISO 639, the v2-to-FHIR mapping is a pass-through: the v2 code goes into Coding.code and the system URI changes from urn:ietf:rfc:3066 (legacy v2) or one of the ISO 639 OIDs to urn:ietf:bcp:47.
| HL7 v2 (PID-15 code) | FHIR (Patient.communication.language) |
|---|---|
en | Coding{system=urn:ietf:bcp:47, code=en} |
es | Coding{system=urn:ietf:bcp:47, code=es} |
zh-Hant | Coding{system=urn:ietf:bcp:47, code=zh-Hant} |
eng (ISO 639-2) | downcast to Coding{system=urn:ietf:bcp:47, code=en} |
No HL7 v2-to-FHIR IG ConceptMap is required when both sides use ISO 639 codes; an ISO 639-2 to ISO 639-1 downcast table is needed when the source uses three-letter codes and the receiver expects BCP-47.
Engine considerations
- ISO 639 variant detection — Engines should inspect the length and shape of the code (
2chars = 639-1,3chars = 639-2/639-3, contains-= BCP-47) and normalize to a configured target variant on egress. - Case sensitivity — ISO 639 codes are lowercase by convention; BCP-47 region suffixes are uppercase (
en-US, noten-us). Engines should normalize on ingest. - Display name resolution — PID-15 component 2 (display name) is informational; engines should not trust it for routing and should resolve display from a canonical ISO 639 lookup table on the way out.
undhandling — ISO 639-2 reservesundfor "undetermined." Engines should acceptundand map it to FHIRunknowndata-absent-reason rather than failing validation.- Round-trip preservation — When the source variant differs from the destination variant (e.g., source is 639-2, destination expects 639-1), preserve the original code as a second
codingelement so the v2 outbound channel can restore it.
How Vorro handles HL70296
Vorro validates PID-15 against the ISO 639 registries (639-1, 639-2, 639-3) and against BCP-47 syntax rules on ingest. Values that match are normalized to the destination's configured variant (most commonly BCP-47 for FHIR destinations and ISO 639-1 for v2 destinations) and forwarded. Values that fail validation — including display strings, locale-style en_US underscores, and vendor extensions — are routed to the terminology curation queue, where they either resolve to a valid ISO 639 code (and a remap rule is created) or pass through with a soft warning so downstream systems are not silently fed bad data.
On outbound, Vorro emits PID-15 as CE for v2.5 profiles and as CWE with CWE.14 populated (using the appropriate ISO 639 OID) for v2.6+ destinations. When mapping to FHIR Patient.communication.language, Vorro always emits a BCP-47 tag and preserves the original variant as a second coding entry so the value round-trips losslessly.
Related pages
- PID segment — Patient Identification
- HL70171 code table — Citizenship
- CWE data type — Coded with Exceptions
