DICOM Modality Worklist

Modality worklist (MWL) is one of DICOM’s workflow services that really make a difference. It’s the difference between grocery store workflow with notes on little pieces of paper and a true modern accountable workflow.

Technically speaking, DICOM Modality Worklist is a task manager just like a piece of paper with short text and a check box or the tasks application on your iPhone (or Android). But for the imaging center or RAD department the advantages are enormous. The most obvious benefit is that there’s no need to reconcile all kind of misspelled names in the PACS because the patient name is no longer keyed in on the modality workstation but received electronically via the MWL query. The fact that the requested procedure is also received electronically reduces the chance for doing the wrong procedure to the wrong patient. Combined with Modality Performed Procedure step (MPPS), that allows the modality to report the task status, take ownership over the task and checkmark it as done when completed, the up side is obvious. No wonder then, that many HMO’s require Modality Worklist as a mandatory feature for every imaging device they purchase. 

The most basic abstraction of a task is a short description of what should be done and a checkbox. That’s all it takes. The MWL data model is a bit more complicated and has two levels.

The top, parent, level is called “Requested Procedure” (RP) and holds the information about the patient (name, id), the study (accession number, study instance UID) and the procedure. The procedure can be described as text using attribute (0032,1060) – “Requested Procedure Description” or in a more sophisticated manner using the (0032,1064) – “Requested Procedure Code Sequence” where static tables of codes and meanings can be used to configure and maintain procedures in the RIS or HIS.

The child level is called “Scheduled Procedure Step” (SPS) and holds attributes relevant to the modality and the actual procedure to be made. A single requested procedure may hold more than one SPS if the request is for a multi-modality study, for example a chest X-Ray and a CT or whatever combination, or if for example two protocols should be applied (e.g. Chest and Abdomen). As a modality, we will use the data in the RP to identify the patient and eliminate re-typing of the name and ID and the SPS to determine what exactly to do.

The DICOM images that the modality will create should use the attributes received from the MWL. When MWL is implemented, the Study Instance UID is generated in the RIS so if a multi-modality procedure is done, each modality will create a series and attach it to the Study by using the Study Instance UID received in the MWL query.

The Modality Worklist Server is responsible for managing the tasks. On one hand it provides means to schedule new tasks (e.g. via HL7 or using a web form) and on the other hand it provides means to get the list of scheduled tasks (via DICOM).

In this post, we’re going to write a simple MWL client using RZDCX DICOM Toolkit and discuss the details of the service and how the workflow is implemented. We’ll leave the MPPS for a future post.

Let’s start with a simplified overview of the workflow at the imaging center or the radiology department.

1. An order is made for an imaging service, let’s say for example a chest X-Ray. The order can be made in various ways. For example it can arrive as a HL7 message from the HIS (Hospital Information System), or it can be that the patient walks in an the order is made at the reception desk. In either case, a new record is created in the worklist manager with the information for the service.
2. The order is scheduled and assigned to the X-Ray machine or Room that will perform the exam. If there are many X-Ray machines, the order may be assigned to one of them. The assignment is made by setting the AE title on the order and setting a date. The exact way it is done, is very much the business of the worklist manager implementation. DICOM only defines the data model entities. The relevant entity for this is scheduled procedure step. It’s an abstraction of a task with description of what should be done, when it should be done and who should do it.
3. When the X-Ray machine makes a modality worklist query, it gets the list of scheduled tasks and performs them.

Let’s have a look at a modality worklist client.

On the upper left of this single form application you see the DICOM network parameters that we’ve already seen on chapter 5 of the DICOM tutorial when talking about DICOM networking.

On the upper right side we have some filter attributes that we can use that make a lot of sense. We can filter by the AE title that the procedure was scheduled for, by the type of modality it was scheduled for and using the scheduled date. For demonstration purpose, the date matching attributes here are very detailed in order to show all possible date and time exact, open and closed range matching.

The Query button packs the filter into a DICOM object and then sends it to the MWL server using the Query method of the DCXREQ interface. The SOP class for Modality Worklist is “1.2.840.10008.5.1.4.31”.

The construction of the query object is a bit tricky because we have to build the parent-child hierarchy. The mechanism of making queries for hierarchical objects is called sequence matching. The server (Q/R SCP) should search all the matching Requested Procedures that have at least one child Scheduled Procedure Step with attributes that matches the query. If it finds such, the complete RP with all its child nodes is sent as a result. The client (Query SCU) may set exactly one child node in the query.

