HL7 OMI messages place an order for an imaging procedure — radiology, nuclear medicine, or ultrasound — and carry the procedure-specific identifiers that downstream imaging systems need to receive, schedule, and track the study. An OMI message is sent from the ordering system to the radiology information system (RIS) or picture archiving and communication system (PACS) and is the v2.5+ successor to the general ORM order for imaging workflows. This page explains what an OMI message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OMI order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OMI message represents
An OMI message — OMI stands for Order Message — Imaging — communicates that a clinician has placed an order for an imaging procedure. The message carries two core clinical segments: the OBR observation request, which identifies the imaging exam requested (the universal service ID), the modality, and scheduling information; and the IPC Imaging Procedure Control segment, which carries the accession number, the requested procedure ID, and the study instance UID. The IPC segment is the structural feature that distinguishes OMI from other order message types — it exists specifically to convey the DICOM-level identifiers that imaging systems require.
The sender is the order-entry system or EHR, and the receivers are the systems that accept, schedule, and perform the study — most often a RIS, a PACS, or a modality worklist broker. OMI sits at the beginning of the imaging workflow: it creates the order that a ORU result will eventually close. Because the accession number and study instance UID originate here, downstream systems depend on the OMI identifiers to associate acquired images with the correct order.
When an OMI message is sent
An OMI message is sent when a clinician places or updates an imaging order. A single imaging encounter may produce a series of OMI messages — a new order, followed by updates for scheduling changes, modifications, or cancellations — and the order control code in ORC distinguishes each action so the RIS can maintain the correct state of the order.
Trigger event
The OMI message type carries a single trigger event:
OMI^O23– General clinical order message for imaging.
The receiver routes on MSH-9 and then reads the order control code in ORC-1 — NW for a new order, CA for a cancel, XO for a change — to determine how to act on the order.
Integration topology
The diagram shows the ordering system emitting an imaging order through the integration engine to the systems that schedule and perform the study.
{{diagram: ordering system / EHR → OMI message → integration engine → RIS / PACS / modality worklist broker}}
Typical senders: EHR order-entry system, CPOE (computerised physician order entry), outpatient scheduling application.
Typical receivers: radiology information system (RIS), picture archiving and communication system (PACS), modality worklist server, and departmental scheduling system.
Direction: unidirectional order from the ordering source to the imaging department, with an acknowledgement returned and results later delivered as ORU messages.
Segments in an OMI message
The OMI_O23 message is organised into an optional PATIENT group (PID through AL1) and one or more repeating ORDER groups, each opening with ORC and ending with the financial and clinical trial segments. Within an order, the OBR observation request and the IPC imaging procedure control segment are the defining clinical content. 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every OMI message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OMI^O23), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
[{SFT}] | Software Segment. Identifies the software product behind the sender — vendor, product, and version. Useful when imaging order behaviour differs across EHR or order-entry system releases. |
[PID] | Patient Identification. Identifies the patient the imaging procedure is ordered for — the identifier list in PID-3, the name in PID-5, and date of birth and sex used by the RIS to confirm identity. Required when the PATIENT group is present; the group as a whole is optional. |
[PD1] | Patient Additional Demographic. Supplements PID with data such as the patient's primary-care facility and living arrangement. |
[{NTE}] | Notes and Comments. Patient-level notes that apply to the order as a whole, such as clinical indications or allergy context. Optional and repeating. |
[PV1] | Patient Visit. The encounter the imaging order belongs to — patient class, assigned location, and the attending and ordering providers. Required by most RIS implementations to route results and generate charges correctly. |
[PV2] | Patient Visit Additional. Companion to PV1 with admit reason and expected discharge date when a visit is present. |
[{IN1,[IN2],[IN3]}] | Insurance. The patient's insurance coverage for the ordered procedure. IN1 carries the plan and subscriber; IN2 and IN3 supplement with additional and Medicare/Medicaid-specific coverage. Optional and repeating to accommodate multiple payers. |
[GT1] | Guarantor. The party financially responsible for the imaging encounter — name, address, and relationship to patient. Optional. |
[{AL1}] | Allergy Information. Patient allergies relevant to the imaging procedure, such as contrast media reactions. Optional and repeating. |
ORC | Common Order. Opens each order group and establishes the order's administrative identity. Carries the order control code in ORC-1 (NW new, CA cancel, XO change), the placer order number in ORC-2, and the filler order number in ORC-3. Required, and the order group repeats once per imaging procedure ordered. |
[{TQ1,[{TQ2}]}] | Timing/Quantity and Relationship. The requested timing and priority for the imaging procedure. TQ1 carries the schedule and priority (STAT, ROUTINE, ASAP); TQ2 relates this order's timing to another order when sequenced or conditional imaging applies. Optional and repeating. |
OBR | Observation Request. The clinical core of the imaging order. OBR-4 carries the universal service ID — the coded exam requested (e.g., CT chest with contrast). OBR-24 carries the diagnostic service section (modality: CT, MR, US, NM). OBR-27 and OBR-36 carry requested and scheduled date-times. OBR-16 names the ordering provider. Required in each order group. |
[{NTE}] | Notes and Comments. Order-level notes following the OBR, such as clinical indication, patient preparation instructions, or protocol guidance for the performing radiologist. Optional and repeating. |
[IPC] | Imaging Procedure Control. The segment that distinguishes OMI from other order message types. IPC-1 carries the accession number assigned by the ordering or RIS system. IPC-2 carries the requested procedure ID. IPC-3 carries the study instance UID — the DICOM identifier that links the order to the acquired images in the PACS. IPC-4 carries the scheduled procedure step ID. These identifiers are the bridge between the HL7 order world and the DICOM worklist and image-management world. |
[{DG1}] | Diagnosis. The diagnosis or diagnoses supporting medical necessity for the imaging procedure — ICD codes carried with the order for prior authorisation and billing. Optional and repeating. |
[{OBX}] | Observation/Result. Order-time observations such as the patient's height and weight (required for contrast dosing), pregnancy status, or clinical question to be answered. Optional and repeating. |
[{FT1}] | Financial Transaction. The charge or billing information associated with the imaging procedure — transaction code, amount, and quantity — sent on to billing. Optional and repeating. |
[{CTI}] | Clinical Trial Identification. Identifies clinical trial protocols under which the imaging procedure is being performed. Optional and repeating, used when the study is part of a research protocol. |
[ ] = optional, { } = repeating
The order group from ORC through CTI repeats once per imaging procedure ordered, so a single OMI message can carry multiple exams for the same patient visit. The canonical segment pages carry the full field-by-field detail.
Sample OMI message
Note. Constructed for illustration. Patient identifiers, accession numbers, dates, and names are fictional.
MSH|^~&|CPOE|MERCYGEN|RIS|MERCYGEN|20260604083000||OMI^O23^OMI_O23|MSG00047|P|2.5.1
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^M||19721015|F
PV1|1|I|RAD^1^WAITING^^^MERCYGEN||||1234^PATEL^RAJESH^^^DR^MD|||||RAD
ORC|NW|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|||^^^20260604110000^^R
NTE|1|L|Clinical indication: shortness of breath, rule out pneumonia
IPC|ACC20260604001^MERCYGEN|RP20260604001|1.2.840.10008.5.1.4.1.1.99|SPS20260604001
DG1|1||J18.9^Pneumonia unspecified^ICD10|Pneumonia|20260604|A
OBX|1|NM|3137-7^Body height^LN||165|cm|||||F
OBX|2|NM|29463-7^Body weight^LN||68|kg|||||F
What this sample shows
The OMI^O23 in MSH-9 marks an imaging order. PID carries the medical record number MR98765, and PV1 places the patient in the radiology waiting area. ORC carries the order control code NW (new order) with placer order number ORD20260604-001 and filler order number RIS20260604-001. The OBR identifies the exam as CPT code 71046 — a two-view chest X-ray — with a scheduled time of 20260604110000 and ordering provider PATEL. The NTE following OBR carries the clinical indication. The IPC segment ties the HL7 order to the DICOM world: accession number ACC20260604001, requested procedure ID RP20260604001, and study instance UID 1.2.840.10008.5.1.4.1.1.99. The DG1 carries the supporting ICD-10 diagnosis, and the two OBX segments carry height and weight.
Working with OMI messages
The IPC segment is the DICOM bridge
The IPC segment is the feature that makes OMI the correct message for imaging orders. The accession number in IPC-1 is the human-readable study identifier used by the RIS and reported on imaging requisitions; the study instance UID in IPC-3 is the DICOM-level identifier that links the HL7 order to the acquired images in the PACS. Both must be preserved and propagated — losing either breaks the chain between the order, the modality worklist, and the resulting images.
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 the order control code in ORC-1 as the natural business key for an imaging order action. Order feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed new order from creating a second worklist entry or a second charge.
Order control codes and state management
ORC-1 drives the state machine of the imaging order. NW creates the order; XO modifies it; CA cancels it. A RIS that ignores the control code and treats every OMI as a new order will accumulate duplicate worklist entries. Parse ORC-1 on every message and apply the action rather than only handling new orders.
Accession number assignment
The accession number in IPC-1 may be assigned by the ordering system (placer-assigned) or by the RIS (filler-assigned), and the convention varies by site. Confirm with the sending system whether the accession number arrives pre-populated in the OMI or is expected to be assigned by the RIS upon receipt — some sites send a blank IPC-1 and expect the RIS to populate it before building the DICOM worklist.
Vendor variance. The
IPCsegment was introduced in HL7 v2.5 specifically for imaging orders; some older RIS implementations that originated with ORM workflows may not parseIPCat all and instead derive the accession number from customZDSorOBRfields. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
An imaging order corresponds to the FHIR ServiceRequest resource, referencing an ImagingStudy resource for the study-level DICOM identifiers, 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. The HL7 v2-to-FHIR Implementation Guide provides no message map for OMI_O23 and no ConceptMap for the IPC segment. A FHIR ServiceRequest produced from an OMI message is therefore mapped manually, taking the universal service ID from OBR-4 as ServiceRequest.code, the ordering provider from OBR-16 as ServiceRequest.requester, the accession number from IPC-1 as an identifier on the ImagingStudy, and the study instance UID from IPC-3 as ImagingStudy.identifier.
Common pitfalls
Pitfall. Discarding the IPC segment. Systems built to handle generic ORM orders may silently drop the
IPCsegment, losing the accession number and study instance UID. The imaging department then cannot link the order to the acquired images, requiring manual reconciliation in the PACS.
Pitfall. Treating every OMI as a new order. Ignoring
ORC-1and always acting as if the control code isNWduplicates worklist entries when a modification (XO) or cancellation (CA) arrives. Always parse the order control code and apply the corresponding action.
Pitfall. Assuming a fixed accession number source. Some sites assign the accession number in the ordering system and send it in
IPC-1; others expect the RIS to generate it. Assuming one convention and receiving the other results in either a blank accession number or a conflict between two systems that each generated one.
How Vorro handles OMI messages
Vorro ingests the OMI feed over MLLP or another transport, deduplicates on MSH-10, and routes each imaging order to every subscribed destination in the format that system expects — the RIS, PACS, and modality worklist broker. Vorro reads the universal service ID and scheduled time from OBR, applies the order action from the control code in ORC, and preserves and propagates the accession number, requested procedure ID, and study instance UID from IPC so that the DICOM worklist and image management chain remains intact. Where a FHIR destination is configured, Vorro maps the order to a ServiceRequest resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- OMG — the general clinical order message used for non-imaging procedure orders.
- ORM — the legacy general order message that preceded OMI 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 OMI_O23
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for IPC
- HL7 Messaging Standard Version 2.5.1 product brief
