サービスクラスには 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サーバだとずっと空白のままである。
どこまで有用なのか否か分からないが何となく開発者の心意気を感じたなぁ。
