JP2018180993A - データ分析支援システム及びデータ分析支援方法 - Google Patents

Abstract

【課題】予測対象の事象の発生原因を考慮した分析を行う。【解決手段】データ分析支援システムであって、複数の患者の状態に関する診療情報を保持する記憶部と、前記診療情報に基づいて、前記複数の患者の状態を複数のクラスタに分類する患者状態分類部と、前記分類された患者の状態、および、前記各患者において所定の事象が発生したか否かに基づいて、前記分類された患者の状態から前記所定の事象の発生を予測する予測モデルを生成する予測モデル生成部と、を有する。【選択図】図１

Description

本発明は、医療機関における蓄積されたデータの分析を支援する情報システムに関する。

近年、医療機関における蓄積されたデータの活用によって、機械学習または統計解析などを用いて特定の事象の予測・検証などを実施し、その結果に基づいて治療計画の決定を支援することなどが行われている。

特許文献１には、ＩＣＵなどの集中的な監視下から監視されない環境へ解放される（または退院する予定の）患者について、作成した予測モデルを使用し、前記患者の心拍数、体温などの生理学的情報および治療データなどを活用し、前記患者の死亡・再入院リスクを算出し、医師に提示することで、医師による退院判断を支援することが記載されている。

特表２０１４−５２０３３５号公報

前述のように、これまでの治療計画決定支援システムでは、予測モデルを作成し、作成した予測モデル使用し、患者の心拍数、体温などの生理学的情報および治療データなどを活用し、前記患者の予測対象の事象の発生リスクを算出し、医師に提示することで、医師による退院判断の支援を実現するシステムがあった。しかし、予測モデルを作成する際に、予測対象の事象の発生原因を考慮した予測モデルの構築がされていない、という問題があった。例えば、再入院に関する予測モデルを構築する際に、予測モデルの作成に使用する目的変数として再入院をするか否かの２値のみを使用した場合では、再入院の原因ごとに関係する説明変数が異なる時に、その原因を把握することは容易ではなく、再入院を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが困難である。そのため、治療計画の決定支援および適切な退院判断の支援などには、予測対象の事象の発生原因を考慮した分析が課題であった。

特許文献１に記載された技術によれば、予測対象の事象の発生原因は考慮していないため、発生原因を考慮した分析ができない。

以上のように予測対象の事象の発生原因を考慮した分析を実現させるには、従来開示されている技術では十分な効果を得ることが困難であった。

上記課題を解決するため、複数の患者の状態に関する診療情報を保持する記憶部と、前記診療情報に基づいて、前記複数の患者の状態を複数のクラスタに分類する患者状態分類部と、前記分類された患者の状態、および、前記各患者において所定の事象が発生したか否かに基づいて、前記分類された患者の状態から前記所定の事象の発生を予測する予測モデルを生成する予測モデル生成部と、を有することを特徴とするデータ分析支援システムを提供する。

本発明の一形態によれば、予測対象の事象の発生後の患者状態に基づく患者の分類を行い、分類に基づいて作成した目的変数を使用した予測モデルの構築を行う事で、分析対象患者の予測対象の事象の発生リスク等と、分析対象患者が予測対象の事象の発生後にどの様な状態であるかを予測・推定することが可能となり、予測対象の事象の発生原因を容易に分析することができる。さらに、例えば、分類に基づいて作成した目的変数を使用した予測モデルの構築によって、予測対象の事象の発生後の状態と関係がある因子を容易に把握することができる。

上記以外の課題、構成および効果は、以下の実施形態の説明によって明らかにされる。

本発明の実施例１の治療計画決定支援システムの構成を示すブロック図である。 本発明の実施例１の治療計画決定支援システムが保持する患者情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持する検査情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持する処方情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持するイベント情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持するイベント原因情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持する目的変数情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持する目的変数情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持する目的変数情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが保持するイベントマスタ情報テーブルの例を示す説明図である。 本発明の実施例１の治療計画決定支援システムの動作を示すフローチャートである。 本発明の実施例１において、イベントデータ生成部がイベントデータを生成する分析処理を実行する動作を示すフローチャートである。 本発明の実施例１において、患者分類部が患者状態を分類する分析処理を実行する動作を示すフローチャートである。 本発明の実施例１の治療計画決定支援システムが表示する分析条件受付用の画面の例を示す説明図である。 本発明の実施例１の治療計画決定支援システムにおいて、原因情報が存在する場合に表示画面生成部が生成する分析結果の提示画面の例を示す説明図である。 本発明の実施例１の治療計画決定支援システムにおいて、原因情報が存在しない場合に表示画面生成部が生成する分析結果の提示画面の例を示す説明図である。 本発明の実施例１の治療計画決定支援システムにおいて、クラスタリング結果表示ボタンが押下された場合に、表示画面生成部が生成するクラスタリング結果の表示画面の例を示す説明図である。 本発明の実施例１の治療計画決定支援システムが、予測モデル構築において可変因子の値が高くなるようにクラスタリングを実施する場合に、表示画面生成部が生成するクラスタリング結果の画面の例を示す説明図である。 本発明の実施例１の治療計画決定支援システムにおいて、可変因子による重み付けを実行した後のクラスタリング結果の表示画面の例を示す説明図である。

以下、図面に基づいて、本発明の実施の形態を説明する。なお、本発明の実施形態は、後述する形態例に限定されるものではなく、その技術思想の範囲において、種々の変形が可能である。

≪構成≫
＜システム構成の説明１＞
図１は、本発明の実施例１の治療計画決定支援システム１００の構成を示すブロック図である。

本実施例の治療計画決定支援システムは、治療計画決定支援システム１００と、病院情報システム１２０と、入出力端末１３０と、ネットワーク１４０と、によって構成される計算機システムである。本実施例の治療計画決定支援システムは、蓄積されたデータから分析用データを作成し、作成した分析用データうち、分析対象の事象が発生した患者について予測対象の事象の発生後の患者状態に基づく患者の分類を行い、分類に基づいて作成した目的変数を使用した予測モデルの構築を行う事で、分析対象患者の予測対象の事象の発生リスク等と分析対象患者が予測対象の事象の発生後にどの様な状態であるかを予測・推定し、その結果を可視化して出力する。

本実施例では、入出力端末１３０は、キーボード、マウス、又はタッチパネルなどの入力部（図示省略）と、ディスプレイなどの出力部（図示省略）と、治療計画決定支援システム１００などと通信する通信部（図示省略）と、を有する１つまたは複数のパーソナルコンピュータである。また、ボタンまたはタッチパネルなどの入力部と、ディスプレイなどの出力部と、治療計画決定支援システム１００などと通信する通信部とを有するＰＤＡ、ＰＨＳ、携帯電話、スマートフォン、タブレット端末、入力部を有するグラス型ディスプレイ又はヘッドマウントディスプレイなどのウェアラブルディスプレイ端末などの可搬型端末を入出力端末１３０として利用することもできる。

本実施例では、入出力端末１３０を、病院または診療所などの医療機関（ヘルスケアプロバイダ）に設置して利用する。一方、治療計画決定支援システム１００がデータセンターに設置される。

このように、治療計画決定支援システム１００をデータセンターに設置することで、患者の個人情報および患者から収集されるデータなどのプライバシー情報を一元管理できるので、情報漏洩防止等のセキュリティ管理を簡易化できる。この治療計画決定支援システム１００は、運用の形態によってはヘルスケアプロバイダに設置して利用してもよい。

