JP2020173530A - 医療支援システム、医療支援方法及びプログラム - Google Patents

Abstract

【課題】ユーザの容態に適したサービスを通知できるようにすること。【解決手段】実施形態に係る医療支援システムは、第１の取得部と、判定部と、選択部と、通知部とを有する。第１の取得部は、ユーザの容態を表すデータを取得する。判定部は、前記データに基づいて、前記ユーザの医療的な処置に係る緊急度を判定する。選択部は、前記判定部の判定結果に基づいて、前記ユーザに提供可能な複数のサービスの中から何れかのサービスを選択する。通知部は、前記選択部で選択されたサービスに応じた通知を行う。【選択図】図３

Description

本発明の実施形態は、医療支援システム、医療支援方法及びプログラムに関する。

従来、医療的な処置を希望又は必要とするユーザを、救急車やドクターヘリ等を用いて、病院に搬送（救急搬送）することが行われている。また、例えば、ユーザ自身が救急搬送を依頼すべきかどうか迷うような場合に、設問に対して回答することで救急搬送の要否判断の参考となる情報を提供するシステムも提案されている。一方、近年では軽症のユーザがタクシー代りに救急車を利用する等、不要不急の要請が増加している。

特開２０１３−４１４７９号公報

本発明が解決しようとする課題は、ユーザの容態に適したサービスを通知できるようにすることである。

実施形態に係る医療支援システムは、第１の取得部と、判定部と、選択部と、通知部とを備える。第１の取得部は、ユーザの容態を表すデータを取得する。判定部は、前記データに基づいて、前記ユーザの医療的な処置に係る緊急度を判定する。選択部は、前記判定部の判定結果に基づいて、前記ユーザに提供可能な複数のサービスの中から何れかのサービスを選択する。通知部は、前記選択部で選択されたサービスに応じた通知を行う。

図１は、実施形態に係る医療支援システムの構成例を示す図である。 図２は、実施形態に係るユーザ端末の構成例を示す図である。 図３は、実施形態に係る医療支援サーバの構成例を示す図である。 図４は、実施形態に係るサービス提供者テーブルのデータ構成の一例を示す図である。 図５は、実施形態に係るサービス選択テーブル構成の一例を示す図である。 図６は、実施形態のユーザ端末で実行される処理の一例を示すフローチャートである。 図７は、実施形態の医療支援サーバで実行される処理の一例を示すフローチャートである。

以下、図面を参照しながら、医療支援システム、医療支援方法及びプログラムの実施形態について詳細に説明する。

図１は、本実施形態に係る医療支援システム１の構成例を示す図である。図１に示すように、医療支援システム１は、ユーザ端末１０と、サービス提供システム２０と、支援サーバ３０とを有する。ここで、各システム及び各装置は、インターネット等のネットワークＮを介して通信可能に接続される。なお、ネットワークＮに接続されるユーザ端末１０及びサービス提供システム２０の個数は、特に問わないものとする。

ユーザ端末１０は、医療支援システム１のユーザが所持する端末装置である。ユーザ端末１０は、ユーザの生体データを取得することが可能な機能及び構成を有している。ユーザ端末１０は、例えば、スマートフォンやスマートウォッチ、生体センサ装置等のコンピュータ機器によって実現される。

サービス提供システム２０は、ユーザの搬送や処置に係る各種のサービス提供者が管理するシステムである。サービス提供システム２０は、支援サーバ３０からサービスの提供を要請する要請情報を受け付け、受け付けた要請情報に基づいてユーザ端末１０のユーザに対しサービスを提供する。サービス提供システム２０は、例えば、サーバやワークステーション等のコンピュータ機器によって実現される。

ここで、患者の搬送に係るサービスとしては、消防機関等が提供する救急車やドクターヘリ等の医療行為を伴う救急搬送サービスや、タクシー会社等が提供する医療行為を伴わない通常搬送サービス等が挙げられる。また、患者の処置に係るサービスとしては、在宅医療機関等が提供する医師やヘルパー等の人材を患者宅に派遣する人材派遣サービス、薬剤配送業者等が提供する薬剤を患者宅に配送する薬剤配送サービス、医療機関等が提供する患者の状態を遠隔で診断する遠隔診断サービス等が挙げられる。

本実施形態の医療支援システム１は、上述したサービス種別のサービス提供システム２０を含むものとする。なお、同一種別のサービスであっても、サービス提供者が相違する場合や、サービス提供者がサービスを提供する範囲（サービス提供エリア）が異なる場合には、サービス提供者毎にサービス提供システム２０が用意されるものとする。

支援サーバ３０は、医療支援システム１の主要な動作を制御する。具体的には、支援サーバ３０は、ユーザ端末１０で取得された生体データに基づき、ユーザ端末１０を所持するユーザの医療的な処置の緊急度を判定する。また、支援サーバ３０は、緊急度の判定結果に適したサービス提供者（サービス提供システム２０）を選定する。そして、支援サーバ３０は、選定したサービス提供者をユーザ端末１０のユーザに通知したり、ユーザ端末１０のユーザに対するサービスの提供を選定したサービス提供者に要請したりする。支援サーバ３０は、例えば、サーバ装置やワークステーション等のコンピュータ機器によって実現される。なお、支援サーバ３０は、単一の装置に限らず、ネットワーク接続された複数のコンピュータ機器の協働（例えばクラウドコンピューティング）により実現される形態としてもよい。

