JP7122279B2 - 医療機関選定サーバ及び医療機関選定方法 - Google Patents

Description

本発明は、医療機関選定サーバ及び医療機関選定方法に関する。

本技術分野の背景技術として、特開２０１１－４８７７５号公報（特許文献１）がある。この公報には、「救急病院選択システム１において、車両端末２は、緊急車両に搭載され、管理サーバ３から救急現場から向かうべき病院の識別情報を取得し、表示する。管理サーバ３は、所定の地域を管轄する統括センタに設置され、車両端末２から病院の問合せがあったときに、病院サーバ４に各病院の対応時間（救急患者の対応が可能になるまでの時間）の問合せを行い、救急現場と、各病院との間の距離等から求めた移動時間を考慮しながら、最適な病院を選択し、車両端末２に通知する。病院サーバ４は、管轄地域にある病院ごとに設置され、管理サーバ３と通信することにより、管理サーバ３から対応時間の問合せがあったときに、医師や手術室等の状況から現時点における対応時間を計算し、通知する。管理サーバ３と、各病院サーバ４とは、例えば、ＷＡＮ等のネットワーク５を介して通信可能に構成される。」と記載されている（要約参照）。

特開２０１１－４８７７５号公報

緊急搬送前の患者の状態によって患者に必要な処置は異なり、また、医療機関によってこれらの処置が可能であるかは異なる。さらに、これらの処置が可能な医療機関であっても、処置行うためのリソースの状況によって、患者に対して処置を開始することができる時間が異なる。そこで、本発明の一態様は、前述した事情を考慮することによって、患者に対する治療を開始するまでの時間をより正確に予測し、ひいては患者に対してより早く処置を行うことができる医療機関を選定可能になることを目的とする。

上記課題を解決するため、本発明の一態様は以下の構成を採用する。患者を搬送する医療機関を選定する医療機関選定サーバであって、プロセッサとメモリとを備え、前記メモリは、前記患者に対して実行される１以上のプロセスからなるフローを、前記患者の状態情報から予測するフロー予測モデルと、実行可能なフローに含まれる各プロセスを実行するためのリソースの状況、を医療機関ごとに示す医療機関情報と、を保持し、前記プロセッサは、前記患者の状態情報を取得し、前記取得した患者の状態情報と前記フロー予測モデルとに基づいて、前記患者に対して実行されるフローを予測し、前記医療機関情報を参照して、各医療機関における、前記予測したフローに含まれる各プロセスを実行するためのリソースの状況を取得し、前記取得したリソースの状況に基づいて、前記患者を搬送する医療機関候補を選定し、前記選定した医療機関候補の情報を出力する、医療機関選定サーバ。

本発明の一態様によれば、患者に対する治療を開始するまでの時間をより正確に予測することができ、ひいては患者に対してより早く処置を行うことができる医療機関を選定可能になる。

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

実施例１における病院選定システムの構成例を示すブロック図である。 実施例１における対応可否テーブルの一例である。 実施例１における診療フローテーブルの一例である。 実施例１におけるリソース状況テーブルの一例である。 実施例１における患者分類履歴テーブルの一例である。 実施例１における緊急搬送履歴テーブルの一例である。 実施例１における受入照会所要時間履歴テーブルの一例である。 実施例１における病院選定処理の一例を示すフローチャートである。 実施例１における患者分類予測モデルによる患者分類の一例である。 実施例１における、各病院の各患者分類の治療開始可能時刻の一例である。 実施例１における、各病院において当該患者に対応不可である確率、及び各病院における治療開始可能時刻の期待値の一例である。 実施例１における、各患者分類の治療開始可能時刻の予測処理の一例を示すフローチャートである。 実施例１における治療開始可能時刻の算出処理の一例を示すフローチャートである。 実施例１におけるプロセスの実行時間の一例を示す説明図である。 実施例１における、患者の搬送終了時刻の推定処理の一例を示すフローチャートである。 実施例１において、端末に表示される入力画面の一例である。 実施例１において、端末に表示される出力画面の一例である。 実施例１において、端末に表示される出力画面の一例である。

以下、本発明の実施形態を図面に基づいて詳細に説明する。本実施形態において、同一の構成には原則として同一の符号を付け、繰り返しの説明は省略する。なお、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。

本実施形態は救急時に患者を搬送する病院を選定する病院選定システムについて説明する。なお、病院は医療機関の一例であり、病院以外の医療機関に患者が搬送されてもよい。また、本実施形態では、脳卒中の患者を搬送する例について説明するが、後述する診療フローのプロセス、及び患者分類を決定するためのモデル等を適宜変更することにより脳卒中以外の傷病の患者を搬送するケースにも適用できることは明らかである。また、本実施形態は、緊急車両を用いて患者を搬送する例を説明するが、車両に限らず、船舶や航空機等の他の輸送機器を用いて患者を搬送するケースにも適用できることは明らかである。

図１は、病院選定システムの構成例を示すブロック図である。病院選定システムは、例えば、インターネット等のネットワーク３００で接続された病院選定サーバ１００及び端末２００を含む。病院選定サーバ１００は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、メモリ１０２、補助記憶装置１０３、及び通信装置１０４を有する計算機によって構成される。

ＣＰＵ１０１は、プロセッサを含み、メモリ１０２に格納されたプログラムを実行する。メモリ１０２は、不揮発性の記憶素子であるＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及び揮発性の記憶素子であるＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ））などを格納する。ＲＡＭは、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような高速かつ揮発性の記憶素子であり、ＣＰＵ１０１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。

補助記憶装置１０３は、例えば、磁気記憶装置（ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ））、フラッシュメモリ（ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ））等の大容量かつ不揮発性の記憶装置であり、ＣＰＵ１０１が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。すなわち、プログラムは、補助記憶装置１０３から読み出されて、メモリ１０２にロードされて、ＣＰＵ１０１によって実行される。

病院選定サーバ１００は、入力インターフェース１０５及び出力インターフェース１０８を有してもよい。入力インターフェース１０５は、キーボード１０６やマウス１０７などの入力装置が接続され、オペレータからの入力を受けるインターフェースである。出力インターフェース１０８は、表示装置１０９やプリンタなどの表示装置が接続され、プログラムの実行結果をオペレータが視認可能な形式で出力するインターフェースである。

通信装置１０４は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。また、通信装置１０４は、例えば、ＵＳＢ等のシリアルインターフェースを含む。

ＣＰＵ１０１が実行するプログラムは、リムーバブルメディア（ＣＤ－ＲＯＭ、フラッシュメモリなど）又はネットワーク３００を介して病院選定サーバ１００に提供され、非一時的記憶媒体である不揮発性の補助記憶装置１０３に格納される。このため、病院選定サーバ１００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