入出力端末１３０の利用者（以下ユーザと記載する）としては、医療機関の医師、分析担当者、薬剤師、管理者又は経営責任者を想定している。

ユーザは、入出力端末１３０を操作し、本実施例で示される情報システムを用いて、蓄積されたデータから分析用データを作成し、作成した分析用データうち、分析対象の事象が発生した患者について予測対象の事象の発生後の患者状態に基づく患者の分類を行う。そして、本実施例の情報システムは、分類に基づいて作成した目的変数を使用した予測モデルの構築を行う事で、分析対象患者の予測対象の事象の発生リスク等、および、分析対象患者が予測対象の事象の発生後にどの様な状態であるかを予測・推定し、その結果を可視化する。

治療計画決定支援システム１００は、相互に接続された、制御部１０１、出力部１０２、メモリ１０３、通信部１０４、表示画面生成部１０５、データ抽出部１０６、分析対象患者抽出部１０７、イベントデータ生成部１０８、患者状態分類部１０９、目的変数ラベル生成部１１０、予測モデル生成部１１１、統合データベース１１２、イベント情報格納データベース１１３、予測モデル格納データベース１１４、および蓄積データ取得部１１９によって構成される。

蓄積データ取得部１１９は、ヘルスケアプロバイダに設置されている病院情報システム１２０に存在する診療情報データベース１２１に蓄積された患者情報、検査情報、処方情報、治療情報、などの患者に関する診療情報のデータを取得し、統合データベース１１２に格納する。

蓄積データ取得部１１９は、ユーザによって直接起動されてもよいし、ユーザが予め指定した時間、例えば毎週土曜の夜などに、自動的に起動してもよい。あるいは、診療情報データベース１２１、のデータが更新された時に、自動的に起動してもよい。

制御部１０１は、例えばメモリ１０３に格納されたプログラムを実行するプロセッサであり、治療計画決定支援システム１００の各部を制御する。メモリ１０３は、例えばＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような記憶装置であり、治療計画決定支援システム１００の各部によって参照されるデータ（例えば制御部１０１によって実行されるプログラム等）を格納する。

統合データベース１１２は、メモリ１０３に格納されてもよいし、治療計画決定支援システム１００内の別の記憶装置（例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）のような不揮発性記憶装置、図示省略）に格納されてもよい。

出力部１０２は、治療計画決定支援システム１００による処理の結果を出力する装置であり、例えばディスプレイ装置であってもよい。

通信部１０４は、ネットワーク１４０に接続され、入出力端末１３０との通信を行う。

表示画面生成部１０５、データ抽出部１０６、分析対象患者抽出部１０７、イベントデータ生成部１０８、患者状態分類部１０９、目的変数ラベル生成部１１０、および予測モデル生成部１１１は、治療計画決定支援システム１００の機能を実現するための処理を実行する処理部であり、それぞれが専用のハードウェアによって実現されてもよいし、ソフトウェアによって実現されてもよい。後者の場合、以下の説明において上記の各処理部が実行する処理は、実際には、制御部１０１がメモリ１０３に格納されたプログラムに記述された命令に従って実行する。上記の各処理部によって実行される処理の詳細については後述する。

制御部１０１が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワーク１４０を介して治療計画決定支援システム１００に提供され、非一時的記憶媒体である不揮発性記憶装置に格納される。このため、治療計画決定支援システム１００は、リムーバブルメディアからデータを読み込むインターフェース（図示省略）を有するとよい。

治療計画決定支援システム１００は、物理的に一つの計算機上で、又は、論理的若しくは物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。

病院情報システム１２０は、ネットワーク１４０に接続される計算機システムであり、例えば、治療計画決定支援システム１００が有するものと同様の制御部、メモリ及び通信部（いずれも図示省略）等を有してもよい。診療情報データベース１２１は、病院情報システム１２０のメモリに格納されてもよいし、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）のような、病院情報システム１２０内の別の記憶装置（図示省略）に格納されてもよい。

ネットワーク１４０には、治療計画決定支援システム１００、病院情報システム１２０および入出力端末１３０が接続されている。治療計画決定支援システム１００は、ネットワーク１４０を介して病院情報システム１２０および入出力端末１３０と通信する。

ネットワーク１４０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）ケーブルによる有線通信、または無線ＬＡＮなどによる無線通信を利用する。

また、ネットワーク１４０は、インターネット、ＶＰＮ、携帯電話通信網、ＰＨＳ通信網など、他の広域ネットワークを利用することもできる。

続いて、統合データベース１１２を構成するテーブル構造を説明する。

統合データベース１１２は、患者毎の基本情報等を管理する患者情報テーブル２００、患者毎の検査情報を格納する検査情報テーブル３００、および、患者毎の処方情報を格納する処方情報テーブル４００で構成される。統合データベース１１２は、そのほかにも、患者毎の治療情報などの患者に関する診療情報を格納するテーブルを有しても良い（図示省略）。

図２は、本発明の実施例１の治療計画決定支援システム１００が保持する患者情報テーブル２００の例を示す説明図である。

患者情報テーブル２００は、患者情報テーブル２００内のレコードを識別するレコードＩＤを格納するフィールド２０１と、患者を識別する患者ＩＤを格納するフィールド２０２と、患者の性別を格納するフィールド２０３と、患者が医療機関に入院した日時、または外来診断のために医療機関を訪問した日時における患者の年齢を格納するフィールド２０４と、患者が外来診断のために医療機関を訪問した場合にその診断年月日を格納するフィールド２０５と、患者が医療機関に入院した場合にその入院年月日を格納するフィールド２０６と、患者が医療機関に入院し、その後退院した場合にその退院年月日を格納するフィールド２０７と、患者の一つ以上の疾患名（病名）を格納する一つ以上のフィールド（図２の例では、病名１を格納するフィールド２０８、病名２を格納するフィールド２０９および病名３を格納するフィールド２１０）と、で構成される。

患者が医療機関に外来診断のために訪問した場合には、診断年月日を格納するフィールド２０５にはレコード毎の値が格納され、入院年月日および退院年月日を格納するフィールド２０６および２０７には「０」が格納される。一方、患者が医療機関に入院のために訪問した場合には、診断年月日を格納するフィールド２０５には「０」が格納され、入院年月日および退院年月日を格納するフィールド２０６および２０７にはレコード毎の値が格納される。

例えば、図２に示した患者情報テーブル２００の患者情報レコードの例２００Ａは、患者ＩＤ「＃１」で識別される患者に関する情報を含み、レコードＩＤ「１」で識別されるレコードであり、レコードの各フィールドの値は、性別「男」、年齢「６８歳」、診断日「０」、入院年月日「２０１６／０４／０１」、退院年月日「２０１６／０４／２６」、病名１「心不全」、病名２「腎不全」、病名３は何も情報が登録されていない事を示す「ＮＵＬＬ」である。これは、患者ＩＤ「＃１」で識別される６８歳の男性の患者が、心不全と腎不全のために２０１６年４月１日から２０１６年４月２６日まで入院したことを示している。

なお、患者情報テーブル２００には、４以上の病名を示す情報が含まれていてもよいし（図示省略）、病名の代わりにＩＣＤ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｌａｓｓｉｆｉｃａｔｉｏｎ ｏｆ Ｄｉｓｅａｓｅｓ）コードなどの病名を示すコードが格納されても良い（図示省略）。