次に、上述したユーザ端末１０及び支援サーバ３０の構成について説明する。

図２は、ユーザ端末１０の構成例を示すブロック図である。図２に示すように、ユーザ端末１０は、通信インタフェース１１と、記憶回路１２と、表示デバイス１３と、入力デバイス１４と、生体データ取得回路１５と、位置データ取得回路１６と、処理回路１７とを備える。

通信インタフェース１１は、外部装置（サービス提供システム２０、支援サーバ３０）との間で行われる通信を制御する。具体的には、通信インタフェース１１は、処理回路１７の制御の下、外部装置との間で各種データや情報の送受信を行う。通信インタフェース１１は、例えば、ネットワークカードやネットワークアダプタ、ＮＩＣ（Network Interface Controller）等によって実現される。

記憶回路１２は、処理回路１７が実行する各種のプログラムや、ユーザ端末１０の動作に関する各種の設定情報等を記憶する。また、記憶回路１２は、自己のユーザ端末１０を所持するユーザに関するユーザ情報を記憶する。ユーザ情報は、例えばユーザの氏名、年齢、性別、患者ＩＤ、住所、連絡先等を含む。記憶回路１２は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ等の半導体メモリ素子や、ハードディスク、光ディスク等によって実現される。

表示デバイス１３は、処理回路１７の制御の下、各種の情報及び画像を表示する。具体的には、表示デバイス１３は、処理回路１７から送られる情報及び画像のデータを表示用の電気信号に変換して出力する。表示デバイス１３は、例えば、液晶ディスプレイやＣＲＴ（Cathode Ray Tube）モニタ等によって実現される。

入力デバイス１４は、ユーザから各種の入力操作を受け付ける。具体的には、入力デバイス１４は、操作者から受け付けた入力操作を電気信号に変換して処理回路１７に出力する。入力デバイス１４は、例えば、トラックボール、スイッチボタン、マウス、キーボード、操作面へ触れることで入力操作を行うタッチパッド、表示デバイス１３の表示画面上に設けられるタッチスクリーン、光学センサを用いた非接触入力回路、音声入力回路等によって実現される。なお、本実施形態において、入力デバイス１４は、マウス、キーボード等の物理的な操作部品を備えるものだけに限られない。例えば、ユーザ端末１０とは別体に設けられた外部の入力機器から入力操作に対応する電気信号を受け取り、この電気信号を処理回路１７に入力する入力回路も入力デバイス１４の例に含まれる。

生体データ取得回路１５は、ユーザの容態を表すデータを取得する。具体的には、生体データ取得回路１５は、ユーザの血圧や体温、心拍、脈波等の生体データを採取し、採取した生体データを処理回路１７に出力する。生体データ取得回路１５は、例えば、血圧や体温、心拍、脈波等の生体データを採取可能な各種のセンシング回路によって実現される。なお、本実施形態において、生体データ取得回路１５は、センシング回路等の物理的な部品を備えるものだけに限られない。例えば、ユーザ端末１０とは別体に設けられた外部のセンシング回路で採取された生体データを受け取り、この生体データを処理回路１７に入力する入力回路も生体データ取得回路１５の例に含まれる。また、医療支援システム１全体で生体データの取得を捉える場合、生体データ取得回路１５は、第１の取得部の一例として機能する。

位置データ取得回路１６は、ユーザ端末１０の存在位置を示す位置データを取得する。具体的には、位置データ取得回路１６は、ユーザ端末１０の存在位置を示す緯度経度などの位置データを取得し、取得した位置データを処理回路１７に出力する。位置データ取得回路１６は、例えば、ＧＰＳ（Global Positioning System）等の位置測定回路によって実現される。なお、本実施形態において、位置データ取得回路１６は、位置測定回路等の物理的な部品を備えるものだけに限られない。例えば、ユーザ端末１０とは別体に設けられた外部の位置測定回路で採取された位置データを受け取り、この位置データを処理回路１７に入力する入力回路も位置データ取得回路１６の例に含まれる。また、医療支援システム１全体で位置データの取得を捉える場合、位置データ取得回路１６は、第２の取得部の一例として機能する。

処理回路１７は、入力デバイス１４を介してユーザから受け付けた入力操作に応じて、ユーザ端末１０の動作を制御する。処理回路１７は、例えば、プロセッサによって実現される。また、処理回路１７は、送信機能１７１と、表示機能１７３とを有する。

送信機能１７１は、通信インタフェース１１と協働することで、外部装置（サービス提供システム２０、支援サーバ３０）に対し各種のデータや情報を送信する。例えば、送信機能１７１は、生体データ取得回路１５で取得された生体データを支援サーバ３０に送信する。また、送信機能１７１は、記憶回路１２に記憶されたユーザ情報や、位置データ取得回路１６で取得された位置データを、生体データとともに支援サーバ３０に送信する。