病院選定サーバ１００は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。端末２００についても同様である。

ＣＰＵ１０１は、例えば、患者分類予測部１１１、治療開始可能時刻予測部１１２、予測結果統合処理部１１３、病院候補選定部１１４、及び搬送時間推定部１１５を含む。患者分類予測部１１１は、例えば、入力された患者情報と、後述する患者分類予測モデル１２１と、を用いて、患者が該当する患者分類を予測する。治療開始可能時刻予測部１１２は、患者の治療を開始することができる時刻を予測する。

予測結果統合処理部１１３は、患者が該当する複数の患者分類に該当する可能性がある場合等に複数の患者分類に対する予測結果を統合する。病院候補選定部１１４は、例えば、治療開始可能時刻や患者分類に対応できる確率等に基づいて、病院候補を選定する。搬送時間推定部１１５は、緊急車両によって患者を病院に搬送するまでの時間を推定する。

例えば、ＣＰＵ１０１は、メモリ１０２にロードされた患者分類予測プログラムに従って動作することで、患者分類予測部１１１として機能し、メモリ１０２にロードされた治療開始可能時刻予測プログラムに従って動作することで、治療開始可能時刻予測部１１２として機能する。ＣＰＵ１０１に含まれる他の機能部についても、プログラムと機能部の関係は同様である。また、端末２００が有するＣＰＵ２０１に含まれる後述する機能部についても、プログラムと機能部の関係は同様である。

なお、ＣＰＵ１０１及びＣＰＵ２０１に含まれる機能部による機能の一部又は全部が、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のハードウェアによって実現されてもよい。

補助記憶装置１０３は、例えば、患者分類予測モデル１２１、対応可否テーブル１２２、診療フローテーブル１２３、リソース状況テーブル１２４、緊急車両移動時間予測モデル１２５、患者分類履歴テーブル１２６、緊急搬送履歴テーブル１２７、及び受入照会所要時間履歴テーブル１２８を保持する。なお、補助記憶装置１０３に格納されている一部又は全部の情報は、メモリ１０２に格納されていてもよいし、病院選定サーバ１００に接続されているデータベースに格納されていてもよい。

患者分類予測モデル１２１は、患者の状態情報（例えば患者の症状、既往歴、又は救急隊員等による聴取情報等）から、患者分類を予測するモデルである。対応可否テーブル１２２は、各病院における各患者分類の患者の対応可否と、対応可能である場合には患者に対して実行される診療フローと、を示す。診療フローは１以上のプロセスからなる。以下、診療フローを単にフローとも呼ぶ。

診療フローテーブル１２３は、フローに含まれるプロセスの情報を保持する。リソース状況テーブル１２４は、各フローのプロセスを実行するために必要なリソースの状況を示す。緊急車両移動時間予測モデル１２５は、例えば、時間帯、曜日、並びに経路情報及び／又は渋滞情報に基づく移動時間等から、緊急車両の移動時間を予測するモデルである。患者分類履歴テーブル１２６は、例えば、患者の状態情報と患者分類の履歴を示し、患者分類予測モデル１２１の生成に用いられる。

緊急搬送履歴テーブル１２７は、例えば、時間帯、曜日、並びに経路情報及び／又は渋滞情報に基づく移動時間と、緊急車両の移動時間と、の履歴を示し、緊急車両移動時間予測モデル１２５の生成に用いられる。受入照会所要時間履歴テーブル１２８は、各病院への受入照会にかかった時間の履歴を示す。

なお、本実施形態において、病院選定システムが使用する情報は、データ構造に依存せずどのようなデータ構造で表現されていてもよい。本実施形態ではテーブル形式で情報が表現されているが、例えば、リスト、データベース又はキューから適切に選択したデータ構造体が、情報を格納することができる。

端末２００は、例えば、ＣＰＵ２０１、メモリ２０２、補助記憶装置２０３、通信装置２０４、入力装置２０５、表示装置２０６、及びＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信装置２０７を有する計算機によって構成される。端末２００は、例えば、救急隊員が携帯するタブレット端末、又は救急車に備え付けられたＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等である。

ＣＰＵ２０１、メモリ２０２、補助記憶装置２０３、及び通信装置２０４のハードウェアとしての説明は、ＣＰＵ１０１、メモリ１０２、補助記憶装置１０３、及び通信装置１０４の説明と同様であるため省略する。

ＣＰＵ２０１は、例えば、患者状態情報入力送信部２１１及び病院候補表示部２１２を含む。患者状態情報入力送信部２１１は、患者の状態情報の入力を受け付け、病院選定サーバ１００に送信する。病院候補表示部２１２は、病院選定サーバ１００から受信した病院候補の情報を、表示装置２０６に表示する。

入力装置２０５は、例えば、キーボード、及びマウス等である。表示装置２０６は、例えば、及びディスプレイ等である。なお、例えば、タッチパネルのように入力装置２０５と表示装置２０６が一体化していてもよい。なお、端末２００についても病院選定サーバ１００と同様に、入力インターフェース及び出力インターフェースを有してもよく、外部の入力装置及び表示装置が接続されていてもよい。ＧＰＳ受信装置２０７は、ＧＰＳ衛星からの信号を受信し、受信した信号に基づいて端末２００の位置情報を取得する。

図２は、対応可否テーブル１２２の一例である。対応可否テーブル１２２は、例えば、ＩＤ欄１２２１、病院欄１２２２、患者分類欄１２２３、対応可否欄１２２４、診療フローＩＤ欄１２２５、及び位置欄１２２６を含む。ＩＤ欄１２２１は、対応可否テーブル１２２内のレコードを識別するＩＤを保持する。病院欄１２２２は、病院の名称を保持する。

患者分類欄１２２３は、患者分類を格納する。対応可否欄１２２４は、当該病院が当該患者分類の患者の治療に対応できるか否かを示す値を保持する。診療フローＩＤ欄１２２５は、対応可否欄１２２４の値が「可」である場合、診療フローＩＤを保持し、対応可否欄１２２４の値が「不可」である場合、例えば、ｎｕｌｌ値等を保持する。

なお、患者分類が同じであっても、病院によってリソース等が異なる可能性があるため、同じ患者分類について異なる診療フローＩＤが格納されていてもよい。また、同じ病院の同じ患者分類であっても、複数種類のフローが実行可能である可能性があるため、同じ病院の同じ患者分類について複数のレコードが存在してもよい。なお、対応可否及び診療フローＩＤが不明である場合には、対応可否欄１２２４及び診療フローＩＤ欄１２２５には、「不明」という値又はｎｕｌｌ値等が格納されている。位置欄１２２６は、当該病院の位置情報を保持する。位置情報は、例えば、緯度及び経度の座標値で表されている。

