Order Entry

The HL7 Order Entry (ORM) message is a commonly used message type that holds information about a request for materials or services. Although these messages are mostly used for patient-specific orders, they can also be used for a medical department (e.g. emergency ward) or for a non-patient order (e.g. resources for a study that doesn’t involve patients).

ORM messages are most commonly used to facilitate orders and results-based workflows within Radiology and Laboratory departments. Unlike some other HL7 messages, the ORM message only has one type: ORM^O01. It is used to initiate the transfer of information about an order, and is generated anytime there is a change to an order, including submission of new orders, order cancellations, and updates to the order.

Below is an example a typical HL7 version 2.3 ORM^O01 message:

PID|1||20891312^^^^EPI||APPLESEED^JOHN^A^^MR.^||19661201|M||AfrAm|505 S. HAMILTON AVE^^MADISON^WI^53505^US^^^DN |DN|(608)123-4567|(608)123-5678||S|| 11480003|123-45-7890||||^^^WI^^
PV1|||^^^CARE HEALTH SYSTEMS^^^^^||| |1173^MATTHEWS^JAMES^A^^^||||||||||||610613||||||||||||||||||||||||||||||||V
OBR|1|363463^EPC|1858^EPC|73610^X-RAY ANKLE 3+ VW^^^X-RAY ANKLE ||||||||||||1173^MATTHEWS^JAMES^A^^^|(608)258-





Message Header. This segment contains information about the message sender and receiver, the date and time that the message was created. This segment is required.


Patient Identification. In this example, the ORM message being sent is related to a particular patient, and therefore it needs to include patient-specific information such as the patient identifier, name, date of birth, etc. If the order was not created for a particular patient, this segment would not be included in the overall message. This segment is required.


Patient Additional Demographics. Here is where you would include the name and ID number of the primary facility where a patient is receiving care, as well as the name and ID number of the ordering provider. This segment is optional.


Patient Visit. This segment contains information about patient visit details such as servicing facility, attending doctor, and visit ID. This segment is required.


Common Order. Here is where the order details are held. Patient orders are typically classified as New Orders (NW), so this distinction is included in this example. Additionally, information about the order number from the source system, the order number for the filing system, the date and time of when the order was created, the ordering provider, the order transcriber, the facility or department ID related to the order, and the callback information for any questions about the order are all contained within this segment. This segment is required.


Observation Request. If an order requires additional information, such as medical codes that identify the reason for the order, it would be included in this segment. Information about the ordering provider and the results interpreter would be included here as well. This segment is conditional.


Diagnosis. Medical contexts, such as ICD-10 codes describing the diagnosis, are provided here in order for billing systems to properly identify and apply charges for the procedure. This segment is optional.

[ ] = optional, { } = repeating


For more information on implementing various HL7 message types, please refer to the HL7 Messaging Standard Implementation Guides corresponding to your required version. 




Other HL7 Message Types:

      • HL7 ADT (Admit, Discharge and Transfer)
      • HL7 ORM (Order Entry)
      • HL7 ORU (Observation Result)
      • HL7 MDM (Medical Document Management)
      • HL7 DFT (Detailed Financial Transactions)
      • HL7 BAR (Billing Account Record)
      • HL7 SIU (Scheduling Information Unsolicited)
      • HL7 RDS (Pharmacy/treatment Dispense)
      • HL7 RDE (Pharmacy/Treatment Encoded Order)
      • HL7 ACK (Acknowledgement Message)


Looking for professional advice? 

Iguana is the leading HL7 integration engine on the market, trusted globally for 20+ years. To learn more about HL7 data exchange, contact one of our integration engine experts today.

Additional Resources:

Debunking the Myths of HL7 Integration

There are many myths about what the HL7 standard can do and the implications for healthcare organizations. In this guide, we set the record straight on common HL7 claims.


Integration with HL7

HL7 is great standard, but anyone with first hand experience knows it's not without its challenges. We're here to help!

Let's talk

The ''non-standard" Standard

In practice, you'll find that everyone formats HL7 messages slightly different, even though it has a standard structure in place. With iNTERFACEWARE's integration engine, you can ensure that all data is normalized as intended for full compliance.


Version Compatiblity

What happens when the source destination is sending one version of HL7, while the recipient's system can only handle an older version of HL7? With Iguana you can convert HL7 versions on the fly.


Data Extraction

As you've seen, HL7 messages can contain a lot of information -- sometimes much more than you need. Simplify things using Iguana, by extracting the data from the specific HL7 fields you need. 


Future Proofing

The HL7 organization is always working on improving the standard and new versions will keep coming in the future. Ensure that your data always remains compatible with iNTERFACEWARE's integration engine, Iguana.