図３は、本発明の実施例１の治療計画決定支援システム１００が保持する検査情報テーブル３００の例を示す説明図である。

検査情報テーブル３００は、患者に対して行われた検査に関する情報を格納するテーブルであり、患者ＩＤを格納するフィールド３０１と、検査項目を識別する情報を格納するフィールド３０２と、検査日を格納するフィールド３０３と、検査結果（例えば検査値）を格納するフィールド３０４と、で構成される。

例えば、図３に示す検査情報テーブル３００の例は、患者ＩＤ「＃１」の患者において、検査項目「検査項目Ｘ」の値が、「２０１６／０４／０１」に「４１」、「２０１６／０４／０７」に「６２」、「２０１６／０４／１３」に「１８０」、「２０１６／０４／１５」に「２２０」、「２０１６／０４／１８」に「１９６」、「２０１６／０４／２５」に「１２０」であったことを示し、検査項目「検査項目Ｙ」の値が、「２０１６／０４／１」に「３８」であったことを示している。

なお、上記のフィールド３０４に格納される検査値は、検査結果の一例であり、検査情報テーブル３００は、検査値の代わりに（またはそれに加えて）、画像検査（例えばＣＴ画像検査）のような、検査値以外の種類の検査結果を示す情報を含んでもよく、さらに、「吐き気」または「嘔吐」といった患者の自覚症状に関する情報を含んでもよい（図示省略）。

図４は、本発明の実施例１の治療計画決定支援システム１００が保持する処方情報テーブル４００の例を示す説明図である。

処方情報テーブル４００は、患者に対して行われた薬剤の処方に関する情報を格納するテーブルであり、患者ＩＤを格納するフィールド４０１と、薬剤を識別する情報（薬剤名）を格納するフィールド４０２と、各薬剤の処方開始日を格納するフィールド４０３と、各薬剤の処方終了日を格納するフィールド４０４と、で構成される。

例えば、図５に示した処方情報テーブル４００の例は、患者ＩＤ「＃１」の患者において、薬剤名「薬剤Ａ」の薬剤が「２０１６／０４／０１」から「２０１６／０４／０７」までと、「２０１４／０６／０８」から「２０１６／０４／１４」までの期間に処方され、薬剤名「薬剤Ｂ」の薬剤がが「２０１６／０４／０３」から「２０１６／０４／０８」までの期間に処方され、薬剤名「薬剤Ｄ」の薬剤が「２０１６／０４／１６」から「２０１６／０４／２０」までの期間に処方されたことを示している。また、処方情報テーブル４００は、各薬剤の処方の開始時間、終了時間、用法、用量、および薬効を示すコードの情報を格納するフィールドを有してもよい（図示省略）。

続いて、イベント情報格納データベース１１３を構成するテーブル構造を説明する。

イベント情報格納データベース１１３は、イベント情報テーブル５００、イベント原因情報テーブル６００、目的変数情報テーブル７００〜９００およびイベントマスタ情報テーブル１０００によって構成される。イベント情報テーブル５００は、予測対象の事象が特定の患者で発生したか否かなどの情報を格納する。イベント原因情報テーブル６００は、予測対象の事象が発生した原因に関する情報を格納する。目的変数情報テーブル７００は、予測対象の事象が発生した原因が存在する場合に患者状態分類部１０９の分類結果と目的変数ラベル生成部１１０が作成する目的変数ラベルを格納する。ここで、予測対象の事象が発生した原因が存在する場合とは、後述する図１３のステップ１３０２において、イベントの発生原因に関連する情報が存在すると判定された場合である。目的変数情報テーブル８００は、予測対象の事象が発生した原因が存在しない場合に患者状態分類部１０９の分類結果と目的変数ラベル生成部１１０が作成する目的変数ラベルを格納する。目的変数情報テーブル９００は、複数の患者分類情報を有する場合に患者状態に患者状態分類部１０９の分類結果と目的変数ラベル生成部１１０が作成する目的変数ラベルを格納する。イベントマスタ情報テーブル１０００は、イベントデータ生成部によって作成されたイベント情報の詳細と対応する予測モデルの情報を格納する。

図５は、本発明の実施例１の治療計画決定支援システム１００が保持するイベント情報テーブル５００の例を示す説明図である。

イベント情報テーブル５００は、イベント情報テーブルの各レコードの識別子を格納するフィールド５０１と、各レコードに対応するイベント識別子を格納するフィールド５０２と、各レコードに対応する患者ＩＤを格納するフィールド５０３と、各レコードに対応するイベント発生日を格納するフィールド５０４と、各レコードに対応するイベント値を格納するフィールド５０５と、で構成される。

各レコードに対応するイベントＩＤによって識別されるイベントが、各レコードに対応する患者ＩＤによって識別される患者において発生した場合には、当該レコードのイベント値を格納するフィールド５０５に「１」が格納され、発生しなかった場合には「０」が格納される。

図６は、本発明の実施例１の治療計画決定支援システム１００が保持するイベント原因情報テーブル６００の例を示す説明図である。

イベント原因情報テーブル６００は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド６０１と、各レコードに対応するイベントの発生原因を格納するフィールド６０２と、で構成される。

イベントの発生原因を格納するフィールドには、例えば、「高血圧コントロール不良」または「不整脈」など、各イベントレコードＩＤに対応するイベントが発生した原因が格納される。イベントの原因を示す数字または識別子などが格納されてもよい。

図７は、本発明の実施例１の治療計画決定支援システム１００が保持する目的変数情報テーブル７００の例を示す説明図である。

目的変数情報テーブル７００は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド７０１と、各レコードに対応するイベント値を格納するフィールド７０２と、各レコードに対応する患者クラスタの値を格納するフィールド７０３と、各レコードに対応する目的変数ラベルの値を格納するフィールド７０４と、で構成される。

目的変数ラベルの値を格納するフィールドには、各患者クラスタに対応する値が格納される。例えば、患者クラスタの値として「高血圧コントロール不良」が格納されている場合、目的変数ラベルとして「Ａ」の値が格納され、患者クラスタの値として「不整脈」が格納されている場合、目的変数ラベルとして「Ｂ」の値が格納される。また、イベント値として「０」が格納されている場合、患者クラスタとしてイベントが発生しなかった事を示す「Ｎｕｌｌ」が格納され、目的変数ラベルとして「Ｚ」が格納される。

図８は、本発明の実施例１の治療計画決定支援システム１００が保持する目的変数情報テーブル８００の例を示す説明図である。

目的変数情報テーブル８００は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド８０１と、各レコードに対応するイベント値を格納するフィールド８０２と、各レコードに対応する患者クラスタの値を格納するフィールド８０３と、各レコードに対応する目的変数ラベルの値を格納するフィールド８０４と、で構成される。

目的変数ラベルの値を格納するフィールド８０４には、クラスタリング処理によって算出された各患者クラスタに対応する値が格納される。例えば、患者クラスタの値として「クラスタ１」が格納されている場合、目的変数ラベルとして「Ａ」の値が格納され、患者クラスタの値として「クラスタ２」が格納されている場合、目的変数ラベルとして「Ｂ」の値が格納される。また、イベント値として「０」が格納されている場合、患者クラスタとしてイベントが発生しなかった事を示す「Ｎｕｌｌ」が格納され、目的変数ラベルとして「Ｚ」が格納される。

