implementation of Dicom worklist listener

[rbeckman-nextgen]

The conversion from SOAP or HL7 to a Worklist server which modalities can query. There are many cases where there is no full featured PACS solution operational or even possible. The workflow from HL7 admission to recording images and storing images to a useful location is often an issue.

Imported Issue. Original Details: Reporter: norbert Created: 2009-07-16T05:28:17.000-0700

[rbeckman-nextgen]

workflow limited PACS solution

Imported Comment. Original Details: Author: norbert Created: 2009-07-16T05:34:50.000-0700

[rbeckman-nextgen]

Do you know a release date to Mirth 2.1 with MWL Added? Regards. Jhon Carrillo

Imported Comment. Original Details: Author: jcarrillo Created: 2010-08-04T07:50:46.000-0700

[rbeckman-nextgen]

Any news about it?

Imported Comment. Original Details: Author: jcarrillo Created: 2010-08-04T08:37:32.000-0700

[rbeckman-nextgen]

No, there has not been any work done on this feature.

Imported Comment. Original Details: Author: dans Created: 2010-08-04T08:47:28.000-0700

[rbeckman-nextgen]

Would be very usefull to have an estimation of the version/date this functionality is expected.

Imported Comment. Original Details: Author: fysicon Created: 2011-01-28T01:45:18.000-0800

[rbeckman-nextgen]

I am still very interested in the new mirth dicom modality worklist feature? Anyone? Any news?

Imported Comment. Original Details: Author: jcarrillo Created: 2012-08-01T19:01:14.000-0700

[rbeckman-nextgen]

FYI - Another customer has requested we consider implementing this in an upcoming version.

Imported Comment. Original Details: Author: alexanderc Created: 2015-11-16T09:35:15.000-0800

[rbeckman-nextgen]

This could be achieved by creating another DICOM listener based on dcm4che2-tool-dcmof.

dcmof supports acting as a DICOM SCP for Modality Worklist (MWL), Modality Performed Procedure Step (MPPS SCP), Image Availability Notification (IAN SCP) and Basic Study Content Notification (SCN SCP).

Most of the infrastructure to support this is already there with MirthDcmRcv, just adapt it to wrap dcmof.

In reality, the current "DICOM Listener" is only a "DICOM Storage Listener".

A more difficult, but cleaner implementation (i.e. then only one DICOM Listener in mirth), would be to refactor MirthDcmRcv to combine both the features of dcm4che dcmrcv and dcmof into a single listener.

Imported Comment. Original Details: Author: mjh_ca Created: 2016-01-30T15:37:19.000-0800

[rbeckman-nextgen]

A rough initial patch to allow existing DICOM listener to support MWL C-FIND is attached. Not super familiar with Mirth internals, so it may require some clean-up, but it should give a Mirth developer an easy starting point to implement this properly.

Essentially - this removes the dcm4che dcmrcv package entirely and replaces with its own implementation using the original dcmrcv code but with a lot of the irrelevant command-line functions removed and added visibility and functions in the class hierarchy to allow you to register multiple types of SCPs (C-STORE, C-FIND, C-ECHO, etc). It is easy to add additional services on top now since you can simply register additional SCPs.

Now the message flow. Incoming C-FIND requests are accepted into the channel and dispatched just like C-STORE. The DICOM listener properties MUST specify a destination (or postprocessor) to provide a response.

This flow provides an opportunity for you to, for example, query an SQL server in the destination based on the tags in the C-FIND request and build up a response which is then passed back to the DICOM Listener and outputted to the DICOM SCU that made the request.

A C-FIND response requires the ability to return multiple DICOM datasets (DicomObjects). Because the existing DICOM datatype supports only a single Dicom Data Set (DicomObject), I took the route of requiring the response in XML so that multiple objects could be returned. Specifying a DICOM datatype as response message type won't work because it will limit you to one DicomObject to be returned (perhaps this can be fixed but it is beyond my proof of concept here).

For example, a destination response could return 2 patient names (note, this is NOT a complete response for a C-FIND, you need more tags, but enough to test successfully with a tool like dcmtk's findscu):

PatientName1 PatientName2

This patch preserves existing StorageSCP capability and has some code fragments to implement Storage Commitment if you wish (but this part is not done). Please test to ensure the behavior of C-STORE has not been affected before applying as this was not my focus here, only to get C-FIND requests into the channel and the ability to respond with multiple Dicom datasets.

Imported Comment. Original Details: Author: mjh_ca Created: 2016-02-02T23:00:25.000-0800

[rbeckman-nextgen]

Nice, thanks! I agree that the default dcmrcv class is not really helpful for Java integrations, since a lot of stuff is private for no reason. Does supporting C-FIND as an SCP constitute a MWL SCP? I thought C-FIND was a separate operation that happens to be used for MWLs. I'm not sure if it would make sense for Mirth Connect to act as a fully-fledged MWL SCP, in the same way that it doesn't act as an FTP server, or a web server, etc.

Imported Comment. Original Details: Author: narupley Created: 2016-02-02T23:33:10.000-0800

[rbeckman-nextgen]

Hi Nick. The patch I supplied only enables C-FIND in the context of an MWL SCP, because it registers the org.dcm4che2.data.UID.ModalityWorklistInformationModelFIND transfer capability with the dcm4che listener.

However, you could rename my MWLSCP class to a more generic CFindSCP class. Add all of the UIDs that end in "FIND" to the UID array in the class (see http://www.dcm4che.org/docs/dcm4che-2.0.22-apidocs/org/dcm4che2/data/UID.html). Then your DICOM listener would support all C-FIND operations.

The user needs to build up a valid response in the destination, depending on the type and contents of C-FIND request dispatched into the channel. Without any response created from the user, Mirth will just respond with an empty dataset. But essentially all forms of C-FIND operations would then be supported. The various forms of C-FIND all ask the server to respond with one or more dicom datasets (DicomObjects in dcm4che) containing different levels of data depending on the request type.

Supporting a broad range of DICOM operations (they are called "DIMSE Services") is a perfect fit for Mirth. The full list is here: http://dicom.nema.org/dicom/2013/output/chtml/part07/sect_7.5.html

DICOM is just all about transferring metadata and file attachments around. With Mirth as intermediary, it gives you the powerful ability to route and manipulate the requests and responses.

To give you a more concrete example for why Mirth is perfect to support a C-FIND SCP (in my case, an MWL C-FIND SCP). We have medical imaging devices (in DICOM speak, "Modalities") that act as an SCU (i.e. client) to request a modality worklist from an SCP (i.e. server). Our clinic software does not support DICOM, but it is backed by SQL, so the patient records and exam schedules are accessible via SQL. By supporting C-FIND in Mirth, I could configure the equipment to connect to Mirth and request an MWL. Then the channel destination connects to the clinic software's SQL server, builds up the appropriate dicom data sets in XML, and Mirth responds to the device with the dataset(s).

In our case it is feeding these devices a list of patients scheduled with exams (a DICOM "study") on that device. The unique IDs passed into the device with the MWL will then be returned by the device when it submits a C-STORE request to store the resulting image, so we can identify who the image belongs to.

Many possibilities...

Imported Comment. Original Details: Author: mjh_ca Created: 2016-02-03T00:35:06.000-0800

[rbeckman-nextgen]

Awesome, thanks this will really help!

Imported Comment. Original Details: Author: narupley Created: 2016-02-03T06:49:01.000-0800

[rbeckman-nextgen]

Hi Marc Thank you for your patch but as I am new to the mirth world could you explain how to implement it ?

Imported Comment. Original Details: Author: xenjibamn Created: 2017-10-26T05:32:44.000-0700