なお、送信機能１７１が、生体データ等を送信するタイミングは特に問わず、任意に設定することが可能である。例えば、送信機能１７１は、入力デバイス１４を介して所定の操作（支援要請操作）の入力を受け付けると、生体データ等を支援サーバ３０に送信する。

受信機能１７２は、通信インタフェース１１と協働することで、外部装置（サービス提供システム２０、支援サーバ３０）から自装置宛に送信された各種のデータや情報を受信する。例えば、受信機能１７２は、支援サーバ３０から送信される支援情報を受信する。

表示機能１７３は、表示デバイス１３に表示する画面を制御する。例えば、表示機能１７３は、受信機能１７２が支援サーバ３０から受信した支援情報に基づく画面を表示デバイス１３に表示させる。また、例えば、表示機能１７３は、遠隔診断サービス等のサービス提供システム２０から提供される情報に基づく画面を表示デバイス１３に表示させる。

図３は、支援サーバ３０の構成例を示す図である。図３に示すように、支援サーバ３０は、通信インタフェース３１と、記憶回路３２と、処理回路３３とを備える。

通信インタフェース３１は、外部装置（ユーザ端末１０、サービス提供システム２０）との間で行われる通信を制御する。具体的には、通信インタフェース３１は、処理回路３３の制御の下、外部装置との間で各種データや情報の送受信を行う。通信インタフェース３１は、例えば、ネットワークカードやネットワークアダプタ、ＮＩＣ等によって実現される。

記憶回路３２は、処理回路３３が実行する各種のプログラムや、支援サーバ３０の動作に関する各種の設定情報等を記憶する。記憶回路３２は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子や、ハードディスク、光ディスク等によって実現される。

また、記憶回路３２は、複数の被検体から採取された生体データを格納した被検体ＤＢ（データベース）３２１を記憶する。具体的には、被検体ＤＢ３２１は、複数の被検体から採取された生体データと、当該被検体の予後の状態等を表す予後情報とを対応付けて格納する。ここで、被検体は、不特定多数とするが、医療支援システム１のユーザ、つまりユーザ端末１０を所持するユーザを含んでもよい。なお、医療支援システム１のユーザを含める場合には、ユーザを特定できるよう、各ユーザを識別することが可能な識別子（患者ＩＤ）を生体データ及び予後情報と対応付けて格納する。

また、記憶回路３２は、複数段階に区分けされた緊急度の各々と、当該緊急度に応じたサービス（サービス種別）とを対応付けたデータの一例として、サービス選択テーブル３２２（図５参照）を記憶する。また、記憶回路３２は、サービス提供者に関する情報を格納したサービス提供者テーブル３２３を記憶する。

ここで、図４は、サービス提供者テーブル３２３のデータ構成の一例を示す図である。図４に示すように、サービス提供者テーブル３２３は、サービス種別と、サービス提供者名と、アドレスと、サービス提供エリアとを対応付けて記憶する。

サービス種別には、ユーザに提供することが可能なサービスのサービス種別が格納される。具体的には、サービス種別には、救急搬送や一般搬送等のサービスの種別を示す情報が格納される。サービス提供者名には、サービスを提供するサービス提供者の組織名や会社名等が格納される。アドレスには、サービス提供システム２０のアドレスや、電話番号、住所等の情報が格納される。サービス提供エリアには、サービスを提供する範囲（地域）を特定可能な情報が格納される。なお、図４では、サービス提供エリアを問わないものについては、サービス提供エリアの欄をヌル（空）としている。

図３に戻り、処理回路３３は、支援サーバ３０の動作を制御する。処理回路３３は、例えば、プロセッサによって実現される。また、処理回路３３は、取得機能３３１と、判定機能３３２と、選択機能３３３と、通知機能３３４とを機能部として備える。

取得機能３３１は、通信インタフェース３１と協働することで、ユーザ端末１０やサービス提供システム２０から送信された各種のデータや情報を取得する。具体的には、取得機能３３１は、ユーザ端末１０から生体データやユーザ情報、位置データが送信された場合に、送信されたデータ及び情報を取得する。なお、支援サーバ３０単体で生体データ及び位置データの取得を捉える場合、取得機能３３１は、第１の取得部及び第２の取得部の一例として機能する。

判定機能３３２は、判定部の一例である。判定機能３３２は、取得機能３３１が取得した生体データに基づいて、医療的な処置の緊急度を判定する。具体的には、判定機能３３２は、被検体ＤＢ３２１に格納された生体データの各々と、取得機能３３１が取得した生体データとを照合し、データ値やデータ推移等の特性が類似した生体データの予後情報を特定する。そして、判定機能３３２は、特定した予後情報の内容に基づいて緊急度を判定する。なお、取得機能３３１が取得したユーザ情報（患者ＩＤ）が被検体ＤＢ３２１に格納されている場合には、判定機能３３２は、該当する患者ＩＤの生体データ及び予後情報に基づき緊急度を判定してもよい。

