简而言之： DICOMweb 是 DICOM 标准第 18 部分定义的一组 Web 服务。它通过纯 HTTPS 暴露 DICOM 存档：QIDO-RS（基于 ID 查询 DICOM 对象）用于搜索检查、系列和实例；WADO-RS（Web 访问 DICOM 对象）用于检索它们，可以是完整的 DICOM 文件、JSON 格式的元数据，或渲染后的 JPEG/PNG；STOW-RS（Web 存储）用于上传新对象。较旧的 WADO-URI 通过查询参数检索单个对象。基于浏览器的查看器使用 DICOMweb，因为它们无法使用经典的 DICOM 网络协议。
经典 DICOM 与 DICOMweb
经典的 DICOM 网络（标准第 7 和第 8 部分)在配置好的节点之间使用基于 TCP 的二进制协议，提供 C-FIND、C-MOVE、C-GET 和 C-STORE 等服务。DICOMweb（第 18 部分)将相同的操作映射到 HTTP：QIDO-RS 用于搜索，WADO-RS 用于检索，STOW-RS 用于存储，这使得它可以在互联网和浏览器上运行。
经典 DICOM（第 7 和 8 部分）使用基于 TCP 的自定义二进制协议，并带有命名服务：C-FIND 用于查询，C-MOVE 或 C-GET 用于检索，C-STORE 用于发送。它需要在两个已知节点（AE 标题、IP 地址、端口）之间配置“关联”，这在医院内部很方便，但在互联网上很难实现。DICOMweb 将相同的概念映射到 HTTP：
| 任务 | 经典 DICOM | DICOMweb |
|---|---|---|
| 查找检查 | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| 检索检查 | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| 仅读取元数据 | 实例级别的 C-FIND | WADO-RS: GET /studies/{uid}/metadata |
| 获取可查看图像 | 先检索再本地渲染 | WADO-RS 渲染: GET …/instances/{uid}/rendered |
| 将图像发送到存档 | C-STORE | STOW-RS: POST /studies |
| 管理工作列表 | MWL (在工作列表上进行 C-FIND) | UPS-RS |
资源层次结构遵循 DICOM 自身的模型：一个检查（一次扫描仪访问）包含系列（每次采集），系列包含实例（单个图像或多帧对象），每个实例都由全局唯一的 UID 标识。
QIDO-RS：搜索
QIDO-RS 是 DICOMweb 的搜索服务。客户端发送 GET /studies、/series 或 /instances 请求，并附带 PatientID、StudyDate 或 ModalitiesInStudy 等查询参数以及 Accept 头部 application/dicom+json。归档系统会返回一个 JSON 数组，其中每个 DICOM 属性都以其八位数字的标签作为键，并包含其值表示和值。
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
响应是一个 JSON 数组，包含检查信息。每个属性都由其标签（组和元素，以八位十六进制数字表示）作为键，并包含其值表示和值：
[{
"00080020": {"vr": "DA", "Value": ["20260314"]},
"00080060": {"vr": "CS", "Value": ["CT"]},
"00100010": {"vr": "PN", "Value": [{"Alphabetic": "DOE^JANE"}]},
"0020000D": {"vr": "UI", "Value": ["1.2.840.113619.2.55.3.2831164356.781.1710415000.1"]},
"00201206": {"vr": "IS", "Value": [3]},
"00201208": {"vr": "IS", "Value": [412]}
}]
这里的 00201206 是“检查相关系列数量”，00201208 是“检查相关实例数量”。标签编号在 DICOM 标签解释 中进行了解释。
WADO-RS：检索
WADO-RS 是 DICOMweb 的检索服务。GET /studies/{StudyInstanceUID} 请求会以 multipart 响应的形式返回整个研究的 DICOM Part 10 文件；/metadata 后缀会以 JSON 格式返回头部信息，不包含像素数据；/frames/{n} 请求会返回单个帧的像素数据；/rendered 请求会返回服务器渲染的 JPEG 或 PNG 图片，并可指定窗口、视口和质量参数。
GET /studies/{study}并带有Accept: multipart/related; type="application/dicom"会将每个实例作为 DICOM Part 10 文件返回，每个文件为一个部分。GET /studies/{study}/metadata以 JSON 格式返回所有实例的头部信息，不包含像素数据。查看器首先调用此接口来构建布局，然后逐帧获取像素。GET /studies/{study}/series/{series}/instances/{instance}/frames/1返回一帧的像素数据，可选地进行转码（通过transfer-syntax参数）。GET …/instances/{instance}/rendered并带有Accept: image/jpeg会返回服务器渲染的图像，并带有window、viewport和quality参数。这是轻量级患者门户用于显示预览的功能。
STOW-RS：存储
STOW-RS 是 DICOMweb 的存储服务。客户端发送 POST /studies 请求，请求体为 multipart/related，其中每个部分是一个 DICOM 文件。归档系统会回复一个已接受和失败的实例列表以及每个失败的原因，并检查 URL 中提供的任何 Study Instance UID 是否与上传的文件匹配。
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
每个部分是一个 DICOM 文件。响应会列出已接受和失败的实例及其原因（SOP 类错误、UID 重复）。存档会验证 URL 中的 Study Instance UID（如果提供）是否与文件匹配。
安全性
DICOMweb 本身没有登录机制；它依赖于 HTTPS 和服务器前端的任何安全措施：大多数现代存档使用 OAuth 2.0 bearer token，当查看器从 EHR 启动时，通常会结合 SMART on FHIR 范围。记录谁检索了哪个检查是存档的职责，而不是协议的职责。
使用场景
每个主要的 PACS 和通用存档现在都提供 DICOMweb 端点，开源存档（Orthanc、dcm4chee、Google Cloud Healthcare API、Azure DICOM 服务）更是以 DICOMweb 为优先。OHIF 等 Web 查看器完全基于 QIDO-RS 和 WADO-RS 构建。在 FHIR 生态系统中，ImagingStudy 资源会指向一个 DICOMweb 端点；像素数据永远不会通过 FHIR 传输。
Anpheros 不存储图像。患者的记录可以包含放射报告（作为 DocumentReference 或 DiagnosticReport），以及在医院提供的情况下，指向其查看器的链接；DICOM 数据本身保留在医院的存档中。要获取您自己的图像作为患者，请参阅 如何获取您的 CT 或 MRI 图像。
相关页面
- FHIR ImagingStudy 与 DICOMweb 的区别
- DICOM 标签解释
- PACS 与 RIS 与 VNA 的区别
- 如何获取您的 CT 或 MRI 图像 (DICOM)
- 医疗互操作性标准：地图
- DICOM 与 FHIR 面向开发者
来源
常见问题
DICOMweb 是一个独立的标准吗？
不是。它是同一个 DICOM 标准的第 18 部分。对象、标签和 UID 都相同；只有传输方式从 DICOM 自有协议改为 HTTP。
WADO-URI 和 WADO-RS 有什么区别？
WADO-URI 是较旧的服务：每次请求一个对象，通过查询参数选择（?requestType=WADO&studyUID=…）。WADO-RS 是 RESTful 的，可以返回整个检查或系列、JSON 格式的元数据以及单个帧，是新系统实现的接口。
我可以在没有 PACS 的情况下使用 DICOMweb 吗？
您需要一个实现了 DICOMweb 的存档。Orthanc 和 dcm4chee 等开源服务器开箱即用地提供 DICOMweb 功能，并常用于开发和小型诊所。
FHIR 是否取代了 DICOMweb？
不。FHIR 描述检查（ImagingStudy）和报告（DiagnosticReport）；DICOMweb 则负责传输图像。查看器同时使用两者：FHIR 用于了解检查的存在，DICOMweb 用于显示它。
Anpheros 致力于打造一个由患者掌控的医疗记录，并可在欧盟的 HL7 FHIR R4 平台上与任何诊所共享。这些指南旨在帮助您理解和整理您的健康信息，但不能替代您的医生。
关于 Anpheros →