JP6410439B2 - データ抽出装置 - Google Patents

Description

本発明は、特に、データベースに登録されている資料を抽出するために用いて好適なデータ抽出装置に関する。

近年、医療分野においても診断所見や治療計画の決定、あるいは看護及び介護の引継ぎに関し、会議（医療カンファレンス）による合議を行う機会が増加している。この背景には、現在の医療が、医師個人による単独医療から複数人によるチーム医療へと推移していることが挙げられる。一方で、医療現場では、診察や治療などに依然として多くの時間が必要であり、医療カンファレンスの準備や実施に割り当てる時間がなかなか確保できていないのが実状である。

一方、医療画像管理システム（Ｐｉｃｔｕｒｅ Ａｒｃｈｉｖｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ 以下、ＰＡＣＳ）と呼ばれるシステムが、通常病院内にデータベースを持ち、構築されている。このＰＡＣＳとの通信方式として、多くの病院においてＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ ＣＯｍｍｕｎｉｃａｔｉｏｎ ｉｎ Ｍｅｄｉｃｉｎｅ）形式が普及している。

また、検査報告書（以下、レポート）管理システムでは、読影医や病理医が作成したレポートが管理されている。また、近年では、医療現場においても、ＰＡＣＳで管理されるＤＩＣＯＭ形式の画像（ＤＩＣＯＭ画像）以外の画像（非ＤＩＣＯＭ画像）が多く利用されるようになっている。典型的には、デジタルカメラで撮影された外傷や手術前後の患部の写真である。これらの画像は、ＰＡＣＳとは別に画像管理システムで管理されることが多い。

前述した医療カンファレンスにおいては、これらの電子カルテ、ＰＡＣＳ、レポート管理システム、あるいは、画像管理システムそれぞれに保持される情報をそれぞれのアプリケーションで参照して議論する形態が取られていた。このような形態ではカンファレンス時に複数のアプリケーションを起動する必要があり煩雑であるため、近年、複数の資料を統合して閲覧するための医療カンファレンスに対する会議支援装置が登場している。

医療カンファレンスにおいてカンファレンスの進行を効率良く行うため、会議支援装置は、使用する資料をカンファレンスごとに開催前にシステムに取り込んでおき、カンファレンス時にはシステムに取り込まれた資料を選択して表示できるようにする。事前にシステムに資料を取り込んでおくためには、データベースに抽出クエリを発行して資料が抽出される。

データベースに対するクエリを作成するには、データベースに関する知識が必要となるため、ユーザが決定することは難しく、自動的にクエリを作成する方法が提案されている。例えば、予め作成された機能項目に基づいて各機能に対するデータベースから資料を抽出するための抽出クエリを作成する方法が提案されている（特許文献１参照）。また、データベースの構造に対して業務名カラムを追加しておくことにより、データベースの物理構成やクエリ言語の文法を理解していなくても、業務名を選択することによって抽出クエリを作成する方法も提案されている（特許文献２参照）。

特開２００６−２３５７７０号公報 特開２００１−１４２８８５号公報

一般的に、会議支援装置のユーザである医師は、データベースに関する知識が少ないため、医療カンファレンスでは医師の要望に基づいて保守人員の操作により抽出条件が設定される。ところが、作業効率を良くするためには、医師が直接操作することによって資料の抽出条件を設定できるようにすることが望ましい。

これに対して、特許文献１に記載の技術では、予め必要となる機能項目を作成するために、データベースの知識を備えた保守人員が必要であり、医師の操作により抽出条件を簡易に変更することはできない。また、特許文献２に記載の技術では、予めデータベースに業務名を入力しておく必要がある。そのため、データベースに関する知識が少ない医師により新たな要望が発生した場合には、医師の操作によって簡易に業務名の追加を行うことはできず、抽出条件を簡易に変更することは難しい。

以上のように、保守人員の操作により抽出条件が設定され、医師は、カンファレンス開催前に自分が説明に必要とする資料が正しく抽出されているか否かを確認する必要がある。そして、不足している資料が存在する場合はシステムに手動で追加しており、医師の業務負担となっている。また、医師が資料の抽出条件を変更したいと考えた場合であっても、医師の操作により抽出条件を変更することができず、保守人員に依頼して対応を待つ必要があり、迅速な変更対応ができない。

本発明は前述の問題点に鑑み、データベースから資料を抽出する際の抽出条件を簡単に生成できるようにすることを目的としている。

本発明に係るデータ抽出装置は、資料参照のために資料データベースから資料データを抽出するデータ抽出装置であって、抽出条件式を用いて前記資料データベースから参照する資料データを抽出する資料データ抽出手段と、参照すべき追加資料データをユーザが手動で追加登録する資料データ手動追加手段と、前記抽出条件式を作成する抽出条件作成手段と、を備え、前記抽出条件作成手段は、前記資料データ手動追加手段によって追加された前記追加資料データのメタ情報を利用して抽出条件式を生成できるか否かを判定し、生成できると判定される場合には、前記追加された追加資料データが抽出結果に含まれるように前記抽出条件式を作成する、ことを特徴とする。

本発明によれば、データベースから資料を抽出する際の抽出条件を簡単に生成することができ、作業効率を向上させることができる。

