DICOM接続でつながらないときは - AE Title・SCU/SCPと確認手順
DICOM対応の装置やシステムでも、対応サービス、画像形式、接続設定が一致しなければ、目的の連携は成立しない。DICOMは一つの機能ではなく、画像保存、検索・取得、ワークリストなどのサービスと、それぞれで扱う情報を定めた規格だからである。
本ページでは、院内の従来型DICOM通信を中心に、接続できない場合や、接続後に画像を利用できない場合の確認事項を整理する。具体的な設定値は、製品のDICOM Conformance Statement（適合性宣言書）と接続仕様に基づいて確認する。DICOM PS3.2：Conformance Requirements
接続調査や改修をご希望の方へ：DICOM接続・既存実装の改修対応をご覧ください。
最初に「何ができないか」を分ける
| 症状 | 最初に確認する対象 |
|---|---|
| 接続要求が相手に届かない | IPアドレス、ポート、経路、接続許可 |
| 接続要求が拒否される | AE Title、サービスの対応、アソシエーションの交渉結果 |
| C-ECHOは成功するが画像を送れない | StorageのSOP Class、Transfer Syntax、SCU／SCPの役割 |
| 検索できるが画像を取得できない | C-MOVE／C-GETの対応、転送先、画像送信経路 |
| 受信できるが表示・紐づけに問題がある | 画像形式、ビューアの対応、患者・検査情報、文字コード |
この表は切り分けの起点である。症状だけで原因を断定せず、送信側・受信側のログと設定を照合する。
Conformance Statementの読み方
Conformance Statementには、製品が実装するDICOMサービスや役割、対応する転送構文、設定項目などが記載される。製品名だけでなく、対象バージョンに合う文書を確認する。DICOM PS3.2：Service and Interoperability Description
| 項目 | 意味 | 接続時の見方 |
|---|---|---|
| AE Title | DICOMのアプリケーション実体を識別する名前 | 相手に登録する名前と一致しているか |
| SCU／SCP | サービスを利用する側／提供する側 | 必要なサービスについて役割が成立するか |
| SOP Class | 扱う情報と操作の組み合わせ | 送る側と受ける側で対象が一致するか |
| Transfer Syntax | データの符号化や画像圧縮などの方式 | 共通して扱える方式があるか |
例えば「CT画像を送る」といっても、通常のCT画像とEnhanced CT画像ではSOP Classが異なる。ModalityがCTというだけで、受信・表示できるとは限らない。
AE Title・IPアドレス・ポートを確認する
IPアドレスとポートはネットワーク上の接続先を示す。AE TitleはDICOMのアプリケーション実体の名前であり、IPアドレスとは別の設定である。
接続要求を出す側のCalling AE Titleと、接続先として指定するCalled AE Titleを、両側の登録内容と照合する。製品によっては、接続を受け入れるAE Titleや接続元が制限されている。装置更新やネットワーク変更後は、片側だけ設定が変わっていないか確認する。
クラウドや別ネットワークをまたぐ場合は、接続先の値に加え、両方向の到達性や中継構成を確認する。設定を一律に緩めるのではなく、必要な通信の送信元・宛先・方向を特定する。
C-ECHOが成功しても画像転送の確認は必要
C-ECHOはVerification Service Classによる確認であり、画像を保存するC-STOREとは別のサービスである。C-ECHOが成功しても、StorageのSOP ClassやTransfer Syntaxの対応まで検証できたことにはならない。DICOM PS3.4：Verification Service Class
画像送信では、実際に扱う種類の画像でC-STOREを実施し、応答ステータスと受信側の登録・保存結果を確認する。単一のテスト画像だけでなく、必要に応じてマルチフレームや圧縮画像など、接続対象が出力する形式を含める。保存できる範囲と、ビューアが表示できる範囲も同一とは限らない。
C-MOVEで検索後の取得に失敗する場合
C-MOVEでは、取得を要求された側が、指定された転送先に対してC-STOREで画像を送る。この画像送信は、C-MOVEの要求とは別のアソシエーションで行われる。DICOM PS3.4：C-MOVE Operation
したがって、ビューアからPACSへ問い合わせできても、PACSから画像受信先へ接続できなければ取得は失敗し得る。例えば、移行後のPACSに転送先AE TitleとIPアドレス・ポートの対応が登録されていない、あるいは戻り方向の接続が許可されていない、といった状況を確認する。
C-GETは同じ方式ではないため、使用する取得サービスを特定してから切り分ける。
受信後のタグ・文字コード・画像表示を確認する
画像を受信できても、患者IDの発行元、検査番号、Study Instance UIDなどの扱いが一致していなければ、目的の検査に紐づかない場合がある。複数施設の画像を集約する場合は、同じ患者ID文字列が別の患者を示す可能性も考慮して、識別のルールを設計する。
文字化けでは、Specific Character Set（0008,0005）と実際の文字列の符号化、受信側・表示側の対応を確認する。見た目だけに合わせて文字コードの宣言を書き換えると、データの実体と宣言が食い違う。タグとデータセットの解釈を揃えることが必要である。DICOM PS3.5：文字集合と文字列
調査に使うサンプルは、患者情報を適切に処理した検証用データを用意し、問題が起きる形式・タグ・操作を再現できるようにする。
DICOMwebでは確認項目が変わる
DICOMwebはHTTPを利用するため、APIのURL、認証・権限、対応する検索条件やメディアタイプなども確認対象になる。従来型DICOMのAE Title設定だけでは、Web APIの接続条件は決まらない。
ゲートウェイを介する場合は、Web側の要求と、内部で行われるDICOM通信を分けてログを確認する。Web側で成功応答が返る範囲と、その後の登録・変換処理の完了条件は、製品の仕様に沿って確認する。DICOM PS3.18：Studies Service
DICOM接続・既存実装の改修について
接続先の変更で通信できなくなった場合や、既存のDICOM実装を調査して改修したい場合にご相談いただけます。リベルワークスでは、通信仕様の解析、他社システムとの接続処理、既存実装の改修・保守に対応しています。