C-MOVE response waiting for C-STORE subcomands completed?


I have a general question how Orthanc handles C-MOVE requests:

C-MOVE triggers C-STORE to send the desired dicom files to the target system.
The target system might or might not be the same system that has triggered the C-MOVE.

Does Orthanc handle it this way?

Thanks in advance

C-MOVE SCP will send pending C-MOVE-RSP to the MOVE SCU while the C-STORE is in progress ( these messages include number of sub-operations completed/failed etc) . When the C-STORE image transfer to the move destination is completed, the MOVE SCP will send a final Success/Failure C-MOVE-Rsp to the MOVE SCU.
You can use Wireshark (and filter DICOM) if you want to watch the message exchange between the SCU and SCP, it’s a good way to understand the flow.

Alexandra Anghelescu
Senior Software Engineer

Varian Medical Systems
3290 Northside Parkway, Suite 500, Atlanta, GA 30327 United States

great - thank you Alexandra for this good explanation!


Actually, the fact that the C-MOVE command ends synchronously with the associated C-STORE commands is purely implementation-specific. For instance, in clinical setups, if long-term archive media is used (such as optical disk or tape), the C-STORE might occur long after the C-MOVE has ended. The fact that a C-MOVE SCU receives a success from the C-MOVE SCP, only indicates that the C-MOVE SCP has properly scheduled the C-STORE commands.

Now, as far as Orthanc is concerned, it is true that by default, the C-STORE commands are done synchronously with the C-MOVE. This explains what Alexandra observes using Wireshark. This behavior is the one expected by many DICOM viewers, which explains this default behavior.

But it is possible to configure Orthanc so that it uses asyncronous operations. This is the purpose of the “SynchronousCMove” configuration option:

Summarizing, the answer to your question: “In Orthanc, does the C-MOVE operation respond not before all C-STORE operations are completed (successful or with error)?”, is: “This depends on the value of the SynchronousCMove option”.

I hope this clarifies things.

Kind Regards,

NB: On a side note, you might be interested by DICOM storage commitment, that is currently under active development:

Thanks Sebastien for this information!
That was the missing piece of information for us (we still use 1.4.2 and it behaves asynch).
We will try it with adding “SynchronousCMove” : true

Works as expected, great!

Just a final question Sebastien:
can you point me to the DICOM standard definition that optionally allows a DICOM C-MOVE either in sync or in async mode?
or is async Orthanc specific and not inline with DICOM standard?


However, I have met in practice hospital PACS infrastructures working in asynchronous mode (which is useful, as written above, to accommodate with long-term archives such as tapes).

This explains why the default value of “SynchronousCMove” is “true” in Orthanc.