図３は、診療フローテーブル１２３の一例である。図３の例は、診療フローＩＤが「３」であるフローを示す。診療フローテーブル１２３は、例えば、プロセスＩＤ欄１２３１、プロセス名称欄１２３２、開始条件欄１２３３、及び実行時間欄１２３４を含む。プロセスＩＤ欄１２３１は、プロセスを識別するＩＤを保持する。

プロセス名称欄１２３２は、プロセスの名称を保持する。図３の例では、「ｔ－ＰＡ治療」及び「カテーテル治療」が治療行為であり、他のフローは治療行為そのものではなく、治療行為を行うための検査等の準備行為である。なお、例えば、診療フローテーブル１２３が治療行為と準備行為を区別するためのフラグを有してもよいし、治療行為に相当するフローを示す別のデータが補助記憶装置１０３に格納されていてもよい。

開始条件欄１２３３は、対応するプロセスを開始するための条件を格納する。例えば、図３において、「血液検査」は、患者の搬送が終了後ならばいつでも開始することができるが、「ＣＴ」は、プロセスＩＤが１～４のプロセス（即ち、「血液検査」、「病歴確認」、「心電図検査」、及び「エコー」）の全てが終了するまで開始することができない。

なお、２つのプロセスの開始条件に、互いのプロセスが終了することが含まれないように定められている必要がある。具体的には、例えば、プロセスＩＤが「１」のプロセスの開始条件が「２が終了」であり、かつプロセスＩＤ「２」のプロセスの開始条件が「１が終了」である場合、いずれのプロセスも開始できなくなってしまうからである。また、他のプロセスの開始条件の例として、所定のプロセスと同時に実行不可能等がある。

実行時間欄１２３４は、当該プロセスの実行開始から終了までにかかる時間を保持する。なお、図３の例では、診療フローＩＤごとに診療フローテーブル１２３が用意されているため、例えば、各診療フローテーブル１２３を検索するためのインデックスが補助記憶装置１０３に格納されてもよい。また、全ての診療フローＩＤのフローの情報を１つの診療フローテーブル１２３に格納してもよく、この場合、例えば、診療フローテーブル１２３は診療フローＩＤ欄をさらに含むとよい。

図４は、リソース状況テーブル１２４の一例である。図４の例は、「Ｂ民間病院」におけるリソース状況を示す。リソース状況テーブル１２４は、例えば、プロセスＩＤ欄１２４１及び利用開始可能時刻欄１２４２を含む。プロセスＩＤ欄１２４１は、「Ｂ民間病院」が実行可能なフローに含まれるプロセスのプロセスＩＤを保持する。

利用開始可能時刻欄１２４２は、当該プロセスに利用されるリソースの利用を開始することができる時刻を示す情報を格納する。なお、利用開始可能時刻欄１２４２に格納された「０分後」は、現時点で当該フローを実行するリソースが利用可能であることを示す。なお、リソースとは検査機器、治療機器、及び手術機器等の物的リソースだけでなく、医師、検査技師、及び看護師等の人的リソースを含んでもよい。

なお、例えば、病院選定サーバ１００は各病院のサーバと接続され、各病院のサーバが定期的に又はリアルタイムでリソース状況を病院選定サーバ１００に送信し、病院選定サーバ１００は受信したリソース状況に従って、リソース状況テーブル１２４を更新する。

図５は、患者分類履歴テーブル１２６の一例である。患者分類履歴テーブル１２６は、患者状態から患者分類を予測する患者分類予測モデル１２１の生成に用いられる。患者分類履歴テーブル１２６は、例えば、患者ＩＤ欄１２６１、説明変数欄１２６２、及び目的変数欄１２６３を含む。

患者ＩＤ欄１２６１は、例えば、患者を識別するＩＤを格納する。説明変数欄１２６２は、当該患者の説明変数の値を保持する。図５の例では、めまいの有無、片マヒの有無、会話が正常であるか否か、抗凝固薬の服用の有無、及び糖尿病既往の有無等の、患者の状態を示す変数が、説明変数として採用されている。

目的変数欄１２６３は、目的変数欄１２６３は、当該患者の目的変数の値を保持する。図５の例では、患者分類が目的変数として採用されている。つまり、なお、例えば、説明変数及び目的変数の値が不明であった場合には、例えば、「不明」という値やｎｕｌｌ値等が、説明変数欄１２６２に格納されてもよい。これは後述する緊急搬送履歴テーブル１２７についても同様である。

患者分類予測モデル１２１は、予め与えられたモデルであってもよいし、例えば、患者分類予測部１１１が、患者分類履歴テーブル１２６の説明変数の値と目的変数の値とを機械学習（例えばディープラーニングやロジスティック回帰等）することによって生成されたモデルであってもよい。

図６は、緊急搬送履歴テーブル１２７の一例である。緊急搬送履歴テーブル１２７は、緊急搬送時の時間情報等から緊急車両の移動時間を予測する緊急車両移動時間予測モデル１２５の生成に用いられる。緊急搬送履歴テーブル１２７は、例えば、ＩＤ欄１２７１、説明変数欄１２７２、及び目的変数欄１２７３を含む。ＩＤ欄１２７１は、緊急搬送履歴テーブル１２７内のレコード、つまり緊急搬送の履歴を識別するＩＤを保持する。

説明変数欄１２７２は、当該ＩＤに対応する履歴の説明変数の値を保持する。図６の例では、緊急搬送が行われた曜日及び時間帯と、経路計算及び／又は渋滞に基づく移動時間と、が説明変数として採用されている。なお、経路計算及び／又は渋滞に基づく移動時間とは、例えば、カーナビゲーションシステム等によって予測された一般の車両用の移動時間であり、緊急車両の特性（例えば、赤信号の交差点を通過可能）は考慮されていない値である。

目的変数欄１２７３は、当該ＩＤに対応する履歴の目的変数の値を保持する。図６の例では、緊急車両の移動時間が目的変数として採用されている。緊急車両の移動時間とは、当該履歴における緊急車両の実際の移動時間である。

緊急車両移動時間予測モデル１２５は、予め与えられたモデルであってもよいし、例えば、搬送時間推定部１１５が、緊急搬送履歴テーブル１２７の説明変数の値と目的変数の値とを機械学習（例えばディープラーニングやロジスティック回帰等）することによって生成されたモデルであってもよい。

