HL7 ORF Messages: Observation Result Response

HL7 ORF messages return solicited observation results — they are the server-side reply to a client that explicitly requested results with a query. An ORF message is sent only because something asked for it, which distinguishes it from the ORU message, which pushes results unsolicited. The ORF carries every result the query matched: patient demographics, the observation request that produced the results, and each individual result value with its units, reference range, and abnormal flags. This page explains what an ORF message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ORF response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an ORF message represents

An ORF message — ORF stands for Observation Result Response — delivers observation results in direct reply to a query. The pair that produces it is a QRY^R02 query, which asks a results server for observations matching specified criteria, followed by an ORF^R04 response that returns those results. This query/response pair predates the modern QBP/RSP query framework and is considered legacy in HL7 v2.5.1, but it remains in wide use in laboratory, radiology, and clinical systems that have not migrated to the newer query model.

The ORF echoes the original query in a QRD segment so the receiver can correlate the response to its request. The clinical content is organized into one or more QUERY_RESPONSE groups, each containing patient demographics and one or more ORDER groups. Each ORDER group opens with an ORC and OBR that identify the observation request — what was ordered, when the specimen was collected, and who ordered it — and then carries one OBX per individual result value. This structure means a single ORF message can return the complete results for multiple patients and multiple orders in a single transmission.

The receiver of an ORF is the system that issued the query and is waiting for the results — a clinical workstation, a results-review application, or an integration engine routing results downstream.

When an ORF message is sent

An ORF message is sent in direct response to a QRY^R02 query. It is not generated spontaneously: a query must arrive first, and the ORF is the synchronous or near-synchronous reply carrying whatever results the results server found that matched the query criteria. If the query matched no results, the ORF may return with an empty QUERY_RESPONSE group and an appropriate acknowledgement code in MSA.

Trigger event

The ORF message type carries a single trigger event:

• ORF^R04 – Observation result response (to a query).

The trigger code R04 signals that the message is a solicited response. Receivers that process both ORF^R04 and ORU^R01 use the trigger code in MSH-9 to distinguish a queried result from an unsolicited push, and may apply different routing, acknowledgement, or duplicate-detection logic to each.

Integration topology

The diagram shows the results server receiving a query and emitting an ORF response through the integration engine to the requesting application.

{{diagram: requesting application → QRY^R02 query → results server → ORF^R04 response → integration engine → requesting application / downstream systems}}

Typical senders: laboratory information system (LIS), radiology information system (RIS), clinical data repository, or any results server that stores observations and responds to queries.

Typical receivers: clinical workstation, results-review application, EHR results module, integration engine routing results to downstream consumers.

Direction: bidirectional request/response. The QRY^R02 travels from requester to server; the ORF^R04 travels from server back to requester. The ORF may then be forwarded onward by an integration engine.

Segments in an ORF message

The ORF_R04 message opens with header and query-echo segments, then contains one or more QUERY_RESPONSE groups. Each QUERY_RESPONSE group contains patient demographics followed by one or more ORDER groups, each of which carries an observation request and its individual results. An optional DSC continuation pointer closes the message when the result set spans multiple transmissions. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The QUERY_RESPONSE group repeats once per matched patient, and the ORDER group within it repeats once per matched order. A single ORF can therefore carry results for several patients and several orders per patient in one transmission. The canonical segment pages carry the full field-by-field detail.

Sample ORF message

Note. Constructed for illustration. Patient identifiers, order numbers, dates, names, and result values are fictional.

MSH|^~&|LIS|MERCYGEN|EHR|MERCYGEN|20260604143000||ORF^R04^ORF_R04|MSG00088|P|2.5.1
MSA|AA|QRY00055
QRD|20260604142500|R|I|QRY00055|||1^RD|MR98765^^^MERCYGEN^MR|RES|ALL
ORC|RE|ORD4421^EHR|LAB9901^LIS
OBR|1|ORD4421^EHR|LAB9901^LIS|57021-8^CBC W Auto Differential panel^LN|||20260604070000|20260604070015||||||||NPI1234^SMITH^CAROL^^^^^^NPI||||||20260604143000|||F
OBX|1|NM|718-7^Hemoglobin^LN||13.8|g/dL|12.0-16.0|N|||F
OBX|2|NM|789-8^Erythrocytes^LN||4.55|10*6/uL|3.80-5.10|N|||F
OBX|3|NM|787-2^MCV^LN||91|fL|80-100|N|||F
OBX|4|NM|785-6^MCH^LN||30.3|pg|27.0-33.0|N|||F
OBX|5|NM|786-4^MCHC^LN||33.3|g/dL|32.0-36.0|N|||F
OBX|6|NM|788-0^Erythrocyte distribution width^LN||13.1|%|11.5-14.5|N|||F
OBX|7|NM|6690-2^Leukocytes^LN||7.2|10*3/uL|4.5-11.0|N|||F
OBX|8|NM|777-3^Platelets^LN||210|10*3/uL|150-400|N|||F

