サーバーがクラッシュすることを想定して、検査や内視鏡や病理のサーバーとデータベースは 2 台が同時に動いています。
2 台のうちの 1 台がクラッシュしたとしても、直ちにもう 1 台の方を閲覧することができるようになっています。
多くの施設ではこんなことしていないと思います。
おそらく、専門の人がいてクラッシュしたらなるべく早くサーバーの再設定をできるようになっているのでしょう。
そこで、dicom サーバー（dcm4chee）に関しても同じデータベースを持つサーバーを設定しようと思ったのですが、dcm 4 chee の pacsdb が大きすぎて、エクスポート→他のサーバーにインポートというのは現実的ではないようです。
なので、現在稼働している dcm4chee はそのままで、dcm4chee じゃなくて他の dicom サーバーを設定できないかと考えました。
これって何年か前にやろうとしたことなんですが、やはり性懲りもなく今度は python の flask でできないかと思って挑戦してみます。dcm4chee がクラッシュした時の緊急避難的なものとしてです。
実は現在も、試験的な python のプログラムで dicom ファイルを閲覧することはできるのですが、どうも使いにくくて冴えません。
dcm4chee の dicom ファイル保存構造
dcm4chee の dicom ファイルは以下のような構造で保存されています。
.
├── 2017
│ └── 12
│ ├── 1
│ │ ├── 10
│ │ │ ├── D897964E
│ │ │ │ ├── 110B9E6C
│ │ │ │ │ ├── 109F2FED
│ │ │ │ │ ├── 109F2FEE
│ │ │ │ │ ├── 109F2FEF
│ │ │ │ │ ├── 110D64A9
│ │ │ │ │ ├── 110D64AA
│ │ │ │ │ └── 110D64AB
│ │ │ │ ├── D8979665
│ │ │ │ │ └── 110B9AA9
│ │ │ │ ├── D8979667
│ │ │ │ │ ├── 1068A365
│ │ │ │ │ ├── 1068A366
│ │ │ │ │ ├── 1068A367
│ │ │ │ │ ├── 110BA232
│ │ │ │ │ └── 110BA233
│ │ │ │ ├── D89796E1
│ │ │ │ │ └── 110D6C25
│ │ │ │ ├── D8979A08
│ │ │ │ │ ├── 1119418C
│ │ │ │ │ ├── 1119418D
│ │ │ │ │ ├── 120EF087
│ │ │ │ │ ├── 120EF088
│ │ │ │ │ └── 120EF089
│ │ │ │ └── D8979AA2
2017、12、1、10 の数字は、インポートされた日付と時間を表しています。
つまり、インポートされたのが「2017年12月1日午前10時」ということです。
この dicom ファイルが作成された日ではありません。
最初はなぜこんな構造にするのかとても疑問だったのですが、今となって考えてみれば、バックアップはこの方式の方がはるかに処理しやすいと思います。
なぜなら、過去に作成されたディレクトリの中に新たに dicom ファイルが追加されることはないからです。
conquest のようにカルテ番号の中に dicom ファイルを追加するタイプであれば、将来ファイルが追加されることは普通にあるはずです。
dcm4chee のようにすれば、2021年になってしまえば 2020年以前のディレクトリに新たにファイルが追加されることはないので、バックする際に漏れがありません。
明日になれば今日以前のディレクトリには何も追加されません。
この構造は、これを利用して新たに何かを作成する際にもとても便利です。
構造を年月日・時刻と考えて古い方から順次処理すればいいからです。
python で dicom ファイルを処理
現在、dcm4chee の dicom ファイル保存先は QNAP の NAS になっていますが、その構造は上の通りになっているので、それを順次処理して synology の NAS に新しい保存構造を作成します。
dcm4chee の保存構造を参考にして以下のようにします。
.
├── 2017
│ └── 12
│ ├── 1
│ │ ├── 10
│ │ │ ├── 20801654
│ │ │ │ └── 01002
│ │ │ │ ├── 01002_0001.dcm
│ │ │ │ ├── 01002_0002.dcm
│ │ │ │ ├── 01002_0003.dcm
│ │ │ │ ├── 01002_0004.dcm
│ │ │ │ ├── 01002_0005.dcm
│ │ │ │ └── 01002_0006.dcm
│ │ │ ├── 21205634
│ │ │ │ └── 00364
│ │ │ │ ├── 00364_0001.dcm
│ │ │ │ ├── 00364_0002.dcm
│ │ │ │ ├── 00364_0003.dcm
│ │ │ │ ├── 00364_0004.dcm
│ │ │ │ ├── 00364_0005.dcm
│ │ │ │ └── 00364_0006.dcm
│ │ │ ├── 21506694
│ │ │ │ └── 08643
│ │ │ │ ├── 08643_0001.dcm
│ │ │ │ ├── 08643_0002.dcm
│ │ │ │ ├── 08643_0003.dcm
│ │ │ │ ├── 08643_0004.dcm
│ │ │ │ ├── 08643_0005.dcm
│ │ │ │ └── 08643_0006.dcm
2017-12-1-10 までは dcm4chee と同じにして、その後はカルテ番号と検査IDにして、dicom ファイルは検査ID_通し番号、拡張子を「.dcm」とします。
必要な情報は 10 個もないので、おそらくテーブルは 1 つで十分。
そうすればデータベースはとても軽量となり、いくら増えてもバックアップは簡単なはずです。
実は同じようなプログラムが現在もずっと動いています。
保存構造を変更すれば割と簡単にできるはず。
こんなことを勝手に決めていいのかという意見があるかと思いますが、いいと思っています。
大事なのは、必要な情報がきちんとデータベースに記録されていて、その情報によって dicom ファイルを抽出することができるかどうかです。
なお、dicom ファイルはいくら rename しても、weasis などのビューワは勝手に dicom ファイル情報を読み込んで表示してくれるので、どんな名前にしても構いません。