実施形態に係る会議支援システムの概略構成例を示すブロック図である。 資料抽出用のクエリを作成する全体的な処理手順の一例を示すフローチャートである。 クエリを作成する具体的な処理手順の一例を示すフローチャートである。 ＳＱＬのクエリを生成する手順を説明するための図である。 クエリを合成する手順を説明するための図である。 登録された資料にクエリの生成に利用できる情報が存在しない場合に、更新日付の条件を変更してクエリを生成する手順を説明するための図である。 登録された資料にクエリの生成に利用できる情報が存在しない場合に、資料種の条件を変更してクエリを生成する手順を説明するための図である。 構文木を用いてサブクエリに分解する処理を説明するための図である。 第２の実施形態において、抽出範囲を狭める処理手順の一例を示すフローチャートである。 第２の実施形態において、数値範囲を変更する詳細な処理手順の一例を示すフローチャートである。 第３の実施形態において、ＭｏｎｇｏＤＢを用いてクエリを生成する手順を説明するための図である。 第４の実施形態において、追加される可能性の高い資料種から順に資料種の条件を変更してクエリを生成する手順を説明するための図である。

以下、本発明の実施形態について図面およびフローチャートを用いて説明する。後述する各実施形態では、情報処理としてデータを抽出する一連の処理を説明するために、医療カンファレンスの際に医師が本装置を操作することを想定して説明するが、他の場合であっても同様に利用可能である。例えば、操作者については看護師や介護士等の他の人物が操作しても同様に利用可能である。また、利用する場面についても会議に限定されず、データベースからデータを抽出するためのクエリを作成することを目的とする場面において利用可能である。

（第１の実施形態）
以下、本発明の第１の実施形態について説明する。
図１は、本実施形態に係る会議支援システム１００の概略構成例を示すブロック図である。
図１において、会議支援システム１００は、データ抽出装置１０８と院内データベース１１０とがネットワーク１０９に接続されて構成されている。データ抽出装置１０８は、ＣＰＵ１０１、入力部１０２、表示部１０３、ＢＵＳ１０４、ＲＯＭ１０５、ＲＡＭ１０６、及びＤＩＳＫ１０７を有する。

ＣＰＵ１０１は中央演算処理装置であり、後述する各部を統括的に制御する。入力部１０２はボタン、キーボード、タッチパネル等であり、操作者の操作に応じて各種の指示を行う。表示部１０３は液晶ディスプレイ等であり、ＣＰＵ１０１の表示制御により、患者診療録等を表示する。ＢＵＳ１０４は、各種信号やデータの転送経路となる通信バスであり、例えば、ＣＰＵ１０１から制御対象である各デバイスへの指示を行う信号や、各デバイス間のデータを所定の処理部に転送する。

ＲＯＭ１０５は読み出し専用の不揮発性メモリである。ＲＯＭ１０５はＣＰＵ１０１のブートプログラム、システムの制御プログラム、各種処理で参照される各種初期データ等を記憶する。ＲＡＭ１０６は読み書き可能なランダムアクセスメモリであり、各デバイスからの各種データの一時記憶や、ＣＰＵ１０１の作業領域等に用いられる。ＲＡＭ１０６には処理に必要なデータを記憶する各種ワーク領域、処理中に必要なスタック、処理中に値変更が行われる各種データを格納する。後述する各種会議データや資料データ（以下、単に資料と称す）の使用頻度テーブル、資料抽出条件もＲＡＭ１０６に格納されている。

ＤＩＳＫ１０７は大容量記憶装置であり、大量のデータを変更可能に記憶する。ＤＩＳＫ１０７は例えばハードディスクやＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等で構成する。なお、ＣＰＵ１０１により実行する制御プログラムや各種初期データは、必要に応じてＲＡＭ１０６上の一時記憶にロードして、実行もしくは参照する。このようにすることによりプログラムや初期データを固定化せず途中で修正可能にすることができ、柔軟なシステムを実現することができる。

また、ＲＡＭ１０６に格納されている各種会議データや資料の使用頻度テーブルや資料抽出条件は、端末の電源を切るなどの終了処理を行った際には、その終了処理の中でＤＩＳＫ１０７上の抽出資料保存部に保存される。そして、次回の起動時にＤＩＳＫ１０７上の抽出資料保存部に保存された使用頻度テーブル等の各種データをＲＡＭ１０６に読み出すことにより、終了したときの状態にて再開することが可能である。

以上のようにデータ抽出装置１０８は、ＣＰＵ１０１からＤＩＳＫ１０７までを含めた、データ抽出を実際に行う装置全体を指すものとする。ネットワーク１０９はデータ抽出装置１０８と院内データベース１１０とを結ぶＬＡＮである。院内データベース１１０は、患者情報や患者カルテ、患者検査画像等を保管するデータベースである。本実施形態では、院内データベース１１０はリレーショナルデータベースで作成されており、院内データベース１１０へのクエリとしてＳＱＬを使用してデータを抽出するものとする。

