6

我想知道是否有人曾尝试解决以下问题。我需要在远程 DICOM Q/R 服务器上执行一系列测试。这将允许一些简单的 DICOM 一致性声明检查。

作为测试套件的实现细节，我正在运行以下命令（DCMTK 样式命令）：

$ findscu --study --cancel 1 --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112

这里的目标是找到一个有效的StudyID（稍后我将使用该StudyID来执行较低密钥级别的 C-FIND 以及一些相关的 C-MOVE 查询）。当然，如果我可以上传自己的数据集并尝试取回它会容易得多，但我无法在临床环境中对正在运行的 PACS 执行此操作。我需要用最少的查询来定义如何找到有效的StudyID。

但是我担心某些 DICOM 实现可能会禁止policies查询整个数据库。

所以我想知道是否有人编写了这些列表policies，并且可能描述了一种从远程服务器检索有效 StudyID 的方法，其 C-FIND 查询数量最少。

4

2 回答 2

4

欢迎来到 DICOM-仙境。

你是对的，你应该非常、非常、非常、非常小心地在临床 PACS 上运行随机查询。我已经看到商业 PAC 发送他们的整个（！）数据库作为它不理解的查询的结果。不是一个漂亮的景象。这（和隐私）是全球许多医院 PACS 管理员非常害怕通过 DICOM 直接访问其 PACS 的原因之一。

一般来说，我会说标准化不会帮助你。所以你必须找到适合你的东西，并且不会让 PACS 崩溃。这里没有保证。

只是在医院查询 PACS 的观察结果列表：

  • 有些匹配时区分大小写，有些则不区分大小写。
  • 大多数支持某种通配符。这通常是一个'*'。但我也见过 '%' （因为这是一个 SQL 通配符，并且查询只是作为 SQL 字符串传递）。我认为这不是很好的定义。
  • 您将获得的列表可能仅限于说前 500 个条目。或 1000。或 500 到 1000 之间的随机数。或整个 PACS。你只是不知道。
  • DICOM 和取消效果不好。取消查询没有很好地实现。通常 PACS 将其视为传输失败，并在一段时间后重试。并且重试队列的大小是有限的，所以它可能会忽略新的查询。所以总是让你的 STORE-SCP 服务器运行来排空这个队列。
  • 有时查询需要几分钟，尤其是检索。下一次它可能已被检索（从磁带？）并快速一段时间。
  • DICOM 查询可能会占用 PACS 的大量资源，具体取决于 PACS。如果您尝试过多一点，如果 PACS 管理员出现，请不要感到惊讶。
  • 支持的查询非常不同。所有人只支持基本查询：患者列表、患者的 studyID/研究 instanceuid 列表、每个研究的系列列表、检索研究或系列。除非你有一个使用 Osirix 的时髦研究部门，它不支持患者级别的查询，而只支持研究级别的查询。

所以如果你想在任何随机 PACS 上工作，我会建议：

  • 使用空返回键而不是“*”。这是检索信息的 DICOM 方式。
  • 不要使用“-取消”。如果确实需要取消，直接关闭 TCP 连接即可（DCMTK 不支持）
  • 使用对 PatientId、PatientName、Birthdate、StudyDate 的查询来获取 StudyIDs/StudyInstanceUids 的列表。

最简单的就是使用一个固定的 StudyID，假设它在 PACS 中的停留时间足够长。如果不是，请考虑限制查询以不使 PACS 过载（您的“今天”建议符合该描述）。

祝你好运！

于 2014-05-22T20:35:44.907 回答
4

我想我可以简单地选择：

TODAY=`date +"%Y%m%d"`
findscu --study --key 0008,0020="$TODAY-" --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112

如果这不起作用（返回空），我会检查yesterday结果。

于 2014-05-18T08:51:05.813 回答