Modality Worklist

[Justin Richter]

Hi,

I am fairly new to working with DICOM so forgive my noobness.  Has anyone used ruby-dicom to connect to and query a modality worklist or receive notifications from a modality using mpps?  Also, where can I find some good info on the DICOM spec?  I keep running into white papers and pdfs that don't help much when googling.

Thanks!

Justin

[Chris]

Hi Justin

ruby-dicom does not as of yet support DICOM Worklist. However, since it already got support for query of patient/study etc., it should be a very small task to create a new worklist query method in DClient. I have not needed this capability yet myself, so I have not implemented it. However I would definitely accept it should anyone want to do it, since I think it would make a very good addition to ruby-dicom.

If you are somewhat familiar with ruby you should be able to do it without to much problems. First have a look at DClient and look at the query methods there. Then you need the network sniffer WireShark, to inspect network communication. Use this on a computer where you have another program which does worklist query. Then you can watch with Wireshark how the network packages are configured, and modify the existing query method of ruby-dicom to reproduce that behaviour. This, I think, is the easiest way to implement it. Alternatively, you can try to read the DICOM standard pdfs, but these documents are extremely verbose and 'bloated' and can be quite difficult to extract useful information from.

The dicom worklist supplement:
ftp://medical.nema.org/medical/dicom/final/sup10_ft.pdf
The dicom standard:
ftp://medical.nema.org/medical/dicom/2009/

If you should succeed with such an implementation, please fork the project at github and send me a pull request.

Best regards,
Chris

[Justin Richter]

I've got a good start on it.  https://github.com/jrichter/ruby-dicom The dicom worklist supplement sucks to read.  I used WireShark, like you suggested, and discovered what the request should look like.  I am not quite there yet.  I need to get some RSpec tests up instead of just changing code and looking at the packet.  When I make a request, the response is larger than a Fixnum for some reason.  Do you think that could be because I don't have group delimiters yet?  ie. (0008,0000)

Justin

[Chris]

Awesome that you've decided to take on this feature!

It seems that the worklist query uses a sequence, which is what is making this difficult..
This is basically a weakness with the current implementation: That we are not able to pass on a nested structure (sequences and items). With the previously implemented query methods it weren't such a big deal, because I think sequences are very rarely used in such queries, but I guess with worklist queries there's no way around it.

I see that you've tried to hack the Link class to accepted a nested hash. Probably, we should try another solution. I think what is likely the best way out of this mess is to change the spec of the query methods to request a DObject as parameter instead of the tag => value hash we have used so far. That will allow the user to encode his query using the DObject class. We will then need to rewrite the find_* methods to work with the DObject, as well as the relevant encoding methods of the Link class.

Could you send a screenshot of a Worklist query captured in Wireshark from an application which sends a proper such query? That would be nice to have.

Best regards,
Chris

[Justin Richter]

That makes sense.  I don't think the decode methods are able to handle sequences yet either.  Correct me if I am wrong.  I have been reading this link, http://www.dabsoft.ch/dicom/5/7.5/, and it seems there are two ways to encode sequences.  I have aquired screenshots which show both ways, I think.  

Screenshot 1 and 2 are my basis for the query I was trying to build.  The query originated from dcm4chee to a Mitra Broker serving the worklist.  I believe dcm4chee is using explicit length in its queries.  Screenshot 3 came from a Toshiba CT.  I don't think it is as strict in its implementation.  I think it is using explicit length as well.  Screenshot 4 and 5 are the first couple responses to the query.  It appears that my worklist is responding with undefined length, using FFFE,E00D to signify the end of the group/sequence/item.  I am not quite sure of the terminology.  Screenshot 6 is from a Fuji CR.  I believe it is using the undefined length syntax as well.  Screenshot 7 and 8 are the responses to that.

Request.raw is the first two screenshots packet.  I think it can be used to test the decode method, but I have been having some trouble with it.

I will look at DObject and familiarize myself with the code.

Justin

[Chris]

Thanks for these images, they should make it easier to get started with worklist query.

At this time I really wish that I had good specs on the network code, which I don't have yet, sadly. I would definitely feel more confident starting on such a rewrite if I had specs to test against.

I dont really think this rewrite is going to be hugely difficult, it's just a matter of reusing existing code by taking advantage of DRead for decoding and DWrite for encoding when handling these network data packages. I will definitely put this on my to-do list, but it's not going to be something that I have a go at immediately. If you are willing to take a closer look at the code and make an attempt, you are of course welcome!

Regards,
Chris