An order response message (ORM) is used to transmit electronic requests and scheduling information between ordercomms, RIS, and PACS. It is important that both customers and vendors recognize the importance of HL7 ORM messages. As there are three vendors (ordercomms, RIS, and PACS) involved in HL7 ORM messaging, it is vital that customers take the lead and get a clearly signed agreement by all vendors before starting any implementation.
Dr. Neelam Dugar is a consultant radiologist at Doncaster Royal Infirmary, U.K., and former chair of the Royal College of Radiologists' Imaging Informatics Group.HL7 ORM messages are generated by two systems in the radiology workflow: ordercomms and RIS. They are received by four systems: RIS, ordercomms (or electronic patient record [EPR], hospital information system etc.), PACS, and DICOM modality worklist broker.
In radiology workflow, when an electronic request for an investigation is made on ordercomms -- which may be standalone or part of EPR or HIS), an HL7 ORM is initiated by ordercomms. For paper radiology requests, HL7 ORMs are generated in the RIS.
When an appointment is subsequently made on the RIS, scheduled information (appointment date and time) is sent out by the RIS to all systems that need to have knowledge of data and time of future appointments (PACS, EPR, ordercomms, etc.). The RIS then sends out order update messages through ORM -- regarding scheduled date and time, accession number, and status update messages.
From a customer's point of view, HL7 ORM has four important segments:
PID (patient demographics information) segment in HL7 ORMs are used for association of the order with the patient, in the RIS and PACS database. HL7 ORM should not update the patient demographics on the downstream systems (RIS or PACS). ORM and ORU (observation result) messages don't have the triggers required to update patient demographics or patient visit information. I have discussed patient demographic updates in a previous article on HL7 ADT messages and triggers.
ORC segment, also called the common order segment. The ORC segment is created in ordercomms for electronic requests, and RIS for paper requests. ORC segments have the following fields that are of importance to RIS, PACS, and DMWL server:
- Triggers for updating the HL7 ORM (field 1-order control)-O 01
New Order-NW
Edit Order-XO
Cancel Order-CA
Hold Order-RE
Status Changed-SC
Accession number assigned by RIS-NA (update ordercomms) Order number: Unique number generated in the ordercomms for each exam in an order group (field 2 -- placer order number)
Accession number - unique number generated in the RIS for each exam (field 3 -- filler order number)
Group order number: This will identify a group of exams requested at the same time on ordercomms or unique number that identifies a group of studies to be done with one clinical requesting history in the OBX segment (field 4-placer group number). This becomes important with multiple exams requested together.
Order status (field 5 -- status): These statuses must be updated as a minimum: requested, held, scheduled, arrived, completed, cancelled)
Date and time of request (field 9 - date/time of transaction)
Requester: junior doctor, nurse specialist, etc., name/ID/job-role/specialty/institution (field 10 - entered by)
Referring consultant/GP/clinician: Name/ID/job-role/specialty/institution (field 11 - verified by)
Main specialty of the consultant/GP requesting the investigation: National Health Service (NHS) data dictionary for main specialty codes (field 12 -- ordering provider)
Referring location (field 13 - enterer's location): GP, outpatient department, accident and emergency, or ward name
GP/consultant's phone/extension number (field 14 - call back phone number)
Referring consultant/GP's institution -- use NACS codes for GP practice or hospital name (field 17 -- enterer's institution)
Reason for cancellation: Free text field should include reason for cancellation (field 16 -- order control code reason -- maximum length of characters is 200)
PC identification (field 18 -- entering device)
Person cancelling the exam (field 19 -- actioned by)
- Triggers for updating the HL7 ORM (field 1-order control)-O 01
- Order number (field 2 - placer order number)
- Accession number (field 3 - filler order number)
- National exam code and description for NHS (field 4 - universal service ID)
- Priority (field 5)
- Requested date/time (field 6)
- Radiographer's completion date/time (field 8 - observation end date/time)
- Modality (field 24 - diagnostic server set ID)
- Radiographer/operator: name/ID/job-role/specialty/institution (field 34 technician)
- Scheduled date/time (field 36 - appointment date and time; same as arrival date and time for walk-in patients)
OBX segment, called observation segment. OBX is commonly used for narrative text, and it can be part of both ORM (and ORU messages). In the ORM, it will contain the narrative clinical history, (whilst in the ORU it will be the narrative report). Radiology request information (clinical history) on ordercomms will form the narrative text as the OBX segment of an ORM. The OBX fields comprise:
- Type of data, text (field 2 -- value type) and
- Narrative clinical history in ordercomms (field 5 -- observation value). The allowable text length is up to 65,536 characters
Composite data fields
Composite data fields should be used in: ORC 10: entered by, ORC 11: verified by, ORC 19: actioned by, OBR 34: technician. These composite HL7 fields should include the following items:
- Name
- ID (for example, U.K. General Medical Council number)
- Job role, as per NHS data dictionary
- Main specialty, as per NHS data dictionary
- Institution, NACS code for NHS
Multiple exams and cancellation workflow
All exams requested together in ordercomms should have a "common" Group Order number -- ORC field 4 -- and Group Placer Order number by ordercomms. Each exam should have a unique order number -- ORC field 2 -- and Placer Order number by Ordercomms. Each exam should be given a unique accession number -- ORC/OBR field 3 -- and Filler Order number by RIS.
When multiple exams are sent out as HL7 ORM, they should be sent as "ORC and OBR pairs" for each exam within the order group. RIS should be able to combine or separate these exams for its workflow -- including scheduling, cancellation, image acquisition, and reporting. The OBX segment (clinical history and questions/answers) should be linked to each exam whether single or combined. It should be possible to edit or cancel exams individually on both ordercomms and RIS.
Cancellation workflow communication using HL7 ORMs is very important too. Requesters not only need to know when an exam is completed and report is issued, but also they need to know when an exam is cancelled and the reason for the cancellation. For example, if the patient was claustrophobic and an MRI scan was cancelled, the referrer needs to know.
Cancellation of an exam may happen either on the ordercomms systems or RIS. However, communication via HL7 ORM must be identical by both systems. Reason for cancellation (field 16: Order Control Code Reason) may be generated by both ordercomms or RIS, depending on which system the cancellation happens. Reason for cancellation is a free text field. The person cancelling the exam should be identified on ORC field 19 (actioned by).
Order update messages
These triggers for updates, generated from RIS only, are important for: accession number (field 3 of ORC and OBR segments), radiographer's completion date/time (OBR field 8: observation end date/time), radiographer/operator: name/ID/job-role/specialty/institution (OBR field 34, technician), scheduled date/time (OBR field 36 -- appointment date and time; same as arrival date and time for walk-in patients), and order status (ORC field 5: status). The following statuses must be used at a minimum -- requested, held, scheduled, arrived, completed, and cancelled.
Older PACS were very image-centric and only showed when images were acquired. PACS is now ubiquitously the single system used by enterprise users to look for all radiology related information. Hence, modern PACS show requested exams, scheduled exams with appointment date and time, completed exams with completion date and time, finalized exams with the images and an authorized radiology report, and any cancelled exams with the reason for cancellation visible to enterprise users.
Customers must take the time to understand and define HL7 ORM messages and triggers. They need to take the lead and get an agreement from all suppliers who choose to work with them. Customers defining their HL7 messages clearly prior to contracts can smooth the implementation and replacement of IT systems. Suppliers will welcome this approach as well, as they know there is a clearly defined HL7 ORM message standard they will be expected to work with.
In my next column, I will discuss HL7 ORU messages.
Dr. Neelam Dugar is consultant radiologist at Doncaster Royal Infirmary, U.K., and former chair of the Royal College of Radiologists' Imaging Informatics Group.
The comments and observations expressed herein do not necessarily reflect the opinions of AuntMinnieEurope.com, nor should they be construed as an endorsement or admonishment of any particular vendor, analyst, industry consultant, or consulting group.
