HL7 OBR Segment (Observation Request): Field-by-Field Specification, ORC/OBR/OBX Hierarchy, and PV1, DG1, MSH & NK1 Message Context

In the HL7 Version 2 (HL7 v2.x) clinical messaging standard, the OBR (Observation Request) segment serves as the structural bridge between a clinical order and its resulting diagnostic observations. Across laboratory orders (ORM^O01, OML^O21) and unstructured or structured diagnostic result feeds (ORU^R01), the OBR segment functions as the order detail and report header: it identifies the specific diagnostic battery or procedure ordered (such as a Complete Blood Count with Differential or a Chest CT), links the ordering system’s Placer Order Number (OBR-2) with the laboratory’s Filler Order Number (OBR-3), captures specimen collection timestamps (OBR-7), and groups all atomic test results transmitted in the child OBX (Observation/Result) segments that immediately follow it.

HL7 OBR Segment Field-by-Field Specification (OBR-1 to OBR-32)

When configuring an integration engine or HL7 v2 parser, interface engineers map the following core positions of the OBR segment (defined in HL7 v2.5.1 / v2.7 Chapter 4 and Chapter 7) to EHR clinical data repositories and HL7 FHIR R4 ServiceRequest and DiagnosticReport resources:

Seq	Field Name	HL7 Data Type	Opt / Rep	Clinical Usage & FHIR R4 Mapping
OBR-1	Set ID — OBR	SI	R (1)	1-based sequence counter (`1`, `2`, `3`…) identifying each distinct order/battery header within a multi-order message.
OBR-2	Placer Order Number	EI	C (1)	Unique order identifier assigned by the ordering application (CPOE / EHR). Must match ORC-2. Maps to ServiceRequest.identifier (PLAC).
OBR-3	Filler Order Number	EI	C (1)	Unique accession or order ID assigned by the fulfilling system (LIS / RIS). Must match ORC-3. Maps to DiagnosticReport.identifier (FILL).
OBR-4	Universal Service Identifier	CWE (CE)	R (1)	Coded identifier for the ordered panel or study (typically a LOINC panel code or CPT code plus local test mnemonic). Maps to ServiceRequest.code and DiagnosticReport.code.
OBR-7	Observation Date/Time	DTM (TS)	C (1)	Physiologically relevant timestamp of the observation—for laboratory specimens, the exact specimen collection start time. Maps to DiagnosticReport.effectiveDateTime.
OBR-8	Observation End Date/Time	DTM (TS)	O (1)	End timestamp for timed specimen collections (e.g., 24-hour urine collection or Holter monitor window). Maps to DiagnosticReport.effectivePeriod.end.
OBR-11	Specimen Action Code	ID (Table 0065)	O (1)	Instructions on how the specimen is handled: A (Add ordered tests to existing specimen), G (Generated reflex order), L (Lab to obtain specimen), O (Specimen obtained by service other than lab).
OBR-13	Relevant Clinical Information	ST	O (1)	Free-text clinical context provided to the pathologist or radiologist (e.g., “Rule out pulmonary embolism; patient on warfarin”).
OBR-15	Specimen Source	SPS	O (1)	Legacy specimen source/site field in HL7 v2.3/v2.4 (superseded in v2.5.1+ by the dedicated SPM [Specimen] segment, though still widely populated by legacy LIS feeds).
OBR-16	Ordering Provider	XCN	O (*)	NPI, ID, family name, and given name of the clinician who ordered the study (mirrors ORC-12). Maps to ServiceRequest.requester.
OBR-22	Results Rpt/Status Chng — Date/Time	DTM (TS)	C (1)	Timestamp when the diagnostic report was released, verified, or amended by the lab/radiology system. Maps to DiagnosticReport.issued.
OBR-24	Diagnostic Serv Sect ID	ID (Table 0074)	O (1)	Performing department classification: LAB (Laboratory), HEM (Hematology), CH (Chemistry), MB (Microbiology), RAD (Radiology), CT (CAT Scan). Maps to DiagnosticReport.category.
OBR-25	Result Status	ID (Table 0123)	C (1)	Lifecycle status of the report: O (Order received, specimen not yet received), I (Specimen in lab, results pending), P (Preliminary), F (Final), C (Corrected/Amended—supersedes prior final report), X (Cancelled). Maps to DiagnosticReport.status.
OBR-26 & OBR-29	Parent Result (PRL) & Parent (EIP)	PRL / EIP	O (1)	Links a child reflex or susceptibility order (e.g., antibiotic minimum inhibitory concentration [MIC] panel) back to the specific parent OBR and OBX isolate that triggered it.
OBR-28	Result Copies To	XCN	O (*)	Secondary providers (e.g., primary care physician or referring specialist) who should receive a courtesy copy (CC) of the result.
OBR-31	Reason for Study	CWE (CE)	O (*)	Coded clinical indication or diagnosis justifying the study. Maps to ServiceRequest.reasonCode.
OBR-32	Principal Result Interpreter	NDL	O (1)	Identifies the signing pathologist, radiologist, or cardiologist responsible for interpreting the study. Maps to DiagnosticReport.resultsInterpreter.

