「DICOMサーバー」の版間の差分
(ページの作成:「DICOMの形式でモダリティの画像を保存するサーバーのこと。」) |
編集の要約なし |
||
1行目: | 1行目: | ||
'''DICOMサーバー'''(DICOM Server)とは、[[DICOM通信]]をもちいて[[DICOMファイル]]を保存管理するストレージサーバーのことである。 | |||
== 概要 == | |||
DICOMサーバーを小難しく言うと、[[DICOM規格]]に規定される[[ストレージサービスクラス]]の[[サービスクラスプロバイダー]]である。 | |||
簡単にいうと[[DICOMファイル]]専用のファイルサーバーである。 | |||
パソコンでいうネットワーク対応HDD、いわゆるNASと同じような物である。 | |||
DICOMサーバーとの通信には[[DICOM通信]]と呼ばれる専用プロトコルを用い、[[DICOMファイル]]の保存や検索、取得を行う。 | |||
DICOMサーバーは[[CT]]や[[MR]]などの[[モダリティ]]が生成した[[DICOM画像]]を受け取り保管し、[[DICOMビューアー]]は必要な画像を検索し取得するというのが基本中の基本である。 | |||
医療機関内でみんなが使う物なので、非常に安定した稼働が求められる。 | |||
== あると嬉しい機能 == | |||
=== DICOM通信 === | |||
これが出来ないと始まらない。 | |||
DICOMサーバーの基礎である。 | |||
稀に[[DICOM通信]]機能は[[モダリティー]]からの受信保存のみで、検索や取得は独自規格を採用した[[PACS]]製品があるが、そういう製品を導入するとベンダーロックインを食らい将来的にデータ移行ができないという悪夢に陥るので注意する必要がある。DICOMサーバー単体ではなく[[PACS]]一式として導入に際しては、[[モダリティー]]からの受信のみならず、フリーの有名どころの[[DICOMビューアー]]で接続できることを確認しておくとよい。これは[[DICOMビューアー]]で接続できれば、将来的なデータ移行時に用いる[[DICOMサーバー]]間の通信も問題ないとみて間違いないためである。 | |||
=== 自動転送 === | |||
[[モダリティ]]から受信した[[DICOMファイル]]を、あらかじめ指定しておいた[[DICOMビューアー]]や他のDICOMサーバーに自動転送する機能である。 | |||
これがあると何かとうれしい。 | |||
一部の高性能なDICOMサーバーでは簡易的なスクリプト言語を組むことで、条件一致したものを特定の転送先に送れるようになっている製品も見かける。 | |||
確認すべき点としては「何か所に転送できるか」という点が意外と重要だったりする。 | |||
転送機能がなかったり、あっても1か所にしか転送できないような物もあり、運用によっては困ったことになることもある。 | |||
また、転送失敗時の挙動も意外と重要な要素である。 | |||
=== バックアップ === | |||
これ超重要。 | |||
この機能が弱いと画像データが一瞬にして消え去るという取り返しのつかない事態になる。 | |||
<ref>http://search.yahoo.co.jp/search?p=%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC+%E3%83%87%E3%83%BC%E3%82%BF%E6%B6%88%E5%A4%B1</ref> | |||
稀に勘違いしている人が多いがハードディスクのRAIDだけでは不十分である。 | |||
RAIDはハードディスクの故障には対応できるが、RAIDコントローラーが壊れると全滅である。 | |||
また、あくまで機械的な故障に対応するためのものであり、人為的な操作ミスによるデータ消失にも対応できない。 | |||
RAIDよりも何よりもまずは定期的なバックアップである。 | |||
前述の転送機能を用いて、2台以上のDICOMサーバーに転送するようにしておくのも手である。 | |||
バックアップ周りを追及すると、いわゆる何もかも冗長化(2重化)するという手法に辿り着き、DICOMサーバーの価格が倍々ゲームのように増えていくことになるが、間違ってもバックアップを手抜きしている製品を導入してはならない。そんなの無駄だろと思えるくらいバックアップ機能が揃った製品を買え。多少機能が劣ってもバックアップに拘っている製品を買え。 | |||
=== 画像圧縮 === | |||
[[モダリティ]]が送信する画像はRAWデータ(無圧縮画像)が一般的であり、そのままではファイル容量が大きいのでDICOMサーバー側で受信後に画像圧縮する機能を備えていることが多い。 | |||
また、DICOMサーバーの中には、長期間保存されている古いDICOM画像を定期的に検出し、可逆圧縮から非可逆圧縮に変更することで、さらなるディスク容量確保を試みるような製品もある。[[医用画像]]の法律上の保存期間は、「診療行為が終了したときから3年間」となっているが、[[電子カルテ]]の保存期間である5年に右にならえとなっているのが一般的であり、非可逆圧縮化は5年を経過した画像を対象とするのが一般的である。 | |||
近年はハードディスクのディスク容量が爆発的に増えてはいるが、それ以上に[[マンモグラフィー]]などの[[モダリティ]]の生成する[[DICOM画像]]が高精細化([[DICOMファイル]]が巨大化)し、かつ[[ADCT]]などの登場により1[[検査]]での撮影枚数も爆発的に増えているため、[[DICOM画像]]の圧縮機能は必須な状況が続いている。 | |||
=== 動画生成 === | |||
[[アンギオ]]や[[IVUS]]、[[US]]などのDICOMファイルを受信した際に、軽量な動画ファイルを生成し、ウェブなどを経由して取得できる機能である。 | |||
かついては性能の悪い端末でDICOMファイルのパラパラアニメは非常に辛く、見るに堪えない物もあったので地味にうれしい機能であった。 | |||
最近はパソコンどころかスマートフォンやタブレットの性能も飛躍的に上がってきた関係で院内で見る分にはあまり重要ではないが、Windows Media VideoやMPEG4などの動画ファイルはDICOMファイルに比べ圧倒的にファイルサイズが小さいのでモバイル環境などの通信回線の細い遠隔地で見る際には重宝する。わざわざ[[DICOMビューアー]]がなくても見れるのも良い。 | |||
== 運用 == | |||
最近では素人でもフリーソフトを用いてDICOMサーバーを作れるが、ある程度の規模の医療機関の場合は専門のスタッフまたは業者に設定や運用を任せた方が確実である。 | |||
サーバーとなの付くものはセキュリティーが重要であり、兼任では管理が行き届かないほどの規模の医療機関で下手に運用すると非常に危険なので、とくに注意する必要がある。 | |||
あとバックアップ。 | |||
== 主な製品 == | |||
=== フリーソフト === | |||
* [[ConQuest DICOM server]] | |||
* [[dcm4chee]] | |||
* [[OsiriX]] - 有名な[[DICOMビューアー]]だが、簡易的なDICOMサーバー機能も備えている。 | |||
=== 商用 === | |||
[[PACS]]としてDICOMサーバーと[[DICOMビューアー]]をセット販売している物が多い。 | |||
DICOMサーバー単品で販売という話はあまり聞かなくなった。 | |||
== 関連項目 == | |||
* [[DICOMビューアー]] | |||
* [[DICOM]] | |||
* [[PACS]] | |||
== 参考文献 == | |||
{{reflist}} | |||
{{medical-stub}} |
2012年7月24日 (火) 22:35時点における版
DICOMサーバー(DICOM Server)とは、DICOM通信をもちいてDICOMファイルを保存管理するストレージサーバーのことである。
概要
DICOMサーバーを小難しく言うと、DICOM規格に規定されるストレージサービスクラスのサービスクラスプロバイダーである。
簡単にいうとDICOMファイル専用のファイルサーバーである。 パソコンでいうネットワーク対応HDD、いわゆるNASと同じような物である。 DICOMサーバーとの通信にはDICOM通信と呼ばれる専用プロトコルを用い、DICOMファイルの保存や検索、取得を行う。
DICOMサーバーはCTやMRなどのモダリティが生成したDICOM画像を受け取り保管し、DICOMビューアーは必要な画像を検索し取得するというのが基本中の基本である。
医療機関内でみんなが使う物なので、非常に安定した稼働が求められる。
あると嬉しい機能
DICOM通信
これが出来ないと始まらない。 DICOMサーバーの基礎である。
稀にDICOM通信機能はモダリティーからの受信保存のみで、検索や取得は独自規格を採用したPACS製品があるが、そういう製品を導入するとベンダーロックインを食らい将来的にデータ移行ができないという悪夢に陥るので注意する必要がある。DICOMサーバー単体ではなくPACS一式として導入に際しては、モダリティーからの受信のみならず、フリーの有名どころのDICOMビューアーで接続できることを確認しておくとよい。これはDICOMビューアーで接続できれば、将来的なデータ移行時に用いるDICOMサーバー間の通信も問題ないとみて間違いないためである。
自動転送
モダリティから受信したDICOMファイルを、あらかじめ指定しておいたDICOMビューアーや他のDICOMサーバーに自動転送する機能である。 これがあると何かとうれしい。
一部の高性能なDICOMサーバーでは簡易的なスクリプト言語を組むことで、条件一致したものを特定の転送先に送れるようになっている製品も見かける。
確認すべき点としては「何か所に転送できるか」という点が意外と重要だったりする。 転送機能がなかったり、あっても1か所にしか転送できないような物もあり、運用によっては困ったことになることもある。
また、転送失敗時の挙動も意外と重要な要素である。
バックアップ
これ超重要。 この機能が弱いと画像データが一瞬にして消え去るという取り返しのつかない事態になる。 [1]
稀に勘違いしている人が多いがハードディスクのRAIDだけでは不十分である。 RAIDはハードディスクの故障には対応できるが、RAIDコントローラーが壊れると全滅である。 また、あくまで機械的な故障に対応するためのものであり、人為的な操作ミスによるデータ消失にも対応できない。
RAIDよりも何よりもまずは定期的なバックアップである。 前述の転送機能を用いて、2台以上のDICOMサーバーに転送するようにしておくのも手である。
バックアップ周りを追及すると、いわゆる何もかも冗長化(2重化)するという手法に辿り着き、DICOMサーバーの価格が倍々ゲームのように増えていくことになるが、間違ってもバックアップを手抜きしている製品を導入してはならない。そんなの無駄だろと思えるくらいバックアップ機能が揃った製品を買え。多少機能が劣ってもバックアップに拘っている製品を買え。
画像圧縮
モダリティが送信する画像はRAWデータ(無圧縮画像)が一般的であり、そのままではファイル容量が大きいのでDICOMサーバー側で受信後に画像圧縮する機能を備えていることが多い。
また、DICOMサーバーの中には、長期間保存されている古いDICOM画像を定期的に検出し、可逆圧縮から非可逆圧縮に変更することで、さらなるディスク容量確保を試みるような製品もある。医用画像の法律上の保存期間は、「診療行為が終了したときから3年間」となっているが、電子カルテの保存期間である5年に右にならえとなっているのが一般的であり、非可逆圧縮化は5年を経過した画像を対象とするのが一般的である。
近年はハードディスクのディスク容量が爆発的に増えてはいるが、それ以上にマンモグラフィーなどのモダリティの生成するDICOM画像が高精細化(DICOMファイルが巨大化)し、かつADCTなどの登場により1検査での撮影枚数も爆発的に増えているため、DICOM画像の圧縮機能は必須な状況が続いている。
動画生成
アンギオやIVUS、USなどのDICOMファイルを受信した際に、軽量な動画ファイルを生成し、ウェブなどを経由して取得できる機能である。
かついては性能の悪い端末でDICOMファイルのパラパラアニメは非常に辛く、見るに堪えない物もあったので地味にうれしい機能であった。
最近はパソコンどころかスマートフォンやタブレットの性能も飛躍的に上がってきた関係で院内で見る分にはあまり重要ではないが、Windows Media VideoやMPEG4などの動画ファイルはDICOMファイルに比べ圧倒的にファイルサイズが小さいのでモバイル環境などの通信回線の細い遠隔地で見る際には重宝する。わざわざDICOMビューアーがなくても見れるのも良い。
運用
最近では素人でもフリーソフトを用いてDICOMサーバーを作れるが、ある程度の規模の医療機関の場合は専門のスタッフまたは業者に設定や運用を任せた方が確実である。 サーバーとなの付くものはセキュリティーが重要であり、兼任では管理が行き届かないほどの規模の医療機関で下手に運用すると非常に危険なので、とくに注意する必要がある。
あとバックアップ。
主な製品
フリーソフト
- ConQuest DICOM server
- dcm4chee
- OsiriX - 有名なDICOMビューアーだが、簡易的なDICOMサーバー機能も備えている。
商用
PACSとしてDICOMサーバーとDICOMビューアーをセット販売している物が多い。 DICOMサーバー単品で販売という話はあまり聞かなくなった。