(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-03-18
(45)【発行日】2025-03-27
(54)【発明の名称】システム
(51)【国際特許分類】
G06Q 50/26 20240101AFI20250319BHJP
【FI】
G06Q50/26
(21)【出願番号】P 2023523896
(86)(22)【出願日】2021-05-28
(86)【国際出願番号】 JP2021020332
(87)【国際公開番号】W WO2022249434
(87)【国際公開日】2022-12-01
【審査請求日】2023-10-27
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100168310
【氏名又は名称】▲高▼橋 幹夫
(72)【発明者】
【氏名】冬野 哲也
【審査官】山崎 誠也
(56)【参考文献】
【文献】特開2017-038205(JP,A)
【文献】特開2014-183419(JP,A)
【文献】特開2010-057075(JP,A)
【文献】特開2019-046122(JP,A)
【文献】特開2016-100886(JP,A)
【文献】木村 博典,地域中核病院におけるBCPのためのクラウド活用,IT vision,(株)インナービジョン,2013年06月25日,No. 28,p.52-54
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
複数の住民うち防災担当者により指定された地域に住む住民を選択し、前記選択された住民が所持する端末に対して、避難情報を送信する、自治体サーバと、
病院サーバと、
を含み、
前記自治体サーバは、前記選択された住民の健康情報をデータ共有により前記病院サーバから取得し、前記取得された健康情報に基づいて、前記選択された住民に案内する避難所を選択する、システム。
【請求項2】
前記病院サーバは、患者の電子カルテに記載されたデータのうち少なくとも一部が前記自治体サーバと前記データ共有されることに関する共有許諾情報を記憶する、請求項
1に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体に関する。
【背景技術】
【0002】
台風等によって大規模災害の発生が予測されると、住民は避難所に避難することになる。住民の避難に関し、種々の技術開発が行われている。
【0003】
特許文献1には、災害時に住民を含む罹災者に各自の状況に合った避難所情報を提供し、罹災者にとってもっとも適合した避難所へと誘導あるいは、各自が避難先を判断できるような機能を備えた災害時避難所情報提供システムを提供する、と記載されている。特許文献1のシステムは、避難所情報提供サーバを含む。当該サーバは、登録処理部と、照会処理部と、を備える。登録処理部は、利用者の住民基本台帳情報を含む住民情報データベースの情報に基づいて、避難所情報を検索する際の優先項目の情報を含む利用者の災害時の住民情報を災害時住民情報データベースに登録する。照会処理部は、災害時の住民情報に基づいて、避難所情報を検索し、避難所情報を利用者に提供する。
【0004】
また、近年の情報処理技術、通信技術の発展により、患者のオンライン診療が可能となっている。
【0005】
例えば、特許文献2には、遠隔診療を支援するサーバであって、医療機関から薬局への処方箋の共有、及び患者の薬の受取のプロセスをスムーズに行うことのできるサーバを提供する、と記載されている。
【先行技術文献】
【特許文献】
【0006】
【文献】特開2014-041507号公報
【文献】特許第6781491号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
上述のように、大規模災害の発生が予測されると、住民は避難所に避難することになる。住民が避難可能な避難所は複数存在することが多いが、住民はいずれの避難所に避難するのがよいのか判断できないことも多い。
【0008】
なお、当該問題点は、上記特許文献1、特許文献2に開示された技術を適用しても解決することはできない。特許文献1の開示は、優先的に避難する住民を選択するに留まるためである。また、特許文献2の開示は、オンライン診療に関する文献であって、住民による避難所の選択とは無関係である。
【0009】
本発明は、住民に適した避難所を案内することに寄与する、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体を提供することを主たる目的とする。
【課題を解決するための手段】
【0010】
本発明の第1の視点によれば、住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する、生成部と、前記生成された避難情報を前記住民が所持する端末に送信する、送信部と、を備える、サーバ装置が提供される。
【0011】
本発明の第2の視点によれば、複数の住民うち防災担当者により指定された地域に住む住民を選択し、前記選択された住民が所持する端末に対して、避難情報を送信する、自治体サーバと、病院サーバと、を含み、前記自治体サーバは、前記選択された住民の健康情報をデータ共有により前記病院サーバから取得し、前記取得された健康情報に基づいて、前記選択された住民に案内する避難所を選択する、システムが提供される。
【0012】
本発明の第3の視点によれば、サーバ装置において、住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成し、前記生成された避難情報を前記住民が所持する端末に送信する、サーバ装置の制御方法が提供される。
【0013】
本発明の第4の視点によれば、サーバ装置に搭載されたコンピュータに、住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する処理と、前記生成された避難情報を前記住民が所持する端末に送信する処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。
【発明の効果】
【0014】
本発明の各視点によれば、住民に適した避難所を案内することに寄与する、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。
【図面の簡単な説明】
【0015】
【
図1】
図1は、一実施形態の概要を説明するための図である。
【
図2】
図2は、第1の実施形態に係る防災システムの概略構成の一例を示す図である。
【
図3】
図3は、第1の実施形態に係る防災システムの動作を説明するための図である。
【
図4】
図4は、第1の実施形態に係る防災システムの動作を説明するための図である。
【
図5】
図5は、第1の実施形態に係る防災システムの動作を説明するための図である。
【
図6】
図6は、第1の実施形態に係る防災システムの動作を説明するための図である。
【
図7】
図7は、第1の実施形態に係る自治体サーバの処理構成の一例を示す図である。
【
図8】
図8は、第1の実施形態に係る住民登録部の動作を説明するための図である。
【
図9】
図9は、第1の実施形態に係る住民情報データベースの一例を示す図である。
【
図10】
図10は、第1の実施形態に係る避難情報制御部の処理構成の一例を示す図である。
【
図11】
図11は、第1の実施形態に係る避難情報制御部の動作の一例を示すフローチャートである。
【
図12】
図12は、第1の実施形態に係る避難情報制御部の動作を説明するための図である。
【
図13】
図13は、第1の実施形態に係る避難所情報データベースの一例を示す図である。
【
図14】
図14は、第1の実施形態に係る避難情報制御部の動作を説明するための図である。
【
図15】
図15は、第1の実施形態に係る避難情報制御部の動作を説明するための図である。
【
図16】
図16は、第1の実施形態に係る病院サーバの処理構成の一例を示す図である。
【
図17】
図17は、第1の実施形態に係る患者情報データベースの一例を示す図である。
【
図18】
図18は、第1の実施形態に係る共有制御部の動作を説明するための図である。
【
図19】
図19は、第1の実施形態に係る防災システムの動作の一例を示すシーケンス図である。
【
図20】
図20は、第2の実施形態に係る住民情報データベースの一例を示す図である。
【
図21】
図21は、第2の実施形態に係る防災システムの概略構成の一例を示す図である。
【
図22】
図22は、第2の実施形態に係る受付端末の処理構成の一例を示す図である。
【
図23】
図23は、第2の実施形態に係る自治体サーバの処理構成の一例を示す図である。
【
図24】
図24は、第2の実施形態に係る病院サーバの処理構成の一例を示す図である。
【
図25】
図25は、第2の実施形態に係る防災システムの動作の一例を示すシーケンス図である。
【
図26】
図26は、第3の実施形態を説明するための図である。
【
図27】
図27は、第3の実施形態に係る医療端末の処理構成の一例を示す図である。
【
図28】
図28は、第3の実施形態に係る生体情報取得部の動作を説明するための図である。
【
図29】
図29は、第3の実施形態に係る自治体サーバの処理構成の一例を示す図である。
【
図30】
図30は、第3の実施形態に係る病院サーバの処理構成の一例を示す図である。
【
図31】
図31は、第3の実施形態に係る防災システムの動作の一例を示すシーケンス図である。
【
図32】
図32は、本願開示に係る自治体サーバのハードウェア構成の一例を示す図である。
【
図33】
図33は、本願開示の変形例に係る自治体サーバの動作を説明するための図である。
【発明を実施するための形態】
【0016】
はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号(データ)の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。
【0017】
一実施形態に係るサーバ装置100は、生成部101と、送信部102と、を備える(
図1参照)。生成部101は、住民の健康情報に基づいて、当該住民に案内する避難所に関する情報を含む避難情報を生成する。送信部102は、生成された避難情報を住民が所持する端末に送信する。
【0018】
サーバ装置100は、住民に対して避難情報を送信する際、当該住民の健康状態を考慮して避難所を選択し、当該選択した避難所に関する情報(例えば、避難所の名称や場所)を住民に通知する。例えば、サーバ装置100は、健康状態に不安のない住民に関しては、特段の設備等を備えていない避難所を選択し、避難情報を用いて当該避難所を案内する。対して、健康状態に不安のある住民に関しては、サーバ装置100は、医師や看護師が常駐している避難所や医療設備が整った避難所を選択し、避難情報を用いて当該避難所を案内する。このように、サーバ装置100は、避難情報が送信される地域に住む住民に適した避難所を案内できる。
【0019】
以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。
【0020】
[第1の実施形態]
第1の実施形態について、図面を用いてより詳細に説明する。
【0021】
[システムの構成]
図2は、第1の実施形態に係る防災システムの概略構成の一例を示す図である。
図2に示すように、防災システムには、防災センター、少なくとも1以上の病院、少なくとも1以上の避難所が含まれる。
【0022】
防災センターは、地域の自治体等により管理、運営される。防災センターは、例えば、市役所等に設置される。各地域の学校、公民館等の施設が避難所に該当する。学校、公民館等の施設は、災害発生時に「避難所」として活用される。
【0023】
防災センターは、自治体サーバ10を運営、管理する。自治体サーバ10は、地域住民の防災に関する管理、避難所の運営、避難者の支援等を担うサーバ装置である。自治体サーバ10は、防災センターが設置された建物と同じ建物に設置されていてもよいし、ネットワーク上(クラウド上)に設置されていてもよい。
【0024】
各病院は、病院サーバ20を備える。病院サーバ20は、患者の診療結果(診察結果、治療結果)を記憶する。病院サーバ20は、患者の診療結果等を「電子カルテ」として記憶する。病院サーバ20は、患者の基本情報、診療に関する診療情報、バイタルデータ、服薬に関する服薬情報等を電子カルテによって一元管理する。
【0025】
患者の基本情報には、患者ID(IDentifier)、氏名、生年月日、住所、連絡先、既往症等に関する情報が含まれる。診療情報には、患者の主訴(問診票への記載事項)、検査結果(レントゲン等の結果)、診断名(診断により確定した病名;現症)、治療方針等の情報が含まれる。バイタルデータには、血圧、脈拍、体温等に関する情報(測定結果、測定履歴)が含まれる。服薬情報には、処方された薬の名称や服薬の指示(服薬のタイミング、服薬量)等が含まれる。
【0026】
各病院が備える病院サーバ20の機能は同一とすることができるので、以降の説明では、病院Aに設置された病院サーバ20を中心に説明する。
【0027】
図2に示す各装置は相互に接続されている。例えば、自治体サーバ10と病院サーバ20は、有線又は無線の通信手段により接続され、相互に通信が可能となるように構成されている。
【0028】
図2に示す防災システムの構成は例示であって、その構成を限定する趣旨ではない。例えば、防災センターには複数の自治体サーバ10が含まれていてもよい。同様に、各病院には、複数の病院サーバ20が含まれていてもよい。
【0029】
[動作概略]
続いて、第1の実施形態に係る防災システムの動作概略について説明する。
【0030】
第1の実施形態に係る防災システムにおいて、災害の発生が見込まれると、防災センターから各住民に避難情報が送信される。避難情報には、避難先に関する情報(例えば、避難所の名称や場所)が含まれる。避難情報を送信する際、防災センターは、各住民の状況、状態を確認し、それぞれの住民に適した避難所を選択して避難を促す。とりわけ、防災センターは、住民の健康状態を考慮して当該住民に案内する避難所を決定する。
【0031】
防災センターは、当該避難所を決定する際、各住民の「健康情報」を病院(住民のかかりつけ病院)から取得する。防災センターは、取得した健康情報に基づいて、各住民それぞれに適した避難所を選択し、住民に案内する。なお、健康情報は、各住民の健康に関する具体的な情報(データ)である。例えば、健康情報として、住民の既往症、現症、服薬情報等が例示される。
【0032】
<住民登録>
はじめに、地域の住民は、自身の情報を自治体(防災センター)に事前登録する(
図3参照)。以降の説明において、住民が自治体サーバ10に登録する情報を「住民情報」と記載する。
【0033】
住民は、任意の手段を用いて住民情報を自治体サーバ10に登録する。例えば、住民は、所持する端末30を操作して住民登録を行う。例えば、住民は、端末30を操作して、自治体サーバ10にアクセスする。より具体的には、住民は、自治体サーバ10が提供するWEB(ウェブ)ページにアクセスする。
【0034】
幼児や高齢者等、自ら情報の登録を行うことが困難な住民に関しては、親や子供が代理で幼児、高齢者等に関する住民情報を自治体サーバ10に登録してもよい。
【0035】
住民情報には、個人情報(所謂、基本4情報;氏名、性別、住所、生年月日)が含まれる。また、住民情報には、住民の連絡先(例えば、端末30で受信可能なメールアドレスや電話番号等)が含まれる。
【0036】
上記情報に加え、住民情報には、かかりつけの病院に関する情報(以下、単に病院情報と表記する)が含まれる。具体的には、かかりつけの病院名、当該かかりつけの病院から発行された患者ID等が「病院情報」に含まれる。
【0037】
なお、かかりつけの病院がない住民は、病院情報を防災センター(自治体サーバ10)に登録しなくてもよい。
【0038】
自治体サーバ10は、住民から個人情報、病院情報を取得すると、当該住民を識別するための住民IDを生成する。自治体サーバ10は、生成した住民ID、個人情報、病院情報等を対応付けて住民情報データベースに記憶する。住民情報データベースの詳細は後述する。
【0039】
<データ共有許諾>
かかりつけ病院を持つ住民は、上記住民登録に前後して、病院から防災センター(自治体)へのデータ共有(データの提供)に関する許諾を病院に設定する。例えば、住民は、端末30を操作して、かかりつけ病院の病院サーバ20にアクセスする(
図4参照)。より具体的には、住民は、病院サーバ20が提供するWEB(ウェブ)ページにアクセスする。
【0040】
当該WEBページにおいて、住民は、かかりつけ病院が記憶、管理する電子カルテに記載されたデータの全部又は一部のデータを外部提供することに対する許諾を与える。例えば、病院サーバ20は、住民の所持する端末30に
図5に示すようなGUI(Graphical User Interface)や入力フォームを表示する。
【0041】
住民は、端末30を操作して、データ共有の「目的」、共有するデータの「種類」、データの「共有先」、データ共有時の「条件」を病院サーバ20に入力する。
【0042】
例えば、住民は、データ共有の目的として「避難所案内」、共有データの種類として「既往症」、「現症」、「服薬情報」、データ共有先として「防災センター」、データ共有の条件として「避難指示以上発令時」を病院サーバ20に入力する。
【0043】
病院サーバ20は、上記住民から取得したデータ共有に関する情報を「共有許諾情報」として管理する。病院サーバ20は、当該住民の患者ID、電子カルテのID(カルテID)、共有許諾情報を対応付けて患者情報データベースに記憶する。患者情報データベースの詳細は後述する。
【0044】
上記住民登録とデータ共有許諾が、災害発生前に行われる事前準備である。続いて、
図6を参照しつつ、災害発生時の防災システムの動作について説明する。
【0045】
<避難情報送信>
自治体の防災担当者は、台風、大雨等によって災害が発生すると見込まれる際には、「避難情報送信指示」を自治体サーバ10に入力する(ステップS1)。例えば、防災担当者は、警戒レベルと共に避難情報送信指示を自治体サーバ10に入力する。
【0046】
当該指示に応じて、自治体サーバ10は、地域の住民に「避難情報」を送信する。例えば、警戒レベルが「5」であれば緊急安全確保、警戒レベルが「4」であれば避難指示、警戒レベルが「3」であれば高齢者等避難のそれぞれに対応した「避難情報」が地域の住民に送信される。
【0047】
その際、自治体サーバ10は、各住民に適した(各住民に最適化された、パーソナライズされた)避難情報を生成し、当該避難情報を各住民が所持する端末30に送信する。
【0048】
避難情報生成の際、自治体サーバ10は、かかりつけ病院が設定されている住民については、当該住民の健康情報をデータ共有によってかかりつけ病院から取得する。具体的には、自治体サーバ10は、住民情報データベースを参照し、避難情報の送信対象となっている住民にかかりつけ病院が設定されているか否か判定する。自治体サーバ10は、かかりつけ病院が設定されていれば、当該病院の病院サーバ20に対して「データ共有要請」を送信する(ステップS2)。
【0049】
具体的には、自治体サーバ10は、住民情報データベースを参照し、かかりつけ病院が設定された住民の患者IDを読み出す。自治体サーバ10は、当該読み出した患者IDを含む「データ共有要請」を病院サーバ20に送信する。
【0050】
データ共有要請には、患者IDに加え、共有データの「利用目的」、共有データの「種類」、共有データの「共有先」が含まれる。例えば、共有データの利用目的として「避難指示発令に伴う避難所案内」、共有データの種類として「現症」、共有データの共有先として「防災センター」がそれぞれ設定される。
【0051】
病院サーバ20は、自治体サーバ10から受信したデータ共有要請を検証する。
【0052】
データ共有要請を受信した病院サーバ20は、当該要請に含まれる患者IDをキーとして患者情報データベースを検索し、対応するカルテID(電子カルテのID)と共有許諾情報を特定する。
【0053】
病院サーバ20は、受信したデータ共有要請に含まれる「利用目的」が上記特定された共有許諾情報に含まれる「目的」及び「条件」に合致するか否か、共有データの共有先が共有許諾情報の「共有先」と一致するか否かを検証する。
【0054】
病院サーバ20は、これらの検証に成功すると、自治体サーバ10との間のデータ共有が可能と判定する。この場合、病院サーバ20は、該当する患者の電子カルテから共有許諾情報に設定されたデータ種類に対応したデータを読み出す。例えば、「現症」に関するデータ共有が承諾されている場合には、「胃がん」、「肺がん」といった具体的な病名が電子カルテから読み出される。
【0055】
病院サーバ20は、データ共有の対象となった患者(住民)の患者ID及び読み出したデータ(共有データ)を含む「健康情報通知」を自治体サーバ10に送信する(ステップS3)。
【0056】
自治体サーバ10は、病院サーバ20から取得した健康情報を参照し、住民(かかりつけ病院が設定された住民)に適した避難情報を生成する。
【0057】
例えば、自治体サーバ10は、住民Aにはかかりつけ病院が設定されておらず、住民Aは健康に不安のない住民であると判断した場合には、当該住民Aの避難先として避難所Bを案内するような避難情報を生成する。避難所Bは、特別な装置や人員が配置されていない通常の避難所である。
【0058】
あるいは、自治体サーバ10は、住民Bにはかかりつけ病院が設定され、住民Bは健康に不安のある住民であると判断した場合には、当該住民Bの避難先として避難所Aを案内するような避難情報を生成する。避難所Aは、医師や看護師が常駐し、医療設備が充実した避難所である。
【0059】
自治体サーバ10は、生成した避難情報を各住民が所持する端末30に送信する(ステップS4)。
【0060】
各住民は、端末30に表示された避難情報を確認し、当該避難情報に記載された避難所に避難する。
【0061】
続いて、第1の実施形態に係る防災システムに含まれる各装置の詳細について説明する。
【0062】
[自治体サーバ]
図7は、第1の実施形態に係る自治体サーバ10の処理構成(処理モジュール)の一例を示す図である。
図7を参照すると、自治体サーバ10は、通信制御部201と、住民登録部202と、避難情報制御部203と、記憶部204と、を備える。
【0063】
通信制御部201は、他の装置との間の通信を制御する手段である。例えば、通信制御部201は、病院サーバ20からデータ(パケット)を受信する。また、通信制御部201は、病院サーバ20に向けてデータを送信する。通信制御部201は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部201は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部201を介して他の装置とデータの送受信を行う。通信制御部201は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0064】
住民登録部202は、上述の住民登録を実現する手段である。住民登録部202は、将来的に避難者となり得る複数の住民それぞれの住民情報を取得する手段である。より具体的には、住民登録部202は、病院情報を含む住民情報を任意の手段により取得する。
【0065】
例えば、住民登録部202は、住民が操作する端末30から住民情報を取得してもよい。あるいは、住民は、住民情報が記載された書類や住民情報が記憶された外部記憶装置を防災センターに送付し、当該センターの職員等が住民情報を自治体サーバ10に入力してもよい。
【0066】
住民登録部202は、住民情報を入力するためのGUIや入力フォームを住民に提供してもよい。例えば、住民登録部202は、
図8に示すようなGUIを住民の端末30に表示してもよい。
【0067】
住民は、端末30を操作して、
図8に示される情報を入力する。住民は、情報入力を完了すると「決定」ボタンを押下し、個人情報(氏名、連絡先等)や病院情報を自治体サーバ10に入力する。
【0068】
また、住民登録部202は、住民を識別するための住民IDを生成する。住民IDは、住民登録された住民を一意に識別できる情報であればどのような情報であってもよい。例えば、住民登録部202は、住民登録のたびに一意な値を採番し住民IDとしてもよい。あるいは、住民登録部202は、住民IDに相当する情報(例えば、公的機関が発行する識別情報)を住民から取得してもよい。
【0069】
住民登録部202は、上記生成された住民ID、個人情報、病院情報を対応付けて住民情報データベースに記憶する(
図9参照)。なお、
図9に示す住民情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、住民の生体情報(例えば、顔画像や当該顔画像から生成された特徴量)が住民情報データベースに登録されていてもよい。あるいは、かかりつけ病院の電話番号等の連絡先が住民情報データベースに登録されていてもよい。なお、患者IDは、かかりつけの病院から発行された識別情報である。例えば、診察券等に記載されているIDが患者IDに相当する。
【0070】
避難情報制御部203は、避難情報に関する制御を行う手段である。避難情報制御部203は、
図10に示すように、送信指示取得部211と、対象住民選択部212と、共有データ取得部213と、避難情報生成部214と、からなるサブモジュールを備える。
【0071】
図11を参照し、避難情報制御部203の動作を説明する。
図11は、第1の実施形態に係る避難情報制御部203の動作の一例を示すフローチャートである。
【0072】
送信指示取得部211は、自治体の防災担当者から「避難情報送信指示」を取得する(ステップS101)。具体的には、送信指示取得部211は、防災担当者の使用する防災担当者端末(
図6等に図示せず)に避難情報送信指示を入力するためのGUI、入力フォーム等を表示する。
【0073】
例えば、送信指示取得部211は、
図12に示すようなGUIを防災担当者端末に表示する。防災担当者は、警戒レベルと、避難情報を発令する地域と、を選択する。
【0074】
対象住民選択部212は、避難情報の送信対象となる住民を選択する(ステップS102)。対象住民選択部212は、住民情報データベースを参照し、防災担当者が入力した地域(避難情報を発令する地域)の住民を選択する。対象住民選択部212は、住民情報データベースの住所フィールドを参照し、避難情報発令地域に居住している住民(エントリ)を抽出する。当該抽出された住民が、避難情報の送信対象となる住民である。
【0075】
共有データ取得部213は、住民のかかりつけ病院から当該住民の健康情報を取得する手段である。共有データ取得部213は、データ共有によって病院サーバ20から健康情報を取得する。共有データ取得部213は、かかりつけ病院の病院サーバ20に対して健康情報に関するデータ共有要請を送信することで、健康情報を取得する。
【0076】
共有データ取得部213は、上記避難情報の送信対象として抽出された各住民の病院情報を確認し、かかりつけ病院が設定されているか否か判定する(ステップS103)。
【0077】
かかりつけ病院が設定されていなければ(ステップS103、No分岐)、共有データ取得部213は、特段の動作を行わない。この場合、ステップS106以降の処理が実行される。
【0078】
かかりつけ病院が設定されていれば(ステップS103、Yes分岐)、共有データ取得部213は、データ共有要請を生成し、当該生成されたデータ共有要請を病院サーバ20に送信する(ステップS104)。
【0079】
具体的には、共有データ取得部213は、病院情報を参照し、かかりつけ病院の病院名及び患者IDを取得する。
【0080】
共有データ取得部213は、病院名からデータ共有要請の送信先となる病院サーバ20を特定する。共有データ取得部213は、病院名と病院サーバ20のIP(Internet Protocol)アドレス等を対応付けて記憶するテーブル情報を参照することで、データ共有要請の送信先を取得する。
【0081】
共有データ取得部213は、上記患者IDと、取得する共有データに関する情報(利用目的、データ種類、データ共有先)と、を含むデータ共有要請を生成し、病院サーバ20に送信する。
【0082】
共有データの利用目的として「避難指示発令に伴う避難所案内」といった内容が設定される。なお、上記設定される内容のうち「避難指示発令」は防災担当者が入力した警戒レベルによって変化する。
【0083】
また、共有データの種類として「現症」、共有データの共有先として「防災センター」といった内容がそれぞれ設定される。なお、どのような種類のデータを共有するか(病院から取得するか)は、防災センターのポリシに基づく。例えば、「現症」を取得するポリシ、「既往症」及び「現症」を取得するポリシ、「既往症」、「現症」及び「服薬情報」を取得するポリシが予め自治体サーバ10に設定される。
【0084】
共有によって取得しようするとするデータ種類を多くすれば、住民から拒絶されている可能性が高いが、自治体サーバ10はより正確な避難情報を作成できる。対して、共有によって取得しようとするデータ種類が少なければ、住民の許諾を得られている可能性が高いが、自治体サーバ10はより正確な避難情報の作成が難しい。防災担当者等は、これらのメリット、デメリットを考慮して共有によって取得するデータ種類を決定する(ポリシを決定する)。
【0085】
共有データ取得部213は、データ共有要請に対する応答を受信する(ステップS105)。データ共有が許諾されていなければ、共有データ取得部213は、否定応答を受信する。この場合、共有データ取得部213は、特段の動作を行わない。共有データ取得部213は、共有データの取得できなかった住民はかかりつけ病院の設定されていない住民と扱えばよい。
【0086】
データ共有が許諾されていれば、共有データ取得部213は、肯定応答を受信する。即ち、共有データ取得部213は、病院サーバ20から「健康情報通知」を受信する。健康情報通知には、患者IDと、健康情報と、が含まれる。
【0087】
なお、上述のように、健康情報は、データ共有要請に設定したデータ種類に対応する具体的なデータ(情報)である。上記の例のように、「現症」のデータ共有を要請した場合には、「胃がん」、「肺がん」といった具体的な病名が健康情報として自治体サーバ10に通知される。
【0088】
避難情報生成部214は、避難情報を生成する手段である。避難情報生成部214は、各住民の健康情報に基づいて、当該住民に案内する避難所に関する情報を含む避難情報を生成する。
【0089】
避難情報生成部214は、避難情報の送信対象となっている住民に案内する避難先(避難所)を選択する(ステップS106)。その際、例えば、避難情報生成部214は、対象住民の健康状態と各避難所の特徴に基づいて、住民に案内する避難先を選択する。
【0090】
避難情報生成部214は、
図13に示すような避難所情報データベースを参照し、各避難所の特徴を読み出す。
図13に示すように、避難所情報データベースは、各避難所の避難所ID、名称、場所、特徴を対応付けて記憶する。また、
図13に示すように、特徴のない避難所もあれば、複数の特徴を持つ避難所も存在する。
【0091】
なお、
図13に示す避難所情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、各避難所の連絡先等が避難所情報データベースに登録されていてもよい。あるいは、各避難所の収容可能人数(キャパシティ)が避難所情報データベースに登録されていてもよい。
【0092】
避難情報生成部214は、住民の健康情報と各避難所の特徴を参照し、当該住民の健康状態に適合する避難所を選択する。
【0093】
例えば、避難情報生成部214は、健康状態に不安のない住民(かかりつけ病院が設定されていない住民;健康情報を考慮する必要のない住民)に関しては、特段の特徴を備えていない避難所を選択する。この場合、例えば、避難情報生成部214は、
図13に示す避難所Bを選択する。このように、避難情報生成部214は、健康状態に不安のない住民に関しては、医師や看護師が常駐していない通常の避難所Bを積極的に選択することができる。
【0094】
健康情報を考慮する必要のある住民(かかりつけ病院が設定された住民)に関しては、避難情報生成部214は、当該住民の健康情報(上記の例では、現症)と避難所の特徴に基づいて避難所を選択する。例えば、現症が医師等の元で観察が必要な病気であれば、避難情報生成部214は、医師や看護師が常駐している避難所を選択する。この場合、避難情報生成部214は、
図13に示す避難所Aや避難所Cを選択する。
【0095】
避難情報生成部214は、現症の内容によっては通常の避難所(例えば、避難所B)を選択することもある。例えば、「指の骨折」のような現症であれば、当該住民に対して特段の配慮は必要ないと想定されるので、通常の避難所Bが選択される。あるいは、避難情報生成部214は、かかりつけ病院が設定されているが、健康情報に基づけば明らかに健康に問題がないと判断される住民に関しては、通常の避難所Bを選択してもよい。
【0096】
住民の健康状態と避難所の選択は、予め定められたテーブル情報等に基づいて行われてもよいし、自治体サーバ10に実装された学習モデルを用いて行われてもよい。例えば、現症を入力すると、当該現症に適合した避難所の特徴を出力するような学習モデルが自治体サーバ10に実装されていてもよい。
【0097】
このように、避難情報生成部214は、健康情報に基づいて健康に不安があると判定される住民に関しては、医師又は看護師が常駐する避難所、又は、医療設備を備える避難所を選択する。
【0098】
避難情報生成部214は、データ共有によって「服薬情報」を取得した場合には、当該服薬情報と避難所の特徴に基づいて、避難所を選択してもよい。例えば、避難情報生成部214は、住民が服薬している薬を常備している避難所を選択してもよい。例えば、
図13の例では、薬Aを服薬している住民に関しては、避難所Cが選択される。
【0099】
避難情報生成部214は、防災担当者が入力した警戒レベルと、上記選択された避難所と、に基づいて避難情報を生成する(ステップS107)。例えば、健康状態に不安のない住民(健康情報を考慮する必要の無い住民)に関しては、
図14に示すような避難情報が生成される。対して、健康情報を考慮する必要のある住民に関しては、
図15に示すような避難情報が生成される。
【0100】
避難情報制御部203は、生成された避難情報を住民の所持する端末30に送信する(ステップS108)。避難情報制御部203は、住民情報データベースに記載された各住民の連絡先(例えば、端末30が受信可能なメールアドレス等)に避難情報を送信する。
【0101】
避難情報制御部203は、避難情報の送信対象となっている住民が残っていれば(ステップS109、Yes分岐)、ステップS102に戻り処理を継続する。避難情報制御部203は、避難情報の送信対象となっている住民が残っていなければ(ステップS109、No分岐)、処理を終了する。
【0102】
記憶部204は、自治体サーバ10の動作に必要な情報を記憶する手段である。記憶部204には、住民情報データベース、避難所情報データベース等が構築される。
【0103】
[病院サーバ]
図16は、第1の実施形態に係る病院サーバ20の処理構成(処理モジュール)の一例を示す図である。
図16を参照すると、病院サーバ20は、通信制御部301と、許諾情報取得部302と、共有制御部303と、記憶部304と、を備える。
【0104】
通信制御部301は、他の装置との間の通信を制御する手段である。例えば、通信制御部301は、自治体サーバ10からデータ(パケット)を受信する。また、通信制御部301は、自治体サーバ10に向けてデータを送信する。通信制御部301は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部301は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部301を介して他の装置とデータの送受信を行う。通信制御部301は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0105】
許諾情報取得部302は、共有許諾情報を取得する手段である。かかりつけ病院にデータ共有のための設定を希望する利用者は、当該病院が管理、運営するホームページにアクセスし、患者情報等を管理するためのアカウントにログインする。その際、利用者は、自身に割り当てられた患者IDをホームページに入力する。許諾情報取得部302は、当該患者IDを取得し、データ共有許諾の設定を希望する利用者(患者)を特定する。
【0106】
利用者がデータ共有許諾の設定をするためのページにアクセスすると、許諾情報取得部302は、利用者の所持する端末30に
図5に示すようなGUIを表示する。許諾情報取得部302は、端末30からデータ共有の目的、データ種類、データ共有先、データ共有時の条件を取得する。
【0107】
許諾情報取得部302は、取得した共有許諾情報(目的、データ種類、データ共有先、条件)を患者情報データベースに記憶する。許諾情報取得部302は、患者ID、カルテID、共有許諾情報を対応付けて患者情報データベースに記憶する(
図17参照)。
【0108】
なお、
図17に示す患者情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、患者の生体情報(例えば、顔画像や当該顔画像から生成された特徴量)が患者情報データベースに登録されていてもよい。
【0109】
また、患者IDやカルテIDは、患者の初診時に生成され、これらのIDが生成されると患者情報データベースに追加される。患者IDの生成やカルテIDを含む電子カルテの生成、管理は当業者にとって明らかであり、本願開示の趣旨とも異なるので詳細な説明を省略する。
【0110】
共有制御部303は、データ共有を制御する手段である。
図18を参照し、共有制御部303の動作を説明する。
図18は、第1の実施形態に係る共有制御部303の動作の一例を示すフローチャートである。
【0111】
共有制御部303は、外部装置(自治体サーバ10)からデータ共有要請を受信する(ステップS201)。
【0112】
共有制御部303は、当該取得したデータ共有要請を検証する。共有制御部303は、2つの検証(2段階の検証)を行う。
【0113】
はじめに、共有制御部303は、データ共有要請に含まれる患者IDをキーとして患者情報データベースを検索し、対応する共有許諾情報を特定する(ステップS202)。
【0114】
共有制御部303は、データ共有要請に含まれる「利用目的」が上記特定された共有許諾情報に含まれる「目的」及び「条件」に合致するか否を検証する(第1の検証;ステップS203)。
【0115】
例えば、患者によって許諾された目的が「避難所案内」、データ共有の条件が「避難指示以上発令時」であって、共有データの利用目的が「避難指示発令に伴う避難所案内」であれば、共有制御部303は、データ共有のための第1の検証に成功したと判定する。
【0116】
対して、患者によって許諾された目的が「避難所案内」、条件が「避難指示以上発令時」であって、共有データの利用目的が「ダイエット情報の提供」であれば、共有制御部303は、データ共有のための第1の検証に失敗したと判定する。
【0117】
第1の検証に失敗すれば(ステップS204、No分岐)、共有制御部303は、データ共有不可に設定する(ステップS205)。
【0118】
第1の検証に成功すれば(ステップS204、Yes分岐)、共有制御部303は、第2の検証を実行する(ステップS206)。具体的には、共有制御部303は、データ共有要請に含まれる共有先が共有許諾情報の「共有先」と一致するか否かを検証する。
【0119】
例えば、患者は防災センターに対してデータ共有を許諾した場合であって、データ共有要請に含まれる共有先も防災センターであれば、共有制御部303は、データ共有のための第2の検証に成功したと判定する。
【0120】
対して、患者は防災センターに対してデータ共有を許諾したにも関わらず、データ共有要請に含まれる共有先が「スポーツジム」であれば、共有制御部303は、データ共有のための第2の検証に失敗したと判定する。
【0121】
第2の検証に失敗すれば(ステップS207、No分岐)、共有制御部303は、データ共有不可に設定する(ステップS205)。
【0122】
第2の検証に成功すれば(ステップS207、Yes分岐)、共有制御部303は、データ共有可に設定する(ステップS208)。
【0123】
共有制御部303は、データ共有要請に対する応答を送信する(ステップS209)。
【0124】
データ共有不可の場合には、共有制御部303は、その旨を示す否定応答を自治体サーバ10に送信する。
【0125】
データ共有可の場合には、共有制御部303は、データ共有要請に含まれる患者IDに対応するカルテIDを患者情報データベースから読み出す。
【0126】
共有制御部303は、カルテIDを用いて、データ共有の対象者の電子カルテを特定する。共有制御部303は、当該特定された電子カルテの記載項目のうち、共有許諾情報において「許諾」と設定されている項目(患者情報データベースのデータ種類フィールドの項目)を読み出す。
【0127】
例えば、
図17の1行目に示すように、データ共有が許諾されたデータ種類が「現症」であれば、共有制御部303は、電子カルテから「現症」とラベル付けされたデータを読み出す。例えば、「胃がん」、「肺がん」といった具体的な病名が読み出される。
【0128】
共有制御部303は、データ共有が許諾されたデータを読み出すと、当該読み出したデータとデータ共有の対象者(患者)の患者IDを含む健康情報通知を生成し、当該情報をデータ共有要請の送信元(共有先;自治体サーバ10)に送信する。健康情報通知は、データ共有要請に対する肯定応答として扱われる。
【0129】
記憶部304は、病院サーバ20の動作に必要な情報を記憶する手段である。記憶部304には、患者情報データベース、電子カルテを構成するデータベース等が構築される。病院サーバ20は、患者の電子カルテに記載されたデータのうち少なくとも一部が自治体サーバ10とデータ共有されることに関する共有許諾情報を記憶部304に記憶する。
【0130】
[端末]
端末30には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置やコンピュータ(パーソナルコンピュータ、ノートパソコン)等が例示される。端末30は、住民の操作を受け付け、自治体サーバ10等と通信可能であれば任意の機器、デバイスとすることができる。また、端末30の構成等は当業者にとって明らかであるので、詳細な説明を省略する。
【0131】
[システムの動作]
続いて、第1の実施形態に係る防災システムの動作について説明する。なお、住民登録やデータ共有許諾に関する動作の説明は省略する。
図19は、第1の実施形態に係る防災システムの動作の一例を示すシーケンス図である。
【0132】
自治体サーバ10は、防災担当者から避難情報送信指示を取得する(ステップS01)。
【0133】
自治体サーバ10は、避難情報の送信対象となる住民を選択する(ステップS02)。
【0134】
当該選択された住民が健康状態を考慮する必要のある住民の場合(かかりつけ病院が設定された住民の場合)、自治体サーバ10は、かかりつけ病院の病院サーバ20に対してデータ共有要請を送信する(ステップS03)。
【0135】
データ共有要請を受信した病院サーバ20は、当該要請の検証を行う(ステップS04)。病院サーバ20は、データ共有要請の利用目的や共有先を検証する。
【0136】
検証に成功すると、病院サーバ20は、患者の電子カルテから当該患者がデータ共有を許諾したデータ種類に対応した具体的なデータを読み出す。病院サーバ20は、当該読み出したデータを含む健康情報通知を自治体サーバ10に送信する(ステップS05)。
【0137】
このように、病院サーバ20は、共有許諾情報を用いてデータ共有要請を検証し、データ共有要請の検証に成功した場合に、患者が許諾したデータの種類に対応するデータを電子カルテから読み出す。病院サーバ20は、当該読み出したデータを健康情報として自治体サーバ10に通知する。
【0138】
健康情報通知を受信すると、自治体サーバ10は、住民の健康状態(健康情報)に基づいて、当該住民に案内する避難所を選択する(ステップS06)。
【0139】
自治体サーバ10は、選択した避難所の情報(避難所の名称や場所)を含む避難情報を生成し、住民が所持する端末30に送信する(ステップS07)。
【0140】
端末30は、受信した避難情報を出力する(ステップS08)。例えば、端末30は、避難情報をモニターに表示する、避難情報をスピーカーから読み上げるといった対応を行う。
【0141】
以上のように、第1の実施形態に係る防災システムにおいて、自治体サーバ10は、複数の住民うち防災担当者により指定された地域に住む住民を選択し、当該選択された住民が所持する端末30に対して避難情報を送信する。その際、自治体サーバ10は、選択された住民の健康情報をデータ共有により病院サーバ20から取得する。自治体サーバ10は、取得した健康情報に基づいて、住民に案内する避難所を選択する。その結果、健康に不安のある住民に対しては、医師が常駐していたり医療設備が充実していたりする避難所が選択される。対して、健康に不安のない住民に対しては、通常の避難所が選択される。このような自治体サーバ10の働きによって、健常者が医療設備等の充実した避難所に避難することがなくなり、健康に不安のある住民がより確実に上記避難所に避難することができる。
【0142】
また、住民が病院に対してデータ共有可能なデータ種類を設定することで、住民が外部に知られたくない情報を適切に保護できる。即ち、電子カルテの情報をそのまま防災センター(自治体;自治体サーバ10)に提供するのではなく、データの共有に条件、範囲の制限を設けることで住民のプライバシーが適切に保護される。
【0143】
[第2の実施形態]
続いて、第2の実施形態について図面を参照して詳細に説明する。
【0144】
第1の実施形態において、住民は、災害発生時に自治体(防災センター)に提供可能な共有データをかかりつけ病院に設定する場合について説明した。自治体は、病院から共有されたデータを用いて、各住民の健康状態に応じた避難所の案内をする。自治体は、健康情報(既往症、現症、服薬情報等)を用いて住民にパーソナライズされた避難先を決定する。即ち、第1の実施形態では、住民が避難所に避難する前のシステムについて、その構成及び動作について説明した。
【0145】
第2の実施形態では、避難後のデータ活用について説明する。具体的には、自治体サーバ10は、避難所に到着した住民を生体認証によって特定する。自治体サーバ10は、特定した住民に関する情報をかかりつけ病院(病院サーバ20)に提供する。
【0146】
以下、第1の実施形態と第2の実施形態の相違点を中心に説明する。
【0147】
第2の実施形態では、住民は、自身の生体情報(例えば、顔画像)を自治体サーバ10に入力する。自治体サーバ10の住民登録部202は、顔画像から特徴量を生成し、当該特徴量(生体情報)を住民ID等と対応付けて住民情報データベースに記憶する(
図20参照)。
【0148】
図21は、第2の実施形態に係る防災システムの概略構成の一例を示す図である。
図21に示すように、各避難所は、避難者の受付を担う受付端末40を備える。なお、各避難所に設置される受付端末40の構成、動作は同一とすることができるので、以降の説明では、避難所Aに設置された受付端末40の構成等を中心に説明する。
【0149】
避難情報を取得すると、住民は、避難所に避難する。避難者は、避難所に設置された受付端末40の面前に移動する。
【0150】
受付端末40は、避難者を撮影し、顔画像を取得する。受付端末40は、取得した顔画像と各避難所に割り当てられた避難所IDを含む「避難者来所通知」を自治体サーバ10に送信する。
【0151】
自治体サーバ10は、取得した顔画像を用いた照合処理を行い、避難所に到着した住民を特定する。自治体サーバ10は、住民の避難先を住民情報データベースに反映する(
図20の避難所フィールド参照)。
【0152】
図20の例では、かかりつけ病院が設定されている住民(ID31の住民)は避難所Aに避難し、同じくかかりつけ病院が設定されている住民(ID32の住民)は避難所Bに避難していることが住民情報データベースに登録されている。なお、ID32の住民は、本来、避難所Aへの避難が案内されたはずであるが、何らかの事情により避難所Bに避難したと想定される。避難所Bは、医師や看護師が常駐していない通常の避難所である。
【0153】
自治体サーバ10は、定期的又は所定のタイミングで住民情報データベースにアクセスする。自治体サーバ10は、かかりつけ病院が設定され、かつ、避難所に避難している住民を抽出する。
図20の例では、ID31、ID32の住民がそれぞれ抽出される。
【0154】
自治体サーバ10は、当該抽出された住民のかかりつけ病院に対して、「患者避難先情報」を送信する。患者避難先情報は、住民(かかりつけ病院の患者)の避難先の情報と患者IDを含む。
図20の例では、病院Aに対してpID31の患者が避難所Aに避難していることを示す患者避難先情報、病院Bに対してpID41の患者が避難所Bに避難していることを示す患者避難先情報がそれぞれ送信される。
【0155】
患者避難先情報を受信した病院サーバ20は、患者の避難先を医師、看護師等に通知する。医師等は、自院の患者の避難先を把握できると共に、その避難先が妥当か否かを判断できる。例えば、病院Bの患者は医師等が常駐していない通常の避難所に避難しているが、当該避難先が妥当か否か病院Bの医師等によって判断される。
【0156】
第2の実施形態に係る各装置の処理構成について説明する。
【0157】
[受付端末]
図22は、受付端末40の処理構成(処理モジュール)の一例を示す図である。
図22を参照すると、受付端末40は、通信制御部401と、生体情報取得部402と、避難者来所通知部403と、記憶部404と、を備える。
【0158】
通信制御部401は、他の装置との間の通信を制御する手段である。具体的には、通信制御部401は、自治体サーバ10からデータ(パケット)を受信する。また、通信制御部401は、自治体サーバ10に向けてデータを送信する。通信制御部401は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部401は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部401を介して他の装置とデータの送受信を行う。通信制御部401は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0159】
生体情報取得部402は、カメラ装置(受付端末40が備えるカメラ装置)を制御し、面前の避難者の生体情報(例えば、顔画像)を取得する手段である。生体情報取得部402は、定期的又は所定のタイミングにおいて自装置の前方を撮像する。生体情報取得部402は、取得した画像に人の顔画像が含まれるか否かを判定し、顔画像が含まれる場合には取得した画像データから顔画像を抽出する。
【0160】
なお、生体情報取得部402による顔画像の検出処理や顔画像の抽出処理には既存の技術を用いることができるので詳細な説明を省略する。例えば、生体情報取得部402は、CNN(Convolutional Neural Network)により学習された学習モデルを用いて、画像データの中から顔画像(顔領域)を抽出してもよい。あるいは、生体情報取得部402は、テンプレートマッチング等の手法を用いて顔画像を抽出してもよい。
【0161】
生体情報取得部402は、抽出した顔画像を避難者来所通知部403に引き渡す。
【0162】
避難者来所通知部403は、自治体サーバ10に対して避難者の来所を通知する手段である。避難者来所通知部403は、取得した顔画像と避難所IDを含む「避難者来所通知」を生成し、自治体サーバ10に送信する。
【0163】
避難所IDは任意の手段により受付端末40と自治体サーバ10の間で共有される。例えば、システム管理者(防災センターの職員)が、各避難所に避難所IDを割り当て、当該割り当てた避難所IDを受付端末40に設定すればよい。
【0164】
記憶部404は、受付端末40の動作に必要な情報を記憶する手段である。
【0165】
[自治体サーバ]
図23は、第2の実施形態に係る自治体サーバ10の処理構成(処理モジュール)の一例を示す図である。
図23を参照すると、第1の実施形態に係る自治体サーバ10の構成に住民避難先管理部205と患者避難先通知部206が追加されている。
【0166】
住民避難先管理部205は、避難所に避難した住民を管理する手段である。住民避難先管理部205は、避難所に設置された受付端末40から避難者来所通知を受信する。当該通知には、避難者の生体情報(顔画像)が含まれるので、住民避難先管理部205は当該顔画像を避難者来所通知から取り出す。住民避難先管理部205は、取得した顔画像から特徴量を生成する。
【0167】
特徴量の生成処理に関しては既存の技術を用いることができるので、その詳細な説明を省略する。例えば、住民避難先管理部205は、顔画像から目、鼻、口等を特徴点として抽出する。その後、住民避難先管理部205は、特徴点それぞれの位置や各特徴点間の距離を特徴量として計算し、複数の特徴量からなる特徴ベクトル(顔画像を特徴づけるベクトル情報)を生成する。
【0168】
住民避難先管理部205は、受付端末40から取得した顔画像に基づき算出された特徴量を照合対象に設定し、住民情報データベースに登録された特徴量との間で照合処理を行う。より具体的には、住民避難先管理部205は、上記算出した特徴量(特徴ベクトル)を照合対象に設定し、住民情報データベースに登録されている複数の特徴量との間で1対N(Nは正の整数、以下同じ)照合を実行する。
【0169】
住民避難先管理部205は、照合対象の特徴量と登録側の複数の特徴量それぞれとの間の類似度を計算する。当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。なお、距離が離れているほど類似度は低く、距離が近いほど類似度が高い。
【0170】
住民避難先管理部205は、上記類似度が所定値以上であって、住民情報データベースに登録された特徴量のうち照合対象の特徴量に最も近い特徴量(類似度が最も高い特徴量)を特定する。住民避難先管理部205は、当該特定された特徴量に対応するエントリの避難所フィールドに避難所から通知された避難所ID(避難所の名称)を設定する。
【0171】
住民避難先管理部205は、類似度が所定値以上の特徴量を持つエントリが住民情報データベースに登録されていなければ、避難所から通知された顔画像に対応する住民の住民登録はされていないと判定する。この場合、住民避難先管理部205は、特段の動作を行わなくてもよいし、住民登録をしていない利用者数を集計する等の統計処理を行ってもよい。
【0172】
患者避難先通知部206は、かかりつけ病院が設定されている患者の避難先を病院に通知する手段である。患者避難先通知部206は、定期的又は所定のタイミングで住民情報データベースにアクセスする。患者避難先通知部206は、かかりつけ病院が設定され、かつ、避難所に避難している住民を抽出する。
【0173】
患者避難先通知部206は、当該抽出された住民のかかりつけ病院に対して、患者の避難先に関する情報(避難所の名称、連絡先等)と患者IDを含む患者避難先情報を送信する。なお、同じ住民について何度も避難先を病院に通知する必要はない。
【0174】
[病院サーバ]
図24は、第2の実施形態に係る病院サーバ20の処理構成(処理モジュール)の一例を示す図である。
図24を参照すると、第1の実施形態に係る病院サーバ20の構成に患者情報提供部305が追加されている。
【0175】
患者情報提供部305は、自院の患者の避難先に関する情報を病院スタッフ(医師、看護師等)に提供する手段である。
【0176】
患者避難先情報を受信すると、患者情報提供部305は、当該患者避難先情報に基づき「患者情報」を生成する。例えば、患者情報提供部305は、患者避難先情報に含まれる患者IDから患者の氏名や電子カルテを特定する。患者情報提供部305は、患者の避難先に関する情報(避難所の名称、連絡先)、当該患者の氏名や電子カルテに記載された情報を含む患者情報を生成する。
【0177】
患者情報提供部305は、生成した患者情報を病院サーバ20に接続された液晶モニター等に表示する。あるいは、患者情報提供部305は、生成された患者情報を医師や看護師等が使用する医師端末、看護師端末に送信してもよい。
【0178】
[システムの動作]
続いて、第2の実施形態に係る防災システムの動作について説明する。
図25は、第2の実施形態に係る防災システムの動作の一例を示すシーケンス図である。
【0179】
受付端末40は、避難者を検出すると、当該避難者の生体情報(顔画像)を取得する。受付端末40は、取得した顔画像を含む避難者来所通知を自治体サーバ10に送信する(ステップS11)。
【0180】
避難者来所通知を受信した自治体サーバ10は、避難者の生体情報を用いた照合処理により避難者を特定する(ステップS12)。自治体サーバ10は、特定した避難者の避難先を住民情報データベースに登録する。
【0181】
避難者にかかりつけ病院が設定されていれば、自治体サーバ10は、患者避難先情報を生成し、かかりつけ病院の病院サーバ20に送信する(ステップS13)。
【0182】
病院サーバ20は、患者避難先情報に基づき、避難所に避難している患者に関する患者情報(避難所に関する情報、患者の電子カルテを含む情報)を生成する(ステップS14)。
【0183】
病院サーバ20は、生成した患者情報を病院の医師、看護師等に提供する(ステップS15)。
【0184】
以上のように、第2の実施形態に係る、各避難所に設置された受付端末40は、来所した避難者の生体情報を含む避難者来所通知を自治体サーバ10に送信する。自治体サーバ10は、避難者来所通知に含まれる生体情報を用いた照合処理により来所した避難者を特定する。自治体サーバ10は、特定された住民のかかりつけ病院の病院サーバ20に、来所した避難者の避難先を含む患者避難先情報を送信する。かかりつけ病院の医師等は、自院の患者が避難している場所を知ることができ、当該避難先の検討、検証を行うことができる。例えば、患者の避難先が不適当と判断すれば、かかりつけ病院の医師等は、避難所に連絡し、当該患者を自院に招く等の対応が可能となる。
【0185】
[第3の実施形態]
続いて、第3の実施形態について図面を参照して詳細に説明する。
【0186】
第3の実施形態においても、第2の実施形態と同様に、避難後のデータ活用について説明する。具体的には、避難所で医師が患者(避難者)を診断する際、必要な情報を病院から取得する場合について説明する。
【0187】
以下、第1乃至第3の実施形態の相違点を中心に説明する。
【0188】
図26に示すように、第3の実施形態に係る防災システムの全部又は一部の避難所は、医師等が使用する医療端末50を備える。医療端末50は、医師が視認可能な表示デバイスと、患者が視認可能な表示デバイスと、を備える。また、患者が視認可能な表示デバイスにはカメラが設置されており、患者の顔を撮影可能に構成されている。
【0189】
医師が常駐している避難所(上記の例では、避難所A)に避難した避難者は、定期的又は所定のタイミングで、医師の診断を受けることができる。
【0190】
医師は、医療端末50を用いて診断を行う。医師は、医療端末50を操作して、面前の避難者(患者)に関する電子カルテを確認する。その際、医療端末50は、面前の患者の生体情報(例えば、顔画像)を取得する。医療端末50は、取得した顔画像を含む認証要求を自治体サーバ10に送信する。
【0191】
自治体サーバ10は、認証要求に含まれる生体情報を用いた認証処理により患者を特定する。認証に成功すると、自治体サーバ10は、特定した患者の病院情報(かかりつけ病院の病院名と患者ID)を医療端末50に送信する。
【0192】
医療端末50は、病院名からかかりつけ病院を特定し、当該特定したかかりつけ病院の病院サーバ20に対して、患者IDを含む「電子カルテ提供要求」を送信する。
【0193】
病院サーバ20は、電子カルテ提供要求に含まれる患者IDをキーとして患者情報データベースを検索し、患者を特定する。病院サーバ20は、当該特定した患者のカルテIDに基づき電子カルテを特定し、その内容を読み出す。
【0194】
病院サーバ20は、読み出した電子カルテを含む応答(電子カルテ提供要求に対する応答)を医療端末50に送信する。
【0195】
医療端末50は、受信した電子カルテを表示する。医師は、電子カルテを確認しつつ、患者の診断を行う。
【0196】
第3の実施形態に係る各装置の処理構成について説明する。
【0197】
[医療端末]
図27は、医療端末50の処理構成(処理モジュール)の一例を示す図である。
図27を参照すると、医療端末50は、通信制御部501と、生体情報取得部502と、認証要求部503と、電子カルテ取得部504と、記憶部505と、を備える。
【0198】
通信制御部501は、他の装置との間の通信を制御する手段である。具体的には、通信制御部501は、自治体サーバ10からデータ(パケット)を受信する。また、通信制御部501は、自治体サーバ10に向けてデータを送信する。通信制御部501は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部501は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部501を介して他の装置とデータの送受信を行う。通信制御部501は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0199】
生体情報取得部502は、カメラ装置を制御し、面前の避難者の生体情報(例えば、顔画像)を取得する手段である。生体情報取得部502は、医師等の操作に応じて、面前の住民(患者)の顔画像を取得する。その際、生体情報取得部502は、患者の顔画像を取得すること及び顔画像の取得目的を表示しつつ、患者の同意を得るようなGUIを表示してもよい。例えば、生体情報取得部502は、
図28に示すようなGUIを表示してもよい。
【0200】
患者(避難者)の同意の下、患者の顔画像を取得すると、生体情報取得部502は、当該取得した顔画像を認証要求部503に引き渡す。
【0201】
認証要求部503は、自治体サーバ10に対して患者に関する認証を要求する手段である。認証要求部503は、取得した顔画像を含む認証要求を生成し、自治体サーバ10に向けて送信する。
【0202】
認証要求部503は、自治体サーバ10から認証結果(認証成功、認証失敗)を受信する。認証結果が認証失敗であれば、認証要求部503は、その旨を医師及び患者に通知する。その際、認証要求部503は、「防災センターに住民登録がされておらず電子カルテが取得できません。」といったメッセージ等を表示する。
【0203】
認証結果が認証成功であれば、認証要求部503は、認証結果(病院情報を含む肯定応答)を電子カルテ取得部504に引き渡す。
【0204】
電子カルテ取得部504は、病院情報に含まれる患者IDを取り出す。電子カルテ取得部504は、当該取り出した患者IDを含む電子カルテ提供要求を病院サーバ20(病院情報に含まれる病院の病院サーバ20)に送信する。
【0205】
電子カルテ取得部504は、病院サーバ20から電子カルテを取得すると、当該取得した電子カルテを医師が視認可能な表示デバイスに表示する。
【0206】
記憶部505は、医療端末50の動作に必要な情報を記憶する手段である。
【0207】
[自治体サーバ]
図29は、第3の実施形態に係る自治体サーバ10の処理構成(処理モジュール)の一例を示す図である。
図29を参照すると、第1の実施形態に係る自治体サーバ10に認証部207が追加されている。
【0208】
認証部207は、医療端末50から受信した認証要求を処理する手段である。認証部207は、認証要求から取り出した生体情報と住民情報データベースに予め記憶された複数の住民それぞれの生体情報を用いた生体認証を行う。
【0209】
認証部207は、認証要求に含まれる生体情報(顔画像)を取り出す。認証部207は、取り出した顔画像から特徴量を算出する。認証部207は、顔画像に基づき算出された特徴量を照合対象に設定し、住民情報データベースに登録された特徴量との間で照合処理を行う。認証部207は、照合対象の特徴量と登録側の複数の特徴量それぞれとの間の類似度を計算する。
【0210】
認証部207は、住民情報データベースに登録された複数の特徴量のうち、照合対象の特徴量との間の類似度が所定の値以上の特徴量が存在しなければ、被認証者の認証に失敗したと判定する。
【0211】
認証に失敗した場合には、認証部207は、その旨(認証失敗)を認証要求の送信元である医療端末50に通知する。認証部207は、認証失敗を示す否定応答を医療端末50に送信する。
【0212】
照合対象の特徴量との間の類似度が所定の値以上の特徴量が住民情報データベースに登録されていれば、認証部207は、照合対象の特徴量に最も近い特徴量(エントリ)を特定する。
【0213】
認証部207は、特定したエントリに病院情報が設定されていれば、認証に成功したと判定する。認証部207は、特定したエントリに病院情報が設定されていなければ、認証に失敗したと判定する。
【0214】
認証に成功した場合、認証部207は、特定されたエントリの病院情報(かかりつけ病院名、患者ID)を含む肯定応答を医療端末50に送信する。
【0215】
[病院サーバ]
図30は、第3の実施形態に係る病院サーバ20の処理構成(処理モジュール)の一例を示す図である。
図30を参照すると、第1の実施形態に係る病院サーバ20の構成に電子カルテ提供部306が追加されている。
【0216】
電子カルテ提供部306は、患者の電子カルテに記載された情報を避難所(医療端末50)に提供する手段である。
【0217】
電子カルテ提供要求を受信すると、電子カルテ提供部306は、当該電子カルテ提供要求に含まれる患者IDをキーとして患者情報データベースを検索し、対応するカルテIDを特定する。電子カルテ提供部306は、当該特定されたカルテIDに対応する電子カルテを取得する。
【0218】
電子カルテ提供部306は、取得した電子カルテを医療端末50に送信する。
【0219】
[システムの動作]
続いて、第3の実施形態に係る防災システムの動作について説明する。
図31は、第3の実施形態に係る防災システムの動作の一例を示すシーケンス図である。
【0220】
医師による診断の際、医療端末50は、避難者の同意の下、当該避難者の生体情報を取得する。医療端末50は、取得した生体情報を含む認証要求を自治体サーバ10に送信する(ステップS21)。
【0221】
認証要求を受信すると、自治体サーバ10は、当該認証要求の生体情報と住民情報データベースに登録された生体情報を用いた認証処理を実行する(ステップS22)。
【0222】
認証に成功すると、自治体サーバ10は、認証成功者(認証成功と判定された被認証者;医療端末50の前の避難者)の病院情報を医療端末50に送信する(ステップS23)。
【0223】
医療端末50は、病院情報から患者IDを取り出し、当該取り出した患者IDを含む電子カルテ提供要求を病院情報に記載された病院(病院サーバ20)に送信する(ステップS24)。
【0224】
病院サーバ20は、患者IDに対応する電子カルテを読み出し、医療端末50に送信する(ステップS25)。
【0225】
<第3の実施形態の変形例>
第3の実施形態では、医療端末50は、自治体サーバ10から病院情報を取得し、患者の電子カルテを病院サーバ20から取得することを説明した。しかし、医療端末50は、病院サーバ20から直接電子カルテを取得することもできる。
【0226】
この場合、住民は、自身の生体情報(例えば、顔画像)をかかりつけ病院の病院サーバ20に登録しておく。病院サーバ20は、顔画像から特徴量を生成し、当該特徴量(生体情報)を患者ID等と対応付けて患者情報データベースに記憶する。
【0227】
医師は、かかりつけ病院を患者(避難者)から聞き出し、医療端末50に入力する。医療端末50は、患者の生体情報(顔画像)を取得する。医療端末50は、当該生体情報を含む電子カルテ提供要求を上記入力された病院の病院サーバ20に送信する。
【0228】
病院サーバ20は、生体認証によって患者を特定し、対応する電子カルテを読み出す。病院サーバ20は、読み出した電子カルテを医療端末50に送信する。
【0229】
なお、この場合の病院サーバ20は、内部に「認証部」を備えていればよい。当該認証部の動作は、自治体サーバ10の認証部207の動作と同一とすることができるので、詳細な説明を省略する。
【0230】
なお、第3の実施形態においても第1の実施形態と同様に、電子カルテの情報が病院サーバ20と医療端末50の間でデータ共有されてもよい。即ち、患者は、医療端末50へのデータ共有に関する許諾を病院サーバ20に設定してもよい。例えば、データ共有の目的として「避難所での診察」、共有データの種類として「電子カルテ」、データ共有先として「医療端末(避難所)」、データ共有時の条件として「医師による診察」といった内容が設定されてもよい。この場合、医療端末50は、電子カルテに関するデータ共有要請を病院サーバ20に送信すればよい。
【0231】
以上のように、第3の実施形態に係る防災システムは医療端末50をさらに含む。医療端末50は、被認証者の生体情報を含む認証要求を自治体サーバ10に送信する。自治体サーバ10は、認証要求に含まれる生体情報を用いて被認証者を特定すると共に、特定された被認証者のかかりつけ病院に関する情報を医療端末50に送信する。医療端末50は、かかりつけ病院に対して、被認証者の電子カルテの提供を要求する。このように、避難所に医師は、患者(避難者)の電子カルテを参照することができ、より確実な診療、診断を行うことができる。
【0232】
また、第3の実施形態では、患者の生体情報を取得する際、電子カルテの情報を共有することに対する患者の同意を得ることができる。即ち、本願開示では、自治体等の団体と共有する情報と、医師間で共有する情報と、を適切に分離することで、利用者のプライバシー保護と利用者の利便性の両立を図っている。
【0233】
続いて、防災システムを構成する各装置のハードウェアについて説明する。
図32は、自治体サーバ10のハードウェア構成の一例を示す図である。
【0234】
自治体サーバ10は、情報処理装置(所謂、コンピュータ)により構成可能であり、
図32に例示する構成を備える。例えば、自治体サーバ10は、プロセッサ311、メモリ312、入出力インターフェイス313及び通信インターフェイス314等を備える。上記プロセッサ311等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。
【0235】
但し、
図32に示す構成は、自治体サーバ10のハードウェア構成を限定する趣旨ではない。自治体サーバ10は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス313を備えていなくともよい。また、自治体サーバ10に含まれるプロセッサ311等の数も
図32の例示に限定する趣旨ではなく、例えば、複数のプロセッサ311が自治体サーバ10に含まれていてもよい。
【0236】
プロセッサ311は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、DSP(Digital Signal Processor)等のプログラマブルなデバイスである。あるいは、プロセッサ311は、FPGA(Field Programmable Gate Array)、ASIC(Application Specific Integrated Circuit)等のデバイスであってもよい。プロセッサ311は、オペレーティングシステム(OS;Operating System)を含む各種プログラムを実行する。
【0237】
メモリ312は、RAM(Random Access Memory)、ROM(Read Only Memory)、HDD(Hard Disk Drive)、SSD(Solid State Drive)等である。メモリ312は、OSプログラム、アプリケーションプログラム、各種データを格納する。
【0238】
入出力インターフェイス313は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。
【0239】
通信インターフェイス314は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス314は、NIC(Network Interface Card)等を備える。
【0240】
自治体サーバ10の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ312に格納されたプログラムをプロセッサ311が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント(non-transitory)なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。
【0241】
なお、病院サーバ20、端末30、受付端末40、医療端末50も自治体サーバ10と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は自治体サーバ10と相違する点はないので説明を省略する。例えば、受付端末40、医療端末50は、被認証者を撮影するためのカメラ装置を備えていればよい。
【0242】
情報処理装置である自治体サーバ10は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで自治体サーバ10の機能が実現できる。また、自治体サーバ10は、当該プログラムにより自治体サーバ10の制御方法を実行する。
【0243】
[変形例]
なお、上記実施形態にて説明した防災システムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。
【0244】
上記実施形態では、医師による電子カルテのシステム入力について説明していないが、当該電子カルテのシステム入力は対面での診断時に行われてもよいし、オンライン診療時に行われてもよい。即ち、電子カルテは任意の方法によってシステムに入力されればよい。
【0245】
上記実施形態では、自治体サーバ10は、かかりつけ病院から各住民の健康情報を取得する場合について説明した。しかし、自治体サーバ10は、住民自身又は住民の家族から当該健康情報を取得してもよい。具体的には、住民は、住民登録の際に健康情報も併せてシステム(自治体サーバ10)に登録してもよい。即ち、本願開示の防災システムは、電子カルテに記載された健康情報を用いてもよいし、住民が自己申告した健康情報を用いてもよい。
【0246】
上記実施形態では、主に現症(現在の病気)に基づいて避難所を選択する場合について説明したが、既往症に基づいて避難所が選択されてもよいことは勿論である。あるいは、現症及び既往症に基づいて避難所が選択されてもよい。あるいは、病院サーバ20から「現症」と「既往症」が取得できた場合(データ共有できた場合)、いずれの情報を優先して避難所を決定するか予め決められていてもよい。
【0247】
自治体サーバ10は、避難情報を生成する際、
図14、
図15に示すような避難情報だけでなく、住民の住宅から避難所までの経路を含むような避難情報を生成してもよい(
図33参照)。自治体サーバ10は、住民の自宅を始点、選択された避難所を終点に設定し、経路を計算して避難情報に含めてもよい。あるいは、
図33に示すように、自治体サーバ10は、提案した避難所の種類、特徴等を含む避難情報を生成してもよい。
【0248】
自治体サーバ10は、住民情報データベースを参照し、防災担当者にとって有益な情報を提供してもよい。例えば、自治体サーバ10は、各住民の服薬情報と避難先の情報から避難所ごとに必要とされる薬の総量を計算する。自治体サーバ10は、計算した総量を防災担当者に提示する。あるいは、自治体サーバ10は、製薬会社等に計算した薬の配送等を依頼してもよい。このように、自治体サーバ10は、避難所ごとに避難者の属性が把握できるので、薬の配送を先回りして準備する等の対応が行える。
【0249】
自治体サーバ10は、避難情報の送信対象が「避難行動要支援者」である場合には、当該要支援者の支援者に対しても避難情報を送信してもよい。即ち、要支援者と支援者で避難情報(避難先)が共有されてもよい。
【0250】
複数のかかりつけ病院を持つ住民は、当該複数のかかりつけ病院に関する病院情報を自治体サーバ10に入力してもよい。この場合、自治体サーバ10は、各病院サーバ20に対してデータ共有要請を送信してもよいし、住民や病院の属性に応じて優先度を設定してもよい。例えば、内科専門の病院と外科専門の病院の2つがかかりつけ病院として設定されている場合には、自治体サーバ10は、内科専門の病院を優先してデータ共有先としてもよい。
【0251】
上記実施形態では、データ共有要請に住民の患者IDを設定する場合について説明した。しかし、患者IDが設定されていない住民に関しては、自治体サーバ10は、当該住民の氏名等を患者IDの代わりに設定しもよい。
【0252】
上記実施形態では、病院サーバ20に避難所案内を目的するデータ共有許諾が設定される場合について説明した。しかし、病院サーバ20にはデータ共有に関する他の目的が設定されてもよい。例えば、保険料算出を目的としたデータ共有許諾が病院サーバ20に設定されてもよい。この場合、例えば、保険会社がデータ共有先となる。
【0253】
あるいは、病院サーバ20は、住民の選択した目的に応じて、当該住民が選択可能なデータ種類を変更してもよい。例えば、上記実施形態で説明したように、避難所案内が目的の場合には、「既往症」、「現症」、「服薬情報」がデータ共有の候補として表示され、保険料算出の目的の場合には、「服薬情報」はデータ共有の候補として表示されなくともよい。
【0254】
上記実施形態では、データ共有時の条件として「避難指示発令(避難指示以上発令)」のように警戒レベルに応じた条件を設定する場合について説明した。しかし、住民の理解しやすいように、病院サーバ20は、「避難情報発令時」のような選択肢や「大雨、台風によって災害発生が予想される時」のような選択肢を用意してもよい。
【0255】
自治体サーバ10は、住民の健康情報によっては避難所に避難するよりも病院に搬送した方がよいと判断することもできる。この場合、自治体サーバ10は、当該住民の下に緊急車両を手配するような対応をしてもよい。
【0256】
あるいは、自治体サーバ10は、住民の健康情報によって避難所に避難するべきか否か判断できない場合には、病院情報に記載された病院に当該住民の処遇を問い合わせてもよい。
【0257】
上記実施形態では、防災担当者は、警戒レベルと避難情報の送信対象地域を自治体サーバ10に入力する場合について説明した。しかし、防災担当者は、データ共有に関する「ポリシ」も併せて自治体サーバ10に入力してもよい。防災担当者は、予想される災害の種類や規模等に応じて、入力するポリシ(データ共有によって取得するデータ種類)を決定してもよい。
【0258】
自治体サーバ10は、住民に案内可能な避難所が複数存在する場合には、住民の現在位置や住宅の位置に基づいて案内する避難所を選択してもよい。具体的には、自治体サーバ10は、住民に適した避難所のうち当該住民に最も近い避難所を選択し、案内をしてもよい。
【0259】
第2の実施形態では、受付端末40が避難者来所通知を自治体サーバ10に送信することを説明した。しかし、当該通知は避難所に設置された監視カメラ等が送信してもよい。
【0260】
第2の実施形態では、生体情報を用いて住民を特定する場合について説明した。しかし、住民を特定する手段は他の方法、手段であってもよい。例えば、マイナンバーカードに記載された電子証明書を使った本人認証が用いられてもよい。あるいは、IDとパスワードを用いたパスワード認証が用いられてもよい。あるいは、自治体サーバ10は、住民登録の際に生成された住民IDを住民に払い出し、当該払い出された住民IDが受付端末40に提示されてもよい。例えば、端末30は、住民登録された際に発行された住民IDを2次元コードに変換し、住民は端末30を操作して、当該2次元コードを受付端末40に提示することで住民の特定が行われてもよい。
【0261】
上記実施形態では、自治体サーバ10の内部に住民情報データベースや避難所情報データベースが構成される場合について説明したが、これらのデータベースは外部のデータベースサーバ等に構築されてもよい。即ち、自治体サーバ10の一部の機能は別のサーバに実装されていてもよい。より具体的には、上記説明した「住民登録部(住民登録手段)」、「避難情報制御部(避難情報制御手段)」等がシステムに含まれるいずれかの装置に実装されていればよい。
【0262】
上記実施形態では、かかりつけ病院が設定されている住民に関しては、その健康状態を確認し、医師等が常駐している避難所に案内する(案内する可能性がある)ことを説明した。しかし、かかりつけ病院が設定されていなく健康状態が不明な場合には、住民の年齢等を考慮して、大事をとって当該住民の避難先として医師や看護師が常駐している避難所が案内されてもよい。
【0263】
自治体サーバ10は、住民登録の際、住民の身元を確認してもよい。具体的には、自治体サーバ10は、住民の生体情報、個人情報等と共に、生体情報が記載された身元確認書類(例えば、パスポート、免許証等)を取得する。自治体サーバ10は、身元確認書類の生体情報と住民から取得した生体情報を用いた1対1照合を実行する。自治体サーバ10は、当該照合に成功した場合に、住民登録を行ってもよい。
【0264】
各装置(自治体サーバ10、病院サーバ20等)間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。これらの装置間では、患者の電子カルテ等が送受信され、これらの情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。
【0265】
上記説明で用いた流れ図(フローチャート、シーケンス図)では、複数の工程(処理)が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。
【0266】
上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。
【0267】
上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、住民の避難を支援する防災システムなどに好適に適用可能である。
【0268】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
[付記1]
住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する、生成部と、
前記生成された避難情報を前記住民が所持する端末に送信する、送信部と、
を備える、サーバ装置。
[付記2]
前記住民のかかりつけ病院から前記健康情報を取得する、取得部をさらに備える、付記1に記載のサーバ装置。
[付記3]
前記取得部は、前記かかりつけ病院の病院サーバに対して前記健康情報に関するデータ共有要請を送信することで、前記健康情報を取得する、付記2に記載のサーバ装置。
[付記4]
前記生成部は、前記住民の健康状態に適合する避難所を選択し、前記選択された避難所に関する情報を含む前記避難情報を生成する、付記1乃至3のいずれか一項に記載のサーバ装置。
[付記5]
前記生成部は、前記健康情報に基づいて健康に不安があると判定された前記住民に関しては、医師又は看護師が常駐する避難所、又は、医療設備を備える避難所を選択する、付記4に記載のサーバ装置。
[付記6]
前記住民のかかりつけ病院に関する情報を記憶する、記憶部をさらに備える、付記1乃至5のいずれか一項に先のサーバ装置。
[付記7]
複数の住民うち防災担当者により指定された地域に住む住民を選択し、前記選択された住民が所持する端末に対して、避難情報を送信する、自治体サーバと、
病院サーバと、
を含み、
前記自治体サーバは、前記選択された住民の健康情報をデータ共有により前記病院サーバから取得し、前記取得された健康情報に基づいて、前記選択された住民に案内する避難所を選択する、システム。
[付記8]
前記病院サーバは、患者の電子カルテに記載されたデータのうち少なくとも一部が前記自治体サーバと前記データ共有されることに関する共有許諾情報を記憶する、付記7に記載のシステム。
[付記9]
前記自治体サーバは、利用目的、データの種類及び共有先を含むデータ共有要請を前記病院サーバに送信する、付記8に記載のシステム。
[付記10]
前記病院サーバは、前記共有許諾情報を用いて前記データ共有要請を検証し、前記データ共有要請の検証に成功した場合に、前記患者が許諾したデータの種類に対応するデータを前記電子カルテから読み出し、前記読み出したデータを前記健康情報として前記自治体サーバに通知する、付記9に記載のシステム。
[付記11]
前記共有許諾情報は、前記データ共有の目的、共有するデータの種類、データの共有先及び前記データ共有時の条件のそれぞれに関する情報を含む、付記10に記載のシステム。
[付記12]
前記避難所に設置された受付端末をさらに含み、
前記受付端末は、来所した避難者の生体情報を含む避難者来所通知を前記自治体サーバに送信し、
前記自治体サーバは、前記避難者来所通知に含まれる生体情報を用いた照合処理により前記来所した避難者を特定し、前記特定された住民のかかりつけ病院の前記病院サーバに、前記来所した避難者の避難先を含む患者避難先情報を送信する、付記7に記載のシステム。
[付記13]
前記避難所に設置された医療端末をさらに含み、
前記医療端末は、被認証者の生体情報を含む認証要求を前記自治体サーバに送信し、
前記自治体サーバは、前記認証要求に含まれる生体情報を用いて前記被認証者を特定すると共に、前記特定された被認証者のかかりつけ病院に関する情報を前記医療端末に送信し、
前記医療端末は、前記かかりつけ病院に対して、前記被認証者の電子カルテの提供を要求する、付記7に記載のシステム。
[付記14]
サーバ装置において、
住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成し、
前記生成された避難情報を前記住民が所持する端末に送信する、サーバ装置の制御方法。
[付記15]
サーバ装置に搭載されたコンピュータに、
住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する処理と、
前記生成された避難情報を前記住民が所持する端末に送信する処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。
【0269】
なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。
【符号の説明】
【0270】
10 自治体サーバ
20 病院サーバ
30 端末
40 受付端末
50 医療端末
100 サーバ装置
101 生成部
102 送信部
201 通信制御部
202 住民登録部
203 避難情報制御部
204 記憶部
205 住民避難先管理部
206 患者避難先通知部
207 認証部
211 送信指示取得部
212 対象住民選択部
213 共有データ取得部
214 避難情報生成部
301 通信制御部
302 許諾情報取得部
303 共有制御部
304 記憶部
305 患者情報提供部
306 電子カルテ提供部
311 プロセッサ
312 メモリ
313 入出力インターフェイス
314 通信インターフェイス
401 通信制御部
402 生体情報取得部
403 避難者来所通知部
404 記憶部
501 通信制御部
502 生体情報取得部
503 認証要求部
504 電子カルテ取得部
505 記憶部