nabeの雑記帳

DICOMという医用画像のフォーマットおよび医療画像通信規約があり、その通信規約の部分についてのまとめです。DICOMがなんであるか知ってる人向けです。

個人的に必要な最低限Query/Retrieveする範囲のみの情報で、網羅はしていません*1。しかし、この情報があればあの厄介かつ難解な規格書を読むのが相当楽になるかと思います。

• はじめに
• 資料
• 通信の概要
  • PDUの種類
  • A-ASSOCIATE
  • A-RELEASE
  • A-ABORT
  • P-DATA
  • クライアント側からみた実際の流れ
• A-ASSOCIATE-RQ, A-ASSOCIATE-AC共通
• A-ASSOCIATE-RQ
  • アプリケーションコンテキスト
  • プレゼンテーションコンテキスト
  • ユーザー情報
• A-ASSOCIATE-AC
  • プレゼンテーションコンテキスト
• A-ASSOCIATE-RJ
• P-DATA-TF
  • プレゼンテーションデータアイテム
• A-RELEASE-RQ
• A-RELEASE-RP
• A-ABORT
• PDV, DIMSEメッセージ
  • コマンド要素、データ要素の形式
  • VRの形式（一部抜粋）
  • シーケンス要素の特殊処理
• Query/Retrieveの実際
  • C-FIND-RQ
  • C-FIND-RSP（C-FIND-RQの応答）
  • 検査画像の情報を取得するまで
• C-MOVEによる画像データの取得
  • C-MOVE-RQ
  • C-MOVE-RSP
  • C-STORE-RQ
  • C-STORE-RSP
• DICOM画像ファイルの復元
  • メタ情報内のタグフォーマット
  • メタ情報以外のタグフォーマット
• その他

はじめに

DICOMの規格書はJIRA（日本画像医療システム工業会）のページより日本語訳をダウンロードすることができますが、公開の仕様でありながらなぜこのようなまとめが必要かというのが頭の痛い問題です。

• TCP/IPではなく元々RS-232などのシリアル通信用に作られた規格。
• 時代の変化と共にTCP/IP専用になってはいるが、古い規格をただ乗せただけ。
• ネットやPCなどのエンジニアが作った規格ではないと思われる。
• おそらくエンジニアではない人が翻訳している。*2
• 記述がOSI 7層モデル準拠である。
• 資料として検索することなど微塵も考えてない全角英字のオンパレード*3

つまりエンジニアの視点から見ると規格書が極めてまどろっこしい上に分かりにくいのです。

資料

DICOMの規格書（本家）はPS 3.1からPS 3.20までの膨大な分冊にわかれていて、まずこの時点で頭痛がしてきます。タイトルをみても何を説明しているのかさっぱり不明です。

DICOM通信のクエリーリトリーブによりデータを取り出したい場合、メインとなるのは以下3冊（上から３冊）のようです。

PS 3.8（第8巻）メッセージ交換のためのネットワーク通信サポート

DICOM通信をTCP/IP上で行う方法について述べられています。

PS 3.7（第7巻）メッセージ交換

確立されたTCP/IP通信路で行う内部通信形式のコマンド部分がまとめられています。

PS 3.4（第4巻）サービスクラス仕様

上記コマンドに付随して使用する「データ部分」がまとめられています。

PS 3.10（第10巻）媒体相互交換のための媒体保存とファイルフォーマット

DICOM画像ファイルフォーマット

通信の概要

• PDU……プロトコルデータユニット（プロトコルデータ単位と訳されている（汗））。通信において1回に送ったり受け取ったりする単位。HTTPで言えば、リクエスト全体がひとつのPDU、それに対する応答全体が１つのPDU。
• ビッグエンディアン。
• 長さの数値は符号なし。

PDUの種類

• A-ASSOCIATE-RQ …… Request
• A-ASSOCIATE-AC …… Acknowledge
• A-ASSOCIATE-RJ …… Reject
• P-DATA-TF
• A-RELEASE-RQ …… Request
• A-RELEASE-RP …… Response
• A-ABORT

