JP7652248B2 - システム - Google Patents

Description

本発明は、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体に関する。

台風等によって大規模災害の発生が予測されると、住民は避難所に避難することになる。住民の避難に関し、種々の技術開発が行われている。

特許文献１には、災害時に住民を含む罹災者に各自の状況に合った避難所情報を提供し、罹災者にとってもっとも適合した避難所へと誘導あるいは、各自が避難先を判断できるような機能を備えた災害時避難所情報提供システムを提供する、と記載されている。特許文献１のシステムは、避難所情報提供サーバを含む。当該サーバは、登録処理部と、照会処理部と、を備える。登録処理部は、利用者の住民基本台帳情報を含む住民情報データベースの情報に基づいて、避難所情報を検索する際の優先項目の情報を含む利用者の災害時の住民情報を災害時住民情報データベースに登録する。照会処理部は、災害時の住民情報に基づいて、避難所情報を検索し、避難所情報を利用者に提供する。

また、近年の情報処理技術、通信技術の発展により、患者のオンライン診療が可能となっている。

例えば、特許文献２には、遠隔診療を支援するサーバであって、医療機関から薬局への処方箋の共有、及び患者の薬の受取のプロセスをスムーズに行うことのできるサーバを提供する、と記載されている。

特開２０１４－０４１５０７号公報 特許第６７８１４９１号公報

上述のように、大規模災害の発生が予測されると、住民は避難所に避難することになる。住民が避難可能な避難所は複数存在することが多いが、住民はいずれの避難所に避難するのがよいのか判断できないことも多い。

なお、当該問題点は、上記特許文献１、特許文献２に開示された技術を適用しても解決することはできない。特許文献１の開示は、優先的に避難する住民を選択するに留まるためである。また、特許文献２の開示は、オンライン診療に関する文献であって、住民による避難所の選択とは無関係である。

本発明は、住民に適した避難所を案内することに寄与する、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体を提供することを主たる目的とする。

本発明の第１の視点によれば、住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する、生成部と、前記生成された避難情報を前記住民が所持する端末に送信する、送信部と、を備える、サーバ装置が提供される。

本発明の第２の視点によれば、複数の住民うち防災担当者により指定された地域に住む住民を選択し、前記選択された住民が所持する端末に対して、避難情報を送信する、自治体サーバと、病院サーバと、を含み、前記自治体サーバは、前記選択された住民の健康情報をデータ共有により前記病院サーバから取得し、前記取得された健康情報に基づいて、前記選択された住民に案内する避難所を選択する、システムが提供される。

本発明の第３の視点によれば、サーバ装置において、住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成し、前記生成された避難情報を前記住民が所持する端末に送信する、サーバ装置の制御方法が提供される。

本発明の第４の視点によれば、サーバ装置に搭載されたコンピュータに、住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する処理と、前記生成された避難情報を前記住民が所持する端末に送信する処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。

本発明の各視点によれば、住民に適した避難所を案内することに寄与する、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

図１は、一実施形態の概要を説明するための図である。 図２は、第１の実施形態に係る防災システムの概略構成の一例を示す図である。 図３は、第１の実施形態に係る防災システムの動作を説明するための図である。 図４は、第１の実施形態に係る防災システムの動作を説明するための図である。 図５は、第１の実施形態に係る防災システムの動作を説明するための図である。 図６は、第１の実施形態に係る防災システムの動作を説明するための図である。 図７は、第１の実施形態に係る自治体サーバの処理構成の一例を示す図である。 図８は、第１の実施形態に係る住民登録部の動作を説明するための図である。 図９は、第１の実施形態に係る住民情報データベースの一例を示す図である。 図１０は、第１の実施形態に係る避難情報制御部の処理構成の一例を示す図である。 図１１は、第１の実施形態に係る避難情報制御部の動作の一例を示すフローチャートである。 図１２は、第１の実施形態に係る避難情報制御部の動作を説明するための図である。 図１３は、第１の実施形態に係る避難所情報データベースの一例を示す図である。 図１４は、第１の実施形態に係る避難情報制御部の動作を説明するための図である。 図１５は、第１の実施形態に係る避難情報制御部の動作を説明するための図である。 図１６は、第１の実施形態に係る病院サーバの処理構成の一例を示す図である。 図１７は、第１の実施形態に係る患者情報データベースの一例を示す図である。 図１８は、第１の実施形態に係る共有制御部の動作を説明するための図である。 図１９は、第１の実施形態に係る防災システムの動作の一例を示すシーケンス図である。 図２０は、第２の実施形態に係る住民情報データベースの一例を示す図である。 図２１は、第２の実施形態に係る防災システムの概略構成の一例を示す図である。 図２２は、第２の実施形態に係る受付端末の処理構成の一例を示す図である。 図２３は、第２の実施形態に係る自治体サーバの処理構成の一例を示す図である。 図２４は、第２の実施形態に係る病院サーバの処理構成の一例を示す図である。 図２５は、第２の実施形態に係る防災システムの動作の一例を示すシーケンス図である。 図２６は、第３の実施形態を説明するための図である。 図２７は、第３の実施形態に係る医療端末の処理構成の一例を示す図である。 図２８は、第３の実施形態に係る生体情報取得部の動作を説明するための図である。 図２９は、第３の実施形態に係る自治体サーバの処理構成の一例を示す図である。 図３０は、第３の実施形態に係る病院サーバの処理構成の一例を示す図である。 図３１は、第３の実施形態に係る防災システムの動作の一例を示すシーケンス図である。 図３２は、本願開示に係る自治体サーバのハードウェア構成の一例を示す図である。 図３３は、本願開示の変形例に係る自治体サーバの動作を説明するための図である。

はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

一実施形態に係るサーバ装置１００は、生成部１０１と、送信部１０２と、を備える（図１参照）。生成部１０１は、住民の健康情報に基づいて、当該住民に案内する避難所に関する情報を含む避難情報を生成する。送信部１０２は、生成された避難情報を住民が所持する端末に送信する。

サーバ装置１００は、住民に対して避難情報を送信する際、当該住民の健康状態を考慮して避難所を選択し、当該選択した避難所に関する情報（例えば、避難所の名称や場所）を住民に通知する。例えば、サーバ装置１００は、健康状態に不安のない住民に関しては、特段の設備等を備えていない避難所を選択し、避難情報を用いて当該避難所を案内する。対して、健康状態に不安のある住民に関しては、サーバ装置１００は、医師や看護師が常駐している避難所や医療設備が整った避難所を選択し、避難情報を用いて当該避難所を案内する。このように、サーバ装置１００は、避難情報が送信される地域に住む住民に適した避難所を案内できる。

以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

［システムの構成］
図２は、第１の実施形態に係る防災システムの概略構成の一例を示す図である。図２に示すように、防災システムには、防災センター、少なくとも１以上の病院、少なくとも１以上の避難所が含まれる。

防災センターは、地域の自治体等により管理、運営される。防災センターは、例えば、市役所等に設置される。各地域の学校、公民館等の施設が避難所に該当する。学校、公民館等の施設は、災害発生時に「避難所」として活用される。

防災センターは、自治体サーバ１０を運営、管理する。自治体サーバ１０は、地域住民の防災に関する管理、避難所の運営、避難者の支援等を担うサーバ装置である。自治体サーバ１０は、防災センターが設置された建物と同じ建物に設置されていてもよいし、ネットワーク上（クラウド上）に設置されていてもよい。

各病院は、病院サーバ２０を備える。病院サーバ２０は、患者の診療結果（診察結果、治療結果）を記憶する。病院サーバ２０は、患者の診療結果等を「電子カルテ」として記憶する。病院サーバ２０は、患者の基本情報、診療に関する診療情報、バイタルデータ、服薬に関する服薬情報等を電子カルテによって一元管理する。

患者の基本情報には、患者ＩＤ（IDentifier）、氏名、生年月日、住所、連絡先、既往症等に関する情報が含まれる。診療情報には、患者の主訴（問診票への記載事項）、検査結果（レントゲン等の結果）、診断名（診断により確定した病名；現症）、治療方針等の情報が含まれる。バイタルデータには、血圧、脈拍、体温等に関する情報（測定結果、測定履歴）が含まれる。服薬情報には、処方された薬の名称や服薬の指示（服薬のタイミング、服薬量）等が含まれる。

各病院が備える病院サーバ２０の機能は同一とすることができるので、以降の説明では、病院Ａに設置された病院サーバ２０を中心に説明する。

図２に示す各装置は相互に接続されている。例えば、自治体サーバ１０と病院サーバ２０は、有線又は無線の通信手段により接続され、相互に通信が可能となるように構成されている。

図２に示す防災システムの構成は例示であって、その構成を限定する趣旨ではない。例えば、防災センターには複数の自治体サーバ１０が含まれていてもよい。同様に、各病院には、複数の病院サーバ２０が含まれていてもよい。

［動作概略］
続いて、第１の実施形態に係る防災システムの動作概略について説明する。

第１の実施形態に係る防災システムにおいて、災害の発生が見込まれると、防災センターから各住民に避難情報が送信される。避難情報には、避難先に関する情報（例えば、避難所の名称や場所）が含まれる。避難情報を送信する際、防災センターは、各住民の状況、状態を確認し、それぞれの住民に適した避難所を選択して避難を促す。とりわけ、防災センターは、住民の健康状態を考慮して当該住民に案内する避難所を決定する。

防災センターは、当該避難所を決定する際、各住民の「健康情報」を病院（住民のかかりつけ病院）から取得する。防災センターは、取得した健康情報に基づいて、各住民それぞれに適した避難所を選択し、住民に案内する。なお、健康情報は、各住民の健康に関する具体的な情報（データ）である。例えば、健康情報として、住民の既往症、現症、服薬情報等が例示される。

