HL7 OBR Observation Request
HL7 field reference OBR fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| OBR.1 | Set ID - OBR | No | No | SI | |
| OBR.2 | Placer Order Number | No | No | EI | |
| OBR.3 | Filler Order Number | No | No | EI | |
| OBR.4 | Universal Service Identifier | Yes | No | CE | |
| OBR.5 | Priority - OBR | No | No | ID | |
| OBR.6 | Requested Date/Time | No | No | TS | |
| OBR.7 | Observation Date/Time | No | No | TS | |
| OBR.8 | Observation End Date/Time | No | No | TS | |
| OBR.9 | Collection Volume | No | No | CQ | 0036 |
| OBR.10 | Collector Identifier | No | Yes | XCN | |
| OBR.11 | Specimen Action Code | No | No | ID | 0065 |
| OBR.12 | Danger Code | No | No | CE | 0047 |
| OBR.13 | Relevant Clinical Information | No | No | ST | |
| OBR.14 | Specimen Received Date/Time | No | No | TS | |
| OBR.15 | Specimen Source | No | No | SPS | 0070 |
| OBR.16 | Ordering Provider | No | Yes | XCN | 0010 |
| OBR.17 | Order Callback Phone Number | No | Yes | XTN | |
| OBR.18 | Placer Field 1 | No | No | ST | |
| OBR.19 | Placer Field 2 | No | No | ST | |
| OBR.20 | Filler Field 1 | No | No | ST | |
| OBR.21 | Filler Field 2 | No | No | ST | |
| OBR.22 | Results Rpt/Status Chng - Date/Time | No | No | TS | |
| OBR.23 | Charge to Practice | No | No | MOC | |
| OBR.24 | Diagnostic Serv Sect ID | No | No | ID | 0074 |
| OBR.25 | Result Status | No | No | ID | 0123 |
| OBR.26 | Parent Result | No | No | PRL | |
| OBR.27 | Quantity/Timing | No | Yes | TQ | |
| OBR.28 | Result Copies To | No | Yes | XCN | |
| OBR.29 | Parent | No | No | EIP | |
| OBR.30 | Transportation Mode | No | No | ID | 0124 |
| OBR.31 | Reason for Study | No | Yes | CE | |
| OBR.32 | Principal Result Interpreter | No | No | NDL | |
| OBR.33 | Assistant Result Interpreter | No | Yes | NDL | |
| OBR.34 | Technician | No | Yes | NDL | |
| OBR.35 | Transcriptionist | No | Yes | NDL | |
| OBR.36 | Scheduled Date/Time | No | No | TS | |
| OBR.37 | Number of Sample Containers * | No | No | NM | |
| OBR.38 | Transport Logistics of Collected Sample | No | Yes | CE | |
| OBR.39 | Collector's Comment * | No | Yes | CE | |
| OBR.40 | Transport Arrangement Responsibility | No | No | CE | |
| OBR.41 | Transport Arranged | No | No | ID | 0224 |
| OBR.42 | Escort Required | No | No | ID | 0225 |
| OBR.43 | Planned Patient Transport Comment | No | Yes | CE | |
| OBR.44 | Procedure Code | No | No | CE | 0088 |
| OBR.45 | Procedure Code Modifier | No | Yes | CE | 0340 |
| OBR.46 | Placer Supplemental Service Information | No | Yes | CE | 0411 |
| OBR.47 | Filler Supplemental Service Information | No | Yes | CE | 0411 |
| OBR.48 | Medically Necessary Duplicate Procedure Reason. | No | No | CWE | 0476 |
| OBR.49 | Result Handling | No | No | IS | 0507 |
| OBR.50 | Parent Universal Service Identifier | No | No | CWE |
OBR is the observation request segment. In plain terms, it is the header for a test, diagnostic study, procedure-style observation, or result group. If ORC tells us what is happening to the order, OBR tells us what the observation request is and gives the context for the OBX result segments that follow.
In a lab result message, the OBR often says "this is the chemistry panel" or "this is the surgical pathology case", and the following OBX segments carry the individual observations, values, comments, or report text. In an order message, OBR describes what the placer is requesting. The same segment therefore has one foot in the ordering world and one foot in the reporting world, which is why it can look a little odd when you first meet it.
The big practical rule is that ORC and OBR overlap deliberately. ORC-2 and OBR-2 are the same logical placer order number. ORC-3 and OBR-3 are the same logical filler order number. If both are sent, they should match. If the sender only sends them in OBR, the receiver can still use them. If they differ, treat it as a real integration issue, not a harmless duplicate. I often use HL7 Soup Web to line ORC and OBR up while testing, because mismatched order numbers are easier to catch before they reach the LIS or RIS.
The other important rule is that OBR is not the result value. OBR-25 can tell you the status of the result group, but the actual glucose value, imaging impression, pathology paragraph, or microbiology organism usually lives in OBX. OBR is the request and report header. OBX is where the individual observations are carried.
So let's go through each of the OBR fields and talk about how they tend to behave in real interfaces.
Sequence is all this field is trying to do. If a message has one OBR, this is usually 1. If it has several observation request groups, the set IDs can count them.
It is not an order number and it is not a panel code. Use it for sequence only. If your receiver ignores it, that is common. If your receiver requires it, keep it boring and consistent.
Order matching needs both sides of the conversation. The placer number comes from the ordering side, and the filler number comes from the performing or resulting side. These are the same logical identifiers as ORC-2 and ORC-3.
These fields matter enormously for matching results back to orders. If an ORU result arrives, the receiving EHR usually wants to know which order it fulfills. The placer number is often the best bridge back to the original request. The filler number is often the best identifier for the performed test or report in the lab, radiology, or diagnostic system.
If ORC and OBR are both present, do not let these fields drift. A common local rule is "ORC and OBR order numbers must match, and if one side is empty, use the other." That is a good rule when the sender behaves that way. What you do not want is a receiver quietly attaching a result to ORC-2 while the lab report itself uses a different OBR-2.
The service code names what was ordered, performed, or reported. In lab it might be a test or panel code. In radiology it might be the exam. In pathology it might be a procedure or report type. It is one of the most important fields in OBR, and it is required.
Send a code, display text, and coding system when you can. 88304^Surgical pathology^L is a local code with text. A LOINC-coded lab test would use the LOINC coding system. A receiver should not have to parse a report title to work out what test this OBR represents. OBR-4 is the place to say it clearly.
Be careful with panels. OBR-4 may identify the panel or battery, while the following OBX segments identify the individual observations. Do not put every individual analyte into separate OBRs unless that is how the interface is designed. Equally, do not cram multiple unrelated studies under one OBR because they happened to travel in one message.
These two fields are older priority and requested-time fields. You will still see them in v2.5.1 style feeds, but later HL7 thinking moved away from them in favor of richer timing structures such as TQ1/TQ2 and other order timing fields.
If your sender populates them, use them only according to the local agreement. Do not assume OBR-6 is the collection time or the result time. It is the requested date/time. OBR-7, OBR-14, OBR-22, and ORC timing fields answer different questions.
Clinical timing starts here. For lab, the start time is often the specimen collection time. For radiology or other diagnostic studies, it may be the exam start time. The end time can matter for timed collections, procedures, studies, or observations that have a duration.
In result messages, OBR-7 is usually much more useful than MSH-7 for clinical interpretation. MSH-7 tells you when the message was created. OBR-7 tells you when the observation happened. If a specimen was collected yesterday but the result was reported today, those dates should not be blended together.
Specimen details start to creep in here. Collection volume uses a quantity and unit, and is most useful where volume affects interpretation or processing. The collector identifier is often empty in routine feeds, but when present it can help trace specimen collection issues.
Do not use OBR-10 as the ordering provider. That is OBR-16 or ORC-12. The collector is the person who collected the specimen. In a phlebotomy workflow, that distinction matters.
Specimen workflow is the point here. Values can mean the lab should obtain the specimen, the specimen was obtained by someone else, the order is pending specimen delivery, tests should be added to an existing specimen, or the order is generated by reflex rules.
This is a workflow field. If a sender says the lab is expected to collect the specimen, the receiver may behave differently than if the specimen is already collected and on its way. Do not populate it from habit; it should reflect the actual specimen workflow.
Hazard and context sit side by side here. The danger code can carry handling or safety information relevant to the specimen or procedure. Relevant clinical information is free text, with examples such as fasting status, symptoms, menstrual cycle timing for cervical cytology, diagnosis hints, or other context needed by the performing service.
OBR-13 is useful, but it is also easy to abuse. If the information can be sent as structured observations, diagnoses, or order questions, that is usually better than a long free-text sentence. Still, in many real lab and radiology interfaces, OBR-13 is the place where a little clinical context survives the trip.
Specimen receipt and source tell the physical specimen story. In v2.5.1 you still see both fields, especially in lab result feeds. In later HL7 versions, much of this specimen detail moved to SPM, which is a better home for modern specimen information.
If your interface has SPM, prefer it for detailed specimen modelling. If your feed is older and uses OBR-14 and OBR-15, handle them carefully. Specimen received time is not collection time. Specimen source is not the test code. These fields help explain the physical specimen behind the observation request.
Provider and callback detail can appear at the OBR level as well as the ORC level. These fields overlap with ORC-12 and ORC-14. In a simple interface, the ORC and OBR values should usually match.
Differences can be legitimate when one ORC has several OBRs and one detail request has a different provider or callback. But that needs to be intentional. Use structured XCN and XTN values. Names and phone numbers in comments are not a reliable provider directory.
These four text fields are local escape hatches: two from the placer side and two from the filler side. They are often used to echo local accession data, requisition labels, case numbers, tray numbers, internal routing values, or values that old systems could not place anywhere cleaner.
The useful habit is to document every one of these fields if you use them. "Placer Field 1" is not a meaning. It is a label waiting for a local agreement. If you cannot explain the field in one sentence, the next interface will probably guess wrong.
The report lifecycle timestamp belongs here. It is the date and time the result report or status changed, and in FHIR-shaped thinking it lines up naturally with the issued time of a diagnostic report. It is not the collection time and not necessarily the observation time.
This field is important when preliminary, corrected, amended, and final results move through the system. If OBR-25 says preliminary at 14:00 and final at 16:00, OBR-22 is one of the places that helps the receiver understand that progression.
Billing and department routing meet here. The charge field is usually only meaningful in billing-aware workflows. The diagnostic service section identifies areas such as laboratory, microbiology, chemistry, hematology, radiology, ultrasound, CT, pathology, or other service categories.
OBR-24 is often useful for routing and display. A receiver may use it to group reports by lab, radiology, cardiology, or pathology. Do not confuse it with OBR-4. OBR-24 says the department or diagnostic service section. OBR-4 says the specific ordered or reported service.
For result messages, this status is one of the big ones. Common values include preliminary, final, corrected, no results available, procedure incomplete, cancelled, partial results, and results stored but not verified. It describes the status of the result group represented by this OBR.
Keep OBR-25 separate from OBX-11. OBR-25 is the status of the whole result group or report header. OBX-11 is the status of an individual observation. They often align, but they do not have to. A panel can have some final OBXs and some preliminary or corrected content depending on the workflow.
Also keep OBR-25 separate from ORC-5. ORC-5 is order status. OBR-25 is result status. A result can be final while the order status has its own lifecycle, and a cancelled order may produce an OBR with status X and no OBX results. Model those ideas deliberately.
Parent links help preserve the lineage of reflex testing, microbiology, add-on testing, replacement reports, and other workflows where one observation request or result follows from another. One field links to a parent result; the other links to a parent order using placer and filler identifiers.
Do not confuse parent result with placer group number. A parent result says this result is related to a previous result. A parent order says this order is related to another order. A group number says orders belong together. These are similar enough to be dangerous if the interface guide is vague.
Older timing detail may still arrive here using the TQ data type. Later profiles may prefer TQ1/TQ2. If you see both, agree which one is authoritative.
Copies-to is a separate routing idea. It lists providers who should receive copies of the result, which is not the same as the ordering provider. In real life, copies-to can drive report distribution, letters, inbox routing, and sometimes medico-legal expectations. Use provider identifiers, not just names.
Transport mode is about moving the patient to the diagnostic service, or sometimes bringing the device to the patient. Values might describe walking, wheelchair, cart, or another local transport pattern. This is common in radiology-style workflows and less common in simple lab reporting.
It is a patient movement and logistics field, not specimen transport. For specimen transport details, look at the specimen and transport fields later in the segment or SPM in newer messages.
Clinical indication belongs here. In radiology this might be the reason for the exam. In lab it might be a clinical reason for testing. It repeats because there may be more than one reason.
Use coded reasons where the receiving system expects them. Do not hide the reason in OBR-13 if the receiver is looking at OBR-31 for clinical indication. Conversely, do not put a long free-text history in OBR-31 if the interface guide expects short coded reasons.
Report workflows often split the human roles. The principal interpreter, assistant interpreters, technicians, and transcriptionists can all be distinct people. These are person-and-location fields using NDL.
These fields are often important in radiology, cardiology, pathology, and other report workflows where interpreting, performing, and transcribing are separate roles. Do not collapse them into "doctor" unless the receiver truly has nowhere else to put the information. If the role matters to the report, keep it distinct.
Scheduled time is the plan, not the event. It is not the same as the observation time in OBR-7. Scheduled time is what was planned. Observation time is what happened.
For scheduling-heavy interfaces, this distinction is useful. A late result can show that the study was scheduled for one time, performed at another, and reported at a third. Those three timestamps answer different questions.
The late OBR transport fields stay quiet until a workflow really needs them. They can carry the number of sample containers, transport logistics for the collected sample, collector comments, transport responsibility, whether transport is arranged, whether an escort is required, and planned patient transport comments.
These fields are quiet until you integrate with a workflow that needs them. Lab collection, radiology transport, inpatient imaging, and outreach collection can all care about these details. For a simple result feed, most of them will be empty. That is fine. Populate them when they reflect a real operational process, not because the segment has room.
Procedure coding lives here, with one field for the procedure code and another for one or more modifiers. These are often used for billing, reporting, procedure classification, or local coding workflows.
Do not confuse OBR-44 with OBR-4. OBR-4 identifies the ordered or reported service. OBR-44 may identify a procedure code used for billing or classification. Sometimes they look similar, but they have different purposes.
Supplemental service information is for agreed extra detail that does not fit cleanly into the main service identifier. One field comes from the placer side and one from the filler side, and both are repeating coded fields.
Use them when the implementation guide defines the codes. If you need to say "left", "contrast", "portable", "stat", or another modifier, check whether your profile expects that in OBR-4, OBR-31, OBR-44/45, OBR-46/47, or somewhere else. Different domains solve this differently.
Duplicate procedure reasons sit in a narrow billing and medical-necessity lane. The field explains why a duplicate procedure is medically necessary, and it depends on the presence and meaning of the procedure code context. It is not a general duplicate-order note.
If you use this field, make sure the receiver understands the coding and the billing or clinical reason behind it. Duplicate procedure logic is exactly the sort of thing that becomes expensive when it is only half implemented.
Result handling tells the receiver what to do next with the result. Local examples include film with patient or notify provider when ready. In modern systems this may map to routing, notification, or delivery behavior.
Be careful not to overuse it as a general comment. If it affects routing, notification, or delivery, make the rules explicit. If it is just a note, put it somewhere the receiver treats as a note.
The final parent-child helper points at the parent universal service. It can help connect a child observation request to the service that generated or contains it.
This is a specialist field, but useful when you have replacement, reflex, child, or panel relationships that need to preserve the parent service. As always, do not invent parent links unless the relationship is real and both sides know how to use it.