A-ASSOCIATE

通信路（アソシエイション）の確立のためのやり取り。クライアント側から通信路確立要求を出し、サーバ側がそれを承認もしくは拒絶する。

TCP/IPが接続されている時点でもう通信路はできていることなど、もちろん気にもしない。

A-RELEASE

通信路（アソシエイション）開放のためのやり取り。クライアント側から通信路の開放を要求し、サーバ側がそれに応答する。

TCPのソケットをクローズすればいいだけではないかと突っ込んではいけない。

A-ABORT

通信路の異常開放。クライアント側から一方的に通信の中断を通知する。

P-DATA

確立された通信路上での「DICOMメッセージ交換」に使用する。

クライアント側からみた実際の流れ

1. 指定のTCPポートに接続
2. A-ASSOCIATE-RQの送信
3. A-ASSOCIATE-ACもしくはA-ASSOCIATE-RJの受信。後者ならexit
4. P-DATA-TFによるDICOMメッセージ交換
5. A-RELEASE-RQの送信
6. A-RELEASE-RPの受信
7. TCPセッションクローズ

A-ASSOCIATE-RQ, A-ASSOCIATE-AC共通

A-ASSOCIATE-RQ

可変アイテムには以下のすべてを含む。

• １つのアプリケーションコンテキスト（応用コンテキストと訳されている（汗））
• １つ以上のプレゼンテーションコンテキスト
• １つのユーザー情報

アプリケーションコンテキスト

コンテキスト名はISO 8824およびISO 9834-3で定義される、世界中でユニークなアプリケーションオブジェクト識別子みたいです。このバージョンのDICOM通信アプリケーションでは以下を使えばよいようです。

1.2.840.10008.3.1.1.1

プレゼンテーションコンテキスト

プレゼンテーションコンテキストは複数存在することがあります。異なる操作を一度に行う場合や、異なる転送構文での転送を一度に行う場合が該当します。その場合、A-ASSOCIATE-ACにおいてそれぞれのコンテキストIDを示し「許可、不許可」を個別に応答します。

抽象構文（Abstract Syntax）

この詳細はQuery/Retrieveの説明で述べます。

転送構文（Transfer Syntax）。

PS 3.5によればこの構文名はDICOM暗黙VRリトルエンディアン転送構文（これはすべてのDICOM実装でサポートされるとある）を指定すれば良いようです。

1.2.840.10008.1.2

ユーザー情報

最大データ長ネゴシエーション。

最大受信長を0や64KB以上に設定したら失敗するアホな実装（これがお高い売り物なんだから信じられない……）がありましたので、16KBに設定するのが無難なようです。ここで設定したPDUよりも大きなサイズのP-DATA PDU（ヘッダのlength基準）は送られなくなります（逆に相手が指定してきた場合は、そのサイズよりも大きなP-DATA PDUは送ってはいけない）。

その他、PS3.7によれば「Item Type 52h（実装UID）」および「Item Type 55h（実装名）」が通知・交換される。これらは特定のDICOM実装同士が互いを認識しあうために使われますが、実装UIDの通知は必須になっています。

K-PACSでは以下の値が使われてるようで、UIDを登録・取得できない場合はISO 8824およびISO 9834-3準拠で被らなそうな値を適当にもじって使えばよさそう*4。実装名は半角英数字および「.」「_」で構成すればよさそうです。

[52h] Their Implementation Class UID: 1.2.826.0.1.3680043.2.1396.999
[55h] Their Implementation Version Name: CharruaVista

またその他、アイテムタイプ51h-FFhは利用者情報サブアイテム用として割り当てられ、その詳細はPS 3.7 D3.3.2に定義されている。

A-ASSOCIATE-AC

可変アイテムには以下のすべてを含む。

• １つのアプリケーションコンテキスト
• １つ以上のプレゼンテーションコンテキスト
• １つのユーザー情報