＜住民登録＞
はじめに、地域の住民は、自身の情報を自治体（防災センター）に事前登録する（図３参照）。以降の説明において、住民が自治体サーバ１０に登録する情報を「住民情報」と記載する。

住民は、任意の手段を用いて住民情報を自治体サーバ１０に登録する。例えば、住民は、所持する端末３０を操作して住民登録を行う。例えば、住民は、端末３０を操作して、自治体サーバ１０にアクセスする。より具体的には、住民は、自治体サーバ１０が提供するＷＥＢ（ウェブ）ページにアクセスする。

幼児や高齢者等、自ら情報の登録を行うことが困難な住民に関しては、親や子供が代理で幼児、高齢者等に関する住民情報を自治体サーバ１０に登録してもよい。

住民情報には、個人情報（所謂、基本４情報；氏名、性別、住所、生年月日）が含まれる。また、住民情報には、住民の連絡先（例えば、端末３０で受信可能なメールアドレスや電話番号等）が含まれる。

上記情報に加え、住民情報には、かかりつけの病院に関する情報（以下、単に病院情報と表記する）が含まれる。具体的には、かかりつけの病院名、当該かかりつけの病院から発行された患者ＩＤ等が「病院情報」に含まれる。

なお、かかりつけの病院がない住民は、病院情報を防災センター（自治体サーバ１０）に登録しなくてもよい。

自治体サーバ１０は、住民から個人情報、病院情報を取得すると、当該住民を識別するための住民ＩＤを生成する。自治体サーバ１０は、生成した住民ＩＤ、個人情報、病院情報等を対応付けて住民情報データベースに記憶する。住民情報データベースの詳細は後述する。

＜データ共有許諾＞
かかりつけ病院を持つ住民は、上記住民登録に前後して、病院から防災センター（自治体）へのデータ共有（データの提供）に関する許諾を病院に設定する。例えば、住民は、端末３０を操作して、かかりつけ病院の病院サーバ２０にアクセスする（図４参照）。より具体的には、住民は、病院サーバ２０が提供するＷＥＢ（ウェブ）ページにアクセスする。

当該ＷＥＢページにおいて、住民は、かかりつけ病院が記憶、管理する電子カルテに記載されたデータの全部又は一部のデータを外部提供することに対する許諾を与える。例えば、病院サーバ２０は、住民の所持する端末３０に図５に示すようなＧＵＩ（Graphical User Interface）や入力フォームを表示する。

住民は、端末３０を操作して、データ共有の「目的」、共有するデータの「種類」、データの「共有先」、データ共有時の「条件」を病院サーバ２０に入力する。

例えば、住民は、データ共有の目的として「避難所案内」、共有データの種類として「既往症」、「現症」、「服薬情報」、データ共有先として「防災センター」、データ共有の条件として「避難指示以上発令時」を病院サーバ２０に入力する。

病院サーバ２０は、上記住民から取得したデータ共有に関する情報を「共有許諾情報」として管理する。病院サーバ２０は、当該住民の患者ＩＤ、電子カルテのＩＤ（カルテＩＤ）、共有許諾情報を対応付けて患者情報データベースに記憶する。患者情報データベースの詳細は後述する。

上記住民登録とデータ共有許諾が、災害発生前に行われる事前準備である。続いて、図６を参照しつつ、災害発生時の防災システムの動作について説明する。

＜避難情報送信＞
自治体の防災担当者は、台風、大雨等によって災害が発生すると見込まれる際には、「避難情報送信指示」を自治体サーバ１０に入力する（ステップＳ１）。例えば、防災担当者は、警戒レベルと共に避難情報送信指示を自治体サーバ１０に入力する。

当該指示に応じて、自治体サーバ１０は、地域の住民に「避難情報」を送信する。例えば、警戒レベルが「５」であれば緊急安全確保、警戒レベルが「４」であれば避難指示、警戒レベルが「３」であれば高齢者等避難のそれぞれに対応した「避難情報」が地域の住民に送信される。

その際、自治体サーバ１０は、各住民に適した（各住民に最適化された、パーソナライズされた）避難情報を生成し、当該避難情報を各住民が所持する端末３０に送信する。

避難情報生成の際、自治体サーバ１０は、かかりつけ病院が設定されている住民については、当該住民の健康情報をデータ共有によってかかりつけ病院から取得する。具体的には、自治体サーバ１０は、住民情報データベースを参照し、避難情報の送信対象となっている住民にかかりつけ病院が設定されているか否か判定する。自治体サーバ１０は、かかりつけ病院が設定されていれば、当該病院の病院サーバ２０に対して「データ共有要請」を送信する（ステップＳ２）。

具体的には、自治体サーバ１０は、住民情報データベースを参照し、かかりつけ病院が設定された住民の患者ＩＤを読み出す。自治体サーバ１０は、当該読み出した患者ＩＤを含む「データ共有要請」を病院サーバ２０に送信する。

データ共有要請には、患者ＩＤに加え、共有データの「利用目的」、共有データの「種類」、共有データの「共有先」が含まれる。例えば、共有データの利用目的として「避難指示発令に伴う避難所案内」、共有データの種類として「現症」、共有データの共有先として「防災センター」がそれぞれ設定される。

病院サーバ２０は、自治体サーバ１０から受信したデータ共有要請を検証する。

データ共有要請を受信した病院サーバ２０は、当該要請に含まれる患者ＩＤをキーとして患者情報データベースを検索し、対応するカルテＩＤ（電子カルテのＩＤ）と共有許諾情報を特定する。

病院サーバ２０は、受信したデータ共有要請に含まれる「利用目的」が上記特定された共有許諾情報に含まれる「目的」及び「条件」に合致するか否か、共有データの共有先が共有許諾情報の「共有先」と一致するか否かを検証する。

病院サーバ２０は、これらの検証に成功すると、自治体サーバ１０との間のデータ共有が可能と判定する。この場合、病院サーバ２０は、該当する患者の電子カルテから共有許諾情報に設定されたデータ種類に対応したデータを読み出す。例えば、「現症」に関するデータ共有が承諾されている場合には、「胃がん」、「肺がん」といった具体的な病名が電子カルテから読み出される。

病院サーバ２０は、データ共有の対象となった患者（住民）の患者ＩＤ及び読み出したデータ（共有データ）を含む「健康情報通知」を自治体サーバ１０に送信する（ステップＳ３）。

自治体サーバ１０は、病院サーバ２０から取得した健康情報を参照し、住民（かかりつけ病院が設定された住民）に適した避難情報を生成する。

例えば、自治体サーバ１０は、住民Ａにはかかりつけ病院が設定されておらず、住民Ａは健康に不安のない住民であると判断した場合には、当該住民Ａの避難先として避難所Ｂを案内するような避難情報を生成する。避難所Ｂは、特別な装置や人員が配置されていない通常の避難所である。

あるいは、自治体サーバ１０は、住民Ｂにはかかりつけ病院が設定され、住民Ｂは健康に不安のある住民であると判断した場合には、当該住民Ｂの避難先として避難所Ａを案内するような避難情報を生成する。避難所Ａは、医師や看護師が常駐し、医療設備が充実した避難所である。

自治体サーバ１０は、生成した避難情報を各住民が所持する端末３０に送信する（ステップＳ４）。

各住民は、端末３０に表示された避難情報を確認し、当該避難情報に記載された避難所に避難する。

続いて、第１の実施形態に係る防災システムに含まれる各装置の詳細について説明する。

［自治体サーバ］
図７は、第１の実施形態に係る自治体サーバ１０の処理構成（処理モジュール）の一例を示す図である。図７を参照すると、自治体サーバ１０は、通信制御部２０１と、住民登録部２０２と、避難情報制御部２０３と、記憶部２０４と、を備える。

通信制御部２０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部２０１は、病院サーバ２０からデータ（パケット）を受信する。また、通信制御部２０１は、病院サーバ２０に向けてデータを送信する。通信制御部２０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部２０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部２０１を介して他の装置とデータの送受信を行う。通信制御部２０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

住民登録部２０２は、上述の住民登録を実現する手段である。住民登録部２０２は、将来的に避難者となり得る複数の住民それぞれの住民情報を取得する手段である。より具体的には、住民登録部２０２は、病院情報を含む住民情報を任意の手段により取得する。

例えば、住民登録部２０２は、住民が操作する端末３０から住民情報を取得してもよい。あるいは、住民は、住民情報が記載された書類や住民情報が記憶された外部記憶装置を防災センターに送付し、当該センターの職員等が住民情報を自治体サーバ１０に入力してもよい。

住民登録部２０２は、住民情報を入力するためのＧＵＩや入力フォームを住民に提供してもよい。例えば、住民登録部２０２は、図８に示すようなＧＵＩを住民の端末３０に表示してもよい。

住民は、端末３０を操作して、図８に示される情報を入力する。住民は、情報入力を完了すると「決定」ボタンを押下し、個人情報（氏名、連絡先等）や病院情報を自治体サーバ１０に入力する。

また、住民登録部２０２は、住民を識別するための住民ＩＤを生成する。住民ＩＤは、住民登録された住民を一意に識別できる情報であればどのような情報であってもよい。例えば、住民登録部２０２は、住民登録のたびに一意な値を採番し住民ＩＤとしてもよい。あるいは、住民登録部２０２は、住民ＩＤに相当する情報（例えば、公的機関が発行する識別情報）を住民から取得してもよい。