図２は、データ抽出装置１０８を操作することによって資料抽出用のクエリを作成する際の、データ抽出装置１０８の動作例を示すフローチャートである。なお、図２に示す各処理は、ＣＰＵ１０１の制御によって行われる。
まず、ステップＳ２０１において、データ抽出装置１０８の操作者により入力部１０２が操作され、抽出する対象となるデータとして会議で使用するための資料が院内データベース１１０から選択されてＤＩＳＫ１０７上の抽出資料保存部に保存される。ここで取得する資料は、会議で使用する資料全てを会議支援システム１００に登録する必要はなく、例えば一人の患者のデータを、会議で使用するＸ線検査画像、電子カルテといった資料の種類ごとに追加すればよい。以下では、このような追加する資料の種類のことを資料種と表現し説明する。

次に、ステップＳ２０２において、ステップＳ２０１で取得された資料をもとに、データ抽出装置１０８は、資料を抽出するためのクエリを生成する。クエリを生成する詳細な手順については後述する。

次に、ステップＳ２０３において、ステップＳ２０２で作成した資料を抽出するためのクエリを表示部１０３に表示し、操作者に通知する。表示方法としては、ＳＱＬのクエリをそのまま表示したり、自然言語に変換して表示したりするなどの方法が挙げられる。また、クエリを表示する際に、そのクエリにて抽出される資料を提示し、操作者の所望の資料が抽出されていることを操作者自身に確認させることも可能である。会議の日に、操作者によりこのクエリが選択されると、データ抽出装置１０８により院内データベース１１０から所望の資料を抽出する。

また、更新されたクエリが所望のものではなかった場合に過去のクエリを使用するように設定を戻すことも可能である。具体的には、データ抽出装置１０８は、ＲＡＭ１０６に過去の抽出条件を記憶する抽出条件記憶領域を備えており、過去のクエリに戻す場合は、記憶されている抽出条件を表示して操作者に提示する。そして、操作者が選択した抽出条件を現在の抽出条件として使用するように変更することによって、データ抽出装置１０８が抽出条件を設定する。

図３は、図２のステップＳ２０２におけるクエリを作成する処理手順の一例を示すフローチャートである。
まず、ステップＳ３０１において、ステップＳ２０１において操作者の操作によって登録された各資料に対して、以下に説明するステップＳ３０１〜Ｓ３１０の処理を行う。

次のステップＳ３０２においては、図２のステップＳ２０１で登録された資料のデータに既知のヘッダ情報（メタ情報）が存在するか否かを判定する。例えばＤＩＣＯＭ形式に対応したモダリティで撮影されたＸ線検査画像には、画像のメタデータや撮影時の情報を保持するＤＩＣＯＭ形式のヘッダが付属されている。また、患者の外傷などを撮影する場合にデジタルカメラなどの機器が用いられることもある。デジタルカメラで撮影した画像にはＥＸＩＦ（Ｅｘｃｈａｎｇｅａｂｌｅ ｉｍａｇｅ ｆｉｌｅ ｆｏｒｍａｔ）形式のヘッダが付属されている場合がある。この処理では、このようなヘッダ情報が資料のデータに付属されているか否かを判定する。この判定の結果、ヘッダ情報が存在する場合は、ステップＳ３０３に遷移する。

ステップＳ３０３においては、資料のデータのヘッダ情報を解析し、メタ情報であるヘッダ内の各種データを取得する。例えば、前述のＤＩＣＯＭ形式のヘッダの場合はヘッダ情報の内容を解析し、「検査日付」、「検査装置」、「検査部位」などの情報を取得する。また、ＥＸＩＦ形式のヘッダの場合は、「撮影日時」などの情報を、クエリを生成するために利用可能な情報として取得する。

次に、ステップＳ３０４においては、ステップＳ３０３で取得したヘッダ情報を利用して、資料を抽出するためのクエリを生成することができるか否かを判定する。ヘッダの種類によっては、画像サイズ等の情報しか持たないデータ形式もあるため、現在対象としている資料がクエリとして不十分な場合もある。このような場合はステップＳ３１０に遷移する。一方、ＤＩＣＯＭ形式のヘッダのように「検査日付」、「検査部位」などクエリとしてデータを絞り込むために使用可能な情報がヘッダ情報に含まれている場合は、ステップＳ３０５に遷移する。

ステップＳ３０５においては、ステップＳ３０３で解析したヘッダ情報を利用して、クエリで抽出する資料種を決定する。例えば、ステップＳ３０３でヘッダを解析した結果、会議支援システム１００に登録された資料がＤＩＣＯＭ形式のデータであり、ヘッダ情報内の「検査装置」を表す部分が「デジタルＸ線」であるものとする。この場合、データ抽出装置１０８は、対象としている資料が院内データベース１１０において資料種が「Ｘ線画像」として保存されている資料であると判定する。判定方法としては、ヘッダ情報内の「検査装置」と資料種とを結び付けたテーブルを予め用意しておき、そのテーブルを検索することによって判定する。判定の結果、クエリで抽出する資料種を「Ｘ線画像」と決定する。

