ORM^O01 is the classic HL7 v2 general order message, used for decades to send lab, radiology and other orders from ordering systems to the departments that perform them. Although newer HL7 versions introduced more specific order messages, ORM^O01 remains widely used in production interfaces. This guide explains its structure, key segments, a full example, how it relates to newer messages and the practices that keep orders flowing reliably. For the wider picture of message types, see our HL7 message types and event types guide. Building or fixing an order interface? Request a free HL7 interface review.
What ORM^O01 Is Used For
ORM stands for Order Message, and the O01 trigger event covers general order transactions. The same message type creates new orders, cancels them, changes them and reports status, with ORC-1 order control codes telling receivers which action to take.
Lab orders
The most common use is sending lab test orders from an EHR to a laboratory information system or reference lab. Each order identifies the patient, the tests requested, the ordering provider and supporting information such as diagnoses needed for billing and medical necessity.
Radiology and imaging orders
Imaging orders often travel as ORM messages to radiology information systems, which then schedule exams and create worklists for modalities. Our radiology PACS integration team builds these order and worklist flows for imaging departments. Accurate procedure codes keep these worklists clean and reliable.
Other departmental orders
ORM also carries orders for cardiology, therapies, procedures and other services, depending on how organizations configure their interfaces. Medication orders more commonly use pharmacy-specific messages, such as RDE, though older interfaces sometimes route them through ORM as well. Each department needs its own mapping review.
Order lifecycle events
Beyond new orders, ORM carries cancellations, changes, holds and status updates. A single order may generate several ORM messages during its lifecycle. Receivers rely on consistent order numbers to apply each update to the correct original order. Test every lifecycle event with partners.
ORM^O01 Message Structure
An ORM^O01 message contains patient information followed by one or more order groups. Each order group begins with ORC and usually includes an order detail segment such as OBR. Understanding this structure helps teams handle messages carrying several orders at once.
| Segment | Name | Usage | Purpose |
| MSH | Message Header | Required | Sender, receiver, message type, version |
| NTE | Notes and Comments | Optional, repeating | Message-level comments |
| PID | Patient Identification | Optional in base, usually required | Patient identifiers and demographics |
| PD1 | Additional Demographics | Optional | Extra patient details |
| PV1 | Patient Visit | Optional | Visit or encounter context |
| IN1 | Insurance | Optional, repeating | Coverage for billing |
| GT1 | Guarantor | Optional | Financially responsible party |
| AL1 | Allergy Information | Optional, repeating | Patient allergies |
| ORC | Common Order | Required, repeating | Order control and identifiers |
| OBR | Observation Request | Optional, per order | Test or procedure details |
| DG1 | Diagnosis | Optional, repeating | Diagnoses supporting the order |
| OBX | Observation/Result | Optional, repeating | Ask-at-order-entry answers and related data |
| FT1 | Financial Transaction | Optional | Charges related to the order |
| BLG | Billing | Optional | Billing information |
Key Segments Explained
A handful of segments carry most of the information receivers need to accept and perform an order. Getting ORC, OBR, PID, DG1 and OBX right covers most real-world mapping work and prevents the majority of rejected or delayed orders.
ORC: order control
ORC-1 tells the receiver what to do, such as NW for a new order or CA for cancellation. ORC also carries placer and filler order numbers, ordering provider and transaction time. Every order group begins with ORC. Partners often support limited code sets.
OBR: what is ordered
OBR identifies the ordered test or procedure in OBR-4, often using the receiving lab’s compendium codes. It also carries timing, specimen and clinical information. Partners usually require codes from their own compendium, so mapping tables are essential for lab interfaces.
DG1: why it is ordered
DG1 carries diagnosis codes supporting the order, usually in ICD-10-CM. Labs and imaging centers rely on these for medical necessity checks and billing. Missing or invalid diagnoses are a common reason orders are held or rejected by receiving systems. Validate codes before sending.
OBX: ask-at-order-entry answers
Some tests require extra questions at ordering, such as fasting status or specimen source. These answers often travel in OBX segments within the order. Partners define required questions in their specifications, and missing answers can delay specimen processing. Validate answers before sending orders.
IN1 and GT1: billing details
Insurance and guarantor segments help labs bill correctly, especially for outreach orders from external clinics. Accurate coverage information prevents denials and patient billing problems. Confirm which billing segments each partner requires before building order mappings. Missing coverage details are a common cause of delayed lab billing.
Example ORM^O01 Message
The example below shows a new glucose order for an outpatient visit, including patient, visit, order control, order detail and supporting diagnosis. Data is fictional. Use examples like this to validate parsing, field positions and partner-specific mappings before go-live.
MSH|^~\&|EHR|HOSP|LAB|HOSPLAB|20261016083000||ORM^O01^ORM_O01|MSG00002|P|2.5.1
PID|1||MRN123456^^^HOSP^MR||Doe^Jane^Marie||19850214|F
PV1|1|O|CLINIC1^^^HOSP
ORC|NW|ORD12345^HOSP_EHR||GRP7788^HOSP_EHR|||||20261016083000|JDOE^Doe^Jane||1234567890^Smith^John^A^^^MD
OBR|1|ORD12345^HOSP_EHR||2345-7^Glucose^LN
DG1|1||E11.9^Type 2 diabetes mellitus without complications^I10
Reading the header, patient and visit
MSH identifies the EHR sending to the lab, message type ORM^O01, control ID MSG00002 and version 2.5.1. PID identifies the patient by MRN with assigning authority. PV1 marks an outpatient visit at location CLINIC1. Each value sits exactly where partners expect it.
Reading the order
ORC-1 is NW, a new order, with placer order ORD12345 and group number GRP7788. ORC-12 identifies the ordering provider. OBR-4 identifies the glucose test. In real lab interfaces, OBR-4 usually carries the lab’s own compendium code. Map these codes carefully for each partner.
Reading the diagnosis
DG1 provides diagnosis code E11.9 using the ICD-10-CM coding system, identified as I10 in the third component. Labs use this diagnosis for medical necessity checks and billing, so accurate coding reduces holds and claim denials. Validate diagnosis codes before every order is sent.
ORM^O01 and Newer Order Messages
HL7 v2.5 and later introduced more specific order messages, such as OML for laboratory orders and OMG for general clinical orders. Many organizations still use ORM^O01 because existing systems support it. Understanding both helps teams plan interfaces that work with current and future partners.
Why ORM is still common
Many EHRs, labs and imaging systems built interfaces around ORM^O01 long before newer messages existed. Changing working interfaces carries cost and risk, so ORM remains widespread. New partners may still request it, especially for imaging and smaller labs. Many partners still expect it.
When partners prefer OML
Lab partners following newer implementation guides may require OML^O21 for orders, which better supports specimen details. Confirm which message each partner expects. Integration engines can transform between formats when one system cannot support the other’s preferred message type. Document each partner’s expectation.
Responses to orders
Receivers typically respond to ORM^O01 with an acknowledgment and, depending on configuration, an ORR^O02 order response confirming acceptance and filler order numbers. Agree on response expectations with each partner, because some send only basic acknowledgments. Document the agreed response pattern clearly.
Planning for change
When building new order interfaces, design mappings so message format can change without rewriting business logic. Engines that separate transformation from routing make it easier to support both ORM and newer messages as partner requirements evolve over time. This flexibility reduces future costs.
Implementation Best Practices
Reliable order interfaces depend on accurate code mapping, consistent identifiers and thorough testing. These practices reflect lessons from building order interfaces for hospitals, labs and imaging centers, where errors delay care and create costly manual work.
Maintain compendium mappings
Map orderable tests to each partner’s compendium and keep mappings current as partners add or retire tests. Version mapping files and test changes before deployment. Outdated mappings are one of the most common causes of rejected lab orders. Assign owners for every partner.
Validate before sending
Check required fields, valid diagnoses, ask-at-order-entry answers and patient identifiers before orders leave your system. Early validation prevents rejections downstream and gives clinicians immediate feedback while they can still fix the order easily. Log every validation failure to identify recurring problems.
Test the full lifecycle
Test new orders, changes, cancellations, duplicates and orders containing several tests. Confirm results return correctly against each order. Lifecycle testing catches identifier and control code issues that single new-order tests never reveal. Include partner staff in reviewing results from every test cycle.
Monitor acknowledgments
Track acknowledgments and order responses, alerting staff when orders are rejected or unacknowledged. Our HL7 integration services include monitoring that catches stuck orders before they delay patient care. Dashboards showing order volumes and rejection rates help teams spot problems early and respond quickly.
How Taction Helps With Order Interfaces
Taction has delivered 200+ healthcare projects, including lab, imaging and departmental order interfaces. We help organizations build, test and monitor ORM and newer order messages so orders reach the right system and results return to the right patient.
Free HL7 interface review
Share sample ORM messages and partner specifications. We review structure, identifiers, compendium mapping and responses, then flag risks and fixes. You get clear, prioritized recommendations. Request your free review. We also flag quick fixes you can apply immediately to reduce rejected orders and manual follow-up.
Order interface development
We build ORM and OML interfaces through engines such as Mirth Connect, with validation, mapping, acknowledgments and monitoring included in every project. Each interface is documented for your support team, tested against real partner scenarios and monitored continuously after go-live so stuck or rejected orders are caught early.
Lab and imaging expertise
Our lab integration HL7 services cover reference labs, outreach clients and LIS connections, while our imaging team handles radiology order and worklist flows end to end. We also help organizations onboard new outreach clients faster with reusable order templates and documented compendium mapping standards.
HL7 engineers on demand
Need experienced interface engineers? Hire HL7 integration engineers who understand order workflows, compendium mapping and engine development. They join your team quickly and document every interface. Engagements scale with your roadmap, from a single order interface to support across many labs, imaging centers and departments.
Frequently Asked Questions
These answers cover common questions about HL7 ORM^O01 messages. Because implementation guides and partners add rules beyond the base standard, always confirm requirements with the specifications for your specific interface.
What is an ORM^O01 message?
ORM^O01 is the HL7 v2 general order message, used to send orders for lab tests, imaging and other services from ordering systems to performing systems. It also carries cancellations, changes and status updates using ORC-1 order control codes. Many partners still use it.
What segments are in an ORM^O01 message?
Typical ORM^O01 messages include MSH, PID, PV1, optional insurance and allergy segments, then one or more order groups with ORC, OBR, DG1 and OBX. Implementation guides define which segments each partner requires. Partners often require additional segments, such as insurance details.
Is ORM^O01 deprecated?
Newer HL7 versions introduced more specific order messages, such as OML for lab orders, and recommend them for new implementations. However, ORM^O01 remains widely used in production, so many partners still support and request it. Confirm each partner’s preference first.
What is the response to an ORM^O01?
Receivers usually send an acknowledgment and, depending on configuration, an ORR^O02 order response confirming acceptance and filler order numbers. Agree on response expectations with each partner, because practices vary considerably. Document the agreed response pattern clearly for every connected partner.
Why are lab orders rejected?
Common causes include invalid or outdated test codes, missing diagnoses, missing ask-at-order-entry answers, invalid patient identifiers and unsupported order control codes. Validating orders before sending and maintaining current compendium mappings prevents most rejections. Monitoring rejection trends helps fix root causes.