ここで、緊急度は、例えば疾病種別や、処置が必要となるまでの猶予時間、処置の内容等の観点で複数段階に区分けされた、医療的な処置の緊急性を表す指標値である。緊急度の区分け方法は任意に設定することが可能であるとする。例えば、疾病種別で区分けする場合には、より重篤な疾病種別であるほど緊急度を高く設定することが好ましい。また、猶予時間で区分けする場合には、１時間等の時間単位で区分けしてもよいし、長短等の比較値で区分けしてもよい。また、処置内容で区分けする場合には、具体的な処置名で区分してもよいし、医療機関での処置の要否等の観点で区分けしてもよい。

なお、生体データから疾病種別や猶予時間、処置内容等を判定することができない場合、例えば判定機能３３２は、後述する選択機能３３３で救急搬送サービスが選択されることがないよう、最も低い緊急度を判定することが好ましい。

選択機能３３３は、選択部の一例である。選択機能３３３は、ユーザに提供可能な複数のサービスの中から、判定機能３３２の判定結果に対応するサービスを選択する。具体的には、選択機能３３３は、サービス選択テーブル３２２を参照し、判定機能３３２で判定された緊急度に対応するサービスを選択する。

図５は、サービス選択テーブル３２２のデータ構成の一例を示す図である。図５に示すように、サービス選択テーブル３２２は、緊急度と、当該緊急度に適したサービス種別とを対応付けて格納する。また、図５では、緊急度の区分例として、猶予期間及び処置内容の条件を合わせて示している。

ここで、緊急度は、その数値が低いほど緊急性が高いことを意味する。例えば、緊急度は、猶予時間がより短く、医療機関での処置が必要な処置内容であるほど高く設定される。また、サービス種別には、緊急度が高いほど、迅速且つ確実に処置することが可能なサービスが設定される。

例えば、判定機能３３２で判定された緊急度が、猶予時間「短」、処置内容「医療機関で処置要」の条件に対応する最上位の緊急度「１」には、救急車等の救急搬送サービスが対応付けて設定している。また、例えば、判定機能３３２で判定された緊急度が、猶予時間「長」、処置内容「医療機関で処置要」の条件に対応する緊急度「２」には、タクシー等の通常搬送サービスを設定している。

また、例えば、判定機能３３２で判定された緊急度が、猶予時間「短」、処置内容「医療機関で処置不要」の条件に対応する緊急度「３」には、患者宅に医師等を派遣する人材派遣サービスを設定している。また、例えば、判定機能３３２で判定された緊急度が、猶予時間「長」、処置内容「医療機関で処置不要」の条件に対応する緊急度「４」には、患者宅に薬剤を配送する薬剤配送サービスを設定している。

また、例えば、判定機能３３２で判定された緊急度が、猶予時間「不明」、処置内容「不明」の条件に対応する最下位の緊急度「５」には、より詳細に診断を行う必要があるため、遠隔診断サービスを設定している。

選択機能３３３は、サービス選択テーブル３２２を参照し、判定機能３３２で判定された緊急度に対応するサービス種別を選択する。例えば、判定機能３３２で緊急度「１」と判定された場合には、選択機能３３３は、緊急度「１」に対応付けられた「救急搬送サービス」を選択する。

図３に戻り、通知機能３３４は、通知部の一例である。通知機能３３４は、選択機能３３３の選択結果に基づいた情報を、ユーザ端末１０及び支援サーバ３０の何れか一方又は両方に通知する。

例えば、通知機能３３４は、選択機能３３３が選択したサービス種別のサービス提供システム２０に対し、ユーザ端末１０のユーザへの対応を要請する情報（要請情報）を送信する。具体的には、通知機能３３４は、サービス提供者テーブル３２３を参照し、選択機能３３３が選択したサービス種別のアドレス宛に要請情報を送信する。係る要請情報は、例えば、取得機能３３１が取得したユーザ情報や位置データ、緊急度判定に伴い導出された各種情報（疾病種別、猶予時間、処置内容）、ユーザへの対応を要請するメッセージ等を含む。また、要請情報は、ユーザに用意させる対象物を指示する情報を含んでもよい。対象物は、例えば、ユーザが排出した排出物（吐しゃ物等）等であってもよいし、薬剤の服用履歴を記した手帳や身分証明書等の物品であってもよい。

なお、選択機能３３３で選択されたサービス種別のサービス提供者が複数登録されている場合には、通知機能３３４は、それらのサービス提供者の中から一のサービス提供者を通知先として選定する。そして、選択機能３３３は、選定した通知先のアドレス（サービス提供システム２０）に要請情報を送信する。ここで、通知先の選定方法は特に問わず、例えばラウンドロビンやランダムに選定してもよい。また、例えば、取得機能３３１が取得した位置データで特定されるユーザ端末１０の位置（ユーザ位置）に基づいて、通知先のサービス提供者を選定してもよい。具体的には、通知機能３３４は、選択機能３３３で選択されたサービス種別のサービス提供者の中から、ユーザ位置をサービス提供エリアに含むサービス提供者を一つ選定する。また、ユーザ位置をサービス提供エリアに含むサービス提供者が存在しない場合には、通知機能３３４は、ユーザ位置に最も近い地域をサービス提供エリアとするサービス提供者を通知先に選定する。

