DICOMwebとは - WADO・QIDO・STOWによるDICOM画像のWeb連携
DICOMweb（DICOM Web）とは、DICOM規格をHTTP/RESTベースで扱えるようにした一連のWeb API仕様である（DICOMの基本概念はDICOMとはを参照）。従来のDICOM通信（C-STORE/C-FIND/C-MOVEなど、TCP/IP上の専用プロトコル＝Upper Layer Protocol）は院内ネットワーク内の装置間連携を前提としていたのに対し、DICOMwebはブラウザ・クラウド・モバイル端末からでも画像データへアクセスできるように設計されている。
Web・クラウド連携をご検討の方へ：DICOMweb・画像連携の開発対応をご覧ください。
DICOMwebを構成する主なサービス
| サービス名 | 役割 | 従来DICOMでの対応関係 |
|---|---|---|
| QIDO-RS（Query based on ID for DICOM Objects） | 患者・検査・シリーズ・画像インスタンスの検索 | C-FIND に相当 |
| WADO-RS（Web Access to DICOM Objects） | 検査・シリーズ・インスタンス単位での画像取得 | C-MOVE／C-GET に相当 |
| STOW-RS（Store Over the Web） | 画像・レポート等のアップロード（保存） | C-STORE に相当 |
| WADO-URI（旧称 WADO） | 単一インスタンスをURL指定で取得する古い方式。RESTfulなWADO-RSの前身 | — |
| UPS-RS（Unified Procedure Step） | ワークリスト・作業指示のWeb版（補足） | Modality Worklist／MPPS に相当 |
DICOMwebの理念
DICOMは1993年の初版制定当時、院内LANでの装置間通信を前提に、TCP/IP上に独自の接続手順を持つ専用プロトコル（Upper Layer Protocol）として設計された。当時はインターネット経由でのアクセスやクラウド連携は想定されておらず、通信には専用ポート・専用クライアントが必要だった。
2000年代に入り、遠隔読影や地域医療連携、施設外からの画像参照といったニーズが高まるにつれて、「ファイアウォール越しでも通信しやすいこと」「専用クライアントなしでも扱えること」が求められるようになった。これに応える形でDICOM標準にWADO（Web Access to DICOM Objects, PS3.18）が追加され、HTTP経由での画像取得が可能になったが、初期のWADOはURLクエリ形式（WADO-URI）で、現在のようなRESTfulなAPI設計ではなかった。
その後、2010年代前半にかけてQIDO-RS（検索）・WADO-RS（取得）・STOW-RS（保存）という現行のRESTful API群が整備され、今のDICOMwebの形になった。根底にある理念は、「医用画像という中身の標準（タグ・IOD等）はそのままに、運び方だけを世界中に普及したWeb技術（HTTP/REST）に合わせる」という発想である。専用プロトコル・専用クライアントを必要としていた医用画像を、汎用的なWebのエコシステム（ブラウザ、標準的な認証基盤、クラウドインフラ）に乗せることを目的としている。
どのように便利になるか
- ブラウザだけで画像を閲覧できる（Zero-footprint Viewer）— 専用ビューアソフトのインストールが不要になる
- ファイアウォール越しでも通信しやすい — 院内DICOM専用ポートでなく、通常のHTTPS（443番）で完結する
- クラウド・分散環境との親和性 — オブジェクトストレージ、CDN、ロードバランサ、マイクロサービス構成と組み合わせやすい
- 標準的なWeb技術がそのまま使える — OAuth等の認証基盤、API Gateway、監視ツールなど、医用画像専用でない汎用ツールを流用できる
- モバイル・タブレット対応が容易 — 各言語の標準的なHTTPクライアントで実装でき、専用SDKが不要
現代の対応状況
海外では、DICOMweb・HL7 FHIR・IHEプロファイルへの対応は、もはや差別化要素ではなく前提条件という位置づけになりつつある。Google Cloud Healthcare API、AWS HealthImaging、Azure Health Data Servicesといった主要クラウドの医療向けサービスは標準でDICOMwebに対応しており、クラウドPACS・VNA製品でもDICOMweb対応は標準機能として扱われる傾向にある。IHEの相互接続プロファイル（施設間の画像共有を定めるXDS-I.b、モバイルアクセスをFHIRトランザクションにマッピングするMHD等）と組み合わせて使われることも多い。
国内については、DICOM画像そのものの実装統計は把握が難しいが、別の角度として、Webを通じて個人の医療情報にアクセスできるようにする取り組みが国レベルで進んでいる。「電子カルテ情報共有サービス」（全国医療情報プラットフォームの中核で、医療機関・薬局間の診療情報共有に加え、患者本人もマイナポータルで自身の情報を閲覧できる仕組み）は、2026年度中の本格運用開始を目指して整備が進められている。これはHL7 FHIRを基盤とした取り組みでDICOMwebそのものではないが、「Webを通じて医療情報を参照する」という方向性自体は国内でも後押しされつつある。
どのようなシステムに向いているか
- クラウド型PACS・医用画像ストレージ
- ブラウザ完結型の読影・参照ビューア（遠隔読影、地域医療連携）
- モバイルアプリからの画像参照
- AI解析基盤への画像データ供給（学習データの収集、推論結果の受け渡し）
- 複数施設・複数ベンダーをまたいだ画像共有基盤
こんな「Web化・クラウド化」のお困りごとに対応します
DICOMwebに関心を持つ方の多くは、「古いシステムをどうクラウド対応させるか」「新しく作るならDICOMwebで作るべきか」という段階にいる。よくあるお困りごとと、当社の解決アプローチを整理する。
| ありがちなお困りごと | 当社の解決アプローチ |
|---|---|
| 古いPACS・モダリティがDICOMweb非対応で、クラウドやブラウザビューアにつなげない | 既存機器・PACSの手前にDICOMwebゲートウェイ（変換アダプタ）を設置し、C-STORE/C-FINDなど従来DICOM通信をWADO-RS/QIDO-RS/STOW-RSへ翻訳する。既存資産を改修せず、Web・クラウド対応の窓口だけを追加できる |
| 自社のクラウドPACS・Webビューアを新規開発したいが、DICOMweb実装のノウハウがない | 自社DICOMライブラリの知見を活かし、QIDO-RS/WADO-RS/STOW-RS準拠のAPIを設計・実装する |
| モバイル・タブレットから画像を参照したいが、セキュリティ面が不安 | DICOMwebと標準的なWeb認証（OAuth等）の組み合わせで、セキュアな配信を設計・実装する |
| 複数施設・複数ベンダーの画像を一元的に検索・参照したい | QIDO-RSベースの横断検索基盤や、施設間連携のゲートウェイを設計する |
| 古いDICOM実装を触れる担当者がいなくなり、クラウド化にも着手できない | 実装を引き取り、DICOMwebゲートウェイによる延命と段階的なクラウド移行を支援する（レガシーシステムの保守・開発代行と連携） |
古いDICOMシステムをDICOMweb対応にする（ラッパー構成という考え方）
既存のモダリティやPACSがC-STORE/C-FINDなど従来DICOM通信にしか対応していない場合でも、装置本体を作り替える必要はない。既存システムの手前に「DICOMwebゲートウェイ」を1枚挟み、外部（ブラウザ・クラウド・モバイル）へはWADO-RS/QIDO-RS/STOW-RSのAPIとして見せるという構成（ラッパー／アダプタ方式）が一般的である。
- 装置・PACS側は改修不要（従来どおりの運用を継続できる）
- 外部連携が必要な範囲だけをゲートウェイ経由でWeb化できる
- 段階的にクラウド移行を進められ、初期投資と切り替えリスクを抑えられる
この構成は、レガシーシステムを抱えたまま外部連携やクラウド化を検討している場合の現実的な選択肢になる。
古いDICOMシステムのDICOMweb化（WADO／QIDO／STOW対応）・クラウド連携・Webビューア開発でお困りなら
関連するサービス・特設サイト