図７は、受入照会所要時間履歴テーブル１２８の一例である。受入照会所要時間履歴テーブル１２８は、例えば、日時欄１２８１、病院欄１２８２、及び照会所要時間欄１２８３を含む。日時欄１２８１は、過去に受入照会を行った日時を保持する。病院欄１２８２は、過去に行った受入照会先の病院の名称を格納する。照会所要時間欄１２８３は、当該受入照会にかかった所要時間を保持する。

なお、リソース状況テーブル１２４にリソースの利用状況が記録されている病院については、リソースの利用状況が判明しているゆえ受入照会を行う必要がない。従って、このような病院については後述する受入照会所要時間を算出しなくてもよいため、受入照会所要時間履歴テーブル１２８は、このような病院の受入照会所要時間履歴を保持しなくてもよい。

図８は、病院選定処理の一例を示すフローチャートである。まず、端末２００の患者状態情報入力送信部２１１は、端末２００の利用者によって入力される患者の状態情報の入力を受け付け、入力された状態情報と、ＧＰＳ受信装置２０７が取得した端末２００の現在位置情報と、を病院選定サーバ１００に送信する（Ｓ８０１）。なお、入力された状態情報は、患者分類予測モデル１２１の説明変数の値を含む。また、端末２００の現在位置情報は患者の位置を示す情報である。

病院選定サーバ１００の患者分類予測部１１１は、受信した状態情報に含まれる説明変数の値を患者分類予測モデル１２１に入力することにより、患者分類予測モデル１２１の目的変数の値である患者分類を取得する（Ｓ８０２）。

治療開始可能時刻予測部１１２は、対応可否テーブル１２２、診療フローテーブル１２３、及びリソース状況テーブル１２４を用いて、各病院について、ステップＳ８０２で取得した各患者分類の治療開始可能時刻を予測する（Ｓ８０３）。ステップＳ８０３の詳細については後述する。

予測結果統合処理部１１３は、ステップＳ８０２で取得した患者分類の確率と、対応可否テーブル１２２における各病院の各患者分類の対応可否欄１２２４の値と、から各病院において当該患者に対応不可である確率を算出する（ステップＳ８０４）。具体的には、ある病院において当該患者に対応不可である確率は、例えば、対応可否テーブル１２２において当該病院について対応可のレコードが存在しない患者分類の確率の和によって算出される。

また、ステップＳ８０４において、予測結果統合処理部１１３は、ステップＳ８０２で得られた患者分類の確率と、ステップＳ８０３で予測した各患者分類の治療開始可能時刻と、から、各病院における治療開始可能時刻の期待値を算出する。なお、予測結果統合処理部１１３は、当該患者の対応が不可である確率が１００％である病院については、期待値を算出する必要はない。

続いて、病院候補選定部１１４は、例えば、ステップＳ８０４で算出した対応不可の確率が所定値以下である病院を選択し、ステップＳ８０４で算出した治療開始可能時刻の期待値が早い順に選択した病院についての対応不可の確率及び治療開始可能時刻の期待値を含む情報をソートし、ソートした情報を表示装置１０９に表示する（Ｓ８０５）。

なお、ステップＳ８０５において、病院候補選定部１１４は、例えば、ステップＳ８０４で算出した対応不可の確率が低い順に所定数の病院を選択してもよいし、対応不可の確率が平均値より低い病院を選択してもよい。

図９は、ステップＳ８０２で得られる患者分類予測モデル１２１による患者分類の結果の一例である。患者分類予測モデル１２１から、各患者分類に該当する確率が得られる。なお、患者分類予測モデル１２１は、目的変数の値を１つに決定して返すモデルであってもよい。また、患者分類予測部１１１が、得られた確率に基づいて、１つの患者分類を決定してもよい。具体的には、例えば、患者分類予測部１１１は、確率が最も高い患者分類（最も確率が高い患者分類が複数ある場合には、これらの患者分類からランダムに選択する）を選択してもよい。

図１０は、ステップＳ８０３で得られる各病院における各患者分類の治療開始可能時刻の一例である。なお、「Ａ市民病院」では、患者分類「（ア）」及び「（イ）」に対応不可であるため、治療開始可能時刻ではなく、「不可」という値が格納されている。

図１１は、ステップＳ８０４で得られる、各病院において当該患者に対応不可である確率及び各病院における治療開始可能時刻の期待値の一例である。なお、当該患者の対応が不可である病院については、ステップＳ８０４の時点で出力から除外されてもよい。

図１２は、ステップＳ８０３における各患者分類の治療開始可能時刻の予測処理の一例を示すフローチャートである。治療開始可能時刻予測部１１２は、カウンタにＮ＝１をセットする（Ｓ１２０１）。治療開始可能時刻予測部１１２は、対応可否テーブル１２２のＮ行目のレコードを読み込む（Ｓ１２０２）。

治療開始可能時刻予測部１１２は、当該レコードの対応可否欄１２２４の値が「対応可」であるか否かを判定する（Ｓ１２０３）。治療開始可能時刻予測部１１２は、当該レコードの対応可否欄１２２４の値が「対応可」であると判定した場合（Ｓ１２０３：Ｙｅｓ）、当該レコードの病院及び患者分類について治療開始可能時刻を算出し（Ｓ１２０４）、ステップＳ１２０６に遷移する。ステップＳ１２０４の詳細については後述する。

治療開始可能時刻予測部１１２は、当該レコードの対応可否欄１２２４の値が「対応不可」であると判定した場合（Ｓ１２０３：Ｎｏ）、当該レコードが示す病院では当該レコードが示す患者分類の対応が「不可」であることを示す情報を出力し（Ｓ１２０５）、ステップＳ１２０６に遷移する。

なお、例えば、対応可否が不明であるレコード、又は対応可であってもフローＩＤが不明若しくはフローＩＤに対応するリソース状況が不明である等の理由で治療開始可能時刻を算出不可能なレコードに対しては、後述するステップＳ１３０２における搬送時間推定処理のみが行われる。

続いて、治療開始可能時刻予測部１１２は、対応可否テーブル１２２の全てのレコードを読み込んだか否かを判定する（Ｓ１２０６）。治療開始可能時刻予測部１１２は、対応可否テーブル１２２の全てのレコードを読み込んだと判定した場合（Ｓ１２０６：Ｙｅｓ）、ステップＳ８０３における処理を終了する。

治療開始可能時刻予測部１１２は、対応可否テーブル１２２内に未読み込みのレコードがあると判定した場合（Ｓ１２０６：Ｎｏ）、カウンタＮの値をインクリメントし（Ｓ１２０７）、ステップＳ１２０２の処理に戻る。

