(57)【要約】  診療データ検索システムは、各患者の症状に対する診療内容を格納した診療データデータベースと、各症状と診療内容との関係を格納した診療パターンデータベースとを備える記憶装置と、前記診療データデータベース及び前記診療パターンデータベースに基づいて、前記症状を表すルートノードと、前記診療内容の名称を表す少なくとも１つの中間ノードと、前記診療内容の参照番号を表す少なくとも１つのリーフノードとを含むグラフを作成するグラフ処理部と、を備える。前記グラフ処理部は、ある症状に関する前記グラフが複数ある場合、前記複数のグラフの間で前記中間ノードの重複部分を統合する。
2015186205.tif 000002
【特許請求の範囲】
【請求項１】
各患者の症状に対する診療内容を格納した診療データデータベースと、各症状と診療内容との関係を格納した診療パターンデータベースとを備える記憶装置と、
前記診療データデータベース及び前記診療パターンデータベースに基づいて、前記症状を表すルートノードと、前記診療内容の名称を表す少なくとも１つの中間ノードと、前記診療内容の参照番号を表す少なくとも１つのリーフノードとを含むグラフを作成するグラフ処理部と、
を備え、
前記グラフ処理部は、ある症状に関する前記グラフが複数ある場合、前記複数のグラフの間で前記中間ノードの重複部分を統合することを特徴とする診療データ検索システム。
【請求項２】
請求項１に記載の診療データ検索システムにおいて、
前記診療パターンデータベースは、各患者の症状と各診療内容との関係を示す情報及び各患者に実施された診療内容間の関係を示す情報を含む関連テーブルを含み、
前記グラフ処理部は、前記関連テーブルを用いて前記グラフを作成することを特徴とする診療データ検索システム。
【請求項３】
請求項１に記載の診療データ検索システムにおいて、
前記グラフ処理部は、
複数の中間ノードの間がリンクによって関連付けられている場合には、前記複数の中間ノードの診療内容の組み合わせのパターンを表す第２の中間ノードを前記中間ノードの下位に作成し、
前記組み合わせのパターンの参照番号を表すリーフノードを前記第２の中間ノードの下位に作成することを特徴とする診療データ検索システム。
【請求項４】
請求項１に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記グラフ上において前記中間ノードに番号を付与し、前記番号と前記中間ノードの前記診療内容との関係を示す通番管理テーブルを作成することを特徴とする診療データ検索システム。
【請求項５】
請求項４に記載の診療データ検索システムにおいて、
前記グラフ処理部は、異なる症状に関する複数の前記グラフがある場合、前記複数のグラフの間で重複する前記中間ノードが多いグラフから優先して、前記番号を付与することを特徴とする診療データ検索システム。
【請求項６】
請求項４に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記参照番号が所定の順序に並ぶように前記リーフノードをソートすることを特徴とする診療データ検索システム。
【請求項７】
請求項４に記載の診療データ検索システムにおいて、
前記グラフ処理部は、同じ階層で互いに隣接する前記中間ノードの間で前記番号の差分値し、当該差分値を前記中間ノードに代入することを特徴とする診療データ検索システム。
【請求項８】
請求項７に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記差分値を符号化することを特徴とする診療データ検索システム。
【請求項９】
請求項８に記載の診療データ検索システムにおいて、
前記符号化は、デルタ符号化であることを特徴とする診療データ検索システム。
【請求項１０】
請求項１に記載の診療データ検索システムにおいて、
前記グラフを記憶するメモリと、
前記メモリ上の前記グラフを参照し、検索文の検索条件に合致する前記診療データデータベース内のレコードの位置を探索する検索式解析部と、をさらに備えることを特徴とする診療データ検索システム。
【請求項１１】
請求項１０に記載の診療データ検索システムにおいて、
前記検索式解析部は、前記検索条件内に前記診療データデータベース内のテーブルが含まれている場合、前記メモリ上の前記グラフを参照することを特徴とする診療データ検索システム。
【請求項１２】
請求項１０に記載の診療データ検索システムにおいて、
前記検索文の検索結果を出力する検索出力部と、
前記検索結果と前記グラフを表示する表示部と、をさらに備えることを特徴とする診療データ検索システム。
【請求項１３】
請求項１に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記診療データデータベース内のデータを暗号化する暗号化処理部を備えることを特徴とする診療データ検索システム。
【請求項１４】
請求項１３に記載の診療データ検索システムにおいて、
前記グラフを記憶するメモリと、
前記メモリ上の前記グラフを参照し、検索文の検索条件に合致する前記診療データデータベース内のレコードの位置を探索する検索式解析部と、をさらに備えることを特徴とする診療データ検索システム。
【請求項１５】
請求項１４に記載の診療データ検索システムにおいて、
前記検索式解析部は、前記診療データデータベース内のデータを復号化する復号化処理部を備えることを特徴とする診療データ検索システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、診療データを検索する検索システムに関する。
【背景技術】
【０００２】
本技術分野の背景技術として、特許文献１がある。特許文献１は、木構造を持つ化学化合物の探索システムを開示している。この探索システムでは、原子に対応するノードと、原子間の結合に対応するエッジからなる木構造として表現し、前記木構造を基に化学化合物の部分構造を文字列化することで、検索を容易にしている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−３２３１８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
診療データは高次元であり、データ間の関連性も複雑なため、データ項目を複数のテーブルに分けて管理する必要がある。このため分析対象となるデータセットを用意するときには、複数テーブルを結合する必要がある。一般的に、テーブル結合は負荷が大きく、大量データを扱う場合には、その処理時間が課題となる。特に、診療データは、データ量が大量であり、かつ、複雑なテーブル構造を持つ。したがって、診療データにおけるテーブル結合は、負荷が大きく、検索の効率性が課題となる。【０００５】
本発明の目的は、複雑なテーブル構造を持つ診療データにおいて、高速にテーブル結合が可能となり、検索の効率性の向上を図ることができる検索システムを提供することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決する為に、例えば特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例をあげるならば、各患者の症状に対する診療内容を格納した診療データデータベースと、各症状と診療内容との関係を格納した診療パターンデータベースとを備える記憶装置と、前記診療データデータベース及び前記診療パターンデータベースに基づいて、前記症状を表すルートノードと、前記診療内容の名称を表す少なくとも１つの中間ノードと、前記診療内容の参照番号を表す少なくとも１つのリーフノードとを含むグラフを作成するグラフ処理部と、を備え、前記グラフ処理部は、ある症状に関する前記グラフが複数ある場合、前記複数のグラフの間で前記中間ノードの重複部分を統合する、診療データ検索システムが提供される。
【発明の効果】
【０００７】
本発明によれば、複雑なテーブル構造を持つ診療データにおいても、高速にテーブル結合が可能となり、検索の効率性の向上を図ることができる。【０００８】
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の、課題、構成および効果は、以下の実施例の説明により明らかにされる。
【図面の簡単な説明】
【０００９】
【図１】第１実施例の診療データ検索システムの構成図である。
【図２】第１実施例のシステムのフローチャートである。
【図３】対象エピソードテーブルの一例である。
【図４】患者テーブルの一例である。
【図５】エピソードテーブルの一例である。
【図６】診療行為テーブルの一例である。
【図７】検査結果テーブルの一例である。
【図８】処方テーブルの一例である。
【図９】関連テーブルの一例である。
【図１０】診断治療知識に関するデータ構造の一例である。
【図１１】検査−適応疾患テーブルの一例である。
【図１２】薬剤−適応疾テーブルの一例である。
【図１３】診療パターン通番管理テーブルの一例である。
【図１４】検査通番管理テーブルの一例である。
【図１５】薬剤通番管理テーブルの一例である。
【図１６】診療行為通番管理テーブルの一例である。
【図１７】連結グラフの一例である。
【図１８】連結グラフの別の例である。
【図１９Ａ】連結グラフによる参照木の第１の例である。
【図１９Ｂ】連結グラフによる参照木の第２の例である。
【図２０】図１９Ａ及び図１９Ｂの２つの連結グラフを統合した例である。
【図２１Ａ】図２０のノード名称を通番に置き換えた例である。
【図２１Ｂ】図２１Ａのリーフノードをソートした例である。
【図２２】図２１Ｂの各ノードの通番に対して差分をとった例である。
【図２３】図２２の各ノードを符号化した例である。
【図２４】第１実施例における関連テーブル生成を説明するフローチャートである。
【図２５】第１実施例における検索処理を説明するフローチャートである。
【図２６】第１実施例に関わるハードシステム構成図である。
【図２７】第２実施例における関連テーブル生成を説明するフローチャートである。
【図２８】第２実施例における検索処理を説明するフローチャートである。
【図２９】検索結果の出力例である。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して本発明の実施例について説明する。なお、添付図面は本発明の原理に則った具体的な実施例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。
【００１１】
［第１実施例］
図１は、本実施例の診療データ検索システム全体の構成を示す。診療データ検索システムは、検索式解析部１０１と、検索式実行部１０２と、検索出力部１０３と、グラフ処理部１０４と、診療データデータベース（ＤＢ）１０５と、診療パターンデータベース（ＤＢ）１０６と、診療パターン管理部１０７とを備える。
【００１２】
検索式解析部１０１は、ユーザが入力した検索文（例えば、図１に記載のＳＱＬ文）を解析し、検索実行計画を検索式実行部１０２に引き渡す。検索式実行部１０２は、検索実行計画に基づき、診療データＤＢ１０５からデータを検索し、検査結果を検索出力部１０３に引渡す。検索出力部１０３は、検索結果を出力する。
【００１３】
ここで、検索式解析部１０１は、検索実行計画を立案する際に、メモリ上にあるグラフ（参照木）１０８を参照して、検索文の検索条件に合致するレコードの位置を探す。グラフ１０８は、診療データＤＢ１０５及び診療パターンＤＢ１０６に基づき、グラフ処理部１０４より生成される。
【００１４】
診療データＤＢ１０５は、各患者のエピソードに対する診療内容を記録したデータベースである。ここで、エピソードとは、ある症状の発現を意味する。診療内容には、患者に対する診療行為、患者に投与した薬剤、患者に対する検査の内容などが含まれる。診療データＤＢ１０５の情報は、医療機関などのデータ提供者から提供されるものである。診療パターンＤＢ１０６は、各症状と診療内容との関係を定義したデータベースである。診療パターンＤＢ１０６は、医療分野で知られている知識を格納したものである。
【００１５】
診療パターン管理部１０７は、入力された各種データを、診療パターンＤＢ１０６へ格納するための処理部である。データ管理者は、診療パターン管理部１０７を介して、診療パターンＤＢ１０６の情報を適宜編集し、管理することもできる。
【００１６】
ここで、図１を実現するハードシステム構成について説明する。図２６は、第１実施例に係る診療データ検索システムに関するハードシステム構成図である。
【００１７】
診療データ検索システムは、データセンタやサーバ等のコンピュータ２６０１でプログラムを実行することで実現される。例えば、上述した検索式解析部１０１と、検索式実行部１０２と、検索出力部１０３と、グラフ処理部１０４と、診療パターン管理部１０７は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することにより実現できる。
【００１８】
コンピュータ２６０１は、プログラムを実行し、かつデータを処理する演算装置であるＣＰＵ２６０２と、管理端末２６０３と、管理端末２６０３との間のインタフェースを構成する入出力インタフェース２６０４と、前述のプログラムやデータ等を記憶するメモリ２６０５と、外部とのインタフェースを構成する通信インタフェース２６０６と、外部記憶装置２６０７（図１のＤＢ１０５、１０６はここに配置される）等から構成される。
【００１９】
管理端末２６０３は、マウスやキーボードなどの入力部と、ディスプレイ等の出力部とを備える。オペレータは、入力部を介して、各種入力情報を入力することができる。また、出力部には、入力情報や検索結果等が表示される。
【００２０】
以下、上記システムが扱うデータ構成について説明する。図３は、対象エピソードテーブルを示す。対象エピソードテーブル３００は、グラフ処理部１０４の処理対象となるエピソードを管理するマスターテーブルである。対象エピソードテーブル３００は、個々のエントリの通し番号である通番３０１と、エピソードを一意に特定するための対象エピソード番号３０２と、当該エピソードを表す状態名３０３と、当該エピソードが主病名なのか合併症なのかを示す種類３０４とを構成項目として含む。状態名３０３は、病名、合併症、または併存症などからなる。
【００２１】
例えば、対象エピソードテーブル３００は、データ管理者が管理端末２６０３を操作し、作成されるものである。対象エピソードテーブル３００は、データ書き込み用の検索文（ＳＱＬ）を用いて、検索式解析部１０１及び検索式実行部１０２を介して、診療データＤＢ１０５に格納されてもよい。データ管理者は、この対象エピソードテーブル３００を作成して、収集するデータの対象を指定する。
【００２２】
図４は、患者テーブルを示す。患者テーブル４００は、患者の基本情報を管理するマスターテーブルである。患者テーブル４００は、患者を識別する患者ＩＤ４０１と、患者の氏名４０２と、患者の生年月日４０３と、患者の性別４０４と、患者が診療を受けている医療機関を識別する識別子である医療機関ＩＤ４０５とを構成項目として含む。
【００２３】
図５は、エピソードテーブルを示す。エピソードテーブル５００は、実際に各患者に起きたエピソード（症状）の情報を格納したテーブルである。エピソードテーブル５００は、エピソードを特定するための番号であるエピソード番号５０１と、患者を識別する患者ＩＤ５０２、エピソードを表す状態名５０３と、当該状態名に対応するレコードを図３の対象エピソードテーブル３００から参照するための対象エピソード番号５０４と、エピソードの開始日５０５と、治癒や死亡などの当該エピソードの帰結を示す転帰５０６と、当該エピソードに関係するコストの合計値であるコスト合計５０７とを構成項目として含む。なお、対象エピソード番号５０４は、図３の対象エピソードテーブル３００に、該当する状態名がない場合には空値となる。
【００２４】
図６は、診療行為テーブルを示す。診療行為テーブル６００は、実際に各患者に実施された診療行為の情報を格納したテーブルである。診療行為テーブル６００は、個々のエントリの通し番号であるオーダ番号６０１と、患者を識別する患者ＩＤ６０２と、当該患者に実施された診療行為に関する行為名６０３と、当該診療行為に関する開始日６０４及び終了日６０５と、当該診療行為に関するコスト６０６とを構成項目として含む。行為名６０３には、検査、処置、手術などの医療行為に関する名称が記載される。
【００２５】
図７は、検査結果テーブルを示す。検査結果テーブル７００は、図６の診療行為テーブル６００にエントリされた検体検査に関する結果を管理するテーブルである。検査結果テーブル７００は、診療行為テーブル６００における、どの検体検査の結果であるかを特定するためのオーダ番号７０１と、患者を識別する患者ＩＤ７０２と、検査名称である検査名７０３と、この検査名の検査結果数値である値７０４と、その単位７０５と、当該検査に関するコスト７０６と、検査日７０７とを構成項目として含む。
【００２６】
一つの検体検査に関して複数の検査が実施される場合があるので、同じオーダ番号に関して複数のレコードが存在することがある。図７は、１つのオーダ番号に２つの検査が含まれる場合を示している。
【００２７】
図８は、処方テーブルを示す。処方テーブル８００は、実際に各患者に処方された薬剤の情報を格納したテーブルである。処方テーブル８００は、個々のエントリの通し番号である処方番号８０１と、患者を識別する患者ＩＤ８０２と、処方された薬剤に関する薬剤名８０３と、当該薬剤の処方量８０４と、処方日８０５と、当該処方に関するコスト８０６とを構成項目として含む。
【００２８】
例えば、図４〜図８のデータは、例えば、医療機関などのデータ提供者から得ることができる。上述したデータは、データ書き込み用の検索文（ＳＱＬ）を用いて、検索式解析部１０１及び検索式実行部１０２を介して、診療データＤＢ１０５に格納される。診療データＤＢ１０５は、外部記憶装置２６０７において管理される。
【００２９】
図６、図７、及び図８は、ある患者に対して行われた診療内容（診療行為、検査、薬剤の処方）に関する記録であるが、これららのテーブルだけでは、各診療内容が、どのエピソードに関係するか判断できない。図９は、患者のエピソードと各診療内容との関係を特定するために用いられる関連テーブルを示す。
【００３０】
関連テーブル９００は、各患者のエピソードと各診療内容との関係を示す情報、及び、各患者に実施された診療内容間の関係を示す情報を含む。関連テーブル９００は、個々のエントリの通し番号である関連番号９０１と、患者を識別する患者ＩＤ９０２と、図５のエピソードテーブルから対象となるエピソードを参照するためのエピソード番号９０３と、テーブルを指定するテーブル名１（９０４）と、テーブル名１（９０４）における参照番号を示す参照番号１（９０５）と、テーブルを指定するテーブル名２（９０６）と、テーブル名２（９０６）における参照番号を示す参照番号２（９０７）とを構成項目として含む。
【００３１】
本例において、９０４、９０６が「対象エピソード」の場合は、参照番号は、図５の対象エピソード番号５０４となる。また、９０４、９０６が「診療行為」の場合は、参照番号は、図６のオーダ番号６０１となる。また、９０４、９０６が「検査結果」の場合は、参照番号は、図７のオーダ番号７０１となる。また、９０４、９０６が「処方」の場合は、参照番号は、図８の処方番号８０１となる。
【００３２】
図９に示すように、関連テーブル９００では、エピソードに対して診療内容が関連付けられる場合と、診療内容同士が関連付けられる場合がある。診療内容同士が関連付けられる場合、一例として、テーブル名１（９０４）及び参照番号１（９０５）で示される診療内容を、テーブル名２（９０６）及び参照番号２（９０７）で示される診療内容よりも時間的に前に実施されるものとして定義してもよい。
【００３３】
図１０は、診断治療知識の例を示す。診断治療知識１０００は、ファイルの構造を有する。診断治療知識１０００は、例えば、ＸＭＬなどの所定の構造を有するファイルである。本例の診断治療知識１０００では、患者がある状態にあるときに実施される検査、その検査結果から判断される病名、及び、その状態のときに実施される診療行為などが定義される。
【００３４】
診断治療知識１０００は、患者の症状（「強い胸痛」等）を表す状態セクション１００１と、前記症状のとき通常行われる検査と検査結果から判断される病名を表す検査セクション１００２と、前記状態のときに患者に行われる第１の診療内容を表す診療内容セクション１００３と、前記状態のときに患者に行われる第２の診療内容を表す診療内容セクション１００４とを構成項目として含む。
【００３５】
検査セクション１００２には、病名を検査結果から判断するための条件１００５（ＣＫ＞１９７、トロポニン＞０．２５  ＡＮＤ  ・・・）が定義されている。したがって、検査結果の条件１００５を満たす場合、病名が特定される。また、本例では、病名の部分が、図３の対象エピソードテーブル３００の対象エピソード番号３０２に関連付けされている。
【００３６】
診療内容セクション１００３には、患者に投与される「アスピリン」、「モルヒネ」等の薬剤名が定義されている。また、診療内容セクション１００４には、前記状態のとき通常行われる「心臓カテーテル（心カテ）」等の診療行為名が定義されている。なお、診療内容セクション１００３のＡｃｔｉｏｎ（１）と診療内容セクション１００４のＡｃｔｉｏｎ（２）の、（１）と（２）は時間順を示す。本例では、診療内容セクション１００３は、診療内容セクション１００４の前に実施されなければならないことを示す。
【００３７】
これら診断治療知識は、医療分野で広く認知された定説となっている知識である。データ管理者は、種々の症状に対するこのような知識を、事前に、例えば管理端末２６０３を用いて、診療パターン管理部１０７を介して診療パターンＤＢ１０６に格納しておく。この診断治療知識は、参照木を作成するために使用される。なお、診療パターンＤＢ１０６は、外部記憶装置２６０７において管理される。
【００３８】
図１１は、検査−適応疾患テーブルを示す。検査−適応疾患テーブル１１００は、各検査の適応疾患を管理するマスターテーブルであり、診断治療知識の一つである。検査−適応疾患テーブル１１００は、病名１１０１と、当該病名に適応する検査名１１０２と、当該検査に関するコスト１１０３とを構成項目として含む。ここで、ある検査がある病名に対して適応であるとは、当該病名（１１０１）が疑われる場合に、当該検査の実施に妥当性があることを意味する。
【００３９】
図１２は、薬剤−適応疾患テーブルを示す。薬剤−適応疾患テーブル１２００は、各薬剤の適応疾患を管理するマスターテーブルであり、診断治療知識の一つである。薬剤−適応疾患テーブル１２００は、病名１２０１と、当該病名に適応する薬剤名１２０２と、当該薬剤に関するコスト１２０３とを構成項目として含む。ここで、ある薬剤がある病名に対して適応であるとは、当該病名が疑われる場合に、当該薬剤の処方に妥当性があることを意味する。
【００４０】
なお、検査−適応疾患テーブル１１００及び薬剤−適応疾患テーブル１２００は、図１０と同様に、診療パターン管理部１０７を介して、事前に、診療パターンＤＢ１０６に格納される。この診断治療知識は、参照木を作成するために使用される。
【００４１】
図１３は、診療パターン通番管理テーブルを示す。ここで、診療パターンとは、診療内容（診療行為、薬剤、検査など）の組み合わせを意味する。診療パターン通番管理テーブル１３００は、各診療パターンの通番を管理するテーブルである。以下で詳細に説明するが、本実施例では、データ量を圧縮するために、参照木のノード名称の文字列を番号に置き換える。
【００４２】
診療パターン通番管理テーブル１３００は、ノードが診療パターンの時の名称と、置き換える番号との関係を定義する。診療パターン通番管理テーブル１３００は、ルート病名１３０１と、通番を表す番号１３０２と、診療パターン名を表す診療パターン１３０３とを構成項目として含む。図１３の例では、「心臓カテーテル（心カテ）」と「アスピリン」の組み合わせの情報が格納されている。
【００４３】
図１４は、検査通番管理テーブルを示す。検査通番管理テーブル１４００は、各検査名の通番を管理するテーブルである。検査通番管理テーブル１４００は、検査名１４０１と、通番を表す番号１４０２とを構成項目として含む。
【００４４】
図１５は、薬剤通番管理テーブルを示す。薬剤通番管理テーブル１５００は、各薬剤名の通番を管理するテーブルである。薬剤通番管理テーブル１５００は、薬剤名１５０１と、通番を表す番号１５０２とを構成項目として含む。
【００４５】
図１６は、診療行為通番管理テーブルを示す。診療行為通番管理テーブル１６００は、各診療行為名の通番を管理するテーブルである。診療行為通番管理テーブル１６００は、行為名１６０１と、通番を表す番号１６０２とを構成項目として含む。
【００４６】
図１７は、参照木を保管するための連結グラフの構造を示す。グラフは、症状を表すルートノードと、診療内容の名称を表す少なくとも１つの中間ノードと、診療内容の参照番号を表す少なくとも１つのリーフノードとを含む。
【００４７】
ノードの構造について説明する。１７０１はノードの値を格納するエリアであり、１７０２、１７０３は、次ノードのポインタを格納するエリアである。この図では、「心筋梗塞」をルートノードにして、ポインタ１７０２により、「心臓カテーテル（心カテ）」の中間ノード１７０４にリンクが張られている。同様に、ポインタ１７０３により、「アスピリン」の中間ノード１７０５にリンクが張られている。
【００４８】
また、リーフノード１７０６と１７０７は、それぞれ、その上位の中間ノード１７０４と１７０５に関連したテーブルのレコードの参照番号を格納する。例えば、リーフノード１７０６には、診療行為テーブル６００のオーダ番号６０１の情報が格納される。また、リーフノード１７０７には、処方テーブル８００の処方番号８０１の情報が格納される。
【００４９】
図１８は、図１７と同じく、参照木を保管するための連結グラフの構造を示す。ここでは、図１８の診療行為ノードから処方ノードにリンク１８０１がある場合で説明する。ここではリンク１８０１に示されるように、「心カテ」ノードと「アスピリン」ノードに医学的な関係があるケースを示している。
【００５０】
診療行為ノードの診療行為については２ケースあり、診療行為後に処方ノードの処方を実施した場合と、そうでない場合がある。図１７のグラフ構造では、この関係が区別することができない。言い換えると、ノード間に矢印がある場合のＡＮＤ条件、この場合は「診療行為かつ処方」という状態を、図１７のグラフ構造では表現できていない。
【００５１】
そこで、本実施例では、複数の中間ノードの間が時間的に前後を表すリンクによって関連付けられている場合には、複数の中間ノードの診療内容の組み合わせのパターンを表す第２の中間ノードを中間ノードの下位に作成し、第２の中間ノードの下位に、前記診療内容の組み合わせのパターンの参照番号を表すリーフノードを作成する。
【００５２】
図１８のように、第２の中間ノード（中継ノード）１８０２と１８０４を設けて、その下に参照番号を格納するリーフノード１８０３、１８０５をぶら下げる。上位ノード１８００は、第２の中間ノード１８０２と１８０４へのポインタを保持する。第２の中間ノード１８０２の名称は「心カテ・アスピリン」であるが、これは、「心カテ」の診療行為の後に、「アスピリン」が処方されたことを示す。
【００５３】
ここでは、「心カテ・アスピリン」のリーフノード１８０３の参照番号を「０００５」とする。例えば、診療行為テーブル６００には、その後にアスピリンを処方しなかった場合の「心カテ」のレコードと、その後にアスピリンの処方した場合の「心カテ」のレコードとが存在し得る。リーフノード１８０３には、アスピリンの処方ありの場合の「心カテ」のレコードの参照番号が格納される。
【００５４】
一方、第２の中間ノード１８０４の名称は「心カテ」だが、これは、「心カテ」の診療行為の後に、リンク１８０１に関連した処方がないことを示す。この場合のリーフノード１８０５の参照番号は、アスピリンの処方なしの場合の「心カテ」の参照番号である「０００２」とする。このような第２の中間ノード１８０２、１８０４を設けることにより、ノード間にリンクがある場合のＡＮＤ条件を、グラフ表現として実現できる。
【００５５】
以上で説明した図１３〜図１６の通番管理テーブル及び図１７、図１８の連結グラフは、メモリ２６０５上で管理されるものとする。
【００５６】
図１９Ａ及び図１９Ｂは、図１７及び図１８で説明した連結グラフの具体例である。図２０は、図１９Ａ及び図１９Ｂで示した２つの連結グラフを統合した例を示す。
【００５７】
図２は、コンピュータ２６０１のＣＰＵ２６０２により実行される、グラフ処理部１０４の処理フローを示す。グラフ処理部１０４は、図２の処理フローに従って、診療データＤＢ１０５及び診療パターンＤＢ１０６に基づいて、上述したグラフ（参照木）を生成する。
【００５８】
まず、ステップ２０１において、グラフ処理部１０４は、関連テーブル９００を作成する。本ステップは、図２４を用いて説明する。
【００５９】
ステップ２４０１では、グラフ処理部１０４は、検査−適応疾患テーブル１１００から１レコードずつ読み取り、病名１１０１と検査名１１０２を取得する。グラフ処理部１０４は、取得した検査名１１０２に基づき、検査結果テーブル７００の検査名７０３を探索する。グラフ処理部１０４は、検査結果テーブル７００内に適合するレコードがあれば、そのオーダ番号７０１、患者ＩＤ７０２、及び、検査日７０７を取得する。
【００６０】
次に、グラフ処理部１０４は、エピソードテーブル５００に対して、取得した患者ＩＤと病名に基づき、患者ＩＤ５０２と状態名５０３を探索する。エピソードテーブル５００内に適合するレコードがあれば、そのレコードの開始日５０５に着目する。そして、グラフ処理部１０４は、取得した検査日と開始日とを比較する。
【００６１】
例えば、ある患者に対して、複数の病名が診断され、複数の検査が実施されている場合がある。この場合、どの病名と、どの検査とを関連付けるかを判断する必要がある。ここでは、ある病名が診断され、その診断結果に対して時間的に後に検査が実施されていれば、その病名と検査を関連付けてもよいと判定する。なお、他の判定条件を用いてもよい。取得した開始日を基準として所定の期間の範囲に検査日が含まれるという、判定条件を用いてもよい。
【００６２】
本例では、取得した検査日が、開始日５０５よりも時間的に後であれば、グラフ処理部１０４は、当該レコードのエピソード番号５０１及び対象エピソード番号５０４を取得する。その後、グラフ処理部１０４は、関連テーブル９００に対して新しいレコードを生成する。関連番号９０１をインクリメントした後に、取得した患者ＩＤ及びエピソード番号を、患者ＩＤ９０２及びエピソード番号９０３にそれぞれ記録する。テーブル名１（９０４）については、「対象エピソード」を記録し、参照番号１（９０５）については、取得した対象エピソード番号を記録する。また、テーブル名２（９０６）については、検査結果テーブル７００を示す「検査結果」を記録し、参照番号２（９０７）については、取得したオーダ番号を記録する。
【００６３】
ステップ２４０２では、グラフ処理部１０４は、薬剤−適応疾患テーブル１２００から１レコードずつ読み取り、病名１２０１と薬剤名１２０２を取得する。グラフ処理部１０４は、取得した薬剤名１２０２に基づき、処方テーブル８００の薬剤名８０３を探索する。グラフ処理部１０４は、処方テーブル８００内に適合するレコードがあれば、その処方番号８０１、患者ＩＤ８０２、処方日８０５を取得する。
【００６４】
次に、グラフ処理部１０４は、エピソードテーブル５００に対して、取得した患者ＩＤと病名に基づき、患者ＩＤ５０２と状態名５０３を探索する。エピソードテーブル５００内に適合するレコードがあれば、そのレコードの開始日５０５に着目する。開始日に注目する理由は上述した通りである。取得した処方日が、この開始日５０５よりも時間的に後であれば、グラフ処理部１０４は、当該レコードのエピソード番号５０１及び対象エピソード番号５０４を取得する。その後、グラフ処理部１０４は、関連テーブル９００に対して新しいレコードを生成する。関連番号９０１をインクリメントした後に、取得した患者ＩＤ及びエピソード番号を、患者ＩＤ９０２及びエピソード番号９０３にそれぞれ記録する。テーブル名１（９０４）については、「対象エピソード」を記録し、その参照番号１（９０５）については、取得した対象エピソード番号を記録する。また、テーブル名２（９０６）については、処方テーブル８００を示す「処方」を記録し、参照番号２（９０７）については、取得した処方番号を記録する。
【００６５】
ステップ２４０３では、グラフ処理部１０４は、図１０の診断治療知識１０００に基づき、関連テーブル９００のレコードを生成する。まず、グラフ処理部１０４は、セクション１００５により病名を取得し、診療内容セクション１００３、１００４から薬剤名や診療行為名などを取得する。薬剤名が取得された場合の処理については、ステップ２４０２と同じである。
【００６６】
診療行為名が取得された場合、グラフ処理部１０４は、取得した診療行為名に基づき、診療行為テーブル６００の行為名６０３を探索する。診療行為テーブル６００内に適合するレコードがあれば、グラフ処理部１０４は、そのオーダ番号６０１、患者ＩＤ６０２、及び開始日６０４を取得する。
【００６７】
次に、グラフ処理部１０４は、エピソードテーブル５００に対して、取得した患者ＩＤと病名に基づき、患者ＩＤ５０２と状態名５０３を探索する。エピソードテーブル５００内に適合するレコードがあれば、そのレコードの開始日５０５に着目する。取得した開始日６０４が、開始日５０５よりも時間的に後であれば、グラフ処理部１０４は、当該レコードのエピソード番号５０１及び対象エピソード番号５０４を取得する。その後、グラフ処理部１０４は、関連テーブル９００に対して新しいレコードを生成する。関連番号９０１をインクリメントした後に、取得した患者ＩＤ及びエピソード番号を、患者ＩＤ９０２及びエピソード番号９０３にそれぞれ記録する。テーブル名１（９０４）については、「対象エピソード」を記録し、その参照番号１（９０５）については、取得した対象エピソード番号を記録する。また、テーブル名２（９０６）については、診療行為テーブル６００を示す「診療行為」を記録し、参照番号２（９０７）については、取得したオーダ番号を記録する。
【００６８】
ステップ２４０４では、グラフ処理部１０４は、図１０の診断治療知識１０００に基づき、診療行為と、処方と、検査結果との関係について調べ、関連テーブル９００に記録する。図１０の例では、診療内容セクション１００３のＡｃｔｉｏｎ（１）は、診療内容セクション１００４のＡｃｔｉｏｎ（２）の前に実施されなければならない。すなわち、図１０は、薬剤のアスピリン及びモルヒネを処方した後に、診療行為である心臓カテーテル（心カテ）が実施されることを示している。このような診療内容同士の関係を、診断治療知識１０００及び関連テーブル９００に基づいて調べる。
【００６９】
まず、グラフ処理部１０４は、関連テーブル９００において、同じエピソード番号９０３である複数のレコードのテーブル名２（９０６）に着目する。テーブル名２（９０６）が「診療行為」の場合は、グラフ処理部１０４は、その参照番号２（９０７）を診療行為テーブル６００のオーダ番号６０１と照合し、適合するレコードの患者ＩＤ６０２及び行為名６０３を取得する。同様に、テーブル名２（９０６）が「処方」の場合は、グラフ処理部１０４は、その参照番号２（９０７）を処方テーブル８００の処方番号８０１と照合し、適合するレコードの患者ＩＤ８０２と薬剤名８０３を取得する。同様に、テーブル名２（９０６）が「検査結果」の場合は、グラフ処理部１０４は、その参照番号２（９０７）を検査結果テーブル７００のオーダ番号７０１と照合し、適合するレコードの患者ＩＤ７０２と検査名７０３を取得する。
【００７０】
グラフ処理部１０４は、上記の処理で取得した、行為名６０３、薬剤名８０３、検査名７０３が、図１０の診療内容セクション１００３のＡｃｔｉｏｎ（１）及び診療内容セクション１００４のＡｃｔｉｏｎ（２）にあるかどうかを探索する。もし診療内容セクション１００３、１００４に存在すれば、グラフ処理部１０４は、そのＡｃｔｉｏｎのペアを新たなレコードとして関連テーブル９００に追加する。
【００７１】
ここでは、ある診断治療知識１０００内のＡｃｔｉｏｎのペアが、薬剤名（処方テーブルに対応）と検査名（検査結果テーブルに対応）だとする。また、Ａｃｔｉｏｎ（１）の薬剤の処方の後にＡｃｔｉｏｎ（２）の検査を実施しなければならないとする。関連番号９０１をインクリメントした後に、取得した患者ＩＤ及びエピソード番号を、患者ＩＤ９０２及びエピソード番号９０３にそれぞれ記録する。テーブル名１（９０４）については、「処方」を記録し、その参照番号１（９０５）については、処方番号を記録する。また、テーブル名２（９０６）については、「検査結果」を記録し、参照番号２（９０７）については、オーダ番号を記録する。
【００７２】
図２４の処理フローによって、診療データＤＢ１０５と診療パターンＤＢ１０６に基づいて、診療データの検索効率化のためのグラフ（参照木）を作成するための情報（関連テーブル９００）を作成することができる。特に、図２４の処理フローによって、各患者のエピソードと各診療内容との関係を示す情報、及び、各患者に実施された診療内容間の関係を示す情報を得ることができる。
【００７３】
次に、ステップ２０２において、グラフ処理部１０４は、診療データＤＢ１０５に格納された関連テーブル９００に基づいてグラフを作成する。まず、グラフ処理部１０４は、関連テーブル９００のレコードを順番に取り込み、エピソード番号９０３を調べ、同一のエピソード番号９０３である複数のレコードをグループ化する。同一のエピソード番号のグループに含まれる各レコードに対して、テーブル名（１）９０４が「対象エピソード」であるレコードを集める。グラフ処理部１０４は、テーブル名（１）９０４が「対象エピソード」のレコードについて、各レコードの参照番号１（９０５）を取得する。次に、グラフ処理部１０４は、対象エピソードテーブル３００において、取得した参照番号１（９０５）と対象エピソード番号３０２とが一致するレコードを探索する。そして、グラフ処理部１０４は、一致したレコードの状態名３０３を取得する。次に、グラフ処理部１０４は、テーブル名（２）９０６と参照番号（２）９０７から、テーブル名とその参照番号を取得する。ここで例えば、テーブル名（２）９０６が「処方」であれば、処方テーブル８００から、参照番号（２）９０７と一致する処方番号８０１のレコードを探索し、当該参照番号（２）９０７に関する薬剤名８０３を取得する。なお、テーブル名（２）９０６が「検査結果」あるいは「診療行為」の場合でも同様の処理である。
【００７４】
ここで、グラフ処理部１０４は、図１７の連結グラフを、上記で取得した状態名をルートノードとして作成する。次に、グラフ処理部１０４は、テーブル名（２）９０６から、当該状態名に関する処方、診療行為、又は検査結果を表す中間ノード１７０４、１７０５を作成する。また、グラフ処理部１０４は、参照番号（２）９０７から、中間ノード１７０４、１７０５に対応するリーフノード１７０６、１７０７を作成する。その後、グラフ処理部１０４は、ルートノードと中間ノード１７０４、１７０５をポインタにより連結し、中間ノード１７０４、１７０５とリーフノード１７０６、１７０７をポインタにより連結する。
【００７５】
関連テーブル９００には、薬剤名と関連する「処方」に関して副作用をチェックするための「検査結果」のように、対象エピソードとは直接関連のない関係が記述されているレコードが含まれ得る。これは、関連テーブル９００におけるテーブル名（１）９０４及びテーブル名（２）９０６が、「診療行為」、「処方」、及び「検査結果」から選択された２つの組み合わせの場合のレコードに相当する。
【００７６】
この場合は、グラフ処理部１０４は、テーブル名（１）９０４に該当するテーブルから、参照番号１（９０５）に基づいて行為名、薬剤名、又は検査名を取得し、取得した行為名、薬剤名、又は検査名のノードを作成する。同様に、グラフ処理部１０４は、テーブル名（２）９０６及び参照番号２（９０７）に対応するノードを作成する。そして、テーブル名（１）９０４に関するノードからテーブル名（２）９０６に関するノードにリンクを張るように、前者のノードが、後者のノードのポインタを保持する。
【００７７】
次に、グラフ処理部１０４は、参照番号１（９０５）及び参照番号（２）９０７を格納するリーフノードを作成する。そして、上位の中間ノードが当該リーフノードへのポインタを保持することにより、リンクを生成する。すなわち、「心カテ」の中間ノード１７０４からリーフノード１７０６へのリンクが張られ、「アスピリン」の中間ノード１７０５からリーフノード１７０７へのリンクが張られる。
【００７８】
次に、ステップ２０３において、グラフ処理部１０４は、ステップ２０２で作成したグラフに対して、第２の中間ノード（中継ノード）を生成する。具体的には、図１８に示すように、複数の中間ノードの間が時間的に前後を表すリンク１８０１によって関連付けられている場合には、グラフ処理部１０４は、複数の中間ノードの診療内容の組み合わせのパターンを表す第２の中間ノード（中継ノード）１８０２、１８０４を中間ノードの下位に作成する。さらに、グラフ処理部１０４は、第２の中間ノード１８０２、１８０４の下位に、前記診療内容の組み合わせのパターンを参照するための参照番号を表すリーフノード１８０３、１８０５を作成する。
【００７９】
例えば、ステップ２０２で作成したグラフが図１７の状態であるとする。行為名である「心カテ」から薬剤名である「アスピリン」にリンクが存在する。このとき、診療行為名のノードの診療行為については２ケースあり、診療行為後に薬剤名のノードの薬剤の処方を実施した場合と、そうでない場合がある。したがって、新たに２つの中間ノードを作成する。具体的には、グラフ処理部１０４は、「心カテ」の後に「アスピリン」を処方した場合を示す「心カテ・アスピリン」の第２の中間ノード１８０２と、「心カテ」のみを行った場合を示す「心カテ」の第２の中間ノード１８０４を作成する。そして、上位ノードである「心カテ」のノード１８００が第２の中間ノード１８０２、１８０４へのポインタを保持することにより、リンクを生成する。次に、グラフ処理部１０４は、第２の中間ノード１８０２、１８０４のそれぞれの参照番号を示すリーフノード１８０３、１８０５を生成する。そして、第２の中間ノード１８０２、１８０４は、それぞれの参照番号を示すリーフノード１８０３、１８０５のポインタを保持する。このような中間ノードを設けたグラフ構造によれば、ノード間にリンクがある場合のＡＮＤ条件を、グラフ表現として実現できるようになり、検索の効率性が高まる。
【００８０】
次に、ステップ２０４において、グラフ処理部１０４は、ステップ２０３で生成したグラフ群に対して重複部分を探索し、グラフ群を統合する。ステップ２０３で生成された、ある症状に関する複数のグラフがある場合、グラフ処理部１０４は、当該複数のグラフの間で中間ノードの重複部分を統合する。
【００８１】
ここでの統合処理を、図１９Ａのグラフ１９０１と図１９Ｂのグラフ１９０２の２つのグラフにより説明する。この例では、ルートノードとその１つ下の階層の中間ノードとを含む範囲において、２つのグラフ１９０１、１９０２の間で重複部分を探索し、その重複部分を統合する。例えば、グラフ１９０１、１９０２において、病名Ａ、薬品Ｂ、検査Ｃのノード、及び、これらのノード間のリンク（矢印）の方向も一致している。グラフ処理部１０４は、このようにルートノードが一致するグラフ間で中間ノードの重複部分を重ね合せることにより複数のグラフを統合する。図２０は、統合されたグラフの一例である。ステップ２０４では、この処理を全てグラフで行い、グラフ同士の重複部分がなくなるまで行う。なお、本例では、ルートノードと、そのルートノードの１つ下の階層の中間ノードとを含む範囲で重複部分を探索しているが、これに限定されず、重複部分を探索する範囲は適宜変更してもよい。
【００８２】
次に、ステップ２０５において、グラフ処理部１０４は、ステップ２０４の処理を行ったグラフに対して、リーフノード以外のノードのノード名称を通番に置き換えるために、各ノード名称の通番生成を行う。通番の付与の方針として、異なる対象エピソードにおいて重複する行為名、薬剤名、検査名、診療パターン（診療行為、薬剤、検査の組み合わせ）がある場合には、その対象エピソードから優先して、なるべく番号が近くなるように通番を割り振る。これは、以後のステップ２０８とステップ２０９で差分圧縮処理をするが、圧縮の効率を高めるために、差分値がなるべく小さくするための工夫である。
【００８３】
異なる対象エピソードに関するグラフおいて、行為名、薬剤名、検査名、診療パターン（診療行為、薬剤、検査の組み合わせ）のノードが重複する場合の処理について説明する。異なる対象エピソード（症状）に関する複数のグラフがある場合には、グラフ処理部１０４は、当該複数のグラフの間で重複する中間ノードが多いグラフから優先して、番号を付与する。
【００８４】
例えば、状態名Ａ（対象エピソードＡ）をルートノードとするグラフが、薬剤１、診療行為１を含み、状態名Ｂ（対象エピソードＢ）をルートノードとするグラフが、薬剤１、診療行為２を含み、状態名Ｃ（対象エピソードＣ）をルートノードとするグラフが、薬剤１、診療行為２、診療行為３を含むと仮定する。このとき、対象エピソードＢと対象エピソードＣとの間では２つの中間ノードが重複する。一方、対象エピソードＡと対象エピソードＢとの間で１つの中間ノードが重複する。したがって、重複部分が多い対象エピソードＢとＣでの通番割り振りを優先する。したがって、グラフ処理部１０４は、薬剤１、診療行為２、診療行為３に、それぞれ「１」、「２」、「３」と通番を割り振る。
【００８５】
次に、グラフ処理部１０４は、対象エピソードＡの診療行為１に「４」と通番を割り振る。対象エピソードＡでは、薬剤１と診療行為１の差分が３と大きくなってしまうが、対象エピソードＢとＣについては、差分がすべて１と小さくできる。ここで、対象エピソードＡの通番割り振りを、対象エピソードＢやＣとは異なる、その他の対象エピソードの後に行うと、薬剤１と診療行為１の差分は３よりも大きな値となってしまう。したがって、グラフで重複する部分（行為名、薬剤名、検査名、診療パターン）がある場合には、その対象エピソードから優先する。上記の例の場合、対象エピソードＢとＣでの通番割り振りが終了した後に、対象エピソードＡの通番の割り振りを行う。これにより、なるべく番号が近くなるように通番を割り振ることができ、ノード間の差分値を小さくできる。その結果、後述する差分値の値が全体的に小さく抑えられ、その後の符号化で短い符号語が割り当てられる。したがって、メモリ上で管理するグラフ（参照木）のデータ量を削減できる。
【００８６】
上記の手続きによって割り振られた通番は、行為名、薬剤名、検査名、診療パターンのそれぞれに応じて、図１３、図１４、図１５、及び図１６の通番管理テーブルの形式で記録される。グラフ処理部１０４は、図１３〜図１６の通番管理テーブルの形式で、割り振られた番号と中間ノードの診療内容との関係を記録する。
【００８７】
具体的には、ノードが診療パターンの場合は、グラフ処理部１０４は、診療パターン通番管理テーブル１３００にレコードを作成する。そのグラフのルートノードとなる状態名がルート病名１３０１に記録され、通番が番号１３０２に記録され、その診療パターンの名称が診療パターン１３０３に記録される。ノードが検査名の場合は、グラフ処理部１０４は、検査通番管理テーブル１４００にレコードを作成する。検査名が検査名１４０１に記録され、通番が番号１４０２に記録される。ノードが薬剤名の場合は、薬剤通番管理テーブル１５００にレコードを作成する。薬剤名が薬剤名１５０１に記録され、通番が番号１５０２に記録される。同様に、ノードが診療行為の行為名の場合は、グラフ処理部１０４は、診療行為通番管理テーブル１６００にレコードを作成する。行為名が行為名１６０１に記録され、通番が番号１６０２に記録される。
【００８８】
次に、ステップ２０６において、グラフ処理部１０４は、グラフにおけるリーフノード以外のノードの名称を、図１３、図１４、図１５、及び図１６の通番管理テーブルの番号で置き換える。なお、対象エピソードの状態名については、対象エピソードテーブル３００の通番３０１で置き換える。図２１Ａは、図２０のノード名称を通番に置き換えた例を示している。
【００８９】
次に、ステップ２０７において、グラフ処理部１０４は、ステップ２０６の処理を行った後のグラフに関して、そのグラフ内のリーフノードの参照番号が左から右に大きくなるよう、リーフノードをソートする。これは、差分値を計算するときに、極力、その差分の値を小さい値にするためである。その効果は、上述したように、符号化した後のデータ量を削減することにある。例えば、図２１Ｂは、参照番号が左から右に大きくなるように、図２１Ａのリーフノードをソートした例である。
【００９０】
次に、ステップ２０８において、グラフ処理部１０４は、ステップ２０７の処理を行った後のグラフに対して、水平方向に隣接するノード（すなわち、グラフ内で同じ階層で互いに隣接するノード）間で差分をとり、その差分値で通番又は参照番号を置き換える。図２１の例では、ルートノードから一段下のノード２１０１、２１０２の間で差分を取るように、水平方向で差分値を算出する。また、さらに一段下のノード２１０３、２１０４の間で差分を取る。さらにリーフノードの間でも差分を取る。
【００９１】
具体的には、グラフ処理部１０４は、水平方向に隣接するノードに関して、右側のノードの通番から左側のノードの通番を引くことにより、差分値を算出する。例えば、ノード２１０１の通番「２」からノード２１０２の通番「１」を引くことによって差分値「１」を算出し、その差分値「１」は、右側のノード２１０１に代入される。同様に、グラフ処理部１０４は、他のノードも差分値を算出する。なお、ルートノードは、差分が取れないので、元の値を保持する。また、各階層において一番左側のノードは、差分が取れないので、元の値を保持する。図２２は、図２１Ｂの各ノードに関して差分をとった例を示している。
【００９２】
次に、ステップ２０９において、グラフ処理部１０４は、ステップ２０８で計算した各中間ノードの差分値に対して所定の符号化を行う。図２３は、図２２のノードの差分値に対して符号化を行った例を示している。本実施例では、ステップ２０９においてデルタ符号化を行う。デルタ符号とは可変長符号であり、小さな値には短い符号語を、反対に大きな値には長い符号語を割り当てる特性がある。したがって、差分後の番号が、全ノードで小さく抑えられれば、短い符号語が割り当てられるため、全体としてデータ量が削減できる。なお、符号化処理は、これに限定されず、他の符号化処理によって全体としてデータ量を削減してもよい。
【００９３】
以上の処理により、グラフ１０８が作成される。グラフ処理部１０４は、グラフ１０８を外部記憶装置に格納しておいてもよい。そして、以下で説明する検索処理時に、グラフ１０８はメモリ上に読み込まれる。本実施例で作成されたグラフを検索処理に用いることにより、複雑なテーブル構造を持つ診療データにおいても、検索の効率性が高まる。
【００９４】
また、従来では、大量なデータを含むテーブル結合において、ＳＱＬオプティマイザーは、ハッシュ結合を採用する場合が多かった。ハッシュテーブルがメモリ上に乗れば高速であるが、メモリ不足の場合、逆に遅くなるという課題がある。これに対して、本実施例で作成されたグラフ１０８によれば、グラフ１０８のデータ量が全体として削減されており、従来に比べて小さいメモリ量でも管理可能である。
【００９５】
図２５は、検索時の検索式解析部１０１、検索式実行部１０２、及び検索出力部１０３の動作を説明するフローチャートである。この検索処理では、図２のフローチャートで作成された参照木（グラフ）を用いて検索を行う。図１に示すように、グラフ（参照木）１０８はメモリ上に読み込まれている。
【００９６】
ステップ２５０１において、検索式解析部１０１が、ＳＱＬ文を受け取り、ＷＨＥＲＥ句の解析を行う。次に、ステップ２５０２において、検索式解析部１０１は、ＷＨＥＲＥ句の中に、エピソードテーブル５００に関する式が含まれているかを判定する。エピソードテーブル５００に関する式が含まれている場合は、ステップ２５０４に進み、そうでない場合は、ステップ２５０３へ進む。
【００９７】
次に、ステップ２５０４において、検索式解析部１０１は、ＷＨＥＲＥ句の中に、診療行為テーブル６００、検査結果テーブル７００、及び処方テーブル８００の少なくとも１つに関する式が含まれているかを判定する。これらの所定のテーブルに関する式が含まれている場合は、ステップ２５０５に進み、そうでない場合は、ステップ２５０３へ進む。このように、検索条件（ＷＨＥＲＥ句）内に診療データＤＢ１０５内のテーブルが含まれているかを判定し、メモリ上のグラフ１０８を参照できるかを判定する。これにより、無駄にグラフを参照することがないようにしている。
【００９８】
なお、ステップ２５０３へ進んだ場合は、検索式解析部１０１は、メモリ上のグラフ１０８を使わずに検索処理を行うものと判定して、ＳＱＬ文を検索式実行部１０２に渡す。検索式実行部１０２は、渡されたＳＱＬ文を実行し、検索結果を検索出力部１０３に受け渡す。
【００９９】
ステップ２５０５において、検索式解析部１０１は、エピソードテーブル５００と、診療行為テーブル６００、検査結果テーブル７００、及び処方テーブル８００の少なくとも１つのテーブルとの結合関係から、メモリ上のグラフ１０８をサーチする。以下で検索式解析部１０１の処理を説明する。
【０１００】
ここでは、下記のＳＱＬ文にもとづき説明する。
ｓｑｌ  ＊  ｆｒｏｍ  エピソードテーブル，  処方テーブル，  検査結果テーブル  ｗｈｅｒｅ  エピソードテーブル．状態名＝‘心筋梗塞’，  診療行為テーブル．行為名＝‘心カテ’；
【０１０１】
まず、エピソードテーブル．状態名＝‘心筋梗塞’については、対象エピソードテーブル３００の状態名３０３と「心筋梗塞」とを照合して、該当する通番３０１を取得する。この例の場合は、通番３０１は「２」となる。次に、メモリ上の複数のグラフ１０８から、グラフのルートノードが「２」のグラフを探し出す。
【０１０２】
次に、診療行為テーブル６００を例に説明するが、検査結果テーブル７００、処方テーブル８００についても同様である。診療行為テーブル．行為名＝“心カテ”については、診療行為通番管理テーブル１６００の行為名１６０１と「心カテ」とを照合して、該当する通番を取得する。上記のグラフ（ルートノードが「２」のグラフ）をトラバースし、かつ、デルタ符号化されたノードを元の通番に戻しながら、この通番がノードに現れるかチェックする。
【０１０３】
次に、ステップ２５０６において、検索式解析部１０１は、ステップ２１０５でのノードの存在の有無を判定する。「心カテ」の通番がノードに存在すれば、リーフノードから、当該診療行為に関する参照番号を取得して、ステップ２５０７に進む。もし存在しない場合には、ステップ２５０３に進む。
【０１０４】
次に、ステップ２５０７において、検索式解析部１０１は、ステップ２５０６で取得した参照番号に基づき、対象となるテーブル（診療行為テーブル６００、検査結果テーブル７００、処方テーブル８００）から、その参照番号に該当するレコードを探索する。これにより、ＳＱＬ文の検索条件（ＷＨＥＲＥ句）に合致するレコードの位置を探すことができる。
【０１０５】
ステップ２５０８において、検索式解析部１０１は、ステップ２５０７の検索結果を検索出力部１０３に受け渡す。図２９は、検索結果の出力例である。例えば、検索結果は、ディスプレイ等の出力部に表示される。画面は、検索結果出力部２９０１と、グラフ出力部２９０２とを備える。検索結果出力部２９０１には、検索条件に合致するレコードが表示される。グラフ出力部２９０２には、検索式解析部１０１が参照したグラフが表示される。グラフ出力部２９０２でのグラフの表示は、図示しないオプションボタンなどによって、表示又は非表示を切替可能にしてもよい。このように、検索に使った参照木を表示されるため、検索処理の根拠がわかり、有用である。
【０１０６】
［第２実施例］
本実施例では、第１実施例の処理に対して、診療データＤＢ１０５のデータを暗号化する処理を加える。図２７及び図２８により、本実施例を説明する。
【０１０７】
図２７は、ステップ２７０１からステップ２７０９までは、図２のステップ２０１からステップ２０９と同じである。本実施例では、グラフ処理部１０４が、暗号化処理部を備える。ステップ２７０１からステップ２７０９によりグラフを作った後に、ステップ２７１０において、グラフ処理部１０４の暗号化処理部が、図３から図９までの診療データＤＢ１０５で管理されたテーブルの内容を暗号化する。
【０１０８】
本実施例では、暗号化の方式は限定しないが、一つの共通鍵で上記テーブルの各レコードを全て暗号化する。これにより、記憶媒体上の診療データに対して、プライバシー保護等のセキュリティが高まる。
【０１０９】
図２８は、図２７の処理で暗号化した診療データＤＢに関する検索処理を示す。ステップ２８０１〜２８０６、２８０８は、図２５のステップ２５０１〜２５０６、２５０８と同じである。本実施例では、検索式解析部１０１が、復号化処理部を備える。ステップ２８０７では、検索式解析部１０１は、ステップ２８０６で求めた参照番号に基づき、対象となるテーブル（診療行為テーブル６００、検査結果テーブル７００、処方テーブル８００）から、参照番号に該当するレコードを探索する。ここで、図２７の処理で診療データＤＢ１０５の各レコードは暗号化されている。したがって、検索式解析部１０１の復号化処理部は、同一の共通鍵で参照番号を復号化する。これにより、検索式解析部１０１は、ステップ２８０６で求めた参照番号と照合し、該当するレコードを取得する。
【０１１０】
図２８のステップ２８０５ではグラフ（参照木）を使って、検索条件に合致するレコードを探索しているが、これを暗号化された診療データＤＢ１０５に対して行うと、一旦、全てのデータの暗号化を複合化して、テーブル間の結合処理が必要となり負荷が大きい。本実施列のように、グラフを使うことで、復号化と結合処理の負荷を大幅に削減することができる。したがって、暗号化によるプライバシー保護等のセキュリティ強化とテーブル間の結合処理の性能向上の両立を図ることが可能となる。
【産業上の利用可能性】
【０１１１】
本発明は、診療データを分析することで、診断治療の質を高めつつ、病院経営の効率を高める技術として有用である。【０１１２】
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。上記実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることもできる。また、ある実施例の構成に他の実施例の構成を加えることもできる。また、各実施例の構成の一部について、他の構成を追加・削除・置換することもできる。【０１１３】
上記の診療データ検索システムの機能、処理手段などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）などの記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤなどの記憶媒体に置くことができる。また、上記で説明した診療データ検索システムの機能、処理手段などは、それらの一部あるいは全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。【０１１４】
また、図面における制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。
【符号の説明】
【０１１５】
１０１  検索式解析部
１０２  検索式実行部
１０３  検索出力部
１０４  グラフ処理部
１０５  診療データＤＢ
１０６  診療パターンＤＢ
１０７  診療パターン管理部
１０８  グラフ（参照木）
３００  対象エピソードテーブル
４００  患者テーブル
５００  エピソードテーブル
６００  診療行為テーブル
７００  検査結果テーブル
８００  処方テーブル
９００  関連テーブル
１０００  診断治療知識
１１００  検査−適応疾患テーブル
１２００  薬剤−適応疾患テーブル
１３００  診療パターン通番管理テーブル
１４００  検査通番管理テーブル
１５００  薬剤通番管理テーブル
１６００  診療行為通番管理テーブル
２６０１  コンピュータ
２６０２  ＣＰＵ
２６０３  管理端末
２６０４  入出力インタフェース
２６０５  メモリ
２６０６  通信インタフェース
２６０７  外部記憶装置
【図１】
2015186205.tif 000003
【図２】
2015186205.tif 000004
【図３】
2015186205.tif 000005
【図４】
2015186205.tif 000006
【図５】
2015186205.tif 000007
【図６】
2015186205.tif 000008
【図７】
2015186205.tif 000009
【図８】
2015186205.tif 000010
【図９】
2015186205.tif 000011
【図１０】
2015186205.tif 000012
【図１１】
2015186205.tif 000013
【図１２】
2015186205.tif 000014
【図１３】
2015186205.tif 000015
【図１４】
2015186205.tif 000016
【図１５】
2015186205.tif 000017
【図１６】
2015186205.tif 000018
【図１７】
2015186205.tif 000019
【図１８】
2015186205.tif 000020
【図１９Ａ】
2015186205.tif 000021
【図１９Ｂ】
2015186205.tif 000022
【図２０】
2015186205.tif 000023
【図２１Ａ】
2015186205.tif 000024
【図２１Ｂ】
2015186205.tif 000025
【図２２】
2015186205.tif 000026
【図２３】
2015186205.tif 000027
【図２４】
2015186205.tif 000028
【図２５】
2015186205.tif 000029
【図２６】
2015186205.tif 000030
【図２７】
2015186205.tif 000031
【図２８】
2015186205.tif 000032
【図２９】
2015186205.tif 000033
【手続補正書】
【提出日】平成28年11月28日(2016.11.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
各患者の症状に対する診療内容を格納した診療データデータベースと、各症状と診療内容との関係を格納した診療パターンデータベースとを備える記憶装置と、
前記診療データデータベース及び前記診療パターンデータベースに基づいて、前記症状を表すルートノードと、前記診療内容の名称を表す少なくとも１つの中間ノードと、前記診療内容の参照番号を表す少なくとも１つのリーフノードとを含むグラフを作成するグラフ処理部と、
を備え、
前記グラフ処理部は、ある症状に関する前記グラフが複数ある場合、前記複数のグラフの間で前記中間ノードの重複部分を統合することを特徴とする診療データ検索システム。
【請求項２】
請求項１に記載の診療データ検索システムにおいて、
前記診療パターンデータベースは、各患者の症状と各診療内容との関係を示す情報及び各患者に実施された診療内容間の関係を示す情報を含む関連テーブルを含み、
前記グラフ処理部は、前記関連テーブルを用いて前記グラフを作成することを特徴とする診療データ検索システム。
【請求項３】
請求項１に記載の診療データ検索システムにおいて、
前記グラフ処理部は、
前記複数の中間ノードの間がリンクによって関連付けられている場合には、前記複数の中間ノードの診療内容の組み合わせのパターンを表す第２の中間ノードを前記中間ノードの下位に作成し、
前記組み合わせのパターンの参照番号を表すリーフノードを前記第２の中間ノードの下位に作成することを特徴とする診療データ検索システム。
【請求項４】
請求項１に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記グラフ上において前記中間ノードに番号を付与し、前記番号と前記中間ノードの前記診療内容との関係を示す通番管理テーブルを作成することを特徴とする診療データ検索システム。
【請求項５】
請求項４に記載の診療データ検索システムにおいて、
前記グラフ処理部は、異なる症状に関する複数の前記グラフがある場合、前記複数のグラフの間で重複する前記中間ノードが多いグラフから優先して、前記番号を付与することを特徴とする診療データ検索システム。
【請求項６】
請求項４に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記参照番号が所定の順序に並ぶように前記リーフノードをソートすることを特徴とする診療データ検索システム。
【請求項７】
請求項４に記載の診療データ検索システムにおいて、
前記グラフ処理部は、同じ階層で互いに隣接する前記中間ノードの間で前記番号の差分値を算出し、当該差分値を前記中間ノードに代入することを特徴とする診療データ検索システム。
【請求項８】
請求項７に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記差分値を符号化することを特徴とする診療データ検索システム。
【請求項９】
請求項８に記載の診療データ検索システムにおいて、
前記符号化は、デルタ符号化であることを特徴とする診療データ検索システム。
【請求項１０】
請求項１に記載の診療データ検索システムにおいて、
前記グラフを記憶するメモリと、
前記メモリ上の前記グラフを参照し、検索文の検索条件に合致する前記診療データデータベース内のレコードの位置を探索する検索式解析部と、をさらに備えることを特徴とする診療データ検索システム。
【請求項１１】
請求項１０に記載の診療データ検索システムにおいて、
前記検索式解析部は、前記検索条件内に前記診療データデータベース内のテーブルが含まれている場合、前記メモリ上の前記グラフを参照することを特徴とする診療データ検索システム。
【請求項１２】
請求項１０に記載の診療データ検索システムにおいて、
前記検索文の検索結果を出力する検索出力部と、
前記検索結果と前記グラフを表示する表示部と、をさらに備えることを特徴とする診療データ検索システム。
【請求項１３】
請求項１に記載の診療データ検索システムにおいて、
前記グラフ処理部は、前記診療データデータベース内のデータを暗号化する暗号化処理部を備えることを特徴とする診療データ検索システム。
【請求項１４】
請求項１３に記載の診療データ検索システムにおいて、
前記グラフを記憶するメモリと、
前記メモリ上の前記グラフを参照し、検索文の検索条件に合致する前記診療データデータベース内のレコードの位置を探索する検索式解析部と、をさらに備えることを特徴とする診療データ検索システム。
【請求項１５】
請求項１４に記載の診療データ検索システムにおいて、
前記検索式解析部は、前記診療データデータベース内のデータを復号化する復号化処理部を備えることを特徴とする診療データ検索システム。
【国際調査報告】
2015186205.tif 000034
2015186205.tif 000035
2015186205.tif 000036
2015186205.tif 000037