DICOMオブジェクトを構成する単位：IOD, IE, Module, Macro, Attribute
DICOMデータは、画像モダリティやコマンドなどの概念ごとにその構造が定義されています。
DICOMオブジェクトは「属性」というオブジェクトのビルディングブロックとしての最小構成単位から構築されます。これがDICOMオブジェクトを構築する唯一の方法です。
しかし、DICOMデータ辞書に定義されている約5,000ものデータエレメントを、どのように構成するかについて、もう少し詳しく知る必要があります。
今回は、この点について解説していきます。
でたらめなDICOMオブジェクトを作るのは簡単です。MRI画像しか持つはずがない静磁場強度や、CTのX線管球の管電圧（kVP）、この他の好きな属性を混ぜて、ピクセルデータには超音波画像を挿入して、はい、DICOMオブジェクトの出っ来上が～り～です。って、これはいただけませんよね。
実際は、このような行き過ぎた間違いは起こらないでしょう。
データエレメント（属性）は、DICOMオブジェクトの最小のビルディングブロックであり、正確に取捨選択して並べることが必要です。
さらには、データエレメントをより大きなビルディングブロックにグループ化し、それらを使ってより意味のあるDICOMオブジェクトを構築するのが進むべき道でしょう。
DICOMでは、これらのブロックを、情報モジュール（Information Module; 略して、Module）、情報エンティティ（Information Entity; IE）、情報オブジェクト定義（Information Object Definition; IOD）と呼んでいます。これらは階層的に関連しています。IOD > IE > Module > Macro > 属性です。
その仕組みについて詳しく見ていきましょう。
以降の内容を読み進める際に、PS 3.3 情報オブジェクト定義も参照しながらみていただくと、より分かりやすいと思います。
PS 3.3 情報オブジェクト定義には、すべてのモジュールの仕様、IODの仕様が、巨大なテーブル（表）で記載されています。どのモジュールがIODに必要なのかなども詳細に説明されています。
ここでは、まず一番細かいところから解説していきます。
属性とマクロ
DICOMでは、意味を形成するために必要な属性の集まりをグループ化することがよくあります。これらのグループはマクロ属性と呼ばれます。
Series and Instance Reference Macro 属性を例に見てみましょう。
（シーケンシングを使用していることに留意しましょう。大なり記号">"は、これまで見てきたように、SQ VRで要素を入れ子にしている（ネストしている）ことを表します。）
見ての通り、Referenced Series Sequenceで構成されている属性グループであることがわかります。このようなマクロとしての属性グループは、特定のオブジェクトに対するデータブロックになるものではなく、すべてのオブジェクトに汎用的に利用できるものです。
ただし、マクロだからシーケンシングが行われているということではありません。シーケンスタグはあくまでマクロを構成する属性の一つになるだけです。例えば、Image Pixel Macroなどは、シーケンスタグはありません。
Information Module（モジュール）
モジュールは、データエレメント（属性）やマクロを束ねるための重要な階層レベルを表現しています。
例えば、患者識別モジュール（Patient Identification Module）は、患者名、ID、旧姓などのタグを含む、すべての患者識別情報をグループ化しています。
このモジュールの役割は明確です。患者の識別に関連するすべての属性がまとめられていることがわかります。モジュールの主な目的は、一貫性のある方法で、データエレメント(属性)を集めることになります。
例えば、患者が臨床試験の被験者になった場合、DICOMオブジェクトへ臨床試験モジュール（Clinical Trial Subject Module）を追加して、すべての臨床試験属性を記録できます。
ここで重要なのは、モジュールに記載されているからと言って、記載されているすべての属性を完全にDICOMオブジェクトへ組み込まなければならないわけではないという点です。表の中の「Type」列を見てみると、その属性の重要度がわかるようになっています。
タグによっては、必須なものもありますが、値が不明な場合は属性の値を空白のままにしたり、必要なければ属性自体を省略することも可能です（データエレメントタイプ参照）。
別の例も見ていきましょう。
Cine モジュールは、マルチフレーム画像の再生パラメータに関する属性を構造化しています。
DICOMオブジェクトにビデオフレームのシーケンス（連続したフレーム画像）を含む場合、Cineモジュールはこのシーケンスの再生方法に関する情報を格納するために役立ちます。 例えば、動画の再生に重要なパラメータとなるフレーム時間は、 (0018,1063) タグで指定でき、フレーム間のミリ秒単位の時間を設定できます。 例えば、フレームレートが25フレーム/秒の場合、(0018,1063)タグの値は、1000/25=40ミリ秒です。
DICOMのデータエレメントタイプと同様に、モジュールにも重要度のレベルが設定されています。このレベルについては、IOD（のUsage）に明記されることになります。後ほど触れます。
例えば、患者識別モジュールは、どのDICOM画像にも必ず必要です。
一方で、Cine モジュールは、超音波のフレーム画像をループさせる必要がある場合は必要ですが、ビデオを操作しないCTやMRのDICOMオブジェクトには必要ありません。
こういったモジュールごとの特性を考えて、レベルが設定される仕組みになっています。
また、モジュール間で、重複するエレメントがあることにも留意が必要です。
例えば、患者名のような重要な属性は、いくつかのモジュールに重複して含まれています。また、患者モジュールには患者識別モジュールに含まれるデータエレメントがほとんど含まれています。
そのため、DICOMオブジェクトを構築するときに、モジュールごとにオブジェクトを作った場合は、重複タグは、その一方は不要となるでしょう（別々にシーケンシングされているときは、そのマクロ内で必要なエレメントになっていることがあるため、削除しなくて良いこともあります）。
Information Entities （IE）
DICOM Information Entity ( IE ) は、DICOM情報モジュールから構築されます。
IEを構築するのは簡単です。
各IEについて、DICOMは含まれるべきモジュールをリストアップしています。
例えば、患者IE（Patient IE）は、患者モジュール（Patient Module）、および臨床試験被験者モジュール（Clinical Trial Subject Module）から成ります。
細かい検査条件などが重要になる画像になると、IEはより複雑になり、多くのモジュールを含むようになります。
すでにモジュール（Information Module）があるのに、なぜIEが必要なのでしょうか？
IEは、後述するIODの構成要素であるだけでなく、DICOM情報モデル（DICOM Information Model）に対する次のレベル（下のレベル）の複雑さを表します。
モジュールが関連するデータ要素を結合するためのものであるならば、IEは医療画像のワークフローに関わる実際のエンティティを表現するために設計されています。
(PS 3.3, Figure 7-1a. DICOM Model of the Real World)
IEを理解するには、このワークフローを見ればわかりやすいと思います。
上図の青塗りの各ボックスはDICOM IEを表しています（図中の一番上がPatientボックスで、これがPatient IEに対応しています）。
ある患者がある装置で検査を受けると、一連の画像が生成され、画像に必要な他のデータも含まれる様子が、概念的に描かれていることがわかります
それ以上の意味はないですのですが、IEのまとまりは、DICOMの上位概念を形成しているのですね。
DICOM情報オブジェクト：DICOM Information Object
IEが意味を持って組み合わされることで、情報オブジェクト定義（Information Object Definition; IOD）が構築されます。IODは、DICOMの情報階層を形成し、DICOMで使用されるオブジェクトを定義します。
DICOMデータ処理はIODの観点から行われますから、すべてのDICOMデータは所定のIODタイプに適合する必要があります。そのため、IODは様々なモダリティの画像（レントゲン、CT、MR、etc）をデータとして表現しています。
例として、CT Image IODを見てみましょう。IEとモジュールのセットから CT Image IOD が設計されていることがわかります。
MRI画像や超音波画像あるいは核医学画像も同様に、IODが定義されています。
モジュールの必要・不要
IODの「Usage」列には、そのモジュールの重要度が明記されています。意味は以下の通りです。
Mandatory（M）：必須
Conditional（C）：特定の条件下では必須
User Difined（U）：ベンダー or ユーザーで使うかどうか決めてよい
ここまで読み進めてきた方は、もうこのIODを読み解くことができるはずです。CT Image IODはどのIEで構成されているか、各IEに必要なモジュールは何か、そのモジュールは必須なのか、モジュールに含まれるマクロや属性は何か、そのマクロや属性は必須なのか。モジュール間で重複する属性はあるか（そして削除するかどうか）。
…（振り返り）
大丈夫ですね！
Normalised IODとComposite IOD
DICOM はすべてのIODをNormalisedとCompositeに分別しています。
Normalised IODは、患者IODが患者を表すように、単一の実世界エンティティ（実体）を表します。Normalised IODのすべての属性は、実世界エンティティに固有のものです。単一のオブジェクトを表現するために使われます。
例えば、DICOM Study IODはNormalisedです。これは、検査日時などの固有の検査プロパティのみを含んでいるためです。
Composite IODは、複数の実世界エンティティまたはその構成要素が混合されたと考えられるものです。
例えば、CT Image IODを考えてみましょう。このIODは、CTスキャナなどの検査属性とともに、患者属性の一部を含んでいます。
このように複数の実体が混在しているため、CT画像はComposite IODとして扱われます。よって、Composite IODは、実体間の関係や関連、プロセス、コンテキストを捉えるのに効果的です。
しかし、NormalisedとCompositeの境界は曖昧であり、これらの差を気にしなくても大丈夫です。それぞれIODとして、同等に扱われると考えておくくらいで、臨床の運用上で問題になることはないでしょう。
Stay Visionary
この記事が気に入ったらサポートをしてみませんか？