MPPSから線量情報が消えた

DICOMには画像以外に検査情報の連携する規格が存在する。

検査の進捗や画像データの送信先を伝える為にMPPS（Modality Performed Procedure Step）という規格が存在するが以前はMPPSにX線の線量情報を含める事が出来た。

現在線量情報はRDSRを使う事により本来の？線量管理が出来るようになっているが、MPPSからはいつ退役したのだろうか？

規格書 PS3.4 2017c-2017dを見ると、DICOM 2017cから2017dの間でRadiation Dose ModuleがMPPSの規格から外されていることが分かる。

DICOM PS3.3 2017dを見ると既にモジュールごと規格から外されているので、Radiation Dose Moduleが何であったかを確認する為には PS3.3 2017cを見る必要がある。

DICOM PS3.3 2017cを見るとようやくRadiation Dose Moduleが規格されておりMPPSに含められていた線量情報がリストされている。

各装置メーカーがプライベート拡張している場合もあり、一概には言えないがMPPSの規格としては曝射ごとの線量情報はKVPとmA、mSecくらいしか無く、mGrayやmGray・cm・cmとかになると合計の量しか定義されていない気がする。 

真偽の程は分からないが、DICOM委員会ではそもそもMPPSに線量情報を含める事は無理があるし規格的にも方向性が違う感じがする中で、日本（JIRA）からの要望でMPPSに線量情報を含める事を可能にしたと聞いた事がある。

MPPSの仕組み

MPPS（Modality Performed Procedure Step）とはモダリティから送信される検査の進捗であったり検査手技の情報であり、N-CREATEとN-SETの2つのコマンドと、IN PROGRESSとCOMPLETEDの2つのステータスの組み合わせのメッセージである。

通常は、

１）N-CREATEコマンド / IN PROGRESS ステータス

２）N-SETコマンド / IN PROGRESS ステータス

３）N-SETコマンド  / COMPLETED ステータス

というシーケンスとなるが、モダリティにより　２）は省略されることもある。

N-CREATEコマンドにはほとんど検査の情報は含まれていないので、MPPSを検査情報の収集等の目的で利用するのであればN-SETコマンドを利用する事になる。

レポートシステムや電子カルテ（RIS）が検査進捗としてMPPSを利用するのであれば、

１）N-CREATEコマンド / IN PROGRESS ステータス → 検査開始

２）N-SETコマンド / IN PROGRESS ステータス → 検査中

３）N-SETコマンド  / COMPLETED ステータス → 検査終了

という進捗情報をレポートシステムや電子カルテ上に反映させることが出来る。

検査の一意性を担保する（0020、000D）Study Instance UID は N-CREATEコマンドのみに存在し N-SETコマンド には含まれない。

N-CREATEコマンド と N-SETコマンドの紐づけは MPPS の SOP Instance UID により行われる。

つまりレポートシステムや電子カルテ（RIS）が MPPS を検査の進捗管理に使用する場合、受信した N-CREATEコマンド を（0020、000D）Study Instance UID で検査リストと紐づけておいて、その後の N-SETコマンド は（0000、1000）Affected SOP Instance UID、及び（0000、1001）Requested SOP Instance UID を使って検査リストと紐づけることになる。

MPPS から線量情報が退役したり、実運用において MPPS を正確に理解しているベンダーが少なかったりして何となく MPPS の利用が進んでいない気がするが、DICOM 運用化で検査の進捗管理は MPPS 以外には出来ないと思う！！

Echo について

 DICOM 接続作業の時に実際の通信（Storage や Q/R 等）を行う前に相手の DICOM サービスが起動しているか否かを確認する手段がある。

ネットワーク的には Ping コマンドを使うが、それだと IP 層と TCP 層までしか確認が出来ない。DICOM Echo であればアプリケーション層（DICOM レベル）まで到達して応答が返ってくる。

ちなみに DICOM Echo は Verification SOP Class の DICOM通信を使っており、Echo という名前は DICOM 通信の C-ECHO コマンドからきている。

DICOM Echo は基本的に通信相手（Verification SCP）が生きているか死んでいるかを確認するだけなので、Verification SCP は Verification SCU の情報を知る必要は無い。

（Verification SCP 側は Verification SCU の情報を登録しなくても通信可能である）

通常 DICOM 通信は SCU がコネクションを張り、SCP はそれをアクセプトするだけである。

DICOM Echo は Verification SCP が Verification SCU からの C-ECHO コマンドを受け取り、既にコネクションが張られている状態で応答を返すので Verification SCU の IP アドレスやポート番号を知る必要はない。

実は Verification だけでなく Storage や Query も全てその原則によって通信する。

まぁ Verification SOP Class は運用開始されてしまえば、その後に使うことも無いのでモダリティ系なんかは未実装の場合も多い気がする。

1つのシリーズに束ねられるか？

1検査のデータには複数の SOP Class のデータが含まれることがある。

例えば超音波検査（US）では、

・US Image Storage

・US Multi-frame Storage

・Secondary Capture Image Storage

・Enhanced SR

と4つの SOP Class のデータが1検査分として出力されることがある。

異なる SOP Class のデータを1つのシリーズ（同一 Series Instance UID）の中に含められるか否かはモダリティ名を同一に出来るか否かによる。