なお、前述した例における、患者分類予測モデル１２１を用いて患者の状態から患者分類を予測し、予測した患者分類に対応するフローＩＤを対応可否テーブル１２２から取得し、フローＩＤに対応するフローの各プロセスを診療フローテーブル１２３から取得する、一連のアルゴリズムを１つのフロー予測モデルとして定義してもよい。また、補助記憶装置１０３は、患者の状態から直接的にフローを推測するモデルを有してもよく、この場合当該モデルによってフローを取得してもよい。

図１３は、ステップＳ１２０４における治療開始可能時刻の算出処理の一例を示すフローチャートである。治療開始可能時刻予測部１１２は、ステップＳ１２０２で読み込んだレコードが示す診療フローＩＤに対応する（即ち、当該レコードが示す病院及び患者分類に対応する）診療フローテーブル１２３及びリソース状況テーブル１２４を読み込む（Ｓ１３０１）。搬送時間推定部１１５は、当該病院への患者の搬送終了時刻を推定する（Ｓ１３０２）。ステップＳ１３０２の詳細については後述する。

治療開始可能時刻予測部１１２は、読み込んだ診療フローテーブル１２３の未選択のプロセスのうち、開始条件を満たす時刻を算出可能なプロセスを１つ選択する（選択したプロセスをプロセスＸとも呼ぶ）（Ｓ１３０３）。

例えば、図３の例では、プロセスＩＤが「５」のプロセスは、プロセスＩＤが「１」乃至「４」のプロセスが終了するまで実行不可能であるため、プロセスＩＤが「１」乃至「４」のプロセスの終了時刻を算出するまでは、ステップＳ１３０３において選択不可能である。図３の例では、初回のステップＳ１３０３において、選択可能なプロセスは、開始条件に他のプロセスの終了が含まれていないプロセスＩＤが「１」乃至「４」のプロセスである。この例では、初回のステップＳ１３０３において、治療開始可能時刻予測部１１２は、例えば、プロセスＩＤが「１」乃至「４」のプロセスから１つのプロセスをランダムに選択する。

治療開始可能時刻予測部１１２は、（１）診療フローテーブル１２３におけるプロセスＸの開始条件を満たす時刻（例えば１以上の所定のプロセスの終了が開始条件である場合には、当該１以上の所定のプロセスの終了時刻のうち最も遅い時刻）、又は（２）リソース状況テーブル１２４におけるプロセスＸのリソースの利用開始可能時刻のうち、遅い方の時刻を、プロセスＸの開始時刻に決定する（Ｓ１３０４）。

治療開始可能時刻予測部１１２は、ステップＳ１３０１で読み込んだ診療フローテーブル１２３におけるプロセスＸの実行時間を、ステップＳ１３０４で算出した開始時刻に加えた時刻を、プロセスＸの終了時刻として算出する（Ｓ１３０５）。治療開始可能時刻予測部１１２は、ステップＳ１３０１で読み込んだ診療フローテーブル１２３の全てのフローを選択済みであるか否かを判定する（Ｓ１３０６）。

治療開始可能時刻予測部１１２は、未選択のフローがあると判定した場合（Ｓ１３０６：Ｎｏ）、ステップＳ１３０３に戻る。治療開始可能時刻予測部１１２は、全てのフローを選択済みであると判定した場合（Ｓ１３０６：Ｙｅｓ）、ステップＳ１２０２で読み込んだレコードが示すフローの（即ち、当該レコードが示す病院において当該レコード患者分類の）治療開始可能時刻を算出する（Ｓ１３０７）。

ステップＳ１３０７において、治療開始可能時刻予測部１１２は、具体的には例えば、検査等の治療の準備行為ではない具体的な治療行為の開始時刻のうち最も早い時刻（図３の例（即ち脳卒中患者の例）では、ｔ－ＰＡ治療の開始時刻又はカテーテル治療の開始時刻のうち早い方の時刻）を治療開始可能時刻として算出する。

前述した処理により、本実施例の病院選定サーバ１００は、予測された患者分類に対応可能な病院を選定し、かつフローのリソース状況を考慮した治療開始可能時刻をより正確に算出することができ、ひいては治療開始可能時刻が早い病院をより正確に選定することができる。

なお、例えば、緊急車両がドクターカー等であれば、患者を搬送中に緊急車両内でフローの一部又は全部のプロセスが実行可能となるケースが起こり得る。例えば、補助記憶装置１０３は、緊急車両において実行可能なプロセス、当該プロセスの開始条件、及び当該プロセスの実行時間を示す、緊急車両のプロセス情報を保持しているものとする。例えば、ステップＳ１３０３～Ｓ１３０５において、治療開始可能時刻予測部１１２は、緊急車両のプロセス情報を参照して、搬送終了時刻までに緊急車両内で終了可能なプロセスが存在すると判定した場合には、当該プロセスについては優先的に緊急車両内で実行することとして、当該プロセスの開始時刻及び終了時刻を算出してもよい。

図１４は、ステップＳ１３０４及びステップＳ１３０５で算出されたプロセスの実行時間の一例を示す説明図である。ケース（１）乃至（３）において、いずれも病院への搬送終了時刻が１０分後である。

まず、ケース（１）について説明する。ケース（１）は、説明変数である発症からの経過の値が「４．５時間未満」であり、説明変数である既往歴の有無の値が「無し」であり、患者分類予測モデル１２１から患者分類が（ア）に決定した例である。

まず、ケース（１）における病院の患者分類（ア）のフロー及び当該フローのリソース状況について説明する。当該病院の患者分類（ア）のフローでは、「血液検査」、「病歴確認」、「心電図」、「エコー」、「ＣＴ」、「造影ＣＴ」、「ｔ－ＰＡ治療」、及び「カテーテル治療」が実行される。

「血液検査」、「病歴確認」、「心電図」、及び「エコー」の開始条件は、「搬送終了」のみである。また、「ＣＴ」の開始条件は、「血液検査」、「病歴確認」、「心電図」、及び「エコー」が終了していることである。「カテーテル治療」の開始条件は、「造影ＣＴ」が終了していることである。

「ｔ－ＰＡ治療」の開始条件は、「ＣＴ」が終了していることである。「カテーテル治療」の開始条件は、「造影ＣＴ」が終了していることである。また、「心電図」及び「エコー」のリソースの利用開始可能時刻は１５分後であり、他のフローのリソース状況の利用開始可能時刻は、利用開始条件を満たす時刻より早いものとする。