アプリケーションコンテキスト（10h）、ユーザー情報（50h）は、A-ASSOCIATE-RQと同一である（同じ識別子を返す模様）。

プレゼンテーションコンテキスト

リザルトについて。

• 0 : アクセプト
• 1 : ユーザーリジェクト
• 2 : 理由なしリジェクト
• 3 : 抽象構文がサポートされていない
• 4 : 転送構文がサポートされていない

A-ASSOCIATE-RQと異なりサブアイテムとして転送構文のみ持つことに注意してください。

A-ASSOCIATE-RQにプレゼンテーションコンテキストが複数存在した場合は、それぞれ個別のコンテキスト（抽象構文＝操作指示および転送構文）についての「許可、不許可」を個別に応答します。応答しないものがある場合、不許可とみなされるようですが、リクエストにあったすべてのプレゼンテーションコンテキストについて応答するほうが望ましいと言えます。

またあるメッセージIDで非対応の転送構文が指定されたときは、対応している転送構文に書き換えてACを返信してあげれば、その形式で送ってくるようです。

A-ASSOCIATE-RJ

拒絶理由について。Source=1のとき。

• Source=1のとき
  • 1 : 理由なし
  • 2 : アプリケーションコンテキストがサポートされない。
  • 3 : Calling AEが認識できない（正しくない）
  • 7 : Called AEが認識できない（正しくない）
  • 4-6,8-10 : 予約済
• Souce=2のとき
  • 1 : 理由なし
  • 2 : サポートされないプロトコルバージョン
• Souce=3のとき
  • 1 : 一時的輻輳
  • 2 : ローカル制限超過
  • 0,3-7 : 予約済

P-DATA-TF

プレゼンテーションデータアイテム

コンテキストIDは「A-ASSOCIATE」によりネゴシエーションされたコンテキストIDを示します。これにより、どんな操作か（抽象構文）、どの形式で転送するか（転送構文）を示しています。

A-RELEASE-RQ

A-RELEASE-RP

A-ABORT

Source=1のときの理由は以下の通り。

• 0 : 理由なし
• 1 : 認識できないPDU
• 2 : 予期しないPDU
• 3 : 予約済
• 4 : 認識できないPDUパラメタ
• 5 : 予期しないPDUパラメタ
• 6 : 無効なPDUパラメタ

PDV, DIMSEメッセージ

P-DATAによりやりとりされる実体がDIMSEメッセージです。

プレゼーテーションアイテム（PDV）が１つであるとき、P-DATA PDUは次のようになります。

PDVは「コマンド集合」もしくは「データ集合」のどちらかです。両方同時に持つことは許されず、ひとつのPDUは必ずどちらかのPDVを持ちます。これを示すのがデータヘッダです。（PS 3.8付属書Eより）

• Headerのbit 0
  • 1 : 続くフラグメントがコマンドである
  • 0 : 続くフラグメントがデータである
• Headerのbit 1
  • 1 : このPDV中に最後の要素を含む
  • 0 : このPDV中に最後の要素を含まない

Headerのbit 1が0の場合、続いて送られてくるP-DATAの中のPDVが後ろに続いているとみなして処理します。例えば、256byteの大きさを持つPDV*5中のとある要素が512byteのサイズをもつ場合、1つめのPDVからあふれた分のサイズは続いてのPDVから読み込みます。

• P-DATA PDU #1
  • PDUヘッダ
  • PDVヘッダ = 0
  • PDV (256byte)
    • 要素X ヘッダ8byte(データ長さ120) + データ120byte
    • 要素Y ヘッダ8byte(データ長さ240) + データの先頭120byte
• P-DATA PDU #2
  • PDUヘッダ
  • PDVヘッダ = 2
  • PDV (256byte以下)
    • 要素Y データの後半120byte
    • 要素Z ヘッダ8byte + データ