次のステップＳ３０６においては、データ抽出装置１０８は、ステップＳ３０３で解析したヘッダ情報を利用して、クエリが抽出する資料の範囲を決定する。ここで決定する範囲とは、抽出する資料を特定の資料種の中で絞り込むための条件であり、以下、ここで決定する範囲を抽出範囲と称す。例えば、ステップＳ３０５で抽出する資料種として「Ｘ線画像」と決定した場合、「検査日付」や「検査部位」を、ある特定の日付期間や特定の検査部位に一致する範囲を抽出範囲とする。

例えば、ヘッダ情報の中の検査日付が、ステップＳ３０６の処理が実行されている日付から５日前である場合には、現在の日付から５日前までに検査が行われた資料を抽出するように抽出範囲を決定する。また、ヘッダ情報において検査部位が「胸部」となっていた場合は、院内データベース１１０上で検査部位が胸部として保存されている資料を抽出するように抽出範囲を決定する。

続いてステップＳ３０７においては、ステップＳ３０５で決定された資料種とステップＳ３０６で決定された抽出範囲とを組み合わせて、院内データベース１１０に対するクエリを生成（更新）する。以下、図４を参照しながら、生成されるクエリの具体例について説明する。

図４において、テーブル４０１は、院内データベース１１０内で管理されている画像のテーブルの一例である。まず、処理４０２に示すように、ステップＳ２０１において、医師により２０１３年３月２６日に画像ＩＤ００１が会議支援システム１００に登録されたものとする。この画像はＤＩＣＯＭ形式のデータであり、「検査装置」、「検査日付」、「検査部位」をヘッダとして持つものとする。

次に、ヘッダ情報の有無を判定し、処理４０３に示すように、登録された資料はヘッダ情報の「検査装置」がＸ線画像撮影装置であることから、資料種がＸ線画像であるとステップＳ３０５で決定する。そして、次のステップＳ３０６において、ヘッダ情報の「検査日付」を利用して何日前に検査された資料が追加されたかを算出する。同様にヘッダ情報の「検査部位」を利用して、どの部位の画像を抽出すればよいかを算出する。これにより、検査日付が５日以内で検査部位が胸部である資料を抽出範囲に決定する。

続いて、処理４０４に示すように、図３のステップＳ３０７において、図４に示すようなＳＱＬ言語のクエリ４０５がデータ抽出装置１０８によって生成される。生成されたクエリ４０５を、資料を抽出するための条件として使用すると、データ抽出装置１０８は、テーブル４０１に示すデータのうち、画像ＩＤ００１と画像ＩＤ００４とを抽出する。

図３の説明に戻り、続いてステップＳ３０８においては、ステップＳ３０７で生成されたクエリを他の資料に対して生成されたクエリとまとめて１つのクエリに合成する。ここで、図５を参照しながらクエリを合成する例について説明する。

まず、合成の方法としては、ＳＱＬのＵＮＩＯＮ演算子を用いてクエリを結合する方法が挙げられる。ＵＮＩＯＮ演算子で結合されたクエリは、各クエリで抽出される資料の和集合を抽出できるため、複数のクエリをまとめることができる。例えば、処理５０１に示すように、図２のステップＳ２０１において、医師により画像ＩＤ００１及び画像ＩＤ００４のデータが会議支援システム１００に登録されたものとする。その場合、処理５０２に示すように、データ抽出装置１０８はそれぞれの画像に対して、ＳＱＬのクエリをステップＳ３０７にて生成する。これらのクエリをＵＮＩＯＮ演算子で結合すると、処理５０３に示すようなクエリ５０４となる。

一方、この方法では、使用しているデータベースシステムによっては、「ＵＮＩＯＮ」句の前後のクエリに相当する部分に対してそれぞれ検索が行われてパフォーマンスが低下する可能性がある。このようなパフォーマンスの低下を避けるため、クエリを合成する際に条件部をまとめる方法を用いてもよい。具体的には、図５に示すようなクエリ５０５をデータ抽出装置１０８が生成する。

例えば、合成前のクエリでは検査日付が５日以内の資料と３日以内の資料とを抽出するが、これら２つの条件のうち範囲が広い「検査日付が５日以内」の資料を抽出するようにクエリを生成する。このようにすることによって、資料を抽出するのにかかる時間を削減することが可能になる。なお、条件部をまとめる例として日付の場合を説明したが、検査部位が「胸部」と「腹部」との２枚のＸ線画像が追加されている場合は、条件部を「検査部位＝'胸部' ＯＲ 検査部位＝'腹部'」とまとめる。これにより、資料を抽出するための時間を削減することが可能となる。

以上の説明では、登録した資料にヘッダ情報が存在し、かつその情報をクエリの生成に利用できる場合について説明した。次に、ステップＳ２０１で登録された資料に、クエリの生成に利用できる情報が存在しない場合の処理手順を説明する。

ステップＳ３０２の判定の結果、登録資料にヘッダ情報が存在しない場合、もしくはステップＳ３０４の判定の結果、ヘッダ情報がクエリを生成するためデータとしては不十分である場合は、ステップＳ３０９に遷移する。ステップＳ３０９においては、後述するステップＳ３１０〜Ｓ３１２までの処理を繰り返し行う。ここで、この繰り返し行う回数は、予め既定の回数が定められており、その回数だけ繰り返す。以下、図６を参照しながら、以下の処理を説明する。

