C-MOVE behavior: when to expect the C-MOVE RSP SUCCESS

[Harald Köstinger]

Hello

After working with some different PACS implementations and performing C-MOVE operations there, I realized, that quite many of them show different behavior when it comes to the C-MOVE RSP "SUCCESS".

When I request a C-MOVE on a PACS to a certain TARGET AE, I would expect, that the PACS notifies me about the C-MOVE progress using "PENDING" messages and about the final "SUCCESS", when the move from PACS to TARGET was done, right?

According to the standard, pending responses are not mandatory, but so is the final message:

"When the number of Remaining sub-operations reaches zero, the SCP shall generate a final response with a status equal to Success, Warning, Failure, or Refused."
Compare: http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.4.2.3.html

According to this, only when the last sub-op was sent over, I get the success response, right?

How should I (as requester) otherwise possibly know and notice, that the PACS finished the MOVE to the TARGET AE?

What is the opinion of experts on this?

Thank you in advance!
Harald

PS: the post in e.g. the Orthanc group related to this topic:
https://groups.google.com/forum/#!topic/orthanc-users/G3_jBy4X4NQ

[c.w.c...@gmail.com]

Your analysis looks ok, so what behaviour did you encounter?

[Harald Köstinger]

On Wednesday, November 14, 2018 at 1:48:20 PM UTC+1, c.w.c...@gmail.com wrote:
> Your analysis looks ok, so what behaviour did you encounter?

For e.g. Orthanc (which is an open source implementation, I know), I found out, that right after the C-MOVE RQ I get the C-MOVE RSP from the SCP saying "SUCCESS" with no information about the completed sub-operations etc.

Right after that, I start getting the actual C-STOREs from the PACS.

But that means, that I end up, not knowing when to end listening for incoming C-STORE RQs, as I do not have a number of items to move nor do I get the SUCCESS message at the correct time.

[Sébastien Jodogne]

Hello,

I write as the author of Orthanc.

As the consensus on this forum seems to be to use "synchronous" C-STORE together with C-MOVE sub-operations, the default behavior of Orthanc was adapted accordingly by the following changeset:
https://bitbucket.org/sjodogne/orthanc/commits/00504dcc996f09a843d9f5782e9e4250c3326b22

This changeset is pending in our mainline, and will be part of forthcoming 1.4.3 release. Note that "synchronous C-Move" was the default behavior of Orthanc <= 1.3.2.

Regards,
Sébastien-

[David Clunie]

Just to be clear, as I read it, the standard expects that the C-MOVE responses reflect what was reported by the C-STORE sub-operations.

This is obviously especially important when the C-MOVE SCU is not the C-STORE SCP (i.e., has requested a move to somewhere else than itself).

To achieve this, the standard does not require that C-STORE sub-operations be implemented synchronously (whether that be the common use of the term to mean on separate threads/processes +/- multiple associations, or by reference to DICOM asynchronous operations).

E.g., a C-MOVE control thread can monitor the behavior of all the C-STORE threads it spawns and report accordingly, thus gaining the potential performance benefits without compromising the integrity of the status reports on which the C-MOVE SCU should be able to rely.

I.e., do not assume that the standard (as opposed to particular implementations) imposes a performance restriction to achieve this particular integrity goal.

David