図９は、本発明の実施例１の治療計画決定支援システム１００が保持する目的変数情報テーブル９００の例を示す説明図である。

目的変数情報テーブル９００は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド９０１と、各レコードに対応するイベント値を格納するフィールド９０２と、各レコードに対応する患者クラスタ１の値を格納するフィールド９０３と、各レコードに対応する患者クラスタ２の値を格納するフィールド９０４と、各レコードに対応する目的変数ラベルの値を格納するフィールド９０５と、で構成される。

患者クラスタ１の値を格納するフィールド９０３には、原因情報に基づいた患者のクラスタリング結果が格納され、患者クラスタ２の値を格納するフィールド９０４には、クラスタリング処理によって算出された各患者クラスタに対応する値が格納される。

目的変数ラベルの値を格納するフィールド９０５には、患者クラスタ２に対応する値が格納される。例えば、患者クラスタ２の値として「クラスタ１’」が格納されている場合、目的変数ラベルとして「Ａ’」の値が格納される。また、イベント値として「０」が格納されている場合、患者クラスタ１および患者クラスタ２としてイベントが発生しなかった事を示す「Ｎｕｌｌ」が格納され、目的変数ラベルとして「Ｚ」が格納される。

図１０は、本発明の実施例１の治療計画決定支援システム１００が保持するイベントマスタ情報テーブル１０００の例を示す説明図である。

イベントマスタ情報テーブル１０００は、各レコードに対応するイベント識別子を格納するフィールド１００１と、イベント識別子と対応する予測モデルの作成時の条件１を格納するフィールド１００２と、イベント識別子と対応する予測モデルの作成時の条件２を格納するフィールド１００３と、各イベント識別子と対応する予測モデルの目的変数を格納するフィールド１００４と、各イベント識別子と対応する予測モデルの識別子を格納するフィールド１００５と、で構成される。イベントマスタ情報テーブル１０００は、上記の例では、イベント識別子と対応する予測モデルの作成時の条件を二つ含んでいるが、三つ以上の条件を含んでもよい。（図示省略）。

次に本実施例のシステムの動作フローを、フローチャートを用いて説明する。

図１１は、本発明の実施例１の治療計画決定支援システム１００の動作を示すフローチャートである。

まず、制御部１０１は、ステップ（Ｓ）１１０１を実行し、統合データベース１１２から蓄積された患者データを呼び出す。ここでは、患者に関するデータ、例えば、患者を識別する情報、患者に対応する処方薬の情報、患者に対応する検査結果の情報等を総称して患者データと記載する。制御部１０１は、ステップ１１０１において、統合データベース１１２に含まれる全患者データを読み出し、メモリ１０３に記憶してもよい。

なお、このステップは、メモリ１０３に記憶されたプログラムに記述された命令に従って実行される。以下に説明する他のステップも同様である。

次に、制御部１０１は、ステップ１１０２を実行し、分析条件の受付画面を表示し、分析対象患者の情報および分析条件の情報を受け付ける。

図１４は、本発明の実施例１の治療計画決定支援システム１００が表示する分析条件受付用の画面の例を示す説明図である。

分析条件受付用の画面の例１４００は、分析対象患者の選択エリア１４０１と、使用モデルの設定エリア１４０２と、分析データ用患者の指定条件エリア１４０３と、目的変数の設定エリア１４０４と、統計解析オプションの設定エアリア１４０５と、分析の実行ボタン１４０６と、で構成される。

ユーザは、分析対象患者の選択エリア１４０１内に表示された患者の中から、イベントの発生に関しての分析を行う患者を分析対象患者として選択する。

ユーザは、使用モデルの設定エリア１４０２に付随するラジオボタンを操作することで、「新たにモデルを作成」または「既存のモデル」のいずれかを選択する。前者が選択された場合、イベントの発生に関する予測モデルが新たに作成され、そのモデルがイベントの発生に関する分析に使用される。後者が選択された場合、過去の分析で作成されたか、又は予めデータとして格納されている既存のモデルが分析に使用される。

ユーザが「新たにモデルを作成」を選択した場合、分析データ用患者の指定条件エリア１４０３と、目的変数の設定エリア１４０４と、統計解析オプションの設定エアリア１４０５と、が表示される。ユーザは、分析データ用患者の指定条件エリア１４０３内のプルダウンリストを操作することで、新たなモデルの作成に使用する分析データ用患者の指定条件を設定する。図１４の例では、条件１に「病名＝心不全」、条件２に「年齢＞＝６０歳」、が選択されている。これは、分析データ用患者として、心不全の病名を有し、年齢が６０歳以上の患者が選択されることを示している。分析データ用患者の指定条件エリア１４０３には、３つ目以上の条件を選択するプルダウンリストが含まれていてもよい（図示省略）。

また、ユーザは、目的変数の設定エリア１４０４内のプルダウンリストを操作することで、新たなモデルの作成に使用する目的変数の設定を行う。図１４の例では、条件１に「退院後３０日以内の再入院」、が選択されている。これは、目的変数として、退院後３０日以内の再入院が起きたか否かを示す情報が使用されることを示している。目的変数の設定エリア１４０４には、２つ目以上の条件を選択するプルダウンリストが含まれていてもよい（図示省略）。

ユーザが「既存のモデル」を選択した場合、制御部１０１は、イベントマスタ情報テーブル１０００に格納されている過去に作成された予測モデルの条件および目的変数を読み出し、過去に作成されたモデルから使用するモデルをユーザに選択させるための画面を表示する（図示省略）。

また、ユーザは、統計解析オプションの設定エアリア１４０５内のプルダウンリストを操作することで、新たなモデルの作成に使用する統計手法の設定を行う。図１４の例では、統計手法に「ロジスティック回帰」、変数選択に「ＡＩＣ：１００個」が選択されている。これは、Ａｋａｉｋｅ’ｓ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｒｉｔｅｒｉｏｎ（ＡＩＣ）によって選択された１００個の変数を活用し、ロジスティック回帰を用いて予測モデルの構築が行われることを示している。

統計解析オプションの設定エアリア１４０５では、例えば、「Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ（ＳＶＭ）」、「Ｄｅｅｐ−Ｌｅａｒｎｉｎｇ」、「ニューラルネットワーク」、「ベイジアンネットワーク」、「決定木学習」および「ランダムフォレスト」など、他の機械学習の方式を提示し、それらのいずれかをユーザに選択させても良いし、上記の例のような複数の機械学習方式を選択させ、同時に複数の予測モデルを作成しても良いし、複数の機械学習の方式を組み合わせた予測モデルの作成方式（アンサンブル学習）を選択させてもよい（図示省略）。

また、目的変数の設定エリア１４０４の変数選択では、例えば、「ステップワイズ」、「相関分析」、「Ｍａｘｉｍｕｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｅｆｆｉｃｉｅｎｔ」および「Ｌ１正則化」のいずれかなど、他の方式を選択しても良いし、上記の例のような複数の変数選択方式を選択し同時に複数の変数選択を実施する方式を選択しても良いし、複数の変数選択を複数回実施することで複数段階の変数選択を行う方式を選択してもよい（図示省略）。