How Do HL7 ORC, OBR, and OBX Segments Work Together in Lab Messages?

In both order messages (ORM^O01, OML^O21) and result messages (ORU^R01), ORC, OBR, and OBX form a strict three-tier parent–child hierarchy within each ORDER_OBSERVATION repeating group:

1. ORC (Common Order Segment — Administrative Order Control): Sits immediately above OBR and governs order action semantics applicable to any department (laboratory, radiology, cardiology, dietary). ORC-1 carries the two-character Order Control Code (HL7 Table 0119), such as NW (New order), CA (Cancel order request), SC (Status changed), or RE (Observations/performed service to follow). Crucially, ORC-2 (Placer Order Number), ORC-3 (Filler Order Number), and ORC-12 (Ordering Provider) must stay synchronized with OBR-2, OBR-3, and OBR-16.
2. OBR (Observation Request Segment — Panel / Battery Header): Defines the specific diagnostic battery ordered (`OBR-4`, e.g., LOINC 24323-8 Comprehensive metabolic 2000 panel), the physiological specimen collection timestamp (`OBR-7`), and the overall battery status (`OBR-25 = F`).
3. OBX (Observation/Result Segment — Atomic Analytes): One OBR header is followed by one or more repeating OBX segments (`1..*`), each carrying a single analyte measurement or narrative line. In each OBX:
   • OBX-1 is the 1-based sequence number under the current OBR;
   • OBX-2 defines the data type (NM for numeric values like Potassium 4.2, SN for structured numeric with comparators like <0.5, CWE for coded microbiology organisms, ST/TX/FT for text, or ED for Base64-encoded PDFs);
   • OBX-3 carries the atomic analyte code (e.g., LOINC 2823-3 Potassium [Moles/volume] in Serum or Plasma);
   • OBX-4 (Observation Sub-ID) disambiguates multiple results sharing the same OBX-3 code under one OBR (such as multi-isolate microbiology cultures); and
   • OBX-5 through OBX-11 store the value, UCUM units (`OBX-6`), reference range (`OBX-7`), abnormal flag (`OBX-8`: `L`, `H`, `LL`, `HH`, `A`), and individual result status (`OBX-11`).

Companion Context Segments: MSH, PV1, DG1, and NK1 Explained

Because an OBR/OBX group only describes the diagnostic test itself, HL7 v2 messages rely on four companion segments to establish message routing, encounter location, medical necessity diagnoses, and emergency contact context:

1. What Envelope Metadata Is Captured in the HL7 MSH Segment?

Every HL7 v2 message begins with the MSH (Message Header) segment, which defines the encoding characters (`MSH-1` = |, `MSH-2` = ^~&), Sending and Receiving Applications/Facilities (`MSH-3` through `MSH-6`), Message Timestamp (`MSH-7`), Message Type and Trigger Event (`MSH-9`, such as ORM^O01 or ORU^R01^ORU_R01), unique Message Control ID (`MSH-10`, echoed back in MSA-2 for MLLP acknowledgment), Processing ID (`MSH-11`: P Production, T Training/Test, D Debugging), and HL7 Version ID (`MSH-12`, e.g., 2.5.1).

2. What Visit Data Is Captured in the HL7 PV1 Segment?

Positioned inside the PATIENT_RESULT group after PID, the PV1 (Patient Visit) segment links the laboratory or radiology order to the clinical encounter (and maps to the FHIR Encounter resource): PV1-2 records Patient Class (`I` Inpatient, `O` Outpatient, `E` Emergency); PV1-3 records the Assigned Patient Location (`PointOfCare^Room^Bed^Facility`) so critical lab values can be routed to the correct nursing station; PV1-7, PV1-8, and PV1-17 identify the Attending, Referring, and Admitting Physicians; PV1-19 holds the Visit/Encounter Number; and PV1-44/PV1-45 record Admit and Discharge timestamps.

3. How Are ICD-10 Diagnosis Codes Structured in the HL7 DG1 Segment?

In outpatient laboratory and diagnostic imaging orders (ORM^O01 / OML^O21), Medicare and commercial payers require medical necessity justification linking the ordered CPT/LOINC panel (`OBR-4`) to one or more diagnosis codes. The DG1 (Diagnosis) segment captures this clinical justification:

• DG1-1 (Set ID — DG1): Sequence number (`1`, `2`, `3`…) ranking diagnoses by priority.
• DG1-2 (Diagnosis Coding Method): Legacy coding system indicator (retained for backward compatibility in v2.3; superseded by the third component of DG1-3 in v2.5.1+).
• DG1-3 (Diagnosis Code — DG1, data type CWE): Carries the diagnosis code, description, and coding system OID/mnemonic—for example, E11.65^Type 2 diabetes mellitus with hyperglycemia^I10 (where I10 designates ICD-10-CM under HL7 Table 0051 / 0396).
• DG1-6 (Diagnosis Type, Table 0052): Classifies the diagnosis as A (Admitting), W (Working), or F (Final).

