(57)【特許請求の範囲】
【請求項１】
外部リクエストに関連するジョブを処理する第一のスイッチを介した第一のネットワークと、内部リクエストに関連するジョブを処理する第二のスイッチを介した第二のネットワークにより、負荷分散制御するロードバランサ、及びストレージユニットと相互にネットワーク接続され、前記ストレージユニットに蓄積された文書または画像データに関連付けられたキー情報を含む属性情報でなるレコードを格納するとともに、外部接続された機器との間で前記ストレージユニットに蓄積された文書または画像データの格納アドレスを中継処理するデータベースサーバであって、
前記第一のネットワークに対するデータ更新用のポートとデータ検索用のポートを備え、前記第一のネットワークを介してなされたデータの更新処理に対して、更新レコードに更新日時を付加して自らのデータベースを更新処理するとともに、前記第二のネットワークを介して当該更新レコードに更新日時を付加して他の画像データベースサーバのデータベースを更新処理する更新処理手段を備え、
故障からの復旧時に自身の更新用ポート及び検索用ポートの双方をクローズして、前記第二のネットワークを介して自身が更新した最終更新日時以降復旧開始日時迄のレコードを他のデータベースサーバから取得して自らのデータベースを更新するとともに当該復旧開始時刻を自らのデータベースの最終更新日時とする更新処理を、最終更新日時と現在日時が所定時間内になるまで繰り返し、最終更新日時と現在日時が所定時間内になると、他のデータベースサーバに自身の最終更新日時以降のデータベースの更新処理を要求し、最終更新日時以降のデータベースの更新処理が行なわれた後にデータ更新用のポート及びデータ検索用のポートをオープンする復旧処理手段を備えているデータベースサーバ。
【請求項２】
故障から復旧中のデータベースサーバからの要求に対して、自らのデータ更新用ポートをクローズして前記第二のネットワークを介して故障から復旧中のデータベースサーバの最終更新日時以降のデータベースの更新処理を行なった後に、自らのデータ更新用のポートをオープンする復旧処理手段を設けている請求項１記載のデータベースサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、ＣＴ装置、ＭＲＩ装置などのモダリティ装置により撮影された大量の医療用画像情報を電子情報として保管するとともに診断に資する画像データベースシステムや、大量の文書ファイルを電子情報として検索可能に保管された文書データベースシステムなどに組み込まれるデータベースサーバに関する。
【背景技術】
【０００２】
従来、医療用の画像データベースシステムでは、画像データを恒久保存するために、ハードディスク装置上に一時的に格納された画像データを、ＤＶＤやＭＯなどのリムーバブルメディアに移動させることが行われていた。このようなリムーバブルメディアへのメディカル・レコードの移動作業は、人手に頼っていたために、コストの増大や、人為的ミスによる画像データの消失などの不都合があったために、ネットワーク経由で画像ファイルを送受信するネットワーク接続手段と、画像ファイルを一時保存する第１の画像保存手段としてのハードディスクと、画像ファイルを恒久保存する第２の画像保存手段としてのリムーバブルメディアと、ネットワーク経由で受信した画像ファイルの保存処理を制御する制御手段とを備え、前記制御手段は、記録指示が付された画像ファイルを受信したことに応答して、前記第１又は第２の画像保存手段のうち指示された方に画像ファイルを保存する画像管理システムが提案されている。
【０００３】
【特許文献１】特開２００２−１１１９８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上述した従来の画像管理システムによれば、大量の画像データを一次蓄積用のメディアとは異なるメディアに恒久保存することにより、大量の恒久保存用のメディアが必要とされ、その保管場所や管理が必要となるばかりか、一旦、恒久保存用のＤＶＤやＭＯなどに保管された画像データは、必要なときに迅速にネットワーク上でアクセスできないという本質的な問題があった。
【０００５】
本発明は、上述した問題点に鑑み、一次蓄積されたメディアと異なるメディアを使用せずに、ネットワーク上で迅速にアクセスでき、且つ、人手を介さずに安全かつ安定的にデータをバックアップできるデータベースシステムに用いられるデータベースサーバを提供する点にある。
【課題を解決するための手段】
【０００６】
上述の目的を達成するため、本発明によるデータベースシステムの第一の特徴構成は、特許請求の範囲の欄の請求項１に記載した通り、外部リクエストに関連するジョブを処理する第一のスイッチを介した第一のネットワークと、内部リクエストに関連するジョブを処理する第二のスイッチを介した第二のネットワークにより、負荷分散制御するロードバランサ、及びストレージユニットと相互にネットワーク接続され、前記ストレージユニットに蓄積された文書または画像データに関連付けられたキー情報を含む属性情報でなるレコードを格納するとともに、外部接続された機器との間で前記ストレージユニットに蓄積された文書または画像データの格納アドレスを中継処理するデータベースサーバであって、前記第一のネットワークに対するデータ更新用のポートとデータ検索用のポートを備え、前記第一のネットワークを介してなされたデータの更新処理に対して、更新レコードに更新日時を付加して自らのデータベースを更新処理するとともに、前記第二のネットワークを介して当該更新レコードに更新日時を付加して他の画像データベースサーバのデータベースを更新処理する更新処理手段を備え、故障からの復旧時に自身の更新用ポート及び検索用ポートの双方をクローズして、前記第二のネットワークを介して自身が更新した最終更新日時以降復旧開始日時迄のレコードを他のデータベースサーバから取得して自らのデータベースを更新するとともに当該復旧開始時刻を自らのデータベースの最終更新日時とする更新処理を、最終更新日時と現在日時が所定時間内になるまで繰り返し、最終更新日時と現在日時が所定時間内になると、他のデータベースサーバに自身の最終更新日時以降のデータベースの更新処理を要求し、最終更新日時以降のデータベースの更新処理が行なわれた後にデータ更新用のポート及びデータ検索用のポートをオープンする復旧処理手段を備えている点にある。
【０００７】
上述した構成によれば、故障からの復旧するデータベースサーバは、最終更新日時と現在日時が所定時間内になるまで、自らが他のデータベースサーバからレコードを取得して自らのデータベースを更新処理し、その後、所定時間内のレコードが正常稼動中のデータベースサーバから更新処理される。
【０００８】
同第二の特徴構成は、同欄請求項２に記載した通り、上述の第一特徴構成に加えて、故障から復旧中のデータベースサーバからの要求に対して、自らのデータ更新用ポートをクローズして前記第二のネットワークを介して故障から復旧中のデータベースサーバの最終更新日時以降のデータベースの更新処理を行なった後に、自らのデータ更新用のポートをオープンする復旧処理手段を設けている点にある。
【発明の効果】
【０００９】
以上説明した通り、本発明によれば、一次蓄積されたメディアと異なるメディアを使用せずに、ネットワーク上で迅速にアクセスでき、且つ、人手を介さずに安全かつ安定的にデータをバックアップできるデータベースシステムに用いられるデータベースサーバを提供することができるようになった。
【発明を実施するための最良の形態】
【００１０】
以下に本発明による画像データベースシステム実施の形態を説明する。図１に示すように、画像データベースシステムは、基本フレーム（基本最小タワー）と複数の拡張フレーム（増設タワー）とから構成される。
【００１１】
基本フレームは、医療用画像データを蓄積する４台のストレージユニット１からなるストレージユニット群と、各ストレージユニット１を管理する２台のコントロールユニット２からなるコントロールユニット群と、各ストレージユニット１に蓄積された医療用画像データに関連付けられたキー情報を含む属性情報が格納され、外部接続されたビューワ１１との間で医療用画像データを中継処理する２台の画像データベースサーバ３からなる画像データベースサーバ群と、画像データベースサーバ３と外部接続された複数のモダリティ装置１０との間でＤＩＣＯＭプロトコルにより医療用画像データを中継処理する２台のＤＩＣＯＭゲートウェイ４からなるＤＩＣＯＭゲートウェイ群とが、スイッチ５，６を介して相互にネットワーク接続されて構成され、ネットワークを介したリクエストのヘッダー情報に基づいて各群毎にそれらを負荷分散制御する２台のロードバランサ７を備えるとともに、電源ユニット８とディスプレイスイッチ９とを設けて構成される。ここに、各ユニットやサーバの台数は例示に過ぎず、それ以上のまたは以下の複数の台数であればよい。
【００１２】
拡張フレームは、電源ユニットと複数台のストレージユニットとスイッチで構成され、大容量の画像データが蓄積できるように拡張可能に構成される。
【００１３】
ストレージユニット１と、コントロールユニット２と、画像データベースサーバ３と、ＤＩＣＯＭゲートウェイ４は、ビューワ１１またはモダリティ装置１０からの外部リクエストに関連するジョブを処理する第一のスイッチ５を介した第一のネットワークＮ１と、内部リクエストに関連するジョブを処理する第二のスイッチ６を介した第二のネットワークＮ２により相互にネットワーク接続されている。前記ネットワークＮ１，Ｎ２は、ＯＳＩ参照標準モデルでネットワークの物理層及びデータリンク層が１０００ＢＡＳＥ−Ｔのイーサネット（登録商標）で、トランスポート層及びネットワーク層がＴＣＰ／ＩＰで構成され、セッション層以上の上位層が、医療分野における画像診断規格であるＤＩＣＯＭプロトコルまたは他のローカルな上位プロトコルで動作するように構成される。
【００１４】
２台のロードバランサ７はローカル通信ライン（ＲＳ２３２−Ｃ）で接続され、通常１台が稼動して、例えば、各群の構成要素の性能に差がなければラウンドロビン方式、性能に差があれば重み付けラウンドロビン方式、さらには応答時間アルゴリズムなどにより各構成要素の負荷が均等になるように負荷分散制御を行ない、ローカル通信ラインを介して故障が検出されると予備のロードバランサが稼動するよう構成されている。ここに、ローカル通信ラインとしてはＲＳ２３２−Ｃを使用するもの以外に他の通信規格による通信ラインを採用することも可能であり、さらには上述の第一または第二のネットワークを介してローカル通信するものであってもよい。
【００１５】
以下に本システムの動作を、モダリティ装置からの画像蓄積リクエスト、画像読出リクエスト、ビューワからの画像閲覧リクエストに対する応答動作などを例に説明する。
【００１６】
モダリティ装置１０は、２台のＤＩＣＯＭゲートウェイ４で構成された群に割当てられた仮想ＩＰアドレス（ＶＩＰ）でＤＩＣＯＭプロトコルにより画像蓄積リクエストを送信してアソシエーションを開始する。ロードバランサ７は、正常に稼動し且つ負荷の最小のＤＩＣＯＭゲートウェイ４を選択し、仮想ＩＰアドレスを宛先アドレスとして持つパケットをインターセプトして、選択したＤＩＣＯＭゲートウェイ４の実ＩＰアドレスに書き換える。以上の処理により画像蓄積リクエストは選択されたＤＩＣＯＭゲートウェイ４に受信される。また戻りのパケットはこれと逆の操作により通信が成立する。ここに、ＤＩＣＯＭゲートウェイ４は、ロードバランサ７により１アソシエーション単位で負荷分散される。
【００１７】
図２及び図３に示すように、リクエストがあったＤＩＣＯＭゲートウェイ４は、受信した画像情報を検査例ＵＩＤ（販売元前置コード、製品固有番号、シリアル番号などからなる）、患者名、患者ＩＤ、受入番号、検査日、検査時刻、患者の生年月日を含む属性情報と画像情報に分割し、分割した画像データを所定の可逆圧縮アルゴリズム（ここでは、ＰＮＧ（Ｐｏｒｔａｂｌｅ  Ｎｅｔｗｏｒｋ  Ｇｒａｐｈｉｃｓ）が使用されるが、それ以外であってもよい）により圧縮率の異なる複数の圧縮画像（ここでは、５１２×５１２ピクセルのオリジナル画像、２５６×２５６ピクセルの１／４画像、１２８×１２８ピクセルの１／１６画像、サムネイルとして使用される６４×６４ピクセルの１／６４画像の４種類の画像が生成格納されるが、これに限るものではない。）のそれぞれに圧縮処理して、コントロールユニット２に転送する。
【００１８】
コントロールユニット２は、転送された画像データを受信して後述するアルゴリズムにより画像データを格納するとともにその格納アドレスをＤＩＣＯＭゲートウェイ４に返信する。ＤＩＣＯＭゲートウェイ４は、前記属性情報をコントロールユニット２から返信された当該画像データの格納アドレスと伴に画像データベースサーバ３に転送してデータの更新処理を指示する。
【００１９】
上述した動作において関与するコントロールユニット２及び画像データベースサーバ３は、ＤＩＣＯＭゲートウェイ４と同様に、第一のネットワークＮ１を介して通信され、ロードバランサ７により負荷分散される。そして、以下に説明する各動作は、基本的には上述と同様にロードバランサ７により負荷分散されるものであるが、以後はロードバランサの動作説明は省略する。
【００２０】
次に、ＤＩＣＯＭゲートウェイ４がモダリティ装置１０から画像提供リクエストを受信したときには、図４及び図５に示すように、リクエスト画像を特定する属性情報の何れかのキー情報を基に画像データベースサーバ３から属性情報と格納アドレスを獲得するとともに、格納アドレスに基づいてストレージユニット１から可逆圧縮された圧縮画像を獲得し、当該圧縮画像を解凍処理して属性情報と伴にＤＩＣＯＭプロトコルによりモダリティ装置１０に返信する。
【００２１】
図６及び図７に示すように、画像データベースサーバ３に対してビューワ１１から画像データの閲覧リクエストがあると、リクエスト画像を特定する属性情報の何れかのキー情報を基に画像データベースサーバ３から属性情報と格納アドレスを獲得してビューワ１１に返信する。その後ビューワ１１は受信した格納アドレスに基づいてストレージユニット１をアクセスして所望の画像データを獲得する。ここに、ビューワ１１がＤＩＣＯＭビューワであれば、上述したＤＩＣＯＭゲートウェイ４を介した動作となるが、ＤＩＣＯＭプロトコルを使用しないものの、ＴＣＰ／ＩＰによるローカルプロトコルがサポートされていれば、任意の上位プロトコルが使用できる。
【００２２】
コントロールユニット２は、電源が立ち上がると、ロードバランサ７を介することなく（コントロールユニット２に対する外部アクセスはロードバランサ７により負荷分散される）、各ストレージユニット１に対して順番に第二のネットワークＮ２を介して稼動状況検査を実行し、その結果を画像データベースサーバ３の稼動状況テーブルに更新記憶する稼動状況検査手段を備えてあり、他のコントロールユニット２による前記稼動状況テーブルデータの更新履歴に基づいて、当該他のコントロールユニットの故障診断を行なう故障診断手段を備えてある。
【００２３】
詳述すると、稼動状況検査手段は、フレーム単位に、且つ、そのフレームに搭載され、数台のハードディスクを備えて構成されるストレージユニット１に対して順番に、ストレージユニットの装着状況、つまり、当該ユニットが取り外されているか、装着されているかという装着状況と、装着されている場合にドライブ毎のディスク残容量、ユニットのトータルの残容量を問い合わせるとともに、各ドライブに対して任意のファイルの書込み、読出しを行ない各ドライブのディスク障害を調査し、その結果をデータベースサーバ３の図１３に示す稼動状況テーブルに更新記憶する。尚、図１３には明記していないが、ストレージユニットＩＤの上位データにフレームＩＤを付加することにより、フレーム単位で管理可能に構成されている。
【００２４】
コントロールユニット２は、ストレージユニット１へのデータ格納リクエストに対して、データ格納先を稼動状況テーブルに基づいて識別された正常稼動しているストレージユニットから冗長化数分選択して格納する冗長化格納手段を備えてある。詳述すると、冗長化格納手段は稼動状況テーブルに基づいてドライブ単位にディスク残容量を調査し、ディスク残容量の大なるドライブを異なるストレージユニットに対して冗長化数分選択して格納する。ここでは、冗長化数を２に設定してある。従って、システム内で同じデータが異なるストレージユニット１に必ず存在することになる（ここに、冗長化数は２以上に設定されるものであってもよいことは言うまでもない。）
【００２５】
別の方法によれば、ストレージユニット１単位にディスク残容量を調査し、ディスク残容量の大なるストレージユニット１を二つ選択するとともに、選択したストレージユニット１の中からディスク残容量の大なるドライブを選択してデータを格納してもよい。データの格納アドレスは、格納リクエストの送信元に返信される。上述の画像データの格納リクエストに対しては、ＤＩＣＯＭゲートウェイ４に返信され、ＤＩＣＯＭゲートウェイ４により画像データの属性情報と伴に、または属性情報としてデータベースサーバ３に格納される。
【００２６】
さらに別の方法によれば、冗長化格納手段は稼動状況テーブルに基づいて、所定容量以上の残容量のストレージユニット１を候補として複数選択し、乱数生成手段により生成された乱数に基づいて対象となるストレージユニット１を二つ選択するように構成してもよい。例えば、候補として冗長化数よりも多い数のストレージユニットを選択し、乱数生成手段により１から９の任意の乱数を順番に生成して各候補のストレージユニットに割り付け、生成された乱数の値が大きなものから冗長化数分のストレージユニットを選択するなどにより実現できる。この場合には、新たに追加されたストレージユニットに負荷が集中することを未然に防止できるようになる。
【００２７】
またさらに別の方法によれば、冗長化格納手段は稼動状況テーブルに基づいて、異なるフレームに搭載されたストレージユニットに対して上述した何れかの方法により、冗長化格納処理を実行するように構成してもよい。この場合には、各フレームが設置される場所や建屋を異ならせることにより、火災、地震、水害などの災害からの影響を低く抑えることができるようになる。
【００２８】
また、冗長化格納手段が稼動状況テーブルに基づいてディスク残容量の調査をする場合に、格納される画像データに想定される最大容量よりも残容量の大きなものをサーチすることになるのであるが、逆に残容量がこの値よりも小さいときには稼動状況テーブルの残容量データに当該ドライブがフルである旨のデータを格納し、ストレージユニット１の全てのドライブがフルとなったときには、当該ストレージユニット１を選択対象から除外されるように構成することにより、ディスク残容量の調査のための時間が短縮できる。
【００２９】
コントロールユニット２は、さらに、稼動状況検査手段により異常と判断されたストレージユニット１またはドライブがあると、そのデータを復旧すべく、データベースサーバ３に格納された格納アドレスに基づいて、異常と判断されたストレージユニットまたはドライブに格納されているデータと同一のデータが格納されている他のストレージユニットのデータ格納アドレスを取得し、当該データ格納アドレスに格納されているデータを、同一データが格納されているストレージユニット１以外で、稼動状況テーブルに基づいて識別された正常稼動しているストレージユニット１から選択して複製する。このようにして、任意のストレージユニットが故障し、または取り外された場合であっても、画像データが自動的に複製され、新たなストレージユニットが追加された場合には追加されたストレージユニットに対する稼動状況テーブルが自動生成されるので、システムの電源をダウンさせることなくストレージユニットの追加や取り外しといったメンテナンス作業を行なうことができるのである。
【００３０】
コントロールユニット２の故障診断手段は、稼動状況テーブルを定期的または不定期にアクセスして、他のコントロールユニット２による稼動状況テーブルデータの更新履歴に基づいて、アクセス時から過去の所定時間以内になされた更新履歴が存在しないときに、当該他のコントロールユニットが故障しているものと判断し、予備のコントロールユニットが装着されているときには、予備のコントロールユニットを１台立ち上げる。
【００３１】
ここで、２台の稼動中のコントロールユニットのいずれか一方のユニットにより稼動状況検査手段を作動させ、他方のコントロールユニットにより故障診断手段を作動させるように構成してもよい。この場合には、他方のコントロールユニットによる故障診断手段の作動完了を示すフラグと作動時刻データを前記稼動状況テーブルに記録するように構成し、当該フラグと作動時刻データを一方のコントロールユニットがチェックすることにより他方のコントロールユニットの故障も検出可能となる。
【００３２】
尚、コントロールユニット２はストレージユニット１と同一基板上に一体的に構成してもよい。この場合には、例えば、２台のストレージユニットをアクティブに設定しておき、故障診断手段により一方の故障が発見されたときに予備のコントロールユニットをアクティブに切り替えるように構成することができる。
【００３３】
以下に画像データベースサーバ３の更新処理及び故障復旧処理について説明する。画像データベースサーバ３は、第一のネットワークＮ１を介してなされたデータの更新処理に対して、自らのデータベースを更新処理するとともに、第二のネットワークＮ２を介して他の画像データベースサーバ３のデータベースを更新処理する更新処理手段を備えている。
【００３４】
画像データベースサーバ３には、ロードバランサ７に対して更新用のポートと検索用のポートを備えてあり、正常時には、両ポートをオープンしている。さらに、一方の画像データベースサーバ３（図中、ＤＢ１）の更新処理手段は、他方の画像データベースサーバ３(図中ＤＢ２)の更新処理手段の最終動作時刻を管理しており、全てのテーブルの全レコードに最終更新日時を書き込み管理している。
【００３５】
図８及び図９に示すように、更新処理手段は、ロードバランサ７を介してＤＩＣＯＭゲートウェイ４から画像データの属性情報及び画像データの格納アドレスの格納リクエストや、コントロールユニット２からの稼動状況テーブルの格納リクエストなどのデータ更新リクエストがあると（図８中、丸１のステップ）、自分のデータベースを更新処理し（図８中、丸２のステップ）、次に第二のネットワーク２を介して他の画像データベースサーバ３のデータベースを更新処理する（図８中、丸３のステップ）。この動作が終了した時点で、リクエストに対するアクノリッジを返す（図８中、丸４のステップ）。
【００３６】
画像データベースサーバは、第一のネットワークＮ１に対してデータ更新用のポートとデータ検索用のポートを備え、第二のネットワークＮ２を介した他の画像データベースサーバのデータベースに対する復旧処理時にデータ更新用のポートをクローズする復旧処理手段を設けてある。
【００３７】
以下に詳述する。他方の画像データベースサーバ３が故障している場合には、その更新用ポート、検索用ポートの双方がクローズされ、ロードバランサ７は一方の画像データベースサーバ３に対してのみ処理を要求する。図１０に示すように、この場合には、更新リクエストに対しては自らのデータベースの更新処理のみを行いアクノリッジを返す。
【００３８】
上述の故障状態からの復旧時には、一方の画像データベースサーバ３は通常動作を行い、他方の画像データベースサーバ３は両ポートがクローズされている。図１１及び図１２に示すように、故障から復帰する他方の画像データベースサーバ３は、自分が更新した最終更新日時を一方の画像データベースサーバ３から取得し（図１１中、丸１のステップ）、復旧開始時刻を記録する（図１１中、丸２のステップ）。次に、第一ステップで取得した以降の更新日時のレコードを一方の画像データベースサーバ３から取得し、自らのデータベースを更新する（図１１中、丸３のステップ）。ステップ２で記録した復旧開始時刻を自らのデータベースの最終更新日時とし（図１１中、丸４のステップ）、第四ステップの最終更新日時と現在日時を比較し、ｎ秒以内になるまで上述のステップを繰り返す。ここに、ｎは数秒のオーダーである。ｎ秒以内になれば、一方の画像データベースサーバ３に対して復旧作業を依頼する（図１１中、丸５のステップ）。これに対して一方の画像データベースサーバ３は更新用ポートをクローズして（図１１中、丸６のステップ）他方の画像データベースサーバ３の最終更新日時以降のデータベースの更新処理を行い（図１１中、丸７のステップ）、更新処理終了後に更新用ポートをオープンして（図１１中、丸８のステップ）他方の画像データベースサーバ３に終了通知を送信する。他方の画像データベースサーバ３は両ポートをオープンして正常動作に復帰する（図１１中、丸９，１０のステップ）。尚、上述の説明では更新用ポート、検索用ポートの双方を各別に構成したものを説明したが、更新用ポート及び検索用ポートを同一のポートとして構成することも可能である。
【００３９】
以下に別実施の形態を説明する。上述の実施形態では、セッション層以上の上位層が、医療分野における画像診断規格であるＤＩＣＯＭプロトコルまたは、他のローカルなプロトコルで動作するシステムを説明したが、ビューワなどの端末がＷＥＢに対応するように構成することも可能である。この場合には、例えば、上述した基本フレームに、複数のＷＥＢサーバからなるＷＥＢサーバ群を設けて、ロードバランサ７の管理下で作動するように構成すればよい。
【００４０】
上述した実施形態ではストレージユニットとしてハードディスクで構成されたものを説明したが、ストレージユニットはハードディスクに限定されるものではなく、不揮発性の半導体メモリや、他のメディアを使用するものであってもよい。
【００４１】
上述したシステムにおいて、ストレージユニット、コントロールユニット、画像データベースサーバ３、ＤＩＣＯＭゲートウェイの何れかまたは全てをユニット単位でホットスワップ可能に構成することにより、システムの稼動状態を維持しながらメンテナンスできるようになる。
【００４２】
上述した実施形態では、医療用画像データを蓄積管理する画像データベースシステムについて説明したが、本システムは画像以外の種々の文書データを蓄積管理するデータベースシステムに適用可能なことは言うまでもない。
【００４３】
上述の実施形態は、本発明の一例に過ぎず、課題を解決するための手段の項に記載したように、各構成要素の組み合わせにより複数の形態のデータベースシステムが構築されるものである。
【図面の簡単な説明】
【００４４】
【図１】本発明による画像データベースシステムの構成図
【図２】画像格納手順の説明図
【図３】画像格納手順のフローチャート
【図４】画像提供手順の説明図
【図５】画像提供手順のフローチャート
【図６】ビューワによる画像検索手順の説明図
【図７】ビューワによる画像検索手順のフローチャート
【図８】画像データベースサーバの動作説明図
【図９】画像データベースサーバのフローチャート
【図１０】画像データベースサーバの動作説明図
【図１１】画像データベースサーバの動作説明図
【図１２】画像データベースサーバのフローチャート
【図１３】稼動状況テーブルの説明図
【符号の説明】
【００４５】
１：ストレージユニット
２：コントロールユニット
３：画像データベースサーバ
４：ＤＩＣＯＭゲートウェイ
５，６：スイッチ
７：ロードバランサ
１０：モダリティ装置
１１：ビューワ
【図１】
0004510785.tif 000002
【図２】
0004510785.tif 000003
【図３】
0004510785.tif 000004
【図４】
0004510785.tif 000005
【図５】
0004510785.tif 000006
【図６】
0004510785.tif 000007
【図７】
0004510785.tif 000008
【図８】
0004510785.tif 000009
【図９】
0004510785.tif 000010
【図１０】
0004510785.tif 000011
【図１１】
0004510785.tif 000012
【図１２】
0004510785.tif 000013
【図１３】
0004510785.tif 000014