What this sample shows

The ORF^R04 in MSH-9 marks a solicited observation response. MSA returns AA (application accept) against the original query id QRY00055. The QRD echoes that query: it was issued at 20260604142500, for patient MR98765, requesting all results. ORC carries the placer order number ORD4421 and filler order number LAB9901, linking the results to the original order. OBR identifies the observation request as a CBC with auto differential (57021-8), with specimen collection at 20260604070000 and ordered by provider NPI1234 (Carol Smith); OBR-25 is F for final. Eight OBX segments follow — one per analyte — each carrying a LOINC-coded observation identifier, a numeric value, units, a reference range, and N (normal) in the abnormal flags field.

Working with ORF messages

Correlate the response to the query using QRD

The QRD segment echoes the original query. Use QRD-4, the query id, as the correlation key that binds this ORF response to the QRY^R02 that requested it. Systems that issue concurrent queries to the same results server must track outstanding query ids and route each ORF to the correct waiting request.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key for the ORF message itself. Use the filler order number in ORC-3 together with the observation identifier in OBX-3 and the observation date in OBX-14 (or the collection date in OBR-7) as the natural business key for each result value. Results servers replay responses after outages, and a replayed ORF carrying the same results must not create duplicate records.

Interpret OBX result status before storing

OBX-11 carries the observation result status — F for final, P for preliminary, C for correction, X for cancelled, and others. Store or display only statuses appropriate for the use case, and update existing records rather than appending when a corrected (C) result arrives for a result already on file.

Handle multi-patient and multi-order responses

The QUERY_RESPONSE group repeats once per matched patient, and the ORDER group repeats once per matched order. Do not assume a single PID or a single OBR per ORF. Parse the repeating groups in sequence and scope each set of OBX segments to the OBR that immediately precedes them.

Vendor variance. The QRF filter segment is optional and its field usage varies widely across results servers. Some senders populate only the date range in QRF-2 and QRF-3, others omit QRF entirely even when filter criteria were present in the original query. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A set of observation results corresponds to FHIR DiagnosticReport and Observation resources, with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on for ORF. The HL7 v2-to-FHIR Implementation Guide provides no message map for ORF_R04. The closely related ORU_R01 (unsolicited observations) does have an official Bundle map — it is the only observation-result message with a published map — but that map does not extend to ORF. A FHIR DiagnosticReport and Observation representation produced from an ORF message is therefore mapped manually, taking the observation request identity and result status from OBR to populate the DiagnosticReport, and each OBX to populate a corresponding Observation resource referenced from that DiagnosticReport.

Common pitfalls

Pitfall. Treating an ORF response like an unsolicited ORU and applying the same routing logic. ORF results were requested by a specific system; routing them as broadcast pushes can deliver results to systems that did not ask for them and are not equipped to deduplicate or scope them correctly.

Pitfall. Storing results without checking OBX-11. Preliminary (P) results are frequently followed by a corrected (C) or final (F) update. Persisting a preliminary value as final causes the downstream record to diverge from the authoritative result.

Pitfall. Assuming a single QUERY_RESPONSE and ORDER group per message. The specification allows the QUERY_RESPONSE group to repeat once per matched patient and the ORDER group to repeat once per matched order. Parsers that assume a flat structure drop all but the first patient's or first order's results silently.

Pitfall. Using MSA-2 instead of QRD-4 for query correlation. MSA-2 echoes the message control id of the query message, while QRD-4 carries the application-level query id. These are not the same field and may differ when the messaging layer assigns its own control ids.

How Vorro handles ORF messages

Vorro ingests ORF responses over MLLP or another transport, deduplicates on MSH-10, and correlates each response to the originating query using QRD-4. Vorro parses the repeating QUERY_RESPONSE and ORDER groups in sequence, scoping each OBX result to its enclosing OBR observation request. Result status from OBX-11 is evaluated before storage or forwarding, so preliminary results are held separately from finals and corrected results update rather than duplicate existing records. Where a FHIR destination is configured, Vorro maps the observation request from OBR to a DiagnosticReport and each OBX to an Observation resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• ORU — the unsolicited observation result message that pushes results without a prior query; the only observation-result message with an official v2-to-FHIR map.
• QBP — the modern query-by-parameter message that replaces the legacy QRY used to elicit an ORF.
• RSP — the modern query response that pairs with QBP, replacing the ORF in newer implementations.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for ORF_R04
• HL7 v2-to-FHIR IG — segment maps index — confirms ORU_R01 has an official map
• HL7 Messaging Standard Version 2.5.1 product brief