PENDING in a C-MOV-RSP

[Max Hrnyak]

I am new to fo-dicom and was wondering when an SCP sends a response to a C-MOVE-REQ with a status of PENDING, the behavior of the SCP is to keep the association open the request was opened on and remain that way until the request is completed with a status of SUCCESS, FAILED, or WARNING correct?  If my understanding is not correct please clarify my understanding...I have looked in the standard and cant seem to find any direction with this status, any help would be appreciated....

[Anders Gustafsson Cureos AB]

Hi Max,

intuitively I would answer Yes to your question. Do you have a scenario where the SCP behaves otherwise?

Regards,

Anders @ Cureos

[Max Hrnyak]

Hi Anders,

Thanks for your response and sorry for the delay in getting back to you...The case is I do a C-FIND and I get two studies in the response, the SCP is including the optional Instance Availability tag and has the values of ONLINE and NEAELINE.  The ONLINE study is retrieved as I would expect but the one with a value of NEARLINE, the SCP sends the C-MOV-RSP with the PENDING then immediately closes the association but then if I do a C_MOVE right after the close for that same study its fine.  In looking at the standard NEARLINE means that the exam has to be retrieved from slow media (tape) which makes sense but the C-MOV connection should remain established as the PENDING status is just letting me know the SCP is getting the study and once it does send the study and provide a status of COMPLETE when done and then close the initial C-MOV connection.  I would like to ask the SCP to not close the connection in this case but want to make sure my understanding is correct before I do as writing code to do a C-MOV_REQ for the study again seems to be redundant.

As always thank you for taking the time in responding to my inquiry.. 

[Anders Gustafsson Cureos AB]

Hi Max,

and sorry for the late response. The scenario that you describe is nothing I have any experience of. I don't know if someone else in the community has?

As far as I know there is no specific support for this scenario in fo-dicom right now, so it is probably safest if you implement your own solution to workaround the issue. If you believe that your implementation could be of general interest to the fo-dicom community, you are more than welcome to post a pull request.

Best regards,

Anders

[Zorian Grey]

Hi.  Does anyone have an update on this topic?  

Some Q/R servers have an option to either:

1. Send C-Move response Success immediately without doing any C-store yet.

or
2.  Send C-Move response Success after C-store has completed.

For the latter,  there should be C-Move Pending status in between each "SOP Instance" in C-Store ,  with number of completed/failed and remaining.

Thanks,
ZG

[Harald Köstinger]

Compare the following topics:

Official in the DICOM group:

https://groups.google.com/forum/#!msg/comp.protocols.dicom/2Icxv2v9TNQ/F9eensWKAAAJ

--> basically saying, that the behavior you describe in bullet 1. is not valid according to DICOM

Orthanc e.g. is not according to the standard, compare this: https://groups.google.com/forum/#!topic/orthanc-users/G3_jBy4X4NQ

[Zorian Grey]

I agree Harald.

Unlike Orthanc, other PACS servers like Conquest and one by LeadTools do #2 (Move=Success  after completing c-store,   and "pending" in between c-stores).

Though I know one VNA by Lexmark that can be configured depending on the group of clients.  They call realtime for #2 (high priority) and batch for #1  (C-Move success before sending/receiving anything).

Some Q/R clients rely on C-Move=Success to determine if no other instance is expected to be received ("number of related instances" is not always reliable).

#1 can be applicable to "pre-fetching".  #2 for "PACS stations" (realtime retrieval).

I'd like to see code sample for #2 because I don't know lower level coding.  I don't know the code behind "IDicomCMoveProvider" that can only send a single batch of responses to a C-Move request and not in between C-stores.

Thanks

ZG

[reini....@aon.at]

Hi Zorian,

the sampe QR SCP server from https://github.com/fo-dicom/fo-dicom-samples/tree/master/Desktop/QueryRetrieve%20SCP should behave like #2. Is that what you are looking for?

Reinhard

[Zorian Grey]

Thanks Reinhard.  I will try it.
Regards,
ZG

[Zorian Grey]

Sorry the code here doesn't work  https://github.com/fo-dicom/fo-dicom-samples/tree/master/Desktop/QueryRetrieve%20SCP 

The counters storeTotal, storeDone, storeFailure are not updated within the DicomClient's SendAsync function.   Either an event has to be added to the DicomClient  (in addition to the only 3 events  Association Rejected, Accepted, Released),  or we have to create our own Send function with Connect, Associate, Send Instances Loop,  Release, Disconnect. 

Thanks,

ZG

[Reinhard Gruber]

I will dig into this. When I wrote the code with version 3.0.2 the counters were updated. Maybe a bug was introduced with version 4.0.

[Zorian Grey]

Thanks.  I also so in other threads the suggestion of doing a DicomClient.Send for each instance,  though it is not efficient  (should only have to associate and release once per batch).