サービス提供システム２０では要請情報を受信すると、要請情報に基づいた表示や報知等を行うことで、ユーザへの対応要請があったことをサービス提供者に通知する。これにより、サービス提供者は、通知されたユーザ情報や位置データに基づき、支援することが要請されたユーザや当該ユーザの位置を特定することで、搬送等の手配を容易に行うことができる。

また、通知機能３３４は、生体データを送信したユーザ端末１０に対し、選択機能３３３で選択されたサービス種別を示した支援情報を送信する。支援情報は、例えば、選択機能３３３で選択されたサービス種別の他、サービス提供者のアドレス、当該サービス種別の利用を促すメッセージ等を含んでもよい。また、支援情報は、要請情報と同様に、ユーザに用意させる対象物を指示する情報を含んでもよい。また、サービス提供者（サービス提供システム２０）に要請情報を送信する構成の場合には、通知機能３３４は、該当するサービス提供者に対応を要請済である旨を通知する情報を支援情報に含めることが好ましい。

ユーザ端末１０では受信機能１７２が支援情報を受信すると、表示機能１７３が支援情報に基づいた画面を表示デバイス１３に表示することで、ユーザの容態に適したサービス種別をユーザに通知（提示）する。これにより、ユーザ端末１０のユーザは、自己の容態に適したサービスを容易に選択したり利用したりすることができる。

次に、図６及び図７を参照して、医療支援システム１の動作について説明する。

図６は、ユーザ端末１０で実行される処理の一例を示すフローチャートである。まず、ユーザ端末１０のユーザは、医療的な処置の支援を要請する場合、入力デバイス１４を介して支援要請のための操作（支援要請操作）を行う。ユーザ端末１０では送信機能１７１が、支援要請操作の入力を待機しており（ステップＳ１１；Ｎｏ）、支援要請操作が行われると、その操作入力を受け付ける（ステップＳ１１；Ｙｅｓ）。

送信機能１７１は、支援要請操作の入力に応じて、生体データ取得回路１５を動作させることで、生体データ取得回路１５に生体データを取得させる（ステップＳ１２）。また、送信機能１７１は、位置データ取得回路１６を動作させることで、位置データ取得回路１６に位置データを取得させる（ステップＳ１３）。次いで、送信機能１７１は、ステップＳ１２及びステップＳ１３で取得された生体データ及び位置データを支援サーバ３０に送信する（ステップＳ１４）。また、送信機能１７１は、記憶回路１２に記憶されたユーザ情報を支援サーバ３０に送信する。

なお、本処理では、送信機能１７１は、支援要請操作が入力されたタイミングで生体データ取得回路１５及び位置データ取得回路１６を動作させることで、支援要請操作後に取得される生体データ及び位置データを送信する形態としたが、これに限らないものとする。例えば、送信機能１７１は、支援要請操作前に生体データ取得回路１５及び位置データ取得回路１６で取得されていた生体データを送信する形態としてもよい。

続いて、受信機能１７２は、支援サーバ３０から応答があるまで待機する（ステップＳ１５；Ｎｏ）。後述する図７の処理により支援サーバ３０から支援情報が送信されると、受信機能１７２は、支援サーバ３０からの応答として支援情報を受信する（ステップＳ１５；Ｙｅｓ）。

続いて、表示機能１７３は、受信機能１７２が受信した支援情報に基づく画面を表示デバイス１３に表示する（ステップＳ１６）。

ここで、上述したステップＳ１１〜Ｓ１４の処理は、例えば、処理回路１７が送信機能１７１に対応する所定のプログラムを記憶回路１２から読み出して実行することにより実現される。また、上述したステップＳ１５の処理は、例えば、処理回路１７が受信機能１７２に対応する所定のプログラムを記憶回路１２から読み出して実行することにより実現される。また、上述したステップＳ１６の処理は、例えば、処理回路１７が表示機能１７３に対応する所定のプログラムを記憶回路１２から読み出して実行することにより実現される。

図７は、支援サーバ３０で実行される処理の一例を示すフローチャートである。まず、支援サーバ３０の取得機能３３１は、何れかのユーザ端末１０から生体データ及び位置データが送信されるまで待機する（ステップＳ２１；Ｎｏ）。支援サーバ３０が生体データ及び位置データを受信すると（ステップＳ２１；Ｙｅｓ）、取得機能３３１は、生体データ及び位置データを取得する（ステップＳ２２）。なお、ユーザ端末１０からユーザ情報が送信された場合には、取得機能３３１は、ユーザ情報も取得する。

続いて、判定機能３３２は、取得機能３３１で取得された生体データに基づき、医療的な処置に係る緊急度を判定する（ステップＳ２３）。次いで、選択機能３３３は、判定機能３３２で判定された緊急度に対応するサービス種別を選択する（ステップＳ２４）。

