WADO-RS与Dicom服务类用户/提供者的目的是什么?

3

我正在尝试弄清楚使用像pynetdicom3这样的(SCU/SCP)与使用wado api传输dicom文件之间的区别。

这两种方法都可以用于传输dicom文件。但我无法弄清楚每种方法的标准用例是什么?

2个回答

6
首先,两种方法都可以实现所有常见用例。不同之处在于你使用的技术和你想要接口的系统,而不是一种方法支持的功能比另一种方法更多。
基于传统TCP/IP协议的DICOM服务自1998年以来一直在开发中。它们广泛分布,并且几乎所有当前领域的系统都支持它们。从现在的角度来看,它们可能显得有些笨拙,并且存在一些内置故障(例如,限制127个表现上下文)。但它们比基于Web的东西更常见。特别是当涉及跨不同站点进行通信的情况时,使用基于TCP/IP的协议很难实现。
WADO服务是由DICOM委员会开发的,旨在采用新技术并为基于Web技术的应用程序简化DICOM实现。它们相当新(就DICOM标准而言)。也就是说,主要用例是基于Web的应用程序,我还没有看到任何传统的模态支持它们,我也不希望它们在不久的将来出现。这是因为你可以依赖PACS来支持基于TCP/IP的DICOM,但你必须指望WADO。PACS系统倾向于支持WADO以及TCP/IP,以便集成网络查看器和移动设备,其中越来越多的应用程序仅支持WADO。
因此,我的非常主观的建议是:
- 对于专为医院使用而设计的应用程序:坚持使用基于TCP/IP的DICOM,因为你可以相当肯定地确保它将被你需要接口的系统所支持。 - 如果通过互联网进行连接是主要用例,或者你的应用程序使用大量Web技术,请考虑使用WADO,但要调查你需要接口的相关系统对WADO的支持情况。这可能取决于您的应用程序所针对的领域。

1
我大多数情况下只遇到过WADO查看器。我从未见过任何实现WADO用于其他服务的设备或PACS。楼上应该采纳你的建议。 - Amit Joshi
1
同意。我预计WADO会逐渐兴起,特别是在HL7欢迎他的新朋友FHIR之后。WADO和FHIR真的是构建基于Web的医疗应用程序的良好框架,而且大公司(谷歌、微软、苹果)正在推动基于Web的标准。也许有一天,新一代开发人员会想知道为什么他们要采用像DICOM TCP协议这样疯狂的东西,而将WADO为基础的东西推向今天认为不可想象的领域(模态<->PACS)。但这可能需要几年时间,直到这种趋势变得显著。 - Markus Sabin

2
要补充@kritzel_sw已经非常好的回答-WADO只是其中的一部分。WADO用于通过网络检索图像。还有STOW或Store Over the Web和QIDO或基于ID查询DICOM对象,用于存储新对象到PACS并分别查询PACS。

我认为我们将在未来越来越多地看到它,不仅适用于基于Web的DICOM查看器,还适用于系统之间的普通DICOM通信。它特别适用于其中一个系统不了解DICOM,而开发人员也没有DICOM经验的情况。

考虑我的经验中的用例。我们希望医生能够上传他们患者的皮肤状况照片并将这些照片发送到我们的PACS。使用STOW让一些开发人员按照规范基本上是“获取用户上传的JPG照片,根据规范以JSON格式添加必要的元数据,并通过HTTP POST请求将其全部发送到此地址”,比起“将上传的JPG文件转换为有效的DICOM对象,具有必要的元数据,传输语法等,并实现C-STORE SCU将其发送到我们的PACS”更容易且可能更便宜。对于第一项工作,您可以获得任何熟练掌握Web开发的开发人员,而对于第二项工作,您需要找到已经知道DICOM及其所有怪癖的人或支付某人大量学习它。

这就是为什么我喜欢所有这些新的基于Web的DICOM选项,并看到它们的未来非常广阔。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接