I recently had the questionable pleasure of writing a DICOM Q/R-module, for communication with a PACS. A future post may be dedicated to letting some steam out, and listing in detail the reasons I consider DICOM to be the worst standard I came across – but this post is meant only to give one (hopefully) substantial development tip, for fellow DICOM warriors.

Suppose, for example, the functionality you’re debugging is querying a PACS for the list of imaging studies performed on a particular patient.

First, get your hands on some DICOM utility that does the work you’re trying to do (IDoImaging had tons of these.). I used JDicom and will refer to it below for brevity, but really, any will do.

Medical Connections, makers of DicomObjects, give away free access to a custom DICOM server specifically designated as ‘A public resource for all DICOM developers to use for testing’. It supports all Query/retrieve service class commands. It accepts any AE title, and responds to the sending AE. As of this writing, its URL is http://www.dicomserver.co.uk and its IP is 87.106.65.167 – but check the link, as it had changed only recently.

What’s so useful about the Med-Conn server is that it dumps a very, very detailed log of all activity – down to every single DICOM element, in every message, in every association it handles.  Partial dump sample:

14:01:15 (8941) IN  Command = 30
14:01:15 (8941) IN  SOP Class = 1.2.840.10008.1.1
14:01:15 (8941) IN  Verification request Received
14:01:15 (0) in main Send Verify Received
14:01:15 (8941) OUT  (0000,0000) 0004 UL 66 (0x42)
14:01:15 (8941) OUT  (0000,0002) 0012 UI 1.2.840.10008.1.1
14:01:15 (8941) OUT  (0000,0100) 0002 US 32816 (0x8030)
14:01:15 (8941) OUT  (0000,0120) 0002 US 1 (0x1)
14:01:15 (8941) OUT  (0000,0800) 0002 US 257 (0x101)
14:01:15 (8941) OUT  (0000,0900) 0002 US 0 (0x0)
14:01:38 (8941) IN   (0000,0000) 0004 UL 56 (0x38)
14:01:38 (8941) IN   (0000,0002) 0012 UI 1.2.840.10008.1.1
14:01:38 (8941) IN   (0000,0100) 0002 US 48 (0x30)
14:01:38 (8941) IN   (0000,0110) 0002 US 2 (0x2)
14:01:38 (8941) IN   (0000,0800) 0002 US 257 (0x101)
14:01:38 (8941) IN  Command = 30
14:01:38 (8941) IN  SOP Class = 1.2.840.10008.1.1
14:01:38 (8941) IN  Verification request Received
14:01:38 (0) in main Send Verify Received
14:01:38 (8941) OUT  (0000,0000) 0004 UL 66 (0x42)
14:01:38 (8941) OUT  (0000,0002) 0012 UI 1.2.840.10008.1.1
14:01:38 (8941) OUT  (0000,0100) 0002 US 32816 (0x8030)
14:01:38 (8941) OUT  (0000,0120) 0002 US 2 (0x2)
14:01:38 (8941) OUT  (0000,0800) 0002 US 257 (0x101)
14:01:38 (8941) OUT  (0000,0900) 0002 US 0 (0x0)

Quoting the Medical-Connections page:

The live log files are available at the following URL :

http://dicomserver.co.uk/logs

Note that the log files may contain a mixture of your own and other users’ activity, but they restart every hour in order to keep the size manageable.

– but do check back the original link, to validate the logs address.

Next – hook up both JDicom and your own software to communicate with the Med-Conn server. Take a first pass with JDicom – either upload your own sample study (make sure you anonymize!), or query the UIDs of some patients & studies lying around there.

Just before you start, save a copy of the current log. Perform the desired transaction using JDicom (i.e., the tool that works). Update the log page and save a 2nd copy. Now, diff the two logs (image below is illustrating Araxis usage). The difference you are seeing is nothing less than a complete trace of a correct form of the transaction you’re trying to perform.

Lastly, repeat the process with your own software in place of JDicom (i.e., use the tool that needs fixing). You end up with a complete trace of the transaction YOU are invoking.

Diff these two!

Some of the differences you’ll spot are supposed to be there (e.g., various association UIDs) – but after a minute or so of noise cleanup, the important difference (a.k.a, the bug) would easily jump into view.

Enjoy!