続いて、通知機能３３４は、判定機能３３２で選択されたサービス種別に対応付けられているサービス提供者が単一か否かを判定する（ステップＳ２５）。サービス提供者が単一の場合には（ステップＳ２５；Ｙｅｓ）、そのサービス提供者を通知先とし、ステップＳ２８に移行する。

一方、サービス提供者が複数存在する場合には（ステップＳ２５；Ｎｏ）、通知機能３３４は、各サービス提供者のサービス提供エリアと、取得機能３３１が取得した位置データで特定されるユーザ位置とを比較する（ステップＳ２６）。次いで、通知機能３３４は、ユーザ位置をサービス提供エリアに含む一のサービス提供者を通知先とし（ステップＳ２７）、ステップＳ２８に移行する。

続いて、通知機能３３４は、ユーザの支援を要請する要請情報を、通知先としたサービス提供者のサービス提供システム２０に送信する（ステップＳ２８）。また、通知機能３３４は、選択機能３３３で選択されたサービス種別や、通知先のサービス提供者名、アドレス等を含んだ支援情報を、生体データを送信したユーザ端末１０に送信する（ステップＳ２９）。

ここで、上述したステップＳ２１、Ｓ２２の処理は、例えば、処理回路３３が取得機能３３１に対応する所定のプログラムを記憶回路３２から読み出して実行することにより実現される。また、上述したステップＳ２３の処理は、例えば、処理回路３３が判定機能３３２に対応する所定のプログラムを記憶回路３２から読み出して実行することにより実現される。また、上述したステップＳ２４の処理は、例えば、処理回路３３が選択機能３３３に対応する所定のプログラムを記憶回路３２から読み出して実行することにより実現される。また、上述したステップＳ２５〜Ｓ２９の処理は、例えば、処理回路３３が通知機能３３４に対応する所定のプログラムを記憶回路３２から読み出して実行することにより実現される。

上述したように、本実施形態では、ユーザの生体データを用いて当該ユーザの医療的な処置に係る緊急度を判定し、緊急度に対応したサービスを選択することができる。また、本実施形態では、選択したサービスに応じた通知をユーザ又は当該サービスを提供するサービス提供者に行うことができる。これにより、本実施形態では、ユーザは通知された情報に基づき自己の容態に適したサービスを容選択したり利用したりすることができる。また、本実施形態では、サービス提供者は、通知された情報に基づきユーザ支援の手配を行うことができる。

なお、上述した実施形態は、支援サーバ３０が有する構成又は機能の一部を変更することで、適宜に変形して実施することも可能である。そこで、以下では、上述した実施形態に係るいくつかの変形例を他の実施形態として説明する。ない、以下では、上述した実施形態と異なる点を主に説明することとし、既に説明した内容と共通する点については詳細な説明を省略する。また、以下で説明する変形例は、個別に実施されてもよいし、適宜組み合わせて実施されてもよい。

（変形例１）
上述した実施形態では、被検体の生体データと予後情報とが対応付けて格納された被検体ＤＢ３２１を用いて緊急度（疾患種別、猶予時間、処置内容等）を判定する例を説明したが、緊急度の判定方法はこれに限らない。例えば、複数の被検体から採取された生体データと当該被検体が罹患していた疾患種別とを対応付けて被検体ＤＢ３２１に格納しておき、当該被検体ＤＢ３２１から生体データと疾患種別との関係を学習することによって、入力された生体データから疾患種別を出力（推定）可能なＡＩ（Artificial Intelligence）等の技術を用いて判定する形態としてもよい。

この場合、例えば、判定機能３３２は、生体データと疾患種別との関係から疾患種別を推定する推定機能を具備してもよい。具体的には、判定機能３３２は、被検体ＤＢ３２１に基づき、ユーザ端末１０から取得された生体データからユーザの疾患種別を推定する。そして、判定機能３３２は、推定した疾患種別に応じた緊急度を判定する。なお、判定機能３３２は、推定した疾患種別から猶予時間や処置内容（医療機関で処置の要否等）を更に推定する構成としてもよい。

また、上述の学習により導出された学習済みモデルを用いて、疾患種別を推定する形態としてもよい。この場合、例えば、判定機能３３２は、学習済みモデルに基づき、ユーザ端末１０から取得された生体データからユーザの疾患種別を推定する。そして、判定機能３３２は、推定した疾患種別に応じた緊急度を判定する。なお、本例のように学習済みモデルを用いる場合には、被検体ＤＢ３２１は不要となるため、支援サーバ３０から被検体ＤＢ３２１を取り除いてもよい。

（変形例２）
上述した実施形態では、被検体の生体データと予後情報とが対応付けて格納された被検体ＤＢ３２１を用いて緊急度（疾患種別、猶予時間、処置内容等）を判定する例を説明したが、緊急度の判定方法はこれに限らない。例えば、生体データの類型パターンと、緊急度とを対応付けた判定テーブルを用いて、緊急度を判定する形態としてもよい。

この場合、判定機能３３２は、判定テーブルに登録された累計パターンの中から、ユーザ端末１０から取得された生体データに類似する類型パターンを特定する。そして、判定機能３３２は、特定した類型パターンに対応する緊急度を、ユーザ端末１０のユーザの緊急度として判定する。なお、本例のように判定テーブルを用いる場合には、被検体ＤＢ３２１は不要となるため、支援サーバ３０から被検体ＤＢ３２１を取り除いてもよい。

（変形例３）
上述した実施形態では、ユーザの容態を表すデータとして生体データを取得する例を説明したが、生体データ以外の他のデータを取得してもよい。例えば、容態を確認するための所定の設問に対しユーザ端末１０のユーザが回答することで得られたデータを、ユーザの容態を表すデータとして取得する形態としてもよい。

（変形例４）
上述した実施形態では、支援サーバ３０は、ユーザ端末１０に支援情報を送信した後、処理を終了する例を説明したが、支援情報を送信した後も生体データの取得を継続する形態としてもよい。

この場合、例えば、取得機能３３１は、通知機能３３４により支援情報が送信された後も、ユーザ端末１０から生体データの取得を継続する。判定機能３３２は、取得機能３３１で取得される生体データを監視し、当該生体データが変動（変化）すると変動後の生体データから緊急度を判定することで判定結果を更新する。また、選択機能３３３は、判定機能３３２の判定結果が更新された場合、更新後の緊急度に応じたサービス種別を選択する。そして、通知機能３３４は、選択機能３３３で選択されたサービス種別のサービス提供システム２０宛に要請情報を送信する。なお、この場合、通知機能３３４は、先に要請情報を送信したサービス提供システム２０宛に、要請情報のキャンセルを指示する旨の情報を送信することが好ましい。

このような構成によれば、支援情報を送信した後、ユーザの容態が急変したような場合に、当該容態に適したサービスを要請することができるため、利便性の向上を図ることができる。

（変形例５）
上述した実施形態では、入力デバイス１４を介して支援要請操作が行われた場合に、ユーザ端末１０から生体データが送信される例を説明したが、生体データが送信されるタイミングはこれに限らない。例えば、送信機能１７１は、生体データ取得回路１５で取得される生体データを監視し、当該生体データの値が閾値を超える等の異常を検出したことを条件に、当該生体データを自動で支援サーバ３０に送信する形態としてもよい。

このような構成によれば、ユーザに異常が発生すると、当該ユーザの生体データを自動で支援サーバ３０に送信することができる。したがって、ユーザ自身がユーザ端末１０を操作できないような状況であっても、ユーザの容態に適したサービスに対応を要請することができる。

（変形例６）
上述した実施形態では、生体データから疾病種別や猶予時間、処置内容等を判定できない場合に、遠隔診断サービスを選択する例を説明したが、この場合、遠隔診断サービスの診断結果を用いることで、疾病種別や猶予時間、処置内容等を判定する形態としてもよい。

この場合、例えば、取得機能３３１は、ユーザ端末１０と遠隔診断サービスとの間で行われた遠隔診断の診断結果を、ユーザ端末１０又は遠隔診断サービスのサービス提供システム２０から取得する。また、判定機能３３２は、取得機能３３１が取得した診断結果に基づいて、疾病種別や猶予時間、処置内容等を判定し、その判定結果に応じた緊急度を判定する。

このような構成によれば、生体データから疾病種別や猶予時間、処置内容等を判定できない場合であっても、より遠隔診断の診断結果を用いて緊急度の判定を行うことができるため、判定精度の向上を図ることができる。なお、上述した実施形態では、遠隔診断サービスは、支援サーバ３０とは別体としたが、支援サーバ３０自体が、遠隔診断を行うことが可能な機能（遠隔診断機能）を具備する構成としてもよい。

（変形例７）
また、上述した各実施形態では、本明細書における第１の取得部、第２の取得部、判定部、選択部及び通知部を、それぞれ、処理回路３３の取得機能３３１、判定機能３３２、選択機能３３３及び通知機能３３４によって実現する場合の例を説明したが、実施形態はこれに限られない。例えば、本明細書における第１の取得部、第２の取得部、判定部、選択部及び通知部は、実施形態で述べた取得機能３３１、判定機能３３２、選択機能３３３及び通知機能３３４によって実現する他にも、ハードウェアのみ、又は、ハードウェアとソフトウェアとの混合によって同機能を実現するものであっても構わない。また、ユーザ端末１０が有する送信機能１７１、受信機能１７２及び表示機能１７３についても、ハードウェアのみ、又は、ハードウェアとソフトウェアとの混合によって同機能を実現するものであってもよい。