モダリティ名はシリーズレベルの情報として定義されている為、異なるモダリティ名のデータを同一シリーズとすることは出来ない。

先の超音波検査を例にすると、下記3つの SOP Class はモダリティ名をUSに出来るので同一のシリーズ内にイメージとして登録することに問題は無い。

・US Image Storage 

・US Multi-frame Storage

・Secondary Capture Image Storage

しかし Enhanced SR は SOP Class の仕様でモダリティ名をSRとすることが定義されているので同一のシリーズとすることは出来ない。

2023年も本日が最後となりました。

良いお年を。

Specific Character Set の勘違い

Storage SCP（DICOMサーバ）だとほとんど問題にならないが、Worklist SCP（MWM）を構築すると（0008,0005） Specific Character Set の値で良く問題が起こる。

モダリティ側が Worklist SCP の C-FIND-RSP に続く Data Set の中の Specific Character Set の値について 指示をしてくるのだが、これがモダリティベンダーの大きな勘違い！！

モダリティ側は C-FIND-RQ  に  Specific Character Set  を含める事で Character Set  を指定出来ると勘違いしているが DICOM 規格では明確に否定している。

K.2.2.2 に  Specific Character Set  はマッチングキーでは無いと記述されており、詳しくはC.2.2.2 を参照しろと書いてある。

C.2.2.2 にもマッチングしない事が前提である記述となっている。

まとめると Specific Character Set はワークリスト検索とは直接関係のない Attribute であり Key では無い。

DICOM 規格上の扱いは下記のようになっている。

・SCU から Specific Character Set を指定することも Return 要求することも出来ない。
・SCU が出力する C-FIND-RQ に続く Data Setにある Specific Character Set は検索キーの中に ASCII 以外の文字列が使われた場合に文字コードを宣言するものである。
・SCP が出力する C-FIND-RSP に続く Data Set にある Specific Character Set はオーダー情報の中に ASCII 以外の文字列が使われた場合に文字コードを宣言するものである。

問題の本質はモダリティ側にあるのだが、経緯としては Worklist 構築ベンダーがモダリティ側の指示通りに Specific Character Set を調整してしまうところにあると思う。

結果的に上手く接続出来てしまう為、いつまで経ってもモダリティの開発側へレポートが上がらない。特に国内でしか販売されていないモダリティに多い気はする。

まぁモダリティ設置作業において Worklist の接続は最終段階となるので、お仕事を早く済ませてしまいたいという気持ちは十分分かるのだが・・・・

検査日、検査時間は必須か？

以前に「患者IDは必須か？」という記事を書いたことがある。

では「検査日」「検査時間」はどうか？

(0008,0020) Study Date （検査日）も(0008,0030) Study Time（検査時間）も Storage SOP Class の通信では Type2となっているので必須では無い。

しかし DICOM ディスクを作成する際は Type1となり必須となる。

検査機器であれば基本的に検査日、検査時間は自動的にセットされると思うが、スキャナ経由の画像や汎用画像（Jpeg 等）を DICOM へ変換する場合は検査日、検査時間を手動でセットする必要がある。

変換した DICOM データをサーバに送信して保管するだけであれば、規格上は検査日、検査時間は不要となるが保管されたデータを書き出す場合は前述の情報は必須となる。

データにより書出しが出来たり出来なかったりするのは運用上問題になるので、やはり DICOM 変換ソフトウェア側で必須項目としてもらうと助かるなぁ。

患者名の半角カナ文字

日本国内に限れば DICOM の運用で使用される患者名は「ローマ字」「漢字」「ひらがな」「カタカナ」かと思う。

DICOM での名前の表記は「=」で区切りながら３グループで表わすのだが、第一グループは１バイト文字でローマ字または半角カナである。
第二グループは Ideographic (表意文字)であり日本語の場合は漢字となる。
第三グループは Phonetic (発音文字)となり日本語の場合は半角カナ、全角カナ、
または全角ひらがなとなる。

本題の趣旨とは少々異なるが末尾の「=」は省略していいことになっているので、ローマ字だけの場合は「Kanja^Mei」でも「Kanja^Mei==」でもどちらでもいいことになる。

ローマ字と漢字の場合は「Kanja^Mei=患者^名」または「Kanja^Mei=患者^名=」のどちらかになる。ローマ字と発音文字（カタカナまたはひらがな）の場合は「Kanja^Mei==カンジャ^メイ」のみとなり真ん中の「==」は省略できない。
「Kanja^Mei=カンジャ^メイ」というように真ん中に「=」を１個とすると表意文字
としてカナを使っていることになるのでDICOM 規格不適合となる。
カナだけの場合は「==カンジャ^メイ」とする方法もあるが、この場合も先頭の「==」は省略できない。

本題であるが DICOM において半角カナが使用出来るか否かは利用可能である。

ただし IHE-J でも半角カナの使用を禁止しているように、半角カナという１バイトの発音文字というのは世界的には異質なようだ。

システム切り替え等の機会があれば積極的に変えておいた方が良いのかもしれない。

半角カナを使っているのは一般撮影系（CR、FPD）が多い気がする。

CR は DICOM が一般的になる前から医事システム等と属性情報の連携をしていた。

恐らく医事システムが半角カナを使っていたからなんだろうなぁと想像はできる。