The RP and SPS entities have many attributes but for this post what’s important is to understand that we, as a modality, are performing a schedule procedure step so we are looking for the child entity. The AE title, modality and scheduled date are all attributes of the schedule procedure step so in order to perform the matching, we create a filter for the scheduled procedure step and then put it into a requested procedure object as a sequence element and this is the query we send. Here’s the code:

// Fill the query object

rp = new DCXOBJ();

sps = new DCXOBJ();

el = new DCXELM();

// Build the Scheduled procedure Step (SPS) item

el.Init((int)DICOM_TAGS_ENUM.ScheduledStationAETitle);

sps.insertElement(el);

// A lot of code to handle all the cases of date and time matching

// that eventually goes into the elements: ScheduledProcedureStepStartDate and ScheduledProcedureStepStartTime

el.Init((int)DICOM_TAGS_ENUM.ScheduledProcedureStepStartDate);

…

/// This adds a filter for time

el.Init((int)DICOM_TAGS_ENUM.ScheduledProcedureStepStartTime);

…

// Handle the modality Combo Box

el.Init((int)DICOM_TAGS_ENUM.Modality);

if (comboBoxModality..SelectedItem.ToString() != "Any")

    el.Value = comboBoxModality.SelectedItem.ToString();

sps.insertElement(el);

// Now we put it as an item to sequence

spsIt = new DCXOBJIterator();

spsIt.Insert(sps);

// and add the sequence Scheduled Procedure Step Sequence to the requested procedure (parent) object

el.Init((int)DICOM_TAGS_ENUM.ScheduledProcedureStepSequence);

el.Value = spsIt;

rp.insertElement(el);

/// Add the Requested Procedure attributes that we would like to get

el.Init((int)DICOM_TAGS_ENUM.RequestedProcedureID);

rp.insertElement(el);

el.Init((int)DICOM_TAGS_ENUM.RequestedProcedureDescription);

rp.insertElement(el);

el.Init((int)DICOM_TAGS_ENUM.studyInstanceUID);

rp.insertElement(el);

el.Init((int)DICOM_TAGS_ENUM.PatientsName);

rp.insertElement(el);

el.Init((int)DICOM_TAGS_ENUM.patientID);

rp.insertElement(el);

el.Init((int)DICOM_TAGS_ENUM.AccessionNumber);

rp.insertElement(el);

// Create the requester object and connect it's callback to our method

req = new DCXREQClass();

req.OnQueryResponseRecieved += new IDCXREQEvents_OnQueryResponseRecievedEventHandler(OnQueryResponseRecievedAction);

rp.Dump("query.txt");

// send the query command

it = req.Query(LocalAEEdit.Text,

               TargetAEEdit.Text,

               HostEdit.Text,

               ushort.Parse(PortEdit.Text),

               "1.2.840.10008.5.1.4.31",  /// Modality Worklist SOP Class

               rp);

At the bottom of the form we have a grid that will show the results.
We can handle the results either in the callback OnQueryResponseRecievedAction or iterate over the items in DCXREQ.Query return value. In this example we’ll do the later and unpack some of the attributes of the RP into a data grid. Here’s the code for it:

private void LoadResultsToGrid(DCXOBJIterator it)

{

    DCXOBJ currObj = null;

    try

    {

        DataTable dt = new DataTable();

        DataRow dr;

        dt.Columns.Add(new DataColumn("Patient Name", typeof(string)));

        dt.Columns.Add(new DataColumn("Accession Number", typeof(string)));

        dt.Columns.Add(new DataColumn("Requested Procedure ID", typeof(string)));

        dt.Columns.Add(new DataColumn("Requested Procedure Description", typeof(string)));

       

        // Iterate over the query results

        for (; !it.AtEnd(); it.Next())

        {

            currObj = it.Get();

            dr = dt.NewRow();

            dr["Patient Name"] = TryGetString(currObj, DICOM_TAGS_ENUM.patientName);

            dr["Accession Number"] = TryGetString(currObj,DICOM_TAGS_ENUM.AccessionNumber);

            dr["Requested Procedure ID"] = TryGetString(currObj,DICOM_TAGS_ENUM.RequestedProcedureID);

            dr["Requested Procedure Description"] = TryGetString(currObj,DICOM_TAGS_ENUM.RequestedProcedureDescription);

            dt.Rows.Add(dr);

        }

        DataView dv = new DataView(dt);

        dgvQueryResults.DataSource = dv;

    }

    finally

    {

        ReleaseComObject(currObj);

    }

} 

The full source code modality worklist SCU example can be downloaded from here. This example has a master-detail  data grid view that shows the SPS’s of the selected RP.

Don’t forget to download and register MODALIZER-SDK (32 or 64 depending on your OS) before building the project.

As always, comments and questions are most welcome.