図１３で説明したように、治療開始可能時刻予測部１１２は、上述したフローの開始条件及びリソース状況から各プロセスの実行時刻を決定することにより、より早く治療行為を開始するためのプロセスの実行順序を決定することができる。

ケース（２）は、ケース（１）と同様に患者分類が（ア）であるものの、「ＣＴ」のリソースの利用開始可能時刻が３０分後である点において、ケース（１）と異なる。２０分後に、「ＣＴ」の開始条件である「血液検査」、「病歴確認」、「心電図」、及び「エコー」が終了していることは満たされているものの、２０分後の時点では「ＣＴ」のリソースがまだ利用できない。また、「ＣＴ」が終了していない段階では、「ｔ－ＰＡ治療」、「造影ＣＴ」、及び「カテーテル治療」のいずれの開始条件を満たすことができないため、２０分後から３０分後までの間に、何もプロセスを実行しない時間帯が発生している。

ケース（３）は、説明変数である発症からの経過の値が「４．５時間以上」であり、説明変数である腎臓病の有無の値が「有り」であり、患者分類予測モデル１２１から患者分類が（イ）に決定した例である。腎臓病に罹患している患者には「ＣＴ」を実行することができないため、ケース（３）のフローは、「ＣＴ」を開始条件とする「ｔ－ＰＡ治療」及び「造影ＣＴ」を行わず、「ＭＲＩ」を実行した上で「カテーテル」治療を実行する点において、ケース（１）のフローと異なる。

なお、「ＭＲＩ」の開始条件は、「ＣＴ」の開始条件と同様に、「血液検査」、「病歴確認」、「心電図」、及び「エコー」が終了していることである。また、「カテーテル治療」の開始条件は、「ＭＲＩ」が終了していることである。

図１５は、ステップＳ１３０２における患者の搬送終了時刻の推定処理の一例を示すフローチャートである（Ｓ１３０２）。搬送時間推定部１１５は、対応可否テーブル１２２から当該病院の位置情報と、ステップＳ８０１で取得した端末２００の現在位置情報と、を取得する（Ｓ１５０１）。

搬送時間推定部１１５は、病院の位置情報と現在位置情報とを用いた、経路計算及び／又は渋滞情報に基づく、現在位置から病院までの（緊急車両はでない）一般車両による移動時間を取得する（Ｓ１５０２）。

なお、ステップＳ１５０１の処理は、例えば、搬送時間推定部１１５が病院選定サーバ１００の外部のカーナビゲーションサーバに病院の位置情報と現在位置情報とを送信し、当該カーナビゲーションサーバが、渋滞予測を考慮した経路情報に基づく一般車両による移動時間を算出して病院選定サーバ１００に送信することにより実行される。なお、緊急車両の代わりに船舶や飛行機等の輸送機器が用いられる場合には、渋滞予測が考慮されなくてもよい。

また、病院選定サーバ１００が、一般車両用のカーナビゲーション用のモデルを有する場合には、例えば、搬送時間推定部１１５が、渋滞予測情報を外部から取得して、病院の位置情報と現在位置情報と渋滞予測情報とを当該モデルに適用することによって、ステップＳ１５０１の処理が実行されてもよい。

続いて、搬送時間推定部１１５は、緊急車両移動時間予測モデル１２５に、説明変数である、現在の曜日、時間帯、及びステップＳ１５０２で算出された移動時間を入力して、目的変数である緊急車両の移動時間を算出し、現在時刻に緊急車両の移動時間を加えることにより、搬送終了時刻を算出する（Ｓ１５０３）。

図１５の処理により、一般の車両と特性や制約条件が異なる緊急車両による移動時間をより正確に算出することができる。これにより、搬送時間の短い病院をより正確に選定できるようになる。

なお、対応可否テーブル１２２において対応可否が不明である病院、又は対応可であってもフローＩＤが不明若しくはフローＩＤに対応するリソース状況が不明である等の理由で治療開始可能時刻を算出不可能な病院に対しては、患者の受入可否や治療開始可能時刻等を照会する受入照会を、救急隊員が行うことが考えらえる。

そこで、搬送時間推定部１１５は、ステップＳ１５０３において、このような病院への搬送終了時刻を算出する場合には、受入照会所要時間を考慮してもよい。具体的には、例えば、搬送時間推定部１１５は、受入照会所要時間履歴テーブル１２８における当該病院への受入照会所要時間の平均値（最大値、最小値、又は中央値等の他の統計量であってもよい）と、緊急車両移動時間予測モデル１２５から得られた移動時間と、を現在時刻に加えることにより、搬送終了時刻を算出してもよい。

なお、病院選定サーバ１００及び端末２００が後述する病院のリソース予約処理を行わない場合には、電話等によって病院に対して予約（受入照会）を行うため、全ての病院についての搬送終了時刻の算出において、受入照会所要時間を考慮してもよい。

図１６は、端末２００に表示される入力画面の一例である。入力画面１６００は、ステップＳ８０１における患者の状態情報（患者分類予測モデル１２１に入力される説明変数の値）を入力するための画面である。入力画面１６００は、例えば、説明変数入力領域１６０１、判定実行ボタン１６０２、及び目的変数表示領域１６０３を含む。

説明変数入力領域１６０１は、患者分類予測モデル１２１に入力するための説明変数の値を入力するための領域である。図１６の例では、端末２００のユーザは、説明変数入力領域１６０１に表示された説明変数の値を選択することにより、説明変数を入力することができる。図１６の例では、説明変数の選択された値が白抜きの文字で表示されている。

説明変数入力領域１６０１において説明変数が入力された状態で、判定実行ボタン１６０２が選択されると、例えば、病院選定サーバ１００が患者分類予測モデル１２１を用いて予測した患者分類（例えば最も該当する確率が高い患者分類）、及び当該患者に実行される予定のフローの情報が、目的変数表示領域１６０３に表示される。なお、目的変数表示領域１６０３には、例えば、図９に示した情報のように複数の患者分類及び当該複数の患者分類それぞれに該当する確率が表示されてもよい。

なお、入力画面１６００は、判定実行ボタン１６０２が選択され、判定が実行された後に、後述する図１７の出力画面を表示するためのボタンを含んでもよい。また、入力画面１６００は、目的変数表示領域１６０３を含まずに、判定実行ボタン１６０２が選択され、判定が実行された後に自動的に図１７の出力画面が表示されてもよい。