住民登録部２０２は、上記生成された住民ＩＤ、個人情報、病院情報を対応付けて住民情報データベースに記憶する（図９参照）。なお、図９に示す住民情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、住民の生体情報（例えば、顔画像や当該顔画像から生成された特徴量）が住民情報データベースに登録されていてもよい。あるいは、かかりつけ病院の電話番号等の連絡先が住民情報データベースに登録されていてもよい。なお、患者ＩＤは、かかりつけの病院から発行された識別情報である。例えば、診察券等に記載されているＩＤが患者ＩＤに相当する。

避難情報制御部２０３は、避難情報に関する制御を行う手段である。避難情報制御部２０３は、図１０に示すように、送信指示取得部２１１と、対象住民選択部２１２と、共有データ取得部２１３と、避難情報生成部２１４と、からなるサブモジュールを備える。

図１１を参照し、避難情報制御部２０３の動作を説明する。図１１は、第１の実施形態に係る避難情報制御部２０３の動作の一例を示すフローチャートである。

送信指示取得部２１１は、自治体の防災担当者から「避難情報送信指示」を取得する（ステップＳ１０１）。具体的には、送信指示取得部２１１は、防災担当者の使用する防災担当者端末（図６等に図示せず）に避難情報送信指示を入力するためのＧＵＩ、入力フォーム等を表示する。

例えば、送信指示取得部２１１は、図１２に示すようなＧＵＩを防災担当者端末に表示する。防災担当者は、警戒レベルと、避難情報を発令する地域と、を選択する。

対象住民選択部２１２は、避難情報の送信対象となる住民を選択する（ステップＳ１０２）。対象住民選択部２１２は、住民情報データベースを参照し、防災担当者が入力した地域（避難情報を発令する地域）の住民を選択する。対象住民選択部２１２は、住民情報データベースの住所フィールドを参照し、避難情報発令地域に居住している住民（エントリ）を抽出する。当該抽出された住民が、避難情報の送信対象となる住民である。

共有データ取得部２１３は、住民のかかりつけ病院から当該住民の健康情報を取得する手段である。共有データ取得部２１３は、データ共有によって病院サーバ２０から健康情報を取得する。共有データ取得部２１３は、かかりつけ病院の病院サーバ２０に対して健康情報に関するデータ共有要請を送信することで、健康情報を取得する。

共有データ取得部２１３は、上記避難情報の送信対象として抽出された各住民の病院情報を確認し、かかりつけ病院が設定されているか否か判定する（ステップＳ１０３）。

かかりつけ病院が設定されていなければ（ステップＳ１０３、Ｎｏ分岐）、共有データ取得部２１３は、特段の動作を行わない。この場合、ステップＳ１０６以降の処理が実行される。

かかりつけ病院が設定されていれば（ステップＳ１０３、Ｙｅｓ分岐）、共有データ取得部２１３は、データ共有要請を生成し、当該生成されたデータ共有要請を病院サーバ２０に送信する（ステップＳ１０４）。

具体的には、共有データ取得部２１３は、病院情報を参照し、かかりつけ病院の病院名及び患者ＩＤを取得する。

共有データ取得部２１３は、病院名からデータ共有要請の送信先となる病院サーバ２０を特定する。共有データ取得部２１３は、病院名と病院サーバ２０のＩＰ（Internet Protocol）アドレス等を対応付けて記憶するテーブル情報を参照することで、データ共有要請の送信先を取得する。

共有データ取得部２１３は、上記患者ＩＤと、取得する共有データに関する情報（利用目的、データ種類、データ共有先）と、を含むデータ共有要請を生成し、病院サーバ２０に送信する。

共有データの利用目的として「避難指示発令に伴う避難所案内」といった内容が設定される。なお、上記設定される内容のうち「避難指示発令」は防災担当者が入力した警戒レベルによって変化する。

また、共有データの種類として「現症」、共有データの共有先として「防災センター」といった内容がそれぞれ設定される。なお、どのような種類のデータを共有するか（病院から取得するか）は、防災センターのポリシに基づく。例えば、「現症」を取得するポリシ、「既往症」及び「現症」を取得するポリシ、「既往症」、「現症」及び「服薬情報」を取得するポリシが予め自治体サーバ１０に設定される。

共有によって取得しようするとするデータ種類を多くすれば、住民から拒絶されている可能性が高いが、自治体サーバ１０はより正確な避難情報を作成できる。対して、共有によって取得しようとするデータ種類が少なければ、住民の許諾を得られている可能性が高いが、自治体サーバ１０はより正確な避難情報の作成が難しい。防災担当者等は、これらのメリット、デメリットを考慮して共有によって取得するデータ種類を決定する（ポリシを決定する）。

共有データ取得部２１３は、データ共有要請に対する応答を受信する（ステップＳ１０５）。データ共有が許諾されていなければ、共有データ取得部２１３は、否定応答を受信する。この場合、共有データ取得部２１３は、特段の動作を行わない。共有データ取得部２１３は、共有データの取得できなかった住民はかかりつけ病院の設定されていない住民と扱えばよい。

データ共有が許諾されていれば、共有データ取得部２１３は、肯定応答を受信する。即ち、共有データ取得部２１３は、病院サーバ２０から「健康情報通知」を受信する。健康情報通知には、患者ＩＤと、健康情報と、が含まれる。

なお、上述のように、健康情報は、データ共有要請に設定したデータ種類に対応する具体的なデータ（情報）である。上記の例のように、「現症」のデータ共有を要請した場合には、「胃がん」、「肺がん」といった具体的な病名が健康情報として自治体サーバ１０に通知される。

避難情報生成部２１４は、避難情報を生成する手段である。避難情報生成部２１４は、各住民の健康情報に基づいて、当該住民に案内する避難所に関する情報を含む避難情報を生成する。

避難情報生成部２１４は、避難情報の送信対象となっている住民に案内する避難先（避難所）を選択する（ステップＳ１０６）。その際、例えば、避難情報生成部２１４は、対象住民の健康状態と各避難所の特徴に基づいて、住民に案内する避難先を選択する。

避難情報生成部２１４は、図１３に示すような避難所情報データベースを参照し、各避難所の特徴を読み出す。図１３に示すように、避難所情報データベースは、各避難所の避難所ＩＤ、名称、場所、特徴を対応付けて記憶する。また、図１３に示すように、特徴のない避難所もあれば、複数の特徴を持つ避難所も存在する。

なお、図１３に示す避難所情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、各避難所の連絡先等が避難所情報データベースに登録されていてもよい。あるいは、各避難所の収容可能人数（キャパシティ）が避難所情報データベースに登録されていてもよい。

避難情報生成部２１４は、住民の健康情報と各避難所の特徴を参照し、当該住民の健康状態に適合する避難所を選択する。

例えば、避難情報生成部２１４は、健康状態に不安のない住民（かかりつけ病院が設定されていない住民；健康情報を考慮する必要のない住民）に関しては、特段の特徴を備えていない避難所を選択する。この場合、例えば、避難情報生成部２１４は、図１３に示す避難所Ｂを選択する。このように、避難情報生成部２１４は、健康状態に不安のない住民に関しては、医師や看護師が常駐していない通常の避難所Ｂを積極的に選択することができる。

健康情報を考慮する必要のある住民（かかりつけ病院が設定された住民）に関しては、避難情報生成部２１４は、当該住民の健康情報（上記の例では、現症）と避難所の特徴に基づいて避難所を選択する。例えば、現症が医師等の元で観察が必要な病気であれば、避難情報生成部２１４は、医師や看護師が常駐している避難所を選択する。この場合、避難情報生成部２１４は、図１３に示す避難所Ａや避難所Ｃを選択する。

避難情報生成部２１４は、現症の内容によっては通常の避難所（例えば、避難所Ｂ）を選択することもある。例えば、「指の骨折」のような現症であれば、当該住民に対して特段の配慮は必要ないと想定されるので、通常の避難所Ｂが選択される。あるいは、避難情報生成部２１４は、かかりつけ病院が設定されているが、健康情報に基づけば明らかに健康に問題がないと判断される住民に関しては、通常の避難所Ｂを選択してもよい。

住民の健康状態と避難所の選択は、予め定められたテーブル情報等に基づいて行われてもよいし、自治体サーバ１０に実装された学習モデルを用いて行われてもよい。例えば、現症を入力すると、当該現症に適合した避難所の特徴を出力するような学習モデルが自治体サーバ１０に実装されていてもよい。

このように、避難情報生成部２１４は、健康情報に基づいて健康に不安があると判定される住民に関しては、医師又は看護師が常駐する避難所、又は、医療設備を備える避難所を選択する。

避難情報生成部２１４は、データ共有によって「服薬情報」を取得した場合には、当該服薬情報と避難所の特徴に基づいて、避難所を選択してもよい。例えば、避難情報生成部２１４は、住民が服薬している薬を常備している避難所を選択してもよい。例えば、図１３の例では、薬Ａを服薬している住民に関しては、避難所Ｃが選択される。

避難情報生成部２１４は、防災担当者が入力した警戒レベルと、上記選択された避難所と、に基づいて避難情報を生成する（ステップＳ１０７）。例えば、健康状態に不安のない住民（健康情報を考慮する必要の無い住民）に関しては、図１４に示すような避難情報が生成される。対して、健康情報を考慮する必要のある住民に関しては、図１５に示すような避難情報が生成される。

避難情報制御部２０３は、生成された避難情報を住民の所持する端末３０に送信する（ステップＳ１０８）。避難情報制御部２０３は、住民情報データベースに記載された各住民の連絡先（例えば、端末３０が受信可能なメールアドレス等）に避難情報を送信する。

避難情報制御部２０３は、避難情報の送信対象となっている住民が残っていれば（ステップＳ１０９、Ｙｅｓ分岐）、ステップＳ１０２に戻り処理を継続する。避難情報制御部２０３は、避難情報の送信対象となっている住民が残っていなければ（ステップＳ１０９、Ｎｏ分岐）、処理を終了する。

