DICOM：最新标准梳理之DICOM Web Service，WADO-URI/WADO-WS/WADO-RS

目录:

0.背景
1.DICOM3.0标准概要
2.DICOM3.0 PS18 Web Service
2.1.WADO-URI
2.2.WADO-WS
2.3.WADO-RS
3.总结

背景：

DICOM标准委员会每年大约处理10个左右标准功能内容方面的增补（supplement），100 个左右的修改提议，并且每年数次发布更新的标准的正式英语版本，本博客专栏中关于数据处理和网络传输基础内容的博文几乎未受到任何影响。但是对于新式的设备的数据格式或者与新的网络技术相关的部分会有所影响，本博文通过梳理最新标准中的DICOM Web Service，来了解一下标准对WADO部分的扩展。

1.DICOM3.0标准概要

直接给出最新标准官方第一部分概述中的几个截图，了解一下DICOM标准的整体结构：

摘自PS3.10 Figure6.2-2

摘自PS3.1 Figure6.2-1

摘自PS3.1 Figure6.11-1

2.DICOM3.0 PS18 Web Service

下面直接进入本文的主题，看一下标准的第18部分：DICOM Web Service，官方文档链接为Dicom Web Service

对比DICOM3.0最新的2016C标准与2011b的第18章，可以看出在WADO协议方面扩展了部分内容，除了保留之前最最原始的WADO-URI的方式，新增了WADO-WS和WADO-RS。（关于Web Service与Restful Service区别可参见网络其他资料，例如REST vs SOAP、Restful vs SOAP，最主要的区别是WS通常指的是SOAP，是一种新的协议；Rest是基于HTTP基础上的新的实现方式）。具体的操作如下截图：

【备注】：从上述描述可以看出，WADO-URI与WADO-RS都是基于HTTP（或者HTTPS）协议之上的一种实现方式，WADO-URI采用的是HTTP的GET方法，通过URL配置参数的方式来完成DICOM数据的交互；WADO-RS同样采用HTTP的GET方法（当然后续扩展的数据上传采用的是HTTP的POST，这个后续会单独介绍）；WADO-WS采用的是HTTP的POST方法，通过SOAP协议的方式来完成DICOM数据的交互操作。

2.1 WADO-URI

WADO-URI是使用HTTP中的GET请求来获取DICOM图像（或者JPG/PNG渲染后图像）的一种解决方案。流程如下：

例如在浏览器输入链接：
http://www.linkingmed.com/#/viewer?imageid=16&patientID=1162&studyUID=1.2.156.112572.18161010101313.5325162118.1245&reportFlag=0&type=dicom
在Chrome调试状态可以看到如下信息：

