DICOM's role in the internet world and new release of RZDCX

There's an event held in Israel every year in Hadasa Ein-Karem hospital called IsraPACS. Diego Gicovate is doing a great job organizing it. This year I was invited to say couple of words and decided to ask the question "Where DICOM is going?" What it's role today with all the Internet and cloud technology.

Old lady knitting next to a Renault 4 car
Source: Unknown
(Please contact if you know this picture and or where it came from)

Usually, when I give presentations on DICOM, the introduction, the couple of slides in the beginning,  goes like this: "DICOM is very old, It's very big, It's a bit complicated, but hey, its working!" I have this slide (above) of an old lady sitting outside on a chair and knitting with a Renault 4 in the background. Then I review the parts of the standard, noting that, printed, it probably weighs something like 10 Kilo's and joking that I've read almost all of its 3 - 4 thousand pages. At the end  I show a slide with the poster of Monty Piton's film "The meaning of life" and replace it with the meaning of DICOM and then a slide saying, but hey, 1 standard, 1,000's of vendors 1,000,000's of patients, 1,000,000,000's of images, it can't be so bad, look, its working!
This presentation didn't change much since I first gave it in the early 2000's. It's still in Power Point, DICOM is pretty much the same but the world has changed.

DICOM is here to stay. It does a great job as a file format and a common data model for all Medical Imaging Modalities and it made the commoditization of medical imaging possible. But beyond the medical imaging production floor, i.e. for transferring the images from the imaging device to the PACS, DICOM's role is in question. Once in the PACS, DICOM looses to modern internet technology and in light of the huge evolvement of the internet, file sharing services and cloud computing, browsers, JavaScript, html5, the one part of the DICOM standard that may still be relevant after the point where the images are in the PACS is chapter 18 - WADO.

For most vendors, with knowledge in internet technologies, it would probably be much easier to integrate using WADO then using the DICOM Network Protocol. By having a standard of how to map DICOM data elements to XML and JSON and standardizing http requests to access DICOM objects WADO is just great.

A DICOM file is just like any other file. It can be transferred using for example Google Drive, Dropbox and the like. Just remember that you have to use encryption so you don't risk in exposing patient private healthcare information (PHI).

When using file sharing or email 7-zip for example, the free archiving software,  lets you encrypt files with a password using AES-256 which is similar to the security level you'll get when using secure DICOM protocol. And if talking about security and privacy, remember that your system logs may also include PHI as they can have dumps of received and sent objects so when you share logs with your technical support, make sure you transfer it securely, again encrypted password protected 7zip may just do the trick for you.

RZDCX 2.0.5.0 

Most of the work done in this release is related to timeouts. We've added two properties to DCXREQ and DCXACC to control the Association Request timeout and the DIMSE command timeout. Most users won't need to use them but sometimes there may be a need for them. If not used, both timeouts are defaulted to DCXAPP's connection timeout.

The association request timeout (ARTM) controls how long we wait for the peer application to answr the association request (and release).
The DIMSE command timeout controls how long we wait for the peer to respond to a command (e.g. C-ECHO).

The following sequence diagram may explain this better

You can set these timeouts for the requester or accepter after they are created and they affect only that instance. Here's a little code snippet that sets the DIMSE command timeout before sending a query:

private void DoQuery(int t)

        {

            DCXREQ req = new DCXREQ();

            req.DimseCommandTimeout = t;

            DCXOBJ identifier = new DCXOBJ();

            DCXELM e = new DCXELM();

            e.Init((int)DICOM_TAGS_ENUM.QueryRetrieveLevel);

            e.Value = "STUDY";

            identifier.insertElement(e);

            e.Init((int)DICOM_TAGS_ENUM.patientName);

            e.Value = "ABC";

            identifier.insertElement(e);

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

            identifier.insertElement(e);

            req.Query(MyAETitle, MyAETitle, MyIPAddress, MyAccepter_port,

                "1.2.840.10008.5.1.4.1.2.1.1",  identifier);

        }

If the peer doesn't respond within t seconds you will get an error and DCXEQ.Query will throw an exception and the description will be DIMSE Timeout.

One scenario that these may be used is for example for connecting to a PACS to takes its time to serve C-FIND requests. You don't want the user to wait to long when sending an echo but you have to give more time for the query to perform. In such case you should set the DIMSE Command Timeout just before sending the Query to a bigger value.