記憶部２０４は、自治体サーバ１０の動作に必要な情報を記憶する手段である。記憶部２０４には、住民情報データベース、避難所情報データベース等が構築される。

［病院サーバ］
図１６は、第１の実施形態に係る病院サーバ２０の処理構成（処理モジュール）の一例を示す図である。図１６を参照すると、病院サーバ２０は、通信制御部３０１と、許諾情報取得部３０２と、共有制御部３０３と、記憶部３０４と、を備える。

通信制御部３０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部３０１は、自治体サーバ１０からデータ（パケット）を受信する。また、通信制御部３０１は、自治体サーバ１０に向けてデータを送信する。通信制御部３０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部３０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部３０１を介して他の装置とデータの送受信を行う。通信制御部３０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

許諾情報取得部３０２は、共有許諾情報を取得する手段である。かかりつけ病院にデータ共有のための設定を希望する利用者は、当該病院が管理、運営するホームページにアクセスし、患者情報等を管理するためのアカウントにログインする。その際、利用者は、自身に割り当てられた患者ＩＤをホームページに入力する。許諾情報取得部３０２は、当該患者ＩＤを取得し、データ共有許諾の設定を希望する利用者（患者）を特定する。

利用者がデータ共有許諾の設定をするためのページにアクセスすると、許諾情報取得部３０２は、利用者の所持する端末３０に図５に示すようなＧＵＩを表示する。許諾情報取得部３０２は、端末３０からデータ共有の目的、データ種類、データ共有先、データ共有時の条件を取得する。

許諾情報取得部３０２は、取得した共有許諾情報（目的、データ種類、データ共有先、条件）を患者情報データベースに記憶する。許諾情報取得部３０２は、患者ＩＤ、カルテＩＤ、共有許諾情報を対応付けて患者情報データベースに記憶する（図１７参照）。

なお、図１７に示す患者情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、患者の生体情報（例えば、顔画像や当該顔画像から生成された特徴量）が患者情報データベースに登録されていてもよい。

また、患者ＩＤやカルテＩＤは、患者の初診時に生成され、これらのＩＤが生成されると患者情報データベースに追加される。患者ＩＤの生成やカルテＩＤを含む電子カルテの生成、管理は当業者にとって明らかであり、本願開示の趣旨とも異なるので詳細な説明を省略する。

共有制御部３０３は、データ共有を制御する手段である。図１８を参照し、共有制御部３０３の動作を説明する。図１８は、第１の実施形態に係る共有制御部３０３の動作の一例を示すフローチャートである。

共有制御部３０３は、外部装置（自治体サーバ１０）からデータ共有要請を受信する（ステップＳ２０１）。

共有制御部３０３は、当該取得したデータ共有要請を検証する。共有制御部３０３は、２つの検証（２段階の検証）を行う。

はじめに、共有制御部３０３は、データ共有要請に含まれる患者ＩＤをキーとして患者情報データベースを検索し、対応する共有許諾情報を特定する（ステップＳ２０２）。

共有制御部３０３は、データ共有要請に含まれる「利用目的」が上記特定された共有許諾情報に含まれる「目的」及び「条件」に合致するか否を検証する（第１の検証；ステップＳ２０３）。

例えば、患者によって許諾された目的が「避難所案内」、データ共有の条件が「避難指示以上発令時」であって、共有データの利用目的が「避難指示発令に伴う避難所案内」であれば、共有制御部３０３は、データ共有のための第１の検証に成功したと判定する。

対して、患者によって許諾された目的が「避難所案内」、条件が「避難指示以上発令時」であって、共有データの利用目的が「ダイエット情報の提供」であれば、共有制御部３０３は、データ共有のための第１の検証に失敗したと判定する。

第１の検証に失敗すれば（ステップＳ２０４、Ｎｏ分岐）、共有制御部３０３は、データ共有不可に設定する（ステップＳ２０５）。

第１の検証に成功すれば（ステップＳ２０４、Ｙｅｓ分岐）、共有制御部３０３は、第２の検証を実行する（ステップＳ２０６）。具体的には、共有制御部３０３は、データ共有要請に含まれる共有先が共有許諾情報の「共有先」と一致するか否かを検証する。

例えば、患者は防災センターに対してデータ共有を許諾した場合であって、データ共有要請に含まれる共有先も防災センターであれば、共有制御部３０３は、データ共有のための第２の検証に成功したと判定する。

対して、患者は防災センターに対してデータ共有を許諾したにも関わらず、データ共有要請に含まれる共有先が「スポーツジム」であれば、共有制御部３０３は、データ共有のための第２の検証に失敗したと判定する。

第２の検証に失敗すれば（ステップＳ２０７、Ｎｏ分岐）、共有制御部３０３は、データ共有不可に設定する（ステップＳ２０５）。

第２の検証に成功すれば（ステップＳ２０７、Ｙｅｓ分岐）、共有制御部３０３は、データ共有可に設定する（ステップＳ２０８）。

共有制御部３０３は、データ共有要請に対する応答を送信する（ステップＳ２０９）。

データ共有不可の場合には、共有制御部３０３は、その旨を示す否定応答を自治体サーバ１０に送信する。

データ共有可の場合には、共有制御部３０３は、データ共有要請に含まれる患者ＩＤに対応するカルテＩＤを患者情報データベースから読み出す。

共有制御部３０３は、カルテＩＤを用いて、データ共有の対象者の電子カルテを特定する。共有制御部３０３は、当該特定された電子カルテの記載項目のうち、共有許諾情報において「許諾」と設定されている項目（患者情報データベースのデータ種類フィールドの項目）を読み出す。

例えば、図１７の１行目に示すように、データ共有が許諾されたデータ種類が「現症」であれば、共有制御部３０３は、電子カルテから「現症」とラベル付けされたデータを読み出す。例えば、「胃がん」、「肺がん」といった具体的な病名が読み出される。

共有制御部３０３は、データ共有が許諾されたデータを読み出すと、当該読み出したデータとデータ共有の対象者（患者）の患者ＩＤを含む健康情報通知を生成し、当該情報をデータ共有要請の送信元（共有先；自治体サーバ１０）に送信する。健康情報通知は、データ共有要請に対する肯定応答として扱われる。

記憶部３０４は、病院サーバ２０の動作に必要な情報を記憶する手段である。記憶部３０４には、患者情報データベース、電子カルテを構成するデータベース等が構築される。病院サーバ２０は、患者の電子カルテに記載されたデータのうち少なくとも一部が自治体サーバ１０とデータ共有されることに関する共有許諾情報を記憶部３０４に記憶する。

［端末］
端末３０には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置やコンピュータ（パーソナルコンピュータ、ノートパソコン）等が例示される。端末３０は、住民の操作を受け付け、自治体サーバ１０等と通信可能であれば任意の機器、デバイスとすることができる。また、端末３０の構成等は当業者にとって明らかであるので、詳細な説明を省略する。

［システムの動作］
続いて、第１の実施形態に係る防災システムの動作について説明する。なお、住民登録やデータ共有許諾に関する動作の説明は省略する。図１９は、第１の実施形態に係る防災システムの動作の一例を示すシーケンス図である。

自治体サーバ１０は、防災担当者から避難情報送信指示を取得する（ステップＳ０１）。

自治体サーバ１０は、避難情報の送信対象となる住民を選択する（ステップＳ０２）。

当該選択された住民が健康状態を考慮する必要のある住民の場合（かかりつけ病院が設定された住民の場合）、自治体サーバ１０は、かかりつけ病院の病院サーバ２０に対してデータ共有要請を送信する（ステップＳ０３）。

データ共有要請を受信した病院サーバ２０は、当該要請の検証を行う（ステップＳ０４）。病院サーバ２０は、データ共有要請の利用目的や共有先を検証する。

検証に成功すると、病院サーバ２０は、患者の電子カルテから当該患者がデータ共有を許諾したデータ種類に対応した具体的なデータを読み出す。病院サーバ２０は、当該読み出したデータを含む健康情報通知を自治体サーバ１０に送信する（ステップＳ０５）。

このように、病院サーバ２０は、共有許諾情報を用いてデータ共有要請を検証し、データ共有要請の検証に成功した場合に、患者が許諾したデータの種類に対応するデータを電子カルテから読み出す。病院サーバ２０は、当該読み出したデータを健康情報として自治体サーバ１０に通知する。

健康情報通知を受信すると、自治体サーバ１０は、住民の健康状態（健康情報）に基づいて、当該住民に案内する避難所を選択する（ステップＳ０６）。

自治体サーバ１０は、選択した避難所の情報（避難所の名称や場所）を含む避難情報を生成し、住民が所持する端末３０に送信する（ステップＳ０７）。

端末３０は、受信した避難情報を出力する（ステップＳ０８）。例えば、端末３０は、避難情報をモニターに表示する、避難情報をスピーカーから読み上げるといった対応を行う。

以上のように、第１の実施形態に係る防災システムにおいて、自治体サーバ１０は、複数の住民うち防災担当者により指定された地域に住む住民を選択し、当該選択された住民が所持する端末３０に対して避難情報を送信する。その際、自治体サーバ１０は、選択された住民の健康情報をデータ共有により病院サーバ２０から取得する。自治体サーバ１０は、取得した健康情報に基づいて、住民に案内する避難所を選択する。その結果、健康に不安のある住民に対しては、医師が常駐していたり医療設備が充実していたりする避難所が選択される。対して、健康に不安のない住民に対しては、通常の避難所が選択される。このような自治体サーバ１０の働きによって、健常者が医療設備等の充実した避難所に避難することがなくなり、健康に不安のある住民がより確実に上記避難所に避難することができる。