ユーザが分析実行ボタン１４０６を選択すると、制御部１０１は、ステップ１１０３を実行し、イベントデータ生成部１０８を起動し、ステップ１１０２で受け付けた各種分析条件に基づき、ステップ１１０２で設定した分析データ用患者の設定情報と、目的変数の設定情報とを用いて、イベントデータを作成する。ステップ１１０３で実行される処理の詳細は図１２を参照して説明する。

図１２は、本発明の実施例１において、イベントデータ生成部１０８がイベントデータを生成する分析処理を実行する動作を示すフローチャートである。

ステップ１２０１において、イベントデータ生成部１０８は、患者情報テーブル２００、をメモリ１０３上に読み出す。

次に、ステップ１２０２において、イベントデータ生成部１０８は、イベントレコードＩＤに「０」を設定する。

次に、ステップ１２０３において、イベントデータ生成部１０８は、メモリ１０３に読み出した患者情報テーブル２００のレコードＩＤを全て取得し、いずれかのレコードＩＤについてイベントデータの生成処理を実行すると判定すると、次のステップ１２０４を実行する。具体的には、例えば、イベントデータ生成部１０８は、ステップ１２０３で取得したレコードＩＤに対応する患者情報テーブル２００の全てのレコードのうち、イベントデータの生成処理（すなわちステップ１２０４以降の処理）がまだ行われていないレコードを対象として、イベントデータの生成処理を実行する。

ステップ１２０４において、イベントデータ生成部１０８は、ステップ１２０３でイベントデータの生成処理を実行すると判定したレコードＩＤの患者が、ステップ１１０２で受け付けた条件に合致するか否かを判定する。合致すると判定した場合、イベントデータ生成部１０８は、次のステップ１２０５を実行する。

ステップ１２０５において、イベントデータ生成部１０８は、イベント値として「０」を設定し、イベントレコードＩＤに「１」を加算する。

次に、ステップ１２０６において、イベントデータ生成部１０８は、イベント情報テーブル５００に、ステップ１２０５の加算によって得られたイベントレコードＩＤと、イベントＩＤと、ステップ１２０３でイベントデータの生成処理を実行すると判定したレコードＩＤの患者ＩＤと、イベント値とを紐づけて格納する。

次に、ステップ１２０７において、イベントデータ生成部１０８は、ステップ１１０２で受け付けた目的変数の情報と合致すると判定すると次のステップ１２０８を実行する。

次に、ステップ１２０８において、イベントデータ生成部１０８は、ステップ１２０６においてデータを格納したレコードのイベント値を１に設定し、目的変数との情報と合致した日付をイベント発生日として格納する。

例えば、図１４に示すように、分析条件として条件１「病名＝心不全」および条件２「年齢＞＝６０歳」が選択され、かつ、目的変数として条件１「退院後３０日以内の再入院」が選択された場合、イベントデータ生成部１０８は、患者情報テーブル２００の各レコードが分析条件に合致するかどうかを判定し、合致するレコードについて、目的変数の条件が満たされるかどうかを判定する。

例えば、ステップ１２０３で、図２に示す患者情報テーブル２００の先頭のレコード２００Ａが処理の対象として選択された場合、当該レコード２００Ａに対応する患者が６０歳以上であり、対応する病名に心不全が含まれることから、ステップ１２０４において当該レコード２００Ａが分析条件に合致すると判定される。すると、ステップ１２０５において、イベント情報テーブル５００に、当該レコード２００Ａに対応する新たなレコード（例えばレコード５００Ａ）が追加される。この時点で、当該レコード５００ＡのイベントＩＤのフィールド５０２には目的変数として設定された条件に相当するイベント（上記の例では条件１「退院後３０日以内の再入院」）を識別するイベントＩＤ（例えば「イベント１」）が設定され、イベント値のフィールド５０５には「０」が設定される。さらに、ステップ１２０６において、当該レコード５００Ａの患者ＩＤのフィールド５０３にはレコード２００Ａの患者ＩＤと同じ値が設定される。

その後、ステップ１２０７では、当該レコード２００Ａが目的変数の設定条件に合致しているかが判定される。図２の例では、レコード２００Ａの患者が２０１６年４月２６日に退院した後、２０１６年５月１８日に再入院している（レコード２００Ｂ）。すなわち、条件１「退院後３０日以内の再入院」が満たされるため（ステップ１２０７：Ｙｅｓ）、レコード５００Ａのイベント値のフィールド５０５が「１」に変更され（ステップ１２０８）、当該再入院の日付がイベント発生日のフィールド５０４に登録される。この例では、「２０１６年５月１８日に再入院した」というイベントが、後述する図１３の処理において分析対象のイベントとして扱われる。

仮に当該患者が２０１６年５月２６日までに再入院していなければ、条件１「退院後３０日以内の再入院」が満たされないため（ステップ１２０７：Ｎｏ）、ステップ１２０８が実行されずに処理はステップ１２０３に戻り、レコード５００Ａのイベント値のフィールド５０５は「０」のままとなる。

ステップ１２０８が終了すると処理はステップ１２０３に戻り、取得された全てのレコードについて処理が終了するまで、ステップ１２０４以降の処理が繰り返し実行される。取得された全てのレコードについてイベントデータの生成処理が終了した場合、図１２の処理が終了してステップ１１０４以降の処理が実行される。

ステップ１１０４において、制御部１０１は、患者状態分類部１０９を起動し、イベントの発生原因、またはイベント発生後の患者状態、に基づく患者の分類を行う。ステップ１１０４で実行される処理の詳細は図１３を参照して説明する。

図１３は、本発明の実施例１において、患者状態分類部１０９が患者状態を分類する分析処理を実行する動作を示すフローチャートである。

ステップ１３０１において、患者状態分類部１０９は、ステップ１１０３で作成したイベント情報テーブル５００をメモリ１０３上に読み出す。

次に、ステップ１３０２において、患者状態分類部１０９は、イベントの発生原因に関連する情報が診療情報データベース１２１または統合データベース１１２に存在するか否かを検証し、イベントの発生原因に関連する情報が存在すると判定した場合にはステップ１３０３を実行する。

次に、ステップ１３０３において、患者状態分類部１０９は、イベントの発生原因に関連する情報をメモリ１０３上に読み出し、イベント情報テーブル５００のイベントレコードＩＤと読み出したイベントの発生原因とを対応づけて格納する。その後、患者状態分類部１０９は、後述するステップ１３０４からステップ１３０６を実行せずに、ステップ１３０７を実行する。

一方で、イベントの発生原因に関連する情報が存在しないと判定した場合には、患者状態分類部１０９はステップ１３０３を実行せずにステップ１３０４を実行する。

次に、ステップ１３０４において、患者状態分類部１０９は、イベント情報テーブル５００から、分析対象のイベントＩＤを有し、かつ、イベント値が「１」のレコードの患者ＩＤを全て抽出する。

次に、ステップ１３０５において、患者状態分類部１０９は、ステップ１３０４で抽出した患者ＩＤと対応する患者に関する、分析対象のイベントが発生した直後の診療情報を抽出する。ここで、分析対象のイベントが発生した直後とは、分析対象のイベントが発生した時点を基準とする所定の期間の一例であり、例えば、分析対象のイベントが発生してから所定の時間が経過するまでの期間である。また、ここで抽出される診療情報は、ステップ１３０４で抽出した患者ＩＤによって識別される患者の状態を示す情報であり、患者情報テーブル２００、検査情報テーブル３００および処方情報テーブル４００の少なくともいずれかから抽出された当該患者に関する値を含んでもよい。