其中大多数信息都仅仅与HTTP协议有关(详情可参考www官方文档https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html)，压根儿跟DICOM协议没有任何关系。例如Request Header中的
accept：请求中的accept表明客户端（通常是浏览器）自身能够支持的从服务器返回的数据类型，例如上图中支持image/webp,image/,/*;q=0.8表示图片的质量
accept-encoding：表示客户端（通常是浏览器）支持的编码格式，通常用于压缩和解压缩
accept-language：表示客户端（通常是浏览器）支持的字符集，通常跟乱码有关。
因为DICOM文件有多种类型，主要有Single frame（简单的可以理解为一个DICOM文件内部只有一个图片）、Multi frame（一个DICOM文件有多个图片）。每种类型在WADO-URI的Response返回结果中有所体现，大致如下：

类型	内容	备注
single frame	application/dicom image/jpeg	还可以支持image/gif,image/png,image/jp2
multi frame	application/dicom video/mpeg image/gif
text文本信息	application/dicom text/plain text/html	还可以支持text/xml,application/pdf,text/rtf

除此以外，唯一跟DICOM有关系的就是底部的“Query String Parameters”，例如上文中的：

serverURL:http://localhost:8080/wado
study:1.2.156.112572.18161010101313.5325162118.1245
series:1.2.156.112572.18161010101313.5325163054.3
object:1.2.156.112572.18161010101313.5325163321.3.4
rows:64

WADO-URI的query参数主要有以下几类：

参数	含义	示例
Request type	请求的类型，即WADO	requestType=WADO
Unique identifier of the Study	检查的UID	studyUID=xxxx
Unique identifier of the Series	序列的UID	seriesUID=xxx
Unique identifier of the Object	对象（文件）UID，可以叫做SOP、instance等	objectUID=xxx
MIME type of response	返回数据的类型	该参数可选，contentType=application/dicom
Charset of the response	字符集类型	该参数可选，charset=xxx
Anonymize object	数据匿名化	该参数可选anonymize=yes

上述参数是所有DICOM数据都支持的参数，另外针对于DICOM Image图像还可支持如下参数（下列选项可选）：

参数	含义	示例
Annotation on the object	注释标记	annotation=
Number of pixel rows	图像的行数	rows=64，当contentType=application/dicom时不存在
Number of pixel columns	图像的列数	columns=64，当contentType=application/dicom时不存在
Region of the image	图像区域，期左上角像素点的x/y坐标和右下角像素点的x/y坐标，范围是0.0-1.0	region=0.0,0.0,1.0,1.0，当contentType=application/dicom时不存在
Window center of the image	窗位，类型是Decimal String，即DS	windowCenter=xxx，，当contentType=application/dicom时不存在
Window width of the image	窗宽，类型是Decimal String，即DS	windowWidth=xxx，，当contentType=application/dicom时不存在
Frame number	图像帧位置	frameNumber=1，当对应的对象时Multi-frame时有效，另外当contentType=application/dicom时不需要存在
Image Quality	图像质量	imageQuality=xxx，档contentType=application/dicom时不需要存在，但是如果同时给出了一个压缩语义transferSyntax参数时需要设定ImageQuality。例如如果返回值为image/jpeg类型，那么imageQuality可以设置1-100来表示图像质量
Transfer Syntax UID	传输语义，用于表示返回的DIOCM数据的字节顺序和编码方式	transferSyntax=1.2.840.10008.1.2.1,默认是Explicit VR Little Endian（即1.2.840.10008.1.2.1）。

WADO-URI的Query参数格式：

下面直接给出几个具体示例：

功能	链接	备注
请求一个DICOM图像，并进行匿名化处理	http://www.linkingmed.com?requestType=WADO&studyUID=1.2.250.1.59.40211.12345678.678910 &seriesUID=1.2.250.1.59.40211.789001276.14556172.67789 &objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2 &contentType=application%2Fdicom &anonymize=yes &transferSyntax=1.2.840.10008.1.2.4.50
请求一个简单的DICOM图像，并要求转换成JPEG格式	http://www.linkingmed.com?requestType=WADO&studyUID=1.2.250.1.59.40211.12345678.678910 &seriesUID=1.2.250.1.59.40211.789001276.14556172.67789 &objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2
请求一个DICOM SR报告，要求以HTML格式返回	http://www.linkingmed.com?requestType=WADO&studyUID=1.2.250.1.59.40211.12345678.678910 &seriesUID=1.2.250.1.59.40211.789001276.14556172.67789 &objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2 &charset=UTF-8
	https://www.linkingmed.com?requestType=WADO&studyUID=1.2.250.1.59.40211.12345678.678910 &seriesUID=1.2.250.1.59.40211.789001276.14556172.67789 &objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2 &contentType=image%2Fjp2;level=1,image%2Fjpeg;q=0.5 &annotation=patient,technique &columns=400 &rows=300 &region=0.3,0.4,0.5,0.5 &windowCenter=-1000 &windowWidth=2500	这个请求链接几乎包含了上述提到的所有关于DICOM Image的操作参数

2.2 WADO-WS

接下来再看一下基于Web Service的WADO服务，因为WADO-WS的实现难度高，复杂度大，所以这里简单介绍一下，以下一章节的WADO-RS为主。
WADO-WS支持三种操作：
- RetrieveImagingDocumentSet：提取DICOM instances and other objects;
- RetrieveRenderedImagingDocumentSet：提取DICOM instance并要求转换为相应的图像格式，例如JPEG。
- RetrieveImagingDocumentSetMetadata：提取DICOM instance对象，但是去除了图像数据Bulk data。
因为WADO-RS符合WS-I（http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html），即需要实现SOAP协议，因此诸多的操作需要手动实现，详情可参见官方文档。

2.3 WADO-RS

从上图可以看出WADO-RS服务支持的类型和服务最多。下面让我们看一下WADO-RS的具体细节：

WADO-RS支持的操作有：
- RetrieveStudy
- RetrieveSeries
- RetrieveInstance
- RetrieveFrames
- RetrieveBulkdata
- RetrieveMetadata

上述操作的实现的功能可以直接从名称中看出来这里就不详细介绍了。由于WADO-RS是基于HTTP的GET来实现DICOM的交互的，因此需要将上述操作的结果封装到HTTP的Response中返回。对应的关系图如下所示：

WADO-RS各个操作的格式：

WADO-RS Action	参数	示例
RetrieveStudy Request	Resource: {SERIVE}/studies/{StudyInstanceUID} Method:GET Headers:Accept:multipart/related;type=”application/dicom”或者type=”application/octet-stream”或者type=”{media-type}”	Accept: multipart/related; type=”image/jpx”; transfer-syntax=1.2.840.10008.1.2.4.92,, multipart/related; type=”image/jpx”; transfer-syntax=1.2.840.10008.1.2.4.93, multipart/related; type=”image/jpeg”
RetrieveStudy Response	Content-type:multipart/related;type=application/dicom;boundary={MessageBodunary}
RestireveSeries Request	Resource:{SERVICE}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID} Method:GET Headers:Accept:multipart/related;type=”application/dicom”;或者type=”application/octet-stream”或者type=”{media-type}”
RetrieveSeries Response	Content-type:multipart/related;type=”application/octet-stream”;boundary={MessageBodunary}
RetrieveInstance Request	Resource:{SERVICE}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID} Method:GET Headers:Accept：multipart/related;type=”application/dicom”或者type=”application/octet-stream”或者type=”media-type”
RetrieveInstance Response	Content-Type:multipart/related; type=”application/dicom”; boundary={MessageBoundary}
RetrieveFrames Request	Resource:{SERVICE}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}/frames/{FrameList} Method:GET Headers:Accept:multipart/related; type=”application/octet-stream”或者type=”{media-type}”	{FrameList}需要用逗号或者%2C隔离开，例如/frames/1,2,4,3
RetrieveFrames Response	Content-Type:multipart/related; type=”application/octet-stream”; boundary={MessageBoundary} [dcm-parameters]
RetrieveBulkdata Request	Resource:{BulkDataURI} Method:GET Headers:Accept:multipart/related; type=”application/octet-stream” [dcm-parameters]或者multipart/related; type=”{media-type}” [dcm-parameters]
RetrieveBulkdata Response	Content-Type:multipart/related; type=”application/octet-stream”; boundary={MessageBoundary} [dcm-parameters]
RetrieveMetadata	Resources:{SERVICE}/studies/{StudyInstanceUID}/metadata或者 {SERVICE}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/metadata或者{SERVICE}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}/metadata Method:GET Headers:Accept:multipart/related; type=”application/dicom+xml”或者application/dicom+json
RetrieveMetadata	Content-Type：multipart/related; type=”application/dicom+xml” [dcm-parameters]或者application/dicom+json [dcm-parameters]

最后看一下WADO-RS Retrieve Rendered Transaction，用于实现DICOM数据到图像格式的转换。请求的格式如下：

针对各个级别的请求如下：

对于DICOM图像格式转换，最重要的是请求中的{?parameter*}参数，参数详细配置如下：

上述参数主要用于配置图像的区域和截取的窗宽窗位，与WADO-URI中的URL中的参数发挥的作用一致。具体的转换格式在“1#rendered-media-type”中给出，这个参数类似于WADO-URI中的&contentType=image%2Fjp2。
由此可以看出WADO-RS与WADO-URI的实现方式是类似的，除了在获取基础对象（Study、Series、Instance）时刻的方式不同（WADO-URI时基于&拼接完成的URL字符串，而WADO-RS是利用的REST实现框架），参数的传递方式是一样的。通过在资源定位URI后的{?parameter*}参数来实现转换操作。或者说WADO-RS仅仅是将WADO-URI放在基础URI后面{?parameter*}参数中的三级UID（studyUID、seriesUID、objectUID）挪到了URI中，仅仅在{?parameter*}中传递转换操作的相关参数。

3.总结

由最初的WADO-URI，到WADO-WS，再到WADO-RS，实现框架越来越简捷清晰，开发工作越来越方便。虽然上文介绍了诸多繁琐的标准和条款，但是其本质是一样的，最终都需要落实到DICOM的解析、DICOM的格式转换、DICOM的存储上来。这也是DICOM标准委员会制定标准的初衷，只规定与医疗服务相关的协议和标准，对于具体的实现路径不做强制约束。

作者：[email protected]
时间：2016-10-15