要素ヘッダの途中で複数のP-DATA PDUに分割されることも考えられるため、柔軟な実装が必要になります。（後に具体例で説明しています）

コマンド要素、データ要素の形式

コマンド集合やデータ集合はそれぞれ、複数の「コマンド要素」や「データ要素」から構成されます。要素はそれぞれ独自のタグ（4byte）を持ち、各要素にはVRと呼ばれるデータ形式が予め決められています。（PS3.5の7.1.3）

これまでと異なり、各要素中の値（数値）はリトルエンディアンで表現されます。A-ASSOCIATE-RQによって「暗黙VRリトルエンディアン転送構文（1.2.840.10008.1.2）」を指定しているためです。*6

VRの形式（一部抜粋）

VRに対応する値の形式はPS 3.5の6.2で定義されています。サイズはすべて偶数である（偶数でなければならない）。

範囲照合の詳細はPS 3.4のC.2.2.2.5参照。サイズが「文字」となっているものはワイドキャラクター（日本語等）においては、byte数と一致しないことがあるらしい（未確認）。

シーケンス要素の特殊処理

DICOM通信においてデータを取得する際、シーケンスを適切に処理する必要があります。

シーケンスの詳細は「PS3.5 7.5」にありますが、要するに一つの項目に複数のデータが列挙された形式です。ここではデータの切り出しについてのみ述べます。中身を詳細に処理したい場合は仕様書を参照してください。

（VR非明示リトルエンディアン転送では）シーケンスデータのアイテムは、「正しい長さ」か「FFFFFFFFhの長さ」を持ちます。後者は長さが未定義であることを示します。鵜呑みにして処理するとその後のアイテムがパースできず痛い目を見ます。シーケンスデータは「FE FF DD E0 00 00 00 00」(FFFE, E0DD)で終わります。この部分まで含めて切り出して上げれば良いわけです。*8

シーケンスとして登録されているVRをすべて処理プログラム側で持つのが本来の正しい処理かもしれませんが、そうも言ってられないので、次の方法で処理をしました。

• シーケンスデータの長さが「FFFFFFFFh」でなければ通常のとおり処理する。
• データ長さが「FFFFFFFFh」でデータの先頭が「FEh FFh」で始まるデータをシーケンスデータとみなす。
• シーケンスデータの終わりは単純に8byteの文字列マッチングで「FEh FFh DDh E0h 00h 00h 00h 00h」の手前までを切り出す。

（追記）シーケンスは入れ子になることがあります。その場合の処理はより複雑になります。入れ子構造を保って切り出さないと、dcmj2pnmなどのコマンドで弾かれることがあります。

Query/Retrieveの実際

以上を踏まえて、クエリー・リトリーブにより情報を取得する方法について述べます。

規格書PS 3.4およびPS 3.7 E.1によれば、Query/Retrieveには次のSOPクラスとコマンドコード（タグ(0000,0100)の値）が割り当てられています。

このSOPクラスはA-ASSOCIATE-RQの抽象構文として送信されます。なおC-GETはサポートされないことが多く、C-FINDとC-MOVEを使うのが定石のようです。

C-FIND-RQ

これらのコマンドは、P-DATA PDUにおけるPDVの中身としてコマンド集合とデータ集合により表現されます。ダンプしてみてると2つのPDVに分けるようです。

• P-DATA (集合ヘッダ + コマンド集合）
• P-DATA（集合ヘッダ + データ集合)

PS 3.7に9.3.2.1に、C-FINDリクエストコマンドのコマンド要素の構成が書かれています。要素は必ず偶数バイトであることに注意してください。文字列ならば後ろに SPACE(20h) を付加します。

この後ろにデータ集合が続きます。PS 3.4のC.6.1.1.3にどのようなデータを付属させるか説明があります。各タグのVRについてはPS 3.6に説明があります。*9

※データ集合タイプが0101h以外のときは後ろにデータ集合が続きます。データ集合タイプが0101hのときはデータ集合は続きません。