例えば、院内データベース１１０において、図６に示すようにＤＩＣＯＭ形式以外のデータを含むテーブル６０１が構成されているものとする。そして、処理６０２に示すように、２０１３年３月２６日に、ステップＳ２０１においてデータＩＤ００１の診療録が、会議支援システム１００に資料として登録されたものとする。

次のステップＳ３１０においては、抽出する資料種を予め定められている順序に基づいて設定するとともに、暫定的な抽出範囲を設定する。図６の処理６０３に示す例では、最初に「診療録」を資料種として設定する。そして、暫定的に抽出範囲を現在の日付から５日以内と決定する。その結果、図６のクエリ６０４が生成される。このクエリにて検出する対象は、資料そのものではなくデータのＩＤである。このようにすることにより、クエリを生成するためのデータを抽出する時間を減らすことができ、院内ネットワークの帯域の圧迫を低減できる。

次のステップＳ３１１においては、ステップＳ３１０で生成されたクエリを用いて、院内データベース１１０から資料の再検索を行う。そして、ステップＳ３１２において、再検索を行った結果、登録された資料が既定値以上含まれているか否かを判定する。図６に示す例の場合は、処理６０２で登録された資料は診療録であり、更新日が６日前であるため、再検索を行った場合に、生成されたクエリ６０４では抽出できない。このように登録された資料が既定値以上含まれなかった場合はステップＳ３１０に戻り、新たな条件でクエリを生成する。ここで、既定の繰り返し回数は、例えば３回とする。

再びステップＳ３１０に遷移すると、例えば、日付が１０日以内の資料を抽出するようにクエリ６０６を再生成する。そして、再びステップＳ３１１に遷移し、再生成したクエリ６０６を用いて再検索を行う。処理６０７に示す例の場合は、再検索の結果として登録された資料のＩＤが抽出されており、ステップＳ３１２において登録された資料を抽出できると判定できる。このような場合には、ステップＳ３０７に遷移し、ステップＳ３１０で生成した条件を用いてクエリを生成する。このように検索を繰り返すことにより検索したい資料を解析するようにしている。

図６に示した例のように、ＤＩＣＯＭ形式以外のデータを登録した場合の例について説明した。そして、生成したクエリで登録された資料を抽出できた例を説明した。一方、ステップＳ３１０〜Ｓ３１２のループにおいて既定回数繰り返して資料を抽出できなかった場合は、クエリは更新されずに既定のクエリを使用することとなる。会議対象の患者の中に登録された資料に係る患者が含まれている場合には、既定のクエリで資料を抽出する他に、次回以降にその登録された資料を抽出するときに、クエリに関係なくその資料を抽出できるようにしてもよい。こうすることにより、クエリを更新できなくても、次回以降も登録された資料の患者が会議対象者となっている限りは登録された資料が会議資料として用意される。そのため、医師は次回以降に同じ資料を追加する作業を不要にすることができる。

以上のように本実施形態によれば、医師によって登録された資料に基づいて資料を抽出するクエリを生成することができ、ＳＱＬについての知識が乏しい医師であっても医師の所望に近い資料を抽出することができる。そのため、保守人員の操作によってクエリを更新するまでの待ちの時間が不要になり、クエリの更新を迅速に行うことが可能となる。また、次回以降にその資料を抽出する際には、医師の操作により登録された資料と同様の資料種が抽出されるため、不足した資料を別途追加する手間が減り、医師の業務効率を向上させることができる。

なお、図６に示した例では、データ抽出装置１０８が、クエリを生成する際にステップＳ３１０において更新日付の条件を変更してクエリを更新した。これに対して、ステップＳ３１０において資料種の条件を変更してクエリを更新してもよい。以下、図７を参照しながら資料種の条件を変更してクエリを更新する場合について説明する。

まず、院内データベース１１０において、図７に示すテーブル７０１が構成されているものとする。そして、資料を抽出するために使用されるクエリ７０２が以前に生成されているものとする。この時、処理７０３に示すように、２０１３年３月２６日に、ステップＳ２０１において医師の操作によりデータＩＤ００２の超音波検査画像が資料として追加されたものとする。ここで、超音波検査画像のデータにはヘッダ情報が存在しないため、データ抽出装置１０８はステップＳ３１０により、クエリの資料種と抽出範囲とを更新する。図７に示す例では、処理７０４に示すように、既存のクエリにおける資料種を紹介状へ更新する。なお、データ抽出装置１０８において既定の資料種の変更順序が予め定められており、この変更順序により資料種が「紹介状」へ変更される。この順序は操作者の操作によって変更することが可能である。

ステップＳ３１０によりクエリが更新される。図７のクエリ７０５に示すように、クエリ７０２にて「診療録」となっていた部分が「紹介状」へ更新される。そして、処理７０６に示すように、ステップＳ３１１において、更新されたクエリを用いて再検索を行う。次いでステップＳ３１２において、再検索を行った結果、登録された資料を抽出できないと判定し、ステップＳ３１０に戻り、次のループに入る。次のループでは、ステップＳ３１０において、クエリの資料種が「超音波検査画像」へ更新される。この結果、図７に示すクエリ７０７が生成される。

