JP5214178B2 - データ記憶システム - Google Patents

データ記憶システム Download PDF

Info

Publication number
JP5214178B2
JP5214178B2 JP2007154982A JP2007154982A JP5214178B2 JP 5214178 B2 JP5214178 B2 JP 5214178B2 JP 2007154982 A JP2007154982 A JP 2007154982A JP 2007154982 A JP2007154982 A JP 2007154982A JP 5214178 B2 JP5214178 B2 JP 5214178B2
Authority
JP
Japan
Prior art keywords
data
record
unit
information
field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007154982A
Other languages
English (en)
Other versions
JP2008310399A (ja
Inventor
規雄 笛木
昌和 尾本
等士 鈴木
達也 塩原
慶一 檜山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Olympus Medical Systems Corp
Original Assignee
Olympus Medical Systems Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Olympus Medical Systems Corp filed Critical Olympus Medical Systems Corp
Priority to JP2007154982A priority Critical patent/JP5214178B2/ja
Publication of JP2008310399A publication Critical patent/JP2008310399A/ja
Application granted granted Critical
Publication of JP5214178B2 publication Critical patent/JP5214178B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Description

本発明は、データ記憶システムに関し、特に複数のデータベースにデータを分散保存させるデータ記憶システムに関する。
病院では、日々、様々な種類の情報がデータベース(DB)に記録されている。医師が患者を検査すると、その検査に使用した器材や、医師が作成したレポート、また検査時に取得した画像など、検査に関する情報が互いに紐付けられて病院内の医用DBに格納される。従来、複数の医用サーバを備え、端末装置から送信された問い合わせを受信した医用サーバが、問い合わせを他の医用サーバに転送し、これに対する医用サーバの応答を端末装置に返信する医用サーバシステムが提案されている(たとえば、特許文献1)。
特開2001−290880号公報
現在、患者や検査に関する情報を病院外のDBに保存することには法律上の制約があるため、患者や検査に関する情報は、病院内のDBに保存する必要がある。このとき、情報が一括して外部に流出するリスクを回避するために、患者や検査に関する情報は、それぞれ異なるDBに分散して保存されることが望ましい。複数のDBに情報を分散保存することで、アクセスが集中する状況を回避することも可能となる。
時代の変化などにより、患者や検査に関する一部または全部の情報を院外にも保存できるようになると、院外のデータ記憶システムと、院内のデータ記憶システムとの連携をとることが困難となることが予想される。病院側のサーバは、院外のデータ記憶システムに対してデータを書き込み、または読み出すために、院外のDBの構造を把握しておけばよいが、これらは病院側サーバの管理下にないため、複数の院外DBの構造を完全に把握することは容易でない。なお院内、院外を問わず、保存するべきデータ種類が多い場合に、分散するDBシステムに対して、データを所望のDBに書き込み、または所望のDBから読み出すことは必ずしも容易でない。
本発明はこうした状況に鑑みてなされたものであり、その目的は、効率よくデータを分散保存することのできるデータ記憶システムを提供することにある。
上記課題を解決するために、本発明のある態様は、複数のデータベースと、データベースを管理する管理システムとを備えて、複数のデータベースにデータを分散保存させるデータ記憶システムである。このデータ記憶システムにおいて、前記複数のデータベースは同じ複数のフィールドを含むテーブルを有して構成され、各テーブルは、データ値の書込または読出が可能なフィールドと、当該テーブル以外の他のテーブルへのリンク情報が格納されるフィールドを有する。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、データを分散保存することのできるデータ記憶システムを提供できる。
本発明の実施例を詳細に説明する前に、まず概要を説明する。本発明の実施例におけるデータ記憶システムは、複数のデータベースと、データベースを管理する管理システムとを備えて、複数のデータベースにデータを分散保存させる機能をもつ。このデータ記憶システムでは、複数のデータベースは同じ複数のフィールドを含むテーブルを有する。各テーブルには、データ値の書込または読出が可能なフィールドと、当該テーブル以外の他のテーブルへのリンク情報が格納されるフィールドとが設けられる。このように本実施例のデータ記憶システムでは、各データベースのテーブルにおいて、データ値を格納するフィールドと、データ値を記憶可能な他のテーブルへのリンク情報を格納するフィールドの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が院内に配置されてもよい。また、実施例では医用情報の記憶システムについて説明したが、他の種類の情報の記憶システムについても本発明を適用できることは言うまでもない。
本発明の実施例にかかるデータ記憶システムの構成を示す図である。 各DBのテーブルの例を示す図である。 医用サーバの構成を示す図である。 DBMSの構成を示す図である。 各DBのテーブルの例を示す図である。 DBMSの構成の変形例を示す図である。 本発明の実施例にかかるデータ記憶システムの構成の変形例を示す図である。 本発明の実施例にかかるデータ記憶システムの構成の変形例を示す図である。 本発明の実施例にかかるデータ記憶システムの構成の変形例を示す図である。 本発明の実施例にかかるデータ記憶システムの構成の変形例を示す図である。 DB作成ツールの構成を示す図である。 DB作成ツールによりディスプレイに表示されるDB作成画面を示す図である。
符号の説明
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・・・リスト保持部。

Claims (4)

  1. 複数のデータベースと、データベースを管理する管理システムとを備えて、複数のデータベースにデータを分散保存させるデータ記憶システムであって、
    前記複数のデータベースは同じ複数のフィールドを含むテーブルを有して構成され、各テーブルは、データ値の書込または読出が可能なフィールドと、当該テーブル以外の他のテーブルへのリンク情報が格納されるフィールドを有し、
    前記管理システムは、アプリケーションプログラムにより特定されるデータベースのフィールドにアクセスがあると、そのフィールドに格納されているデータ値またはリンク情報をアプリケーションプログラムに送信し、
    アプリケーションプログラムは、受信したリンク情報により特定されるデータベースのフィールドに再アクセスすることを特徴とするデータ記憶システム。
  2. 前記管理システムは、アプリケーションプログラムからの指示により、全てのデータベースのテーブルに、新たなレコードを作成することを特徴とする請求項1に記載のデータ記憶システム。
  3. 前記管理システムは、データ値の書込または読出が可能なフィールドをテーブルごとに特定するマッピング情報を利用して、レコードを作成することを特徴とする請求項2に記載のデータ記憶システム。
  4. 前記管理システムは、マッピング情報を利用して、各テーブルにおいて、データ値の書込が可能なフィールドにはnullデータを保存し、データ値の書込が不能なフィールドには、参照するべき他のテーブルのリンク情報を格納することを特徴とする請求項3に記載のデータ記憶システム。
JP2007154982A 2007-06-12 2007-06-12 データ記憶システム Expired - Fee Related JP5214178B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007154982A JP5214178B2 (ja) 2007-06-12 2007-06-12 データ記憶システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007154982A JP5214178B2 (ja) 2007-06-12 2007-06-12 データ記憶システム

Publications (2)

Publication Number Publication Date
JP2008310399A JP2008310399A (ja) 2008-12-25
JP5214178B2 true JP5214178B2 (ja) 2013-06-19

Family

ID=40237972

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007154982A Expired - Fee Related JP5214178B2 (ja) 2007-06-12 2007-06-12 データ記憶システム

Country Status (1)

Country Link
JP (1) JP5214178B2 (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004246642A (ja) * 2003-02-14 2004-09-02 Nissho Electronics Kk 電子文書ファイル保管及び検索方法及びシステム
JP4539952B2 (ja) * 2003-11-05 2010-09-08 日本電信電話株式会社 情報分散保管システム、その装置、プログラム及び記録媒体
JP3836492B1 (ja) * 2005-07-22 2006-10-25 株式会社ソフィア データ管理装置、データ管理方法、データ処理方法、データ保存方法及びプログラム
JP2007219634A (ja) * 2006-02-14 2007-08-30 Dat Japan Kk 分散型データベースシステム及びデータベースの分散管理方法

Also Published As

Publication number Publication date
JP2008310399A (ja) 2008-12-25

Similar Documents

Publication Publication Date Title
US9152631B2 (en) Document management system, method for controlling the same, and storage medium
US7386575B2 (en) System and method for synchronizing related data elements in disparate storage systems
JP2004246903A (ja) ドキュメントの要素をデータベース内の対応するフィールド、クエリおよび/または手続きにリンクする方法
US8812462B2 (en) User-driven menu generation system with dynamic generation of target files with placeholders for persistent change or temporary security change over cloud computing virtual storage from template files
EP1758042A1 (en) Document distribution system and method
JP2004528636A (ja) 自動データ更新
US20120215882A1 (en) Content management method, management storage device, and non-transistory content management computer program product
AU2006304109A1 (en) Managing relationships between resources stored within a repository
WO2012120658A1 (ja) ウェブ操作記録・再現方法および装置
JP4713257B2 (ja) データ記憶装置及びバージョン管理プログラム
US20070299688A1 (en) Communication and Interface Support System
JP2007310481A (ja) 文書管理方法、そのプログラム及び記録媒体、並びに文書共有サーバ及び文書共有システム
JPH09218815A (ja) ネットワーク通信機能を持つ情報機器及び同機器における情報アクセス方法
JP5214178B2 (ja) データ記憶システム
US20050216827A1 (en) Document management program and document management apparatus
JP2004199446A (ja) 共有ドキュメント管理システム、メンバ端末装置、メンバ端末用ドキュメント共有処理プログラム、および共有ドキュメント管理プログラム
JP2020074216A (ja) 標準化データベースアクセスシステムおよび方法
JP4634729B2 (ja) Dicomメディア情報管理システム及びdicomメディア情報を管理する管理サーバ
CN107491466A (zh) 客户端设备、信息处理系统、以及信息处理方法
JP2020170549A (ja) 電子カルテシステム及び電子カルテプログラム
JP5397591B2 (ja) 文書管理プログラムおよび文書管理装置
US20120136963A1 (en) Content transmission method, connection-target storage, and content transmission program
JPH11212985A (ja) 情報ライブラリ装置
JP6903107B2 (ja) 症例蓄積システム
JP2002189622A (ja) 更新データの配信システム、配信方法、及び記録媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100531

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120608

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121023

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130205

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130227

R151 Written notification of patent or utility model registration

Ref document number: 5214178

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160308

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees