UIDの裏話

DICOMでは画像やクラスを識別する為にUIDを使われる。

UIDとはUnique Identifierの略でOSI組織登録番号と各組織が付与する唯一無二の番号の組み合わせである。

クラスを表すUIDは下記のような感じとなる。

例：1.2.840.10008.1.1 （Verification SOP Class）

・1はISOの事で国際標準という意味

・2は加盟機関

・840はアメリカの国番(DICOM規格はアメリカ初なので)

・その後の番号はクラス毎に重ならいように発番されている。

UIDは画像個々にも付帯されている。

画像個々のUIDは検査単位（Study Instance UID）、シリーズ単位（Series Instance UID）、画像単位（SOP Instance UID）がそれぞれ付帯されているが、検査単位以外のUIDは装置側内部で発番している。

検査単位のUIDはオーダー側が発番する場合もあるが、オーダー（MWM）と接続されていない場合は装置側が発番する事になる。

画像のUIDも基本的にはクラスのUIDと同じ仕様で発番されている。
例：1.2.392.200036.91XX.XXXX・・・・・・

・392 は日本の国番

・200036 は日本画像医療システム工業会（JIRA）

・91XXX は装置メーカーの番号

日本の検査装置が発番する多くのUIDは 1.2.392.200036. まで共通であり、200036の枝番として各装置メーカーの識別番号が付けられている。

つまりJIRAがDICOMへのUID申請を代行しているという事である。

確証は無いが、DICOM運用が開始された当時はUIDの申請ルールも良く分からない事から（英語だし・・）JIRAが申請を代行したのだと思うが、現在も当時のまま運用を継続しているという事となる。

全部知っている訳では無いが、海外メーカーのUIDの国番の後は自社が申請した番号になっている場合が多い。

UIDの申請程度の事は基本的に効率的にやれば良いと思うが、本質を理解しながら効率的にやるのと良く分からないから丸投げするのとはちょっと違うと思うけど。

3D画像の距離計測

CTやMRの画像上での距離計測は（0028,0030）Pixel Spacingの値によりキャリブレーションして距離値を表示する。
 Axialであれば計測値に間違いは無いと思うが、3D再構成された後に斜め方向とかにした後の画像を計測した場合はどうなのだろうか？

多分（0028,0030）Pixel Spacingのみを使用した距離計測では正確な値は出ないはずである。

3D再構成画像からの計測であれば、画像の座標系を正確に把握することが重要であり、Pixel Spacingだけでなく、スライスの厚さ（Slice Thickness）や画像のオフセットなども考慮する必要がある。

計測値に高精度が必要な場合はPixel Spacingだけでなく、DICOMファイルに含まれる他のメタデータや画像情報を確認し物理的な距離を検証することが重要となる。

放射線技師さんとかであれば理解はしていると思うが、3D画像を生成するソフトウェア側の会社があまり理解していないと大した説明もせずに3D再構成画像に（0028,0030）Pixel Spacingを含めてしまう。

（0028,0030）Pixel Spacingがあれば多くのビューアは距離計測可能となるが、その値の信憑性は自己責任となる。

距離計測の変化

画像上で距離計測が出来るのは普通の事であるが、実は規格的には色々と深い内容となっていて、距離計測をDICOM規格通りに実装すると計測出来ない画像が多い。

距離計測をする為の主な情報は下記である。

（0028,0030）Pixel Spacing

（0018,1164）Imager Pixel Spacing

（0018,1114）Estimated Radiographic Magnification

（0028,0030）Pixel SpacingはCT、MR等のIODタグでありCRやDXには定義されていないタグである。

DICOM規格上はCRやDXでは（0018,1164）Imager Pixel Spacingと（0018,1114）Estimated Radiographic Magnificationの補正値を使って計測値を表示するのが正しい。

（乱暴な言い方だと直接撮影のモダリティはImager Pixel Spacingを使い、再構成をするモダリティはPixel Spacingを使う）

