Before we jump into ORM messages, a quick review might be in order. As we’ve discussed before, HL7 has many message types which can be very daunting. It’s not only that there are messages but also that there are types of HL7 messages which are geared towards handling specific events. Admission, Discharge, Transfer (ADT) messages are sent when patient’s are admitted, discharged or otherwise moved around the hospital. Scheduling (SIU) messages schedule and update appointments in clinics. Order Entry (ORM) messages are sent when orders are placed or edited and Order Result (ORU) messages are sent back with results that correspond to the original ORM message. These are the most common HL7 message types; most other workflows, like updating flowsheets or filing visit notes, use some combination of segments from these message types to accomplish their goals. Since we already covered the ADT message in detail here, we thought we could move onto the Order Entry (ORM) message.
As mentioned earlier, an order is a request for material or services, usually for a specific patient. These could be anything ranging from medication orders, measuring of vitals, lab tests, specific food / dietary orders, radiology films. These could also be generic orders (not clinical or pertaining to patient) for materials required to keep the hospital running i.e. linens from housekeeping, supplies from central supply etc. If something needs to happen in a hospital or clinic, from printing a requisition to e-prescribing, orders distribute pertinent data from system to system.
Common uses for ORM
ORM messages are most commonly used to send Radiology Orders and Lab Orders. Following the standard HL7 message structure, an ORM message is made up of segments and groups of segments, each of which may be required, optional, repeatable, or some combination thereof. A quick note on reading HL7 message examples which seem to contain a bunch of [],{} etc. The general rule is as follows:
- No brackets around it - Required
[]- Optional{ }- Repeating[{ }]- Optional Repeating
The ORM message structure is as follows.
ORM General Order Message
MSH Message Header
[{NTE}] Notes and Comments (for Header)
[
PID Patient Identification
[PD1] Additional Patient Identification
[{NTE}] Notes and Comments (for Patient ID)
[PV1 Patient Visit
[PV2|] Patient Visit Additional Information
[{IN1 Insurance
[IN2] Insurance Additional Info
[IN3] Insurance Additional Info
}]
[GT1] Guarantor
[{AL1}] Allergy
]
]
{
ORC Common Order
[
Order Detail Segment OBR, etc.
[{NTE}] Notes and Comments (for Detail)
[{DG1}] Diagnosis
[
{
OBX Observation/Result
[{NTE}] Notes and Comments (for Results)
}
]
]
{[CTI]} Clinical Trial Identification
[BLG] Billing segment
}
A couple of interesting things to note before we work through an example.
- As mentioned earlier, the ORM message can be used to send patient specific orders or just operational orders (like ordering sheets etc.) which is why, the PID segment above is an optional segment. The segment is only required in the case of new orders and only if the new order is related to a particular patient. Only then will / should the PID segment be included in the message.
- Note the presence of multiple (optional, repeatable) Diagnosis (DG1) segments. If repeated, the first will be the primary diagnosis.
- Note the presence of the OBX (Observation) segment as an optional, repeatable segment. The use here is different from its use in the ORU (Observational Report - Unsolicited) message. When used, it carries clinical information that might be needed by the receiving system to interpret the observation that will be made, rather than information about observations and results. So if the consuming system is an Imaging system, then the ID would be set to TCM and and additional context around the order would be sent (for example, CPT code of order with the associated description -
73610^X-RAY ANKLE 3+ VW). Similarly, other ID types allowed include GDT (narrative), Addendum (ADT), Study Notes (TCM), Transcribed Reports (TX).
With that out of the way, let’s take a simple message and see how it gets translated into an HL7 ORM message.
The message I want to send is: A male, African American patient, John Appleseed, MRN:20891312, SSN:123-45-7890 born on December 1, 1966 and account number of 11480003 needs to have X-Ray of his ankle done. The order is being place by Dr. James Matthews. The exact procedure to be performed is X-RAY ANKLE 3+ VW with the associated CPT code of 73610. This is based upon a diagnosis of Broken Ankle. Additional information that will need to be sent will include facility, sending and receiving systems, the version of HL7 being used etc.
Based on this information, the segments would be created as follows:
MSH - Message Header
Assuming an all Epic environment i.e. sending and receiving systems are all Epic and order is created at 2014/04/18 at 17:33:14. Version of HL7 being used is v2.3. This would result in a segment that looks like this.
MSH|^~\&|EPIC|EPIC|||20140418173314|1148|ORM^O01|497|D|2.3||
PID - Patient Identification
Since this message is a patient specific order, it needs all the associated patient info to prevent any confusion and ensure no billing comebacks. This would include the patients identifier, full name, DOB, sex, race, address, phone number(s), account number, SSN and place of birth. Some of these are optional as described in the format specification.
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^^
I’ll skip the NTE segment and go the next key one.
PD1 - Patient Additional demographics
This essentially contains the name and ID of primary facility where care is being provided and the name and ID of the provider placing the order resulting in
PD1|||FACILITY(EAST)^^12345|1173^MATTHEWS^JAMES^A^^^
PV1 - Patient Visit
This usually contains information on the admission information, attending, referring and consulting, admitting physician IDs and names and so on. I’ll just keep it simple and just have the attending physician’s info in the sample giving us
PV1|||^^^CARE HEALTH SYSTEMS^^^^^||| |1173^MATTHEWS^JAMES^A^^^||||||||||||610613||||||||||||||||||||||||||||||||V
ORC - Common Order
Finally, we get to the order details. As mentioned before, since this is a patient specific order, it must be a new order. So, we need to specify that it is a new order (NW), the order number of the originating (placer) system (987654 from EPIC), the order number of the system filling this (for reference - 76543 from EPIC). Additional details that need to be filled in include dates and times of transaction, who created the order, who the ordering provider was, the location IDs (facility, department) and callback information in case something needs to be clarified.
ORC|NW|987654^EPIC|76543^EPC||Final||^^^20140418170014^^^^||20140418173314|1148^PATTERSON^JAMES^^^^||1173^MATTHEWS^JAMES^A^^^|1133^^^222^^^^^|(618)222-1122||
Observation Request
Since the order is being sent to an imaging facility, additional details need to be specified such as the CPT codes and so on. I won’t detail this as much here. The key fields required here are the order details (73610^X-RAY ANKLE 3+ VW), ordering provider info (1173^MATTHEWS^JAMES^A^^^) and who the interpreter of the results is going to be (6064^MANSFIELD^JEREMY^^^^).
OBR|1|363463^EPC|1858^EPC|73610^X-RAY ANKLE 3+ VW^^^X-RAY ANKLE
||||||||||||1173^MATTHEWS^JAMES^A^^^|(608)258-
8866||||||||Final||^^^20140418170014^^^^|||||6064^MANSFIELD^JEREMY^^^^||1148010^1A^EAST^X-RAY^^^|^|
DG1: - Diagnosis
Some basic context needs to be provide so that the billing systems can do their work so diagnosis information is also provided. So in ICD10 (I10), ankle fracture is coded as S82.
DG1||I10|S82^ANKLE FRACTURE^I10|ANKLE FRACTURE||
Bringing it all together
Now, we string all these together and we get the full HL7 ORM message.
MSH|^~\&|EPIC|EPIC|||20140418173314|1148|ORM^O01|497|D|2.3||
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^^
PD1|||FACILITY(EAST)^^12345|1173^MATTHEWS^JAMES^A^^^
PV1|||^^^CARE HEALTH SYSTEMS^^^^^||| |1173^MATTHEWS^JAMES^A^^^||||||||||||610613||||||||||||||||||||||||||||||||V
ORC|NW|987654^EPIC|76543^EPC||Final||^^^20140418170014^^^^||20140418173314|1148^PATTERSON^JAMES^^^^||1173^MATTHEWS^JAMES^A^^^|1133^^^222^^^^^|(618)222-1122||
OBR|1|363463^EPC|1858^EPC|73610^X-RAY ANKLE 3+ VW^^^X-RAY ANKLE ||||||||||||1173^MATTHEWS^JAMES^A^^^|(608)258-
8866||||||||Final||^^^20140418170014^^^^|||||6064^MANSFIELD^JEREMY^^^^||1148010^1A^EAST^X-RAY^^^|^|
DG1||I10|S82^ANKLE FRACTURE^I10|ANKLE FRACTURE||
It’s not pretty, but it’s the way healthcare orders are passed from system to system today, even if it’s an all EPIC facility. Thankfully there are services like Datica to help you work with HL7 messages.
If you’re looking to integrate EHR data with your application without becoming an HL7 expert, Datica can help. Learn more about Datica Managed Integration Services for HL7 here.
Looking for further help on integrating an ORM (Orders, Procedures) feed with an EHR? Check out ORM Integration Help.