HL7 Table HL70125: Value Type

HL70125 is the OBX segment's parser discriminator. It tells the receiver what shape OBX-5 has — a number, a string, a coded concept, a date, an encapsulated PDF — so the receiver can run the right parser against the rest of the segment. It lives in OBX-2 Value Type and is the most consequential single field in the entire OBX universe, because OBX-5 is typed as Varies and HL70125 is the discriminator that decides which variant Varies is.

Purpose

OBX-5 has no fixed data type. A lab result row for hemoglobin carries a number; a microbiology susceptibility row carries a coded concept; a radiology impression carries narrative text; an EKG strip carries encapsulated binary. All four ride in OBX-5, and the only thing telling the parser which shape to expect is OBX-2.

The choice of HL70125 value has cascading effects on the receiver:

• It selects the parsing rule for OBX-5 (numeric, coded, text, binary).
• It selects the FHIR Observation.value[x] slot the result maps to.
• It determines whether OBX-6 Units is meaningful (NM and SN use units; ST, TX, CWE don't).
• It determines whether OBX-7 References Range is interpretable (only for numeric and coded).

A mismatch between OBX-2 and OBX-5 is one of the most common interface failures in v2 — see Common Mistakes below.

Where it's used

• OBX-2 Value Type — the canonical and effectively only home of HL70125.
• MFE-4 Value Type (some master-file profiles) where a master-file entry needs to declare the expected value type of an attribute.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.46
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0125

The OID resolves on the HL7 Terminology server.

HL7-defined vs user-defined

HL70125 is HL7-defined. Receivers must recognize every code in the table because the code drives parsing of the rest of the segment — there is no notion of "local extension" here. A sender that invents a new value type breaks the receiver's parser, not just its terminology mapping.

Version differences

• v2.1 – v2.2 — Initial set: NM, ST, TX, DT, TM, TS, CE, CK, CN, AD, PN, TN, ID, IS, FT, NA, ED, RP, CP, MO, SN.
• v2.3.1 — CF (Coded Element with Formatted Values) added.
• v2.5 — CWE and CNE introduced as the modern coded shapes; CX, XAD, XCN, XON, XPN, XTN added as the extended-composite replacements for the legacy CE/CK/CN/AD/PN/TN family.
• v2.5.1 — DTM added as the modern timestamp; TS continues to be accepted for backward compatibility.
• v2.6 – v2.8.1 — Set stable. Legacy codes (CE, CK, CN, AD, PN, TN, TS) remain present for backward compatibility but new implementations should use the modern equivalents.

Common mistakes

• Declaring OBX-2 = NM but populating OBX-5 with <10 or >=100. The correct value type for a comparator-bearing result is SN (Structured Numeric), not NM. A receiver that parses <10 as NM either errors or silently drops the comparator.
• Declaring OBX-2 = ST for a coded result. Coded concepts must be carried as CWE (v2.5+) or CE (legacy) so the receiver knows to parse the caret-separated components.
• Using TS in new v2.7+ implementations. TS is the legacy timestamp; the modern code is DTM. Many engines accept both, but FHIR mapping is cleaner from DTM.
• Sending an EKG strip or PDF as ST instead of ED. The encapsulated-data type carries the encoding (Base64), the MIME type, and either the inline payload or a reference; a receiver that sees ST will neither decode nor route the binary.
• Treating HL70125 as user-extensible. New codes cannot be invented locally because they have no associated parser.

Examples

A numeric lab result — hemoglobin in g/dL:

OBX|1|NM|718-7^HEMOGLOBIN^LN||14.2|g/dL|13.5-17.5|N|||F

A structured-numeric result with a comparator:

OBX|2|SN|6690-2^WBC^LN||>^25|10*3/uL|4.0-11.0|H|||F

A coded microbiology result:

OBX|3|CWE|634-6^BACTERIA^LN||87171005^Escherichia coli^SCT|||A|||F

An encapsulated PDF report:

OBX|4|ED|11506-3^PROGRESS NOTE^LN||^application^PDF^Base64^JVBERi0xLjQK...||||||F

FHIR mapping is driven by OBX-2. The four examples above produce, respectively, Observation.valueQuantity, Observation.valueQuantity with a comparator, Observation.valueCodeableConcept, and Observation.valueAttachment:

{
  "resourceType": "Observation",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "718-7" }] },
  "valueQuantity": { "value": 14.2, "unit": "g/dL", "system": "http://unitsofmeasure.org", "code": "g/dL" }
}

{
  "valueQuantity": { "comparator": ">", "value": 25, "unit": "10*3/uL" }
}

Mapping failure example — value type and payload disagree:

OBX|5|NM|634-6^BACTERIA^LN||E. coli|||A|||F

NM declares numeric but E. coli is text. A conformant engine should reject the row or route to a curation queue rather than coerce.

FHIR mapping

HL70125 has no direct FHIR ValueSet because it is not a clinical concept — it is a discriminator that selects which FHIR Observation.value[x] slot the receiver populates. The v2-to-FHIR IG documents the per-value-type routing rules:

The receiver consults OBX-2 first, then dispatches to the matching parser and FHIR builder.

Engine considerations

• Parser dispatch — Engines must dispatch on OBX-2 before reading OBX-5. The classic bug is reading OBX-5 generically (as a string) and then post-hoc deciding the type from regex inspection; that loses precision for SN and CWE.
• Case sensitivity — HL70125 codes are uppercase; nm is not valid. Normalize on ingest.
• Legacy compatibility — Accept TS on ingest and translate to DTM semantics on outbound to v2.5.1+ destinations.
• OBX-6 dependency — Units (OBX-6) are meaningful only for NM, SN, and MO. Engines should drop OBX-6 silently when emitting a ST or CWE row to FHIR.
• OBX-2 mismatch detection — Validate that OBX-5 actually parses under the declared OBX-2; route mismatches to the curation queue rather than coercing.

How Vorro handles HL70125

Vorro dispatches OBX parsing on OBX-2 before touching OBX-5 — every value type has a dedicated parser and FHIR builder. Rows where the declared type and the payload disagree (numeric type but non-numeric payload, coded type but no caret separators) are routed to the terminology curation queue with the original payload preserved in the audit log. Vorro accepts the legacy TS and CE codes on ingest and normalizes to DTM and CWE on outbound for v2.7+ destinations.

On the FHIR side, Vorro selects the correct Observation.value[x] slot from OBX-2 and never falls back to valueString as a catch-all — silent string-fallback is one of the most common sources of downstream data quality issues, and Vorro's policy is to surface the mismatch rather than hide it.

Related pages

• OBX segment — Observation Result
• Varies data type — Polymorphic OBX-5 payload
• HL70078 code table — Abnormal Flags

Sources

• Caristix — Table 0125 (HL7 v2.8.1) Value Type
• HL7 v2 product brief