以下、図面に基づいて、本発明の実施の形態を説明する。なお、本発明の実施形態は、後述する形態例に限定されるものではなく、その技術思想の範囲において、種々の変形が可能である。
≪構成≫
<システム構成の説明1>
図1は、本発明の実施例1の治療計画決定支援システム100の構成を示すブロック図である。
本実施例の治療計画決定支援システムは、治療計画決定支援システム100と、病院情報システム120と、入出力端末130と、ネットワーク140と、によって構成される計算機システムである。本実施例の治療計画決定支援システムは、蓄積されたデータから分析用データを作成し、作成した分析用データうち、分析対象の事象が発生した患者について予測対象の事象の発生後の患者状態に基づく患者の分類を行い、分類に基づいて作成した目的変数を使用した予測モデルの構築を行う事で、分析対象患者の予測対象の事象の発生リスク等と分析対象患者が予測対象の事象の発生後にどの様な状態であるかを予測・推定し、その結果を可視化して出力する。
本実施例では、入出力端末130は、キーボード、マウス、又はタッチパネルなどの入力部(図示省略)と、ディスプレイなどの出力部(図示省略)と、治療計画決定支援システム100などと通信する通信部(図示省略)と、を有する1つまたは複数のパーソナルコンピュータである。また、ボタンまたはタッチパネルなどの入力部と、ディスプレイなどの出力部と、治療計画決定支援システム100などと通信する通信部とを有するPDA、PHS、携帯電話、スマートフォン、タブレット端末、入力部を有するグラス型ディスプレイ又はヘッドマウントディスプレイなどのウェアラブルディスプレイ端末などの可搬型端末を入出力端末130として利用することもできる。
本実施例では、入出力端末130を、病院または診療所などの医療機関(ヘルスケアプロバイダ)に設置して利用する。一方、治療計画決定支援システム100がデータセンターに設置される。
このように、治療計画決定支援システム100をデータセンターに設置することで、患者の個人情報および患者から収集されるデータなどのプライバシー情報を一元管理できるので、情報漏洩防止等のセキュリティ管理を簡易化できる。この治療計画決定支援システム100は、運用の形態によってはヘルスケアプロバイダに設置して利用してもよい。
入出力端末130の利用者(以下ユーザと記載する)としては、医療機関の医師、分析担当者、薬剤師、管理者又は経営責任者を想定している。
ユーザは、入出力端末130を操作し、本実施例で示される情報システムを用いて、蓄積されたデータから分析用データを作成し、作成した分析用データうち、分析対象の事象が発生した患者について予測対象の事象の発生後の患者状態に基づく患者の分類を行う。そして、本実施例の情報システムは、分類に基づいて作成した目的変数を使用した予測モデルの構築を行う事で、分析対象患者の予測対象の事象の発生リスク等、および、分析対象患者が予測対象の事象の発生後にどの様な状態であるかを予測・推定し、その結果を可視化する。
治療計画決定支援システム100は、相互に接続された、制御部101、出力部102、メモリ103、通信部104、表示画面生成部105、データ抽出部106、分析対象患者抽出部107、イベントデータ生成部108、患者状態分類部109、目的変数ラベル生成部110、予測モデル生成部111、統合データベース112、イベント情報格納データベース113、予測モデル格納データベース114、および蓄積データ取得部119によって構成される。
蓄積データ取得部119は、ヘルスケアプロバイダに設置されている病院情報システム120に存在する診療情報データベース121に蓄積された患者情報、検査情報、処方情報、治療情報、などの患者に関する診療情報のデータを取得し、統合データベース112に格納する。
蓄積データ取得部119は、ユーザによって直接起動されてもよいし、ユーザが予め指定した時間、例えば毎週土曜の夜などに、自動的に起動してもよい。あるいは、診療情報データベース121、のデータが更新された時に、自動的に起動してもよい。
制御部101は、例えばメモリ103に格納されたプログラムを実行するプロセッサであり、治療計画決定支援システム100の各部を制御する。メモリ103は、例えばDRAM(Dynamic Random Access Memory)のような記憶装置であり、治療計画決定支援システム100の各部によって参照されるデータ(例えば制御部101によって実行されるプログラム等)を格納する。
統合データベース112は、メモリ103に格納されてもよいし、治療計画決定支援システム100内の別の記憶装置(例えばHDD(Hard Disk Drive)のような不揮発性記憶装置、図示省略)に格納されてもよい。
出力部102は、治療計画決定支援システム100による処理の結果を出力する装置であり、例えばディスプレイ装置であってもよい。
通信部104は、ネットワーク140に接続され、入出力端末130との通信を行う。
表示画面生成部105、データ抽出部106、分析対象患者抽出部107、イベントデータ生成部108、患者状態分類部109、目的変数ラベル生成部110、および予測モデル生成部111は、治療計画決定支援システム100の機能を実現するための処理を実行する処理部であり、それぞれが専用のハードウェアによって実現されてもよいし、ソフトウェアによって実現されてもよい。後者の場合、以下の説明において上記の各処理部が実行する処理は、実際には、制御部101がメモリ103に格納されたプログラムに記述された命令に従って実行する。上記の各処理部によって実行される処理の詳細については後述する。
制御部101が実行するプログラムは、リムーバブルメディア(CD−ROM、フラッシュメモリなど)又はネットワーク140を介して治療計画決定支援システム100に提供され、非一時的記憶媒体である不揮発性記憶装置に格納される。このため、治療計画決定支援システム100は、リムーバブルメディアからデータを読み込むインターフェース(図示省略)を有するとよい。
治療計画決定支援システム100は、物理的に一つの計算機上で、又は、論理的若しくは物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
病院情報システム120は、ネットワーク140に接続される計算機システムであり、例えば、治療計画決定支援システム100が有するものと同様の制御部、メモリ及び通信部(いずれも図示省略)等を有してもよい。診療情報データベース121は、病院情報システム120のメモリに格納されてもよいし、例えばHDD(Hard Disk Drive)のような、病院情報システム120内の別の記憶装置(図示省略)に格納されてもよい。
ネットワーク140には、治療計画決定支援システム100、病院情報システム120および入出力端末130が接続されている。治療計画決定支援システム100は、ネットワーク140を介して病院情報システム120および入出力端末130と通信する。
ネットワーク140は、LAN(Local Area Network)ケーブルによる有線通信、または無線LANなどによる無線通信を利用する。
また、ネットワーク140は、インターネット、VPN、携帯電話通信網、PHS通信網など、他の広域ネットワークを利用することもできる。
続いて、統合データベース112を構成するテーブル構造を説明する。
統合データベース112は、患者毎の基本情報等を管理する患者情報テーブル200、患者毎の検査情報を格納する検査情報テーブル300、および、患者毎の処方情報を格納する処方情報テーブル400で構成される。統合データベース112は、そのほかにも、患者毎の治療情報などの患者に関する診療情報を格納するテーブルを有しても良い(図示省略)。
図2は、本発明の実施例1の治療計画決定支援システム100が保持する患者情報テーブル200の例を示す説明図である。
患者情報テーブル200は、患者情報テーブル200内のレコードを識別するレコードIDを格納するフィールド201と、患者を識別する患者IDを格納するフィールド202と、患者の性別を格納するフィールド203と、患者が医療機関に入院した日時、または外来診断のために医療機関を訪問した日時における患者の年齢を格納するフィールド204と、患者が外来診断のために医療機関を訪問した場合にその診断年月日を格納するフィールド205と、患者が医療機関に入院した場合にその入院年月日を格納するフィールド206と、患者が医療機関に入院し、その後退院した場合にその退院年月日を格納するフィールド207と、患者の一つ以上の疾患名(病名)を格納する一つ以上のフィールド(図2の例では、病名1を格納するフィールド208、病名2を格納するフィールド209および病名3を格納するフィールド210)と、で構成される。
患者が医療機関に外来診断のために訪問した場合には、診断年月日を格納するフィールド205にはレコード毎の値が格納され、入院年月日および退院年月日を格納するフィールド206および207には「0」が格納される。一方、患者が医療機関に入院のために訪問した場合には、診断年月日を格納するフィールド205には「0」が格納され、入院年月日および退院年月日を格納するフィールド206および207にはレコード毎の値が格納される。
例えば、図2に示した患者情報テーブル200の患者情報レコードの例200Aは、患者ID「#1」で識別される患者に関する情報を含み、レコードID「1」で識別されるレコードであり、レコードの各フィールドの値は、性別「男」、年齢「68歳」、診断日「0」、入院年月日「2016/04/01」、退院年月日「2016/04/26」、病名1「心不全」、病名2「腎不全」、病名3は何も情報が登録されていない事を示す「NULL」である。これは、患者ID「#1」で識別される68歳の男性の患者が、心不全と腎不全のために2016年4月1日から2016年4月26日まで入院したことを示している。
なお、患者情報テーブル200には、4以上の病名を示す情報が含まれていてもよいし(図示省略)、病名の代わりにICD(International Classification of Diseases)コードなどの病名を示すコードが格納されても良い(図示省略)。
図3は、本発明の実施例1の治療計画決定支援システム100が保持する検査情報テーブル300の例を示す説明図である。
検査情報テーブル300は、患者に対して行われた検査に関する情報を格納するテーブルであり、患者IDを格納するフィールド301と、検査項目を識別する情報を格納するフィールド302と、検査日を格納するフィールド303と、検査結果(例えば検査値)を格納するフィールド304と、で構成される。
例えば、図3に示す検査情報テーブル300の例は、患者ID「#1」の患者において、検査項目「検査項目X」の値が、「2016/04/01」に「41」、「2016/04/07」に「62」、「2016/04/13」に「180」、「2016/04/15」に「220」、「2016/04/18」に「196」、「2016/04/25」に「120」であったことを示し、検査項目「検査項目Y」の値が、「2016/04/1」に「38」であったことを示している。
なお、上記のフィールド304に格納される検査値は、検査結果の一例であり、検査情報テーブル300は、検査値の代わりに(またはそれに加えて)、画像検査(例えばCT画像検査)のような、検査値以外の種類の検査結果を示す情報を含んでもよく、さらに、「吐き気」または「嘔吐」といった患者の自覚症状に関する情報を含んでもよい(図示省略)。
図4は、本発明の実施例1の治療計画決定支援システム100が保持する処方情報テーブル400の例を示す説明図である。
処方情報テーブル400は、患者に対して行われた薬剤の処方に関する情報を格納するテーブルであり、患者IDを格納するフィールド401と、薬剤を識別する情報(薬剤名)を格納するフィールド402と、各薬剤の処方開始日を格納するフィールド403と、各薬剤の処方終了日を格納するフィールド404と、で構成される。
例えば、図5に示した処方情報テーブル400の例は、患者ID「#1」の患者において、薬剤名「薬剤A」の薬剤が「2016/04/01」から「2016/04/07」までと、「2014/06/08」から「2016/04/14」までの期間に処方され、薬剤名「薬剤B」の薬剤がが「2016/04/03」から「2016/04/08」までの期間に処方され、薬剤名「薬剤D」の薬剤が「2016/04/16」から「2016/04/20」までの期間に処方されたことを示している。また、処方情報テーブル400は、各薬剤の処方の開始時間、終了時間、用法、用量、および薬効を示すコードの情報を格納するフィールドを有してもよい(図示省略)。
続いて、イベント情報格納データベース113を構成するテーブル構造を説明する。
イベント情報格納データベース113は、イベント情報テーブル500、イベント原因情報テーブル600、目的変数情報テーブル700〜900およびイベントマスタ情報テーブル1000によって構成される。イベント情報テーブル500は、予測対象の事象が特定の患者で発生したか否かなどの情報を格納する。イベント原因情報テーブル600は、予測対象の事象が発生した原因に関する情報を格納する。目的変数情報テーブル700は、予測対象の事象が発生した原因が存在する場合に患者状態分類部109の分類結果と目的変数ラベル生成部110が作成する目的変数ラベルを格納する。ここで、予測対象の事象が発生した原因が存在する場合とは、後述する図13のステップ1302において、イベントの発生原因に関連する情報が存在すると判定された場合である。目的変数情報テーブル800は、予測対象の事象が発生した原因が存在しない場合に患者状態分類部109の分類結果と目的変数ラベル生成部110が作成する目的変数ラベルを格納する。目的変数情報テーブル900は、複数の患者分類情報を有する場合に患者状態に患者状態分類部109の分類結果と目的変数ラベル生成部110が作成する目的変数ラベルを格納する。イベントマスタ情報テーブル1000は、イベントデータ生成部によって作成されたイベント情報の詳細と対応する予測モデルの情報を格納する。
図5は、本発明の実施例1の治療計画決定支援システム100が保持するイベント情報テーブル500の例を示す説明図である。
イベント情報テーブル500は、イベント情報テーブルの各レコードの識別子を格納するフィールド501と、各レコードに対応するイベント識別子を格納するフィールド502と、各レコードに対応する患者IDを格納するフィールド503と、各レコードに対応するイベント発生日を格納するフィールド504と、各レコードに対応するイベント値を格納するフィールド505と、で構成される。
各レコードに対応するイベントIDによって識別されるイベントが、各レコードに対応する患者IDによって識別される患者において発生した場合には、当該レコードのイベント値を格納するフィールド505に「1」が格納され、発生しなかった場合には「0」が格納される。
図6は、本発明の実施例1の治療計画決定支援システム100が保持するイベント原因情報テーブル600の例を示す説明図である。
イベント原因情報テーブル600は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド601と、各レコードに対応するイベントの発生原因を格納するフィールド602と、で構成される。
イベントの発生原因を格納するフィールドには、例えば、「高血圧コントロール不良」または「不整脈」など、各イベントレコードIDに対応するイベントが発生した原因が格納される。イベントの原因を示す数字または識別子などが格納されてもよい。
図7は、本発明の実施例1の治療計画決定支援システム100が保持する目的変数情報テーブル700の例を示す説明図である。
目的変数情報テーブル700は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド701と、各レコードに対応するイベント値を格納するフィールド702と、各レコードに対応する患者クラスタの値を格納するフィールド703と、各レコードに対応する目的変数ラベルの値を格納するフィールド704と、で構成される。
目的変数ラベルの値を格納するフィールドには、各患者クラスタに対応する値が格納される。例えば、患者クラスタの値として「高血圧コントロール不良」が格納されている場合、目的変数ラベルとして「A」の値が格納され、患者クラスタの値として「不整脈」が格納されている場合、目的変数ラベルとして「B」の値が格納される。また、イベント値として「0」が格納されている場合、患者クラスタとしてイベントが発生しなかった事を示す「Null」が格納され、目的変数ラベルとして「Z」が格納される。
図8は、本発明の実施例1の治療計画決定支援システム100が保持する目的変数情報テーブル800の例を示す説明図である。
目的変数情報テーブル800は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド801と、各レコードに対応するイベント値を格納するフィールド802と、各レコードに対応する患者クラスタの値を格納するフィールド803と、各レコードに対応する目的変数ラベルの値を格納するフィールド804と、で構成される。
目的変数ラベルの値を格納するフィールド804には、クラスタリング処理によって算出された各患者クラスタに対応する値が格納される。例えば、患者クラスタの値として「クラスタ1」が格納されている場合、目的変数ラベルとして「A」の値が格納され、患者クラスタの値として「クラスタ2」が格納されている場合、目的変数ラベルとして「B」の値が格納される。また、イベント値として「0」が格納されている場合、患者クラスタとしてイベントが発生しなかった事を示す「Null」が格納され、目的変数ラベルとして「Z」が格納される。
図9は、本発明の実施例1の治療計画決定支援システム100が保持する目的変数情報テーブル900の例を示す説明図である。
目的変数情報テーブル900は、イベント原因情報テーブルの各レコードの識別子を格納するフィールド901と、各レコードに対応するイベント値を格納するフィールド902と、各レコードに対応する患者クラスタ1の値を格納するフィールド903と、各レコードに対応する患者クラスタ2の値を格納するフィールド904と、各レコードに対応する目的変数ラベルの値を格納するフィールド905と、で構成される。
患者クラスタ1の値を格納するフィールド903には、原因情報に基づいた患者のクラスタリング結果が格納され、患者クラスタ2の値を格納するフィールド904には、クラスタリング処理によって算出された各患者クラスタに対応する値が格納される。
目的変数ラベルの値を格納するフィールド905には、患者クラスタ2に対応する値が格納される。例えば、患者クラスタ2の値として「クラスタ1’」が格納されている場合、目的変数ラベルとして「A’」の値が格納される。また、イベント値として「0」が格納されている場合、患者クラスタ1および患者クラスタ2としてイベントが発生しなかった事を示す「Null」が格納され、目的変数ラベルとして「Z」が格納される。
図10は、本発明の実施例1の治療計画決定支援システム100が保持するイベントマスタ情報テーブル1000の例を示す説明図である。
イベントマスタ情報テーブル1000は、各レコードに対応するイベント識別子を格納するフィールド1001と、イベント識別子と対応する予測モデルの作成時の条件1を格納するフィールド1002と、イベント識別子と対応する予測モデルの作成時の条件2を格納するフィールド1003と、各イベント識別子と対応する予測モデルの目的変数を格納するフィールド1004と、各イベント識別子と対応する予測モデルの識別子を格納するフィールド1005と、で構成される。イベントマスタ情報テーブル1000は、上記の例では、イベント識別子と対応する予測モデルの作成時の条件を二つ含んでいるが、三つ以上の条件を含んでもよい。(図示省略)。
次に本実施例のシステムの動作フローを、フローチャートを用いて説明する。
図11は、本発明の実施例1の治療計画決定支援システム100の動作を示すフローチャートである。
まず、制御部101は、ステップ(S)1101を実行し、統合データベース112から蓄積された患者データを呼び出す。ここでは、患者に関するデータ、例えば、患者を識別する情報、患者に対応する処方薬の情報、患者に対応する検査結果の情報等を総称して患者データと記載する。制御部101は、ステップ1101において、統合データベース112に含まれる全患者データを読み出し、メモリ103に記憶してもよい。
なお、このステップは、メモリ103に記憶されたプログラムに記述された命令に従って実行される。以下に説明する他のステップも同様である。
次に、制御部101は、ステップ1102を実行し、分析条件の受付画面を表示し、分析対象患者の情報および分析条件の情報を受け付ける。
図14は、本発明の実施例1の治療計画決定支援システム100が表示する分析条件受付用の画面の例を示す説明図である。
分析条件受付用の画面の例1400は、分析対象患者の選択エリア1401と、使用モデルの設定エリア1402と、分析データ用患者の指定条件エリア1403と、目的変数の設定エリア1404と、統計解析オプションの設定エアリア1405と、分析の実行ボタン1406と、で構成される。
ユーザは、分析対象患者の選択エリア1401内に表示された患者の中から、イベントの発生に関しての分析を行う患者を分析対象患者として選択する。
ユーザは、使用モデルの設定エリア1402に付随するラジオボタンを操作することで、「新たにモデルを作成」または「既存のモデル」のいずれかを選択する。前者が選択された場合、イベントの発生に関する予測モデルが新たに作成され、そのモデルがイベントの発生に関する分析に使用される。後者が選択された場合、過去の分析で作成されたか、又は予めデータとして格納されている既存のモデルが分析に使用される。
ユーザが「新たにモデルを作成」を選択した場合、分析データ用患者の指定条件エリア1403と、目的変数の設定エリア1404と、統計解析オプションの設定エアリア1405と、が表示される。ユーザは、分析データ用患者の指定条件エリア1403内のプルダウンリストを操作することで、新たなモデルの作成に使用する分析データ用患者の指定条件を設定する。図14の例では、条件1に「病名=心不全」、条件2に「年齢>=60歳」、が選択されている。これは、分析データ用患者として、心不全の病名を有し、年齢が60歳以上の患者が選択されることを示している。分析データ用患者の指定条件エリア1403には、3つ目以上の条件を選択するプルダウンリストが含まれていてもよい(図示省略)。
また、ユーザは、目的変数の設定エリア1404内のプルダウンリストを操作することで、新たなモデルの作成に使用する目的変数の設定を行う。図14の例では、条件1に「退院後30日以内の再入院」、が選択されている。これは、目的変数として、退院後30日以内の再入院が起きたか否かを示す情報が使用されることを示している。目的変数の設定エリア1404には、2つ目以上の条件を選択するプルダウンリストが含まれていてもよい(図示省略)。
ユーザが「既存のモデル」を選択した場合、制御部101は、イベントマスタ情報テーブル1000に格納されている過去に作成された予測モデルの条件および目的変数を読み出し、過去に作成されたモデルから使用するモデルをユーザに選択させるための画面を表示する(図示省略)。
また、ユーザは、統計解析オプションの設定エアリア1405内のプルダウンリストを操作することで、新たなモデルの作成に使用する統計手法の設定を行う。図14の例では、統計手法に「ロジスティック回帰」、変数選択に「AIC:100個」が選択されている。これは、Akaike’s Information Criterion(AIC)によって選択された100個の変数を活用し、ロジスティック回帰を用いて予測モデルの構築が行われることを示している。
統計解析オプションの設定エアリア1405では、例えば、「Support Vector Machine(SVM)」、「Deep−Learning」、「ニューラルネットワーク」、「ベイジアンネットワーク」、「決定木学習」および「ランダムフォレスト」など、他の機械学習の方式を提示し、それらのいずれかをユーザに選択させても良いし、上記の例のような複数の機械学習方式を選択させ、同時に複数の予測モデルを作成しても良いし、複数の機械学習の方式を組み合わせた予測モデルの作成方式(アンサンブル学習)を選択させてもよい(図示省略)。
また、目的変数の設定エリア1404の変数選択では、例えば、「ステップワイズ」、「相関分析」、「Maximum Information Coefficient」および「L1正則化」のいずれかなど、他の方式を選択しても良いし、上記の例のような複数の変数選択方式を選択し同時に複数の変数選択を実施する方式を選択しても良いし、複数の変数選択を複数回実施することで複数段階の変数選択を行う方式を選択してもよい(図示省略)。
ユーザが分析実行ボタン1406を選択すると、制御部101は、ステップ1103を実行し、イベントデータ生成部108を起動し、ステップ1102で受け付けた各種分析条件に基づき、ステップ1102で設定した分析データ用患者の設定情報と、目的変数の設定情報とを用いて、イベントデータを作成する。ステップ1103で実行される処理の詳細は図12を参照して説明する。
図12は、本発明の実施例1において、イベントデータ生成部108がイベントデータを生成する分析処理を実行する動作を示すフローチャートである。
ステップ1201において、イベントデータ生成部108は、患者情報テーブル200、をメモリ103上に読み出す。
次に、ステップ1202において、イベントデータ生成部108は、イベントレコードIDに「0」を設定する。
次に、ステップ1203において、イベントデータ生成部108は、メモリ103に読み出した患者情報テーブル200のレコードIDを全て取得し、いずれかのレコードIDについてイベントデータの生成処理を実行すると判定すると、次のステップ1204を実行する。具体的には、例えば、イベントデータ生成部108は、ステップ1203で取得したレコードIDに対応する患者情報テーブル200の全てのレコードのうち、イベントデータの生成処理(すなわちステップ1204以降の処理)がまだ行われていないレコードを対象として、イベントデータの生成処理を実行する。
ステップ1204において、イベントデータ生成部108は、ステップ1203でイベントデータの生成処理を実行すると判定したレコードIDの患者が、ステップ1102で受け付けた条件に合致するか否かを判定する。合致すると判定した場合、イベントデータ生成部108は、次のステップ1205を実行する。
ステップ1205において、イベントデータ生成部108は、イベント値として「0」を設定し、イベントレコードIDに「1」を加算する。
次に、ステップ1206において、イベントデータ生成部108は、イベント情報テーブル500に、ステップ1205の加算によって得られたイベントレコードIDと、イベントIDと、ステップ1203でイベントデータの生成処理を実行すると判定したレコードIDの患者IDと、イベント値とを紐づけて格納する。
次に、ステップ1207において、イベントデータ生成部108は、ステップ1102で受け付けた目的変数の情報と合致すると判定すると次のステップ1208を実行する。
次に、ステップ1208において、イベントデータ生成部108は、ステップ1206においてデータを格納したレコードのイベント値を1に設定し、目的変数との情報と合致した日付をイベント発生日として格納する。
例えば、図14に示すように、分析条件として条件1「病名=心不全」および条件2「年齢>=60歳」が選択され、かつ、目的変数として条件1「退院後30日以内の再入院」が選択された場合、イベントデータ生成部108は、患者情報テーブル200の各レコードが分析条件に合致するかどうかを判定し、合致するレコードについて、目的変数の条件が満たされるかどうかを判定する。
例えば、ステップ1203で、図2に示す患者情報テーブル200の先頭のレコード200Aが処理の対象として選択された場合、当該レコード200Aに対応する患者が60歳以上であり、対応する病名に心不全が含まれることから、ステップ1204において当該レコード200Aが分析条件に合致すると判定される。すると、ステップ1205において、イベント情報テーブル500に、当該レコード200Aに対応する新たなレコード(例えばレコード500A)が追加される。この時点で、当該レコード500AのイベントIDのフィールド502には目的変数として設定された条件に相当するイベント(上記の例では条件1「退院後30日以内の再入院」)を識別するイベントID(例えば「イベント1」)が設定され、イベント値のフィールド505には「0」が設定される。さらに、ステップ1206において、当該レコード500Aの患者IDのフィールド503にはレコード200Aの患者IDと同じ値が設定される。
その後、ステップ1207では、当該レコード200Aが目的変数の設定条件に合致しているかが判定される。図2の例では、レコード200Aの患者が2016年4月26日に退院した後、2016年5月18日に再入院している(レコード200B)。すなわち、条件1「退院後30日以内の再入院」が満たされるため(ステップ1207:Yes)、レコード500Aのイベント値のフィールド505が「1」に変更され(ステップ1208)、当該再入院の日付がイベント発生日のフィールド504に登録される。この例では、「2016年5月18日に再入院した」というイベントが、後述する図13の処理において分析対象のイベントとして扱われる。
仮に当該患者が2016年5月26日までに再入院していなければ、条件1「退院後30日以内の再入院」が満たされないため(ステップ1207:No)、ステップ1208が実行されずに処理はステップ1203に戻り、レコード500Aのイベント値のフィールド505は「0」のままとなる。
ステップ1208が終了すると処理はステップ1203に戻り、取得された全てのレコードについて処理が終了するまで、ステップ1204以降の処理が繰り返し実行される。取得された全てのレコードについてイベントデータの生成処理が終了した場合、図12の処理が終了してステップ1104以降の処理が実行される。
ステップ1104において、制御部101は、患者状態分類部109を起動し、イベントの発生原因、またはイベント発生後の患者状態、に基づく患者の分類を行う。ステップ1104で実行される処理の詳細は図13を参照して説明する。
図13は、本発明の実施例1において、患者状態分類部109が患者状態を分類する分析処理を実行する動作を示すフローチャートである。
ステップ1301において、患者状態分類部109は、ステップ1103で作成したイベント情報テーブル500をメモリ103上に読み出す。
次に、ステップ1302において、患者状態分類部109は、イベントの発生原因に関連する情報が診療情報データベース121または統合データベース112に存在するか否かを検証し、イベントの発生原因に関連する情報が存在すると判定した場合にはステップ1303を実行する。
次に、ステップ1303において、患者状態分類部109は、イベントの発生原因に関連する情報をメモリ103上に読み出し、イベント情報テーブル500のイベントレコードIDと読み出したイベントの発生原因とを対応づけて格納する。その後、患者状態分類部109は、後述するステップ1304からステップ1306を実行せずに、ステップ1307を実行する。
一方で、イベントの発生原因に関連する情報が存在しないと判定した場合には、患者状態分類部109はステップ1303を実行せずにステップ1304を実行する。
次に、ステップ1304において、患者状態分類部109は、イベント情報テーブル500から、分析対象のイベントIDを有し、かつ、イベント値が「1」のレコードの患者IDを全て抽出する。
次に、ステップ1305において、患者状態分類部109は、ステップ1304で抽出した患者IDと対応する患者に関する、分析対象のイベントが発生した直後の診療情報を抽出する。ここで、分析対象のイベントが発生した直後とは、分析対象のイベントが発生した時点を基準とする所定の期間の一例であり、例えば、分析対象のイベントが発生してから所定の時間が経過するまでの期間である。また、ここで抽出される診療情報は、ステップ1304で抽出した患者IDによって識別される患者の状態を示す情報であり、患者情報テーブル200、検査情報テーブル300および処方情報テーブル400の少なくともいずれかから抽出された当該患者に関する値を含んでもよい。
次に、ステップ1306において、患者状態分類部109は、ステップ1305で抽出した診療情報に含まれる値を対象とするクラスタ分析などのクラスタリング処理を実施し、ステップ1304で抽出した患者IDの患者群を複数のクラスタに分類する。クラスタリング処理において、クラスタ数は予めユーザが指定した値を使用しても良いし、予めユーザが指定した値を上限クラスタ数として最もイベントの予測精度が高くなるクラスタを網羅的に探索しても良いし。例えば、患者状態分類部109は、クラスタ数を変更しながら複数回のクラスタリングを実行してもよい。予測モデル生成部111は、複数回のクラスタリングの結果に基づいて複数の予測モデルを生成し(後述するステップ1106)、それぞれの予測モデルによるイベントの発生の予測精度を比較し、最も高い予測モデルを出力してもよい。患者状態分類部109は、そのときのクラスタ数を最適なクラスタ数として決定してもよい。あるいは、患者状態分類部109は、x-means法などのクラスタ数を自動的に最適化する方式を用いても良い(図示省略)。これによって、予測精度の高い予測モデルを構築することができる。
上記のステップ1303またはステップ1306が実行されると、次に、ステップ1307が実行される。ステップ1303の次にステップ1307が実行される(すなわちステップ1302においてイベント原因の情報が存在すると判定された)場合、患者状態分類部109は、各イベントレコードIDに対応するイベント原因を患者クラスタとして設定し、イベントレコードIDと、イベント値と、患者クラスタと、を対応づけて目的変数情報テーブル700に格納する。一方で、ステップ1306の次にステップ1307が実行される(すなわちステップ1302においてイベント原因の情報が存在しないと判定された)場合、患者状態分類部109は、ステップ1306で分類したクラスタの情報を活用し、各イベントレコードIDに対応する患者IDのクラスタリング結果を、各イベントレコードIDに対応する患者クラスタとして設定し、イベントレコードIDと、イベント値と、患者クラスタと、を対応づけて目的変数情報テーブル800に格納する。
次に、ステップ1308において、患者状態分類部109は、イベント情報テーブル500から、分析対象のイベントIDを有し、かつ、イベント値が「0」のレコードの患者IDを全て抽出する。
次に、ステップ1309において、患者状態分類部109は、患者クラスタにNullを設定し、ステップ1308において抽出した各レコードについて、イベントレコードIDと、イベント値と、患者クラスタと、を対応づけて、目的変数情報テーブル700又は目的変数情報テーブル800に格納する。
なお、患者状態分類部109は、ステップ1303を実行して、イベント原因に対応するクラスタを生成した場合であっても、いずれかのクラスタに属する患者の数が所定の下限値より少ない場合には、クラスタ数を減らしてステップ1304からステップ1306を実行してもよい。前述した図9は、このようにして実行されたクラスタリングの結果の例を示す。また、患者状態分類部109は、ステップ1304からステップ1306を実行した結果、いずれかのクラスタに属する患者の数が所定の下限値より少ない場合にも、クラスタ数を減らして再度ステップ1304からステップ1306を実行することができる。
上記のように、原因情報を利用できる場合にはそれを利用することによって、原因に応じた適切なクラスタリングを行うことができる。また、原因情報を利用できない場合には、診療情報を利用してクラスタリングすることによって、傾向の似た患者の状態を同一クラスタに分類することができる。また、各クラスタに含まれる患者の数が所定の下限値以上に保たれるため、後述する予測モデルの構築の精度を確保することができる。
次に、ステップ1105において、制御部101は、目的変数ラベル生成部110を起動し、目的変数情報テーブル700又は目的変数情報テーブル800において、各患者クラスタにユニークな目的変数ラベルを作成し、各イベントレコードIDの各患者クラスタに対応する目的変数ラベルをフィールド704又は804に登録する(図示省略)。
次に、ステップ1106において、制御部101は、ステップ1102で受け付けた分析データ用患者の患者情報、検査情報及び処方情報などの診療情報と、目的変数情報テーブル700又は目的変数情報テーブル800の情報と、を活用し、ステップ1102で受け付けた予測モデルの作成方法に基づき、予測モデルの構築を行う。具体的には、予測モデル生成部111が、患者状態分類部109によって分類された患者の状態と、それぞれの患者の状態において予測対象のイベントが発生したか否かに基づいて、患者の状態から予測対象のイベントの発生を予測する予測モデルを構築する。上記のような作成方法による予測モデルの構築は公知であるため、その詳細な説明は省略する。
次に、ステップ1107において、制御部101は、ステップ1102で受け付けた分析対象患者に対して、ステップ1106で作成した予測モデルを適用し、分析対象患者の予測対象のイベントの発生確率と、各目的変数ラベルに該当する確率等を算出する。
次に、ステップ1108において、制御部101は、表示画面生成部105を起動し、ステップ1107で算出した、分析対象患者の予測対象のイベントの発生確率および各目的変数ラベルに該当する確率等に基づき、ユーザに提示する分析結果の提示画面を生成する。
次に、ステップ1109において、制御部101は、ステップ1108で生成された提示画面を出力部102に出力させる。
図15は、本発明の実施例1の治療計画決定支援システム100において、原因情報が存在する場合に表示画面生成部105が生成する分析結果の提示画面1500の例を示す説明図である。
分析結果の提示画面1500は、分析対象患者の予測対象のイベントの発生リスクを提示するイベント発生リスク提示エリア1501と、分析対象患者の予測対象のイベントの発生原因ごとの確率を提示するイベント発生原因確率提示エリア1502と、で構成される。
このように、イベント発生原因確率提示エリア1502に、各イベント発生原因確率が表示されることで、ユーザは、分析対象患者が、どのような原因で分析対象のイベントが発生するのかを容易に把握可能となり、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。
図16は、本発明の実施例1の治療計画決定支援システム100において、原因情報が存在しない場合に表示画面生成部105が生成する分析結果の提示画面1600の例を示す説明図である。
分析結果の提示画面1600は、分析対象患者の予測対象のイベントの発生リスクを提示するイベント発生リスク提示エリア1601と、分析対象患者が分類される患者クラスタ内の患者のうち類似する症例を提示する類似症例提示エリア1602と、クラスタリング結果の画面を表示する際に使用するクラスタリング結果表示ボタン1603と、で構成される。
このように、類似症例提示エリア1602に、分析対象患者が分類される患者クラスタ内の患者のうち類似する症例を提示することで、ユーザは、分析対象患者が、イベントを発生した場合にどのような患者と類似な状態であるかを把握することが可能となり、類似する患者を分析することで、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。ユーザは、クラスタ分析によって分析対象患者が分類された結果を参照する際に、クラスタリング結果表示ボタン1603を押下する。このときに提示される画面について図17を参照して説明する。
図17は、本発明の実施例1の治療計画決定支援システム100において、クラスタリング結果表示ボタン1603が押下された場合に、表示画面生成部105が生成するクラスタリング結果の表示画面の例1700を示す説明図である。
クラスタリング結果の表示画面1700は、軸の選択エリア1701と、クラスタリング結果の表示エリア1702と、で構成される。ユーザは、まず、軸の選択エリア1701に表示されたプルダウンリストを操作することで、クラスタリング結果の表示エリア1702に表示するクラスタリング結果の縦軸と横軸を設定する。クラスタリング結果の表示エリア1702には、軸の選択エリア1701のプルダウンリストによって選択された縦軸と横軸に応じて、分析対象患者のクラスタリング結果が表示される。画面例1700では、分析対象患者の症例を白抜きの丸印で示し、その他の患者の症例を黒い丸印で示している。この例では、分析対象患者が属するクラスタであるクラスタAの内部において、分析対象患者と類似する症例として患者IDが#1と#20の症例が提示されている。このように、任意の軸でクラスタリング結果を表示することで、ユーザは分析対象患者と類似する症例がどの項目において類似していると判定されているかを分析することが可能となる。これによって、ユーザは、イベントが発生した場合にどのような患者と類似な状態であるかを把握し、類似する患者を分析することで、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。
また、ステップ1306におけるクラスタリングでは、ユーザに指定された因子または予めシステムに記憶された因子を可変因子として定義し、ステップ1106の予測モデルの構築において可変因子の重み係数などの重み付け値が最も高くなるクラスタ数を使用クラスタ数と定義し、クラスタリングを実施しても良い。ここで可変因子とは、治療行為によって変更可能な因子である。イベント発生リスクを予測する予測モデルにおいて、可変因子の重み係数が十分に高い場合、イベント発生リスクを低下させる方向にその可変因子を変更するための治療を行うことが可能になる。このようなクラスタリングの詳細について、図18および図19を参照して説明する。
図18は、本発明の実施例1の治療計画決定支援システム100が、予測モデル構築において可変因子の値が高くなるようにクラスタリングを実施する場合に、表示画面生成部105が生成するクラスタリング結果の画面の例1800を示す説明図である。
クラスタリング結果の表示画面1800は、軸の選択エリア1801と、可変因子の選択エリア1802と、可変因子による重み付けの実行ボタン1803と、クラスタリング結果の表示エリア1804と、で構成される。ユーザは、まず、軸の選択エリア1801に表示されたプルダウンリストを操作することで、クラスタリング結果の表示エリア1804に表示するクラスタリング結果の縦軸と横軸を設定する。クラスタリング結果の表示エリア1804には、軸の選択エリア1801のプルダウンリストによって選択された縦軸と横軸に応じて、分析対象患者のクラスタリング結果が表示される。画面例1800では、縦軸にイベント発生リスク、横軸に因子Yが選択され、分析対象患者がクラスタAに属する例が示されている。この例では、クラスタA内部において、分析対象患者よりもイベント発生リスクが低い症例は2症例しか存在せず、それらの症例の因子Yの値もほぼ変わらない。このような場合、因子Yが可変な因子、つまり治療によって改善可能な因子であったとしても、同一クラスタ内部の患者群を比較しただけでは、どの程度治療を実施すればイベント発生リスクがどの程度下がるのか、といった分析を行うことが困難である。
このような場合において、ユーザは、可変因子の選択エリア1802を操作することで可変因子を選択し、可変因子による重み付けの実行ボタン1803を押下する。予測モデル構築において選択された可変因子の重み係数が高くなるクラスタ数を最適クラスタ数としたクラスタリングを患者状態分類部109が実行する(ステップ1306)。
図19は、本発明の実施例1の治療計画決定支援システム100において、可変因子による重み付けを実行した後のクラスタリング結果の表示画面の例を示す説明図である。
すなわち、図19は、ユーザが可変因子の選択エリア1802を操作することで可変因子を選択し、可変因子による重み付けの実行ボタン1803を押下した後のクラスタリング結果の表示画面1800の例を示す。
図19に示した表示画面1800では、選択した因子の重み係数が高くなるクラスタ数を使用し、再度クラスタリングを実施した結果が示されている。この例において、分析対象患者はクラスタAに属し、クラスタA内部において、分析対象患者よりイベント発生リスクが低い症例は、因子Yが低い傾向があることが分析可能である。このことから、分析対象患者の症例はクラスタAの患者群に類似した状態でイベントを発生するリスクがあり、因子Yが低い症例ほどリスクが低いことから、因子Yを改善する治療を実施することでイベント発生のリスクを低減することができる可能性がある、という分析を行うことができる。
因子の重み付けにおいて、重み付けの度合いは、ユーザが指定してもよいし、予め記載された値を使用しても良いし、イベントの予測精度が最も高くなる値を使用するなどしてもよい。また、選択した因子の重み係数が高くなるクラスタ数を最適クラスタ数とする際に、一定の予測精度を保つために、イベントの予測精度が予め指定した閾値を超えることを条件として加えてもよい。
上記のような可変因子の重み付けは、例えば次のような手順で実行されてもよい。患者状態分類部109は、クラスタ数を変更しながら、複数回のクラスタリングを実行する(ステップ1304〜ステップ1306)。予測モデル生成部111は、複数回のクラスタリングの結果に基づいて、複数の予測モデルを生成する(ステップ1106)。ここで、予測モデル生成部111は、生成した複数の予測モデルに含まれる複数の因子について、予測対象イベントの発生リスクに対する重み係数を取得し、可変因子の重み係数がより大きい予測モデルを生成結果として出力する。
以上、本発明である治療計画決定支援システムによって、分析対象の事象が発生した患者について予測対象の事象の発生後の患者状態に基づく患者の分類を行い、分類に基づいて作成した目的変数を使用した予測モデルの構築を行う事で、分析対象患者の予測対象の事象の発生リスク等と分析対象患者が予測対象の事象の発生後にどの様な状態であるかを予測・推定し、その結果の可視化を実施することで、イベントの発生を予防するために適切な治療計画を決定する、適切な退院判断を行う、などが可能となる。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。
例えば、上記の実施例の治療計画決定支援システム100は、医療情報の分析を支援するためのデータ分析支援システムの一例であり、本発明は医療情報以外の情報の分析を支援するために使用することもできる。具体的には、例えば、データ分析支援システムは、複数の個体の履歴情報を保持し、履歴情報に基づいて複数の個体の状態を複数のクラスタに分類し、分類された個体の状態、および、各個体において所定のイベントが発生したか否かに基づいて、分類された個体の状態から所定のイベントの発生を予測する予測モデルを生成し、分析対象の個体の状態に予測モデルを適用することで当該分析対象の個体における所定のイベントの発生を予測してもよい。
ここで、個体とは、上記の実施例のような患者であってもよいし、例えば任意の種類の機器であってもよい。履歴情報とは、上記の実施例のような診療情報であってもよいし、例えば機器の種類、使用期間、保守履歴、故障履歴、検査履歴等を含んでもよい。所定のイベントは、上記の実施例のような所定の期間内の再入院等であってもよいし、所定の態様の故障の発生等であってもよい。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスクドライブ、SSD(Solid State Drive)等の記憶装置、または、ICカード、SDカード、DVD等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
また、図面には、実施例を説明するために必要と考えられる制御線及び情報線を示しており、必ずしも、本発明が適用された実際の製品に含まれる全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。