HL7 ORI Messages: Imaging Order Response

HL7 ORI messages confirm the receipt and acceptance of an imaging order and, critically, return the accession number assigned by the radiology information system (RIS) or PACS back to the ordering system. An ORI message is the response to an OMI imaging order and is sent from the imaging department to the system that placed the order. This page explains what an ORI message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ORI response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an ORI message represents

An ORI message — ORI stands for Imaging Order Response — communicates that the receiving imaging system has processed and accepted an imaging order. The defining segment of the message is the IPC Imaging Procedure Control segment, which carries the accession number assigned by the RIS or PACS back to the ordering system. When the ordering system sends an OMI^O23 with a blank or placeholder accession number, or when the RIS is the authoritative source for accession numbering, the ORI^O24 response is the mechanism by which that assigned accession number travels back to the originating system.

The sender is the radiology information system or PACS, and the receiver is the order-entry system or EHR that submitted the original imaging order. ORI sits one step downstream of the OMI order: the OMI places the order and the ORI confirms it, returning the identifiers that the ordering system needs to track the study. The MSA acknowledgement segment reports whether the order was accepted or rejected at the application level, which is distinct from the transport-level ACK. An ORI message carrying a rejection code in MSA-1 tells the ordering system the order was not accepted and why, without the ordering system having to wait for a human follow-up from the imaging department.

When an ORI message is sent

An ORI message is sent by the imaging system in response to each OMI^O23 it receives. A single imaging order workflow produces at minimum one ORI — confirming the initial order — and may produce additional ORI messages when the imaging system subsequently assigns or updates the accession number, study instance UID, or scheduled procedure step identifiers.

Trigger event

The ORI message type carries a single trigger event:

• ORI^O24 – Imaging order response message.

The receiver routes on MSH-9 and then reads MSA-1 — AA for application accept, AE for application error, AR for application reject — to determine whether the order was accepted and how to update the order's state. The MSH-9 in the ORI always echoes ORI^O24; the original trigger OMI^O23 from the request is not repeated in the response.

Integration topology

The diagram shows the imaging system returning an order response through the integration engine to the ordering system that submitted the original OMI.

{{diagram: RIS / PACS → ORI message → integration engine → ordering system / EHR / CPOE}}

Typical senders: radiology information system (RIS), picture archiving and communication system (PACS), modality worklist server.

Typical receivers: EHR order-entry system, CPOE (computerised physician order entry), outpatient scheduling application.

Direction: response from the imaging department back to the originating ordering system, confirming acceptance and returning assigned imaging identifiers.

Segments in an ORI message

The ORI_O24 message opens with required header and acknowledgement segments, an optional error block, and optional message-level notes. The optional RESPONSE group (PID through PV2) echoes patient and visit context from the original order. One or more repeating ORDER groups each open with ORC and close with the IPC segment that returns the assigned accession number. 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 ORDER group from ORC through NTE repeats once per imaging procedure, so a single ORI message can acknowledge and return identifiers for multiple exams ordered together. The canonical segment pages carry the full field-by-field detail.

Sample ORI message

Note. Constructed for illustration. Patient identifiers, accession numbers, dates, and names are fictional.

MSH|^~&|RIS|MERCYGEN|CPOE|MERCYGEN|20260604110500||ORI^O24^ORI_O24|MSG00048|P|2.5.1
MSA|AA|MSG00047
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^M||19721015|F
PV1|1|I|RAD^1^WAITING^^^MERCYGEN||||1234^PATEL^RAJESH^^^DR^MD|||||RAD
ORC|OK|ORD20260604-001^CPOE|RIS20260604-001^RIS|||^^^20260604110000^^R
OBR|1|ORD20260604-001^CPOE|RIS20260604-001^RIS|71046^Chest X-Ray 2 Views^CPT|||20260604083000|||||||20260604083000||1234^PATEL^RAJESH^^^DR^MD||||||CT
IPC|ACC20260604001^MERCYGEN|RP20260604001|1.2.840.10008.5.1.4.1.1.99|SPS20260604001
NTE|1|L|Order accepted. Scheduled for Bay 3.

What this sample shows

