The OBX segment, short for Observation/Result, carries the actual clinical values in HL7 v2 messages: lab results, vital signs, imaging findings, questionnaire answers and more. If OBX is mapped incorrectly, clinicians see wrong units, missing values or results filed against the wrong test. This reference explains every OBX field, the value types and result status codes you will encounter, and the implementation details that make results file reliably. For the wider picture of message types, see our HL7 message types and event types guide. Struggling with result mapping? Request a free HL7 interface review.
What the OBX Segment Does
OBX is the workhorse of clinical data exchange in HL7 v2. Each OBX carries one observation, so a single result message may contain dozens. Understanding how OBX relates to surrounding segments is the foundation for building reliable result interfaces.
One observation per segment
Each OBX holds a single observation, such as a glucose value or a blood pressure reading. A panel like a complete blood count produces many OBX segments, one per component. Receivers process each separately, then group them under the related order.
Relationship to OBR
OBX segments usually follow an OBR segment, which describes the ordered test or panel. OBR provides the order context, while OBX carries individual values. Correct grouping matters, because results attached to the wrong OBR appear under the wrong test in the chart.
Messages that use OBX
OBX appears in many message types, including ORU result messages, ADT messages carrying vital signs or other observations, and MDM document messages. The same segment structure works across these contexts, though implementation guides often restrict which fields and value types are allowed.
Notes and comments
Comments about a result usually travel in NTE segments following the related OBX. These may contain interpretive notes, specimen comments or lab disclaimers. Receivers should display them alongside results, because clinicians often rely on these notes when interpreting values. Never discard NTE content.
OBX Field Reference (HL7 v2.5.1)
The table below lists OBX fields as defined in HL7 v2.5.1. Optionality uses standard codes: R for required, O for optional and C for conditional. Several fields were added in v2.5.1 to support lab reporting, and partners may require them for regulatory or public health interfaces.
| Seq | Field name | Data type | Opt | Notes |
| OBX-1 | Set ID – OBX | SI | O | Sequence number within the message |
| OBX-2 | Value Type | ID | C | Data type of OBX-5, e.g. NM, ST, CWE |
| OBX-3 | Observation Identifier | CE | R | What was observed, often a LOINC code |
| OBX-4 | Observation Sub-ID | ST | C | Groups related OBX segments |
| OBX-5 | Observation Value | Varies | C | The result value itself |
| OBX-6 | Units | CE | O | Units of measure, often UCUM |
| OBX-7 | References Range | ST | O | Normal range for the result |
| OBX-8 | Abnormal Flags | IS | O | e.g. H, L, HH, LL, A, N |
| OBX-9 | Probability | NM | O | Probability for the observation |
| OBX-10 | Nature of Abnormal Test | ID | O | Basis for normal range |
| OBX-11 | Observation Result Status | ID | R | e.g. F final, P preliminary, C corrected |
| OBX-12 | Effective Date of Reference Range | TS | O | When the range took effect |
| OBX-13 | User Defined Access Checks | ST | O | Access restrictions |
| OBX-14 | Date/Time of the Observation | TS | O | Clinically relevant time |
| OBX-15 | Producer’s ID | CE | O | Organization producing the result |
| OBX-16 | Responsible Observer | XCN | O | Person responsible for the result |
| OBX-17 | Observation Method | CE | O | Method used |
| OBX-18 | Equipment Instance Identifier | EI | O | Instrument that produced the result |
| OBX-19 | Date/Time of the Analysis | TS | O | When the analysis was performed |
| OBX-20 to 22 | Reserved | Reserved for harmonization with later versions | ||
| OBX-23 | Performing Organization Name | XON | O | Lab that performed the test |
| OBX-24 | Performing Organization Address | XAD | O | Address of the performing lab |
| OBX-25 | Performing Organization Medical Director | XCN | O | Director of the performing lab |
Value Types and Result Status Codes
Two fields decide how receivers interpret every OBX: OBX-2 Value Type and OBX-11 Observation Result Status. Misreading either produces display errors or incorrect clinical status. Knowing the common values helps teams build parsers and mappings that handle real-world results correctly.
Common value types in OBX-2
NM carries numeric values, ST short text, TX longer text and FT formatted text. CE or CWE carry coded values, SN structured numerics such as ranges or ratios, and ED encapsulated data such as PDFs. OBX-5 must match the declared type exactly.
Structured numerics and comparators
SN values handle results like greater than 100 or ratios such as 1:64. They include separate components for comparator and numbers. Receivers that treat SN as plain text lose this structure, which can break trending, alerts and clinical decision support.
Result status in OBX-11
F means final, P preliminary and C a correction to a previously final result. Other codes include X for results that cannot be obtained, D for deletions and I for pending. Receivers must update stored results correctly when corrections or deletions arrive.
Abnormal flags in OBX-8
Abnormal flags highlight results outside reference ranges, such as H for high, L for low, HH and LL for critical values, and A for abnormal. Display them clearly, because clinicians rely on flags to spot urgent results quickly in busy workflows.
Example OBX Segment
The sample below shows a numeric glucose result with LOINC coding, units, reference range, normal flag, final status and observation time. Values are fictional and shown in standard pipe-delimited format so teams can validate parsing and field positions.
OBX|1|NM|2345-7^Glucose in Serum or Plasma^LN||95|mg/dL^mg/dL^UCUM|70-99|N|||F|||20261016091500
Reading the example
OBX-1 is the set ID, OBX-2 declares a numeric value and OBX-3 identifies the test with LOINC code 2345-7. OBX-5 holds the value 95, OBX-6 the units and OBX-7 the reference range of 70 to 99. Each value sits in its expected position.
Flags, status and timing
OBX-8 shows N for normal. OBX-9 and OBX-10 are empty. OBX-11 is F, meaning final. OBX-14 records when the observation was made, which receivers should use for clinical timelines rather than the time the message arrived. Accurate timing supports correct trending.
Why LOINC matters here
Using LOINC in OBX-3 gives the result a standard identity across systems, supporting analytics, public health reporting and FHIR conversion. Learn more in our LOINC glossary entry. Local codes alone make results harder to share and compare. Map local codes to LOINC early.
Implementation Tips and Common Errors
Most OBX issues come from mismatched value types, unit problems, mishandled corrections and inconsistent coding. These tips reflect problems we see repeatedly when building and troubleshooting result interfaces for hospitals, reference labs and digital health platforms.
Match OBX-5 to OBX-2
Validate that every OBX-5 value matches its declared type. Text in a numeric field or numbers declared as coded values break parsing and trending. Reject or flag mismatches at the interface engine before they reach clinical systems. Log every rejection for follow-up.
Standardize units carefully
Different labs report the same test in different units. Map units consistently, preferably to UCUM, and decide how to display them. Unit mismatches can cause dangerous misinterpretation, so include unit checks in automated interface testing. Review unit mappings with laboratory experts.
Handle corrections and deletions
When OBX-11 arrives as C or D, receivers must update or remove the earlier result, not store a duplicate. Test correction workflows explicitly with partners, because many interfaces work for new results but mishandle updates. Notify clinicians when corrected results change values.
Preserve sub-IDs and grouping
OBX-4 sub-IDs group related observations, such as microbiology organisms and their sensitivities. Losing this grouping scrambles complex results. Preserve sub-IDs through transformations, and verify grouped results display correctly in receiving systems. Microbiology results are the most common place where grouping errors appear, so test them thoroughly.
How Taction Helps With HL7 Result Interfaces
Taction has delivered 200+ healthcare projects, including lab, imaging and device result interfaces. We help organizations map OBX accurately, handle corrections and coding correctly, and keep results flowing reliably into EHRs and clinical applications.
Free HL7 interface review
Share sample result messages and partner specifications. We review OBX value types, units, coding and status handling, then flag mapping risks and fixes. You get clear recommendations. Request your free review. We also flag quick fixes you can apply immediately to reduce filing errors.
Result interface development
We build ORU and related interfaces through engines such as Mirth Connect, with validation, unit mapping and monitoring. Our lab integration HL7 services cover reference labs, LIS connections and outreach programs. Every interface includes alerting, so unfiled or rejected results are caught before clinicians notice.
HL7 to FHIR conversion
Many organizations convert OBX results to FHIR Observation resources for apps and analytics. Our HL7 v2 to FHIR mapping reference explains how these conversions preserve values, units and status accurately. We build these conversion pipelines with automated tests that confirm every value survives the transformation intact.
HL7 engineers on demand
Need experienced interface engineers? Hire HL7 integration engineers who understand result workflows, coding and engine development. They join your team quickly and document every interface for long-term support. Engagements scale with your roadmap, from a single result interface to support across many labs, devices and clinical systems.
Frequently Asked Questions
These answers cover common questions about the HL7 OBX segment. Because implementation guides and partners often add rules beyond the base standard, always confirm requirements with the specifications for your specific interface.
What does OBX stand for in HL7?
OBX stands for Observation/Result. Each OBX segment carries one observation, such as a lab value, vital sign or questionnaire answer. OBX segments usually follow an OBR segment describing the ordered test, and appear in ORU and other message types. Each one holds one value.
Which OBX fields are required?
In HL7 v2.5.1, OBX-3 Observation Identifier and OBX-11 Observation Result Status are required. OBX-2 Value Type and OBX-5 Observation Value are conditional. Partners and implementation guides frequently require more, so check each specification. Validate those rules before go-live with every partner.
What does OBX-11 status F mean?
F means final. The result is complete and verified. Other common values include P for preliminary, C for a corrected result and X when results cannot be obtained. Receivers must handle corrections without creating duplicate results. Test correction handling carefully.
What value types can OBX-5 contain?
OBX-5 can contain many types, declared in OBX-2, including NM for numbers, ST and TX for text, FT for formatted text, CWE or CE for coded values, SN for structured numerics and ED for encapsulated documents. Validate every value against its type.
How should units be sent in OBX-6?
Send units as coded values, ideally using UCUM, in OBX-6. Consistent, standard units prevent misinterpretation and support analytics. Agree on unit conventions with every partner and validate units during interface testing before go-live. Review mappings with laboratory experts regularly. Consistency matters.