次に、ステップ１３０６において、患者状態分類部１０９は、ステップ１３０５で抽出した診療情報に含まれる値を対象とするクラスタ分析などのクラスタリング処理を実施し、ステップ１３０４で抽出した患者ＩＤの患者群を複数のクラスタに分類する。クラスタリング処理において、クラスタ数は予めユーザが指定した値を使用しても良いし、予めユーザが指定した値を上限クラスタ数として最もイベントの予測精度が高くなるクラスタを網羅的に探索しても良いし。例えば、患者状態分類部１０９は、クラスタ数を変更しながら複数回のクラスタリングを実行してもよい。予測モデル生成部１１１は、複数回のクラスタリングの結果に基づいて複数の予測モデルを生成し（後述するステップ１１０６）、それぞれの予測モデルによるイベントの発生の予測精度を比較し、最も高い予測モデルを出力してもよい。患者状態分類部１０９は、そのときのクラスタ数を最適なクラスタ数として決定してもよい。あるいは、患者状態分類部１０９は、x-means法などのクラスタ数を自動的に最適化する方式を用いても良い（図示省略）。これによって、予測精度の高い予測モデルを構築することができる。

上記のステップ１３０３またはステップ１３０６が実行されると、次に、ステップ１３０７が実行される。ステップ１３０３の次にステップ１３０７が実行される（すなわちステップ１３０２においてイベント原因の情報が存在すると判定された）場合、患者状態分類部１０９は、各イベントレコードＩＤに対応するイベント原因を患者クラスタとして設定し、イベントレコードＩＤと、イベント値と、患者クラスタと、を対応づけて目的変数情報テーブル７００に格納する。一方で、ステップ１３０６の次にステップ１３０７が実行される（すなわちステップ１３０２においてイベント原因の情報が存在しないと判定された）場合、患者状態分類部１０９は、ステップ１３０６で分類したクラスタの情報を活用し、各イベントレコードＩＤに対応する患者ＩＤのクラスタリング結果を、各イベントレコードＩＤに対応する患者クラスタとして設定し、イベントレコードＩＤと、イベント値と、患者クラスタと、を対応づけて目的変数情報テーブル８００に格納する。

次に、ステップ１３０８において、患者状態分類部１０９は、イベント情報テーブル５００から、分析対象のイベントＩＤを有し、かつ、イベント値が「０」のレコードの患者ＩＤを全て抽出する。

次に、ステップ１３０９において、患者状態分類部１０９は、患者クラスタにＮｕｌｌを設定し、ステップ１３０８において抽出した各レコードについて、イベントレコードＩＤと、イベント値と、患者クラスタと、を対応づけて、目的変数情報テーブル７００又は目的変数情報テーブル８００に格納する。

なお、患者状態分類部１０９は、ステップ１３０３を実行して、イベント原因に対応するクラスタを生成した場合であっても、いずれかのクラスタに属する患者の数が所定の下限値より少ない場合には、クラスタ数を減らしてステップ１３０４からステップ１３０６を実行してもよい。前述した図９は、このようにして実行されたクラスタリングの結果の例を示す。また、患者状態分類部１０９は、ステップ１３０４からステップ１３０６を実行した結果、いずれかのクラスタに属する患者の数が所定の下限値より少ない場合にも、クラスタ数を減らして再度ステップ１３０４からステップ１３０６を実行することができる。

上記のように、原因情報を利用できる場合にはそれを利用することによって、原因に応じた適切なクラスタリングを行うことができる。また、原因情報を利用できない場合には、診療情報を利用してクラスタリングすることによって、傾向の似た患者の状態を同一クラスタに分類することができる。また、各クラスタに含まれる患者の数が所定の下限値以上に保たれるため、後述する予測モデルの構築の精度を確保することができる。

次に、ステップ１１０５において、制御部１０１は、目的変数ラベル生成部１１０を起動し、目的変数情報テーブル７００又は目的変数情報テーブル８００において、各患者クラスタにユニークな目的変数ラベルを作成し、各イベントレコードＩＤの各患者クラスタに対応する目的変数ラベルをフィールド７０４又は８０４に登録する（図示省略）。

次に、ステップ１１０６において、制御部１０１は、ステップ１１０２で受け付けた分析データ用患者の患者情報、検査情報及び処方情報などの診療情報と、目的変数情報テーブル７００又は目的変数情報テーブル８００の情報と、を活用し、ステップ１１０２で受け付けた予測モデルの作成方法に基づき、予測モデルの構築を行う。具体的には、予測モデル生成部１１１が、患者状態分類部１０９によって分類された患者の状態と、それぞれの患者の状態において予測対象のイベントが発生したか否かに基づいて、患者の状態から予測対象のイベントの発生を予測する予測モデルを構築する。上記のような作成方法による予測モデルの構築は公知であるため、その詳細な説明は省略する。

次に、ステップ１１０７において、制御部１０１は、ステップ１１０２で受け付けた分析対象患者に対して、ステップ１１０６で作成した予測モデルを適用し、分析対象患者の予測対象のイベントの発生確率と、各目的変数ラベルに該当する確率等を算出する。

次に、ステップ１１０８において、制御部１０１は、表示画面生成部１０５を起動し、ステップ１１０７で算出した、分析対象患者の予測対象のイベントの発生確率および各目的変数ラベルに該当する確率等に基づき、ユーザに提示する分析結果の提示画面を生成する。

次に、ステップ１１０９において、制御部１０１は、ステップ１１０８で生成された提示画面を出力部１０２に出力させる。

図１５は、本発明の実施例１の治療計画決定支援システム１００において、原因情報が存在する場合に表示画面生成部１０５が生成する分析結果の提示画面１５００の例を示す説明図である。

分析結果の提示画面１５００は、分析対象患者の予測対象のイベントの発生リスクを提示するイベント発生リスク提示エリア１５０１と、分析対象患者の予測対象のイベントの発生原因ごとの確率を提示するイベント発生原因確率提示エリア１５０２と、で構成される。

このように、イベント発生原因確率提示エリア１５０２に、各イベント発生原因確率が表示されることで、ユーザは、分析対象患者が、どのような原因で分析対象のイベントが発生するのかを容易に把握可能となり、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。

図１６は、本発明の実施例１の治療計画決定支援システム１００において、原因情報が存在しない場合に表示画面生成部１０５が生成する分析結果の提示画面１６００の例を示す説明図である。

分析結果の提示画面１６００は、分析対象患者の予測対象のイベントの発生リスクを提示するイベント発生リスク提示エリア１６０１と、分析対象患者が分類される患者クラスタ内の患者のうち類似する症例を提示する類似症例提示エリア１６０２と、クラスタリング結果の画面を表示する際に使用するクラスタリング結果表示ボタン１６０３と、で構成される。

このように、類似症例提示エリア１６０２に、分析対象患者が分類される患者クラスタ内の患者のうち類似する症例を提示することで、ユーザは、分析対象患者が、イベントを発生した場合にどのような患者と類似な状態であるかを把握することが可能となり、類似する患者を分析することで、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。ユーザは、クラスタ分析によって分析対象患者が分類された結果を参照する際に、クラスタリング結果表示ボタン１６０３を押下する。このときに提示される画面について図１７を参照して説明する。

