ピースペース

DicomのRetrieveはMoveとStoreをペアで使うよ

leave a comment »

Q/Rサービスを担当するコマンドは、C-Find、C-Move、C-Strore
C-Findはわかりやすい、検索条件をFind要求として送って、結果をFind応答でもらう。
そして、そのFind結果から、実際の画像があるDicomオブジェクトを取得(Retrieve)するには、C-Moveを使う。
検査IDをMove要求で送って、そのMove応答で要求したDicomオブジェクトが返される。と、思うじゃないですか!?ふつー
にフツーにはまった;;

Move要求というのは、その名前が示す通り、サーバーにDicomファイルのMoveを要求する。
Move要求を受けたサーバーは、C-Stroreを使ってそのMoveを実行する。ということらしい。
Move要求を受けたサーバーは、Storeクライアントになって、
Move要求で指定された別のStoreサーバーにDicomオブジェクトを送る。
Move要求に関連するMove(Store)が完了したところ(または途中で)で、
その結果(状況)をMoveクライアントにMove応答として連絡してくれる。
実は、Retrieve用途にはC-Getもあるが、
Move/Store機能があればその目的はほぼ達成できるため、Getを実装しないサーバーがたくさんある(らしい)。
つまり、不特定のサーバーを対象にGetを期待するクライアントは作成できない。ので、まずは無いも等しい→Getコマンド

あっしが最初にMoveに期待した挙動はGetのものであり、
MoveとGetがある時点でそれは勘違いだということに気付くべきだったのだ。

なるほど!その動作を実際に確認してみれば、理屈はうまくあっている…
ということが、Dicomスタンダードにはきっとちゃんと説明してあるのだろう。
しかし、最初から勘違いを思い込んだ頭にそれを理解するのは難しい。
ひとこと 「ここはよく勘違いが起こるところなので注意してネ」があれば助かるのだが、
スタンダードを作った人にしてみれば、あっしの勘違いなんて「思いもよらない」ことだから、それは無理だ;;

一般的に、Q/RのクライアントはViewerで、サーバーはアーカイブStorageとなる。をまとめてPACSという。
PACSサーバーはもちろんStoreコマンドのサーバーで、それはいい。
上記のRetrieveシーケンスに従うと、ViewerもStoreサーバーになる必要がある。
いいかえると、Q/Rサービスのクライアント側にもサーバー側にもStoreサーバーは必要になる。
というあたりが直観しずらいので、最初の誤解が産まれる。

さらに、この誤解に拍車をかけるのがWADOで、
最新のPACSで、Viewer←Storageは、WADO経由が一般的で、
そのWADOインタフェースが、直観通りの要求/応答の仕組みなので、
もちろんWADOには罪もなにもないが、それが当たり前すぎて…
余計にMoveを最初から誤解してしまふ;;

Written by nasu38yen

2013年6月6日 @ 8:11 AM

カテゴリー: 未分類

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。