PACS troubleshooting tips and tricks series (part 9): Modality Worklist issues

In the previous set of blog posts in this series I talked about how to deal with communication errors,

causes for an image to be Unverified and errors in the image header as well as display. This post will discuss the errors that might occur with the DICOM modality worklist.

A modality worklist (MWL) is created by querying a Modality Worklist provider using the DICOM protocol for studies to be performed at an acquisition modality. The information that is retrieved includes patient demographic details (name, ID, birthday, sex, etc.), order details (procedure code, Accession number identifying the order, etc.) and scheduling details (referring physician, scheduled date/time etc.). This information is contained in a scheduling database, which is created by receiving orders for the department in an HL7 format (ORM messages).

The Worklist provider used to be typically hosted on a separate server, aka broker or connectivity manager. But increasingly, this function is embedded in a PACS, a RIS or even EMR that has a radiology package. Moving this function from the broker to these other systems is the source of several issues as the original broker was likely rather mature with a lot of configurability to make sure it matches the department workflow, while some of these new implementations are still rather immature with regard to configurability.

The challenge is to provide a worklist with only those examinations that are scheduled for a particular modality, no more and no less, which is achieved by mapping information from the HL7 order to a particular modality. Issues include:

·        The worklist is unable to differentiate between the same modality at different locations – An order has a procedure code and description, e.g. CT head. As the order in HL7 does not have a separate field for modality, the MWL provider will map the procedure codes to a modality, in this case “CT” so a scanner can do a query for all procedures to be performed for modality “CT.” The problem occurs if there is a CT in the outpatient ER, one in cardiology for cardiac exams, one in main radiology, and one in the therapy department (RT). Obviously, we don’t want all procedures showing up on all these devices. It might get even more complicated if a CT in radiology is allocated, let’s say on Fridays to do scans for RT. We need to distinguish between these orders, e.g. look at the “patient class” being in-or outpatient, or department, or another field in the order and map these procedures to a particular station. The modalities will have to support the “Station Name” or “Scheduled AE-Title” as query keys.

·        The worklist can only query on a limited set of modality types – Some devices are not properly configured, for example, a panoramic x-ray unit used for dentistry should use the modality PX instead of CR, the latter of which might group them together with all of the other CR units. The same applies for a Bone Mineral Densitometry (“DEXA”) device; it should be identified as modality BMD instead of CR or OT (“Other”). Document scanners also should be configured to pull for “DOC” instead of OT or SC (“secondary Capture”), endoscopy exams need to be designated ES, and so on. The challenge is to configure the MWL provider as well as the modality itself to match these modality codes.

·        The worklist has missing information – A worklist query might not have enough fields to include all the information needed at the modality. In one particular instance I encountered, the hospital wanted to see the Last Menstrual Date (LMD) as it was always on the paper order. Other examples are contrast allergy information, patient weight for some modalities, pregnancy status, or other information. If the worklist query does not have a field allocated for these, one could map this at the MWL provider in another field, preferably a “comment field” instead of misusing another field that was intended and named for a different purpose.

·        The worklist is not being displayed – There could be several reasons, assuming that you tested the connectivity as described in earlier blogs, i.e. there could be no match for the matching key specified in the query request, or, the query response that comes back is not interpreted correctly. In one case a query response was not displayed at an ultrasound of a major manufacturer because one of the returned parameters had a value that was illegal, i.e. not part of the enumerated values defined by the DICOM standard for that field. In this case, I could only resolve this issue by looking at sniffer responses and taking those and running them against a validator such as DVTK.

MWL issues are tricky to resolve. It is highly recommended that one have access to the MWL provider configuration software. Most vendors will have a separate training class on this device. Be aware that the mapping tables need to be updated every time a new set of procedure codes is introduced; therefore, it is an ongoing support effort. Configuring requires detailed knowledge of HL7 so you can do the mapping into DICOM.

To troubleshoot these issues, a modality worklist simulator can be very useful. There is a DVTK modality worklist simulator available for free and a licensed modality simulator from OTech.

In case you need to brush up on your HL7 knowledge, there is a HL7 textbook available and there are on-line as well as face-to-face training classes, which include a lot of hands-on exercises.

In the next blog post we’ll spend some time describing the most common HL7 issues impacting the PACS.