2

I don't think I"m going to get the answer I want but I figured I would ask before giving up with GDCM.

I've built a tool using the GDCM library to do some Query/Retrieve on our local PACS. During testing, everything worked fine, but now that I've deployed it, we have one major issue.

When C-Move is transferring a study (with multiple series) and comes upon a series with a document or a report (IE patient protocol, dose report), it stops transferring any more images, even for the other series in the study. Using Wireshark, I can see that the C-Move requests are being sent, but no C-Store transfers are being sent back in return.

This will continue until the next Study, which will transfer normally until it gets to another series that has a document/report. We didn't catch this during early testing because we were testing on select studies that did not contain reports.

Is there a reason why GDCM doesn't play ball with non-images using C-Move? If I can't overcome this limitation of the library easily, is there a way to ignore series with reports, or series with only 1 image (which is how scout images and reports are stored and neither are necessary for me). Do I need to change the DCMTK library instead for my Q/R tool?

Cheers,

Shensmobile

Shensmobile
  • 21
  • 3
  • The source of your issue is not necessarily GDCM. C-MOVE invokes a C-STORE association with a presentation context negotiation of its own. I suspect that the Service Classes (SOP Class UIDs) are either not proposed by GDCM or not accepted by DCMTK. By default DCMTK's Storage SCP would accept anything, but it depends how you are using / configuring it. – Markus Sabin Aug 17 '18 at 06:45
  • It might not necessarily be a problem with GDCM, I agree; however, other free DICOM viewers like Radiant Viewer are able to C-Move the same entire studies without issue, so I feel like the Storage SCP is capable of handling the transfer of these reports, it's just how GDCM's SCU toolkit is setup. – Shensmobile Aug 17 '18 at 14:38

1 Answers1

1

Well to begin with:

  • Your question needs some more information. I will still try to answer with obvious reasons.
  • I never used GDCM. I will answer in context of DICOM.

GDCM is: QR SCU and CStore SCP.
PACS is: QR SCP and CStore SCU.

If above is reverse, it does not change the answer much, just reverse the roles.

I do not think problem is with your PACS or GDCM. I think the problem is while Association part of MOVE request.

Your CStore SCP does not support those SOP class because:

  • Simply, it does not support those at all.
    May be you need to configure it to add the support. I do not know what to do here. I neither know GDCM nor your PACS. You need to figure this out yourself.
  • Those are not proposed by SCU at all.
    Configure your SCU to propose those classes.
  • Those are proposed by SCU but not accepted by SCP.
    Check why SCP is rejecting those classes in Associate Response. I strongly suspect this is the problem. Most probably, your CStore SCP is not configured to accept instances with those SOP classes.
  • Those are accepted by SCP but on CStore Request, instances are being rejected for some reason.
    Why, I do not know. You may need to check your logs and configurations.

Please understand that most of the problems in DICOM network communication lies in Association part. Focus your debugging there.

What I can say for sure is that, this problem is not related to C-Find or C-Move Requests/Responses. This problem is related to C-Store operation and its Association part.

Please read following excellent articles from Roni:

http://dicomiseasy.blogspot.com/2012/01/dicom-queryretrieve-part-i.html
http://dicomiseasy.blogspot.com/2012/02/c-move.html

Using Wireshark, I can see that the C-Move requests are being sent, but no C-Store transfers are being sent back in return.

Assuming your are moving a Study, MOVE request is sent once to initiate MOVE operation. Then, MOVE SCP will become CStore SCU and will initiate another Association with CStore SCP. CStore SCP can be different from original MOVE SCU; but I do not think this is the case in your scenario. Then for each (optionally; do not rely on this. Read Roni's articles mentioned below) CStore operation, MOVE response is communicated. You did not mention about MOVE responses in your question.

Is there a reason why GDCM doesn't play ball with non-images using C-Move?

I do not think this is about "non-image" as mentioned above; but cannot bypass this possibility all together. May be that CStore SCP is accepting those SOP classes (incorrectly, even though it does not support those) but reject the instances for some reason (may be non-image instance) while C-Store. You need to check logs and configurations of your CStore SCP here.

If I can't overcome this limitation of the library easily, is there a way to ignore series with reports, or series with only 1 image

You may choose to bypass the Study level retrieve/MOVE and try Series level retrieve. To do this, you first need to fetch list (C-Find) of SeriesInstanceUIDs for that Study. Then MOVE each series independently. In C-Find response, you also get other attributes like image count where you can put your filters for further MOVE operation.

Do I need to change the DCMTK library instead for my Q/R tool?

As I said above, I do not think this problem is with library.

Amit Joshi
  • 15,448
  • 21
  • 77
  • 141
  • Good answer. The Storage SCP is based on DCMTK as far as I understand. With the implementations provided by OFFIS, it would accept any known kind of "official DICOM object". – Markus Sabin Aug 17 '18 at 10:52
  • Thank you for all the help. I am going to manually try to C-Move instances of reports to see what the association response is. I figure that it is more to do with my usage of GDCM rather than the problem being on the PACS end with the QR SCP. Is there a reason why hitting a series with a report would cause subsequent series to fail transferring? I thought of trying a Series level retrieve, and using some logic in my code to filter out single-image series, but my PACS does not support Series retrieve, along with a multitude of Tags that aren't supported in C-Find. – Shensmobile Aug 17 '18 at 14:46
  • So unfortunately my PACS does not allow C-Move for SOP Instance UIDs either. The only way I am able to see an associate response is by filtering through the log when doing C-Move on a study with a report, which I am looking at now. Hopefully I can find something that indicates what's happening when I try to retrieve the report. – Shensmobile Aug 17 '18 at 17:44