そして、処理７０８に示すように、クエリ７０７を使用してステップＳ３１１にて再検索を行う。その結果、登録された資料を抽出できると判定し、ステップＳ３０７に遷移する。そして前述した手順によりクエリを生成する。

以上のように、抽出する資料種を変更して処理をループすることによっても所望の資料を抽出するクエリを生成することが可能となる。そのため、医師の業務効率を向上させることができる。また、抽出範囲を変更するか、資料種を変更するか、また、どのような順序でこれらを設定するかは、予め操作者の操作などによって変更することができる。

（第２の実施形態）
第１の実施形態においては、クエリにおいてＳＱＬの「ＷＨＥＲＥ」句が小規模で単純な場合を例に説明した。本実施形態では、既存のクエリにおいて「ＷＨＥＲＥ」句が予め定められた数よりも多くの条件が「ＡＮＤ」や「ＯＲ」などの論理演算子で結合されて構成されている場合の処理方法について説明する。

図８は、論理演算子で結合されている「ＷＨＥＲＥ」句を分解して処理する過程を説明するための図である。まず、図８に示すような「ＷＨＥＲＥ」句８０１がクエリに構成されているものとする。そこで、「ＡＮＤ」、「ＯＲ」、「ＮＯＴ」などの論理演算子が既定数以上使用されている場合は構文木に分解し、分解された構成要素ごとにクエリの更新処理を行う。この論理演算子の既定数は予め定められているものとし、図８に示す例では、既定数よりも多い論理演算子が使用されているものとする。

図８に示す「ＷＨＥＲＥ」句８０１の例では、データ抽出装置１０８はこの句を構文木８０２に分解する。構文木は、会議支援システムで内部的に処理される句構造を模式的に表しており、内部的には木構造で処理する必要は無く、リスト構造や配列等を使用して実装してもよい。各項がどの論理演算子と結合しているかが判定可能なデータ構造であれば、どのような構造であっても適用可能である。以下の説明では、構文木として分解するものとする。

構文木を用いてクエリを複数のサブクエリに分解する際には、公知の構文木解析技術を用いる。クエリが構文木を用いて複数のサブクエリに分解されると、各サブクエリに対して、第１の実施形態と同様の方法によりクエリを更新する。図８に示す例では、構文木８０２に示すサブクエリＱ１、Ｑ２、Ｑ３、Ｑ４に対してそれぞれ更新を行う。なお、サブクエリは、既定数以下の論理演算子で結合されているものを指す。

ここで、図８において、サブクエリＱ４の前に否定演算子である「ＮＯＴ」が付されている場合、否定演算子で否定されるため、抽出条件を狭める方向に更新を行うことになる。サブクエリＱ４に対して抽出条件を狭める方向に更新することにより、否定演算子と結合した際に抽出条件全体では、抽出範囲は広がっていることとなる。

各サブクエリに対して更新処理を行った後、構文木に従って「ＷＨＥＲＥ」句を再びまとめて１つのクエリとする再構築を行い、以降では再構築後のクエリを用いるようにする。一方、このように各サブクエリに対して更新処理を施し、再構築を行うだけでは抽出条件を広げすぎてしまう可能性がある。そのため、再構築後に抽出範囲を狭める処理を行うようにしてもよい。以下、抽出範囲を狭める方法について説明する。

図９は、抽出範囲を狭める処理手順の一例を示すフローチャートである。なお、図９に示す各処理は、ＣＰＵ１０１の制御によって行われる。
まず、ステップＳ９０１において、抽出条件を分解する。この処理は、例えば、クエリに示す「ＷＨＥＲＥ」句８０１を構文木８０２によってサブクエリに分割する処理である。

次に、ステップＳ９０２において、分解された各サブクエリに対してステップＳ９０３〜Ｓ９０４の処理を繰り返す。まず、ステップＳ９０３において、現在対象としているサブクエリが数値範囲を規定する条件を含むかどうかを判定する。数値範囲を規定する条件か否かについては、サブクエリが比較演算子で結合されており、なおかつ演算子の片方の項が数値であるか否かを判定すればよい。この判定の結果、サブクエリが数値範囲を規定する条件を含まない場合は、条件を狭める更新は行わず、次のサブクエリに対して処理を行う。一方、サブクエリが数値範囲を規定する条件を含む場合は、ステップＳ９０４に遷移する。

ステップＳ９０４においては、データ抽出装置１０８は、使用頻度が低い資料を抽出対象から外すように数値範囲を変更する。この処理の詳細については後述する。そして、ステップＳ９０５においては、変更されたサブクエリを他のサブクエリと再結合し、ＳＱＬ言語のクエリを再構築する。

図１０は、図９のステップＳ９０４における数値範囲を変更する詳細な処理手順の一例を示すフローチャートである。
まず、ステップＳ１００１において、現在のクエリにおいて抽出されているすべての資料に対して、ステップＳ１００２〜Ｓ１００３の処理を繰り返す。そして、ステップＳ１００２において、ある資料のデータにヘッダ情報が存在しているか否かを判定する。この判定の結果、ヘッダ情報が存在する場合はステップＳ１００３に遷移し、ヘッダ情報を解析する。このヘッダ情報の解析では、図３のステップＳ３０３と同様の処理を行う。なお、ステップＳ１００２の判定の結果、ヘッダ情報が存在しない場合は、次の資料のデータに対して処理を行う。以上のように全資料に対して処理が完了したら、ステップＳ１００４に遷移する。

