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

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

▶ オンタクト ヘルス カンパニー リミテッドの特許一覧

<>
  • 特許-最適な移送病院決定方法及びサーバ 図1
  • 特許-最適な移送病院決定方法及びサーバ 図2
  • 特許-最適な移送病院決定方法及びサーバ 図3
  • 特許-最適な移送病院決定方法及びサーバ 図4
  • 特許-最適な移送病院決定方法及びサーバ 図5
  • 特許-最適な移送病院決定方法及びサーバ 図6
  • 特許-最適な移送病院決定方法及びサーバ 図7
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-05-27
(45)【発行日】2024-06-04
(54)【発明の名称】最適な移送病院決定方法及びサーバ
(51)【国際特許分類】
   G16H 40/20 20180101AFI20240528BHJP
【FI】
G16H40/20
【請求項の数】 18
(21)【出願番号】P 2022514162
(86)(22)【出願日】2020-09-03
(65)【公表番号】
(43)【公表日】2022-11-10
(86)【国際出願番号】 KR2020011872
(87)【国際公開番号】W WO2021045535
(87)【国際公開日】2021-03-11
【審査請求日】2022-03-03
(31)【優先権主張番号】10-2019-0109299
(32)【優先日】2019-09-04
(33)【優先権主張国・地域又は機関】KR
(31)【優先権主張番号】10-2019-0109300
(32)【優先日】2019-09-04
(33)【優先権主張国・地域又は機関】KR
(73)【特許権者】
【識別番号】522080797
【氏名又は名称】オンタクト ヘルス カンパニー リミテッド
(74)【代理人】
【識別番号】110000877
【氏名又は名称】弁理士法人RYUKA国際特許事務所
(72)【発明者】
【氏名】チャン、ヒョク ジェ
(72)【発明者】
【氏名】パク、ウン ジェオン
(72)【発明者】
【氏名】スン、ジ ミン
(72)【発明者】
【氏名】キム、ジ フーン
(72)【発明者】
【氏名】キム、ミン ジョウン
(72)【発明者】
【氏名】キム、スン ウ
(72)【発明者】
【氏名】ジョン、ビョン ファン
(72)【発明者】
【氏名】ハ、セオン ミン
(72)【発明者】
【氏名】アン、キョン ジン
【審査官】梅岡 信幸
(56)【参考文献】
【文献】国際公開第2013/065113(WO,A1)
【文献】特開2013-148996(JP,A)
【文献】特開2003-150707(JP,A)
【文献】特開2011-048775(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G16H 10/00-80/00
(57)【特許請求の範囲】
【請求項1】
最適な移送病院を決定する方法において、
救急AIサーバが、病院の位置および救急車の位置に基づいて、または、病院の位置および救急患者の位置に基づいて、候補病院を決定するステップと、
前記救急AIサーバが、前記救急患者の状態情報を獲得するステップと、
前記救急AIサーバが、前記獲得した状態情報を予め生成されて前記救急AIサーバに保有されている重症度判断モデルに入力することで、患者の重症度を決定するステップと、
前記救急AIサーバが、前記獲得した状態情報を予め生成されて前記救急AIサーバに事前に保有されている機械学習モデルに入力することで、救急イベント発生可能性情報を算出するステップと、
前記救急AIサーバが、輸送資源可用情報を保有する前記救急AIサーバの格納部または前記輸送資源可用情報を保有する外部デバイスから前記決定された候補病院に対する前記輸送資源可用情報を獲得するステップと、
前記救急AIサーバが、前記決定された患者の重症度、前記獲得した救急イベント発生可能性情報、及び前記輸送資源可用情報を、予め生成されて前記救急AIサーバに事前に保有されている病院選定モデルに入力することで、候補病院それぞれの適合度を算出するステップと、
前記救急AIサーバが、前記算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定するステップと
を含み、
前記輸送資源可用情報は、リアルタイム交通情報、前記候補病院それぞれの位置情報、現在位置情報、前記候補病院それぞれの可用病床情報、前記候補病院それぞれの当直医情報、前記候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報を含む、
最適な移送病院を決定する方法。
【請求項2】
前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、
前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含む、
請求項1に記載の最適な移送病院を決定する方法。
【請求項3】
前記決定された最適な移送病院の適合度が事前決定された値未満である場合、
前記救急AIサーバが、探索半径を拡大して前記候補病院を再決定するステップと、
前記救急AIサーバが、前記再決定された候補病院の適合度を算出するステップと、
前記救急AIサーバが、前記算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップと、
をさらに含む、
請求項1に記載の最適な移送病院を決定する方法。
【請求項4】
前記再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまで、
(1)前記救急AIサーバが、探索半径を拡大して前記候補病院を再決定するステップと、
(2)前記救急AIサーバが、前記再決定された候補病院の適合度を算出するステップと、
(3)前記救急AIサーバが、前記算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップと、
を引き継ぎ繰り返す、
請求項3に記載の最適な移送病院を決定する方法。
【請求項5】
前記救急AIサーバが、前記決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて、救急患者移送にドクターヘリを活用するか否かを決定するステップと、
救急患者移送にドクターヘリを活用する場合、前記救急AIサーバが、前記決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて最適な引き継ぎ点を決定するステップと、
をさらに含む、
請求項1に記載の最適な移送病院を決定する方法。
【請求項6】
最適な移送病院を決定する救急AIサーバにおいて、
獲得した救急患者の状態情報に基づいて、患者の重症度を決定し、そして救急イベント発生可能性情報を算出し、
前記決定された患者の重症度、救急イベント発生可能性情報及び輸送資源可用情報に基づいて、候補病院それぞれの適合度を算出し、
前記算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定する制御部と、
救急患者の状態情報、救急イベント発生可能性情報及び輸送資源可用情報を格納する格納部と
を含み、
前記制御部は、
病院の位置および救急車の位置に基づいて、または、病院の位置および前記救急患者の位置に基づいて、前記候補病院を決定し、
前記獲得した状態情報を、予め生成されて前記格納部に保有されている重症度判断モデルに入力することで、前記患者の重症度を決定し、前記獲得した状態情報を、予め生成されて前記格納部に保有されている機械学習モデルに入力することで、救急イベント発生可能性情報を算出し、
前記決定された候補病院に対する前記輸送資源可用情報を前記格納部から獲得し、
前記決定された患者の重症度、前記獲得した救急イベント発生可能性情報、及び前記輸送資源可用情報を、予め生成されて前記格納部に保有されている病院選定モデルに入力することで、候補病院それぞれの前記適合度を算出する、
前記輸送資源可用情報は、リアルタイム交通情報、前記候補病院それぞれの位置情報、現在位置情報、前記候補病院それぞれの可用病床情報、前記候補病院それぞれの当直医情報、前記候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報を含む、
最適な移送病院を決定する救急AIサーバ。
【請求項7】
前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、
前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含む、
請求項6に記載の最適な移送病院を決定する救急AIサーバ。
【請求項8】
前記制御部は、
前記決定された最適な移送病院の適合度が事前決定された値未満である場合、探索半径を拡大して前記候補病院を再決定し、再決定された候補病院の適合度を算出し、算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定する、
請求項6に記載の最適な移送病院を決定する救急AIサーバ。
【請求項9】
前記再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまで、
(1)探索半径を拡大して前記候補病院を再決定するステップと、
(2)前記再決定された候補病院の適合度を算出するステップと、
(3)前記算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップと、
を引き続き繰り返す、
請求項8に記載の最適な移送病院を決定する救急AIサーバ。
【請求項10】
複数の救急患者それぞれが移送される病院を決定する方法において、
救急AIサーバが、前記病院の位置および救急車の位置に基づいて、または、病院の位置および救急患者の位置に基づいて、候補病院を決定するステップと、
前記救急AIサーバが、移送距離を用いたモデリングと患者情報を用いたモデリングから、それぞれの救急患者の候補病院に対する移送可能性に対応する重み付け情報を生成するステップと、
前記救急AIサーバが、前記救急患者それぞれの最適な移送病院を決定するステップと、
前記救急AIサーバが、前記重み付け情報と共に救急患者を収容するか否かを決定された最適な移送病院に問い合わせるステップと
を含む、前記複数の救急患者それぞれが移送される病院を決定する方法であって、
それぞれの救急患者に対する最適な移送病院を決定するステップは、
前記救急AIサーバが、救急患者の状態情報を獲得するステップと、
前記救急AIサーバが、前記獲得した状態情報を、予め生成され前記救急AIサーバに保有されている重症度判断モデルに入力することで、患者の重症度を決定するステップと、
前記獲得した状態情報を予め生成され前記救急AIサーバに事前に保有されている機械学習モデルに入力することで、救急イベント発生可能性情報を算出するステップと、
前記救急AIサーバが、輸送資源可用情報を保有する前記救急AIサーバの格納部もしくは前記輸送資源可用情報を保有する外部デバイスから前記決定された候補病院に対する前記輸送資源可用情報を獲得するステップと、
前記救急AIサーバが、前記決定された患者の重症度、前記獲得した救急イベント発生可能性情報、及び前記輸送資源可用情報を、予め生成され前記救急AIサーバに事前に保有されている病院選定モデルに入力することで、候補病院それぞれの適合度を算出するステップと、
前記救急AIサーバが、前記算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定するステップと、
をさらに含み、
前記輸送資源可用情報は、リアルタイム交通情報、前記候補病院それぞれの位置情報、現在位置情報、前記候補病院それぞれの可用病床情報、前記候補病院それぞれの当直医情報、前記候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報を含む、
複数の救急患者それぞれが移送される病院を決定する方法。
【請求項11】
救急患者を収容するか否かを決定された最適な移送病院に問い合わせた結果、収容されない場合、
前記救急AIサーバが、救急患者及び候補病院に対する情報をリアルタイムでアップデートした以後に重み付け情報を再生成する、
請求項10に記載の複数の救急患者それぞれが移送される病院を決定する方法。
【請求項12】
前記複数の救急患者それぞれが移送される病院を決定する方法は、
前記救急AIサーバが、救急患者それぞれに対する最終移送病院を決定した以後、決定された最終移送病院に対する重み付け情報を生成する、
請求項10に記載の複数の救急患者それぞれが移送される病院を決定する方法。
【請求項13】
前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、
前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含む、
請求項10に記載の複数の救急患者それぞれが移送される病院を決定する方法。
【請求項14】
前記決定された最適な移送病院の適合度が事前決定された値未満である場合、
前記救急AIサーバが、探索半径を拡大して前記候補病院を再決定するステップと、
前記救急AIサーバが、前記再決定された候補病院の適合度を算出するステップと、
前記救急AIサーバが、前記算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップと
をさらに含む、
請求項13に記載の複数の救急患者それぞれが移送される病院を決定する方法。
【請求項15】
前記再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまで、
(1)前記救急AIサーバが、探索半径を拡大して前記候補病院を再決定するステップと、
(2)前記救急AIサーバが、前記再決定された候補病院の適合度を算出するステップと、
(3)前記救急AIサーバが、前記算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップと
を引き続き繰り返す、
請求項14に記載の複数の救急患者それぞれが移送される病院を決定する方法。
【請求項16】
前記救急AIサーバが、前記決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて、救急患者移送にドクターヘリを活用するか否かを決定するステップと、
救急患者移送にドクターヘリを活用する場合、前記救急AIサーバが、決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて最適な引き継ぎ点を決定するステップと
をさらに含む、
請求項10に記載の複数の救急患者それぞれが移送される病院を決定する方法。
【請求項17】
複数の救急患者それぞれが移送される病院を決定する救急AIサーバにおいて、
前記病院の位置および救急車の位置に基づいて、または、病院の位置および救急患者の位置に基づいて、候補病院を決定し、移送距離を用いたモデリングと患者情報を用いたモデリングから、それぞれの救急患者の候補病院に対する移送可能性に対応する重み付け情報を生成し、それぞれの救急患者に対する最適な移送病院を決定し、前記重み付け情報と共に救急患者を収容するか否かを決定された最適な移送病院に問い合わせる制御部、および輸送資源可用情報を保有する格納部を含み、
前記制御部はさらに:
救急患者の状態情報を獲得し、
前記獲得した状態情報を、予め生成され前記格納部に保有されている重症度判断モデルに入力することで、患者の重症度を決定し、
前記獲得した状態情報を、予め生成され前記格納部に保有されている機械学習モデルに入力することで、救急イベント発生可能性情報を算出し、
前記決定された候補病院に対する前記輸送資源可用情報を前記格納部から獲得し、
前記決定された患者の重症度、前記獲得した救急イベント発生可能性情報、及び前記輸送資源可用情報を、予め生成され前記格納部に保有されている病院選定モデルに入力することで、候補病院それぞれの適合度を算出し、
前記算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定し、
前記輸送資源可用情報は、リアルタイム交通情報、前記候補病院それぞれの位置情報、現在位置情報、前記候補病院それぞれの可用病床情報、前記候補病院それぞれの当直医情報、前記候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報を含む、
複数の救急患者それぞれが移送される病院を決定する救急AIサーバ。
【請求項18】
前記格納部は、救急患者の状態情報、救急イベント発生可能性情報をさらに格納し、
前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、
前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含む、
請求項17に記載の複数の救急患者それぞれが移送される病院を決定する救急AIサーバ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、救急患者の発生時、救急患者の最適な移送病院を決定する方法及びそれを提供するサーバを提供しようとする。
【背景技術】
【0002】
現在、韓国内の救急医療システムは、救急医療体系の参与主体である病院、救急現場、管制機関間の情報の流れが断絶されており、救急現場で統合的データを収集して活用するのに限界が存在するため、良質の救急医療サービスの提供が難しい。これによって、適切な現場の判断が必要な重症患者の応急処置、移送及び転院に非効率性を引き起こし、結果的に国民の健康と安全を担保すべき救急医療サービスに深刻な問題を招いている。
【0003】
特に、患者移送病院の選定時、119総合状況室と救急現場間(音声通話を通した情報交流によって)のリアルタイムで変更される状況情報の伝達が円滑でなく、時間遅延が発生する。また、移送病院を選定する過程で個別救急医療センターに数回の電話が必要であり、音声通話を通した情報伝達によって患者の状態に対する正確な情報伝達が難しい。
【0004】
これによって、重症患者に対する応急処置の時間遅延が発生し、重症救急疾患移送後、1次転院率が11.2%、2次転院率が8.6%発生している。
【0005】
また、病院前のステップで重症度分類の困難により心血管系重症疾患30.7%、脳神経系重症疾患31.9%、重症外傷44.6%が不適切な医療機関へ移送されて適切な治療を受けることができていない。
【0006】
また、非専門家が移送病院決定に介入して適切な処置を提供できる病院へ移送され得ない状況が頻繁に発生する。
【0007】
韓国内の医療状況は、救急室過密化、重症度分類エラー、道路状況に対する問題等により最適な移送病院選定に困難があり、これを解決するための技術開発が必要な実情である。
【0008】
韓国登録特許KR10-0800026は、救急患者を最適な医療機関へ移送させる方法及びシステムについて開示する。
【発明の概要】
【発明が解決しようとする課題】
【0009】
本発明は、前述した背景技術に対応して案出されたものであり、救急患者の発生時、救急患者に対する最適な移送病院を効率的に正確に決定しようとする。
【課題を解決するための手段】
【0010】
前述した課題を解決するための本発明の実施例のうち第1側面は、最適な移送病院を決定する方法において、候補病院を決定するステップ;救急患者の状態情報を獲得するステップ;前記獲得した状態情報に基づいて、患者の重症度を決定するステップ;前記獲得した状態情報に基づいて、救急イベント発生可能性情報を算出するステップ;前記決定された候補病院に対する輸送資源可用情報を獲得するステップ;前記決定された患者の重症度、前記獲得した救急イベント発生可能性情報、及び前記輸送資源可用情報に基づいて、候補病院それぞれの適合度を算出するステップ;及び、算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定するステップ;を含む、最適な移送病院を決定する方法を提供することができる。
【0011】
また、前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含み、前記輸送資源可用情報は、リアルタイム交通情報、候補病院それぞれの位置情報、現在位置情報、候補病院それぞれの可用病床情報、候補病院それぞれの当直医情報、候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報のうち少なくとも一つを含むことができる。
【0012】
また、前記決定された最適な移送病院の適合度が事前決定された値未満である場合:探索半径を拡大して候補病院を再決定するステップ;再決定された候補病院の適合度を算出するステップ;算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップ;をさらに含むことができる。
【0013】
また、前記再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまで下記の(1)、(2)及び(3)ステップ:(1)探索半径を拡大して候補病院を再決定するステップ;(2)再決定された候補病院の適合度を算出するステップ;(3)算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップ;を引き続き繰り返すことができる。
【0014】
また、決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて、救急患者移送にドクターヘリを活用するか否かを決定するステップ;救急患者移送にドクターヘリを活用する場合、決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて最適な引き継ぎ点を決定するステップ;をさらに含むことができる。
【0015】
前述した課題を解決するための本発明の実施例のうち第1側面は、最適な移送病院を決定するサーバにおいて、獲得した救急患者の状態情報に基づいて、患者の重症度を決定し、そして救急イベント発生可能性情報を算出し、決定された患者の重症度、救急イベント発生可能性情報及び輸送資源可用情報に基づいて、候補病院それぞれの適合度を算出し、算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定する制御部;及び、救急患者の状態情報、救急イベント発生可能性情報及び輸送資源可用情報を格納する格納部;を含む最適な移送病院を決定するサーバを提供することができる。
【0016】
また、前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含み、前記輸送資源可用情報は、リアルタイム交通情報、候補病院それぞれの位置情報、現在位置情報、候補病院それぞれの可用病床情報、候補病院それぞれの当直医情報、候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報のうち少なくとも一つを含むことができる。
【0017】
また、前記制御部は:前記決定された最適な移送病院の適合度が事前決定された値未満である場合、探索半径を拡大して候補病院を再決定し、再決定された候補病院の適合度を算出し、算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定できる。
【0018】
また、前記再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまで下記の(1)、(2)及び(3)ステップ:(1)探索半径を拡大して候補病院を再決定するステップ;(2)再決定された候補病院の適合度を算出するステップ;(3)算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップ;を引き続き繰り返すことができる。
【0019】
前述した課題を解決するための本発明の実施例のうち第2側面は、複数の救急患者それぞれが移送される病院を決定する方法において、候補病院を決定するステップ;救急患者それぞれの候補病院に対する重み付け情報を生成するステップ;救急患者それぞれの最適な移送病院を決定するステップ;及び、重み付け情報と共に救急患者を収容するか否かを決定された最適な移送病院に問い合わせるステップ;を含む、複数の救急患者それぞれが移送される病院を決定する方法が提供され得る。
【0020】
また、前記重み付け情報を生成するステップは、移送距離基盤病院モデリング及び患者情報基盤モデリングを通して救急患者それぞれの候補病院に対する重み付けを算出することができる。
【0021】
また、救急患者を収容するか否かを決定された最適な移送病院に問い合わせた結果、収容されない場合、救急患者及び候補病院に対する情報をリアルタイムでアップデートした以後に重み付け情報を再生成できる。
【0022】
また、救急患者それぞれの最終移送病院を決定するステップは:救急患者の状態情報を獲得するステップ;前記獲得した状態情報に基づいて、患者の重症度を決定するステップ;前記獲得した状態情報に基づいて、救急イベント発生可能性情報を算出するステップ;前記決定された候補病院に対する輸送資源可用情報を獲得するステップ;前記決定された患者の重症度、前記獲得した救急イベント発生可能性情報、及び前記輸送資源可用情報に基づいて、候補病院それぞれの適合度を算出するステップ;及び、算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定できる。
【0023】
また、前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含み、前記輸送資源可用情報は、リアルタイム交通情報、候補病院それぞれの位置情報、現在位置情報、候補病院それぞれの可用病床情報、候補病院それぞれの当直医情報、候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報のうち少なくとも一つを含むことができる。
【0024】
また、前記決定された最適な移送病院の適合度が事前決定された値未満である場合:探索半径を拡大して候補病院を再決定するステップ;再決定された候補病院の適合度を算出するステップ;算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップ;をさらに含むことができる。
【0025】
また、前記再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまで下記の(1)、(2)及び(3)ステップ:(1)探索半径を拡大して候補病院を再決定するステップ;(2)再決定された候補病院の適合度を算出するステップ;(3)算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップ;を引き続き繰り返すことができる。
【0026】
また、決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて、救急患者移送にドクターヘリを活用するか否かを決定するステップ;救急患者移送にドクターヘリを活用する場合、決定された最適な移送病院の位置情報、リアルタイム交通情報及びドクターヘリ運行情報のうち少なくとも一つに基づいて最適な引き継ぎ点を決定するステップ;をさらに含むことができる。
【0027】
前述した課題を解決するための本発明の実施例のうち第2側面は、複数の救急患者それぞれが移送される病院を決定するサーバにおいて、候補病院を決定し、救急患者それぞれの候補病院に対する重み付け情報を生成し、救急患者それぞれの最適な移送病院を決定し、重み付け情報と共に救急患者を収容するか否かを決定された最適な移送病院に問い合わせる制御部;を含む、複数の救急患者それぞれが移送される病院を決定するサーバを提供することができる。
【0028】
また、前記制御部は:獲得した救急患者の状態情報に基づいて、患者の重症度を決定し、そして救急イベント発生可能性情報を算出し、決定された患者の重症度、救急イベント発生可能性情報及び輸送資源可用情報に基づいて、候補病院それぞれの適合度を算出し、算出された候補病院それぞれの適合度に基づいて、最適な移送病院を決定し、前記サーバは:救急患者の状態情報、救急イベント発生可能性情報及び輸送資源可用情報を格納する格納部;をさらに含み、前記救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、前記救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI発生可能性情報、UA+NSTEM発生可能性情報、LVO発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含み、前記輸送資源可用情報は、リアルタイム交通情報、候補病院それぞれの位置情報、現在位置情報、候補病院それぞれの可用病床情報、候補病院それぞれの当直医情報、候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報のうち少なくとも一つを含む、複数の救急患者それぞれが移送される病院を決定するサーバを提供することができる。
【発明の効果】
【0029】
本発明は、前述した背景技術に対応して案出されたものであり、救急患者に対する最適な移送病院を決定する方法を提供することができる。
【図面の簡単な説明】
【0030】
多様な様相がこれから図面を参照して記載され、ここで類似した参照番号は、総括的に類似した構成要素を指すのに利用される。以下の実施例において、説明目的のために、多数の特定細部事項が一つ以上の様相の総体的理解を提供するために提示される。しかし、そのような様相がこのような具体的な細部事項なしに実施され得ることは明らかであるだろう。他の例示において、公知の構造及び装置が一つ以上の様相の記載を容易にするためにブロック図形態に示される。
図1】本開示の一実施例と関連した最適な移送病院決定システムを例示的に示す。
図2】本開示の一実施例と関連した最適な移送病院を決定する方法を例示的に示す。
図3】本開示の一実施例によって最適な移送病院を再決定する方法を説明するための図である。
図4】本開示の一実施例によって複数名の救急患者が発生した場合の最適な移送病院を決定する方法を説明するための図である。
図5】本開示の一実施例によって最適な引き継ぎ点を推薦する方法を説明するための図である。
図6】本開示の一実施例によって最適な移送病院を決定するアルゴリズムを詳細に説明するための図である。
図7】本開示の一実施例に係る救急AIサーバの構成要素を説明するための図である。
【発明を実施するための形態】
【0031】
多様な実施例がこれから図面を参照して説明され、全図面にわたって類似した図面番号は、類似した構成要素を示すために使用される。本明細書において、多様な説明が本発明の理解を提供するために提示される。しかし、このような実施例は、このような具体的な説明がなくても実行され得ることが明らかである。他の例において、公知になった構造及び装置は、実施例の説明を容易にするためにブロックダイアグラム形態に提供される。
【0032】
本明細書において使用される用語「コンポーネント」、「モジュール」、「システム」等は、コンピュータ-関連エンティティ、ハードウェア、ファームウェア、ソフトウェア、ソフトウェア及びハードウェアの組み合わせ、またはソフトウェアの実行を指す。例えば、コンポーネントは、プロセッサ上で実行される処理過程、プロセッサ、客体、実行スレッド、プログラム、および/またはコンピュータであってよいが、これらに制限されるものではない。例えば、コンピューティング装置で実行されるアプリケーション及びコンピューティング装置はいずれもコンポーネントであってよい。一つ以上のコンポーネントは、プロセッサおよび/または実行スレッド内に常駐でき、一コンポーネントは、一つのコンピュータ内にローカル化され得、または2個以上のコンピュータの間に分配され得る。また、このようなコンポーネントは、その内部に格納された多様なデータ構造を有する多様なコンピュータ読み取り可能な媒体から実行できる。コンポーネントは、例えば、一つ以上のデータパケットを有する信号(例えば、ローカルシステム、分散システムで他のコンポーネントと相互作用する一つのコンポーネントからデータおよび/または信号を通して他のシステムとインターネットのようなネットワークを通したデータ)によってローカルおよび/または遠隔処理を通して通信できる。
【0033】
本明細書において、救急車デバイス1000は、救急車で使用されるマイクロプロセッサ、メインフレームコンピュータ、デジタルシングルプロセッサ、携帯用デバイス及びデバイス制御器等のような任意のタイプのコンピュータシステムまたはコンピュータデバイスを含むことができる。
【0034】
本明細書において、救急AIサーバ3000は、単一のサーバを指し得る。また、救急AIサーバ3000は、複数個のサーバで構成されたグループを指し得る。また、救急AIサーバ3000は、クラウドサーバを指し得、これに限定されない。
【0035】
本明細書において、救急医療サーバ2000は、単一のサーバを指し得る。また、救急医療サーバ2000は、複数個のサーバで構成されたグループを指し得る。また、救急医療サーバ2000は、クラウドサーバを指し得、これに限定されない。
【0036】
提示された実施例についての説明は、本発明の技術の分野において通常の知識を有する者が本発明を利用または実施できるように提供される。このような実施例に対する多様な変形は、本発明の技術の分野において通常の知識を有する者に明らかであり、ここに定義された一般的な原理は、本発明の範囲を外れることなく他の実施例に適用され得る。それゆえ、本発明は、ここに提示された実施例に限定されるものではなく、ここに提示された原理及び新規な特徴と一貫する最広義の範囲で解釈されるべきである。
【0037】
以下においては、添付の図面を参照して、本発明に係る実施例を詳細に説明する。
【0038】
図1は、本開示の一実施例と関連した最適な移送病院決定システムを例示的に示す。
【0039】
本開示の一実施例によれば、救急患者が発生した場合、救急隊員(例えば、119救急隊等)は、該当地域に配置され得る。救急患者が救急車に搭乗した場合、救急隊員は、応急処置を遂行することができ、救急患者に対する情報を習得できる。
【0040】
例えば、救急隊員は、救急活動日誌を作成でき、救急患者の音声を録音でき、カメラを活用して救急患者の状態を撮影できる。また、救急車に備えられた多様な装置を活用して、救急患者の生体信号を測定できる。
【0041】
救急隊員により獲得された救急患者に対する多様な状態情報は、救急車デバイス1000に格納され得る。この場合、救急車デバイス1000は、救急隊員が使用する端末機、救急車に備えられたコンピュータ等、救急患者の情報を格納し、外部のデバイスと通信できる多様な装置を含むことができる。
【0042】
本開示の一実施例によれば、救急車デバイス1000は、救急患者の状態情報を自動で獲得できる。例えば、救急車デバイス1000は、救急隊員の話の音節を認識して、救急活動日誌を自動で作成できる。また、救急車デバイス1000は、撮影される映像を分析して、救急患者の状態情報を自動で獲得できる。
【0043】
救急車デバイス1000は、救急AI(Artificial Intelligence)サーバ3000に患者の状態情報を送付し、救急患者の重症度および/または救急イベント発生可能性情報を要請できる。また、救急車デバイス1000は、患者の状態情報を送付し、最適な移送病院の決定を救急AIサーバ3000に要請できる。
【0044】
救急AIサーバ3000は、救急車デバイス1000の要請に応答して、患者の状態情報を事前生成された重症度判断モデルに入力することで、患者の重症度を決定し、決定された重症度を救急車デバイス1000に提供できる。また、救急AIサーバ3000は、救急車デバイス1000の要請に応答して、患者の状態情報を事前生成された機械学習モデルに入力することで、重症疾患イベント発生可能性情報を生成し、生成された情報を救急車デバイス1000に提供できる。
【0045】
また、救急AIサーバ3000は、救急車デバイス1000の要請に応答して、救急患者に対する最適な移送病院を決定し、決定された最適な移送病院に対する情報を救急車デバイス1000に提供できる。
【0046】
救急医療サーバ2000は、救急患者と関連した情報を提供する多様なサーバを含むことができる。例えば、救急医療サーバ2000は、国家救急診療情報網(NEDIS)サーバを含むことができる。救急医療サーバ2000は、救急医療と関連した多様な情報を獲得して保有でき、必要な場合、情報を救急車デバイス1000および/または救急AIサーバ3000に提供できる。
【0047】
例えば、救急医療サーバ2000は、リアルタイム交通情報、病院それぞれの位置情報、現在位置情報、病院それぞれの可用病床情報、病院それぞれの当直医情報、候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報のうち少なくとも一つを獲得して保有でき、これに限定されず、多様な情報を獲得して保有できる。また、獲得した情報を救急車デバイス1000および/または救急AIサーバ3000に提供できる。
【0048】
図2は、本開示の一実施例と関連した最適な移送病院を決定する方法を例示的に示す。
【0049】
ステップS210で、救急AIサーバ3000は、最適な移送病院の候補病院を決定できる。例えば、救急AIサーバ3000は、救急車が位置する地点(または、救急患者が発生した地点)から事前決定された距離(例えば、3km、5km等)以内に位置した病院を候補病院に決定できる。また、救急AIサーバ3000は、救急車が位置した地点が含まれる都市(例えば、ソウル市、仁川市、水原市等)内に位置した病院を候補病院に決定できる。また、救急AIサーバ3000は、救急車が位置した区(例えば、江南区、瑞草区、江東区等)内に位置した病院を候補病院に決定でき、これに限定されず、多様な方法で候補病院を決定できる。
【0050】
ステップS220で、救急AIサーバ3000は、救急患者の状態情報を獲得できる。例えば、救急AIサーバ3000は、救急患者の状態情報を救急車デバイス1000から獲得できる。
【0051】
救急患者の状態情報は、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報及び心電図情報のうち少なくとも一つを含み、これに限定されない。
【0052】
本開示の一実施例によれば、ステップS230で、救急AIサーバ3000は、救急患者の重症度を決定できる。例えば、救急AIサーバ3000は、救急患者の状態情報を利用して患者の重症度を決定できる。
【0053】
この場合、救急AIサーバ3000は、機械学習を通して重症度判断モデルを予め生成でき(または、予め保有でき)、重症度判断モデルに救急患者の状態情報を入力することで、救急患者の重症度を決定できる。
【0054】
この場合、救急AIサーバ3000は、病院前韓国型救急患者分類道具(Prehospital KTAS)を基盤に救急患者の救急度を決定できる。例えば、救急AIサーバ3000は、救急患者の年齢を活用して1次的にコードを付与し、症状に対する大分類(例えば、消化器、皮膚、神経科等)を遂行して2次的にコードを付与し、大分類に対する中分類(例えば、腹痛、嘔吐/吐き気等)を遂行して3次的にコードを付与し、中分類に対する細部症状(例えば、呼吸困難、ショック等)を判別して4次的にコードを付与できる。そして、救急AIサーバ3000は、最終的に付与されたコードにマッチングされる重症度(例えば、1、2、3、4、5ステップ、1ステップが最も危険であり得る)を救急患者の重症度に決定できる。
【0055】
この場合、重症度判断モデルを生成するために活用されるアルゴリズムは、指導学習(Supervised learning)、サポートベクターマシン(Support Vector Machines、SVM)、ランダムフォレスト(Random Forest、RF)、ナイーブベイズ(Naive、NB)、人工神経網(Artificial Neural Network、ANN)、判断ツリー(Decision Tree)及びベイジアン(Bayesian)のうち少なくとも一つを含むことができ、これに限定されない。
【0056】
ステップS240で、救急医療サーバ2000は、救急患者の状態情報を利用して救急イベント発生可能性情報を算出することができる。
【0057】
この場合、救急イベント発生可能性情報は、集中治療室入室可能性情報、STEMI(ST-Elevation Myocardial Infarction、ST分節上昇心筋梗塞)発生可能性情報、UA(不安定狭心症、Unstable Angina)及びNSTEMI(Non ST-Elevation Myocardial Infarction、非ST分節上昇心筋梗塞)発生可能性情報、LVO(Large Vessel Occlusion、大血管閉鎖)発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環回復(ROSC)発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを含むことができる。
【0058】
本開示の一実施例によれば、救急AIサーバ3000は、事前に機械学習を通して生成した機械学習モデルに救急患者の状態情報を入力することで、それぞれのイベントに対する可能性情報を獲得できる。例えば、救急AIサーバ3000は、事前に集中治療室入室スクリーニングモデルを生成でき、救急患者の状態情報を集中治療室入室スクリーニングモデルに入力することで、集中治療室入室可能性情報を獲得できる。また、救急AIサーバ3000は、事前にSTEMIスクリーニングモデルを生成でき、救急患者の状態情報をSTEMIスクリーニングモデルに入力することでSTEMI発生可能性情報を獲得できる。また、救急AIサーバ3000は、事前にUA及びNSTEMIスクリーニングモデル、LVO発生スクリーニングモデル、脳梗塞及び脳出血スクリーニングモデル、自発循環(ROSC)回復スクリーニングモデル及び心停止再発スクリーニングモデルのうち少なくとも一つを生成でき、それぞれに救急患者の状態情報を入力することで、UA(不安定狭心症、Unstable Angina)及びNSTEMI(Non ST-Elevation Myocardial Infarction、非ST分節上昇心筋梗塞)発生可能性情報、LVO(Large Vessel Occlusion、大血管閉鎖)発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環(ROSC)回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを獲得できる。
【0059】
この場合、それぞれのスクリーニングモデルは、データの内在された不確実性をモデリングすると同時に結果値を解析できるベイジアン深層ネットワークを通して具現され得、これに限定されず、多様な方式に具現され得る。例えば、スクリーニングモデルは、指導学習(Supervised learning)、サポートベクターマシン(Support Vector Machines、SVM)、ランダムフォレスト(Random Forest、RF)、ナイーブベイズ(Naive Bayes、NB)、人工神経網(Artificial Neural Network、ANN)、判断ツリー(Decision Tree)及びベイジアン(Bayesian)等のアルゴリズムのうち一つを通して具現され得、これに限定されない。
【0060】
この場合、救急AIサーバ3000は、引き続き入力される救急患者のデータを活用して機械学習を続けることで、各スクリーニングモデルの正確度を増進させることができる。
【0061】
ステップS250で、救急AIサーバ3000は、輸送資源可用情報を獲得できる。
【0062】
例えば、救急AIサーバ3000は、救急医療サーバ2000から輸送資源可用情報を獲得できる。また、救急AIサーバ3000は、救急車デバイス1000から輸送資源可用情報を獲得できる。また、救急AIサーバ3000は、これに限定されず、多様な外部デバイスから輸送資源可用情報を獲得できる。
【0063】
輸送資源可用情報は、救急患者を移送に必要となる資源に対する情報であって、リアルタイム交通情報、候補病院それぞれの位置情報、現在位置情報、候補病院それぞれの可用病床情報、候補病院それぞれの当直医情報、候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報のうち少なくとも一つを含むことができる。
【0064】
ステップS260で、救急AIサーバ3000は、候補病院それぞれの適合度を算出することができる。
【0065】
本開示の一実施例によれば、救急AIサーバ3000は、決定された患者の重症度、獲得した救急イベント発生可能性情報及び前記輸送資源可用情報のうち少なくとも一つに基づいて、候補病院それぞれの適合度を算出することができる。
【0066】
例えば、救急AIサーバ3000は、最適な病院選定モデルを予め生成して保有でき、決定された患者の重症度、救急イベント発生可能性情報及び輸送資源可用情報を最適な病院選定モデルに入力することで、候補病院それぞれに対する適合度を算出することができる。
【0067】
この場合、最適な病院選定モデルを生成するために活用されるアルゴリズムは、指導学習(Supervised learning)、サポートベクターマシン(Support Vector Machines、SVM)、ランダムフォレスト(Random Forest、RF)、ナイーブベイズ(Naive Bayes、NB)、人工神経網(Artificial Neural Network、ANN)、判断ツリー(Decision Tree)及びベイジアン(Bayesian)のうち少なくとも一つを含むことができ、これに限定されない。
【0068】
ステップS270で、救急AIサーバ3000は、最適な移送病院を選定できる。
【0069】
本開示の一実施例によれば、救急AIサーバ3000は、候補病院の中で適合度が高い順序によって最適な移送病院を決定し、決定された最適な移送病院に対する情報を救急車デバイス1000に提供できる。例えば、救急AIサーバ3000は、候補病院のうち適合度が最も高い一つの病院を最適な移送病院に決定し、これに対する情報を救急車デバイス1000に提供できる。また、救急AIサーバ3000は、候補病院のうち適合度が高い順序によって事前決定された個数の病院(例えば、2個、3個等)を最適な移送病院に決定し、これに対する情報を救急車デバイス1000に提供できる。
【0070】
図3は、本開示の一実施例によって最適な移送病院を再決定する方法を説明するための図である。
【0071】
本開示の一実施例によれば、救急AIサーバ3000は、決定された最適な移送病院の適合度が事前決定された値未満である場合、最適な移送病院を再決定できる。
【0072】
ステップS310で、救急AIサーバ3000は、探索半径を拡大して候補病院を再決定できる。例えば、救急AIサーバ3000は、救急車の位置(または、救急患者が発生した地点)から探索半径を拡大(例えば、2km増加、都市拡大、地域拡大等)して、候補病院を再決定できる。
【0073】
ステップS320で、救急AIサーバ3000は、再決定された候補病院の適合度を算出できる。例えば、救急AIサーバ3000は、再決定された候補病院を反映して輸送資源可用情報を再獲得でき、再決定された候補病院それぞれの適合度を再算出できる。適合度を算出する方法については図2において説明したので、これについての詳細な説明は省略する。
【0074】
ステップS330で、救急AIサーバ3000は、最適な移送病院を再決定できる。
【0075】
本開示の一実施例によれば、救急AIサーバ3000は、再決定された候補病院の中で適合度が高い順序によって最適な移送病院を決定し、再決定された最適な移送病院に対する情報を救急車デバイス1000に提供できる。例えば、救急AIサーバ3000は、候補病院のうち適合度が最も高い一つの病院を最適な移送病院に再決定し、これに対する情報を救急車デバイス1000に提供できる。
【0076】
本開示の一実施例によれば、再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまでS310探索半径を拡大して候補病院を再決定するステップ;S320再決定された候補病院の適合度を算出するステップ;S330算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップ;を引き続き繰り返すことができる。
【0077】
図4は、本開示の一実施例によって複数名の救急患者が発生した場合の最適な移送病院を決定する方法を説明するための図である。
【0078】
事前決定された距離以内に類似した症状を有する救急患者が類似した時点に発生した場合、個人別の最適な病院選定モジュールだけを活用するならば全ての患者が同じ病院へ移送される可能性がある。
【0079】
本開示の一実施例によれば、s410を参照する場合、事前決定された距離以内で、事前決定された時間以内に複数名の救急患者が発生した場合、救急AIサーバ3000は、救急患者の情報及び候補病院の情報を利用して救急患者それぞれの候補病院に対する重み付け情報を生成できる。
【0080】
救急患者それぞれの候補病院に対する重み付けは、下記の式により説明され得る。
【数1】
【0081】
これを解いて説明すると、
【数2】
により説明され得、
【数3】
部分は、下記のように具体化され得る。
【数4】
【0082】
結論的に、救急患者それぞれの重み付けは、下記の式により算出され得る。
【数5】
【0083】
また説明すると、救急AIサーバ3000は、1)移送距離基盤病院モデリング及び2)患者情報基盤病院モデリングを通して救急患者それぞれの候補病院に対する重み付けを算出できる。
【0084】
この場合、変数は、下記のように説明され得る。
【0085】
【表1】
【0086】
1)移送距離基盤病院モデリング
移送距離は、代表重症度疾患に該当するゴールデンタイム情報と密接な関連を持っている。従って、病院(j)と病変(k)因子情報と共に計算された移送距離情報を基盤に救急患者の候補病院に対する重み付けを算出することができる。
【0087】
2)患者情報基盤病院モデリング
特定患者に対する心停止(cardiac arrest)入院生存率、主要外傷(major trauma)、STEMI収容率及び脳卒中(stroke)収容率のうち少なくとも一つに対する患者情報(φ)、病変(k)、集中治療室入室如何(ρ)に基づいて救急患者の候補病院に対する重み付けを算出することができる。
【0088】
本開示の一実施例によって救急患者それぞれの候補病院に対する重み付けを算出する方法を具体的に説明すると、下記の式により算出され得る。
【0089】
1)移送距離基盤モデリングの一実施例
【数6】
【0090】
2)患者情報基盤モデリングの一実施例
【数7】
【0091】
1番目、1)で確率が0になる場合
1)で確率が0になる場合、生存確率が希薄な場合を意味するが、最終的に1)と2)、そして以前weightのjoint演算(
)でアップデートがなされるリアルタイム患者の重み付けは、1)で確率が0になるため、全重み付け(
)は、0になる。同じ病院に患者が集まる場合(仮定状況)、特定病院Aに重み付けが反映された患者リストが伝達されるはずであるが、重み付けが0になった患者は、リアルタイム重み付けリストから患者情報が消えるようになる。従って、患者情報消滅は、該当患者が病院に割り当てられる機能を失うものであるため、仮定状況に対する例外が発生する。
【0092】
結論的に、リアルタイム全ての患者の重み付けが整列されているリストで0になった患者は除外されて病院リストから除外される。
【0093】
2番目、2)で条件変数cにより影響を受ける場合
2)でc1、c2、c3、c4、c5、c6条件により1番目の仮定のようにリアルタイム患者重み付けが0になり得る。しかし、この場合は、単に病院自体承認、病床現況、移送自制等、病院の収容如何と関連があるものであるので、早い時間に次善策になる病院を探索する過程が必要である。
【0094】
病院再探索以前に条件変数により患者の重み付けが0になると1番目の仮定のように病院リストには患者情報が消滅する。従って、仮定状況に対する例外が発生する。
【0095】
3番目、重み付けが0にならない場合
1)と2)で重み付けが0にならない場合がある。該当場合では、病院リストにある患者情報が抜けないため、病院で許容可能な範囲をリアルタイムアップデートして順次的な処理をするようになる。ここで、許容可能な範囲をリアルタイムアップデートをする過程は、2番目の仮定と一部関連がある(収容不可時、c1、c2、c3=0になって病院で保有した患者情報消滅)。
【0096】
即ち、仮定状況であるとき、救急隊員により先に見つけられる患者からFirst-In-First-Outの順序によって病院Aのリストに入り、病院Aは、収容可能な患者は収容するが、超過する人員に対しては次の病院に割り振る方式でアルゴリズムが進められる。
【0097】
ステップs420で、救急AIサーバ3000は、救急患者それぞれの最終移送病院を決定できる。最適な移送病院を決定する方法については先に説明したので、ここで詳細な説明は省略する。
【0098】
ステップS430で、救急AIサーバ3000は、決定された最適な移送病院に救急患者の重み付け情報と共に患者を収容するか否かを問い合わせることができる。また、病院から問い合わせに対する応答を受信することができる。
【0099】
また、救急AIサーバ3000は、決定された最適な移送病院に対する情報及び救急患者の重み付け情報を救急車デバイス1000に提供でき、救急車デバイス1000は、救急患者の重み付け情報と共に患者を収容するか否かを病院に問い合わせることができる。
【0100】
ステップs440で、病院は、救急患者を収容するか否かを決定できる。また、病院は、該当患者を収容するか否かに対する答弁を救急車デバイスおよび/または救急AIサーバ3000に伝送することができる。
【0101】
病院では、複数の救急患者に対する重み付け情報を受信することができるので、重み付け情報を考慮して収容する救急患者を決定できる。また、重み付け情報を考慮して収容しない患者に対しては速く他の病院に割り振ることができる。
【0102】
ステップS450で、救急AIサーバ3000は、救急患者及び病院に対する情報をリアルタイムでアップデートできる。例えば、重み付けの高い患者が特定病院に割り振られた場合、特定病院の収容可能な患者は減少し得る。この場合、重み付けの低い患者に対しては変化した情報を反映して重み付け情報が再生成され得る。
【0103】
本開示の他の実施例によれば、最終移送病院を決定するステップ以後に重み付け情報を生成するステップが遂行され得る。具体的に、救急AIサーバ3000は、救急患者それぞれに対する最終移送病院を先に決定し、決定された最終移送病院に対する重み付け情報を算出して、最終移送病院に対する重み付け情報を生成できる。
【0104】
本開示の他の実施例によれば、救急AIサーバ3000は、重み付け情報を生成する以前に最適な移送病院を決定できる。例えば、救急AIサーバ3000は、救急患者それぞれに対して最終移送病院を決定し、決定された最終移送病院に対する重み付け情報を生成した後、重み付け情報と共に最適な移送病院に患者を収容するか否かを問い合わせることができる。この場合、重み付け情報を生成する病院の個数が減少することで、救急AIサーバ3000の効率性は増進され得る。
【0105】
図5は、本開示の一実施例によって最適な引き継ぎ点を推薦する方法を説明するための図である。
【0106】
本開示の一実施例によれば、救急AIサーバ3000は、最適な移送病院の位置情報リアルタイム交通情報、ドクターヘリ運行情報及び候補引き継ぎ点(救急車からドクターヘリに救急患者を引き継ぎできる地点)に対する情報を獲得できる。
【0107】
ステップS510で、救急AIサーバ3000は、救急患者の移送にドクターヘリを活用するか否かを決定できる。
【0108】
例えば、救急AIサーバ3000は、救急患者の状態が危急で応急措置が必要であるかまたは患者を移送するのに時間が多く遅延する状況(地域特性化反映)である場合、ドクターヘリを活用すると決定できる。
【0109】
ドクターヘリを活用すると決定した場合、ステップS520で、救急AIサーバ3000は、決定された最適な移送病院の位置情報、リアルタイム交通情報、候補引き継ぎ点位置情報、救急車位置情報(または、救急患者が発生した所の位置情報)及びドクターヘリ運行情報のうち少なくとも一つに基づいて最適な引き継ぎ点を決定できる。
【0110】
例えば、救急AIサーバ3000は、候補引き継ぎ点を決定でき、ドクターヘリを活用する複数個の候補ルートを決定できる。例えば、救急AIサーバ3000は、候補引き継ぎ点それぞれを活用する候補ルートを決定できる。
【0111】
また、救急AIサーバ3000は、複数の候補ルートそれぞれを通して最適な移送病院に行く時間を計算できる。例えば、救急AIサーバ3000は、決定された最適な移送病院の位置情報、リアルタイム交通情報、候補引き継ぎ点位置情報、救急車位置情報(または、救急患者が発生した所の位置情報)及びドクターヘリ運行情報を活用して、候補ルートそれぞれに対する所要時間を決定できる。
【0112】
また、救急AIサーバ3000は、所要時間が最も短い候補ルートを最適な移送ルートに決定できる。
【0113】
救急AIサーバ3000は、最適な移送ルートを決定する場合、これに対する情報を救急車デバイス1000に提供できる。この場合、救急車デバイス1000に提供される情報は、最適な引き継ぎ点に対する情報が含まれ得る。
【0114】
図6は、本開示の一実施例によって最適な移送病院を決定するアルゴリズムを詳細に説明するための図である。
【0115】
図6を参照する場合、
は、移送中のデータと現時点の病院内資源情報が与えられた場合、i番目の病院の適合度を示すことができる。これは、下記に開示される条件付き確率を通して計算可能であり得る。
【0116】
は、移送中のデータが与えられた場合、救急イベント発生可能性情報及び重症度分類結果を示すことができる。
【0117】
は、救急イベント発生可能性情報及び輸送資源可用情報が与えられた場合、i番目の病院の適合度を示す。
【0118】
下記の表は、入力変数及び出力変数の例示を示す。
【0119】
1.
に対する入力変数と出力変数の例示
【表2】
【0120】
2.
に対する入力変数と出力変数の例示
【表3】
【0121】
3.
に対する入力変数と出力変数の例示
【表4】
【0122】
図7は、本開示の一実施例に係る救急AIサーバの構成要素を説明するための図である。
【0123】
本開示の一実施例によれば、救急AIサーバ3000は、制御部3300、ネットワーク連結部3100及び格納部3200を含むことができ、これに限定されず、多様な構成要素を含むことができる。
【0124】
格納部3200は、多様な情報を保有できる。例えば、格納部3200は、受信した救急患者の状態情報(例えば、生体信号情報、年齢情報、訴える症状情報、既存の病歴情報、意識情報、心電図情報等)を含むことができる。また、格納部3200は、輸送資源情報(例えば、リアルタイム交通情報、候補病院それぞれの位置情報、現在位置情報、候補病院それぞれの可用病床情報、候補病院それぞれの当直医情報、候補病院それぞれの施設情報、ドクターヘリ位置情報及びドクターヘリ運行情報等)を保有できる。
【0125】
また、格納部3200に格納された情報は、外部のデバイスから受信した情報に基づいてリアルタイムまたは非リアルタイムでアップデートされ得る。
【0126】
格納部3200は、任意のデータを持続的に格納できる非-揮発性(non-volatile)格納媒体を通して具現され得る。例えば、格納部3200は、ディスク、光学(optical)ディスク及び光磁気(magneto-optical)格納デバイスだけではなく、フラッシュメモリおよび/またはバッテリー-バックアップメモリに基づいた格納デバイスを含むことができ、これに限定されない。
【0127】
また、格納部3200は、多様な機械学習モデルを保有できる。例えば、格納部3200は、重症度判断モデル、集中治療室入室スクリーニングモデル、STEMIスクリーニングモデル、UA及びNSTEMIスクリーニングモデル、LVO発生スクリーニングモデル、脳出血スクリーニングモデル、自発循環(ROSC)回復スクリーニングモデル及び心停止再発スクリーニングモデルのうち少なくとも一つを保有できる。制御部3300は、外部から獲得したデータを活用して機械学習を進行することで、格納部3200に格納された機械学習モデルを引き続きアップデートできる。
【0128】
ネットワーク連結部3100は、任意の形態のネットワークを通して救急車デバイス1000及び救急医療サーバ2000と通信を遂行することができる。ネットワーク連結部3100は、ネットワーク接続のための有/無線接続モジュールを含むことができる。無線接続技術としては、例えば、
【0129】
WLAN(Wireless LAN)(Wi-Fi(登録商標))、Wibro(Wireless broadband)、Wimax(登録商標)(World Interoperability for Microwave Access)、HSDPA(High Speed Downlink PacketAccess)、IMT(International Mobile Telecommunication System)2000、IMT-advanced、IMT-2020等が利用され得る。
【0130】
制御部3300は、少なくとも一つのプロセッサ(processor)に具現され得る。例えば、制御部3300は、一つのプロセッサに具現され得、複数のプロセッサに具現され得る。また、制御部3300が複数のプロセッサに具現された場合、複数のプロセッサは、物理的に隣接した所に位置し得、物理的に離隔された所に位置し得る。
【0131】
本開示の一実施例によれば、制御部3300は、最適な移送病院の候補病院を決定できる。例えば、制御部3300は、救急車が位置する地点(または、救急患者が発生した地点)から事前決定された距離(例えば、3km、5km等)以内に位置した病院を候補病院に決定できる。また、制御部3300は、救急車が位置した地点が含まれる都市(例えば、ソウル市、仁川市、水原市等)内に位置した病院を候補病院に決定できる。また、制御部3300は、救急車が位置した区(例えば、江南区、瑞草区、江東区等)内に位置した病院を候補病院に決定でき、これに限定されず、多様な方法で候補病院を決定できる。
【0132】
また、制御部3300は、救急患者の状態情報を獲得できる。例えば、制御部3300は、救急患者の状態情報を救急車デバイス1000から獲得できる。
【0133】
制御部3300は、救急患者の重症度を決定できる。例えば、制御部3300は、救急患者の状態情報を利用して患者の重症度を決定できる。
【0134】
この場合、制御部3300は、機械学習を通して重症度判断モデルを予め生成でき(または、予め保有でき)、重症度判断モデルに救急患者の状態情報を入力することで、救急患者の重症度を決定できる。
【0135】
この場合、制御部3300は、病院前韓国型救急患者分類道具(Prehospital KTAS)を基盤に救急患者の救急度を決定できる。例えば、制御部3300は、救急患者の年齢を活用して1次的にコードを付与し、症状に対する大分類(例えば、消化器、皮膚、神経科等)を遂行して2次的にコードを付与し、大分類に対する中分類(例えば、腹痛、嘔吐/吐き気等)を遂行して3次的にコードを付与し、中分類に対する細部症状(例えば、呼吸困難、ショック等)を判別して4次的にコードを付与できる。そして、制御部3300は、最終的に付与されたコードにマッチングされる重症度(例えば、1、2、3、4、5ステップ、1ステップが最も危険であり得る)を救急患者の重症度に決定できる。
【0136】
この場合、重症度判断モデルを生成するために活用されるアルゴリズムは、指導学習(Supervised learning)、サポートベクターマシン(Support Vector Machines、SVM)、ランダムフォレスト(Random Forest、RF)、ナイーブベイズ(Naive Bayes、NB)、人工神経網(Artificial Neural Network、ANN)、判断ツリー(Decision Tree)及びベイジアン(Bayesian)のうち少なくとも一つを含むことができ、これに限定されない。
【0137】
救急AIサーバ2000は、救急患者の状態情報を利用して救急イベント発生可能性情報を算出することができる。
【0138】
本開示の一実施例によれば、制御部3300は、事前に機械学習を通して生成した機械学習モデルに救急患者の状態情報を入力することで、それぞれのイベントに対する可能性情報を獲得できる。例えば、制御部3300は、事前に集中治療室入室スクリーニングモデルを生成(および/または保有)でき、救急患者の状態情報を集中治療室入室スクリーニングモデルに入力することで、集中治療室入室可能性情報を獲得できる。また、制御部3300は、事前にSTEMIスクリーニングモデルを生成(および/または保有)でき、救急患者の状態情報をSTEMIスクリーニングモデルに入力することでSTEMI発生可能性情報を獲得できる。また、制御部3300は、事前にUA及びNSTEMIスクリーニングモデル、LVO発生スクリーニングモデル、脳梗塞及び脳出血スクリーニングモデル、自発循環(ROSC)回復スクリーニングモデル及び心停止再発スクリーニングモデルのうち少なくとも一つを生成(および/または保有)でき、それぞれに救急患者の状態情報を入力することで、UA(不安定狭心症、Unstable Angina)及びNSTEMI(Non ST-Elevation Myocardial Infarction、非ST分節上昇心筋梗塞)発生可能性情報、LVO(Large Vessel Occlusion、大血管閉鎖)発生可能性情報、脳梗塞及び脳出血発生可能性情報、自発循環(ROSC)回復発生可能性情報及び心停止再発可能性情報のうち少なくとも一つを獲得できる。
【0139】
この場合、それぞれのスクリーニングモデルは、データの内在された不確実性をモデリングすると同時に結果値を解析できるベイジアン深層ネットワークを通して具現され得、これに限定されず、多様な方式に具現され得る。例えば、スクリーニングモデルは、指導学習(Supervised learning)、サポートベクターマシン(Support Vector Machines、SVM)、ランダムフォレスト(Random Forest、RF)、ナイーブベイズ(Naive Bayes、NB)、人工神経網(Artificial Neural Network、ANN)、判断ツリー(Decision Tree)及びベイジアン(Bayesian)等のアルゴリズムのうち一つを通して具現され得、これに限定されない。
【0140】
この場合、制御部3300は、引き続き入力される救急患者のデータを活用して機械学習を続けることで、各スクリーニングモデルの正確度を増進させることができる。
【0141】
制御部3300は、候補病院それぞれの適合度を算出することができる。本開示の一実施例によれば、制御部3300は、決定された患者の重症度、獲得した救急イベント発生可能性情報及び前記輸送資源可用情報のうち少なくとも一つに基づいて、候補病院それぞれの適合度を算出することができる。
【0142】
例えば、制御部3300は、最適な病院選定モデルを予め生成して保有でき、決定された患者の重症度、救急イベント発生可能性情報及び輸送資源可用情報を最適な病院選定モデルに入力することで、候補病院それぞれに対する適合度を算出することができる。
【0143】
制御部3300は、最適な移送病院を選定できる。本開示の一実施例によれば、制御部3300は、候補病院の中で適合度が高い順序によって最適な移送病院を決定し、決定された最適な移送病院に対する情報を救急車デバイス1000に提供できる。例えば、制御部3300は、候補病院のうち適合度が最も高い一つの病院を最適な移送病院に決定し、これに対する情報を救急車デバイス1000に提供できる。また、制御部3300は、候補病院のうち適合度が高い順序によって事前決定された個数の病院(例えば、2個、3個等)を最適な移送病院に決定し、これに対する情報を救急車デバイス1000に提供できる。
【0144】
本開示の一実施例によれば、制御部3300は、決定された最適な移送病院の適合度が事前決定された値未満である場合、最適な移送病院を再決定できる。
【0145】
制御部3300は、探索半径を拡大して候補病院を再決定できる。例えば、制御部3300は、救急車の位置(または、救急患者が発生した地点)から探索半径を拡大(例えば、2km増加、都市拡大、地域拡大等)して、候補病院を再決定できる。
【0146】
制御部3300は、再決定された候補病院の適合度を算出できる。例えば、制御部3300は、再決定された候補病院を反映して輸送資源可用情報を再獲得でき、再決定された候補病院それぞれの適合度を再算出できる。適合度を算出する方法については図2において説明したので、これについての詳細な説明は省略する。
【0147】
制御部3300は、最適な移送病院を再決定できる。本開示の一実施例によれば、制御部3300は、再決定された候補病院の中で適合度が高い順序によって最適な移送病院を決定し、再決定された最適な移送病院に対する情報を救急車デバイス1000に提供できる。例えば、制御部3300は、候補病院のうち適合度が最も高い一つの病院を最適な移送病院に再決定し、これに対する情報を救急車デバイス1000に提供できる。
【0148】
本開示の一実施例によれば、再決定された最適な移送病院の適合度が事前決定された値未満である場合、再決定された最適な移送病院の適合度が事前決定された値以上になるまでS310探索半径を拡大して候補病院を再決定するステップ;S320再決定された候補病院の適合度を算出するステップ;S330算出された候補病院それぞれの適合度に基づいて最適な移送病院を再決定するステップ;を引き続き繰り返すことができる。
【0149】
制御部3300は、事前決定された距離以内で、事前決定された時間以内に複数名の救急患者が発生した場合、制御部3300は、救急患者の情報及び候補病院の情報を利用して救急患者それぞれの候補病院に対する重み付け情報を生成できる。これについては、図4において詳細に上述している。
【0150】
また、制御部3300は、救急患者それぞれの最終移送病院を決定できる。最適な移送病院を決定する方法については先に説明したので、ここで詳細な説明は省略する。
【0151】
制御部3300は、決定された最適な移送病院に救急患者の重み付け情報と共に患者を収容するか否かを問い合わせることができる。また、病院から問い合わせに対する応答を受信することができる。
【0152】
病院は、救急患者を収容するか否かを決定できる。また、病院は、該当患者を収容するか否かに対する答弁を救急車デバイスおよび/または救急AIサーバ3300に伝送することができる。
【0153】
制御部3300は、救急患者及び病院に対する情報をリアルタイムでアップデートできる。例えば、重み付けの高い患者が特定病院に割り振られた場合、特定病院の収容可能な患者は減少し得る。この場合、重み付けの低い患者に対しては変化した情報を反映して重み付け情報が再生成され得る。
【0154】
本開示の一実施例によれば、制御部3300は、最適な移送病院の位置情報リアルタイム交通情報、ドクターヘリ運行情報及び候補引き継ぎ点(救急車からドクターヘリに救急患者を引き継ぎできる地点)に対する情報を獲得できる。
【0155】
制御部3300は、救急患者の移送にドクターヘリを活用するか否かを決定できる。例えば、制御部3300は、救急患者の状態が危急で応急措置が必要であるかまたは患者を移送するのに時間が多く遅延する状況(地域特性化反映)である場合、ドクターヘリを活用すると決定できる。
【0156】
ドクターヘリを活用すると決定した場合、制御部3300は、決定された最適な移送病院の位置情報、リアルタイム交通情報、候補引き継ぎ点位置情報、救急車位置情報(または、救急患者が発生した所の位置情報)及びドクターヘリ運行情報のうち少なくとも一つに基づいて最適な引き継ぎ点を決定できる。
【0157】
例えば、制御部3300は、候補引き継ぎ点を決定でき、ドクターヘリを活用する複数個の候補ルートを決定できる。例えば、制御部3300は、候補引き継ぎ点それぞれを活用する候補ルートを決定できる。
【0158】
また、制御部3300は、複数の候補ルートそれぞれを通して最適な移送病院に行く時間を計算できる。例えば、制御部3300は、決定された最適な移送病院の位置情報、リアルタイム交通情報、候補引き継ぎ点位置情報、救急車位置情報(または、救急患者が発生した所の位置情報)及びドクターヘリ運行情報を活用して、候補ルートそれぞれに対する所要時間を決定できる。
【0159】
また、制御部3300は、所要時間が最も短い候補ルートを最適な移送ルートに決定できる。
【0160】
本開示の技術の分野において通常の知識を有する者は、情報及び信号が任意の多様な異なる技術及び技法を利用して表現され得るということを理解するだろう。例えば、上の説明において参照され得るデータ、指示、命令、情報、信号、ビット、シンボル及びチップは、電圧、電流、電磁波、磁場または粒子、光学場または粒子、またはこれらの任意の結合により表現され得る。
【0161】
本開示の技術の分野において通常の知識を有する者は、ここに開示された実施例と関連して説明された多様な例示的な論理ブロック、モジュール、プロセッサ、手段、回路及びアルゴリズムステップが電子ハードウェア、(便宜のために、ここで「ソフトウェア」と称される)多様な形態のプログラムまたは設計コードまたはこれらの全ての結合により具現され得るということを理解するだろう。ハードウェア及びソフトウェアのこのような相互互換性を明確に説明するために、多様な例示的なコンポーネント、ブロック、モジュール、回路及びステップがこれらの機能と関連して上で一般的に説明された。このような機能がハードウェアまたはソフトウェアとして具現されるか否かは、特定のアプリケーション及び全システムに対して賦課される設計制約によって左右される。本開示の技術の分野において通常の知識を有する者は、それぞれの特定のアプリケーションに対して多様な方式で説明された機能を具現できるが、このような具現決定は、本開示の範囲を外れるものと解釈されてはならないだろう。
【0162】
ここで提示された多様な実施例は、方法、装置、または標準プログラミングおよび/またはエンジニアリング技術を使用した製造物品(article)に具現され得る。用語「製造物品」は、任意のコンピュータ-読み取り可能格納装置からアクセス可能なコンピュータプログラム、キャリア、または媒体(media)を含む。例えば、コンピュータ-読み取り可能格納媒体は、磁気格納装置(例えば、ハードディスク、フロッピーディスク、磁気ストリップ等)、光学ディスク(例えば、CD、DVD等)、スマートカード、及びフラッシュメモリ装置(例えば、EEPROM、カード、スティック、キードライブ等)を含むが、これらに制限されるものではない。また、ここで提示される多様な格納媒体は、情報を格納するための一つ以上の装置および/または他の機械-読み取り可能な媒体を含む。
【0163】
提示されたプロセスにあるステップの特定の順序または階層構造は、例示的な接近の一例であることを理解するようにする。設計優先順位を基盤に、本開示の範囲内でプロセスにあるステップの特定の順序または階層構造が再配列され得るということを理解するようにする。添付の方法請求項は、サンプル順に多様なステップのエレメントを提供するが、提示された特定の順序または階層構造に限定されることを意味するものではない。
【0164】
提示された実施例についての説明は、任意の本開示の技術の分野において通常の知識を有する者が本開示を利用または実施できるように提供される。このような実施例に対する多様な変形は、本開示の技術の分野において通常の知識を有する者に明らかであり、ここに定義された一般的な原理は、本開示の範囲を外れることなく他の実施例に適用され得る。それゆえ、本開示は、ここに提示された実施例に限定されるものではなく、ここに提示された原理及び新規な特徴と一貫する最広義の範囲で解釈されるべきである。
図1
図2
図3
図4
図5
図6
図7