また、住民が病院に対してデータ共有可能なデータ種類を設定することで、住民が外部に知られたくない情報を適切に保護できる。即ち、電子カルテの情報をそのまま防災センター（自治体；自治体サーバ１０）に提供するのではなく、データの共有に条件、範囲の制限を設けることで住民のプライバシーが適切に保護される。

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

第１の実施形態において、住民は、災害発生時に自治体（防災センター）に提供可能な共有データをかかりつけ病院に設定する場合について説明した。自治体は、病院から共有されたデータを用いて、各住民の健康状態に応じた避難所の案内をする。自治体は、健康情報（既往症、現症、服薬情報等）を用いて住民にパーソナライズされた避難先を決定する。即ち、第１の実施形態では、住民が避難所に避難する前のシステムについて、その構成及び動作について説明した。

第２の実施形態では、避難後のデータ活用について説明する。具体的には、自治体サーバ１０は、避難所に到着した住民を生体認証によって特定する。自治体サーバ１０は、特定した住民に関する情報をかかりつけ病院（病院サーバ２０）に提供する。

以下、第１の実施形態と第２の実施形態の相違点を中心に説明する。

第２の実施形態では、住民は、自身の生体情報（例えば、顔画像）を自治体サーバ１０に入力する。自治体サーバ１０の住民登録部２０２は、顔画像から特徴量を生成し、当該特徴量（生体情報）を住民ＩＤ等と対応付けて住民情報データベースに記憶する（図２０参照）。

図２１は、第２の実施形態に係る防災システムの概略構成の一例を示す図である。図２１に示すように、各避難所は、避難者の受付を担う受付端末４０を備える。なお、各避難所に設置される受付端末４０の構成、動作は同一とすることができるので、以降の説明では、避難所Ａに設置された受付端末４０の構成等を中心に説明する。

避難情報を取得すると、住民は、避難所に避難する。避難者は、避難所に設置された受付端末４０の面前に移動する。

受付端末４０は、避難者を撮影し、顔画像を取得する。受付端末４０は、取得した顔画像と各避難所に割り当てられた避難所ＩＤを含む「避難者来所通知」を自治体サーバ１０に送信する。

自治体サーバ１０は、取得した顔画像を用いた照合処理を行い、避難所に到着した住民を特定する。自治体サーバ１０は、住民の避難先を住民情報データベースに反映する（図２０の避難所フィールド参照）。

図２０の例では、かかりつけ病院が設定されている住民（ＩＤ３１の住民）は避難所Ａに避難し、同じくかかりつけ病院が設定されている住民（ＩＤ３２の住民）は避難所Ｂに避難していることが住民情報データベースに登録されている。なお、ＩＤ３２の住民は、本来、避難所Ａへの避難が案内されたはずであるが、何らかの事情により避難所Ｂに避難したと想定される。避難所Ｂは、医師や看護師が常駐していない通常の避難所である。

自治体サーバ１０は、定期的又は所定のタイミングで住民情報データベースにアクセスする。自治体サーバ１０は、かかりつけ病院が設定され、かつ、避難所に避難している住民を抽出する。図２０の例では、ＩＤ３１、ＩＤ３２の住民がそれぞれ抽出される。

自治体サーバ１０は、当該抽出された住民のかかりつけ病院に対して、「患者避難先情報」を送信する。患者避難先情報は、住民（かかりつけ病院の患者）の避難先の情報と患者ＩＤを含む。図２０の例では、病院Ａに対してｐＩＤ３１の患者が避難所Ａに避難していることを示す患者避難先情報、病院Ｂに対してｐＩＤ４１の患者が避難所Ｂに避難していることを示す患者避難先情報がそれぞれ送信される。

患者避難先情報を受信した病院サーバ２０は、患者の避難先を医師、看護師等に通知する。医師等は、自院の患者の避難先を把握できると共に、その避難先が妥当か否かを判断できる。例えば、病院Ｂの患者は医師等が常駐していない通常の避難所に避難しているが、当該避難先が妥当か否か病院Ｂの医師等によって判断される。

第２の実施形態に係る各装置の処理構成について説明する。

［受付端末］
図２２は、受付端末４０の処理構成（処理モジュール）の一例を示す図である。図２２を参照すると、受付端末４０は、通信制御部４０１と、生体情報取得部４０２と、避難者来所通知部４０３と、記憶部４０４と、を備える。

通信制御部４０１は、他の装置との間の通信を制御する手段である。具体的には、通信制御部４０１は、自治体サーバ１０からデータ（パケット）を受信する。また、通信制御部４０１は、自治体サーバ１０に向けてデータを送信する。通信制御部４０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部４０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部４０１を介して他の装置とデータの送受信を行う。通信制御部４０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

生体情報取得部４０２は、カメラ装置（受付端末４０が備えるカメラ装置）を制御し、面前の避難者の生体情報（例えば、顔画像）を取得する手段である。生体情報取得部４０２は、定期的又は所定のタイミングにおいて自装置の前方を撮像する。生体情報取得部４０２は、取得した画像に人の顔画像が含まれるか否かを判定し、顔画像が含まれる場合には取得した画像データから顔画像を抽出する。

なお、生体情報取得部４０２による顔画像の検出処理や顔画像の抽出処理には既存の技術を用いることができるので詳細な説明を省略する。例えば、生体情報取得部４０２は、ＣＮＮ（Convolutional Neural Network）により学習された学習モデルを用いて、画像データの中から顔画像（顔領域）を抽出してもよい。あるいは、生体情報取得部４０２は、テンプレートマッチング等の手法を用いて顔画像を抽出してもよい。

生体情報取得部４０２は、抽出した顔画像を避難者来所通知部４０３に引き渡す。

避難者来所通知部４０３は、自治体サーバ１０に対して避難者の来所を通知する手段である。避難者来所通知部４０３は、取得した顔画像と避難所ＩＤを含む「避難者来所通知」を生成し、自治体サーバ１０に送信する。

避難所ＩＤは任意の手段により受付端末４０と自治体サーバ１０の間で共有される。例えば、システム管理者（防災センターの職員）が、各避難所に避難所ＩＤを割り当て、当該割り当てた避難所ＩＤを受付端末４０に設定すればよい。

記憶部４０４は、受付端末４０の動作に必要な情報を記憶する手段である。

［自治体サーバ］
図２３は、第２の実施形態に係る自治体サーバ１０の処理構成（処理モジュール）の一例を示す図である。図２３を参照すると、第１の実施形態に係る自治体サーバ１０の構成に住民避難先管理部２０５と患者避難先通知部２０６が追加されている。

住民避難先管理部２０５は、避難所に避難した住民を管理する手段である。住民避難先管理部２０５は、避難所に設置された受付端末４０から避難者来所通知を受信する。当該通知には、避難者の生体情報（顔画像）が含まれるので、住民避難先管理部２０５は当該顔画像を避難者来所通知から取り出す。住民避難先管理部２０５は、取得した顔画像から特徴量を生成する。

特徴量の生成処理に関しては既存の技術を用いることができるので、その詳細な説明を省略する。例えば、住民避難先管理部２０５は、顔画像から目、鼻、口等を特徴点として抽出する。その後、住民避難先管理部２０５は、特徴点それぞれの位置や各特徴点間の距離を特徴量として計算し、複数の特徴量からなる特徴ベクトル（顔画像を特徴づけるベクトル情報）を生成する。

住民避難先管理部２０５は、受付端末４０から取得した顔画像に基づき算出された特徴量を照合対象に設定し、住民情報データベースに登録された特徴量との間で照合処理を行う。より具体的には、住民避難先管理部２０５は、上記算出した特徴量（特徴ベクトル）を照合対象に設定し、住民情報データベースに登録されている複数の特徴量との間で１対Ｎ（Ｎは正の整数、以下同じ）照合を実行する。

住民避難先管理部２０５は、照合対象の特徴量と登録側の複数の特徴量それぞれとの間の類似度を計算する。当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。なお、距離が離れているほど類似度は低く、距離が近いほど類似度が高い。

住民避難先管理部２０５は、上記類似度が所定値以上であって、住民情報データベースに登録された特徴量のうち照合対象の特徴量に最も近い特徴量（類似度が最も高い特徴量）を特定する。住民避難先管理部２０５は、当該特定された特徴量に対応するエントリの避難所フィールドに避難所から通知された避難所ＩＤ（避難所の名称）を設定する。

住民避難先管理部２０５は、類似度が所定値以上の特徴量を持つエントリが住民情報データベースに登録されていなければ、避難所から通知された顔画像に対応する住民の住民登録はされていないと判定する。この場合、住民避難先管理部２０５は、特段の動作を行わなくてもよいし、住民登録をしていない利用者数を集計する等の統計処理を行ってもよい。

患者避難先通知部２０６は、かかりつけ病院が設定されている患者の避難先を病院に通知する手段である。患者避難先通知部２０６は、定期的又は所定のタイミングで住民情報データベースにアクセスする。患者避難先通知部２０６は、かかりつけ病院が設定され、かつ、避難所に避難している住民を抽出する。

患者避難先通知部２０６は、当該抽出された住民のかかりつけ病院に対して、患者の避難先に関する情報（避難所の名称、連絡先等）と患者ＩＤを含む患者避難先情報を送信する。なお、同じ住民について何度も避難先を病院に通知する必要はない。

［病院サーバ］
図２４は、第２の実施形態に係る病院サーバ２０の処理構成（処理モジュール）の一例を示す図である。図２４を参照すると、第１の実施形態に係る病院サーバ２０の構成に患者情報提供部３０５が追加されている。