図１７は、端末２００に表示される出力画面の一例である。出力画面１７００は、例えば、病院候補表示部２１２によって、表示装置２０６に表示される。出力画面１７００は、例えば、目的変数表示領域１７０１及び地図情報表示領域１７０２を含む。目的変数表示領域１７０１は、例えば、目的変数表示領域１６０３と同様に、患者分類予測モデル１２１を用いて予測した患者分類、及び当該患者に実行される予定のフローの情報を表示する。

地図情報表示領域１７０２は、例えば、ステップＳ８０５において候補として選定された病院の位置情報と、端末２００の現在位置情報と、を表示する。地図情報表示領域１７０２は、病院情報表示領域１７０３を含む。病院情報表示領域１７０３は、例えば、ステップＳ８０３で算出された、当該候補病院に患者を搬送した場合における治療開始可能時刻、が表示される。

なお、Ｄ病院のように治療開始可能時刻が算出不可能であった病院については、例えば、患者分類ごとに予め定められた時間を搬送終了時刻に加えた時刻を治療開始可能時刻として表示してもよいし、治療開始可能時刻の代わりに搬送終了時刻が表示されてもよいし、さらに予測した受付照会時間が表示されてもよい。

また、病院情報表示領域１７０３は、例えば、状況表示ボタン１７０４と、搬送予約ボタン１７０５と、を含む。状況表示ボタン１７０４が選択されると、例えば、後述する図１８のリソース状況を表示する出力画面に遷移する。なお、Ｄ病院のようにリソース状況が不明である病院については、状況表示ボタン１７０４が表示されない。

搬送予約ボタン１７０５が選択されると、例えば、当該病院のフローのプロセスに対応するリソースの開始時刻と終了時刻に基づき、当該病院のリソース状況テーブル１２４の利用開始可能時刻が更新される。具体的には、例えば、当該終了時刻が利用開始可能時刻として更新される。また、病院選定サーバ１００は、当該病院のサーバに当該病院のフローのプロセスに対応するリソースの開始時刻と終了時刻を送信してもよく、この場合、当該病院のサーバは当該病院で当該リソースを当該終了時刻まで予約する。

また、例えば、病院を決定して患者を搬送している最中に、事故等により到着予定時刻が変更となる可能性がある。このような場合、病院選定サーバ１００は、例えば、変更後の到着時刻の入力を受け付ける、又は端末２００から受信する。病院選定サーバ１００は、変更後の到着時刻に基づいて、各フローの開始時刻及び終了時刻を再計算して、リソースの予約時間を更新してもよい。また、実際の到着時刻が到着予定時刻との差が所定値以上である場合にも、同様にリソースの予約時間を更新してもよい。

これらの予約処理を実行することにより、リソース状況テーブル１２４をリアルタイムに更新することができ、ひいてはこの後に実行される治療開始可能時刻の推測をより正確に実行することができる。

なお、Ｄ病院のように対応可否が不明であったり、リソース状況が不明であったりする病院については、搬送予約ボタン１７０５の代わりに、受付照会ボタン１７０６が表示されてもよい。受付照会ボタン１７０６が選択されると、例えば、当該病院への通話が開始されたり、当該病院に対して患者の状態情報や患者分類が送信されたりする。なお、対応可否が不明であったものの受付照会によって当該病院への受付が完了した場合に、例えば、対応可否テーブル１２２の当該病院の当該患者分類の対応可否の値を「可」に変更してもよい。

図１８は、端末２００に表示される出力画面の一例である。出力画面１８００は、例えば、病院候補表示部２１２によって、表示装置２０６に表示される。例えば、前述した状況表示ボタン１７０４が選択されると、出力画面１７００から出力画面１８００に遷移する、又は出力画面１８００がポップアップする。

出力画面１８００は、状況表示ボタン１７０４に対応する病院の選択されたフローの各プロセスのリソース状況を表示する。図１８はＡ病院に対応する状況表示ボタン１７０４が選択された場合の例である。図１８の例では、病院Ａは選択されたフローを実行するリソースを３セット（患者枠１～３）有している。

例えば、「完」は当該リソースの利用が終了しているものの、当該リソースが所属するセットにおいて予約済みのリソースがあることを示す。「空」は当該リソースが空いている状態、即ち直ちに予約可能であることを示す。「不」は当該リソースが故障等を理由に利用不可能であること、又は当該フローにおいて当該リソースは使用対象外であることを示す。また、空欄は当該リソースが予約されている状況であることを示す。また、例えば、「経過時間」は当該セットのリソースの利用開始からの経過時間を示す。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることも可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

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

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１００ 病院選定サーバ、１０１ ＣＰＵ、１０２ メモリ、１０４通信装置、１０３ 補助記憶装置、１１２ 治療開始可能時刻予測部、１１４ 病院候補選定部、１１５ 搬送時間推定部、１２１ 患者分類予測モデル、１２２ 対応可否テーブル、１２３ 診療フローテーブル、１２４ リソース状況テーブル、１２５ 緊急車両移動予測モデル、１２８ 受入照会所要時間履歴テーブル、 ２００ 端末、２０１ ＣＰＵ、２０２ メモリ、２０３ 補助記憶装置、２０６ 表示装置、２１１ 患者状態情報入力部、２１２ 病院候補表示部

Claims (12)

1. 患者を搬送する医療機関を選定する医療機関選定サーバであって、
   プロセッサとメモリとを備え、
   前記メモリは、
   前記患者に対して実行される１以上のプロセスからなるフローを、前記患者の状態情報から予測するフロー予測モデルと、
   実行可能なフローに含まれる各プロセスを実行するためのリソースの状況、を医療機関ごとに示す医療機関情報と、を保持し、
   前記プロセッサは、
   前記患者の状態情報を取得し、
   前記取得した患者の状態情報と前記フロー予測モデルとに基づいて、前記患者に対して実行されるフローを予測し、
   前記医療機関情報を参照して、各医療機関における、前記予測したフローに含まれる各プロセスを実行するためのリソースの状況を取得し、
   前記取得したリソースの状況に基づいて、前記患者を搬送する医療機関候補を選定し、
   前記選定した医療機関候補の情報を出力する、医療機関選定サーバ。
2. 請求項１に記載の医療機関選定サーバであって、
   前記メモリは、前記フロー予測モデルが示すフローに含まれる各プロセスの開始条件及び実行時間を示すフロー情報を保持し、
   前記医療機関情報が示す前記リソースの状況は、当該リソースの利用開始可能時刻を示し、
   前記プロセッサは、
   前記フロー情報を参照して、前記予測したフローに含まれる各プロセスの開始条件及び実行時間を取得し、
   前記医療機関情報を参照して、前記予測したフローに含まれる各プロセスを実行するためのリソースの利用開始可能時刻を取得し、
   前記取得した開始条件と、前記取得した実行時間と、前記取得した利用開始可能時刻と、に基づいて、前記予測したフローに含まれる各プロセスの開始時刻を算出し、
   前記算出した開始時刻に基づいて、前記医療機関候補を選定する、医療機関選定サーバ。
