C-Move response: no pending status

[harald.k...@gmail.com]

Hello

I just did perform a C-MOVE on the Orthanc PACS and realized, that right after requesting the C-MOVE I get the C-MOVE-Response in with status=Success and 1 Completed sub-operation. 

And only right after this, the PACS starts to actually perform the C-STORE actions on my SCP.

According to the standard, this does not seem to be correct, right?

Compare: http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.4.2.3.html

It says:

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. 

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

Also compare

https://stackoverflow.com/questions/19547885/should-a-c-move-success-message-only-be-received-after-the-associated-c-store-co

http://dicomiseasy.blogspot.com/2012/02/c-move.html

What should I do to actually correctly handle the C-MOVE then?

How would I know, when the last C-Store was received?

I do not get any number of remaining items nor the success message at the right time.

Cheers,

Harald

[harald.k...@gmail.com]

To add something more here:

I tried with Dicoogle PACS and the open PACS from DicomserverUK as well as a Phoenix PACS.

All those send the success in the end, which means, according to the standard, I could rely on the incoming success message and then know, that all C-Stores went through and I received the last instance.

[Sébastien Jodogne]

Hello,

This asynchronous sending of DICOM files as implemented in Orthanc can also be seen in commercial PACS systems. The DICOM SCP only says that it has successfully received all the transfer requests, but the transfers themselves can be delayed.

If this behavior is problematic to you, just set the "SynchronousCMove" configuration option of Orthanc to "true":

http://book.orthanc-server.com/users/configuration.html

Sébastien-

[Harald Köstinger]

Hello,

The thing with that behavior is, that it is not according to the standard, right?

Even though other PACS may implement it that way, it is not correct.

The C-MOVE response actually shall help the requesting party to:

• see when the TARGET AE finally received all files
• maybe have some "pending" status updates in the meantime to display a progress bar or the like

In the current implementation, the C-MOVE response itself is rather useless. 

The requesting party would never know, if the C-MOVE to the TARGET AE actually was successful or not.

It would just know, if the SCP understood the C-MOVE request, but nothing more.

Harald

[Sébastien Jodogne]

Hello,

As this is a question about the DICOM standard on which I cannot decide by myself, I highly suggest you to ask the question on the dedicated forum:

https://groups.google.com/forum/#!forum/comp.protocols.dicom

I'll happily revert the default behavior of Orthanc to "SynchronousCMove" be defined as "true" (which was the case for Orthanc <= 1.3.2), if DICOM experts say so.

Regards,

Sébastien-

[Harald Köstinger]

Hello,

I now did post this question in the DICOM group:

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

Cheers,

Harald

[Harald Köstinger]

There is now some reply to my question.

https://groups.google.com/d/msg/comp.protocols.dicom/2Icxv2v9TNQ/F9eensWKAAAJ

Seems, that my expected behavior is the correct one, according to the standard.

Which would mean, that Orthanc is not behaving according to the standard, when you do configure async handling of C-MOVE RQs.

[Sébastien Jodogne]

OK, so here's my answer on the DICOM forum:

"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-"

[kozu...@gmail.com]

Hi,

One related thing I've had on my mind for some time and wanted to ask: is there an asynchronous way to retrieve imaging from remote modality via HTTP. Currently the POST to:

/queries/{id}/retrieve

blocks until the operation is completed in Orthanc. If there is a lot of data to fetch from the remote modality this can take minutes and the connection might timeout on the client (which one can usually configure), but also on an intermediate HTTP proxy (which one might not). Then there's no way to tell when the operation completed.

Depending on the architecture of the HTTP client used to talk to Orthanc this potentially blocks a client thread for the entire period.

Thanks for any insights,

Ales

[Sébastien Jodogne]

Hello,

You can set the "Synchronous" option to "false" while initiating a C-MOVE operation from the REST API. This will create a job and the HTTP request will end immediately. For instance:

# curl http://localhost:8042/queries/7e599bad-270e-4d7b-9ea4-f0bbaa00c134/retrieve -d '{"TargetAet":"PACS","Synchronous":false}'

{

   "ID" : "a67b1332-7cbe-4f02-a51b-6f0b96935a0f",

   "Path" : "/jobs/a67b1332-7cbe-4f02-a51b-6f0b96935a0f"

}

HTH,

Sébastien-

[kozu...@gmail.com]

Hi Sebastien,

thanks for the hint, I tested this today but for some reason am unable to pass a JSON object as the payload. I tried:

curl -d '{"TargetAet":"MY-AET","Synchronous":false}' 'https://myorthanc/queries/ee7eac32-877d-43db-9278-c6772c8ec073/retrieve'

whereby Orthanc logs:

W1120 15:28:09.572323 OrthancRestModalities.cpp:540] Driving C-Move SCU on modality: {"TargetAet":"MY-AET","Synchronous":false}

Note that it considers the entire POST payload as AET. Then this works of course but is synchronous:

curl -d 'MY-AET' 'https://myorthanc/queries/d5340dd0-2d99-4aae-8796-79966a44afed/retrieve

Orthanc version we use is 1.4.1. Where am I doing wrong?

Thanks,

Ales

[Sébastien Jodogne]

Sorry, this feature is visibly only available in the Orthanc mainline currently.

You'll have to wait until forthcoming 1.4.3 release, to build Orthanc from source, or to use nightly builds of the mainline.

Here is for instance the link to the nightly debug LSB (Linux Standard Base) binaries:

http://lsb.orthanc-server.com/orthanc/mainline/

The Docker image "jodogne/orthanc" can also be pulled to use the mainline version:

http://book.orthanc-server.com/users/docker.html#running-the-orthanc-core

Sébastien-

[Felix Nensa]

Dear Sébastien,

 

is this {"TargetAet":"MY-AET","Synchronous":false} syntax available for the “/modalities/{dicom}/move” API as well?

 

Thanks,

Felix

[kozu...@gmail.com]

> You'll have to wait until forthcoming 1.4.3 release, to build Orthanc from source, or to use nightly builds of the mainline.

Hi Sebastien,

thanks for clarifying. We're upgrade to the new version when it's out to use the async retrievals.

Best regards,

Ales

[Sébastien Jodogne]

Hello,

Driving a C-MOVE on a remote modality is only available in synchronous mode. Here is a sample call:

# curl http://localhost:8042/modalities/pacs/move -X POST -d '{"Resources":[{"StudyInstanceUID":"1.3.51.0.1.1.192.168.29.133.1681753681732"}],"TargetAet":"STORESCP","Level":"Study"}'

Sébastien-