本発明の実施例を詳細に説明する前に、まず概要を説明する。本発明の実施例におけるデータ記憶システムは、複数のデータベースと、データベースを管理する管理システムとを備えて、複数のデータベースにデータを分散保存させる機能をもつ。このデータ記憶システムでは、複数のデータベースは同じ複数のフィールドを含むテーブルを有する。各テーブルには、データ値の書込または読出が可能なフィールドと、当該テーブル以外の他のテーブルへのリンク情報が格納されるフィールドとが設けられる。このように本実施例のデータ記憶システムでは、各データベースのテーブルにおいて、データ値を格納するフィールドと、データ値を記憶可能な他のテーブルへのリンク情報を格納するフィールドの2種類を設けることで、アプリケーションプログラムによるデータ記憶システムへのアクセスを容易にすることが可能となる。以下の実施例では、医用情報を記憶する医用データ記憶システムについて説明するが、用途は医用情報の記憶に限定されるものではない。
図1は、本発明の実施例にかかるデータ記憶システム1の構成を示す。実施例にかかるデータ記憶システム1は、患者DB10a、器材DB10b、レポートDB10c、静止画DB10d、動画DB10eおよびマスタDB10fを含む複数のデータベース(以下、総称する場合は「DB10」とよぶ)と、DB10を管理するデータベース管理システム(以下、「DBMS20」とよぶ)を備える。DBMS20は、ネットワーク30を介して医用サーバ40に接続される。医用サーバ40では、DB10にアクセスするためのアプリケーションプログラム50が起動され、医用サーバ40は、アプリケーションプログラム50により、所望のDB10に対してデータを書き込み、または読み出すことができる。医用サーバ40は、病院内部に設けられる。
実施例では、データ記憶システム1における全てのDB10が病院外部に配設されている。たとえば、法律等による諸々の制約条件が緩和されて、病院外部に全ての情報を持ち出せるようになった場合に、医用情報を全て病院外部のDB10に分散保存するようにした例である。
本実施例においてDB10は、情報の集合体を意味し、DBMS20と協同してデータ記憶システム1を構築する。DB10は、複数のフィールドを含むテーブルそのものであってよく、DBMS20は、複数のテーブルの相互に関係をもたせて管理するリレーショナルデータベース管理システムであってもよい。本実施例において複数のDB10は、同じ複数のフィールドを含むテーブルを有して構成される。各DB10は、1つのテーブルを有してもよく、2以上のテーブルを有してもよいが、以下では、DB10が1つのテーブルを有する器であるものとして説明する。なお、複数のDB10は、異なるハードディスクなどの記憶装置に構築されてもよく、また同一の記憶装置に構築されてもよい。
各DB10のテーブルは、同じ複数の項目を有して構成される。これにより、各テーブルは同じフィールドをもつことになる。各テーブルは、データ値の書込または読出が可能な「第1フィールド」と、当該テーブル以外の他のテーブルへのリンク情報が格納される「第2フィールド」とを有する。データ値の書込または読出が可能な第1フィールドは、テーブルごとに設定される。以下、各DB10に割り当てられる第1フィールドおよび第2フィールドを例示する。
図2は、各DB10のテーブルの例を示す。
図2(a)は、患者DB10aのテーブルを示す。患者DB10aのテーブルは、患者氏名および患者IDのフィールドのみを第1フィールドに設定され、それ以外のフィールドを第2フィールドに設定される。これにより患者DB10aにおいては、患者氏名および患者IDのフィールドにデータ値が書き込まれ、または記憶したデータ値が読み出されることを可能とする一方で、患者氏名および患者ID以外のフィールドにデータ値を書き込むことはできない。図2(a)に示す例では、レコードIDを「0001」とするレコードとして、患者氏名「AAA」、患者ID「100100」が保存され、患者氏名および患者ID以外のフィールドには、対応するデータ値が格納されている又は格納されるべき他のDB10のリンク情報が格納されている。レコードIDを「0002」とするレコードについても同様である。リンク情報は、当該他のDB10のアクセス先を特定できる情報であればよく、たとえばIPアドレスの形式をとってもよい。
図2(b)は、器材DB10bのテーブルを示す。器材DB10bのテーブルは、使用器材のフィールドのみを第1フィールドに設定され、それ以外のフィールドを第2フィールドに設定される。これにより器材DB10bにおいては、使用器材のフィールドにデータ値が書き込まれ、または記憶したデータ値が読み出されることを可能とする一方で、使用器材以外のフィールドにデータ値を書き込むことはできない。図2(b)に示す例では、レコードIDを「0001」とするレコードとして、使用器材「なし」が保存され、使用器材以外のフィールドには、対応するデータ値が格納されている又は格納されるべき他のDB10のリンク情報が格納されている。レコードIDを「0002」とするレコードについても同様である。
図2(c)は、レポートDB10cのテーブルを示す。レポートDB10cのテーブルは、レポートのフィールドのみを第1フィールドに設定され、それ以外のフィールドを第2フィールドに設定される。これによりレポートDB10cにおいては、レポートのフィールドにデータ値が書き込まれ、または記憶したデータ値が読み出されることを可能とする一方で、レポート以外のフィールドにデータ値を書き込むことはできない。図2(c)に示す例では、レコードIDを「0001」とするレコードとして、レポート「レポート100100.File」が保存され、レポート以外のフィールドには、対応するデータ値が格納されている又は格納されるべき他のDB10のリンク情報が格納されている。レコードIDを「0002」とするレコードについても同様である。
以上は、患者DB10a、器材DB10b、レポートDB10cのテーブルであるが、他のDB10、すなわち静止画DB10d、動画DB10e、マスタDB10fなどについても同様である。
以上のように、データ記憶システム1においては、複数のDB10が同一のテーブルを有し、それぞれに割り当てられるデータ項目のみのデータ値を保存する。これにより、データの分散保存を実現でき、セキュリティの高いデータ記憶システム1を実現できる。また、各DB10が同一のレコードを記憶することで、後述するように、医用サーバ40のアプリケーションプログラム50は、データ記憶システム1におけるDB構造を意識することなく、所望のデータにアクセスできるようになる。
図3は、医用サーバ40の構成を示す。医用サーバ40は、アクセス先設定部43、通信部44、判別部45、医用データ格納部46および制御部47を備える。制御部47は、読出指示部41および書込指示部42を備える。このうち、読出指示部41、書込指示部42、アクセス先設定部43および判別部45は、アプリケーションプログラム50により実現される。読出指示部41はDB10に対してデータの読出を指示する機能をもち、書込指示部42はDB10に対してデータの書込を指示する機能をもつ。アクセス先設定部43は、複数のDB10のうち、アクセス先となるDBを設定する。判別部45は、DB10から送信される情報を判別し、判別結果に応じた処理を実行する。医用データ格納部46は、DB10に対して書き込むデータを一時的に記憶し、またDB10から読み出されたデータを一時的に記憶するバッファ装置である。通信部44は、ネットワーク30を介してアクセス先設定部43により特定されるDBとの間で情報を送受信する。
図4は、DBMS20の構成を示す。DBMS20は、通信部21、書込/読出制御部22、レコード作成部23およびマッピング情報保持部24を備える。書込/読出制御部22は、医用サーバ40により指示されるDBにアクセスして、データを書き込み、または読み出す処理を実行する。レコード作成部23は、DBMS20で管理する全てのDB10に新しいレコードを作成する。マッピング情報保持部24は、データ値の書込が可能なフィールドをテーブルごとに特定するマッピング情報を保持する。このマッピング情報を利用して、レコード作成部23は、管理下にあるDB10に新しいレコードを追加することができる。通信部21は、ネットワーク30を介して医用サーバ40との間で情報を送受信する。
以下、図3および図4を参照して、DB10に対してデータを書き込む手順と、DB10からデータを読み出す手順について説明する。
<データ書込手順>
一例として、レコードID「0003」のレコードの使用器材フィールドに、「内視鏡」と書き込む場合について説明する。
データをDB10に書き込む前段階として、アプリケーションプログラム50は、DB10がデータを書き込める状態にあるか確認する。そのために、読出指示部41が、レコードIDと、項目(フィールド)を特定した情報を含む読出指示を作成し、通信部44が、アクセス先設定部43により特定されるアクセス先に読出指示を送信する。ここでは、レコードIDを「0003」、フィールド特定情報を「使用器材」とする読出指示が作成される。アクセス先設定部43は、アクセス先として、所定のDB10のアドレスを保持している。本実施例のデータ記憶システム1では、各DB10が第1フィールドと第2フィールドを保持することで、アクセス先は任意のDB10でよい。アクセス先設定部43は、たとえば患者DB10aのアドレスをアクセス先のデフォルト値として保持する。この場合、通信部44は、患者DB10aに読出指示を送信する。
DBMS20の通信部21は、患者DB10aに対する読出指示を受け取り、書込/読出制御部22に送る。書込/読出制御部22は、読出指示に含まれるレコードIDと、フィールド特定情報をもとに、患者DB10aから情報を読み出す。
読出指示に含まれるレコードIDが「0003」の場合、図2(a)を参照して、患者DB10aのテーブルには、該当するレコードが存在しない。したがって書込/読出制御部22は、該当するレコードが存在しないことを示すレコード未保存情報を通信部21から医用サーバ40に送信させる。判別部45は、通信部44からレコード未保存情報を受け取ると、DB10がデータを書き込めない状態にあることを確認し、書込指示部42に対して、新規レコードの作成指示を生成させる。書込指示部42は、レコードID「0003」のレコードを用意させるレコード作成指示を作成し、通信部44が、患者DB10aにレコード作成指示を送信する。
レコード作成部23は、通信部21からレコード作成指示を受けると、マッピング情報保持部24に保持されているマッピング情報を利用して、全てのDB10のテーブルに新たなレコードを追加する。図2(a)〜図2(c)に関連して説明したように、患者DB10aは、患者氏名および患者IDのフィールドのみへのデータ書込を可能とし、器材DB10bは、使用器材のフィールドのみへのデータ書込を可能とし、レポートDB10cは、レポートのフィールドのみへのデータ書込を可能とする。データ書込が可能とされないフィールドには、データが書き込まれるべき他のテーブルのリンク情報が書き込まれる。マッピング情報保持部24は、この情報をマッピング情報としてテーブルごとに保持しており、レコード作成部23は、このマッピング情報を利用することで、各テーブルに、レコードを適切に追加することができる。
図5は、各DB10のテーブルの例を示す。図5(a)は、患者DB10aのテーブルを示し、図5(b)は、器材DB10bのテーブルを示し、図5(c)は、レポートDB10cのテーブルを示す。
図5(a)の患者DB10aのテーブルでは、レコードID「0003」のレコードが追加され、患者氏名および患者IDのフィールドには、データを書き込むことが可能なことを示す「null」が記録される。患者氏名および患者ID以外のフィールドには、対応するデータ値が格納されるべき他のDB10のリンク情報が記録されている。
図5(b)の器材DB10bのテーブルでは、レコードID「0003」のレコードが追加され、使用器材のフィールドには、データを書き込むことが可能なことを示す「null」が記録される。使用器材以外のフィールドには、対応するデータ値が格納されるべき他のDB10のリンク情報が記録されている。
図5(c)のレポートDB10cのテーブルでは、レコードID「0003」のレコードが追加され、レポートのフィールドには、データを書き込むことが可能なことを示す「null」が記録される。レポート以外のフィールドには、対応するデータ値が格納されるべき他のDB10のリンク情報が記録されている。
なお、静止画DB10d、動画DB10eなどの他のテーブルについても同様である。
レコード作成部23は、全DB10にレコードを作成すると、レコード作成が終了したことを示すレコード作成終了情報を通信部21から医用サーバ40に送信させる。判別部45は、通信部44からレコード作成終了情報を受け取ると、読出指示部41に、レコードIDと、フィールドを特定した情報を含む読出指示を作成させる。ここでは、レコードIDを「0003」、フィールド特定情報を「使用器材」とする読出指示が作成される。読出指示は、通信部44から患者DB10aに送信される。
書込/読出制御部22は、患者DB10aのレコードID「0003」で特定されるレコードの使用器材フィールドに記録されているデータを読み出す。図5(a)を参照して、このフィールドには、「器材DBのリンク情報」が記録されている。書込/読出制御部22は、この情報を通信部21から医用サーバ40に送信させ、判別部45は、通信部44から情報を受け取ると、リンク情報であることを判別し、書込指示部42に対して、データの書込指示を生成させる。書込指示部42は、レコードID「0003」と、フィールド特定情報「使用器材」と、書き込むべきデータ値「内視鏡」を含む書込指示を作成する。
このとき、判別部45は、アクセス先設定部43に設定されているアクセス先のアドレスを、器材DB10bのアドレスに一時的に変更する。これにより、通信部44は、器材DB10bに書込指示を送信する。なお、変更したアクセス先のアドレスは、書込指示の送信後、元のデフォルトのアクセス先のアドレスに戻される。書込/読出制御部22は、書込指示を受けると、器材DB10bのテーブルのレコードID「0003」で特定されるレコードの「使用器材」フィールドに、「内視鏡」を記録する。これにより、データを適切なDB10に書き込むことができる。書込/読出制御部22は、書込処理を終了すると、医用サーバ40に対して書込終了メッセージを送信する。
以上は、リンク情報がDBMS20から返信された後、すぐに書込指示を作成する例について説明したが、リンク情報が返信されると、そのリンク情報で特定されるDB10のテーブルに、レコードが本当に存在しているか確認するための読出指示を送信することも可能である。DB10より「null」データが返信されると、判別部45は、書込指示部42に対して書込指示を生成させる。
データ記憶システム1では、各DB10が第1フィールドと第2フィールドを保持することで、アプリケーションプログラム50は、最初はどのDBにアクセスしても、結果としてデータを書き込むことができる。そのため、上述の例では、アクセス先設定部43がアクセス先を変更したあと、すぐにデフォルト値に戻すこととしたが、変更後のアクセス先を、そのまま保持することも可能である。
レコードID「0003」のレコードが作成された後、レコードID「0003」の患者氏名のフィールドに「CCC」、および患者IDのフィールドに「301243」と書き込む場合について説明する。
読出指示部41は、レコードIDを「0003」、フィールド特定情報を「患者氏名」および「患者ID」とする読出指示を作成する。読出指示は、通信部44から患者DB10aに送信される。
書込/読出制御部22は、患者DB10aのレコードID「0003」で特定されるレコードの患者氏名フィールド、患者IDフィールドに記録されているデータを読み出す。図5(a)を参照して、これらのフィールドには、それぞれ「null」が記録されている。書込/読出制御部22は、この情報を通信部21から医用サーバ40に送信させ、判別部45は、通信部44から情報を受け取ると、データを書込可能であることを判別し、書込指示部42に対して、データの書込指示を生成させる。書込指示部42は、レコードID「0003」と、フィールド特定情報「患者氏名」および「患者ID」と、書き込むべきデータ値「CCC」、「301243」を含む書込指示を作成する。通信部44は、患者DB10aに書込指示を送信する。書込/読出制御部22は、書込指示を受けると、患者DB10aのテーブルのレコードID「0003」で特定されるレコードの「患者氏名」および「患者ID」フィールドに、「CCC」、「301243」を記録する。これにより、データを適切なDB10に書き込むことができる。書込/読出制御部22は、書込処理を終了すると、医用サーバ40に対して書込終了メッセージを送信する。
このように、医用サーバ40は、複数のDB10の構造を把握することなく、適切なDB10にデータを書き込むことが可能である。これは、各テーブルが同一の構造をとり、データを書込可能な第1フィールドと、他のテーブルへのリンク情報を格納する第2フィールドとを有することで実現される。このように複数のDB10を構築することで、アプリケーションプログラム50は、単純な機能でデータの書込処理を実現できる。また、DB10に変更があった場合でも、アプリケーションプログラム50側でSQL文などの変更を必要としないため、病院側のシステム管理者の負担を軽減することができる。
<データ読出手順>
一例として、レコードID「0002」の使用器材のフィールドからデータを読み出す場合について説明する。
読出指示部41は、レコードIDを「0002」、フィールド特定情報を「使用器材」とする読出指示を作成し、通信部44が、アクセス先設定部43により特定されるアクセス先に読出指示を送信する。このアクセス先のアドレスは、患者DB10aのアドレスであり、通信部44は、患者DB10aに読出指示を送信する。
書込/読出制御部22は、通信部21から読出指示を受け取り、読出指示に含まれるレコードIDと、フィールド特定情報をもとに、患者DB10aから情報を読み出す。図5(a)を参照して、レコードID「0002」のレコードの「使用器材」フィールドには、「器材DBのリンク情報」が記録されている。書込/読出制御部22は、この情報を通信部21から医用サーバ40に送信させ、判別部45は、通信部44から情報を受け取ると、リンク情報であることを判別し、読出指示部41に対して、データの読出指示を再生成させる。
このとき、判別部45は、アクセス先設定部43に設定されているアクセス先のアドレスを、器材DB10bのアドレスに一時的に変更する。これにより、通信部44は、器材DB10bに読出指示を送信する。なお、変更したアクセス先のアドレスは、読出指示の送信後、元のデフォルトのアクセス先のアドレスに戻される。書込/読出制御部22は、読出指示を受けると、器材DB10bのテーブルのレコードID「0002」で特定されるレコードの「使用器材」フィールドから、データ値「内視鏡」を読み出す。書込/読出制御部22は、読出処理を終了すると、医用サーバ40に対して、データ値「内視鏡」を送信する。
データ記憶システム1では、各DB10が第1フィールドと第2フィールドを保持することで、アプリケーションプログラム50は、最初はどのDBにアクセスしても、結果としてデータを読み出すことができる。そのため、上述の例では、アクセス先設定部43がアクセス先を変更したあと、すぐにデフォルト値に戻すこととしたが、変更後のアクセス先を、そのまま保持することも可能である。
次に、レコードID「0002」の患者氏名および患者IDのフィールドからデータを読み出す場合について説明する。
読出指示部41は、レコードIDを「0002」、フィールド特定情報を「患者氏名」および「患者ID」とする読出指示を作成し、通信部44が、アクセス先設定部43により特定されるアクセス先に読出指示を送信する。このアクセス先のアドレスは、患者DB10aのアドレスであり、通信部44は、患者DB10aに読出指示を送信する。
書込/読出制御部22は、通信部21から読出指示を受け取り、読出指示に含まれるレコードIDと、フィールド特定情報をもとに、患者DB10aから情報を読み出す。図5(a)を参照して、レコードID「0002」のレコードの「患者氏名」フィールドおよび「患者ID」フィールドには、「BBB」、「200235」が記録されている。書込/読出制御部22は、このデータ値「BBB」、「200235」を読み出す。書込/読出制御部22は、読出処理を終了すると、医用サーバ40に対して、データ値「BBB」、「200235」を送信する。
このように、医用サーバ40は、複数のDB10の構造を把握することなく、適切なDB10からデータを読み出すことが可能である。これは、各テーブルが同一の構造をとり、データが記録されている第1フィールドと、他のテーブルへのリンク情報を格納する第2フィールドとを有することで実現される。このように複数のDB10を構築することで、アプリケーションプログラム50は、単純な機能でデータの読出処理を実現できる。また、DB10に変更があった場合でも、アプリケーションプログラム50側でSQL文などの変更を必要としないため、病院側のシステム管理者の負担を軽減することができる。
図6は、DBMS20の構成の変形例を示す。DBMS20は、図4に示した通信部21、書込/読出制御部22、レコード作成部23およびマッピング情報保持部24に加えて、判別部25を備える。判別部25は、図3に示す医用サーバ40の判別部45の機能を代替する。
具体的に判別部25は、書込/読出制御部22で取得された情報をもとに、アプリケーションプログラム50により書き込みを希望するレコードの存在の有無を判別する。図2に示すDB10の例では、レコードID3のレコードが存在しないため、既述したように書込/読出制御部22は、該当するレコードが存在しないことを示すレコード未保存情報を生成する。判別部25は、レコード未保存情報を受け取ると、DB10がデータを書き込めない状態にあることを確認し、レコード作成部23に対してレコードID「0003」のレコードを用意させるレコード作成指示を作成する。レコード作成部23は、レコード作成指示を受けると、マッピング情報保持部24に保持されているマッピング情報を利用して、全てのDB10のテーブルに新たなレコードを追加する。
また判別部25は、書込/読出制御部22でDB10から読み出した情報が、所望のデータ値であるのか、またはリンク情報であるかを判別する。所望のデータ値であるときは、判別部25は、書込/読出制御部22に対して送信指示を送り、書込/読出制御部22は、そのデータ値を通信部21から医用サーバ40に送信する。一方、リンク情報であるときは、書込/読出制御部22に対して、そのリンク情報で特定されるテーブルに保持されたデータ値を読み出させる。判別部25は、このデータ値がリンク情報でないことを確認すると、書込/読出制御部22に対して送信指示を送り、書込/読出制御部22は、そのデータ値を通信部21から医用サーバ40に送信する。
以上のように、判別部25をDBMS20に持たせることで、アプリケーションプログラム50から判別部45の機能を外すことができ、アプリケーションプログラム50の開発工数を削減できる。また、DBMS20と医用サーバ40の間の通信回数を少なくできるため、情報の読出時間または書込時間を短縮できる。
図7は、本発明の実施例にかかるデータ記憶システムの構成の変形例を示す。このデータ記憶システム1aは、患者DB10a、器材DB10b、レポートDB10c、静止画DB10d、動画DB10eおよびマスタDB10fを含む複数のDB10と、DB10を管理する複数のDBMS20を備える。データ記憶システム1aでは、患者DB10aおよび器材DB10bを管理するDBMS20aと、レポートDB10c、静止画DB10d、動画DB10e、マスタDB10fを管理するDBMS20bとが設けられる。
DBMS20aおよび20bは、それぞれが管理するDB10のマッピング情報をもっており、レコードの追加指示を受けて、DB10にレコードを追加する。その他の構成および動作は、図1に示すデータ記憶システム1のDBMS20と同様である。なお、図6に示すように判別部25を各DBMS20にもたせる場合は、レコードの追加指示を生成した判別部25が、別のDBMS20のレコード作成部23に対してもレコード追加指示を伝えることで、データ記憶システム1aにおける全てのテーブルに、同じレコードを作成することが可能となる。
図8は、本発明の実施例にかかるデータ記憶システムの構成の変形例を示す。このデータ記憶システム1bは、患者DB10a、器材DB10b、レポートDB10c、静止画DB10d、動画DB10eおよびマスタDB10fを含む複数のDB10と、DB10を管理する複数のDBMS20を備える。データ記憶システム1bでは、患者DB10aを管理するDBMS20dと、器材DB10b、レポートDB10c、静止画DB10d、動画DB10e、マスタDB10fを管理するDBMS20cとが設けられる。DBMS20dおよび患者DB10aは病院内部に設けられ、DBMS20cおよびDB10b〜10fは病院外部に設けられる。
DBMS20cおよび20dは、それぞれが管理するDB10のマッピング情報をもっており、レコードの追加指示を受けて、DB10にレコードを追加する。その他の構成および動作は、図1に示すデータ記憶システム1のDBMS20と同様である。なお、図6に示すように判別部25を各DBMS20にもたせる場合は、レコードの追加指示を生成した判別部25が、別のDBMS20のレコード作成部23に対してもレコード追加指示を伝えることで、データ記憶システム1bにおける全てのテーブルに、同じレコードを作成することが可能となる。
なお、図8に示すデータ記憶システム1bでは、患者DB10aが病院内部に設けられている。たとえば、患者情報を病院外部で管理してはいけないという法律的な規制が課されている場合、DB10b〜10fのいずれかにアクセスすることで、患者DB10aのリンク情報から患者DB10aにアクセスできることは禁止されなければならない。そこで、病院外部に情報開示することが好ましくないDB10については、外部からのアクセスを禁止するために、そのDB10のリンク情報が、院外DB10のレコードから削除されてもよい。これにより、情報開示を禁止されているDB10への外部からのアクセスが不可能となり、法律による規制を遵守することができる。なお、このような事情は法律の問題だけでなく、病院側で情報を外部に開示したくない場合も含まれる。
一方、このような情報開示の是非についての事情は、時代に応じて変化することもある。たとえば患者情報を外部で管理してもよくなった場合、院外DB10のレコードにリンク情報を追記すればよい。また、そのような事態に事前に備えるべく、リンク情報は予め格納しておき、院内DB10からの読出を不可とするフラグをオンに設定しておくことで対応することも可能である。事情の変化により外部への情報開示が可能となったときに、このフラグをオフに設定することで、外部からのアクセスを可能にできる。これは、フラグの設定だけですむため、事情の変化に効率よく対応できる利点がある。
図9は、本発明の実施例にかかるデータ記憶システムの構成の変形例を示す。このデータ記憶システム1cは、患者DB10a、器材DB10b、レポートDB10c、静止画DB10d、動画DB10eおよびマスタDB10fを含む複数のDB10と、DB10を管理するDBMS20eを有するアプリケーションサーバ70を備える。DBMS20eは、DB10a〜10fを管理する。アプリケーションサーバ70は、伝文パーサ60、アプリケーションプログラム50aをさらに有する。図9に示すデータ記憶システム1cでは、医用サーバ40から、各種指示またはデータを含む伝文がアプリケーションサーバ70に送信され、伝文パーサ60が、その伝文を構文解析して、アプリケーションプログラム50aに引き渡す。
伝文の形式は、一般に医用サーバ40ごとに異なる。また医用サーバ40のバージョンがアップすると、伝文形式がバージョンアップされることもある。そのような場合、伝文パーサ60は、伝文を構文解析して、アプリケーションプログラム50aで処理可能なデータに分解することで、データ記憶システム1cが効率的に動作することが可能となる。なお伝文パーサ60は、医用サーバ40のゲートウェイに設けられてもよい。いずれの場合であっても、医用サーバ40の伝文形式の違いを伝文パーサ60で吸収することで、医用サーバ40は、DB10の構造を意識することなく、データの書込または読出を効率よく実行することが可能となる。
図10は、本発明の実施例にかかるデータ記憶システムの構成の変形例を示す。このデータ記憶システム1dは、患者DB10a、器材DB10b、レポートDB10c、静止画DB10d、動画DB10eおよびマスタDB10fを含む複数のDB10と、DB10を管理するDBMS20fを備える。データ記憶システム1dでは、医用サーバ40がネットワーク30を介してWebサーバ80と接続し、アプリケーションプログラム50bが、Webサーバ80とDBMS20fに接続する構成がとられている。
データ記憶システム1dでは、DB10が全てファイアウォール内に配置される。医用サーバ40からアクセスがあると、アプリケーションプログラム50bがDBMS20fからデータを抽出し、医用サーバ40で参照可能な形にしてWebサーバ80にデータを配置する。Webサーバ80は、医用サーバ40からのアクセスが終了したときに、アプリケーションプログラム50bから供給されたデータを削除する。
このような構成をとることで、DB10を外部ネットワークにさらす必要がなくなるため、セキュリティの高いデータ記憶システム1dを構築できる。また、Webサーバ80のデータは、医用サーバ40からのアクセスが終了次第、削除することで、情報流出を防いだシステムを実現できる。
なおWebサーバ80にデータを配置する場合、アプリケーションプログラム50bは、DB10からの情報をxml化してもよい。複数のDB10に分散保存した情報を収集してWebサーバ80に配置する場合、それぞれのテーブルに格納されているデータ容量に差があるため、Webサーバ80に配置するまでの時間が異なることが想定される。そこで、Webサーバ80は、DB10からデータの読出しが終わるまで、各DB10について「ローディング中」であることを示す文字列を表示させ、たとえば読出しが終了したDB10から、レコード情報を表示していくようにしてもよい。これにより、全ての情報が揃わなくても医用サーバ40に結果を表示することができるため、医用サーバ40において情報表示を待っているユーザのストレスを軽減することができる。
以上は、データ記憶システムにおいてDB10が既に作成されていることを前提としたが、DB構造は、ユーザにより以下のように初期設定されてもよい。
図11は、DB作成ツールの構成を示す。DB作成ツール90は、病院外のデータサーバに設けられてもよく、また病院内の医用サーバ40に設けられてもよい。DB作成ツール90は、入力受付部91、選択項目取得部92、変更部93、テーブル生成部94、マーク部95、GUI生成部96およびリスト保持部97を備える。
図12は、DB作成ツール90によりディスプレイに表示されるDB作成画面100を示す。このDB作成画面100には、追加ボタン101、削除ボタン102、修正ボタン103、保存ボタン104からなるボタン群と、仮DB作成画面105およびリスト選択画面106が表示される。リスト選択画面106には、ユーザにより設定可能な項目リストがチェックボックス107とともに表示される。ユーザがチェックボックス107を選択し、追加ボタン101を押下すると、仮DB作成画面105に仮DBアイコン108が表示される。
GUI生成部96は、リスト保持部97から設定可能リストを読み込み、GUI画面を生成して、ディスプレイに表示する。このGUI画面が、図12に示すDB作成画面100である。ユーザは、作成したいテーブルごとにチェックボックス107をチェックし、追加ボタン101を押下すると、入力受付部91が選択された項目を受け付け、選択項目取得部92に送る。選択項目取得部92は、選択項目を取得して、仮DBアイコン108を仮DB作成画面105に表示させる。なお、仮DBアイコン108を表示する前に、DB作成画面100に、そのDBにつける名前と、DBの格納先を入力するウインドウが表示され、ユーザにより、DB名と格納先とが決定されてもよい。これらの決定情報は、それぞれ対応付けられてテーブル生成部94に送られる。
マーク部95は、選択済みのチェックボックス107が再選択されないように、選択済みのチェックボックス107にマークを付与する。図12の例では、患者氏名、患者IDのチェックボックスが、再選択できないように×マークされている。なおマーク部95は、選択済みのチェックボックス107に色付けするなど、通常色とは異なる配色を施してもよい。なお、リスト選択画面106において、使用器材のチェックボックス107にチェックが入っているが、この状態で追加ボタン101が押下され、DB名および格納先が決定されると、仮DBアイコン108が仮DB作成画面105に表示され、また使用器材のチェックボックス107に×マークが表示される。
ユーザが、以上のようにしてDBに格納する情報を決定する。選択項目取得部92は、各DBに対して選択された項目を取得し、テーブル生成部94が、DB名と対応付けて、選択項目を保持する。ユーザにより、保存ボタン104が押下されると、入力受付部91は、テーブル生成部94に、各DBのテーブルを作成する指示を送る。テーブル生成部94は、選択された全ての項目を収集して、各テーブルに設定する項目を特定する。また、各DBごとに選択された項目を利用して、それぞれのテーブルを作成する。これにより、DB10は、図2に示すテーブルを保持することが可能となる。
DBの作成時、ユーザは、削除ボタン102を押下して、仮DBアイコン108を削除することで、設定した仮DBについての情報をリセットできる。これにより、マーク部95は、対応するチェックボックス107の×マークを解除し、ユーザにより選択可能な状態に変更する。
ユーザは、修正ボタン103を押下して、設定したDBのテーブルを修正することができる。テーブル生成部94は、ユーザから修正指示が入ると、対応するテーブルの修正処理を行う。
データをテーブル間で移動させる指示の場合、テーブル生成部94は、移動元のテーブルのフィールドから移動先のテーブルのフィールドにデータをコピーする。次に、移動元および移動先のテーブル以外のテーブルの同じフィールドのリンク情報を、移動先のアドレスを示すリンク情報に置換する。それから、移動元のフィールドのデータを、移動先のアドレスを示すリンク情報に置換する。これにより、テーブル生成部94は、データをテーブル間で移動させることができる。なお、新たなDBを作成して、新たなDBにデータを移動する場合も同様であり、この場合は新規DBのテーブルが移動先のテーブルに対応する。
テーブルの修正処理が終了すると、テーブル生成部94は、マッピング情報保持部24(図4参照)に保持していたマッピング情報を更新する。複数のDBMS20が存在するデータ記憶システム1においては、1つのDBMS20に組み込まれたDB作成ツール90がDB作成処理を実行し、その処理結果を示すマッピング情報を他のDBMS20に通知することで、他のDBMS20においても同様のDB修正処理が実行される。
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。実施例では、DB10は院外に配置され、または院外または院内に配置されるとしたが、全てのDB10が院内に配置されてもよい。また、実施例では医用情報の記憶システムについて説明したが、他の種類の情報の記憶システムについても本発明を適用できることは言うまでもない。
1・・・データ記憶システム、10・・・DB、20・・・DBMS、21・・・通信部、22・・・書込/読出制御部、23・・・レコード作成部、24・・・マッピング情報保持部、25・・・判別部、30・・・ネットワーク、40・・・医用サーバ、41・・・読出指示部、42・・・書込指示部、43・・・アクセス先設定部、44・・・通信部、45・・・判別部、46・・・医用データ格納部、47・・・制御部、50・・・アプリケーションプログラム、60・・・伝文パーサ、70・・・アプリケーションサーバ、80・・・Webサーバ、90・・・DB作成ツール、91・・・入力受付部、92・・・選択項目取得部、93・・・変更部、94・・・テーブル生成部、95・・・マーク部、96・・・GUI生成部、97・・・リスト保持部。