図１７は、本発明の実施例１の治療計画決定支援システム１００において、クラスタリング結果表示ボタン１６０３が押下された場合に、表示画面生成部１０５が生成するクラスタリング結果の表示画面の例１７００を示す説明図である。

クラスタリング結果の表示画面１７００は、軸の選択エリア１７０１と、クラスタリング結果の表示エリア１７０２と、で構成される。ユーザは、まず、軸の選択エリア１７０１に表示されたプルダウンリストを操作することで、クラスタリング結果の表示エリア１７０２に表示するクラスタリング結果の縦軸と横軸を設定する。クラスタリング結果の表示エリア１７０２には、軸の選択エリア１７０１のプルダウンリストによって選択された縦軸と横軸に応じて、分析対象患者のクラスタリング結果が表示される。画面例１７００では、分析対象患者の症例を白抜きの丸印で示し、その他の患者の症例を黒い丸印で示している。この例では、分析対象患者が属するクラスタであるクラスタＡの内部において、分析対象患者と類似する症例として患者ＩＤが＃１と＃２０の症例が提示されている。このように、任意の軸でクラスタリング結果を表示することで、ユーザは分析対象患者と類似する症例がどの項目において類似していると判定されているかを分析することが可能となる。これによって、ユーザは、イベントが発生した場合にどのような患者と類似な状態であるかを把握し、類似する患者を分析することで、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。

また、ステップ１３０６におけるクラスタリングでは、ユーザに指定された因子または予めシステムに記憶された因子を可変因子として定義し、ステップ１１０６の予測モデルの構築において可変因子の重み係数などの重み付け値が最も高くなるクラスタ数を使用クラスタ数と定義し、クラスタリングを実施しても良い。ここで可変因子とは、治療行為によって変更可能な因子である。イベント発生リスクを予測する予測モデルにおいて、可変因子の重み係数が十分に高い場合、イベント発生リスクを低下させる方向にその可変因子を変更するための治療を行うことが可能になる。このようなクラスタリングの詳細について、図１８および図１９を参照して説明する。

図１８は、本発明の実施例１の治療計画決定支援システム１００が、予測モデル構築において可変因子の値が高くなるようにクラスタリングを実施する場合に、表示画面生成部１０５が生成するクラスタリング結果の画面の例１８００を示す説明図である。

クラスタリング結果の表示画面１８００は、軸の選択エリア１８０１と、可変因子の選択エリア１８０２と、可変因子による重み付けの実行ボタン１８０３と、クラスタリング結果の表示エリア１８０４と、で構成される。ユーザは、まず、軸の選択エリア１８０１に表示されたプルダウンリストを操作することで、クラスタリング結果の表示エリア１８０４に表示するクラスタリング結果の縦軸と横軸を設定する。クラスタリング結果の表示エリア１８０４には、軸の選択エリア１８０１のプルダウンリストによって選択された縦軸と横軸に応じて、分析対象患者のクラスタリング結果が表示される。画面例１８００では、縦軸にイベント発生リスク、横軸に因子Ｙが選択され、分析対象患者がクラスタＡに属する例が示されている。この例では、クラスタＡ内部において、分析対象患者よりもイベント発生リスクが低い症例は２症例しか存在せず、それらの症例の因子Ｙの値もほぼ変わらない。このような場合、因子Ｙが可変な因子、つまり治療によって改善可能な因子であったとしても、同一クラスタ内部の患者群を比較しただけでは、どの程度治療を実施すればイベント発生リスクがどの程度下がるのか、といった分析を行うことが困難である。

このような場合において、ユーザは、可変因子の選択エリア１８０２を操作することで可変因子を選択し、可変因子による重み付けの実行ボタン１８０３を押下する。予測モデル構築において選択された可変因子の重み係数が高くなるクラスタ数を最適クラスタ数としたクラスタリングを患者状態分類部１０９が実行する（ステップ１３０６）。

図１９は、本発明の実施例１の治療計画決定支援システム１００において、可変因子による重み付けを実行した後のクラスタリング結果の表示画面の例を示す説明図である。

すなわち、図１９は、ユーザが可変因子の選択エリア１８０２を操作することで可変因子を選択し、可変因子による重み付けの実行ボタン１８０３を押下した後のクラスタリング結果の表示画面１８００の例を示す。

図１９に示した表示画面１８００では、選択した因子の重み係数が高くなるクラスタ数を使用し、再度クラスタリングを実施した結果が示されている。この例において、分析対象患者はクラスタＡに属し、クラスタＡ内部において、分析対象患者よりイベント発生リスクが低い症例は、因子Ｙが低い傾向があることが分析可能である。このことから、分析対象患者の症例はクラスタＡの患者群に類似した状態でイベントを発生するリスクがあり、因子Ｙが低い症例ほどリスクが低いことから、因子Ｙを改善する治療を実施することでイベント発生のリスクを低減することができる可能性がある、という分析を行うことができる。

因子の重み付けにおいて、重み付けの度合いは、ユーザが指定してもよいし、予め記載された値を使用しても良いし、イベントの予測精度が最も高くなる値を使用するなどしてもよい。また、選択した因子の重み係数が高くなるクラスタ数を最適クラスタ数とする際に、一定の予測精度を保つために、イベントの予測精度が予め指定した閾値を超えることを条件として加えてもよい。

上記のような可変因子の重み付けは、例えば次のような手順で実行されてもよい。患者状態分類部１０９は、クラスタ数を変更しながら、複数回のクラスタリングを実行する（ステップ１３０４〜ステップ１３０６）。予測モデル生成部１１１は、複数回のクラスタリングの結果に基づいて、複数の予測モデルを生成する（ステップ１１０６）。ここで、予測モデル生成部１１１は、生成した複数の予測モデルに含まれる複数の因子について、予測対象イベントの発生リスクに対する重み係数を取得し、可変因子の重み係数がより大きい予測モデルを生成結果として出力する。

以上、本発明である治療計画決定支援システムによって、分析対象の事象が発生した患者について予測対象の事象の発生後の患者状態に基づく患者の分類を行い、分類に基づいて作成した目的変数を使用した予測モデルの構築を行う事で、分析対象患者の予測対象の事象の発生リスク等と分析対象患者が予測対象の事象の発生後にどの様な状態であるかを予測・推定し、その結果の可視化を実施することで、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。

例えば、上記の実施例の治療計画決定支援システム１００は、医療情報の分析を支援するためのデータ分析支援システムの一例であり、本発明は医療情報以外の情報の分析を支援するために使用することもできる。具体的には、例えば、データ分析支援システムは、複数の個体の履歴情報を保持し、履歴情報に基づいて複数の個体の状態を複数のクラスタに分類し、分類された個体の状態、および、各個体において所定のイベントが発生したか否かに基づいて、分類された個体の状態から所定のイベントの発生を予測する予測モデルを生成し、分析対象の個体の状態に予測モデルを適用することで当該分析対象の個体における所定のイベントの発生を予測してもよい。

ここで、個体とは、上記の実施例のような患者であってもよいし、例えば任意の種類の機器であってもよい。履歴情報とは、上記の実施例のような診療情報であってもよいし、例えば機器の種類、使用期間、保守履歴、故障履歴、検査履歴等を含んでもよい。所定のイベントは、上記の実施例のような所定の期間内の再入院等であってもよいし、所定の態様の故障の発生等であってもよい。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