3. 請求項２に記載の医療機関選定サーバであって、
   前記プロセッサは、
   前記予測したフローに含まれる各プロセスについて、当該プロセスが開始条件を満たす時刻、又は当該プロセスを実行するためのリソースの利用開始可能時刻のうち、遅い時刻を、当該プロセスの開始時刻として算出する、医療機関選定サーバ。
4. 請求項２に記載の医療機関選定サーバであって、
   前記１以上のプロセスは、治療行為を含み、
   前記予測したフローそれぞれにおける、前記治療行為であるプロセスの前記算出した開始時刻のうち最も早い時刻である治療開始可能時刻に基づいて、前記医療機関候補を選定する、医療機関選定サーバ。
5. 請求項４に記載の医療機関選定サーバであって、
   前記プロセッサは、前記医療機関候補それぞれの治療開始可能時刻を前記選定した医療機関候補の情報に含めて出力する、医療機関選定サーバ。
6. 請求項２に記載の医療機関選定サーバであって、
   前記メモリは、
   経路に基づく一般輸送機器における予想移動時間から、緊急輸送機器による移動時間を予測する、移動時間予測モデルと、
   前記緊急輸送機器の位置情報と、
   医療機関の位置情報と、を保持し、
   前記プロセッサは、
   前記緊急輸送機器の位置情報と、前記医療機関の位置情報と、が示す前記緊急輸送機器が前記医療機関に到着するまでの経路、に基づく前記一般輸送機器における予想移動時間を取得し、
   前記取得した前記一般輸送機器における予想移動時間と前記移動時間予測モデルとに基づいて、前記緊急輸送機器が医療機関に到着する搬送終了時刻を算出し、
   前記搬送終了時刻に基づいて、前記予測したフローに含まれる各プロセスの開始時刻を算出する、医療機関選定サーバ。
7. 請求項６に記載の医療機関選定サーバであって、
   前記メモリは、
   各医療機関に対する受入照会の所要時間の履歴を示す受入照会所要時間履歴情報を保持し、
   前記プロセッサは、
   各医療機関に対する受入照会の所要時間の所定の統計量に基づいて、前記搬送終了時刻を算出する、医療機関選定サーバ。
8. 請求項２に記載の医療機関選定サーバであって、
   前記プロセッサは、
   前記医療機関候補から決定された前記患者を搬送する搬送先医療機関を示す情報を取得し、
   前記搬送先医療機関において実行される予定のフローに含まれる各プロセスの終了時刻に基づいて、前記医療機関情報における前記搬送先医療機関のリソースの状況を更新する、医療機関選定サーバ。
9. 請求項１に記載の医療機関選定サーバであって、
   前記フロー予測モデルは、
   前記患者の状態情報から前記患者の患者分類を予測する患者分類予測モデルと、
   前記患者分類の対応可否、及び対応可能である患者分類の患者に対して実行されるフロー、を医療機関ごとに示す対応可否情報と、を含み、
   前記プロセッサは、
   前記取得した患者の状態情報と、前記患者分類予測モデルと、に基づいて、前記患者の患者分類を予測し、
   前記対応可否情報を参照して、前記予測した患者分類に対応可能である医療機関を特定し、当該医療機関において前記患者に対して実行されるフローを予測する、医療機関選定サーバ。
10. 請求項９に記載の医療機関選定サーバであって、
    前記メモリは、前記フロー予測モデルが示すフローに含まれる各プロセスの開始条件及び実行時間を示すフロー情報を保持し、
    前記医療機関情報が示す前記リソースの状況は、当該リソースの利用開始可能時刻を示し、
    前記１以上のプロセスは、治療行為を含み、
    前記患者分類予測モデルは、前記患者の状態情報から、前記患者が各患者分類に該当する確率を予測するモデルであり、
    前記プロセッサは、
    前記取得した患者の状態情報と、前記患者分類予測モデルと、に基づいて、前記患者が各患者分類に該当する確率を予測し、
    前記予測した確率と前記対応可否情報とに基づいて、各医療機関において患者に対して各フローが実行される確率を算出し、
    前記医療機関情報を参照して、前記各フローに含まれる各プロセスを実行するためのリソースの利用開始可能時刻を取得し、
    前記フロー情報を参照して、前記各フローに含まれる各プロセスの開始条件及び実行時間を取得し、
    前記医療機関情報を参照して、前記各フローに含まれる各プロセスを実行するためのリソースの利用開始可能時刻を取得し、
    前記取得した開始条件と、前記取得した実行時間と、前記取得した利用開始可能時刻と、に基づいて、前記各フローに含まれる各プロセスの開始時刻を算出し、
    前記各フローについて、前記治療行為であるプロセスの前記算出した開始時刻のうち最も早い時刻である治療開始可能時刻を算出し、
    前記算出した治療開始可能時刻と、前記各フローが実行される確率と、に基づいて、前記各医療機関における前記治療開始可能時刻の期待値を算出し、
    前記算出した期待値に基づいて、前記医療機関候補を選定する、医療機関選定サーバ。
11. 請求項１に記載の医療機関選定サーバであって、
    前記プロセッサは、前記医療機関候補のリソースの状況を、前記選定した医療機関候補の情報に含めて出力する、医療機関選定サーバ。
12. 患者を搬送する医療機関を、医療機関選定サーバが選定する方法であって、
    前記医療機関選定サーバは、
    前記患者に対して実行される１以上のプロセスからなるフローを、前記患者の状態情報から予測するフロー予測モデルと、
    実行可能なフローに含まれる各プロセスを実行するためのリソースの状況、を医療機関ごとに示す医療機関情報と、を保持し、
    前記方法は、
    前記医療機関選定サーバが、前記患者の状態情報を取得し、
    前記医療機関選定サーバが、前記取得した患者の状態情報と前記フロー予測モデルとに基づいて、前記患者に対して実行されるフローを予測し、
    前記医療機関選定サーバが、前記医療機関情報を参照して、各医療機関における、前記予測したフローに含まれる各プロセスを実行するためのリソースの状況を取得し、
    前記医療機関選定サーバが、前記取得したリソースの状況に基づいて、前記患者を搬送する医療機関候補を選定し、
    前記医療機関選定サーバが、前記選定した医療機関候補の情報を出力する、方法。

Images