患者情報提供部３０５は、自院の患者の避難先に関する情報を病院スタッフ（医師、看護師等）に提供する手段である。

患者避難先情報を受信すると、患者情報提供部３０５は、当該患者避難先情報に基づき「患者情報」を生成する。例えば、患者情報提供部３０５は、患者避難先情報に含まれる患者ＩＤから患者の氏名や電子カルテを特定する。患者情報提供部３０５は、患者の避難先に関する情報（避難所の名称、連絡先）、当該患者の氏名や電子カルテに記載された情報を含む患者情報を生成する。

患者情報提供部３０５は、生成した患者情報を病院サーバ２０に接続された液晶モニター等に表示する。あるいは、患者情報提供部３０５は、生成された患者情報を医師や看護師等が使用する医師端末、看護師端末に送信してもよい。

［システムの動作］
続いて、第２の実施形態に係る防災システムの動作について説明する。図２５は、第２の実施形態に係る防災システムの動作の一例を示すシーケンス図である。

受付端末４０は、避難者を検出すると、当該避難者の生体情報（顔画像）を取得する。受付端末４０は、取得した顔画像を含む避難者来所通知を自治体サーバ１０に送信する（ステップＳ１１）。

避難者来所通知を受信した自治体サーバ１０は、避難者の生体情報を用いた照合処理により避難者を特定する（ステップＳ１２）。自治体サーバ１０は、特定した避難者の避難先を住民情報データベースに登録する。

避難者にかかりつけ病院が設定されていれば、自治体サーバ１０は、患者避難先情報を生成し、かかりつけ病院の病院サーバ２０に送信する（ステップＳ１３）。

病院サーバ２０は、患者避難先情報に基づき、避難所に避難している患者に関する患者情報（避難所に関する情報、患者の電子カルテを含む情報）を生成する（ステップＳ１４）。

病院サーバ２０は、生成した患者情報を病院の医師、看護師等に提供する（ステップＳ１５）。

以上のように、第２の実施形態に係る、各避難所に設置された受付端末４０は、来所した避難者の生体情報を含む避難者来所通知を自治体サーバ１０に送信する。自治体サーバ１０は、避難者来所通知に含まれる生体情報を用いた照合処理により来所した避難者を特定する。自治体サーバ１０は、特定された住民のかかりつけ病院の病院サーバ２０に、来所した避難者の避難先を含む患者避難先情報を送信する。かかりつけ病院の医師等は、自院の患者が避難している場所を知ることができ、当該避難先の検討、検証を行うことができる。例えば、患者の避難先が不適当と判断すれば、かかりつけ病院の医師等は、避難所に連絡し、当該患者を自院に招く等の対応が可能となる。

［第３の実施形態］
続いて、第３の実施形態について図面を参照して詳細に説明する。

第３の実施形態においても、第２の実施形態と同様に、避難後のデータ活用について説明する。具体的には、避難所で医師が患者（避難者）を診断する際、必要な情報を病院から取得する場合について説明する。

以下、第１乃至第３の実施形態の相違点を中心に説明する。

図２６に示すように、第３の実施形態に係る防災システムの全部又は一部の避難所は、医師等が使用する医療端末５０を備える。医療端末５０は、医師が視認可能な表示デバイスと、患者が視認可能な表示デバイスと、を備える。また、患者が視認可能な表示デバイスにはカメラが設置されており、患者の顔を撮影可能に構成されている。

医師が常駐している避難所（上記の例では、避難所Ａ）に避難した避難者は、定期的又は所定のタイミングで、医師の診断を受けることができる。

医師は、医療端末５０を用いて診断を行う。医師は、医療端末５０を操作して、面前の避難者（患者）に関する電子カルテを確認する。その際、医療端末５０は、面前の患者の生体情報（例えば、顔画像）を取得する。医療端末５０は、取得した顔画像を含む認証要求を自治体サーバ１０に送信する。

自治体サーバ１０は、認証要求に含まれる生体情報を用いた認証処理により患者を特定する。認証に成功すると、自治体サーバ１０は、特定した患者の病院情報（かかりつけ病院の病院名と患者ＩＤ）を医療端末５０に送信する。

医療端末５０は、病院名からかかりつけ病院を特定し、当該特定したかかりつけ病院の病院サーバ２０に対して、患者ＩＤを含む「電子カルテ提供要求」を送信する。

病院サーバ２０は、電子カルテ提供要求に含まれる患者ＩＤをキーとして患者情報データベースを検索し、患者を特定する。病院サーバ２０は、当該特定した患者のカルテＩＤに基づき電子カルテを特定し、その内容を読み出す。

病院サーバ２０は、読み出した電子カルテを含む応答（電子カルテ提供要求に対する応答）を医療端末５０に送信する。

医療端末５０は、受信した電子カルテを表示する。医師は、電子カルテを確認しつつ、患者の診断を行う。

第３の実施形態に係る各装置の処理構成について説明する。

［医療端末］
図２７は、医療端末５０の処理構成（処理モジュール）の一例を示す図である。図２７を参照すると、医療端末５０は、通信制御部５０１と、生体情報取得部５０２と、認証要求部５０３と、電子カルテ取得部５０４と、記憶部５０５と、を備える。

通信制御部５０１は、他の装置との間の通信を制御する手段である。具体的には、通信制御部５０１は、自治体サーバ１０からデータ（パケット）を受信する。また、通信制御部５０１は、自治体サーバ１０に向けてデータを送信する。通信制御部５０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部５０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部５０１を介して他の装置とデータの送受信を行う。通信制御部５０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

生体情報取得部５０２は、カメラ装置を制御し、面前の避難者の生体情報（例えば、顔画像）を取得する手段である。生体情報取得部５０２は、医師等の操作に応じて、面前の住民（患者）の顔画像を取得する。その際、生体情報取得部５０２は、患者の顔画像を取得すること及び顔画像の取得目的を表示しつつ、患者の同意を得るようなＧＵＩを表示してもよい。例えば、生体情報取得部５０２は、図２８に示すようなＧＵＩを表示してもよい。

患者（避難者）の同意の下、患者の顔画像を取得すると、生体情報取得部５０２は、当該取得した顔画像を認証要求部５０３に引き渡す。

認証要求部５０３は、自治体サーバ１０に対して患者に関する認証を要求する手段である。認証要求部５０３は、取得した顔画像を含む認証要求を生成し、自治体サーバ１０に向けて送信する。

認証要求部５０３は、自治体サーバ１０から認証結果（認証成功、認証失敗）を受信する。認証結果が認証失敗であれば、認証要求部５０３は、その旨を医師及び患者に通知する。その際、認証要求部５０３は、「防災センターに住民登録がされておらず電子カルテが取得できません。」といったメッセージ等を表示する。

認証結果が認証成功であれば、認証要求部５０３は、認証結果（病院情報を含む肯定応答）を電子カルテ取得部５０４に引き渡す。

電子カルテ取得部５０４は、病院情報に含まれる患者ＩＤを取り出す。電子カルテ取得部５０４は、当該取り出した患者ＩＤを含む電子カルテ提供要求を病院サーバ２０（病院情報に含まれる病院の病院サーバ２０）に送信する。

電子カルテ取得部５０４は、病院サーバ２０から電子カルテを取得すると、当該取得した電子カルテを医師が視認可能な表示デバイスに表示する。

記憶部５０５は、医療端末５０の動作に必要な情報を記憶する手段である。

［自治体サーバ］
図２９は、第３の実施形態に係る自治体サーバ１０の処理構成（処理モジュール）の一例を示す図である。図２９を参照すると、第１の実施形態に係る自治体サーバ１０に認証部２０７が追加されている。

認証部２０７は、医療端末５０から受信した認証要求を処理する手段である。認証部２０７は、認証要求から取り出した生体情報と住民情報データベースに予め記憶された複数の住民それぞれの生体情報を用いた生体認証を行う。

認証部２０７は、認証要求に含まれる生体情報（顔画像）を取り出す。認証部２０７は、取り出した顔画像から特徴量を算出する。認証部２０７は、顔画像に基づき算出された特徴量を照合対象に設定し、住民情報データベースに登録された特徴量との間で照合処理を行う。認証部２０７は、照合対象の特徴量と登録側の複数の特徴量それぞれとの間の類似度を計算する。

認証部２０７は、住民情報データベースに登録された複数の特徴量のうち、照合対象の特徴量との間の類似度が所定の値以上の特徴量が存在しなければ、被認証者の認証に失敗したと判定する。

認証に失敗した場合には、認証部２０７は、その旨（認証失敗）を認証要求の送信元である医療端末５０に通知する。認証部２０７は、認証失敗を示す否定応答を医療端末５０に送信する。

照合対象の特徴量との間の類似度が所定の値以上の特徴量が住民情報データベースに登録されていれば、認証部２０７は、照合対象の特徴量に最も近い特徴量（エントリ）を特定する。

認証部２０７は、特定したエントリに病院情報が設定されていれば、認証に成功したと判定する。認証部２０７は、特定したエントリに病院情報が設定されていなければ、認証に失敗したと判定する。

認証に成功した場合、認証部２０７は、特定されたエントリの病院情報（かかりつけ病院名、患者ＩＤ）を含む肯定応答を医療端末５０に送信する。

［病院サーバ］
図３０は、第３の実施形態に係る病院サーバ２０の処理構成（処理モジュール）の一例を示す図である。図３０を参照すると、第１の実施形態に係る病院サーバ２０の構成に電子カルテ提供部３０６が追加されている。

電子カルテ提供部３０６は、患者の電子カルテに記載された情報を避難所（医療端末５０）に提供する手段である。

