我有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（“设备”）哪些图像可用。但是这项服务在实践中并没有得到广泛支持。
即使您确实知道正在向您发送研究的系统上有哪些图像可用 - 您如何确保没有用户坐在其前面，他们刚刚选择了研究的子集发送。
很抱歉，我无法向您提供“真正的解决方案”，但由于我上面提到的原因，我不知道任何支持您所描述的功能（进度条）的真实系统。