Query/Retrieveはその取得する情報によって、レベルが定義されています（PS 3.4 C6.2）。です。

• PATIENT : 患者情報
• STUDY : 検査情報
• SERIES : シリーズ情報（※上記表では「SE」表記）
• IMAGE : 複合オブジェクトインスタンス情報（※上記表では「IMG」表記）

１人の患者は１つ以上の検査情報を持ち、1つの検査情報は１つ以上のシリーズ情報を持ちます。１つのシリーズには１つ以上のIMAGEが含まれます。つまり、上から包含関係になっていることに注意してください。

例えば、CTならこんな感じです。

• [STUDY]1回のCTの検査
  • [SERIES]足先から足の付根までの撮影データ
    • 画像1
    • 画像2
    • 画像3
    • 　:
  • [SERIES]頭部撮影データ
    • 画像1
    • 画像2
    • 画像3
    • 　:

患者情報のタグについてはかなり省略しました。

• U 固有キー属性
• R 必要キー属性
• O 任意選択キー属性

属性は、Rは多分情報として必ず返せ（持て）、Uはその情報を一意に決めるためのIDという意味だと思われます。しかしながら、とある実装ではRを必ず返すわけでもなく、よく分かりません。とりあえず、例えばモダリティなど特定の情報を取得したい場合はデータサイズ0で送りつけると返してくれます。どうやら「どの情報によって絞り込むか」を決めると同時に、「どの情報が欲しいかC-FIND時のデータ集合の要素があるかないかによって指定する」ようです。

なお、例えば検査情報を取得するのにシリーズ番号を指定するなど不正な項目を指定するとエラーが返ってきます。また表では「O」になっていませんが、検査情報やシリーズ情報を取得する際に、患者名等を取得することもできるようです。

C-FIND-RSP（C-FIND-RQの応答）

これものP-DATA PDUにおけるPDV（集合ヘッダ + コマンド集合）の中身として送られてきます。

ステータスの詳細（PS 3.4付属書K 4.1.1）。

クエリーに対して複数のマッチデータがある場合、P-DATA（集合ヘッダ + データ集合）がその数だけ存在する。データ要素についてはC-FIND-RQ参照。

受信側のフローは以下のとおり。

1. コマンド集合のP-DATA PDUを送信する。
2. データ集合のP-DATA PDUを送信する
3. コマンド集合のP-DATA PDUを受信する。
   • Statusが0000hならば正常終了（これ以上処理しない）
   • StatusがFF00h, FF01hのどちらでもなければ異常終了（これ以上処理しない）
4. データ集合のP-DATA PDUを受信する。（データ集合タイプ != 0101h の時）
5. 3に戻る
6. （C-MOVE/C-GET時）最後のStatusがB000hの場合、続けてデータ集合P-DATA PDUが送られてくる。これには失敗インスタンスリスト(0008,0058)が入っている。*10

受信したデータ集合の数だけ、要求した検索条件（C-FIND）にマッチしたデータが存在したことになります。

P-DATAは続けて送られてきますので、初回のコマンド受信以外は socket に対して select しないほうが無難です。

検査画像の情報を取得するまで

1. QR Levelを「STUDY」にして検査データ（複数）を取得する。条件として、患者IDを指定したり、検査時期を指定したりといった検索条件を付加することができる（K-PACS等の実装を参照のこと）。この際「検査インスタンスUID（study_uid）」を忘れず取得すること。
2. 取得した検査データに含まれるシリーズデータを取得する。検査データごとに「検査インスタンスUID（study_uid）」を指定して、その検査に含まれるシリーズ（複数）を取得する。この際「シリーズインスタンスUID（series_uid）」を忘れず取得すること。

このような手順で画像情報までは取得できますが、C-FINDでは画像そのものを取得することはできません。

なお、検査インスタンスUIDは世界で唯一であることが保証されています。*11

C-MOVEによる画像データの取得

C-FINDによって得られた情報から、実際に画像を取得する方法を述べます。

実際に画像データを取得するためには C-MOVE-RQ（PS3.7 - 9.3.4）を発行し、指定したDICOMサーバ（通常、自分自身）に対してデータを転送するように要求します。要求時はAEタイトルのみしか指定できませんので、DICOM/PACSサーバに予め自分自身が登録されいる必要があります。

仕様書を読むとC-GETが適当な気もするのですが、C-GETを実装しているPACSサーバはほとんどありません。

具体的な手順は以下のようになります。

1. 【自分 → 相手：通信路１】C-MOVE-RQを発行
2. 【自分 ← 相手：通信路２】C-STORE-RQにより画像データが送られてくる
3. 【自分 → 相手：通信路２】C-STORE-RSPを発行。画像がまだあれば続けて2に戻る。
4. 【自分 ← 相手：通信路２】A-RELEASE-RQ
5. 【自分 → 相手：通信路２】A-RELEASE-RP
6. 【自分 ← 相手：通信路１】C-MOVE-RSPによりC-STOREの結果が送られてくる
7. 【自分 → 相手：通信路１】A-RELEASE-RQ
8. 【自分 ← 相手：通信路１】A-RELEASE-RP

通信路2は相手から自分に対して接続してきますので、こちら側にC-STOREに対応したDICOMサーバが必要になります。非常に厄介な仕様です……。

C-MOVE-RQ

以下詳細はPS3.7 9.3のプロトコルをみてください。

C-MOVE-RSP

C-STORE-RQ

これに続けて、データ集合を含むP-DATA PDUが送られてきます。

このときのコマンド集合とデータ集合を一体としたものが、１つのDICOM画像形式になります。

C-STORE-RSP

DICOM画像ファイルの復元

C-MOVE（C-STORE）で得られた画像からDICOM画像ファイル（.dcm）を復元することができます。PS3.10にヘッダの形式が書かれています。

これだけです。メタ情報の内容はDICOM通信のA_ASSOCIATEに相当し、明示VRリトルエンディアンでエンコードされます。このエンコードは、暗黙VRとはアイテムヘッダの構成が異なり、ヘッダ中にVRを明示する必要があります。

メタ情報内のタグフォーマット

VRが「OB,OW,OF,SQ,UT,UN,VR」のどれかの場合。（PS3.5の7.1.2）

VRが上記以外の場合。

これだけ注意すればヘッダの構成は簡単です。ヘッダに続けて画像データを書き出します。

• なお転送構文UID集合はメタ情報の中にのみ存在し、他の場所で書くことは禁止されています。
• メタ情報以外の部分では「VR」部分は付きません。

メタ情報以外のタグフォーマット

基本的にはC-MOVE（C-STORE）で得られたデータ集合をそのまま書き出すだけです。メタ情報の転送構文UIDにて「1.2.840.10008.1.2」を指定しておけば、基本的に暗黙VRリトルエンディアン（同じく1.2.840.10008.1.2）により得られたデータをそのまま書き出せば良いことなります。

なお、VRがSQであるシーケンスデータは未定義長さ（0xFFFFFFFF）を持ちますが、ファイルに書き出すときに正しいシーケンスの長さ（シーケンス要素の長さ）を指定してあげます。*12

作成した画像ファイルはDICOM ViewerやIrfanViewなどで表示できます。これらの閲覧ツールは作成したファイルが正しいか確認するのに使用できます。ただコントラスト（WC/WW）を本来の値で表示したり変更したいときなど、前者のようなDICOM専用ビュアーで見るほうがよいでしょう。

その他

Perlmagick（ImageMagick）で処理する際のメモ。

	$image->Set( 'dcm:display-range' => 'reset' );
	$image->Read( 'file.dcm' );
	$image = $image->[0];
	$image->AutoLevel();

DICOM関連の開発のご相談がありましたら、連絡ください。Windowsアプリでも、Webアプリでも何でも。