ところがImager Pixel Spacingを使うと計測出来ないビューアが多くある。

特にCTやMRのビューアからCRを表示出来るように作り替えたような製品ではImager Pixel Spacingでは計測出来ない事から、結局CRやDXのモダリティメーカーが（0028,0030）Pixel Spacingを使うようになってしまった。

ただCRやDXが（0028,0030）Pixel Spacingを設定するのは単なるプライベート拡張である。

2006年にCP-586にてDICOM規格が変更となり、それまで（0018,1164）Imager Pixel Spacingのみでキャリブレーションして計測値を出していたことが禁止され、距離値を出す為には（0028,0030）Pixel Spacing、若しくは（0018,1114）Estimated Radiographic Magnificationが必要となった。

更にCP-586の説明に従うと（0028,0030）Pixel Spacingと（0018,1164）Imager Pixel Spacingが同じ値であった場合はUncalibratedと見なされる事になっていて、（0018,1114）Estimated Radiographic Magnification 等による補正が必要になるという事になっている。

まぁ線源から生体中心までの距離がある撮影と再構成画像が同じキャリブレーション値を使う事自体がおかしいので当然と言えば当然かと思う。

ただ現実のCR画像の（0028,0030）Pixel Spacingと（0018,1164）Imager Pixel Spacingには同じ値が挿入されている場合がほとんどである。違反だけど・・・

そうなると過去画像も含めてCR画像のほとんどが計測不可となってしまうため、例えば（0018,1114）Estimated Radiographic Magnificationが無い場合には（0028,0030）Pixel Spacingと（0018,1164）Imager Pixel Spacingが同じであってもCalibratedとして扱うようなローカルルールをビューア側で決めるしか無い。

Tagの順番

DICOMデータには属性を識別するための「タグ」が付属している。

タグは2つの16進数にて「グループ番号」と「エレメント番号」の組み合わせで表現される。

