DICOMとは - 医用画像のファイル・タグ・通信とDICOMweb
DICOM（Digital Imaging and Communications in Medicine、ダイコム）とは、CT・MRI・超音波などの医用画像と関連情報を、装置やシステムの間で扱うための国際標準規格である。画像のファイル形式に加え、患者・検査・撮影条件などの情報の表し方や、画像を保存・検索・取得する通信の仕組みを定めている。
例えばCT検査では、撮影装置で作成した画像をPACS（医用画像管理システム）へ送り、医師がビューアで参照する。このとき、画像を「誰の、どの検査の、どのシリーズか」と結び付けて受け渡す基盤がDICOMである。規格の対象には画像だけでなく、計測結果や構造化レポートなども含まれ、Web連携のDICOMwebも同じ規格の一部を構成する。DICOM規格の構成
開発・連携でお調べの方へ：DICOM接続・画像連携の開発対応をご覧ください。
DICOMの「ファイル」「タグ」「通信」の違い
DICOMを理解するには、保存されるデータと、そのデータをやり取りする仕組みを分けて考えるとよい。
| 観点 | 定めていること | CT検査での例 |
|---|---|---|
| ファイル・データ形式 | 画像や関連情報をどのような構造で記録するか | CT画像を、撮影条件や検査の識別情報とともに保存する |
| タグ・属性 | 情報の項目をどう識別し、どのような値を持たせるか | 患者ID、検査日時、画像の位置、画素間隔を記録する |
| 通信・サービス | 装置やシステムの間で何を要求し、応答するか | CT装置からPACSへ画像を送り、ビューアから検索・取得する |
同じDICOM対応でも、ファイルを開く機能と、ネットワーク経由で画像を受信する機能は別である。画像を表示できるソフトウェアが、必ずPACSとの送受信にも対応しているわけではない。
DICOMファイルとJPEG・PNGの違い
JPEGやPNGは一般的な画像形式である。一方、DICOMの画像データには、画素そのものに加え、検査との対応や医用画像として解釈するための情報が含まれる。例えばCT画像では、画素値をCT値として扱うための変換情報や、表示の階調を調整する情報が使われる。
DICOMの画像をJPEGやPNGへ書き出すと、通常は特定の階調や表示条件で見える画像になる。書き出し方によっては、元の画素値、位置情報、検査情報などを引き継げない。説明資料への貼り付けと、画像処理・計測に使うデータの受け渡しでは、必要な情報が異なる。DICOM PS3.3・画像と表示に関する情報モデル
DICOM画像は必ず非圧縮なのか
DICOMには、非圧縮の画像と、圧縮された画像の両方がある。圧縮にも、元の画素値を復元できる可逆圧縮と、元に戻せない変化を伴う非可逆圧縮がある。「DICOMだから画素値が一切変化していない」とは判断できない。
データの符号化方式はTransfer Syntaxで識別する。JPEGなどの圧縮方式を使った画素データをDICOMの中に格納する場合もあり、JPEG圧縮を使うことと、通常のJPEGファイルへ変換することは別である。読み込みや転送では、送信側と受信側が対応するTransfer Syntaxの確認が必要になる。DICOM PS3.5・画素データの符号化
DICOMタグとは何か
DICOMタグは、データ項目を識別する番号である。16進数のグループ番号とエレメント番号を組み合わせ、例えば患者IDは (0010,0020) と表す。各項目には値が入り、文字列・数値・入れ子の情報などをどう扱うかはVR（Value Representation、値表現）で定める。DICOM PS3.5・データセットの構造
画像表示で使うRows・Columns（行数・列数）やPixel Spacing（画素間隔）、検査を識別するStudy Instance UIDも、タグで識別する属性である。例えば計測値の確認では画素間隔、患者情報の文字化けでは文字集合や文字列の扱いが調査対象になる。タグは付属の説明文ではなく、表示・検索・連携を支える情報といえる。
主なタグの番号・名称・意味は、DICOMタグ一覧で確認できる。
検査・シリーズ・画像はどうまとまるか
医用画像を探すときは、患者、検査（Study）、シリーズ（Series）、個々のデータ（SOP Instance）の関係が基本になる。
| 単位 | 意味 | CT検査の例 |
|---|---|---|
| 患者（Patient） | 検査の対象となる患者 | 同じ患者の今回と過去の検査をたどる |
| 検査（Study） | 関連するシリーズをまとめる単位 | ある日の胸部CT検査 |
| シリーズ（Series） | 撮影・再構成などに応じたデータのまとまり | 同じ検査の薄いスライス画像と別条件の再構成画像 |
| SOP Instance | 個々の画像やレポートなどのデータ | 1枚のCT画像、または複数フレームを含む画像データ |
検査・シリーズ・個々のデータには、それぞれStudy Instance UID、Series Instance UID、SOP Instance UIDという識別子を使う。例えば同じ胸部CT検査から複数の再構成画像を作る場合、同じStudyの中で別のSeriesとして整理できる。DICOM PS3.3・情報モデル
1ファイルに画像が何枚入るのか
DICOMのファイル形式では、1ファイルに1つのSOP Instanceを格納する。ただし、画像のSOP Instanceには、1フレームのものと、複数フレームを扱うマルチフレームのものがある。多数のファイルで1つのシリーズを構成する場合も、1ファイルに複数のフレームをまとめる場合もある。「1ファイル＝1検査」でも「DICOMはすべてマルチフレーム」でもない。DICOM PS3.10・ファイル形式、PS3.3・Multi-frame Module
DICOM通信は院内で何をしているか
放射線検査では、検査の依頼、撮影予定の取得、画像の保存、結果の参照という流れがある。DICOMは、このうち画像の送受信や、撮影装置と部門システムの業務情報の連携などを担う。
| 目的 | 主なサービス・処理 | 利用場面 |
|---|---|---|
| 画像を保存する | Storage／C-STORE | 撮影装置からPACSへ画像を送る |
| 検査や画像を探す・取得する | Query/Retrieve／C-FIND、C-MOVE、C-GET | ビューアなどが条件を指定して検索し、必要な画像を取得する |
| 撮影予定を取り込む | Modality Worklist（MWL／MWM） | 撮影装置が患者・検査の予定情報を取得し、手入力を減らす |
| 検査の実施情報を通知する | MPPS | 撮影装置が検査の開始・完了などの実施情報を通知する |
例えば撮影装置がMWMで取得した患者・検査情報を画像に引き継ぎ、C-STOREでPACSへ送ると、予定と撮影画像を対応付けやすくなる。MWMとMPPS、画像保存はそれぞれ役割が異なり、必要なサービスを組み合わせて業務をつなぐ。IHE・Scheduled Workflow.b
PACSは画像を管理するシステム、RISは放射線部門の業務を管理するシステムであり、DICOMはその間などで利用する規格である。検査依頼や患者情報の連携にはHL7も使われる。IHEは、こうした規格を具体的な業務でどう組み合わせるかを整理する取り組みである。詳しくはPACS、RIS、HL7の解説を参照。
DICOMweb・クラウド・AIとの関係
Webブラウザやクラウドから画像を利用する
DICOMwebは、HTTPを用いてDICOMデータを扱うWebサービス群である。代表的なものに、検索のQIDO-RS、取得のWADO-RS、保存のSTOW-RSがある。院内で使われてきたDICOM通信に加え、Webアプリケーションやクラウドの画像基盤を組み合わせる際の選択肢になる。DICOM PS3.18・Studies Service
例えば、撮影装置から従来のDICOM通信で画像を受け取るサーバーを用意し、ブラウザのビューアへDICOMwebで画像を提供する構成が考えられる。従来の装置とWeb側の機能を接続できる一方、接続先の対応サービス、認証・アクセス権、画像量に応じた転送性能の設計が必要になる。WebビューアやクラウドPACSという名称だけで、DICOMwebに対応しているかは判断できない。
具体例として、WebビューアのOHIFは、公式ドキュメントでOrthancやDCM4CHEEなどの画像サーバーとのDICOMweb接続を説明している。画像を保管するサーバーと表示するアプリケーションを、標準のWebインターフェースで組み合わせる実装例である。OHIF・DICOMweb接続の公式ドキュメント
AI解析の結果を画像と一緒に扱う
AIとの連携では、解析用に画像を渡すことに加え、解析結果を元画像に結び付けて返すことが重要になる。例えば、抽出した臓器や領域をDICOM SEG（Segmentation）、計測値などをDICOM SR（Structured Reporting）で表現する構成がある。これらはAI専用の形式ではなく、画像に関係する結果を共有するためにも使える。DICOM PS3.3・Segmentation IOD、Structured Report Document IODs
ただし、結果をDICOM形式で出力しても、受け手のPACSやビューアがその種類のデータを保存・表示できるとは限らない。元画像との対応、対応するSOP Class、結果の表示方法まで確認する必要がある。画像の受信から結果の参照までを一連の連携として設計する点は、通常の画像連携と共通している。
DICOMファイルを開く・確認するときのポイント
DICOM画像の表示には、そのデータに対応したDICOMビューアを使う。.dcm という拡張子が使われることもあるが、ファイル名だけでは内容や対応可否を判断できない。一般の画像ソフトで開けない場合も、直ちにファイルの破損とは限らず、画像の種類や圧縮方式、マルチフレームへの対応を確認する。
開発・検証では、見た目だけでなくタグや通信ログも確認できると、表示と接続の問題を切り分けやすい。リベルワークスのDICOMアシストは、開発・研究用途のビューアとして、画像・タグの表示、タグ比較、DICOM通信などの機能を提供している。
また、検証やデータの二次利用では患者情報の扱いも確認する。患者氏名のタグだけを削除しても、ほかの属性、プライベートタグ、画像に直接書き込まれた文字などに識別情報が残る場合がある。DICOMの機密性プロファイルでは、属性の処理や画像内情報の除去などを扱っており、必要な処理はデータと利用目的に応じて選ぶ。DICOM PS3.15・Attribute Confidentiality Profiles
「DICOM対応」の機器同士なら接続できるのか
「DICOM対応」は、すべての機能・画像形式に対応するという意味ではない。接続時にはDICOM Conformance Statement（適合性宣言書）を照合し、画像などの種類を示すSOP Class、サービスを利用・提供する役割であるSCU／SCP、Transfer Syntaxなどの対応範囲を確認する。DICOM PS3.2・適合性宣言書
例えば疎通確認のC-ECHOが成功しても、必要なCT画像の保存や検索まで成功するとは限らない。接続条件に加え、対象データで送信・保存・表示まで確かめる必要がある。AE Titleの設定や症状別の確認方法は、DICOM接続時の確認事項で解説する。
DICOM連携の開発について
撮影装置とPACSの接続、既存システムへの画像連携機能の追加、接続先の変更に伴う改修についてご相談いただけます。リベルワークスでは、DICOM連携の実装、既存実装の調査・改修、画像サーバーやビューアの開発に対応しています。