ステップＳ１００４においては、ステップＳ１００３で解析したヘッダ情報からサブクエリが更新可能か否かを判定する。この処理では、サブクエリに対して図３のステップＳ３０４と同様の方法により判定を行う。この判定の結果、サブクエリが更新可能である場合は、ステップＳ１００５に遷移する。

ステップＳ１００５においては、会議における資料の使用頻度の情報を用いて、使用頻度が低い資料を抽出しないように数値条件を更新する。具体的には、会議において各資料の使用頻度をデータ抽出装置１０８が保存しておき、使用頻度が既定値以上の資料を選定する。そして選定された資料に対する解析済みであるヘッダ情報を利用して数値条件を更新する。数値条件の更新方法としては、図３のステップＳ３０６と同様の方法を用いる。そして、ステップＳ１００６において、ステップＳ１００５で更新された数値条件をサブクエリに設定し、数値変更処理を完了する。

一方、ステップＳ１００４の判定の結果、ヘッダ情報を用いてサブクエリを更新できない場合は、ステップＳ１００７に進み、後述するステップＳ１００８〜Ｓ１０１０の処理を繰り返す。ステップＳ１００８以降の処理を、最大で操作者の操作によって設定された既定の回数だけ行う。

まず、ステップＳ１００８においては、現在処理対象としている数値範囲を狭める方向へサブクエリを暫定的に更新する。どの程度範囲を狭めるかについては、操作者の操作により設定可能な値によって定められる。例えば、数値を１０減らす、または１割減らすといった処理内容が予め定められている。そして、ステップＳ１００９において、狭められた数値範囲を用いて、サブクエリを再構築し、資料ＩＤを対象として再検索を行う。具体的に行う処理内容はステップＳ３１１と同様である。

再検索後、ステップＳ１０１０に遷移し、会議での使用頻度が閾値以上の資料が抽出対象として残っているか否かを判定する。この判定の結果、使用頻度が閾値以上の資料が残っている場合は、まだ数値範囲を狭めることができる可能性があるため、次のループに入る。

一方、ステップＳ１０１０の判定の結果、使用頻度が閾値以上の資料が残っていない場合は、頻繁に使用されている資料が抽出対象から外れていることになる。そこで、ステップＳ１０１１に遷移し、１ループ前に使用していた数値範囲の条件を更新後のサブクエリとして設定する。なお、初回のループでステップＳ１０１１に進んだ場合は、ステップＳ１００８で狭めた数値範囲を破棄し、数値範囲の変更処理を行う前のサブクエリを更新後のサブクエリとして設定する。

以上のように本実施形態によれば、クエリが複数の論理演算子で結合されている場合であっても、クエリを更新することができ、本システムの適用可能範囲を広げることができる。また、抽出範囲を狭くする際には、使用頻度の高い資料を残しながら抽出範囲を狭めることが可能となる。そのため、データを抽出するのにかかる時間を減らすことができ、病院内におけるネットワークの帯域の圧迫を低減できる。また、会議での使用頻度が低い資料を抽出しないようになるため、会議時に医師が資料を探す際の負担を低減することができ、医師の業務効率を向上させることができる。

（第３の実施形態）
第１及び第２の実施形態では、院内データベース１１０からのデータを抽出するためのクエリの言語としてＳＱＬを用いた場合について説明した。ここで、ＳＱＬはリレーショナルデータベース管理システムに対する、データを抽出するための言語であり、他のデータベース管理システムにおいては、他のデータを抽出するための言語がクエリに用いられることもある。本実施形態では、リレーショナルデータベースではない形式のデータベースとしてＭｏｎｇｏＤＢを例とし、第１及び第２の実施形態と同様にクエリを生成（更新）する処理について説明する。

図１１は、図６に示した処理の流れと同等の処理を、ＭｏｎｇｏＤＢで行った場合を説明するための図である。なお、図６に示したテーブル６０１には診療録以外の種類のデータが存在していたが、図１１に示すテーブル１１０１は、すべて診療録のデータであるものとする。

まず、処理１１０２に示すように、２０１３年３月２６日にステップＳ２０１において、医師の操作によりデータＩＤ００１の診療録が資料として追加されたものとする。そして、処理１１０３に示すように、ステップＳ３１０において、資料種を診療録に決定し、抽出範囲を日付が５日以内と暫定的に決定する。そして、ＭｏｎｇｏＤＢのクエリを生成する。データの資料種が診療録と定まると、診療録がどのテーブルに存在するかを判定する。図１１に示す例の場合は、「Ｃｏｌｌｅｃｔｉｏｎ１」というテーブルが診療録のデータが保存されたテーブルであると判定し、ＭｏｎｇｏＤＢのクエリ１１０４を生成する。

