短く言うと: DICOMwebは、DICOM規格のPart 18で定義されているWebサービス群です。これは、プレーンなHTTPSを介してDICOMアーカイブを公開します。QIDO-RS (Query based on ID for DICOM Objects) は、スタディ、シリーズ、インスタンスを検索します。WADO-RS (Web Access to DICOM Objects) は、これらを完全なDICOMファイルとして、JSON形式のメタデータとして、またはレンダリングされたJPEG/PNGとして取得します。STOW-RS (Store Over the Web) は、新しいオブジェクトをアップロードします。古いWADO-URIは、クエリパラメータを介して1つのオブジェクトを取得します。ブラウザベースのビューアは、従来のDICOMネットワーキングを話すことができないため、DICOMwebを使用します。
従来のDICOMとDICOMwebの比較
従来のDICOMネットワーク（規格のパート7および8）は、設定されたノード間でC-FIND、C-MOVE、C-GET、C-STOREなどのサービスを持つTCP上のバイナリプロトコルを使用します。DICOMweb（パート18）は、同じ操作をHTTPにマッピングします。QIDO-RSは検索、WADO-RSは取得、STOW-RSは保存に使用され、インターネットやブラウザから利用できます。
従来のDICOM (Part 7および8) は、TCP上で独自のバイナリプロトコルを使用し、名前付きサービス（クエリにはC-FIND、取得にはC-MOVEまたはC-GET、送信にはC-STORE）を使用します。これは、2つの既知のノード（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独自のモデルに従います。スタディ（スキャナーへの1回の訪問）にはシリーズ（各取得）、それにはインスタンス（単一の画像またはマルチフレームオブジェクト）が含まれ、それぞれがグローバルに一意なUIDによって識別されます。
QIDO-RS: 検索
QIDO-RSはDICOMwebの検索サービスです。クライアントは、PatientID、StudyDate、ModalitiesInStudyなどのクエリパラメータとAcceptヘッダーapplication/dicom+jsonを指定して、GET /studies、/series、または/instancesを送信します。アーカイブは、各DICOM属性が8桁のタグとその値表現および値でキー付けされたJSON配列を返します。
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
応答は、スタディのJSON配列です。各属性は、そのタグ（グループと要素を8桁の16進数で表したもの）、値表現、および値でキー付けされます。
[{
"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はNumber of Study Related Series、00201208はNumber of Study Related Instancesです。タグ番号については、DICOMタグの説明を参照してください。
WADO-RS: 取得
WADO-RSはDICOMwebの取得サービスです。GET /studies/{StudyInstanceUID}は、multipartレスポンスでDICOMパート10ファイル全体としてスタディを返します。/metadataサフィックスは、ピクセルデータなしでJSON形式のヘッダーを返します。/frames/{n}は1フレームのピクセルを返します。/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は、1フレームのピクセルデータを返します。オプションでトランスコードされます（transfer-syntaxパラメータ）。GET …/instances/{instance}/renderedとAccept: image/jpegは、サーバーでレンダリングされた画像を返します。window、viewport、qualityパラメータが使用されます。これは、軽量な患者ポータルがプレビューを表示するために使用するものです。
STOW-RS: 保存
STOW-RSはDICOMwebの保存サービスです。クライアントは、各パートが1つのDICOMファイルであるmultipart/relatedボディを付けてPOST /studiesを送信します。アーカイブは、受け入れられたインスタンスと失敗したインスタンスのリスト、および各失敗の理由を返します。また、URLで指定されたStudy Instance UIDがアップロードされたファイルと一致するかどうかを確認します。
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
各パートは1つのDICOMファイルです。応答は、受け入れられたインスタンスと失敗したインスタンスを理由（無効なSOPクラス、重複したUID）とともにリストします。アーカイブは、URL内のStudy Instance UID（指定されている場合）がファイルと一致することを確認します。
セキュリティ
DICOMwebには独自のログイン機能はありません。HTTPSと、サーバーが前面に配置するものを利用します。ほとんどの最新のアーカイブではOAuth 2.0ベアラートークンが使用され、ビューアが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 vs RIS vs VNA
- CTまたはMRI画像を取得する方法 (DICOM)
- 医療相互運用性標準：マップ
- 開発者向けDICOM vs FHIR
ソース
- DICOM PS3.18: Web Services
- DICOM PS3.7: Message Exchange
- DICOMweb概要 (DICOM Standards Committee)
- OHIF Viewer ドキュメント
よくある質問
DICOMwebはDICOMとは異なる規格ですか？
いいえ。同じDICOM規格のPart 18です。オブジェクト、タグ、UIDは同じです。トランスポートのみが、DICOM独自のプロトコルからHTTPに変更されます。
WADO-URIとWADO-RSの違いは何ですか？
WADO-URIは古いサービスです。リクエストごとに1つのオブジェクトが、クエリパラメータ（?requestType=WADO&studyUID=…）で選択されます。WADO-RSはRESTfulであり、スタディ全体またはシリーズ、JSON形式のメタデータ、個々のフレームを返すことができ、新しいシステムで実装されています。
PACSなしでDICOMwebを使用できますか？
DICOMwebを実装しているアーカイブが必要です。Orthancやdcm4cheeなどのオープンソースサーバーは、DICOMwebを標準で提供しており、開発や小規模クリニックで一般的に使用されています。
FHIRはDICOMwebを置き換えますか？
いいえ。FHIRはスタディ（ImagingStudy）とレポート（DiagnosticReport）を記述します。DICOMwebは画像を提供します。ビューアは両方を使用します。FHIRでスタディが存在することを確認し、DICOMwebでそれを表示します。
Anpheros Dailyで試してみる
スキャンや検査レポートをAnpheros Dailyに一元管理し、次回の受診時に提示できるようにしておきましょう。
アプリでの使い方 →
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →