(57)【要約】【課題】  ユーザの状況判断および意思決定にかかる負担を軽減し、適切な情報を取得するための支援技術を提供する。【解決手段】  傷病者の状態の判定を支援するシステムである。このシステムは、収集した傷病者に関する情報を記憶する記憶部と、収集した傷病者に関する情報から、傷病者の状態の判定を行なう判定部と、収集した傷病者に関する情報から、収集すべき情報に対応する質問項目の推定を行い、推定により得られた質問項目の優先度を決定する推定部と、を有することを特徴とする。【選択図】  図１
2020013234.tif 000002
【特許請求の範囲】
【請求項１】
傷病者の状態の判定を支援するシステムであって、
収集した傷病者に関する情報を記憶する記憶部と、
前記収集した傷病者に関する情報から、傷病者の状態の判定を行なう判定部と、
前記収集した傷病者に関する情報から、収集すべき情報に対応する質問項目の推定を行い、推定により得られた質問項目の優先度を決定する推定部と、
を有することを特徴とする救急通報聴取支援システム。
【請求項２】
前記判定部と推定部は並列的に動作する、
請求項１記載の救急通報聴取支援システム。
【請求項３】
前記記憶部は、前記推定により得られた質問項目に対応する情報を記憶し、
前記判定部は、前記推定により得られた質問項目に対応する情報から、さらに傷病者の状態の判定を行なう
請求項１記載の救急通報聴取支援システム。
【請求項４】
前記推定部は、質問推定特徴量抽出部と、質問候補推定処理部と、質問項目を記憶する質問テーブルと、順序最適化部を備え、
前記質問推定特徴量抽出部は、前記記憶部に格納された情報から特徴量を抽出し、
前記質問候補推定処理部は、前記特徴量を入力とし、機械学習モデルである候補推定モデルを用いて、前記質問テーブルに記憶された質問項目にスコアを付し、
前記順序最適化部は、前記スコアに従って前記質問項目をソートする、
請求項１記載の救急通報聴取支援システム。
【請求項５】
前記順序最適化部は、一定の値を下回るスコアを除外する、
請求項４記載の救急通報聴取支援システム。
【請求項６】
前記順序最適化部は、あらかじめ決められた数の質問項目のみ、スコア上位から取得する、
請求項４記載の救急通報聴取支援システム。
【請求項７】
前記推定により得られた質問項目を表示する出力装置を備え、
前記出力装置における前記優先度の表示は、強調表示およびスコア表示の少なくとも一つである、
請求項１記載の救急通報聴取支援システム。
【請求項８】
前記推定により得られた質問項目を表示する出力装置、および、前記収集した傷病者に関する情報を入力する入力装置の少なくとも一つとネットワークを介して通信するためのインタフェースを備える、
請求項１記載の救急通報聴取支援システム。
【請求項９】
非常事態判定部をさらに備え、
前記非常事態判定部は、通話音声入力部と、通話音声特徴抽出部と、非常事態判定処理部と、非常事態判定出力部を備え、
前記通話音声入力部は、前記傷病者に関する情報を収集した際に取得された通話音声を入力し、
前記通話音声特徴抽出部は、前記通話音声から通話音声特徴量を抽出し、
前記非常事態判定処理部は、前記通話音声特徴量を入力とし、機械学習モデルである非常事態判定モデルを用いて、非常事態の有無を判定し、
前記非常事態判定出力部は、前記非常事態の有無を出力する、
請求項４記載の救急通報聴取支援システム。
【請求項１０】
前記順序最適化部は、前記非常事態判定出力部の出力に基づいて、前記質問項目の数を制限する処理を行う、
請求項９記載の救急通報聴取支援システム。
【請求項１１】
前記順序最適化部は、前記非常事態判定出力部の出力に基づいて、非常事態専用の質問項目を優先してソートする処理を行う、
請求項９記載の救急通報聴取支援システム。
【請求項１２】
前記質問候補推定処理部は、前記非常事態判定出力部の出力に基づいて、非常事態専用の候補推定モデルを用いて質問候補の推定を行う、
請求項９記載の救急通報聴取支援システム。
【請求項１３】
演算装置、記憶装置、入力装置、および出力装置を用いて、傷病者の状態の判定を支援する救急通報聴取支援方法であって、
前記入力装置から傷病者に関する情報を入力する第１のステップ、
入力した前記傷病者に関する情報を記憶装置に記憶する第２のステップ、
前記記憶した傷病者に関する情報から、傷病者の状態の判定を行なう第３のステップ、
前記記憶した傷病者に関する情報から、収集すべき情報に対応する質問項目の推定を行なう第４のステップ、
推定により得られた前記質問項目の優先度を決定する第５のステップ、
前記質問項目を前記優先度に従って表示させる第６のステップ、を実行し、
前記第６のステップにおける質問項目の表示に対応して収集した情報を、新たな傷病者に関する情報として前記第１のステップを繰り返す、
救急通報聴取支援方法。
【請求項１４】
前記入力装置から前記傷病者が存在する場所に関する情報を入力する第７のステップ、
前記傷病者が存在する場所に関する情報から、非常事態の有無を判定する第８のステップ、を実行し、
前記非常事態の有無に基づいて、前記第４のステップのアルゴリズム及び前記第５のステップのアルゴリズムの少なくとも一つを変更する、
請求項１３記載の救急通報聴取支援方法。
【請求項１５】
前記アルゴリズムの変更により、前記第６のステップにおける質問項目の表示数を減少させる、
請求項１４記載の救急通報聴取支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、救急医療における救急通報聴取業務に関し、その業務の支援を行う技術に関する。
【背景技術】
【０００２】
近年、高齢者人口の増加等の社会的背景により、一般市民の救急通報件数が増加する傾向にある。救急車、救急隊員などの救急資源には限りがあり、救急医療業務の効率化が求められている。
【０００３】
前記課題への対策の一つとして、救急通報時に聴取内容から傷病者の緊急度(時間経過が生命の危険性に影響する程度)を判定し、事案に応じた救急サービスの提供を判断する、コールトリアージが提案されている。コールトリアージの実施には、緊急度を判定する基準となるプロトコルが必要であり、消防庁やコールトリアージの推進を図るグループがプロトコルの作成と改善を実施している。通常プロトコルは聴取により得られた傷病者の１つ乃至は複数の症状から緊急度を決定するだけでなく、ある症状が得られた場合に、関連する１つ乃至は複数の関連する質問項目を列挙し、円滑な聴取業務を促すことが出来るよう作成されている。
【０００４】
そのようなプロトコルが作成されている一方で、非特許文献１では、過去の救急通報聴取の事例から緊急度判定のモデルを作成し、緊急度判定を精度良く行うアルゴリズムの提案がなされている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】OHSHIGE，Kenji，et al. Evaluation of an algorithm for estimating a patient’s life threat risk from an ambulance call. BMC emergency medicine，2009，9.1: 21.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
時間的な制約条件が存在しない状況においては、緊急度判定のプロトコルに従って傷病者の緊急度を判定することは容易に可能である。しかし、実際の救急医療現場においては、傷病者の置かれた状況により、時間的な制約の強さが異なる。特に、傷病者の置かれた状況が重篤である場合、聴取の時間は限られたものとなる。プロトコルはある症状に関連する質問項目を複数列挙することはあっても、どの項目を優先的に聴取すべきかを通常記載しない。これは状況に応じた判断が必要なためであるが、傷病者の発生局面において、最も重要な項目を判断して聴取を行うには経験を要する。
【０００７】
そこで、ユーザの状況判断および意思決定にかかる負担を軽減し、適切な情報を取得するための支援技術が望まれる。
【課題を解決するための手段】
【０００８】
本発明の好ましい一側面は、傷病者の状態の判定を支援するシステムである。このシステムは、収集した傷病者に関する情報を記憶する記憶部と、収集した傷病者に関する情報から、傷病者の状態の判定を行なう判定部と、収集した傷病者に関する情報から、収集すべき情報に対応する質問項目の推定を行い、推定により得られた質問項目の優先度を決定する推定部と、を有することを特徴とする。
【０００９】
本発明の好ましい他の側面は、演算装置、記憶装置、入力装置、および出力装置を用いて、傷病者の状態の判定を支援する救急通報聴取支援方法である。この方法は、入力装置から傷病者に関する情報を入力する第１のステップ、入力した傷病者に関する情報を記憶装置に記憶する第２のステップ、記憶した傷病者に関する情報から、傷病者の状態の判定を行なう第３のステップ、記憶した傷病者に関する情報から、収集すべき情報に対応する質問項目の推定を行なう第４のステップ、推定により得られた質問項目の優先度を決定する第５のステップ、質問項目を優先度に従って表示させる第６のステップ、を実行し、第６のステップにおける質問項目の表示に対応して収集した情報を、新たな傷病者に関する情報として前記第１のステップを繰り返す。
【発明の効果】
【００１０】
本発明によれば、ユーザの状況判断および意思決定にかかる負担を軽減し、適切な情報を取得するための支援が可能となる。
【図面の簡単な説明】
【００１１】
【図１】救急通報聴取支援システム及びプログラムの実施例１の構成例を示すブロック図。
【図２】実施例１の処理手順の一例を示すフローチャート。
【図３Ａ】実施例１の救急通報聴取画面の一例を示すイメージ図。
【図３Ｂ】実施例１の救急通報聴取画面の一例を示す部分拡大イメージ図。
【図３Ｃ】実施例１の救急通報聴取画面の一例を示す部分拡大イメージ図。
【図３Ｄ】実施例１の救急通報聴取画面の一例を示す部分拡大イメージ図。
【図３Ｅ】実施例１の救急通報聴取画面の一例を示す部分拡大イメージ図。
【図４】実施例１のデータの流れの一例を示すデータフローダイアグラム。
【図５】救急通報聴取支援システム及びプログラムの実施例２の構成例を示すブロック図。
【図６】実施例２の処理手順の一例を示すフローチャート。
【図７】実施例２の救急通報聴取画面の一例を示すイメージ図。
【図８】実施例２のデータの流れの一例を示すデータフローダイアグラム。
【発明を実施するための形態】
【００１２】
以下、図面を用いて実施例を説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
【００１３】
以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。同一あるいは同様な機能を有する要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、複数の要素を区別する必要がない場合には、添字を省略して説明する場合がある。
【００１４】
本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、もしくはその内容を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
【００１５】
図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。
【００１６】
以下で詳細に説明される実施例の概要を説明する。提案される救急通報聴取支援システム及びプログラムは、緊急度の判定を支援する支援システムであって、通報者の聴取に基づき、傷病者の情報を入力させる入力手段と、ユーザに情報を表示する出力手段とを備える。また、入力された聴取内容を記憶する聴取情報入力記憶手段と、入力された聴取の内容や日付などから、聴取すべき質問項目の推定を行うための質問推定特徴量を抽出する質問推定特徴量抽出手段とを備える。また、質問推定特徴量を入力として質問候補を推定する候補推定モデルを持つ質問候補推定処理手段と、質問候補推定処理手段から得られた複数の質問項目のうち、次に聴取すべき質問を最適化計算する順序最適化手段と、最適化された質問候補を出力手段に強調して表示する質問強調表示手段とを備える。
【００１７】
さらに、候補推定モデルを構築するために使用する、過去の聴取内容の特徴量および聴取順序の特徴量を格納した聴取順序履歴テーブルと、聴取情報入力記憶手段の内容や日付などのその他変数から、緊急度判定を行うための特徴量を抽出する緊急度判定特徴量抽出手段と、緊急度判定特徴量を入力として緊急度および疑い病名を判定する緊急度判定モデルを持つ緊急度判定処理手段とを備える。また、緊急度判定処理手段から得られた判定結果を出力手段に表示する緊急度判定出力手段と、緊急度判定モデルを構築するために使用する、過去の聴取内容の特徴量を格納した救急聴取履歴テーブルと、同じく緊急度判定モデルを構築するために使用する疑い病名テーブルと、を備える。また、質問の項目のテキストデータを格納する質問テーブルを備える。
【００１８】
さらに、好ましい形態では、通報者が非常事態にあるかを判定するために、通話音声を入力として得るための音声入力手段と、通話音声から特徴量を抽出するための通話音声特徴量抽出手段と、通話音声特徴量を入力として非常事態かを判定する非常事態判定モデルを持つ非常事態判定処理手段と、非常事態判定処理手段から得られた判定結果を前記出力手段に表示する非常事態判定出力手段と、非常事態判定モデルを構築するために使用する、過去の通話音声の特徴量を格納した通話音声履歴テーブルと、を備える。
【実施例１】
【００１９】
図１は、本実施例の救急通報聴取支援システムの一構成例を示す図である。本実施例では、ユーザに質問項目とその順序を示す方法について説明する。本実施例の救急通報聴取支援システム１００は、サーバやＰＣ（パーソナルコンピュータ）などの処理端末１０１と、マウス、キーボードなどのユーザ用の入力装置１０２と、ディスプレイなどのユーザ用の出力装置１０３と、で構成する。救急通報聴取支援システム１００は、ユーザ（オペレータ）により操作される。処理端末１０１は、演算装置１０４と記憶装置１０５を備える。記憶装置１０５は、演算装置１０４で実行されるプログラムとして、質問候補推定部１０６と緊急度判定部１１３を格納する。
【００２０】
聴取の内容によって次以降の質問項目を推測する質問候補推定部１０６は、推定処理を行う質問候補推定処理部１０７と、推定に使用する機械学習モデルである候補推定モデル１０８と、推定処理の入力となる特徴量を抽出する質問推定特徴量抽出部１０９とを備えている。さらに、推定により得られた複数の質問候補を聴取すべき順序に最適化する順序最適化部１１１と、出力装置１０３に聴取すべき質問候補を強調して表示する質問候補強調表示部１１２とを備える。また、機械学習モデルの構築に使用するため、過去の聴取情報（質問の項目とそれに対応する聴取内容）と聴取順序を格納した聴取順序履歴テーブル１１０を備える。また、質問項目ＩＤに対応して質問の項目のテキストデータを格納する質問テーブル１２１を備える。質問テーブル１２１の内容は、例えば後に図３Ａで説明する表示画面に表示されるテキストを含む。
【００２１】
また、聴取内容の入力によって傷病者の状態、例えば緊急度を判定する緊急度判定部１１３は、判定処理を行う緊急度判定処理部１１４と、判定に使用する機械学習モデルである緊急度判定モデル１１５と、判定処理の入力となる特徴量を抽出する緊急度判定特徴量抽出部１１６とを備える。また、疑い病名の一覧を格納した疑い病名テーブル１１８と、出力装置１０３に緊急度および疑い病名を表示する緊急度判定出力部１１９とを備える。また、機械学習モデルの構築に使用するため、過去の聴取情報を格納した救急聴取履歴テーブル１１７を備える。救急聴取履歴テーブル１１７は、聴取順序履歴テーブル１１０で代用しても良い。
【００２２】
本実施例では、機械学習モデルである候補推定モデル１０８と緊急度判定モデル１１５は、ニューラルネットワークで構成することにした。機械学習モデルは、上述のように、過去の聴取情報を格納した聴取順序履歴テーブル１１０と救急聴取履歴テーブル１１７のデータを用い、人間が正解を付したこれらのデータを教師データとして用い、教師有り学習によって学習することにした。ニューラルネットワークの学習方法自体は、公知技術を踏襲してよい。
【００２３】
例えば候補推定モデル１０８は、得られている症状などの情報を問題データとし、熟練した医師等が疑い病名と緊急度を特定、あるいはさらに絞り込むために、次にどのような質問を行なうかを正解データとして、モデルの学習を行なう。また、例えば緊急度判定モデル１１５は、得られている症状などの情報を問題データとし、熟練した医師等がどのような疑い病名と緊急度を判定するかを正解データとして、モデルの学習を行なう。候補推定モデル１０８では、新たに行なう質問は過去にした質問以外のものになるため、モデルの学習や訓練に用いる聴取順序履歴テーブル１１０のデータは、質問の順序の情報を含むことが好ましい。
【００２４】
記憶装置１０５は、質問候補推定部１０６と緊急度判定部１１３に入力する聴取情報を記憶するための聴取情報入力記憶部１２０を備える。本実施例では計算や制御等の機能は、ＰＣの記憶装置１０５に格納されたプログラムが演算装置１０４によって実行されることで、定められた処理を他のハードウェアと協働して実現される。ＰＣなどが実行するプログラム、その機能、あるいはその機能を実現する手段を、「機能」、「手段」、「部」等と呼ぶ場合がある。以上の構成は、単体のコンピュータで構成してもよいし、あるいは、入力装置１０２、出力装置１０３、演算装置１０４、記憶装置１０５の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。
【００２５】
なお、候補推定モデル１０８や緊急度判定モデル１１５は人工知能ではなく、条件分岐により結論を導くモデルで構成することも考えられる。たとえば、緊急度判定モデル１１５では、「胸・上腹部に痛みあり」かつ「激しい痛み」が情報として得られた場合、疑い病名として「狭心症」「心筋梗塞」を抽出する。また、候補推定モデル１０８では、上記の場合、質問候補として「痛みは持続性か？」を優先的に抽出し、「狭心症」と「心筋梗塞」を識別する。このようなモデルは、別途ユーザが作成して記憶装置１０５に格納しておくものとする。
【００２６】
図２は、救急通報を受けてから救急通報聴取を終えるまでの、本実施例の処理の手順を記述したフローチャートである。以下、フローチャートの各ステップに沿って説明する。
【００２７】
ステップＳ２０１では、救急通報聴取支援システム１００のユーザが救急通報を受ける。通報は電話回線やインターネットなどを通じたものである。通報者は、自分の電話やスマートフォン等から音声により通報を行なうことを想定する。
【００２８】
ステップＳ２０２では、ユーザは通報者から聴取を開始する。まずは例えば傷病者の氏名や年齢、性別、通報者と傷病者の関係などを聴取し、入力装置１０２を用いて救急通報聴取支援システム１００に情報を入力する。入力された情報は聴取情報入力記憶部１２０に格納される。
【００２９】
ステップＳ２０３では、ユーザはステップＳ２０２に続いて、傷病者の状態・症状について聴取を行う。通報者が自発的に説明を開始した場合、ユーザはその内容を聴き取る。そうでない場合は怪我人か病人か等、説明が開始しやすいようにユーザがコミュニケーションをとることで状態・症状の聴取を開始する。
【００３０】
ステップＳ２０４では、ユーザは通報者の回答内容を、救急通報聴取支援システム１００の入力装置１０２である画面に入力する。後に図３Ａで説明するように、入力画面は該当する項目をクリックして選択する方式であり、基本的にマウスクリックやタッチパネルのタップによる入力を想定したものである。項目が選択されると、聴取情報入力記憶部１２０に、当該の項目のＩＤおよび当該の項目が何番目に入力された項目であるかという情報と共に格納される。項目は通常質問そのもの、あるいは質問に対応した内容となっており、例えば図３Ａ等に表されるような、プルダウン式の入力が可能である。以上ステップＳ２０１〜ステップＳ２０４までは、システムのオペレータであるユーザが介在する、救急通報聴取支援システム１００への入力処理である。なお、ユーザが通報者と直接会話するのではなく、音声合成や音声認識のインタフェースを用いて入力処理を行なうことも可能である。
【００３１】
ステップＳ２０５では、緊急度判定部１１３が聴取情報入力記憶部１２０に入力された聴取情報を用いて緊急度および疑い病名の判定を行う。緊急度判定特徴量抽出部１１６は、判定を実行する緊急度判定処理部１１４の入力となる特徴量を得るための処理を行う。特徴量は、聴取情報入力記憶部１２０に記録された情報や、日時、天気、国などの情報をそのまま使用するか、それらの情報を加工することで得られる。そのように得られた特徴量を学習済みの緊急度判定モデル１１５を持つ緊急度判定処理部１１４に入力することで、結果である緊急度と疑い病名ＩＤが出力される。緊急度判定のアルゴリズムについては、非特許文献１にも報告されている。
【００３２】
ステップＳ２０６では、緊急度判定出力部１１９はステップＳ２０５の結果である緊急度と疑い病名ＩＤを取得し、出力装置１０３に表示を行う。その際、出力装置には疑い病名を表示することが好ましく、疑い病名テーブル１１８を使用して、疑い病名ＩＤを疑い病名に変換する。
【００３３】
ステップＳ２０７では、質問候補推定部１０６が聴取情報入力記憶部１２０に入力された聴取情報を用いて、次に聴取すべき質問候補の推定を行う。質問推定特徴量抽出部１０９は、推定を実行する質問候補推定処理部１０７の入力となる特徴量を得るための処理を行う。特徴量は、聴取情報入力記憶部１２０に記録された情報や、日時、天気、土地などの情報をそのまま使用するか、情報を加工することで得られる。そのように得られた特徴量を学習済みの候補推定モデル１０８を持つ質問候補推定処理部１０７に入力することで、各質問項目ＩＤが次に質問するのにどれだけ適しているかを示すスコアとして出力される。
【００３４】
ステップＳ２０８では、順序最適化部１１１が、ステップＳ２０８の結果である各質問項目ＩＤおよびそのスコアを取得し、スコアの高い順にソートを行う。そして、一定の値を下回るスコアを除外するか、あらかじめ決められた数の質問項目のみ、スコア上位から取得することで、スコアに応じた順序最適化を行い、比較的スコアの高い質問のみを抽出する。
【００３５】
ステップＳ２０９では、質問候補強調表示部１１２は順序最適化された質問項目ＩＤおよびそのスコアを取得し、出力装置１０３に表示する。その際、出力装置には質問項目を表示することが好ましく、質問テーブル１２１を使用して、質問項目ＩＤを質問項目に変換する。なお、図２に示すように、質問候補推定部１０６の処理と、緊急度判定部１１３の処理は、実質的に並行して実行される。
【００３６】
図３Ａは、質問候補強調表示部１１２が出力装置１０３に表示する画面の一例を示す図である。点線で示す範囲３００１，３００２，３００３，３００４の拡大図をそれぞれ、図３Ｂ，図３Ｃ，図３Ｄ，図３Ｅに示す。基本的にこの画面はユーザの作業中に出力装置１０３に表示されており、ユーザによる入力作業が進捗するに従い内容が変化する。本実施例では、画面中に質問に対応した項目が表示されており、入力されると入力済みが判別できるように表示が変更される。例えば、図３Ｂでは、「基本情報」「年齢」の項目で「１６歳から３９歳（青年）」が入力済みであり、表示が反転している。また、「バイタルサイン」「顔色」の項目で「蒼白」が入力済みである。本図からわかるように、質問項目は多岐に渡るため、全てを記入することは特に緊急時には現実的でない。本実施例では、質問すべき項目の重要度をシステムが判断し、聴取を行う優先度を表示することで、ユーザの支援を行なう。
【００３７】
ここで、質問候補強調表示部１１２は、図３Ｃに示すように、該当する質問項目ＩＤに対応する情報が表示されている画面エリアを強調枠線３０１で強調表示する。強調表示する質問項目が複数存在する場合、最も高いスコアの質問項目が表示されている画面エリアを、色が最も濃い強調枠線３０１で強調表示し、次に高いスコアの質問項目が表示されている画面エリアを、より色が薄いで準強調枠線３０２で強調表示することで、質問候補推定部１０６が、どの質問項目を次に最も聴取すべきかを判定したか、ユーザが知ることができる。また、前記表示方法に併せて、質問項目の内容とスコア表示した質問候補表示エリア３０３を画面エリア内に表示することでも、質問候補推定部１０６の推定結果をユーザが知る手段となる。図３Ｅでは、「しびれの有無」のスコアが０．８６、「マヒの有無」のスコアが０．６５であることが示される。なお、図３各図に示した表示方法は一例であり、強調表示の他の例としては、色を変える、大きさを変える、優先順位の低いものを非表示にする等種々の態様が考えられる。
【００３８】
ステップＳ２１０では、ユーザは図３Ｅに示すように、出力装置１０３に表示された緊急度および疑い病名の判定結果３０５、質問候補とこれまでの聴取内容や時間的制約の強さなどから、表示された緊急度を結論として聴取を終了するか、または聴取を継続するかを判断する。これまでの聴取内容によっては緊急度判定部１１３が緊急度および疑い病名が判定できず、判定結果なしとなるケースを許容する場合、緊急度判定不能となるため、聴取は継続となる。
【００３９】
ステップＳ２１１では、聴取を継続する場合、ステップＳ２１２を実施し、聴取を終了する場合、ステップＳ２１３を実施する。
【００４０】
ステップＳ２１２では、聴取を継続するため、次の質問を実施する。次の質問項目の決定はステップＳ２０９の結果、出力装置１０３に表示された候補を参考に行う。当該質問で得られた回答はステップＳ２０４で入力され、聴取情報入力記憶部１２０に記憶される。聴取を終了しない場合には、聴取情報入力記憶部１２０の内容に基づいて、さらに緊急度判定および質問候補推定が行なわれる。
【００４１】
ステップＳ２１３では、聴取を終了する。聴取を終了したユーザは救急車の出動要請等聴取後の業務を実施し、次の救急通報があれば聴取を開始する。救急車の出動要請等の際には、聴取内容や聴取の結果である緊急度および疑い病名等は、出動する救急要員に伝達される。
【００４２】
図４は、図２のフローチャートに従って処理を実施した際のデータフローダイアグラムの一例である。データフロー４０１は、ステップＳ２０２およびステップＳ２０４における、ユーザによる傷病者の聴取情報の入力を記述している。データフロー４０２は、入力された聴取情報が聴取情報入力記憶部１２０に記憶されることを記述している。
【００４３】
データフロー４０３は、ステップＳ２０５において、緊急度判定特徴量抽出部１１６が緊急度判定特徴量の算出に必要な情報を読み出す処理、およびステップＳ２０７において、質問推定特徴量抽出部１０９が質問推定特徴量の算出に必要な情報を読み出す処理のデータの流れを記述している。演算装置１０４は、データ読み出し後に緊急度判定特徴量および質問推定特徴量を算出する。
【００４４】
データフロー４０４は、ステップＳ２０５において、緊急度判定モデル１１５を読み出す処理を記述している。演算装置１０４は、緊急度判定特徴量および緊急度判定モデル１１５から緊急度および疑い病名の判定を実行する。
【００４５】
データフロー４０５は、ステップＳ２０６において、緊急度判定出力部１１９が、緊急度および疑い病名を出力装置１０３に出力することを記述している。
【００４６】
データフロー４０６は、ステップＳ２０７において、候補推定モデル１０８を読み出す処理を記述している。演算装置１０４は、質問推定特徴量および候補推定モデル１０８から質問候補の推定を実行する。
【００４７】
データフロー４０７は、ステップＳ２０９において、順序最適化部１１１によって順序最適化された質問候補を、質問候補強調表示部１１２が出力装置１０３に出力することを記述している。
【００４８】
データフロー４０８は、ステップＳ２１１で聴取継続を決定した後、再びステップＳ２０４において、傷病者の聴取情報を入力する処理を記述している。その後データフロー４０２から４０７のデータのやり取りが繰り返し実行されるが、図４への記述は省略している。
【００４９】
以上、図２のフローチャートおよび図４のデータフローダイアグラムに沿って、聴取の入力が開始された際に次の質問候補となる項目を順序最適化した上でユーザに提示する処理の流れを説明した。これらの処理により、質問候補推定処理部１０７が聴取すべき質問項目を推定し、順序最適化部１１１が次に質問すべき項目を決定することで、ユーザの状況判断および意思決定にかかる負担を軽減することができる。
【００５０】
上述の実施例では、一つの計算機上で処理を実施する例を記載したが、図４のデータフローダイアグラムが実現できる構成であれば、入力装置１０２、出力装置１０３、演算装置１０４、記憶装置１０５は同一計算機である必要はない。また、記憶装置１０５は、互いにデータの送受信が可能なものであれば、単一の装置である必要はない。
【００５１】
以上説明した実施例によれば、質問候補推定処理部１０７が聴取すべき質問項目を推定し、順序最適化部１１１が次に質問すべき項目候補を決定し、質問候補強調表示部１１２が強調表示する。これにより、ユーザの状況判断および意思決定にかかる負担を軽減し、適切な情報を迅速に取得することができる。
【実施例２】
【００５２】
次の実施例２では、通報者非常事態判定処理部が聴取の時間的制約の強さを判定した上で、質問候補推定処理部が聴取すべき質問項目を推定し、順序最適化部が次に質問すべき項目を決定する例について説明する。実施例１と同様の構成については、同一の符号を付して説明を省略する。ここで非常事態とは、通常に比べて時間的制約が強いと判定される状況をいう。そのため、ユーザに提示する質問候補の数を制限するなどの処理を行なう。
【００５３】
図５は本実施例の支援システム５００の一構成例を示す図である。処理端末５０１は図１で示した処理端末１０１に、通報者非常事態判定部５２１を追加した構成となっている。傷病者あるいは通報者の居場所の安全が確保されていない等の非常事態であるかを判定する通報者非常事態判定部５２１は、判定処理を行う非常事態判定処理部５２２と、判定に使用する機械学習モデルである非常事態判定モデル５２３と、判定に用いる通話音声を取得する通話音声入力部５２４と、判定処理の入力となる特徴量を抽出する通話音声特徴抽出部５２６と、過去の通話音声を格納した通話音声履歴テーブル５２５と、出力装置１０３に判定結果を表示する非常事態判定出力部５２７、により構成される。
【００５４】
図６は、救急通報を受けてから救急通報聴取を終えるまでの、本実施例の処理の手順を記述したフローチャートである。以下、フローチャートの各ステップに沿って説明する。
【００５５】
ステップＳ６０５では、通報者非常事態判定部５２１が判定を実施する。まず通話音声入力部５２４は入力装置１０２から入力された通話音声データを取得する。通話音声特徴抽出部５２６は、通話音声を解析し、判定を実行する非常事態判定処理部５２２の入力となる特徴量を得るための処理を行う。通話音声データには通報者の音声のほかに、通話者周辺の環境音が含まれており、そのどちらか乃至両方を対象として特徴量を抽出する。そのように得られた特徴量を学習済みの非常事態判定モデル５２３を持つ非常事態判定処理部５２２に入力することで、非常事態判定結果が出力される。
【００５６】
例えば、高速道路上の事故現場では、通報者の安全確保のため速やかに道路外へ退避することが望ましい。通話音声特徴抽出部５２６は、例えば通話音声データに含まれる高速道路上の車の走行による騒音の特徴量を検知し、高速道路上からの通報であることを判定する。あるいは、通報者の声の抑揚からストレスの状態を検知し、状況の切迫度を判定する。
【００５７】
ステップＳ６０６では、非常事態判定出力部５２７は、ステップＳ６０５で得られた非常事態判定結果の情報を質問候補推定部１０６が使用できるよう記憶装置１０５に出力する。記憶装置１０５に出力された非常事態判定結果は後述のステップＳ２０７ｂで使用する。また、非常事態判定出力部５２７は、非常事態判定結果の情報を出力装置１０３に出力しても良い。その場合、ユーザが聴取に使用する画面の一部エリアにアイコンを表示することで、ユーザは通話が非常事態の状況下で行われていると通報者非常事態判定部５２１が判断したことを知ることができる。それにより、ユーザは通報者に非常事態の回避が可能か、通報者に確認することが可能となる。
【００５８】
ステップＳ２０７ｂ〜Ｓ２０９ｂでは、実施例１と同様に、質問候補推定部１０６が、聴取情報入力記憶部１２０に入力された聴取情報を用いて質問候補の推定、順序最適化、表示を行う。ただし、実施例２では、非常事態判定出力部５２７から非常事態である旨の出力を得た場合には、例えば次の処理の少なくとも一つを行なう。
【００５９】
（１）ステップＳ２０７ｂでは、通常の質問に加え、非常事態特有の質問を追加する。例えば、「あなたのいる場所は高速道路上ですか？」等である。また、例えば前述の質問の回答が「はい」であれば、「ただちに安全な場所に退避してください。」などの非常事態特有の指示を質問に代えて選択してもよい。
【００６０】
（２）ステップＳ２０８ｂでは、非常事態特有の質問や指示を通常の質問に優先して行なうように、順序を最適化する。非常事態特有の質問や指示は、質問テーブル１２１に非常事態専用の項目として、あらかじめスコアの最大値を付して格納すればよい。ステップＳ２０９ｂでは、質問候補強調表示部１１２は順序最適化された質問項目ＩＤおよびそのスコアを取得し、出力装置１０３に表示する。
【００６１】
（３）ステップＳ２０７ｂでは、質問候補推定処理部１０７は非常事態専用の候補推定モデルを用いて質問候補の推定を行う。非常事態においては、質問と回答に時間的制約がある場合が多いので、通常よりも質問事項を重要なものに限定し、質疑応答時間を短縮する。
【００６２】
（４）ステップＳ２０８ｂでは、順序最適化部１１１で質問項目の数を制限する処理を行なう。このためには、例えば順序最適化部１１１は、質問項目を除外するためのスコアの閾値を大きくする。
【００６３】
以上のように、非常事態と判定された場合には、各ステップのアルゴリズムの変更により、ユーザに提示する質問項目の数を減少させる
図７は、質問候補強調表示部１１２が出力装置１０３に表示する画面の一例を示す図である。図３Ａと同様に次に質問すべき候補が強調表示されている。さらに、図７の画面例では、質問候補表示エリア７０１において、スコアの横に非常事態であることを示すアイコン「！」が表示されている。これにより、ユーザは通報者非常事態判定部５２１が非常事態と判定した上で質問候補を提示していることを知ることができる。
【００６４】
図８は、図６のフローチャートに従って処理を実施した際のデータフローダイアグラムの一例である。図４と同様のフローの説明は省略し、実施例２特有の部分を説明する。データフロー８０１は、ユーザによる傷病者の聴取情報の入力に加え、通報者非常事態判定Ｓ６０５で利用する、通報場所周辺の背景音、位置情報等を取得している。
【００６５】
データフロー８０２は、入力された聴取情報と背景音等が聴取情報入力記憶部１２０に記憶されることを記述している。データフロー８０３は、ステップＳ６０５において、非常事態判定モデル５２３を読み出す処理を記述している。演算装置１０４は、非常事態判定特徴量および非常事態判定モデル５２３から非常事態かの判定を実行し、結果をステップＳ２０７ｂの質問候補推定に使用する。その後のデータフロー４０３〜８０９では、非常事態特有の質問、指示、情報が優先的に追加される以外、実施例１と同様である。
【００６６】
以上、図６のフローチャートおよび図８のデータフローダイアグラムに沿って、傷病者または通報者が非常事態にあるかを判定した上で次の質問候補となる項目を順序最適化した上でユーザに提示する処理の流れを説明した。これらの処理により、質問候補推定処理部１０７が聴取すべき質問項目を推定するときに、非常事態であるかの判定を行ったうえで聴取すべき質問項目を推定し、順序最適化部１１１が次に質問すべき項目を決定することで、ユーザの状況判断及び意思決定にかかる負担をさらに軽減することができる。
【００６７】
実施例１では、一つの計算機上で処理を実施する例を記載したが、図４のデータフローダイアグラムが実現できる構成であれば、入力装置１０２、演算装置１０４、記憶装置１０５は同一計算機である必要はない。また、記憶装置は、互いにデータの送受信が可能なものであれば、単一の装置である必要はない。図５の例では、入力装置１０２と出力装置１０３は、ネットワークＮＷを介して処理端末５０１を接続される例を示している。例えば、入力装置１０２と出力装置１０３は、例えば携帯用情報処理端末やパーソナルコンピュータであり、処理端末５０１はより複雑な処理が可能なサーバである。このサーバは、記推定により得られた質問項目を表示する出力装置１０３、および、収集した傷病者に関する情報を入力する入力装置１０２の少なくとも一つとネットワークＮＷを介して通信するためのインタフェースＩＦを備えている。
【００６８】
以上説明したように、実際の救急医療現場においては、傷病者あるいは通報者の置かれた状況により、時間的な制約の強さが異なる。特に、傷病者あるいは通報者の居場所の安全が確保されていない状態のような、非常事態である場合、聴取の時間は非常に限られたものとなる。プロトコルはある症状に関連する質問項目を複数列挙することはあっても、どの項目を優先的に聴取すべきかを通常記載しない。これは状況に応じた判断が必要なためであるが、非常事態において、最も重要な項目を判断して聴取を行うには経験を要する。また、そもそも非常事態であるかを判断すること自体にも経験を要する。上記実施例では、非常事態判定処理部が聴取の時間的制約の強さを判定した上で、質問候補推定処理部が聴取すべき質問項目を推定し、順序最適化部が次に質問すべき項目を決定することで、ユーザの状況判断および意思決定にかかる負担をさらに軽減することができる。
【符号の説明】
【００６９】
１０１：処理端末、１０２：入力装置、１０３：出力装置、１０４：演算装置、１０５：記憶装置、１０６：質問候補推定部、１０７：質問候補推定処理部、１０８：候補推定モデル、１０９：質問推定特徴量抽出部、１１０：聴取順序履歴テーブル、１１１：順序最適化部、１１２：質問候補強調表示部、１１３：緊急度判定部、１１４：緊急度判定処理部、１１５：緊急度判定モデル、１１６：緊急度判定特徴量抽出部、１１７：救急聴取履歴テーブル、１１８：疑い病名テーブル、１１９：緊急度判定出力部、１２０：聴取情報入力記憶部
【図１】
2020013234.tif 000003
【図２】
2020013234.tif 000004
【図３Ａ】
2020013234.tif 000005
【図３Ｂ】
2020013234.tif 000006
【図３Ｃ】
2020013234.tif 000007
【図３Ｄ】
2020013234.tif 000008
【図３Ｅ】
2020013234.tif 000009
【図４】
2020013234.tif 000010
【図５】
2020013234.tif 000011
【図６】
2020013234.tif 000012
【図７】
2020013234.tif 000013
【図８】
2020013234.tif 000014