How to dump DICOM Modality Worklist messages? - DICOM

This is a discussion on How to dump DICOM Modality Worklist messages? - DICOM ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: How to dump DICOM Modality Worklist messages?

  1. How to dump DICOM Modality Worklist messages?

    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


  2. Re: How to dump DICOM Modality Worklist messages?

    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

  3. Re: How to dump DICOM Modality Worklist messages?

    squidsushi@gmail.com wrote:
    > 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
    >

    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/...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

  4. Re: How to dump DICOM Modality Worklist messages?

    Hi,

    You can also try : http://sourceforge.net/project/showf...roup_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



  5. Re: How to dump DICOM Modality Worklist messages?

    Hi James.

    I frequently make dumps of WLM queries in the following way:
    -1- Sniff the RIS query using e.g. Wireshark (Ethereal)
    -2- Load the resulting capture file in the DPM program from Merge
    -3- Select the C-FIND-RQ and save it to DICOM file
    -4- Select one or more C-FIND-RSP and save these to DICOM file(s)
    -5- Load the resulting DICOM files in a "DICOM dumper". I use DICOMEye
    to this purpose, but there are numerous other programs.
    -6- Works perfectly.

    All the best from Eindhoven.
    Ome Kees


    On 4 Jan 2007 09:13:13 -0800, squidsushi@gmail.com wrote:

    >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


  6. Re: How to dump DICOM Modality Worklist messages?

    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

    squidsushi@gmail.com wrote:
    > 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
    >


  7. Re: How to dump DICOM Modality Worklist messages?

    On Jan 5, 11:24 am, David Clunie 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.pampana@REMOVETHIS.esaote.com


+ Reply to Thread