只有在關聯的C-STORE完成後才能收到C-MOVE成功消息？

Question

我們有一個客戶端向PACS服務器發出C-MOVE請求。我的理解是，在C-MOVE關聯關閉之前，輔助關聯將被打開並完成C-STORE操作，並返回成功狀態。

對於一臺特定的PACS，我們在實際發生C-STORE子操作後纔會收到C-MOVE成功完成狀態。成功消息的狀態表明它們都發生了。

(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 

在我們收到這個狀態後，剩下的C-STORE操作就完成了。

根據我對DICOM標準第7部分的理解，我們不應該收到一個C-MOVE響應，並且狀態爲成功，直到所有C-STORE子操作實際完成。我是否正確解釋並且這PACS是否不遵守標準？

如果這是正常的，C-MOVE請求者如何知道傳輸何時成功完成？

Answer 1

C-MOVE SCP應該等到C-STORE子操作完成後再回復最終的C-MOVE-RSP。雖然沒有明確說這在DICOM標準的第四部分，它是由下面的語句說的最終狀態完成子操作之後被送到暗示：

PS 3.4, C.4.2.3.1

「當數剩餘子操作的數量達到零時，SCP應生成狀態等於成功，警告，失敗或拒絕的最終響應，該響應應指出已完成的子操作的數量，失敗的子操作的數量，以及具有警告狀態的子操作的數量「。

也許您遇到麻煩的PACS具有排隊請求的體系結構，也可能在確保請求排隊後返回，但是誰知道。

在任何情況下，至於如何確定什麼時候一切都完成了，成功操作數返回的計數是否正確？您可以將此計數與C-STORE-SCP收到的實例數關聯起來，並確保計數等於知道什麼時候一切確實完成。如果您的C-MOVE目的地是第三方服務器，這不起作用，但如果您控制C-MOVE-SCU和C-STORE-SCP，它應該可以工作。或者，如果您的目的地C-STORE-SCP也是C-FIND-SCP，則可以查詢它以檢查正在移動的研究的實例計數（即，檢查研究相關實例的數量標記）以確保計數匹配。