電子カルテ提供要求を受信すると、電子カルテ提供部３０６は、当該電子カルテ提供要求に含まれる患者ＩＤをキーとして患者情報データベースを検索し、対応するカルテＩＤを特定する。電子カルテ提供部３０６は、当該特定されたカルテＩＤに対応する電子カルテを取得する。

電子カルテ提供部３０６は、取得した電子カルテを医療端末５０に送信する。

［システムの動作］
続いて、第３の実施形態に係る防災システムの動作について説明する。図３１は、第３の実施形態に係る防災システムの動作の一例を示すシーケンス図である。

医師による診断の際、医療端末５０は、避難者の同意の下、当該避難者の生体情報を取得する。医療端末５０は、取得した生体情報を含む認証要求を自治体サーバ１０に送信する（ステップＳ２１）。

認証要求を受信すると、自治体サーバ１０は、当該認証要求の生体情報と住民情報データベースに登録された生体情報を用いた認証処理を実行する（ステップＳ２２）。

認証に成功すると、自治体サーバ１０は、認証成功者（認証成功と判定された被認証者；医療端末５０の前の避難者）の病院情報を医療端末５０に送信する（ステップＳ２３）。

医療端末５０は、病院情報から患者ＩＤを取り出し、当該取り出した患者ＩＤを含む電子カルテ提供要求を病院情報に記載された病院（病院サーバ２０）に送信する（ステップＳ２４）。

病院サーバ２０は、患者ＩＤに対応する電子カルテを読み出し、医療端末５０に送信する（ステップＳ２５）。

＜第３の実施形態の変形例＞
第３の実施形態では、医療端末５０は、自治体サーバ１０から病院情報を取得し、患者の電子カルテを病院サーバ２０から取得することを説明した。しかし、医療端末５０は、病院サーバ２０から直接電子カルテを取得することもできる。

この場合、住民は、自身の生体情報（例えば、顔画像）をかかりつけ病院の病院サーバ２０に登録しておく。病院サーバ２０は、顔画像から特徴量を生成し、当該特徴量（生体情報）を患者ＩＤ等と対応付けて患者情報データベースに記憶する。

医師は、かかりつけ病院を患者（避難者）から聞き出し、医療端末５０に入力する。医療端末５０は、患者の生体情報（顔画像）を取得する。医療端末５０は、当該生体情報を含む電子カルテ提供要求を上記入力された病院の病院サーバ２０に送信する。

病院サーバ２０は、生体認証によって患者を特定し、対応する電子カルテを読み出す。病院サーバ２０は、読み出した電子カルテを医療端末５０に送信する。

なお、この場合の病院サーバ２０は、内部に「認証部」を備えていればよい。当該認証部の動作は、自治体サーバ１０の認証部２０７の動作と同一とすることができるので、詳細な説明を省略する。

なお、第３の実施形態においても第１の実施形態と同様に、電子カルテの情報が病院サーバ２０と医療端末５０の間でデータ共有されてもよい。即ち、患者は、医療端末５０へのデータ共有に関する許諾を病院サーバ２０に設定してもよい。例えば、データ共有の目的として「避難所での診察」、共有データの種類として「電子カルテ」、データ共有先として「医療端末（避難所）」、データ共有時の条件として「医師による診察」といった内容が設定されてもよい。この場合、医療端末５０は、電子カルテに関するデータ共有要請を病院サーバ２０に送信すればよい。

以上のように、第３の実施形態に係る防災システムは医療端末５０をさらに含む。医療端末５０は、被認証者の生体情報を含む認証要求を自治体サーバ１０に送信する。自治体サーバ１０は、認証要求に含まれる生体情報を用いて被認証者を特定すると共に、特定された被認証者のかかりつけ病院に関する情報を医療端末５０に送信する。医療端末５０は、かかりつけ病院に対して、被認証者の電子カルテの提供を要求する。このように、避難所に医師は、患者（避難者）の電子カルテを参照することができ、より確実な診療、診断を行うことができる。

また、第３の実施形態では、患者の生体情報を取得する際、電子カルテの情報を共有することに対する患者の同意を得ることができる。即ち、本願開示では、自治体等の団体と共有する情報と、医師間で共有する情報と、を適切に分離することで、利用者のプライバシー保護と利用者の利便性の両立を図っている。

続いて、防災システムを構成する各装置のハードウェアについて説明する。図３２は、自治体サーバ１０のハードウェア構成の一例を示す図である。

自治体サーバ１０は、情報処理装置（所謂、コンピュータ）により構成可能であり、図３２に例示する構成を備える。例えば、自治体サーバ１０は、プロセッサ３１１、メモリ３１２、入出力インターフェイス３１３及び通信インターフェイス３１４等を備える。上記プロセッサ３１１等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。

但し、図３２に示す構成は、自治体サーバ１０のハードウェア構成を限定する趣旨ではない。自治体サーバ１０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス３１３を備えていなくともよい。また、自治体サーバ１０に含まれるプロセッサ３１１等の数も図３２の例示に限定する趣旨ではなく、例えば、複数のプロセッサ３１１が自治体サーバ１０に含まれていてもよい。

プロセッサ３１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）等のプログラマブルなデバイスである。あるいは、プロセッサ３１１は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等のデバイスであってもよい。プロセッサ３１１は、オペレーティングシステム（ＯＳ；Operating System）を含む各種プログラムを実行する。

メモリ３１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。メモリ３１２は、ＯＳプログラム、アプリケーションプログラム、各種データを格納する。

入出力インターフェイス３１３は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。

通信インターフェイス３１４は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス３１４は、ＮＩＣ（Network Interface Card）等を備える。

自治体サーバ１０の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３１２に格納されたプログラムをプロセッサ３１１が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transitory）なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。

なお、病院サーバ２０、端末３０、受付端末４０、医療端末５０も自治体サーバ１０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は自治体サーバ１０と相違する点はないので説明を省略する。例えば、受付端末４０、医療端末５０は、被認証者を撮影するためのカメラ装置を備えていればよい。

情報処理装置である自治体サーバ１０は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで自治体サーバ１０の機能が実現できる。また、自治体サーバ１０は、当該プログラムにより自治体サーバ１０の制御方法を実行する。

［変形例］
なお、上記実施形態にて説明した防災システムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。

上記実施形態では、医師による電子カルテのシステム入力について説明していないが、当該電子カルテのシステム入力は対面での診断時に行われてもよいし、オンライン診療時に行われてもよい。即ち、電子カルテは任意の方法によってシステムに入力されればよい。

上記実施形態では、自治体サーバ１０は、かかりつけ病院から各住民の健康情報を取得する場合について説明した。しかし、自治体サーバ１０は、住民自身又は住民の家族から当該健康情報を取得してもよい。具体的には、住民は、住民登録の際に健康情報も併せてシステム（自治体サーバ１０）に登録してもよい。即ち、本願開示の防災システムは、電子カルテに記載された健康情報を用いてもよいし、住民が自己申告した健康情報を用いてもよい。

上記実施形態では、主に現症（現在の病気）に基づいて避難所を選択する場合について説明したが、既往症に基づいて避難所が選択されてもよいことは勿論である。あるいは、現症及び既往症に基づいて避難所が選択されてもよい。あるいは、病院サーバ２０から「現症」と「既往症」が取得できた場合（データ共有できた場合）、いずれの情報を優先して避難所を決定するか予め決められていてもよい。

自治体サーバ１０は、避難情報を生成する際、図１４、図１５に示すような避難情報だけでなく、住民の住宅から避難所までの経路を含むような避難情報を生成してもよい（図３３参照）。自治体サーバ１０は、住民の自宅を始点、選択された避難所を終点に設定し、経路を計算して避難情報に含めてもよい。あるいは、図３３に示すように、自治体サーバ１０は、提案した避難所の種類、特徴等を含む避難情報を生成してもよい。

自治体サーバ１０は、住民情報データベースを参照し、防災担当者にとって有益な情報を提供してもよい。例えば、自治体サーバ１０は、各住民の服薬情報と避難先の情報から避難所ごとに必要とされる薬の総量を計算する。自治体サーバ１０は、計算した総量を防災担当者に提示する。あるいは、自治体サーバ１０は、製薬会社等に計算した薬の配送等を依頼してもよい。このように、自治体サーバ１０は、避難所ごとに避難者の属性が把握できるので、薬の配送を先回りして準備する等の対応が行える。

自治体サーバ１０は、避難情報の送信対象が「避難行動要支援者」である場合には、当該要支援者の支援者に対しても避難情報を送信してもよい。即ち、要支援者と支援者で避難情報（避難先）が共有されてもよい。

複数のかかりつけ病院を持つ住民は、当該複数のかかりつけ病院に関する病院情報を自治体サーバ１０に入力してもよい。この場合、自治体サーバ１０は、各病院サーバ２０に対してデータ共有要請を送信してもよいし、住民や病院の属性に応じて優先度を設定してもよい。例えば、内科専門の病院と外科専門の病院の２つがかかりつけ病院として設定されている場合には、自治体サーバ１０は、内科専門の病院を優先してデータ共有先としてもよい。

上記実施形態では、データ共有要請に住民の患者ＩＤを設定する場合について説明した。しかし、患者ＩＤが設定されていない住民に関しては、自治体サーバ１０は、当該住民の氏名等を患者ＩＤの代わりに設定しもよい。

上記実施形態では、病院サーバ２０に避難所案内を目的するデータ共有許諾が設定される場合について説明した。しかし、病院サーバ２０にはデータ共有に関する他の目的が設定されてもよい。例えば、保険料算出を目的としたデータ共有許諾が病院サーバ２０に設定されてもよい。この場合、例えば、保険会社がデータ共有先となる。

