4

我们有一个客户端向 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-STORE 子操作实际完成之前，我们不应该收到具有成功状态的 C-MOVE 响应。我是否正确解释了这一点，这个 PACS 是否不符合标准？

如果这是正常的，C-MOVE 请求者如何知道传输成功完成的时间？

4

1 回答 1

6

C-MOVE SCP 应该等到 C-STORE 子操作完成后才以最终的 C-MOVE-RSP 响应。尽管在 DICOM 标准的第 4 部分中没有明确说明这一点，但类似这样的语句暗示了最终状态是在子操作完成后发送的：

PS 3.4，C.4.2.3.1

“当 Remaining 子操作数达到零时，SCP 应生成状态等于 Success、Warning、Failure 或 Refused 的最终响应。该响应应指示 Completed 子操作数、Failed 子操作数-操作，以及带有警告状态的子操作的数量。”

也许您遇到问题的 PACS 有一个体系结构，它将请求排队，也许在确保请求排队之后，它会返回，但谁知道呢。

无论如何，至于如何确定一切都完成了，成功操作数中返回的计数是否正确？您可以将此计数与 C-STORE-SCP 接收到的实例数相关联，并确保计数等于知道一切何时真正完成。如果您的 C-MOVE 目标是第 3 方服务器，这不起作用，但如果您控制 C-MOVE-SCU 和 C-STORE-SCP，它应该可以工作。或者，如果您的目标 C-STORE-SCP 也是 C-FIND-SCP，您可以查询它以检查正在移动的研究的实例计数（即检查与研究相关的实例标签的数量）以确保计数匹配.

于 2013-10-23T20:22:09.460 回答