IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 東芝メディカルシステムズ株式会社の特許一覧

特許7406924医療支援システム、医療支援方法及びプログラム
<>
  • 特許-医療支援システム、医療支援方法及びプログラム 図1
  • 特許-医療支援システム、医療支援方法及びプログラム 図2
  • 特許-医療支援システム、医療支援方法及びプログラム 図3
  • 特許-医療支援システム、医療支援方法及びプログラム 図4
  • 特許-医療支援システム、医療支援方法及びプログラム 図5
  • 特許-医療支援システム、医療支援方法及びプログラム 図6
  • 特許-医療支援システム、医療支援方法及びプログラム 図7
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-20
(45)【発行日】2023-12-28
(54)【発明の名称】医療支援システム、医療支援方法及びプログラム
(51)【国際特許分類】
   G16H 50/30 20180101AFI20231221BHJP
【FI】
G16H50/30
【請求項の数】 9
(21)【出願番号】P 2019074068
(22)【出願日】2019-04-09
(65)【公開番号】P2020173530
(43)【公開日】2020-10-22
【審査請求日】2022-03-02
【前置審査】
(73)【特許権者】
【識別番号】594164542
【氏名又は名称】キヤノンメディカルシステムズ株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】重田 高志
(72)【発明者】
【氏名】杉山 敦子
(72)【発明者】
【氏名】丹羽 慎太朗
(72)【発明者】
【氏名】宇都宮 和樹
(72)【発明者】
【氏名】橋本 敬介
【審査官】今井 悠太
(56)【参考文献】
【文献】特開2018-033660(JP,A)
【文献】特開2004-046450(JP,A)
【文献】特開2009-187167(JP,A)
【文献】特開2007-128245(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G16H 10/00-80/00
(57)【特許請求の範囲】
【請求項1】
ユーザの容態を表すデータを取得する第1の取得部と、
前記データから医療機関での処置の要否と、処置に係る猶予時間とを判定し、当該判定結果に基づいて前記ユーザの医療的な処置に係る緊急度を判定する判定部と、
医療機関での処置が要と判定されると、前記緊急度に基づいて、医療行為を伴って前記ユーザを医療機関に搬送するサービスと、医療行為を伴わずに前記ユーザを医療機関に搬送するサービスとの中から、前記ユーザに提供するサービスを選択し、医療機関での処置が不要と判定されると、前記緊急度に基づいて、前記ユーザのもとに人材を派遣するサービスと、前記ユーザのもとに薬剤を配送するサービスと、前記ユーザの診断を遠隔で行うサービスとの中から、前記ユーザに提供するサービスを選択する選択部と、
前記選択部で選択されたサービスに応じた通知を行う通知部と、
を有する医療支援システム。
【請求項2】
前記選択部は、複数段階に区分けされた前記緊急度の各々と当該緊急度に応じた前記サービスとを対応付けたデータに基づき、前記判定部で判定された緊急度に対応するサービスを選択する、請求項1に記載の医療支援システム。
【請求項3】
前記第1の取得部は、前記データとして前記ユーザの生体データを取得する、請求項1に記載の医療支援システム。
【請求項4】
前記第1の取得部は、前記通知部が通知を行った後も前記データを継続して取得し、
前記判定部は、前記通知部が通知を行った後に前記データの状態が変化した場合、変化後の前記データに基づいて前記緊急度の判定結果を更新する、請求項1に記載の医療支援システム。
【請求項5】
前記通知部は、前記ユーザ又は前記サービスを提供するサービス提供者に対して通知を行う請求項1に記載の医療支援システム。
【請求項6】
前記ユーザの位置を表した位置データを取得する第2の取得部を更に有し、
前記通知部は、前記選択部で選択されたサービスを提供するサービス提供者の中から、前記位置データが表す位置を前記サービスの提供範囲に含むサービス提供者を通知先とする、請求項に記載の医療支援システム。
【請求項7】
前記選択部は、前記第1の取得部で取得された前記データから前記判定部が前記緊急度を判定することができない場合に、前記ユーザの診断を遠隔で行うサービスを選択し、
前記判定部は、前記選択部が選択したサービスによって得られた診断結果に基づいて、前記緊急度を判定する、請求項1~の何れか一項に記載の医療支援システム。
【請求項8】
取得部が、ユーザの容態を表すデータを取得するステップと、
判定部が、前記データから医療機関での処置の要否と、処置に係る猶予時間とを判定し、当該判定結果に基づいて前記ユーザの医療的な処置に係る緊急度を判定するステップと、
選択部が、医療機関での処置が要と判定されると、前記緊急度に基づいて、医療行為を伴って前記ユーザを医療機関に搬送するサービスと、医療行為を伴わずに前記ユーザを医療機関に搬送するサービスとの中から、前記ユーザに提供するサービスを選択し、医療機関での処置が不要と判定されると、前記緊急度に基づいて、前記ユーザのもとに人材を派遣するサービスと、前記ユーザのもとに薬剤を配送するサービスと、前記ユーザの診断を遠隔で行うサービスとの中から、前記ユーザに提供するサービスを選択するステップと、
通知部が、前記選択部で選択されたサービスに応じた通知を行うステップと、
を含む医療支援方法。
【請求項9】
ユーザの容態を表すデータから医療機関での処置の要否と、処置に係る猶予時間とを判定し、当該判定結果に基づいて、前記ユーザの医療的な処置に係る緊急度を判定する判定機能と、
医療機関での処置が要と判定されると、前記緊急度に基づいて、医療行為を伴って前記ユーザを医療機関に搬送するサービスと、医療行為を伴わずに前記ユーザを医療機関に搬送するサービスとの中から、前記ユーザに提供するサービスを選択し、医療機関での処置が不要と判定されると、前記緊急度に基づいて、前記ユーザのもとに人材を派遣するサービスと、前記ユーザのもとに薬剤を配送するサービスと、前記ユーザの診断を遠隔で行うサービスとの中から、前記ユーザに提供するサービスを選択する選択機能と、
前記選択機能で選択されたサービスに応じた通知を行う通知機能と、
をコンピュータに実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、医療支援システム、医療支援方法及びプログラムに関する。
【背景技術】
【0002】
従来、医療的な処置を希望又は必要とするユーザを、救急車やドクターヘリ等を用いて、病院に搬送(救急搬送)することが行われている。また、例えば、ユーザ自身が救急搬送を依頼すべきかどうか迷うような場合に、設問に対して回答することで救急搬送の要否判断の参考となる情報を提供するシステムも提案されている。一方、近年では軽症のユーザがタクシー代りに救急車を利用する等、不要不急の要請が増加している。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2013-41479号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明が解決しようとする課題は、ユーザの容態に適したサービスを通知できるようにすることである。
【課題を解決するための手段】
【0005】
実施形態に係る医療支援システムは、第1の取得部と、判定部と、選択部と、通知部とを備える。第1の取得部は、ユーザの容態を表すデータを取得する。判定部は、前記データから医療機関での処置の要否と、処置に係る猶予時間とを判定し、当該判定結果に基づいて前記ユーザの医療的な処置に係る緊急度を判定する。選択部は、医療機関での処置が要と判定されると、前記緊急度に基づいて、医療行為を伴って前記ユーザを医療機関に搬送するサービスと、医療行為を伴わずに前記ユーザを医療機関に搬送するサービスとの中から、前記ユーザに提供するサービスを選択し、医療機関での処置が不要と判定されると、前記緊急度に基づいて、前記ユーザのもとに人材を派遣するサービスと、前記ユーザのもとに薬剤を配送するサービスと、前記ユーザの診断を遠隔で行うサービスとの中から、前記ユーザに提供するサービスを選択する。通知部は、前記選択部で選択されたサービスに応じた通知を行う。
【図面の簡単な説明】
【0006】
図1図1は、実施形態に係る医療支援システムの構成例を示す図である。
図2図2は、実施形態に係るユーザ端末の構成例を示す図である。
図3図3は、実施形態に係る医療支援サーバの構成例を示す図である。
図4図4は、実施形態に係るサービス提供者テーブルのデータ構成の一例を示す図である。
図5図5は、実施形態に係るサービス選択テーブル構成の一例を示す図である。
図6図6は、実施形態のユーザ端末で実行される処理の一例を示すフローチャートである。
図7図7は、実施形態の医療支援サーバで実行される処理の一例を示すフローチャートである。
【発明を実施するための形態】
【0007】
以下、図面を参照しながら、医療支援システム、医療支援方法及びプログラムの実施形態について詳細に説明する。
【0008】
図1は、本実施形態に係る医療支援システム1の構成例を示す図である。図1に示すように、医療支援システム1は、ユーザ端末10と、サービス提供システム20と、支援サーバ30とを有する。ここで、各システム及び各装置は、インターネット等のネットワークNを介して通信可能に接続される。なお、ネットワークNに接続されるユーザ端末10及びサービス提供システム20の個数は、特に問わないものとする。
【0009】
ユーザ端末10は、医療支援システム1のユーザが所持する端末装置である。ユーザ端末10は、ユーザの生体データを取得することが可能な機能及び構成を有している。ユーザ端末10は、例えば、スマートフォンやスマートウォッチ、生体センサ装置等のコンピュータ機器によって実現される。
【0010】
サービス提供システム20は、ユーザの搬送や処置に係る各種のサービス提供者が管理するシステムである。サービス提供システム20は、支援サーバ30からサービスの提供を要請する要請情報を受け付け、受け付けた要請情報に基づいてユーザ端末10のユーザに対しサービスを提供する。サービス提供システム20は、例えば、サーバやワークステーション等のコンピュータ機器によって実現される。
【0011】
ここで、患者の搬送に係るサービスとしては、消防機関等が提供する救急車やドクターヘリ等の医療行為を伴う救急搬送サービスや、タクシー会社等が提供する医療行為を伴わない通常搬送サービス等が挙げられる。また、患者の処置に係るサービスとしては、在宅医療機関等が提供する医師やヘルパー等の人材を患者宅に派遣する人材派遣サービス、薬剤配送業者等が提供する薬剤を患者宅に配送する薬剤配送サービス、医療機関等が提供する患者の状態を遠隔で診断する遠隔診断サービス等が挙げられる。
【0012】
本実施形態の医療支援システム1は、上述したサービス種別のサービス提供システム20を含むものとする。なお、同一種別のサービスであっても、サービス提供者が相違する場合や、サービス提供者がサービスを提供する範囲(サービス提供エリア)が異なる場合には、サービス提供者毎にサービス提供システム20が用意されるものとする。
【0013】
支援サーバ30は、医療支援システム1の主要な動作を制御する。具体的には、支援サーバ30は、ユーザ端末10で取得された生体データに基づき、ユーザ端末10を所持するユーザの医療的な処置の緊急度を判定する。また、支援サーバ30は、緊急度の判定結果に適したサービス提供者(サービス提供システム20)を選定する。そして、支援サーバ30は、選定したサービス提供者をユーザ端末10のユーザに通知したり、ユーザ端末10のユーザに対するサービスの提供を選定したサービス提供者に要請したりする。支援サーバ30は、例えば、サーバ装置やワークステーション等のコンピュータ機器によって実現される。なお、支援サーバ30は、単一の装置に限らず、ネットワーク接続された複数のコンピュータ機器の協働(例えばクラウドコンピューティング)により実現される形態としてもよい。
【0014】
次に、上述したユーザ端末10及び支援サーバ30の構成について説明する。
【0015】
図2は、ユーザ端末10の構成例を示すブロック図である。図2に示すように、ユーザ端末10は、通信インタフェース11と、記憶回路12と、表示デバイス13と、入力デバイス14と、生体データ取得回路15と、位置データ取得回路16と、処理回路17とを備える。
【0016】
通信インタフェース11は、外部装置(サービス提供システム20、支援サーバ30)との間で行われる通信を制御する。具体的には、通信インタフェース11は、処理回路17の制御の下、外部装置との間で各種データや情報の送受信を行う。通信インタフェース11は、例えば、ネットワークカードやネットワークアダプタ、NIC(Network Interface Controller)等によって実現される。
【0017】
記憶回路12は、処理回路17が実行する各種のプログラムや、ユーザ端末10の動作に関する各種の設定情報等を記憶する。また、記憶回路12は、自己のユーザ端末10を所持するユーザに関するユーザ情報を記憶する。ユーザ情報は、例えばユーザの氏名、年齢、性別、患者ID、住所、連絡先等を含む。記憶回路12は、例えば、RAM(Random Access Memory)、フラッシュメモリ等の半導体メモリ素子や、ハードディスク、光ディスク等によって実現される。
【0018】
表示デバイス13は、処理回路17の制御の下、各種の情報及び画像を表示する。具体的には、表示デバイス13は、処理回路17から送られる情報及び画像のデータを表示用の電気信号に変換して出力する。表示デバイス13は、例えば、液晶ディスプレイやCRT(Cathode Ray Tube)モニタ等によって実現される。
【0019】
入力デバイス14は、ユーザから各種の入力操作を受け付ける。具体的には、入力デバイス14は、操作者から受け付けた入力操作を電気信号に変換して処理回路17に出力する。入力デバイス14は、例えば、トラックボール、スイッチボタン、マウス、キーボード、操作面へ触れることで入力操作を行うタッチパッド、表示デバイス13の表示画面上に設けられるタッチスクリーン、光学センサを用いた非接触入力回路、音声入力回路等によって実現される。なお、本実施形態において、入力デバイス14は、マウス、キーボード等の物理的な操作部品を備えるものだけに限られない。例えば、ユーザ端末10とは別体に設けられた外部の入力機器から入力操作に対応する電気信号を受け取り、この電気信号を処理回路17に入力する入力回路も入力デバイス14の例に含まれる。
【0020】
生体データ取得回路15は、ユーザの容態を表すデータを取得する。具体的には、生体データ取得回路15は、ユーザの血圧や体温、心拍、脈波等の生体データを採取し、採取した生体データを処理回路17に出力する。生体データ取得回路15は、例えば、血圧や体温、心拍、脈波等の生体データを採取可能な各種のセンシング回路によって実現される。なお、本実施形態において、生体データ取得回路15は、センシング回路等の物理的な部品を備えるものだけに限られない。例えば、ユーザ端末10とは別体に設けられた外部のセンシング回路で採取された生体データを受け取り、この生体データを処理回路17に入力する入力回路も生体データ取得回路15の例に含まれる。また、医療支援システム1全体で生体データの取得を捉える場合、生体データ取得回路15は、第1の取得部の一例として機能する。
【0021】
位置データ取得回路16は、ユーザ端末10の存在位置を示す位置データを取得する。具体的には、位置データ取得回路16は、ユーザ端末10の存在位置を示す緯度経度などの位置データを取得し、取得した位置データを処理回路17に出力する。位置データ取得回路16は、例えば、GPS(Global Positioning System)等の位置測定回路によって実現される。なお、本実施形態において、位置データ取得回路16は、位置測定回路等の物理的な部品を備えるものだけに限られない。例えば、ユーザ端末10とは別体に設けられた外部の位置測定回路で採取された位置データを受け取り、この位置データを処理回路17に入力する入力回路も位置データ取得回路16の例に含まれる。また、医療支援システム1全体で位置データの取得を捉える場合、位置データ取得回路16は、第2の取得部の一例として機能する。
【0022】
処理回路17は、入力デバイス14を介してユーザから受け付けた入力操作に応じて、ユーザ端末10の動作を制御する。処理回路17は、例えば、プロセッサによって実現される。また、処理回路17は、送信機能171と、表示機能173とを有する。
【0023】
送信機能171は、通信インタフェース11と協働することで、外部装置(サービス提供システム20、支援サーバ30)に対し各種のデータや情報を送信する。例えば、送信機能171は、生体データ取得回路15で取得された生体データを支援サーバ30に送信する。また、送信機能171は、記憶回路12に記憶されたユーザ情報や、位置データ取得回路16で取得された位置データを、生体データとともに支援サーバ30に送信する。
【0024】
なお、送信機能171が、生体データ等を送信するタイミングは特に問わず、任意に設定することが可能である。例えば、送信機能171は、入力デバイス14を介して所定の操作(支援要請操作)の入力を受け付けると、生体データ等を支援サーバ30に送信する。
【0025】
受信機能172は、通信インタフェース11と協働することで、外部装置(サービス提供システム20、支援サーバ30)から自装置宛に送信された各種のデータや情報を受信する。例えば、受信機能172は、支援サーバ30から送信される支援情報を受信する。
【0026】
表示機能173は、表示デバイス13に表示する画面を制御する。例えば、表示機能173は、受信機能172が支援サーバ30から受信した支援情報に基づく画面を表示デバイス13に表示させる。また、例えば、表示機能173は、遠隔診断サービス等のサービス提供システム20から提供される情報に基づく画面を表示デバイス13に表示させる。
【0027】
図3は、支援サーバ30の構成例を示す図である。図3に示すように、支援サーバ30は、通信インタフェース31と、記憶回路32と、処理回路33とを備える。
【0028】
通信インタフェース31は、外部装置(ユーザ端末10、サービス提供システム20)との間で行われる通信を制御する。具体的には、通信インタフェース31は、処理回路33の制御の下、外部装置との間で各種データや情報の送受信を行う。通信インタフェース31は、例えば、ネットワークカードやネットワークアダプタ、NIC等によって実現される。
【0029】
記憶回路32は、処理回路33が実行する各種のプログラムや、支援サーバ30の動作に関する各種の設定情報等を記憶する。記憶回路32は、例えば、RAM、フラッシュメモリ等の半導体メモリ素子や、ハードディスク、光ディスク等によって実現される。
【0030】
また、記憶回路32は、複数の被検体から採取された生体データを格納した被検体DB(データベース)321を記憶する。具体的には、被検体DB321は、複数の被検体から採取された生体データと、当該被検体の予後の状態等を表す予後情報とを対応付けて格納する。ここで、被検体は、不特定多数とするが、医療支援システム1のユーザ、つまりユーザ端末10を所持するユーザを含んでもよい。なお、医療支援システム1のユーザを含める場合には、ユーザを特定できるよう、各ユーザを識別することが可能な識別子(患者ID)を生体データ及び予後情報と対応付けて格納する。
【0031】
また、記憶回路32は、複数段階に区分けされた緊急度の各々と、当該緊急度に応じたサービス(サービス種別)とを対応付けたデータの一例として、サービス選択テーブル322(図5参照)を記憶する。また、記憶回路32は、サービス提供者に関する情報を格納したサービス提供者テーブル323を記憶する。
【0032】
ここで、図4は、サービス提供者テーブル323のデータ構成の一例を示す図である。図4に示すように、サービス提供者テーブル323は、サービス種別と、サービス提供者名と、アドレスと、サービス提供エリアとを対応付けて記憶する。
【0033】
サービス種別には、ユーザに提供することが可能なサービスのサービス種別が格納される。具体的には、サービス種別には、救急搬送や一般搬送等のサービスの種別を示す情報が格納される。サービス提供者名には、サービスを提供するサービス提供者の組織名や会社名等が格納される。アドレスには、サービス提供システム20のアドレスや、電話番号、住所等の情報が格納される。サービス提供エリアには、サービスを提供する範囲(地域)を特定可能な情報が格納される。なお、図4では、サービス提供エリアを問わないものについては、サービス提供エリアの欄をヌル(空)としている。
【0034】
図3に戻り、処理回路33は、支援サーバ30の動作を制御する。処理回路33は、例えば、プロセッサによって実現される。また、処理回路33は、取得機能331と、判定機能332と、選択機能333と、通知機能334とを機能部として備える。
【0035】
取得機能331は、通信インタフェース31と協働することで、ユーザ端末10やサービス提供システム20から送信された各種のデータや情報を取得する。具体的には、取得機能331は、ユーザ端末10から生体データやユーザ情報、位置データが送信された場合に、送信されたデータ及び情報を取得する。なお、支援サーバ30単体で生体データ及び位置データの取得を捉える場合、取得機能331は、第1の取得部及び第2の取得部の一例として機能する。
【0036】
判定機能332は、判定部の一例である。判定機能332は、取得機能331が取得した生体データに基づいて、医療的な処置の緊急度を判定する。具体的には、判定機能332は、被検体DB321に格納された生体データの各々と、取得機能331が取得した生体データとを照合し、データ値やデータ推移等の特性が類似した生体データの予後情報を特定する。そして、判定機能332は、特定した予後情報の内容に基づいて緊急度を判定する。なお、取得機能331が取得したユーザ情報(患者ID)が被検体DB321に格納されている場合には、判定機能332は、該当する患者IDの生体データ及び予後情報に基づき緊急度を判定してもよい。
【0037】
ここで、緊急度は、例えば疾病種別や、処置が必要となるまでの猶予時間、処置の内容等の観点で複数段階に区分けされた、医療的な処置の緊急性を表す指標値である。緊急度の区分け方法は任意に設定することが可能であるとする。例えば、疾病種別で区分けする場合には、より重篤な疾病種別であるほど緊急度を高く設定することが好ましい。また、猶予時間で区分けする場合には、1時間等の時間単位で区分けしてもよいし、長短等の比較値で区分けしてもよい。また、処置内容で区分けする場合には、具体的な処置名で区分してもよいし、医療機関での処置の要否等の観点で区分けしてもよい。
【0038】
なお、生体データから疾病種別や猶予時間、処置内容等を判定することができない場合、例えば判定機能332は、後述する選択機能333で救急搬送サービスが選択されることがないよう、最も低い緊急度を判定することが好ましい。
【0039】
選択機能333は、選択部の一例である。選択機能333は、ユーザに提供可能な複数のサービスの中から、判定機能332の判定結果に対応するサービスを選択する。具体的には、選択機能333は、サービス選択テーブル322を参照し、判定機能332で判定された緊急度に対応するサービスを選択する。
【0040】
図5は、サービス選択テーブル322のデータ構成の一例を示す図である。図5に示すように、サービス選択テーブル322は、緊急度と、当該緊急度に適したサービス種別とを対応付けて格納する。また、図5では、緊急度の区分例として、猶予期間及び処置内容の条件を合わせて示している。
【0041】
ここで、緊急度は、その数値が低いほど緊急性が高いことを意味する。例えば、緊急度は、猶予時間がより短く、医療機関での処置が必要な処置内容であるほど高く設定される。また、サービス種別には、緊急度が高いほど、迅速且つ確実に処置することが可能なサービスが設定される。
【0042】
例えば、判定機能332で判定された緊急度が、猶予時間「短」、処置内容「医療機関で処置要」の条件に対応する最上位の緊急度「1」には、救急車等の救急搬送サービスが対応付けて設定している。また、例えば、判定機能332で判定された緊急度が、猶予時間「長」、処置内容「医療機関で処置要」の条件に対応する緊急度「2」には、タクシー等の通常搬送サービスを設定している。
【0043】
また、例えば、判定機能332で判定された緊急度が、猶予時間「短」、処置内容「医療機関で処置不要」の条件に対応する緊急度「3」には、患者宅に医師等を派遣する人材派遣サービスを設定している。また、例えば、判定機能332で判定された緊急度が、猶予時間「長」、処置内容「医療機関で処置不要」の条件に対応する緊急度「4」には、患者宅に薬剤を配送する薬剤配送サービスを設定している。
【0044】
また、例えば、判定機能332で判定された緊急度が、猶予時間「不明」、処置内容「不明」の条件に対応する最下位の緊急度「5」には、より詳細に診断を行う必要があるため、遠隔診断サービスを設定している。
【0045】
選択機能333は、サービス選択テーブル322を参照し、判定機能332で判定された緊急度に対応するサービス種別を選択する。例えば、判定機能332で緊急度「1」と判定された場合には、選択機能333は、緊急度「1」に対応付けられた「救急搬送サービス」を選択する。
【0046】
図3に戻り、通知機能334は、通知部の一例である。通知機能334は、選択機能333の選択結果に基づいた情報を、ユーザ端末10及び支援サーバ30の何れか一方又は両方に通知する。
【0047】
例えば、通知機能334は、選択機能333が選択したサービス種別のサービス提供システム20に対し、ユーザ端末10のユーザへの対応を要請する情報(要請情報)を送信する。具体的には、通知機能334は、サービス提供者テーブル323を参照し、選択機能333が選択したサービス種別のアドレス宛に要請情報を送信する。係る要請情報は、例えば、取得機能331が取得したユーザ情報や位置データ、緊急度判定に伴い導出された各種情報(疾病種別、猶予時間、処置内容)、ユーザへの対応を要請するメッセージ等を含む。また、要請情報は、ユーザに用意させる対象物を指示する情報を含んでもよい。対象物は、例えば、ユーザが排出した排出物(吐しゃ物等)等であってもよいし、薬剤の服用履歴を記した手帳や身分証明書等の物品であってもよい。
【0048】
なお、選択機能333で選択されたサービス種別のサービス提供者が複数登録されている場合には、通知機能334は、それらのサービス提供者の中から一のサービス提供者を通知先として選定する。そして、選択機能333は、選定した通知先のアドレス(サービス提供システム20)に要請情報を送信する。ここで、通知先の選定方法は特に問わず、例えばラウンドロビンやランダムに選定してもよい。また、例えば、取得機能331が取得した位置データで特定されるユーザ端末10の位置(ユーザ位置)に基づいて、通知先のサービス提供者を選定してもよい。具体的には、通知機能334は、選択機能333で選択されたサービス種別のサービス提供者の中から、ユーザ位置をサービス提供エリアに含むサービス提供者を一つ選定する。また、ユーザ位置をサービス提供エリアに含むサービス提供者が存在しない場合には、通知機能334は、ユーザ位置に最も近い地域をサービス提供エリアとするサービス提供者を通知先に選定する。
【0049】
サービス提供システム20では要請情報を受信すると、要請情報に基づいた表示や報知等を行うことで、ユーザへの対応要請があったことをサービス提供者に通知する。これにより、サービス提供者は、通知されたユーザ情報や位置データに基づき、支援することが要請されたユーザや当該ユーザの位置を特定することで、搬送等の手配を容易に行うことができる。
【0050】
また、通知機能334は、生体データを送信したユーザ端末10に対し、選択機能333で選択されたサービス種別を示した支援情報を送信する。支援情報は、例えば、選択機能333で選択されたサービス種別の他、サービス提供者のアドレス、当該サービス種別の利用を促すメッセージ等を含んでもよい。また、支援情報は、要請情報と同様に、ユーザに用意させる対象物を指示する情報を含んでもよい。また、サービス提供者(サービス提供システム20)に要請情報を送信する構成の場合には、通知機能334は、該当するサービス提供者に対応を要請済である旨を通知する情報を支援情報に含めることが好ましい。
【0051】
ユーザ端末10では受信機能172が支援情報を受信すると、表示機能173が支援情報に基づいた画面を表示デバイス13に表示することで、ユーザの容態に適したサービス種別をユーザに通知(提示)する。これにより、ユーザ端末10のユーザは、自己の容態に適したサービスを容易に選択したり利用したりすることができる。
【0052】
次に、図6及び図7を参照して、医療支援システム1の動作について説明する。
【0053】
図6は、ユーザ端末10で実行される処理の一例を示すフローチャートである。まず、ユーザ端末10のユーザは、医療的な処置の支援を要請する場合、入力デバイス14を介して支援要請のための操作(支援要請操作)を行う。ユーザ端末10では送信機能171が、支援要請操作の入力を待機しており(ステップS11;No)、支援要請操作が行われると、その操作入力を受け付ける(ステップS11;Yes)。
【0054】
送信機能171は、支援要請操作の入力に応じて、生体データ取得回路15を動作させることで、生体データ取得回路15に生体データを取得させる(ステップS12)。また、送信機能171は、位置データ取得回路16を動作させることで、位置データ取得回路16に位置データを取得させる(ステップS13)。次いで、送信機能171は、ステップS12及びステップS13で取得された生体データ及び位置データを支援サーバ30に送信する(ステップS14)。また、送信機能171は、記憶回路12に記憶されたユーザ情報を支援サーバ30に送信する。
【0055】
なお、本処理では、送信機能171は、支援要請操作が入力されたタイミングで生体データ取得回路15及び位置データ取得回路16を動作させることで、支援要請操作後に取得される生体データ及び位置データを送信する形態としたが、これに限らないものとする。例えば、送信機能171は、支援要請操作前に生体データ取得回路15及び位置データ取得回路16で取得されていた生体データを送信する形態としてもよい。
【0056】
続いて、受信機能172は、支援サーバ30から応答があるまで待機する(ステップS15;No)。後述する図7の処理により支援サーバ30から支援情報が送信されると、受信機能172は、支援サーバ30からの応答として支援情報を受信する(ステップS15;Yes)。
【0057】
続いて、表示機能173は、受信機能172が受信した支援情報に基づく画面を表示デバイス13に表示する(ステップS16)。
【0058】
ここで、上述したステップS11~S14の処理は、例えば、処理回路17が送信機能171に対応する所定のプログラムを記憶回路12から読み出して実行することにより実現される。また、上述したステップS15の処理は、例えば、処理回路17が受信機能172に対応する所定のプログラムを記憶回路12から読み出して実行することにより実現される。また、上述したステップS16の処理は、例えば、処理回路17が表示機能173に対応する所定のプログラムを記憶回路12から読み出して実行することにより実現される。
【0059】
図7は、支援サーバ30で実行される処理の一例を示すフローチャートである。まず、支援サーバ30の取得機能331は、何れかのユーザ端末10から生体データ及び位置データが送信されるまで待機する(ステップS21;No)。支援サーバ30が生体データ及び位置データを受信すると(ステップS21;Yes)、取得機能331は、生体データ及び位置データを取得する(ステップS22)。なお、ユーザ端末10からユーザ情報が送信された場合には、取得機能331は、ユーザ情報も取得する。
【0060】
続いて、判定機能332は、取得機能331で取得された生体データに基づき、医療的な処置に係る緊急度を判定する(ステップS23)。次いで、選択機能333は、判定機能332で判定された緊急度に対応するサービス種別を選択する(ステップS24)。
【0061】
続いて、通知機能334は、判定機能332で選択されたサービス種別に対応付けられているサービス提供者が単一か否かを判定する(ステップS25)。サービス提供者が単一の場合には(ステップS25;Yes)、そのサービス提供者を通知先とし、ステップS28に移行する。
【0062】
一方、サービス提供者が複数存在する場合には(ステップS25;No)、通知機能334は、各サービス提供者のサービス提供エリアと、取得機能331が取得した位置データで特定されるユーザ位置とを比較する(ステップS26)。次いで、通知機能334は、ユーザ位置をサービス提供エリアに含む一のサービス提供者を通知先とし(ステップS27)、ステップS28に移行する。
【0063】
続いて、通知機能334は、ユーザの支援を要請する要請情報を、通知先としたサービス提供者のサービス提供システム20に送信する(ステップS28)。また、通知機能334は、選択機能333で選択されたサービス種別や、通知先のサービス提供者名、アドレス等を含んだ支援情報を、生体データを送信したユーザ端末10に送信する(ステップS29)。
【0064】
ここで、上述したステップS21、S22の処理は、例えば、処理回路33が取得機能331に対応する所定のプログラムを記憶回路32から読み出して実行することにより実現される。また、上述したステップS23の処理は、例えば、処理回路33が判定機能332に対応する所定のプログラムを記憶回路32から読み出して実行することにより実現される。また、上述したステップS24の処理は、例えば、処理回路33が選択機能333に対応する所定のプログラムを記憶回路32から読み出して実行することにより実現される。また、上述したステップS25~S29の処理は、例えば、処理回路33が通知機能334に対応する所定のプログラムを記憶回路32から読み出して実行することにより実現される。
【0065】
上述したように、本実施形態では、ユーザの生体データを用いて当該ユーザの医療的な処置に係る緊急度を判定し、緊急度に対応したサービスを選択することができる。また、本実施形態では、選択したサービスに応じた通知をユーザ又は当該サービスを提供するサービス提供者に行うことができる。これにより、本実施形態では、ユーザは通知された情報に基づき自己の容態に適したサービスを容選択したり利用したりすることができる。また、本実施形態では、サービス提供者は、通知された情報に基づきユーザ支援の手配を行うことができる。
【0066】
なお、上述した実施形態は、支援サーバ30が有する構成又は機能の一部を変更することで、適宜に変形して実施することも可能である。そこで、以下では、上述した実施形態に係るいくつかの変形例を他の実施形態として説明する。ない、以下では、上述した実施形態と異なる点を主に説明することとし、既に説明した内容と共通する点については詳細な説明を省略する。また、以下で説明する変形例は、個別に実施されてもよいし、適宜組み合わせて実施されてもよい。
【0067】
(変形例1)
上述した実施形態では、被検体の生体データと予後情報とが対応付けて格納された被検体DB321を用いて緊急度(疾患種別、猶予時間、処置内容等)を判定する例を説明したが、緊急度の判定方法はこれに限らない。例えば、複数の被検体から採取された生体データと当該被検体が罹患していた疾患種別とを対応付けて被検体DB321に格納しておき、当該被検体DB321から生体データと疾患種別との関係を学習することによって、入力された生体データから疾患種別を出力(推定)可能なAI(Artificial Intelligence)等の技術を用いて判定する形態としてもよい。
【0068】
この場合、例えば、判定機能332は、生体データと疾患種別との関係から疾患種別を推定する推定機能を具備してもよい。具体的には、判定機能332は、被検体DB321に基づき、ユーザ端末10から取得された生体データからユーザの疾患種別を推定する。そして、判定機能332は、推定した疾患種別に応じた緊急度を判定する。なお、判定機能332は、推定した疾患種別から猶予時間や処置内容(医療機関で処置の要否等)を更に推定する構成としてもよい。
【0069】
また、上述の学習により導出された学習済みモデルを用いて、疾患種別を推定する形態としてもよい。この場合、例えば、判定機能332は、学習済みモデルに基づき、ユーザ端末10から取得された生体データからユーザの疾患種別を推定する。そして、判定機能332は、推定した疾患種別に応じた緊急度を判定する。なお、本例のように学習済みモデルを用いる場合には、被検体DB321は不要となるため、支援サーバ30から被検体DB321を取り除いてもよい。
【0070】
(変形例2)
上述した実施形態では、被検体の生体データと予後情報とが対応付けて格納された被検体DB321を用いて緊急度(疾患種別、猶予時間、処置内容等)を判定する例を説明したが、緊急度の判定方法はこれに限らない。例えば、生体データの類型パターンと、緊急度とを対応付けた判定テーブルを用いて、緊急度を判定する形態としてもよい。
【0071】
この場合、判定機能332は、判定テーブルに登録された累計パターンの中から、ユーザ端末10から取得された生体データに類似する類型パターンを特定する。そして、判定機能332は、特定した類型パターンに対応する緊急度を、ユーザ端末10のユーザの緊急度として判定する。なお、本例のように判定テーブルを用いる場合には、被検体DB321は不要となるため、支援サーバ30から被検体DB321を取り除いてもよい。
【0072】
(変形例3)
上述した実施形態では、ユーザの容態を表すデータとして生体データを取得する例を説明したが、生体データ以外の他のデータを取得してもよい。例えば、容態を確認するための所定の設問に対しユーザ端末10のユーザが回答することで得られたデータを、ユーザの容態を表すデータとして取得する形態としてもよい。
【0073】
(変形例4)
上述した実施形態では、支援サーバ30は、ユーザ端末10に支援情報を送信した後、処理を終了する例を説明したが、支援情報を送信した後も生体データの取得を継続する形態としてもよい。
【0074】
この場合、例えば、取得機能331は、通知機能334により支援情報が送信された後も、ユーザ端末10から生体データの取得を継続する。判定機能332は、取得機能331で取得される生体データを監視し、当該生体データが変動(変化)すると変動後の生体データから緊急度を判定することで判定結果を更新する。また、選択機能333は、判定機能332の判定結果が更新された場合、更新後の緊急度に応じたサービス種別を選択する。そして、通知機能334は、選択機能333で選択されたサービス種別のサービス提供システム20宛に要請情報を送信する。なお、この場合、通知機能334は、先に要請情報を送信したサービス提供システム20宛に、要請情報のキャンセルを指示する旨の情報を送信することが好ましい。
【0075】
このような構成によれば、支援情報を送信した後、ユーザの容態が急変したような場合に、当該容態に適したサービスを要請することができるため、利便性の向上を図ることができる。
【0076】
(変形例5)
上述した実施形態では、入力デバイス14を介して支援要請操作が行われた場合に、ユーザ端末10から生体データが送信される例を説明したが、生体データが送信されるタイミングはこれに限らない。例えば、送信機能171は、生体データ取得回路15で取得される生体データを監視し、当該生体データの値が閾値を超える等の異常を検出したことを条件に、当該生体データを自動で支援サーバ30に送信する形態としてもよい。
【0077】
このような構成によれば、ユーザに異常が発生すると、当該ユーザの生体データを自動で支援サーバ30に送信することができる。したがって、ユーザ自身がユーザ端末10を操作できないような状況であっても、ユーザの容態に適したサービスに対応を要請することができる。
【0078】
(変形例6)
上述した実施形態では、生体データから疾病種別や猶予時間、処置内容等を判定できない場合に、遠隔診断サービスを選択する例を説明したが、この場合、遠隔診断サービスの診断結果を用いることで、疾病種別や猶予時間、処置内容等を判定する形態としてもよい。
【0079】
この場合、例えば、取得機能331は、ユーザ端末10と遠隔診断サービスとの間で行われた遠隔診断の診断結果を、ユーザ端末10又は遠隔診断サービスのサービス提供システム20から取得する。また、判定機能332は、取得機能331が取得した診断結果に基づいて、疾病種別や猶予時間、処置内容等を判定し、その判定結果に応じた緊急度を判定する。
【0080】
このような構成によれば、生体データから疾病種別や猶予時間、処置内容等を判定できない場合であっても、より遠隔診断の診断結果を用いて緊急度の判定を行うことができるため、判定精度の向上を図ることができる。なお、上述した実施形態では、遠隔診断サービスは、支援サーバ30とは別体としたが、支援サーバ30自体が、遠隔診断を行うことが可能な機能(遠隔診断機能)を具備する構成としてもよい。
【0081】
(変形例7)
また、上述した各実施形態では、本明細書における第1の取得部、第2の取得部、判定部、選択部及び通知部を、それぞれ、処理回路33の取得機能331、判定機能332、選択機能333及び通知機能334によって実現する場合の例を説明したが、実施形態はこれに限られない。例えば、本明細書における第1の取得部、第2の取得部、判定部、選択部及び通知部は、実施形態で述べた取得機能331、判定機能332、選択機能333及び通知機能334によって実現する他にも、ハードウェアのみ、又は、ハードウェアとソフトウェアとの混合によって同機能を実現するものであっても構わない。また、ユーザ端末10が有する送信機能171、受信機能172及び表示機能173についても、ハードウェアのみ、又は、ハードウェアとソフトウェアとの混合によって同機能を実現するものであってもよい。
【0082】
なお、上述した説明で用いた「プロセッサ」という文言は、例えば、CPU(Central Processing Unit)、GPU(Graphics Processing Unit)、或いは、特定用途向け集積回路(Application Specific Integrated Circuit:ASIC)、プログラマブル論理デバイス(例えば、単純プログラマブル論理デバイス(Simple Programmable Logic Device:SPLD)、複合プログラマブル論理デバイス(Complex Programmable Logic Device:CPLD)、及びフィールドプログラマブルゲートアレイ(Field Programmable Gate Array:FPGA))等の回路を意味する。プロセッサは、記憶回路に保存されたプログラムを読み出して実行することで、機能を実現する。なお、記憶回路にプログラムを保存する代わりに、プロセッサの回路内にプログラムを直接組み込むように構成しても構わない。この場合は、プロセッサは回路内に組み込まれたプログラムを読み出して実行することで機能を実現する。また、本実施形態のプロセッサは、単一の回路として構成される場合に限らず、複数の独立した回路を組み合わせて一つのプロセッサとして構成され、その機能を実現するようにしてもよい。
【0083】
ここで、プロセッサによって実行されるプログラムは、ROM(Read Only Memory)や記憶回路等に予め組み込まれて提供される。なお、このプログラムは、これらの装置にインストール可能な形式又は実行可能な形式のファイルでCD(Compact Disk)-ROM、FD(Flexible Disk)、CD-R(Recordable)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記憶媒体に記録されて提供されてもよい。また、このプログラムは、インターネット等のネットワークに接続されたコンピュータ上に保存され、ネットワーク経由でダウンロードされることにより提供又は配布されてもよい。例えば、このプログラムは、上述した各機能部を含むモジュールで構成される。実際のハードウェアとしては、CPUが、ROM等の記憶媒体からプログラムを読み出して実行することにより、各モジュールが主記憶装置上にロードされて、主記憶装置上に生成される。
【0084】
以上説明した少なくとも1つの実施形態(変形例)によれば、ユーザの容態に適したサービスをユーザ又はサービス提供者に通知できる。
【0085】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これらの実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【0086】
1 医療支援システム
10 ユーザ端末
15 生体データ取得回路
16 位置データ取得回路
20 サービス提供システム
30 支援サーバ
33 処理回路
331 取得機能
332 判定機能
333 選択機能
334 通知機能
図1
図2
図3
図4
図5
図6
図7