4. Role of the HL7 NK1 (Next of Kin / Associated Parties) Segment

The NK1 segment follows PID (and PD1) to transmit next-of-kin, legal guardian, healthcare proxy, or emergency contact details (`NK1-2` Name, `NK1-3` Relationship such as SPO [Spouse] or MTH [Mother], `NK1-4` Address, `NK1-5` Phone Number, and `NK1-7` Contact Role). In pediatric, geriatric, and public health infectious-disease reporting (`ORU^R01` Electronic Laboratory Reporting [ELR]), NK1 ensures public health departments and clinicians can reach the authorized surrogate decision-maker when critical results return.

Annotated Multi-Segment HL7 v2.5.1 Lab Message Example

MSH|^~&|LIS_ENGINE|METRO_LAB|EPIC_BRIDGES|METRO_HOSP|20260410142210-0500||ORU^R01^ORU_R01|MSG20260410991|P|2.5.1
PID|1||90048217^^^METRO_MRN^MR||CARTER^SAMUEL^J||19610824|M|||742 EVERGREEN TER^^SPRINGFIELD^IL^62701||(217)555-0194
NK1|1|CARTER^MARGARET^L|SPO^Spouse^HL70063|742 EVERGREEN TER^^SPRINGFIELD^IL^62701|(217)555-0199||EC^Emergency Contact^HL70131
PV1|1|I|4WEST^412^B^METRO_HOSP||||1234567890^VANCE^MARCUS^A^^^MD^^NPI|||||||||||V2026-88412^^^METRO_VN^VN|||||||||||||||||||||||||20260409081500-0500
DG1|1||E11.65^Type 2 diabetes mellitus with hyperglycemia^I10|||W
ORC|RE|ORD-778210^EPIC_ORD|ACC-554091^LIS_ACC||CM||||20260410134500-0500|||1234567890^VANCE^MARCUS^A^^^MD^^NPI
OBR|1|ORD-778210^EPIC_ORD|ACC-554091^LIS_ACC|24323-8^Comprehensive metabolic 2000 panel^LN|||20260410135000-0500||||L||Fasting specimen|||1234567890^VANCE^MARCUS^A^^^MD^^NPI||||||20260410142150-0500||CH|F
OBX|1|NM|2345-7^Glucose [Mass/volume] in Serum or Plasma^LN|1|198|mg/dL^milligrams per deciliter^UCUM|70-99|H|||F|||20260410135000-0500
OBX|2|NM|2823-3^Potassium [Moles/volume] in Serum or Plasma^LN|1|4.3|mmol/L^millimoles per liter^UCUM|3.5-5.1|N|||F|||20260410135000-0500
OBX|3|NM|2160-0^Creatinine [Mass/volume] in Serum or Plasma^LN|1|1.1|mg/dL^milligrams per deciliter^UCUM|0.7-1.3|N|||F|||20260410135000-0500

Frequently Asked Questions

How do HL7 ORC, OBR, and OBX segments work together in lab messages?

In HL7 v2 laboratory messages (ORM^O01, OML^O21, ORU^R01), ORC (Common Order) provides administrative order control (`ORC-1`), placer/filler IDs (`ORC-2`/`ORC-3`), and ordering provider metadata; OBR (Observation Request) acts as the diagnostic panel or battery header specifying the LOINC/CPT panel code (`OBR-4`), specimen collection timestamp (`OBR-7`), and report status (`OBR-25`); and one or more repeating OBX (Observation/Result) segments nested underneath OBR carry the individual analyte results (`OBX-3`, `OBX-5`, `OBX-6`, `OBX-8`).

What visit data is captured in the HL7 PV1 segment?

The HL7 PV1 (Patient Visit) segment captures encounter-level context: Patient Class (`PV1-2`: `I` Inpatient, `O` Outpatient, `E` Emergency), Assigned Patient Location (`PV1-3`: nursing unit, room, bed, and facility), Attending/Referring/Consulting/Admitting Physicians (`PV1-7`, `PV1-8`, `PV1-9`, `PV1-17`), Visit Number (`PV1-19`), Discharge Disposition (`PV1-36`), and Admit/Discharge timestamps (`PV1-44`/`PV1-45`).

How are ICD-10 diagnosis codes structured in the HL7 DG1 segment?

In the HL7 DG1 (Diagnosis) segment, ICD-10-CM diagnosis codes are carried in DG1-3 (data type CWE) as a caret-delimited triplet of Code^Description^CodingSystem (for example, E11.65^Type 2 diabetes mellitus with hyperglycemia^I10), paired with a priority sequence number in DG1-1 and a Diagnosis Type indicator in DG1-6 (`A` Admitting, `W` Working, `F` Final).