DICOM C-StoreSCP:如何预先知道SCU将发送的图像数量?

时间:2016-07-08 08:10:50

标签: dicom

我有DICOM C-StoreSCP应用程序,它从我的其他C-StoreSCU应用程序接收DICOM图像。我的SCU总是在一个关联上发送一个(并且只有一个)并完成(来自给定研究的所有图像)研究。所以SCP总是知道从SCU收到的所有图像都属于单一研究。我知道我也可以查看StudyIUID;但这不是我感兴趣的地方。

我想知道正在转移的研究中的图像总数。使用这些数据,我想在屏幕上显示“收到3张图片中的3张......”等状态。我可以统计收到的图像(在这种情况下为3),但是如何知道正在传输的给定研究中的图像总数(本例中为10)?

解决方法:

在收到SCP的第一个C-Store请求后,我应该阅读StudyIUID并与SCU建立新的关联(SCU也应支持Q \ R SCP在这种情况下的能力),以获得Q \ R并获得研究中的图像总数使用C-Find。

限制: -

  • SCU还应支持Q \ R SCP功能。

  • SCU应强制在C-Find响应中发送图像计数。

  • SCU应该始终只在一次研究中发送一次研究的所有图像。

如果我自己编写SCU(具有Q \ R SCP功能),我可以轻松克服这些限制。但是我的SCP还会收到第三方SCU的图像,这些图像可能没有实现必要的功能。

请建议是否有任何与DICOM兼容的解决方案?

使用MPPS可以吗?我还没有参加过DICOM的MPPS部分。

结论: -

接受的答案(kritzel_sw)表明非常好的解决方案(使用MPPS)只有一个缺点。 MPPS不是每个SCU的强制服务。 MPPS仅适用于那些实际获取图像的SCU,即模态。即便不是所有模式都支持开箱即用的MPPS;他们需要通过额外的许可证成本和配置来解锁功能。此外,还有很多场景将模式推送到某个中间工作站,工作站进一步将其推送到SCP。

可能,我需要研究DICOM + NON_DICOM的结合。

1 个答案:

答案 0 :(得分:1)

好问题,但没有简单的答案。

期望存储SCU支持C-FIND-SCP,除非您指的是存档服务器/ VNA,否则在实践中不会很好地工作。

MPPS并不是一个坏主意。您需要的所有属性(Study,Series,SOP Instance UID)都是必需的,因此有效依赖它们。 “应该”,因为我看到供应商违反了这些限制。 但是,您怎么能确定SCU已经收到完整的研究?也许该研究包括CT和MR系列,但SCU向您发送图像仅符合CT并拒绝接收MR。

您可能需要考虑实例可用性通知服务,该服务是另一个服务类,通过该服务类可以向其他系统提供有关“谁拥有哪个图像”的信息。实际上,这将完全满足您的需求,因为您事先知道每个AET(“设备”)哪些图像可用。但是这项服务在实践中并没有得到广泛支持。

即使您确实知道正在向您发送研究的系统上有哪些图像可用 - 您如何确保没有用户坐在其前面,他们刚刚选择了研究的子集发送。

很抱歉,我无法向您提供“真正的解决方案”,但由于我上面提到的原因,我不知道任何支持您所描述的功能(进度条)的真实系统。