Reference·HL7 v2·OBR
HL7 v2 Reference

HL7 v2 OBR Segment Guide: Fields, Format, and Testing Gotchas

Jul 27, 2026 · 6 min read

Get the OBR-2/OBR-3 order number pairing wrong and your lab results silently stop matching back to the original order, leaving clinicians staring at an orphaned result with no context.

Quick answer

OBR is the HL7 v2 segment that carries the details of a single observation or diagnostic order, such as the test being requested, who ordered it, when it was collected, and who is responsible for the result.

The fields that actually matter in practice

OBR-1 →
Set ID — numbers each OBR when a message carries more than one order; skip this and downstream systems can misassociate results across multiple test panels in the same message
OBR-2 →
Placer Order Number — the ordering system's identifier for the request — mismatched or dropped placer numbers are the single most common reason results fail to reconcile with the original order
OBR-3 →
Filler Order Number — the performing lab or department's own identifier
OBR-4 →
Universal Service ID — identifies what was actually ordered, usually a coded test name — coding-system mismatches here are a frequent source of silent mapping failures
OBR-7 →
Observation Date/Time — when the specimen or observation was taken
OBR-16 →
Ordering Provider — identifies who requested the test
OBR-24 →
Diagnostic Serv Sect ID — a short code for the performing service area, like the lab section — downstream routing logic often keys off this value
OBR-25 →
Result Status — signals whether the order is pending, preliminary, or final

Example

Synthetic example Generated by Synthibase
OBR|1|ORD44219^SYNTHIB|FIL98831^SYNTHIB|CBC^Complete Blood Count^L|||20260726090000|||||||||3021^HAYES^DEREK^A^^^MD||||||||CH|F||||||R/O anemia

A synthetic OBR segment for a complete blood count order, showing the placer/filler order number pairing, ordering provider, and a final result status.

Where this trips people up

A shockingly common integration bug is treating OBR-2 (placer order number) and OBR-3 (filler order number) as interchangeable or optional. When a lab system generates its own filler number but the interface layer forgets to echo the original placer number back on the result message, the ordering EHR has no reliable way to match the incoming result to the pending order it created. The result either gets dropped, queued as unmatched, or gets manually reconciled by staff against the wrong patient encounter. Any test suite for OBR handling should explicitly verify that both identifiers survive the full order-to-result round trip unchanged.

HL7 ADT Messages: A01 through A08 Explained
Healthcare API Testing Guide: FHIR and X12
Test OBR handling without waiting on a live lab feed
Synthibase generates realistic, synthetic HL7 v2 order and result messages on demand so your team can validate OBR field mapping, order matching, and status transitions before anything touches production data.
Start free trial →
This page is written independently by Synthibase for testing and informational purposes. It is not an official publication of HL7 International or X12/Washington Publishing Company, and is not a substitute for reviewing the official standard or your trading partner's companion guide. See our Terms of Service for full legal terms.