次に、処理１１０５に示すように、ステップＳ３１１において、生成されたＭｏｎｇｏＤＢのクエリを用いて再検索を行う。そして、ステップＳ３１２の判定の結果、登録された資料を抽出できなかったため、ステップＳ３１０に戻り、抽出範囲において日付を１０日以内に変更したＭｏｎｇｏＤＢのクエリ１１０６を生成する。そして、処理１１０７に示すように、ステップＳ３１１にて再検索を行い、ステップＳ３１２の判定の結果、で登録された資料を抽出することができるため、ステップＳ３０７に遷移し、クエリを更新する。

以上のように、院内データベース１１０からデータを抽出するためのクエリに用いる言語がＳＱＬでない場合であっても、抽出する資料種及び抽出範囲にクエリのどの部分が対応するかが分かれば、第１及び第２の実施形態に示した処理を行うことができる。本実施形態によれば、データベースからデータを抽出するためのクエリに用いる言語がＳＱＬではない場合であっても、クエリを作成または更新することができる。そのため、対応可能なデータベース管理システムの種類を増やすことが可能となり、より柔軟なシステムを構築することが可能となる。

（第４の実施形態）
第１の実施形態において、抽出する資料の資料種が異なる場合に、会議支援システムが既定の順序で資料種を変更して再検索を行った例についても説明した。本実施形態では、会議対象の患者一覧にある各患者のカルテの記載情報に基づいて、追加される可能性の高い資料種から順に変更していく方式を用いる。以下、診断名の情報を用いて処理を行う場合について説明する。

図１２（ａ）は、診断名と疾病が発生している部位との対応付けを表したテーブル１２０１の一例を示す図である。図１２（ａ）に示すように、例えばテーブル１２０１には、肺気腫は胸部の疾病であるという対応付けが取られている。

図１２（ｂ）は、各部位に対する抽出資料順を定めた抽出順テーブル１２０２の一例を示す図である。例えば、胸部の疾病を持つ患者に対して、図３のステップＳ３１０でクエリの資料種を暫定的に更新する際に、資料種を胸部レントゲン画像に更新する。そして、登録された資料を抽出できなかった場合は、次回のループではステップＳ３１０において資料種を心電図データへ変更する。なお、図１２（ｂ）に示す抽出順テーブル１２０２は、予め各部位に対して設定されていることを想定しているが、追加される頻度を資料種毎に記録しておき、追加頻度が高い資料種を上位の抽出順に設定するようにしてもよい。これにより、抽出順テーブルを実際の運用に即した形に更新されて再検索の回数を低減でき、会議支援システムの負荷を低減して応答性を向上させることが可能となる。

以上のように本実施形態によれば、会議対象の患者のカルテに記載されている診断名を元にして、再検索で抽出する資料種を変更するようにしたので、再検索回数をより低減することができる。これにより、会議支援システムの負荷を低減するとともにクエリの更新の正確性を向上させることができ、医師の業務効率を向上させることが可能となる。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０１ ＣＰＵ
１０５ ＲＯＭ
１０６ ＲＡＭ
１０７ ＤＩＳＫ

Claims (7)

1. 資料参照のために資料データベースから資料データを抽出するデータ抽出装置であって、
   抽出条件式を用いて前記資料データベースから参照する資料データを抽出する資料データ抽出手段と、
   参照すべき追加資料データをユーザが手動で追加登録する資料データ手動追加手段と、
   前記抽出条件式を作成する抽出条件作成手段と、
   を備え、
   前記抽出条件作成手段は、前記資料データ手動追加手段によって追加された前記追加資料データのメタ情報を利用して抽出条件式を生成できるか否かを判定し、生成できると判定される場合には、前記追加された追加資料データが抽出結果に含まれるように前記抽出条件式を作成する、
   ことを特徴とするデータ抽出装置。
2. 前記抽出条件作成手段は、前記メタ情報を利用して前記抽出条件式を生成できないと判定された場合には、前記資料データベースに予め含まれる前記資料データの種類と日付とのうち少なくとも一方を範囲とする前記抽出条件式を作成することを特徴とする請求項１に記載のデータ抽出装置。
3. 前記資料データベースは、患者情報、患者カルテ、及び患者検査画像を含む院内データベースであることを特徴とする請求項１または２に記載のデータ抽出装置。
4. 前記抽出条件作成手段は、前記追加資料データから前記メタ情報の有無を判定し、前記メタ情報が存在しない場合に、前記資料データベースに予め含まれる前記資料データの種類または日付を用いて検索を繰り返すことにより前記抽出条件式を作成することを特徴とする請求項１〜３の何れか１項に記載のデータ抽出装置。
5. 前記抽出条件作成手段は、前記抽出条件式が複数の条件を組み合わせた条件である場合に、前記複数の条件それぞれに分解して前記抽出条件式を更新することを特徴とする請求項１〜４の何れか１項に記載のデータ抽出装置。
6. 前記抽出条件作成手段は、前記複数の条件それぞれに分解して前記抽出条件式を更新した後に、さらに前記更新した抽出条件式の抽出範囲を狭くすることを特徴とする請求項５に記載のデータ抽出装置。
7. 前記資料データが、医療カンファレンスで使用するための資料のデータであることを特徴とする請求項１〜６の何れか１項に記載のデータ抽出装置。

Images