我有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的结合。
答案 0 :(得分:1)
好问题,但没有简单的答案。
期望存储SCU支持C-FIND-SCP,除非您指的是存档服务器/ VNA,否则在实践中不会很好地工作。
MPPS并不是一个坏主意。您需要的所有属性(Study,Series,SOP Instance UID)都是必需的,因此应有效依赖它们。 “应该”,因为我看到供应商违反了这些限制。 但是,您怎么能确定SCU已经收到完整的研究?也许该研究包括CT和MR系列,但SCU向您发送图像仅符合CT并拒绝接收MR。
您可能需要考虑实例可用性通知服务,该服务是另一个服务类,通过该服务类可以向其他系统提供有关“谁拥有哪个图像”的信息。实际上,这将完全满足您的需求,因为您事先知道每个AET(“设备”)哪些图像可用。但是这项服务在实践中并没有得到广泛支持。
即使您确实知道正在向您发送研究的系统上有哪些图像可用 - 您如何确保没有用户坐在其前面,他们刚刚选择了研究的子集发送。
很抱歉,我无法向您提供“真正的解决方案”,但由于我上面提到的原因,我不知道任何支持您所描述的功能(进度条)的真实系统。