なお、上述した説明で用いた「プロセッサ」という文言は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、或いは、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、プログラマブル論理デバイス（例えば、単純プログラマブル論理デバイス（Simple Programmable Logic Device：ＳＰＬＤ）、複合プログラマブル論理デバイス（Complex Programmable Logic Device：ＣＰＬＤ）、及びフィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ））等の回路を意味する。プロセッサは、記憶回路に保存されたプログラムを読み出して実行することで、機能を実現する。なお、記憶回路にプログラムを保存する代わりに、プロセッサの回路内にプログラムを直接組み込むように構成しても構わない。この場合は、プロセッサは回路内に組み込まれたプログラムを読み出して実行することで機能を実現する。また、本実施形態のプロセッサは、単一の回路として構成される場合に限らず、複数の独立した回路を組み合わせて一つのプロセッサとして構成され、その機能を実現するようにしてもよい。

ここで、プロセッサによって実行されるプログラムは、ＲＯＭ（Read Only Memory）や記憶回路等に予め組み込まれて提供される。なお、このプログラムは、これらの装置にインストール可能な形式又は実行可能な形式のファイルでＣＤ（Compact Disk）−ＲＯＭ、ＦＤ（Flexible Disk）、ＣＤ−Ｒ（Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記憶媒体に記録されて提供されてもよい。また、このプログラムは、インターネット等のネットワークに接続されたコンピュータ上に保存され、ネットワーク経由でダウンロードされることにより提供又は配布されてもよい。例えば、このプログラムは、上述した各機能部を含むモジュールで構成される。実際のハードウェアとしては、ＣＰＵが、ＲＯＭ等の記憶媒体からプログラムを読み出して実行することにより、各モジュールが主記憶装置上にロードされて、主記憶装置上に生成される。

以上説明した少なくとも１つの実施形態（変形例）によれば、ユーザの容態に適したサービスをユーザ又はサービス提供者に通知できる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これらの実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ 医療支援システム
１０ ユーザ端末
１５ 生体データ取得回路
１６ 位置データ取得回路
２０ サービス提供システム
３０ 支援サーバ
３３ 処理回路
３３１ 取得機能
３３２ 判定機能
３３３ 選択機能
３３４ 通知機能

Claims (10)

1. ユーザの容態を表すデータを取得する第１の取得部と、
   前記データに基づいて、前記ユーザの医療的な処置に係る緊急度を判定する判定部と、
   前記判定部の判定結果に基づいて、前記ユーザに提供可能な複数のサービスの中から何れかのサービスを選択する選択部と、
   前記選択部で選択されたサービスに応じた通知を行う通知部と、
   を有する医療支援システム。
2. 前記選択部は、複数段階に区分けされた前記緊急度の各々と当該緊急度に応じた前記サービスとを対応付けたデータに基づき、前記判定部で判定された緊急度に対応するサービスを選択する、請求項１に記載の医療支援システム。
3. 前記第１の取得部は、前記データとして前記ユーザの生体データを取得する、請求項１に記載の医療支援システム。
4. 前記複数のサービスは、
   医療行為を伴って前記ユーザを医療機関に搬送するサービスと、
   前記医療行為を伴わずに前記ユーザを医療機関に搬送するサービスと、
   前記ユーザのもとに人材を派遣するサービスと、
   前記ユーザのもとに薬剤を配送するサービスと、
   前記ユーザの診断を遠隔で行うサービスと、
   の何れか又は全てを含む、請求項１に記載の医療支援システム。
5. 前記第１の取得部は、前記通知部が通知を行った後も前記データを継続して取得し、
   前記判定部は、前記通知部が通知を行った後に前記データの状態が変化した場合、変化後の前記データに基づいて前記緊急度の判定結果を更新する、請求項１に記載の医療支援システム。
6. 前記通知部は、前記ユーザ又は前記サービスを提供するサービス提供者に対して通知を行う請求項１に記載の医療支援システム。
7. 前記ユーザの位置を表した位置データを取得する第２の取得部を更に有し、
   前記通知部は、前記選択部で選択されたサービスを提供するサービス提供者の中から、前記位置データが表す位置を前記サービスの提供範囲に含むサービス提供者を通知先とする、請求項６に記載の医療支援システム。
8. 前記選択部は、前記第１の取得部で取得された前記データから前記判定部が前記緊急度を判定することができない場合に、前記ユーザの診断を遠隔で行うサービスを選択し、
   前記判定部は、前記選択部が選択したサービスによって得られた診断結果に基づいて、前記緊急度を判定する、請求項１〜６の何れか一項に記載の医療支援システム。
9. 取得部が、ユーザの容態を表すデータを取得するステップと、
   判定部が、前記データに基づいて、前記ユーザの医療的な処置に係る緊急度を判定するステップと、
   選択部が、前記緊急度の判定結果に基づいて、前記ユーザに提供可能な複数のサービスの中から何れかのサービスを選択するステップと、
   通知部が、前記選択部で選択されたサービスに応じた通知を行うステップと、
   を含む医療支援方法。
10. ユーザの容態を表すデータに基づいて、前記ユーザの医療的な処置に係る緊急度を判定する判定機能と、
    前記判定機能の判定結果に基づいて、前記ユーザに提供可能な複数のサービスの中から何れかのサービスを選択する選択機能と、
    前記選択機能で選択されたサービスに応じた通知を行う通知機能と、
    をコンピュータに実現させるためのプログラム。

Images