以前に書いた記事で DICOM を取り扱うソフトは、データ構造として

Patient - Study - Series - Image(s)

になっていると書いたが、そうはなっていないものもある。

代表例は OsiriX の open source version で、少なくともデータベースの構造は

Alubum - Study - Series - Image(s)

という階層を採用している。

OsiriX と言っても商用版はもはやオープンソースではないので確かめてみようがないが、少なくとも Ver 5 あたりまでは、この構造になっている。

だから、オープンソース時代の OsiriX をベースに開発された Horos や HorliX も基本的には同じデータベース構造になっている。

上に掲げた図は、OsiriX 系の dicom viewer のデータベースのテーブル間の関係性をソースコードを基にまとめたものだ。
Album, Study, Series, Image が実際にデータベースとして使われている sqlite のテーブルに対応しており、Attribute がカラムに対応している。ただし、ソースコードをベースに機械的に図に起こしたものなので、現在では使われていないカラムも含まれている。例えば、Album の index はソースコード上では Int32 （符号付32ビット整数）で定義はされているが、実際には使われていない。

では、HorliX にスタディを一つだけ登録してみよう。

このとき、実際のデータベースの ZSTUDY テーブルは以下のようになっている。

ダイコムファイルを取り込んだ際などに患者 id を正しく設定してさえおけば、sqlite の patientid のカラムはその施設で使っている施設の患者 id と一致するはずだ。
patientuid は デフォルトの設定では'患者名-患者 id-患者birthday' になる。
この設定は、HorliX では menu -> HorliX -> 設定 -> データベース の以下のパネルで微調整はできる。

ただし、UID とは言っても多施設で使用した場合は、これは必ずしも Unique な ID にはならない。
施設 A にも 00003 さんはいるだろうし、施設 B にも 00003 さんはいる可能性があるからだ。
だから、多施設で使われることを前提にした電子カルテなどと連動させる場合には、この点には注意をする必要がある。

ところで、UI にも採用されている Album を階層の一番上に持ってきたのは、使いやすさを考慮してのことなのだろう。

だが、この構造を採用したことで、他の医療ソフトと連動させた時などに若干の影響は出ると思う。

通常であれば、単純には、トップの階層のテーブルにある患者の id 同士を照合させて欲しいデータをとってくればいいが、この構造では、いったん、一階層落ちて Study の patientid または patientuid で照合をさせる必要があるからだ。

猪股弘明
HorliX: 開発者
Horos: contributor, OsiriX(OpenSource Version): contributor