あるいは、病院サーバ２０は、住民の選択した目的に応じて、当該住民が選択可能なデータ種類を変更してもよい。例えば、上記実施形態で説明したように、避難所案内が目的の場合には、「既往症」、「現症」、「服薬情報」がデータ共有の候補として表示され、保険料算出の目的の場合には、「服薬情報」はデータ共有の候補として表示されなくともよい。

上記実施形態では、データ共有時の条件として「避難指示発令（避難指示以上発令）」のように警戒レベルに応じた条件を設定する場合について説明した。しかし、住民の理解しやすいように、病院サーバ２０は、「避難情報発令時」のような選択肢や「大雨、台風によって災害発生が予想される時」のような選択肢を用意してもよい。

自治体サーバ１０は、住民の健康情報によっては避難所に避難するよりも病院に搬送した方がよいと判断することもできる。この場合、自治体サーバ１０は、当該住民の下に緊急車両を手配するような対応をしてもよい。

あるいは、自治体サーバ１０は、住民の健康情報によって避難所に避難するべきか否か判断できない場合には、病院情報に記載された病院に当該住民の処遇を問い合わせてもよい。

上記実施形態では、防災担当者は、警戒レベルと避難情報の送信対象地域を自治体サーバ１０に入力する場合について説明した。しかし、防災担当者は、データ共有に関する「ポリシ」も併せて自治体サーバ１０に入力してもよい。防災担当者は、予想される災害の種類や規模等に応じて、入力するポリシ（データ共有によって取得するデータ種類）を決定してもよい。

自治体サーバ１０は、住民に案内可能な避難所が複数存在する場合には、住民の現在位置や住宅の位置に基づいて案内する避難所を選択してもよい。具体的には、自治体サーバ１０は、住民に適した避難所のうち当該住民に最も近い避難所を選択し、案内をしてもよい。

第２の実施形態では、受付端末４０が避難者来所通知を自治体サーバ１０に送信することを説明した。しかし、当該通知は避難所に設置された監視カメラ等が送信してもよい。

第２の実施形態では、生体情報を用いて住民を特定する場合について説明した。しかし、住民を特定する手段は他の方法、手段であってもよい。例えば、マイナンバーカードに記載された電子証明書を使った本人認証が用いられてもよい。あるいは、ＩＤとパスワードを用いたパスワード認証が用いられてもよい。あるいは、自治体サーバ１０は、住民登録の際に生成された住民ＩＤを住民に払い出し、当該払い出された住民ＩＤが受付端末４０に提示されてもよい。例えば、端末３０は、住民登録された際に発行された住民ＩＤを２次元コードに変換し、住民は端末３０を操作して、当該２次元コードを受付端末４０に提示することで住民の特定が行われてもよい。

上記実施形態では、自治体サーバ１０の内部に住民情報データベースや避難所情報データベースが構成される場合について説明したが、これらのデータベースは外部のデータベースサーバ等に構築されてもよい。即ち、自治体サーバ１０の一部の機能は別のサーバに実装されていてもよい。より具体的には、上記説明した「住民登録部（住民登録手段）」、「避難情報制御部（避難情報制御手段）」等がシステムに含まれるいずれかの装置に実装されていればよい。

上記実施形態では、かかりつけ病院が設定されている住民に関しては、その健康状態を確認し、医師等が常駐している避難所に案内する（案内する可能性がある）ことを説明した。しかし、かかりつけ病院が設定されていなく健康状態が不明な場合には、住民の年齢等を考慮して、大事をとって当該住民の避難先として医師や看護師が常駐している避難所が案内されてもよい。

自治体サーバ１０は、住民登録の際、住民の身元を確認してもよい。具体的には、自治体サーバ１０は、住民の生体情報、個人情報等と共に、生体情報が記載された身元確認書類（例えば、パスポート、免許証等）を取得する。自治体サーバ１０は、身元確認書類の生体情報と住民から取得した生体情報を用いた１対１照合を実行する。自治体サーバ１０は、当該照合に成功した場合に、住民登録を行ってもよい。

各装置（自治体サーバ１０、病院サーバ２０等）間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。これらの装置間では、患者の電子カルテ等が送受信され、これらの情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。

上記説明で用いた流れ図（フローチャート、シーケンス図）では、複数の工程（処理）が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。

上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、住民の避難を支援する防災システムなどに好適に適用可能である。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する、生成部と、
前記生成された避難情報を前記住民が所持する端末に送信する、送信部と、
を備える、サーバ装置。
［付記２］
前記住民のかかりつけ病院から前記健康情報を取得する、取得部をさらに備える、付記１に記載のサーバ装置。
［付記３］
前記取得部は、前記かかりつけ病院の病院サーバに対して前記健康情報に関するデータ共有要請を送信することで、前記健康情報を取得する、付記２に記載のサーバ装置。
［付記４］
前記生成部は、前記住民の健康状態に適合する避難所を選択し、前記選択された避難所に関する情報を含む前記避難情報を生成する、付記１乃至３のいずれか一項に記載のサーバ装置。
［付記５］
前記生成部は、前記健康情報に基づいて健康に不安があると判定された前記住民に関しては、医師又は看護師が常駐する避難所、又は、医療設備を備える避難所を選択する、付記４に記載のサーバ装置。
［付記６］
前記住民のかかりつけ病院に関する情報を記憶する、記憶部をさらに備える、付記１乃至５のいずれか一項に先のサーバ装置。
［付記７］
複数の住民うち防災担当者により指定された地域に住む住民を選択し、前記選択された住民が所持する端末に対して、避難情報を送信する、自治体サーバと、
病院サーバと、
を含み、
前記自治体サーバは、前記選択された住民の健康情報をデータ共有により前記病院サーバから取得し、前記取得された健康情報に基づいて、前記選択された住民に案内する避難所を選択する、システム。
［付記８］
前記病院サーバは、患者の電子カルテに記載されたデータのうち少なくとも一部が前記自治体サーバと前記データ共有されることに関する共有許諾情報を記憶する、付記７に記載のシステム。
［付記９］
前記自治体サーバは、利用目的、データの種類及び共有先を含むデータ共有要請を前記病院サーバに送信する、付記８に記載のシステム。
［付記１０］
前記病院サーバは、前記共有許諾情報を用いて前記データ共有要請を検証し、前記データ共有要請の検証に成功した場合に、前記患者が許諾したデータの種類に対応するデータを前記電子カルテから読み出し、前記読み出したデータを前記健康情報として前記自治体サーバに通知する、付記９に記載のシステム。
［付記１１］
前記共有許諾情報は、前記データ共有の目的、共有するデータの種類、データの共有先及び前記データ共有時の条件のそれぞれに関する情報を含む、付記１０に記載のシステム。
［付記１２］
前記避難所に設置された受付端末をさらに含み、
前記受付端末は、来所した避難者の生体情報を含む避難者来所通知を前記自治体サーバに送信し、
前記自治体サーバは、前記避難者来所通知に含まれる生体情報を用いた照合処理により前記来所した避難者を特定し、前記特定された住民のかかりつけ病院の前記病院サーバに、前記来所した避難者の避難先を含む患者避難先情報を送信する、付記７に記載のシステム。
［付記１３］
前記避難所に設置された医療端末をさらに含み、
前記医療端末は、被認証者の生体情報を含む認証要求を前記自治体サーバに送信し、
前記自治体サーバは、前記認証要求に含まれる生体情報を用いて前記被認証者を特定すると共に、前記特定された被認証者のかかりつけ病院に関する情報を前記医療端末に送信し、
前記医療端末は、前記かかりつけ病院に対して、前記被認証者の電子カルテの提供を要求する、付記７に記載のシステム。
［付記１４］
サーバ装置において、
住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成し、
前記生成された避難情報を前記住民が所持する端末に送信する、サーバ装置の制御方法。
［付記１５］
サーバ装置に搭載されたコンピュータに、
住民の健康情報に基づいて、前記住民に案内する避難所に関する情報を含む避難情報を生成する処理と、
前記生成された避難情報を前記住民が所持する端末に送信する処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。

なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。

１０ 自治体サーバ
２０ 病院サーバ
３０ 端末
４０ 受付端末
５０ 医療端末
１００ サーバ装置
１０１ 生成部
１０２ 送信部
２０１ 通信制御部
２０２ 住民登録部
２０３ 避難情報制御部
２０４ 記憶部
２０５ 住民避難先管理部
２０６ 患者避難先通知部
２０７ 認証部
２１１ 送信指示取得部
２１２ 対象住民選択部
２１３ 共有データ取得部
２１４ 避難情報生成部
３０１ 通信制御部
３０２ 許諾情報取得部
３０３ 共有制御部
３０４ 記憶部
３０５ 患者情報提供部
３０６ 電子カルテ提供部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０１ 通信制御部
４０２ 生体情報取得部
４０３ 避難者来所通知部
４０４ 記憶部
５０１ 通信制御部
５０２ 生体情報取得部
５０３ 認証要求部
５０４ 電子カルテ取得部
５０５ 記憶部

Claims (2)

1. 複数の住民うち防災担当者により指定された地域に住む住民を選択し、前記選択された住民が所持する端末に対して、避難情報を送信する、自治体サーバと、
   病院サーバと、
   を含み、
   前記自治体サーバは、前記選択された住民の健康情報をデータ共有により前記病院サーバから取得し、前記取得された健康情報に基づいて、前記選択された住民に案内する避難所を選択する、システム。
2. 前記病院サーバは、患者の電子カルテに記載されたデータのうち少なくとも一部が前記自治体サーバと前記データ共有されることに関する共有許諾情報を記憶する、請求項１に記載のシステム。

Images