また、図面には、実施例を説明するために必要と考えられる制御線及び情報線を示しており、必ずしも、本発明が適用された実際の製品に含まれる全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１００ 治療計画決定支援システム
１０１ 制御部
１０２ 出力部
１０３ メモリ
１０４ 通信部
１０５ 表示画面生成部
１０６ データ抽出部
１０７ 分析対象患者抽出部
１０８ イベントデータ生成部
１０９ 患者状態分類部
１１０ 目的変数ラベル生成部
１１１ 予測モデル生成部
１１２ 統合データベース
１１３ イベント情報格納データベース
１１４ 予測モデル格納データベース
１１９ 蓄積データ取得部
１２０ 病院情報システム
１２１ 診療情報データベース
１３０ 入出力端末
１４０ ネットワーク

Claims (15)

1. 複数の患者の状態に関する診療情報を保持する記憶部と、
   前記診療情報に基づいて、前記複数の患者の状態を複数のクラスタに分類する患者状態分類部と、
   前記分類された患者の状態、および、前記各患者において所定の事象が発生したか否かに基づいて、前記分類された患者の状態から前記所定の事象の発生を予測する予測モデルを生成する予測モデル生成部と、を有することを特徴とするデータ分析支援システム。
2. 請求項１に記載のデータ分析支援システムであって、
   前記記憶部は、前記所定の事象が発生した原因を示す情報さらに保持し、
   前記患者状態分類部は、前記所定の事象が同一の原因で発生した患者の状態が同一のクラスタに属するように分類することを特徴とするデータ分析支援システム。
3. 請求項１に記載のデータ分析支援システムであって、
   前記患者状態分類部は、前記複数の患者のうち前記所定の事象が発生した患者について、前記所定の事象が発生した時点を基準とする所定の期間の、前記診療情報に含まれる前記複数の患者の状態を示す値を対象とするクラスタ分析を実行することによって、前記複数の患者の状態を複数のクラスタに分類することを特徴とするデータ分析支援システム。
4. 請求項３に記載のデータ分析支援システムであって、
   前記患者状態分類部は、前記予測モデルを用いた前記所定の事象の発生の予測精度が最も高くなるように、分類されるクラスタ数を決定することを特徴とするデータ分析支援システム。
5. 請求項３に記載のデータ分析支援システムであって、
   前記患者状態分類部は、クラスタ数を変更しながら前記クラスタ分析を複数回実行し、
   前記予測モデル生成部は、
   複数回実行された前記クラスタ分析の結果のそれぞれについて前記予測モデルを生成し、
   生成されたそれぞれの予測モデルについて、前記事象の発生リスクに対する、前記診療情報に含まれる複数の因子の重み係数を取得し、
   前記診療情報に含まれる複数の因子のうち治療によって値を変更可能な因子の重み係数がより大きい予測モデルを出力することを特徴とするデータ分析支援システム。
6. 請求項１に記載のデータ分析支援システムであって、
   前記患者状態分類部は、いずれかのクラスタに分類された患者の数が所定の下限値より少ない場合、分類されるクラスタ数を減らして、前記複数の患者のうち前記所定の事象が発生した患者について、前記所定の事象が発生した時点を基準とする所定の期間の、前記診療情報に含まれる前記複数の患者の状態を示す値を対象とするクラスタ分析を実行することによって、前記複数の患者の状態を複数のクラスタに分類することを特徴とするデータ分析支援システム。
7. 請求項１に記載のデータ分析支援システムであって、
   前記診療情報から抽出された分析対象患者の状態に前記予測モデルを適用することによって、前記分析対象患者における前記所定の事象の発生を予測する制御部と、
   前記制御部による予測の結果を出力する出力部と、をさらに有することを特徴とするデータ分析支援システム。
8. 複数の個体の状態に関する履歴情報を保持する記憶部と、
   前記履歴情報に基づいて、前記複数の個体の状態を複数のクラスタに分類する個体状態分類部と、
   前記分類された個体の状態、および、前記各個体において所定の事象が発生したか否かに基づいて、前記分類された個体の状態から前記所定の事象の発生を予測する予測モデルを生成する予測モデル生成部と、を有することを特徴とするデータ分析支援システム。
9. プロセッサと、前記プロセッサに接続される記憶部と、を有する計算機システムが実行するデータ分析支援方法であって、
   前記記憶部は、複数の患者の状態に関する診療情報を保持し、
   前記データ分析支援方法は、
   前記プロセッサが、前記診療情報に基づいて、前記複数の患者の状態を複数のクラスタに分類する第１手順と、
   前記プロセッサが、前記分類された患者の状態、および、前記各患者において所定の事象が発生したか否かに基づいて、前記分類された患者の状態から前記所定の事象の発生を予測する予測モデルを生成する第２手順と、を含むことを特徴とするデータ分析支援方法。
10. 請求項９に記載のデータ分析支援方法であって、
    前記記憶部は、前記所定の事象が発生した原因を示す情報さらに保持し、
    前記第１手順において、前記プロセッサは、前記所定の事象が同一の原因で発生した患者の状態が同一のクラスタに属するように分類することを特徴とするデータ分析支援方法。
11. 請求項９に記載のデータ分析支援方法であって、
    前記第１手順において、前記プロセッサは、前記複数の患者のうち前記所定の事象が発生した患者について、前記所定の事象が発生した時点を基準とする所定の期間の、前記診療情報に含まれる前記複数の患者の状態を示す値を対象とするクラスタ分析を実行することによって、前記複数の患者の状態を複数のクラスタに分類することを特徴とするデータ分析支援方法。
12. 請求項１１に記載のデータ分析支援方法であって、
    前記第１手順において、前記プロセッサは、前記予測モデルを用いた前記所定の事象の発生の予測精度が最も高くなるように、分類されるクラスタ数を決定することを特徴とするデータ分析支援方法。
13. 請求項１１に記載のデータ分析支援方法であって、
    前記第１手順において、前記プロセッサは、クラスタ数を変更しながら前記クラスタ分析を複数回実行し、
    前記第２手順において、前記プロセッサは、
    複数回実行された前記クラスタ分析の結果のそれぞれについて前記予測モデルを生成し、
    生成されたそれぞれの予測モデルについて、前記事象の発生リスクに対する、前記診療情報に含まれる複数の因子の重み係数を取得し、
    前記診療情報に含まれる複数の因子のうち治療によって値を変更可能な因子の重み係数がより大きい予測モデルを出力することを特徴とするデータ分析支援方法。
14. 請求項９に記載のデータ分析支援方法であって、
    前記第１手順において、前記プロセッサは、いずれかのクラスタに分類された患者の数が所定の下限値より少ない場合、分類されるクラスタ数を減らして、前記複数の患者のうち前記所定の事象が発生した患者について、前記所定の事象が発生した時点を基準とする所定の期間の、前記診療情報に含まれる前記複数の患者の状態を示す値を対象とするクラスタ分析を実行することによって、前記複数の患者の状態を複数のクラスタに分類することを特徴とするデータ分析支援方法。
15. 請求項９に記載のデータ分析支援方法であって、
    前記プロセッサが、前記診療情報から抽出された分析対象患者の状態に前記予測モデルを適用することによって、前記分析対象患者における前記所定の事象の発生を予測する第３手順と、
    前記プロセッサが、前記予測の結果を出力する第４手順と、をさらに含むことを特徴とするデータ分析支援方法。

Images