DICOM情報の階層
DICOMデータの仕組みを理解するために、DICOMがどのように情報を階層化しているかを見ておくのは、一見の価値があります。
DICOMデータ辞書の属性は、現実世界のデータをDICOM規格にマッピングする上で重要な役割を担っています。 しかし、属性はフラットに並べられているだけです。
そのため、構造化して並べるにはどうすればよいでしょうか。
この構造化は、DICOMでは患者（Patient）- 検査（Study）- シリーズ（Series）- 画像（Image）の階層構造で表現されます。
ある患者がいます。
その患者が複数の検査を受けます。
各検査は、さらに1つ以上の画像シリーズを含みます。
各シリーズは1枚以上の画像を持ちます。
という、当たり前のことを整理するための考え方です。
この階層化は、患者が何らかの画像診断を受ける必要がある場合に、現実の世界で起こることをデータの階層として反映しています。
例えば、長津田 万次郎（仮名）は、健診のために病院にやってきます（もしなにか病気が見つかれば、後日、別のフォローアップ検査が必要になる可能性があります）。ここでは、胸部レントゲンにしておきましょう。レントゲン検査は、複数の画像シリーズを持つことができます（正面と側面）。各検査の複数画像シリーズは、1枚ずつ画像（正面画像が一枚、側面画像が一枚）があることになります。
この患者の画像を検索する必要がある場合を考えてみます。DICOMデータは階層化を意識して設定されているため、データは、患者、検査、シリーズ、および画像の属性に基づいて検索することができます。
例えば、過去1年間に行われたこの患者のすべてのレントゲン検査を検索するなどです。
この階層化は、各階層にキーとなるIDを割り当てることで実現されています。
患者レベルでは、患者IDです。すべての患者は、その施設内で、一意に識別できるIDを持つ必要があります。患者IDは、（0010,0020）患者ID属性に保存され、このタグはあらゆる検索に用いられます。
検査レベルでは、StudyインスタンスUIDで、検査の一意性が担保されます。各検査は固有のStudyインスタンスUIDが割り当てられます。
シリーズレベルでは、各シリーズは固有のSeriesインスタンスUIDが割り当てられます。
画像レベルでは、各画像に固有のSOPインスタンスUIDが割り当てられます。
これらのIDのうち、患者IDは、検索などのために実運用上で頻繁に使用されるため、あまり構造化されていない（UIDのように複雑でない）LO（Long String）VRタイプでエンコードされます。他のUIDは、UI VRです。
すべてのDICOMコマンドと、ほとんどのDICOMデータ属性は、常にこれら4レベルの情報モデルで運用されます。
例えば、2つのDICOM画像があり、同じ患者IDを属性に持っていた場合、これらは同一人物の画像であることがわかります（当然ですが）。
また、2つのDICOM画像が、同じStudyインスタンスUIDを持っていた場合、同一検査で取得された画像であることがわかります。
そして、2つのDICOM画像が、同じSeriesインスタンスUIDを持っていた場合、同一シリーズとして取得された画像（例えば、スライス送りできるCT画像のように）であることがわかります。
最後に、2つのDICOM画像が、異なるSOPインスタンスUIDを持っていた場合、これは当然、そうなっていないといけないので、そうなっているのです（各画像は世界に一つしかないSOPインスタンスUIDがセットされるので）。
これをうまく使えば、データの識別性が大幅に向上します。どの患者のどの検査のどのシリーズのどの画像？という質問に、アプリケーションが答えてくれます。
Study、Series、SOP(Images) UIDの良い点は、検査時に入力される患者IDとは異なり、自動で割り当てられることです。データ生成時に、DICOM画像としてDICOMタグに挿入されることになります。どのようなUIDがセットされるかは、Unique Idntifierの解説をご参照ください。
Stay Visionary