We have a client issuing a C-MOVE request to a PACS server. My understanding is that the secondary association will be opened and the C-STORE operations completed prior to the C-MOVE association being closed and a status of success being returned.
With one particular PACS we are receiving the C-MOVE successful completion status after only about have the C-STORE sub-operations have actually occurred. The status of the success message indicates they have all occurred.
(0000,0002) UI =Study Root Query/Retrieve Information Model - MOVE # 28 Affected SOP Class UID 1
(0000,0100) US 32801 # 2 Command Field 1
(0000,0120) US 1 # 2 Message ID Being Responded To 1
(0000,0800) US 257 # 2 Data Set Type 1
(0000,0900) US 0 # 2 Status 1
(0000,0902) LO (no value available) # 0 Error Comment 1
(0000,1020) US (no value available) # 0 Number of Remaining Sub-operations 1
(0000,1021) US 248 # 2 Number of Completed Sub-operations 1
(0000,1022) US 0 # 2 Number of Failed Sub-operations 1
(0000,1023) US 0 # 2 Number of Warning Sub-operations 1
The remaining C-STORE operations do complete, just after we have received this status.
From my understanding of Part 7 of the DICOM standard we should not be receiving a C-MOVE response with a successful status until all the C-STORE sub operations have actually completed. Am I interpreting this correctly and is this PACS not following the standard?
If this is normal, how does the C-MOVE requestor know when the transfer has completed successfully?
The C-MOVE SCP should wait until the C-STORE sub operations are completed before responding with the final C-MOVE-RSP. Although it doesn't explicitly say this in Part 4 of the DICOM Standard, it is implied by statements like this saying the final status is sent after the completion of the sub operations:
"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. This response shall indicate the number of Completed sub-operations, the number of Failed sub-operations, and the number of sub-operations with warning Status."
Perhaps the PACS you're having trouble with has an architecture where it queues up the requests, and perhaps after it ensures that the requests are queued up, it returns, but who knows.
In any case, as to how to determine when everything is done, is the count returned in the number of successful operations correct? You could correlate this count with the number of instances received by the C-STORE-SCP and ensure the count is equal to know when everything really is done. This doesn't work if your C-MOVE destination is a 3rd party server, but if you control the C-MOVE-SCU and the C-STORE-SCP, it should work. Alternately, if your destination C-STORE-SCP also is a C-FIND-SCP, you could query it to check the instance count for the study being moved (ie, check the Number of Study Related Instances tag) to ensure the counts match.