例えば「（0010,0010）Patient`s Name 」であると最初の0010がグループ番号であり、後の0010がエレメント番号となる。

ちなみにグループ番号0010は「患者情報グループ」である。

大した話では無いがタグはグループ番号とエレメント番号の昇順に並んでいる必要がある。

（0010,0010）の次は（0010,0020）となる。

ｘ

「大した話では無い」としたのは、仮に昇順になっていないデータが送信された場合にStorage SCP側が受信拒否するのか否かはStorage SCP側の仕様による。

ルールはルールなので本来は拒否すべきではあるが、どのレベルの違反を拒否すべきかなのかには意思が必要だと思う。

ルール通り（規格通り）に作るのが一番簡単なのだが、それだと受信出来る画像が限定的になってしまうのが現実なんだよなー・・・

接続作業が無くなるかも

DICOM サーバと接続されている医療機器が変更になったり追加される場合には DICOM サーバ側と医療機器側の両社にて接続確認作業を行う。

技術者が訪問した上で作業を行う訳だし、接続に不具合や不都合が起きた場合は解消するのが使命となるので有償作業とならざる得ないのかも知れないが接続数が多くなると結構痛い出費となる。

フリー Wifi のように自動で接続してインターネットサービスを利用出来るような感じにはならないのだろうか？

一応規格としては Supplement 67 Configuration Management が DICOM 2003 から Part 15 の一部として組み込まれている。

これは DICOM 接続の自動化を目的とした仕組みであり、IP Address は家庭用ルータ同様に DHCP サーバから取得して、 AE Title や Port 番号、Transfer Syntax の DICOM パラメータについては LDAP サーバから取得するという事になっている。
SCU、SCP に関わらず LDAP サーバを利用したい AE は、LDAP クライアントを実装して
LDAP サーバから取得するということになる。

実装されれば DICOM 接続作業が必要無くなるかというと現時点では無くならない。

DICOM 接続が出来たとしても画像の解像度が適切か否かの確認やビューア側の表示設定等の確認は必要となる。

DICOM 規格に組み込まれてから20年経過しても誰も実装しようとしないのは、現時点では結局最終的な労力が変わらないからだと思われるが、将来は Ai も使って自動で適切な接続状態と出来るかも知れない。

IHE Image Manager の運用

医療情報システムの運用を標準化するプロジェクトとして IHE というのがある。

IHE はあくまでも運用を標準化するもので、画像関係の規格についてはあくまでも DICOM を使用する。

日本では IHE-J として20年程前から活動が開始されており、活動開始当初はそれなりに盛り上がった気がするが現在はいまいち感がある。

理由は明確な気がするが明言は避ける事にする(^^;)

IHE では DICOM Server に相当する Actors が Image Manager と Image Archive の2つに分かれている。Image Manager は画像管理であり Image Archive は画像保管となるのだが、多くの実運用先では DICOM Server として統合されているので運用側が分かれている事を意識する必要は無い。

IHE の Technical Framework（技術仕様書）によると、画像を保管する Image Archive が複数あり、それらを管理する Image Manager があるという構成形態を意識したことのようである。

 つまり院内に複数の DICOM Server（Image Archive） が存在していたとしても、1つの DICOM Server（Image Manager）を経由して串刺しで検索可能になるという事である。

Transaction から仕組みを読み取ると、最終的に Image Manager が MPPS を受信することで対象画像がどの Image Archive に保管されているのかを Image Manager が管理可能となるという事である。

個人的には結構理想的な運用を実現出来る気がするが、最近はサーバとビューアが自社間である必要がある事が多くて DICOM 通信により画像を取得する運用要求が減っている。

頑張って開発実装してもあんまり売れない気がするなぁ・・・

Storage Commitment について

サービスクラスには Storage Commitment というのもある。

検索してみると「データ保存委託」とかヒットしてくるのだが、これを意識して運用している人はいないと思うし、実運用的には検査装置から DICOM データを送信してエラーが無ければ終わりである。

ただ DICOM 通信的には Storage と Storage Commitment は大きく異なっている。

DICOM 通信では通常 SCU がコネクションを張り SCP はそれをアクセプトするだけである。SCU と SCP 間では既にコネクションが張られているので SCP は SCU の IP アドレスやポート番号を知る必要は無い。

（送信側情報が未設定でも受信出来る DICOM サーバはこの理屈である）

ただ Storage Commitment は上記とは内容が異なる。

SCU がコネクションを張り SCP に Storage Commitment を要求するコマンドを送った後、一旦 SCU はコネクションを切って SCP からの応答を待つ。

SCP はコネクションが切られていなければそのまま応答を返すが、コネクションが切られてしまっている場合は自分から SCU に対してコネクションを張り、応答を返すための通信を行う。このため Storage Commitment の SCP は SCU の IP や ポート番号を知っている必要がある。

何故 Storage Commitment が要求コマンドと応答が別通信にできるようになってかというとサーバーが応答をすぐに返せない状況を想定しているからである。

過去のジュークボックスやテープのストレージではデータを読んで正常に存されていることを確認するのに時間がかかるため、要求コマンドの後一旦通信を切ってゆっくりデータを確認した後に、別通信で応答を返してもらえるような通信形態が必要であった。

現在はハードディスクや SSD を使ったストレージが主流であり、データの確認はほとんど瞬時であることからもうこのような２段構えの通信は必要ない。

実運用でStorage Commitmentを体感したことがある。

外資系のモダリティであったが、DICOM サーバ側がStorage Commitmentを受け取るとモダリティコンソール側に「Archive」がラベルされた！！

単にStorageしただけではArchiveはラベルされないので、Storage Commitmentに非対応のDICOMサーバだとずっと空白のままである。

どこまで有用なのか否か分からないが何となく開発者の心意気を感じたなぁ。