DICOMの働き
複雑な医療環境に秩序をもたらすために、DICOMは実世界のモデル（DICOM情報モデル）に基づいた独自の用語を使用しています。そのモデルについて、簡単に説明したいと思います。
以降の解説は抽象的な説明にとどまりますが、続編で実践的な例を読み進めていただくにあたり、必要な用語の意味の整理を提供する解説になるよう心掛けました。
DICOMでは、現実世界のすべてのデータ（患者、検査、検査装置など）は、それぞれの特性や属性を持つ「オブジェクト」として捉えます。
お恥ずかしい話ですが、オブジェクトという用語を聞き慣れない方は多いでしょう（私もその一人です）。コンピュータ・プログラミングを経験されている人には馴染み深いものですが、そうでない人には宇宙語です。
私は、オブジェクトのことを人が考える何らかの概念（例えば、患者、検査、検査装置のように）だと思うことにしています。
さて、このオブジェクトと属性の定義は、DICOM Information Object Definition（IOD）に従って標準化されています。
このIODはオブジェクトの特性を記述する属性の集合体になっています。
例えば、患者について考えたいと思います。現実世界の臨床で患者について知りたいことは、例えば、患者の名前、患者のID、性別、年齢、体重、喫煙状況などが挙げられます。
では、現実世界の患者を患者IODとして記述したいとします。これは非常にシンプルで、患者の名前、患者ID、性別、年齢、体重、喫煙状況など、臨床的に関連するすべての患者情報を把握するために必要な、属性（概念を説明するために必要な情報）として記述するわけです。
有名な「哲学者」ポパイが好んで言った「私は私のままであり、それが私のすべてである」という格言のように、概念を説明するために必要な情報をくまなくまとめているというわけです。
（患者IOD例，すべてのIODは属性のかたまりで表現されます）
DICOM は、IODを構成する属性について、命名、フォーマット（データタイプ）、および処理の一貫性を確保するために、DICOM データ辞書と呼ばれる標準として定めた属性のリスト（その数は 5000 以上！）を管理しています。
例えば、先に挙げたような患者の属性（名前、生年月日、性別など）もDICOMデータ辞書に含まれています。このように、DICOMデータ辞書に定義された属性は、一般的に、DICOM属性と呼ばれます。
すべてのDICOM属性は、日付、時間、名前、識別子などを含む34種類のValue Representation(VR)に従ってフォーマットされています。VRについては別の機会に詳述します。ここでは、（数値なのか文字なのか、日付なのかといった）属性のデータの種類のようなものだと思って流してください。
なんらかの情報が、DICOMの属性に照らし合わされてDICOMデータになると、DICOMのアプリケーション・エンティティ（AE: Application Entities）と呼ばれる様々なDICOMモダリティやソフトウェア間で伝送・処理できるようになります。モダリティというのは、CTやMRIなどの医療機器や装置のことです。アプリケーション・エンティティは、相互にデータを通信するための「場所の単位」だと考えると分かりやすかもしれません。専門的な用語で用いられる「DICOMノード」や「DICOMピア」とも意味合いとしては似ています。
（DICOMデータ通信を行う装置やソフトウェアがアプリケーション・エンティティになります）
アプリケーション・エンティティは、互いにサービスを提供し合うことになるわけです（DICOMでは、この処理をサービスレンダリングモデルと表現します）。
各サービス（データのやり取り）は通常、何らかのデータ交換（通常はコンピュータネットワーク上で行われる）を伴うため、特定のサービスタイプを処理するデータ（IOD）と関連付ける必要があります。アプリケーション・エンティティとして通信拠点を分けておけば、受け取りたくないデータを受け取らないとか、不要な通信をさせたくないなどの設定が可能になるという仕組みです。
DICOM はこれらの関連付けをサービス・オブジェクト・ペア（SOP; Service Object Pair）と呼び、SOPクラスとしてデータ交換の定義をグループ分けしています。
例えば、CTスキャナからPACS画像サーバーにCT画像を保存する場合、CT Storage Service Object Pair（CT Storage SOP）が用いられます。
この例では、送信されるCT画像は、CT画像のDICOM情報オブジェクト定義（Computer Tomography IOD）に則って作成されたデータになります。CTスキャナはPACS画像サーバーにCTストレージサービスを要求し、画像サーバーはCTスキャナにCTストレージサービスを提供します。
このように、データをやり取りする際には必ず要求者（リクエストする側）と提供する側（プロバイダー）が必要になることが分かります。
そのため、DICOMでは、サービス要求者をサービス・クラス・ユーザ（SCU; Service Class User）、サービス提供者をサービス・クラス・プロバイダー（SCP; Service Class Provider）と呼んでいます。
同じCTの例では、CTスキャナはCTストレージサービスクラスユーザー（SCU）、PACS画像サーバーは、CTストレージサービスクラスプロバイダー（SCP）として機能します。
もちろん、これはあくまで一例であり、必ずモダリティがSCUになるということはありません。SCUやSCPは状況によって入れ替わります。
別のケースを想像してみます。例えば、病院内のPACS画像サーバーから、地域連携のために設置されたクラウド型の画像サーバに送りたいとします。
このような場合は、PACS画像サーバーはCT画像をクラウド上のDICOMアプリケーション・エンティティに送ることになるわけですので、PACS画像サーバーがSCU、クラウド上のサーバーがSCPの役割を担うことになります。
（CTスキャナから画像サーバーへ送信するときと、画像サーバーからさらにクラウドサーバーに送るときとで、画像サーバーがSCUにもSCPにもなる例）
もう少し、DICOM特有の呼び名について、確認していきたいと思います。
SCUとSCPピア間のデータ交換はDICOMでは「アソシエーション」と呼びます。
ネットワークにおけるデータ転送は、アソシエーションの確立（DICOMハンドシェイク）で始まり、これは2つの接続されたアプリケーションが互いの情報を交換する際に使用されます。このときに利用される情報はプレゼンテーション・コンテキストと呼ばれ、2つのアプリケーションがコンテキストを一致させることができれば、SCU-SCPの処理を開始することができるという仕組みになっています。
CT画像を画像サーバーに送信する例では、CTスキャナはCT画像ストレージのプレゼンテーション・コンテキストを持つPACS画像サーバーへのアソシエーションを行うことになります。PACS画像サーバーは、現在の保存可能なデータ設定（MRIやX線など異なる種類の画像を保存する場合もある）を確認し、その中にCTがあれば、スキャナのアソシエーションを受け付けます。
多数のDICOMに準拠した装置やアプリケーションが、複数のDICOMメーカーにより製造されているため、それぞれの装置や機能単位のユニットには独自のDICOMコンフォーマンス・ステートメントが添付されることになります。
このステートメントは、その装置やユニットがどのSOP（サービス）をサポートし、どの程度（SCU、SCP、またはその両方）サポートするかを説明しています。DICOMコンフォーマンス・ステートメントは、DICOM関連プロジェクトの計画に最も必要となるガイドです。装置やソフトウェアを利用するユーザーは、前もってメーカーから取得し、慎重に読んでおく必要があります。例えば、CT Storage SCUのみをサポートする（CT Storage SCPをサポートしない）PACS画像サーバーを購入した場合、そこにCT画像を保存することはできません。そのアーカイブはCT Storage Serviceを提供することができないためです。
さて、少々、専門的になってきた解説となりましたが、以上の抽象的な概念（IOD、DICOM属性、SOPのサービス）がDICOMのコアです。
私は最初はややこしく感じましたが、このデータの定義と通信というパターンに分けることができると思えば、非常に分かりやすいとも感じました（たぶん）。
実際、DICOMの大枠の理論を理解することは簡単です。なぜなら、一般的な技術者に必要な情報としては、ここで紹介したことがすべてだからです。しかし、もう一歩踏み込みたい人にとっては、残念ながら、まだ抽象的過ぎて、実生活でDICOMを扱うことは困難です。
以降の解説から、そのような課題を解決するための支援になるような具体的な内容について触れていきたいと思います。
（少なくとも私はそう感じたのですが）くたびれる内容であったにもかかわらず、最後までお読みくださり、ありがとうございました。
Stay Visionary
この記事が気に入ったらサポートをしてみませんか？