The ORI^O24 in MSH-9 marks an imaging order response. MSA carries the acknowledgement code AA (application accept) and echoes the message control id MSG00047 from the originating OMI, linking this response to the request. PID echoes the patient MR98765 and PV1 echoes the visit context from the original order. ORC carries the order control code OK with the placer order number ORD20260604-001 echoed from the OMI and the filler order number RIS20260604-001 assigned by the RIS. OBR identifies the exam as CPT code 71046. The IPC segment is the payload of the response: it returns accession number ACC20260604001 in IPC-1, requested procedure ID RP20260604001 in IPC-2, study instance UID 1.2.840.10008.5.1.4.1.1.99 in IPC-3, and scheduled procedure step ID SPS20260604001 in IPC-4. The NTE following IPC carries a scheduling note from the imaging department.

Working with ORI messages

The IPC segment carries the return payload

The IPC segment is the reason the ORI message exists. The accession number returned in IPC-1 is the authoritative identifier assigned by the imaging system; the study instance UID in IPC-3 is the DICOM-level link between the HL7 order and the acquired images in the PACS. The ordering system must extract both values and store them against the order — losing either breaks the chain between the order, the modality worklist, and the resulting images, and prevents the ORU result from being matched back to the correct order.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the placer order number in ORC-2 together with MSA-2 as the natural business key for a response. RIS feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed acceptance from overwriting an accession number that has since been updated or from triggering a duplicate worklist entry on the ordering side.

Distinguishing acceptance from rejection

MSA-1 drives the ordering system's response logic. AA means the imaging system accepted and has scheduled or queued the order; AE means an application-level error occurred and the order may need to be resubmitted; AR means the order was explicitly rejected and corrective action is required before resubmission. Parse MSA-1 on every ORI and surface rejections to the ordering user rather than silently discarding them — an unhandled AR leaves the ordering system believing the order was accepted when it was not.

Matching the response to the request

MSA-2 echoes the MSH-10 message control id of the originating OMI. Always match ORI messages to their originating OMI using this field rather than relying on arrival order or order numbers alone — order numbers can change between the OMI and the ORI if the RIS renumbers the order on intake.

Vendor variance. Some RIS implementations do not send an ORI at all and instead rely on the transport-level ACK to confirm receipt. Others send an ORI only when the order is rejected, not on acceptance. Confirm a partner's ORI behaviour against their interface specification — do not assume an ORI will always be returned, and do not assume silence means rejection.

FHIR equivalent

An imaging order response conceptually spans two FHIR resources: the ServiceRequest resource, which represents the order being responded to, and the ImagingStudy resource, which carries the study-level DICOM identifiers — including the accession number and study instance UID — that the ORI returns via IPC.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for ORI_O24 and no ConceptMap for the IPC segment. A FHIR representation produced from an ORI message is therefore mapped manually: the accession number from IPC-1 becomes an identifier on the ImagingStudy; the study instance UID from IPC-3 becomes ImagingStudy.identifier; the acknowledgement outcome from MSA-1 has no direct FHIR analogue in the resource model and is handled at the messaging layer.

Common pitfalls

Pitfall. Discarding the IPC segment. Systems that process ORI messages only for the MSA acknowledgement and ignore IPC lose the assigned accession number and study instance UID. Without these identifiers the ordering system cannot link the order to the PACS study, requiring manual reconciliation in the imaging department.

Pitfall. Treating AA as the only possible response. A RIS may return AE or AR for a malformed order, a missing patient, or a duplicate accession number conflict. Ordering systems that only check for AA and discard other responses leave rejections unhandled, creating phantom orders in the ordering system that the imaging department never processes.

Pitfall. Assuming the accession number in IPC-1 is always populated. When the RIS encounters an error before assigning an accession number, IPC-1 may arrive blank in an AE response. Do not treat a blank IPC-1 as a valid accession number — check MSA-1 first and handle error responses before attempting to extract IPC data.

How Vorro handles ORI messages

Vorro ingests the ORI feed over MLLP or another transport, deduplicates on MSH-10, and matches each response to its originating OMI using the echoed message control id in MSA-2. Vorro reads the acknowledgement outcome from MSA, surfaces application errors and rejections to the ordering system rather than silently discarding them, and extracts and stores the assigned accession number, requested procedure ID, study instance UID, and scheduled procedure step ID from IPC so that the ordering system holds the complete imaging identifier set. Where a FHIR destination is configured, Vorro maps the returned identifiers to an ImagingStudy resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• OMI — the imaging order message that an ORI responds to.
• ORM — the legacy general order message used for imaging workflows in v2.4 and earlier.
• ORU — the observation result message that delivers the radiology report and closes the imaging order.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for ORI_O24
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for IPC
• HL7 Messaging Standard Version 2.5.1 product brief