Understanding HL7: Updating a Modality Work List (MWL) using an ORM^O01 message
Recently I’ve been playing with putting together a basic Radiology Information System (RIS), and one of the things that came up was how to add to a modality worklist (MWL) via an appropriately chosen HL7 message.
In my setup, the MWL is actually handled by dcm4chee, which adds an additional level of specificity. However, here I’d like to have a more general discussion, one which sheds a bit of light on the broader set of steps one can take when trying to understand something new in HL7 (which is hopefully more efficient than trawling google for hours on end :)).
Your greatest friend, and, at first, frenemy (though definitely more friend than enemy), will be your copy of the HL7 standard, which can be obtained for free here, albeit only after registering and signing a rather lawyerly terms-of-use agreement.
Note: The discussion in this article is based off of HL7 v2.5.1.
An MWL item is typically added by sending an ORM_O01 HL7 message to an HL7 server which lives within your RIS. ORM_O01 messages are described in “Chapter 4: Order Entry” of the HL7 specification.
The ORM_O01 message consists of a few groups of information called ‘segments.’ For our purposes, we will be interested in the following segments:
- MSH – Message Header (required) – contains stuff like version of HL7 message belongs to, syntax info, etc.
- PID – Patient Identification (required) – contains fields that identify the patient.
- PV1 – Patient Visit Info (optional), contains things like referring physician.
- ORC – Common Order (required) – will contain meta details about the order.
- OBR – A sub-segment of ORC (optional, but one of OBR, RQD, RQ1, RXO, ODS, or ODT is required)- containing details about the order.
- ZDS – A custom segment not defined by the HL7 standard (optional), but useful in RIS – it will contain things like the studyUID of the radiology order.
Eventually these segments will all get packed together into an HL7 message that in plain text format looks like this:
MSH|^~\&|SendingApp|SendingFac|ReceivingApp|ReceivingFac|20160611122202||ORM^O01^ORM_O01|168715|P|2.5 PID||1|A-10001||B-10001|DOE^JOHN PV1||RAD|||||TEST.JaLo^Jaramillo^Lorenza|^ReferringPhysLast^ReferringPhysFirst ORC|NW|1||||||||20150414120000 OBR|1|1|2|1100|||||||||||||||2|SPSID||||CT ZDS|18.104.22.168.13.1.432252867.1552647.1^dorara.CT.1^CT.1
where a new line separates each segment, and the pipe character (“|”) separates each field within a segment.
Looking Up Segment Definitions
Segments, huh? That’s all good and great, but how do we find out what segments go in a specific type of message, and what pieces of data go into each segment?
The procedure is as follows. Looking at the above snapshot of the ORM^O01 message definition, we see a list of possible segments allowed +/ required for this message type, and that for each segment referred to in this definition, there is a column specifying the chapter in which the segment is described in fuller detail.
For example, according to the above snapshot, further information on the MSH, PID and PV1 segments can be found in chapters 2, 3 and 3, respectively.
The PID Segment
Having discovered that the PID segment is defined in Chapter 3, we open it up and discover via it’s table of contents that Section 3.4 is dedicated to various types of message segment definitions, and that the PID message segment is described in section 3.4.2, starting on pg. 3-72.
Opening up Section 3.4.2, we see that, indeed, the fields contained in the PID segment are defined, including various notes on valid values for each field, information on whether a given field is optional or not, and so on.
For example, looking at the table “HL7 Attribute Table – PID – Patient Identification” on pg. 3-72, we see that the only two fields that are explicitly required for the PID segment are PID-3 and PID-5, corresponding to “Patient Identifier List” and “Patient Name,” respectively (they are explicitly required due to their having an “R” value in the “OPT” column). These two fields are described in detail on pages 3-74 and 3-75.
For example, for PID-5 we discover that:
“This field contains the names of the patient, the primary or legal name of the patient is reported first. Therefore, the name type code in this field should be “L – Legal”. Refer to HL7 Table 0200 – Name Type for valid values. Repetition of this field is allowed for representing the same name in different character sets. Note that “last name prefix” is synonymous to “own family name prefix” of previous versions of HL7, as is “second and further given names or initials thereof” to “middle initial or name”. Multiple given names and/or initials are separated by spaces.”
And has a rather complex set of components and sub-components, separated by “^” and “&”, respectively, which leads to values looking something like so:
w/ each field potentially having sub-components. For example, also on pg. 3-75 we discover that “FamilyName” can be further broken down into:
In our above ORM^O001 sample message it doesn’t get that complex, for PID-5 we simply have “DOE^JOHN”, ie: “FamilyName^GivenName”.
The discussion thus far has been fairly general and could serve as a primer on how to work with the standard to learn about HL7 messages. The below is more specific to ORM^O01 and the problem of updating an MWL in a radiological setting.
Sending a Message Announcing a New Radiology Order
Since our aim is also to discuss how to add a radiology order to an MWL via HL7, our HL7 message should include some bits of information that are specific to this task. Namely:
- Scheduled Procedure Step ID
- Modality of the scheduled procedure step
- Scheduled Station AE Title
- Referring physician
- Attending physician
- The studyUID of the study
This is where you start understanding that as fantastic and detail oriented as the HL7 standard is, it leaves quite a bit of ambiguity for you to resolve. For example, of the above desired fields, some have explicit rules for their implementation (ie: the referring and attending physicians), but some important fields do not.
For example, as described here:
“The IHE Radiology Technical Framework – Volume 2 (RAD TF-2): Transactions, Appendix B: HL7 Order Mapping to DICOM MWL also does not specify recommended mapping for DICOM tags:
- (0040,0001) Scheduled Station AE Title
- (0008,0060) Modality.”
Thus, we are left with some leeway as to where and how we put this information into our HL7 message. In the above example ORM^O01 message we’ve actually already decided upon how to do this. The AE Title is specified within a sub-component of the ZDS-1 field, while the modality is specified within OBR-24.
The ZDS Segment
The ZDS segment merits special note, as you may be confused to find that it does not really appear in the HL7 standard. That’s because all segments with names starting with the letter “Z” are treated as custom segments whose implementation is defined by the user. Such segments are used to transmit information that is not explicitly defined by the HL7 standard, but that nonetheless one needs / wants to include, for whatever reason.
For example, in our example message, we are using the ZDS segment to transmit the studyUID, the AE title and the AE station name as sub-comonents of the ZDS-1 field, ie:
And our HL7 server will be configured to parse this segment correctly and enter this information into our modality work list.
For additional info on the ZDS field, you might be interested in this stackoverflow question / answer.
In a companion article we describe in detail how to update the MWL in dcm4chee using an HL7 / ORM^O01 message, which requires some extra configuration on dcm4chee’s end.