How to dump DICOM Modality Worklist messages?

[squid...@gmail.com]

There are many utilities that can do a "DICOM header dump," i.e.
display the text data bound to an image in a DICOM image+text file. I'm
looking for a utility that can dump the contents of a modality worklist
message in human-readable form.

We have a PACS that doesn't do auto-routing. Our breast center needs to
have its patients' priors auto-routed. There is a company that makes
hang-on-the-side boxes for our brand of PACS that are supposed to add
auto-routing functionality. It depends on modality worklist to do this.
It queries to obtain the same worklist information that is being sent
to the mammo imaging rooms. When it sees a new mammogram order it looks
for the value in DICOM field 0040,0002 (Scheduled Procedure Step Start
Date). If the date is today, it extracts the patient's MR number from
the message and goes hunting for prior MG studies for that patient. If
it fines any, it issues a third-party C-MOVE directing the PACS to
transmit the prior exam to the mammo reading stations.

It's not working, and the vendor's theory is that field 0040,0002 is
not being populated in the worklist messages our PACS provides.
0040,0002 is what their software keys on to determine that a new MG
order is scheduled for today, and if it doesn't find it, it concludes
that it has nothing to do. So I need to locate a way to examine the
worklist messages and either prove that 0040,0002 is there and
correctly filled in, or else determine that it actually isn't there or
is incorrectly filled in, and then figure out why and what to do about
it.

How do you capture and dump responses to modality worklist queries? Has
anybody ever seen a utility that can query for worklist and then
display the message it got back in human-readable form? (Or any form,
for that matter; I can read hex or binary if I have to.) Do I have any
alternative to running a sniffer on the transaction and grovelling
through Ethereal packet captures?

Thanks very much for any pointers or suggestions!

James P. H. Fuller
PACS admin
Athens Regional Medical Center

[Peter B Schmidt]

Hello James,

well, I think the only way to look inside the Worklist Queries and
Responses is to use a network sniffer, such as wireshark (formerly
ethereal). wireshark and ethereal are DICOM aware and can already show
interpreted data element views of the TCP Packets that came across the wire.

wireshark is Open Source Software, you can learn more at

http://www.wireshark.org/

There are other implementations, such as Packetyzer (based on wireshark
technology with a nice native Frontend for Windows only) and commercial
sniffers, so choose the one you (or maybe your IT staff) like best.

You will need a Network Hub (not switch!) and a wireshark computer
(preferably a laptop) - and an IT Administrator that will have to allow
sniffing the traffic, as this is a highly security relevant issue (you
can see Patient Data and maybe even authentication data that may be not
intended for you to see).

Before you start to sniff, please filter the traffic to the boxes
involved (by only capturing packets with the respective IP Addresses),
this limits the security problem a little.

An alternative could be contacting the manufacturers involved, whether
their systems can be configured to log the DICOM messages - many devices
have this feature - but of course, you will maybe not get a really
independent analysis from that, if the device logging mechanism does
also ignore the tags the device does not process...

I will not explain the whole process here as this might be too
comprehensive, but please let me know if you really want to get into
network sniffing, I will provide more information on your demand.

HTH,

Peter

[Geert Vandenbussche]

James,

With Wireshark you will be able to analyse this, using the built-in
DICOM dissector. It is just a matter of browsing through the packets.

Another possibility is the use of the DICOM Network Sniffer and
Analyzer, which can be found on:
http://www.dvtk.org/modules/wiwimod/index.php?page=page4
I didn't have much time to play with it yet, but it looks very promising.
This application is also opensource.

Best regards,

Geert Vandenbussche

[Laurent Lecomte]

Hi,

You can also try : http://sourceforge.net/project/showfiles.php?group_id=166667
==> dicom4j-tools-0.0.1.zip.

You will find a basic WorklistSCU. Playing with log4j.properties, you can
see DataSet retrieved from the Worklist SCP.

I you have remarks there welcom

Regards

[David Clunie]

Just for completeness, since James asked this same question
on Aunt Minnie and pacsadmin, here is the same response as
I posted there ...

The OFFIS dcmtk findscu utility should be just what you
need - it allows you to specify the modality worklist
sop class and query model as a command line argument (-W)
and specify values for various matching and return keys
either on the command line (-k) or in a DICOM "file".

See "http://dicom.offis.de/dcmtk.php.en".

This is probably easier than sniffing the tcp/ip connection
between the products and trying to interpret the packets
as DICOM messages.

David

[lui...@hotmail.com]

On Jan 5, 11:24 am, David Clunie <dclu...@dclunie.com> wrote:
> [...]

> The OFFIS dcmtk findscu utility should be just what you
> need - it allows you to specify the modality worklist
> sop class and query model as a command line argument (-W)
> and specify values for various matching and return keys
> either on the command line (-k) or in a DICOM "file".
>
> See "http://dicom.offis.de/dcmtk.php.en".
>
> This is probably easier than sniffing the tcp/ip connection
> between the products and trying to interpret the packets
> as DICOM messages.

Simulating or sniffing it are slightly different things. In the sense
that the C-FIND-RSP's messages depend both on the behaviour of the MWL
SCP _and_ the contents of the C-FIND-RQ's. With a sniffer you can see
both the query and the responses, otherwise the doubt could remain
about the fact that something in the responses is wrong because the
query is not correct, or some attribute is not queried at all.

I normally use Ethereal and MergeDPM: no need to save the C-FIND
messages from MergeDPM and to see them with a DICOM dumper, because
MergeDPM can directly do that. In fact Ethereal/Wireshark has some
DICOM dumping capability, but I never used it, having my licensed
MergeDPM copy, perhaps it could be enough.

Having a MWL SCU simulator, as David succested, is very useful, anyway:
when studying the behaviour of a given RIS or PACS, it allows you to
change the query with so much more freedom than the modality interface
normally allows you.

Of course, the same things we wrote about MWL also apply to Q/R.

Regards.

Luigi Pampana-Biancheri
luigi....@REMOVETHIS.esaote.com