WO2022249434A1 - サーバ装置、システム、サーバ装置の制御方法及び記憶媒体 - Google Patents

サーバ装置、システム、サーバ装置の制御方法及び記憶媒体 Download PDF

Info

Publication number
WO2022249434A1
WO2022249434A1 PCT/JP2021/020332 JP2021020332W WO2022249434A1 WO 2022249434 A1 WO2022249434 A1 WO 2022249434A1 JP 2021020332 W JP2021020332 W JP 2021020332W WO 2022249434 A1 WO2022249434 A1 WO 2022249434A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
evacuation
server
residents
hospital
Prior art date
Application number
PCT/JP2021/020332
Other languages
English (en)
French (fr)
Inventor
哲也 冬野
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to JP2023523896A priority Critical patent/JPWO2022249434A5/ja
Priority to PCT/JP2021/020332 priority patent/WO2022249434A1/ja
Publication of WO2022249434A1 publication Critical patent/WO2022249434A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Definitions

  • the present invention relates to a server device, a system, a server device control method, and a storage medium.
  • Patent Document 1 describes a function that provides disaster victims, including residents, with information on shelters that match their individual circumstances, guides them to the most suitable shelter, or allows each person to decide where to evacuate. It is described that it provides a disaster shelter information provision system equipped with.
  • the system of Patent Literature 1 includes a shelter information providing server.
  • the server includes a registration processor and a query processor.
  • the registration processing unit stores the user's resident information at the time of disaster, including information on priority items when searching for shelter information, as disaster resident information. Register in the database.
  • the inquiry processing unit searches for evacuation center information based on the resident information at the time of the disaster, and provides the evacuation center information to the user.
  • Patent Document 2 describes providing a server that supports telemedicine, and that enables smooth processes of sharing prescriptions from medical institutions to pharmacies and receiving medicines from patients. It is
  • Patent Document 1 is limited to selecting residents who preferentially evacuate.
  • Patent Document 2 relates to online medical care and has nothing to do with the choice of shelter by residents.
  • the main purpose of the present invention is to provide a server device, a system, a server device control method, and a storage medium that contribute to guiding residents to suitable evacuation shelters.
  • a generator that generates evacuation information including information about a shelter to be guided to the residents based on health information of the residents;
  • a server device comprising: a transmitting unit for transmitting to a possessed terminal.
  • a municipality selects residents living in an area designated by a person in charge of disaster prevention from among a plurality of residents, and transmits evacuation information to a terminal possessed by the selected residents.
  • a server and a hospital server wherein the local government server acquires the health information of the selected residents from the hospital server by data sharing, and based on the acquired health information, provides the selected residents with A system is provided for selecting a shelter to guide.
  • evacuation information including information regarding a shelter to be guided to the residents is generated based on the residents' health information, and the residents receive the generated evacuation information.
  • a method for controlling a server device is provided, which transmits to a possessed terminal.
  • a computer installed in a server device generates evacuation information including information about a shelter to which the residents are guided based on the health information of the residents;
  • a computer-readable storage medium is provided for storing a program for executing a process of transmitting the evacuation information to the terminal owned by the resident.
  • a server device a system, a server device control method, and a storage medium that contribute to guiding residents to suitable evacuation shelters are provided.
  • the effect of this invention is not limited above. Other effects may be achieved by the present invention instead of or in addition to this effect.
  • FIG. 1 is a diagram for explaining an overview of one embodiment.
  • FIG. 2 is a diagram showing an example of a schematic configuration of the disaster prevention system according to the first embodiment.
  • FIG. 3 is a diagram for explaining the operation of the disaster prevention system according to the first embodiment.
  • FIG. 4 is a diagram for explaining the operation of the disaster prevention system according to the first embodiment.
  • FIG. 5 is a diagram for explaining the operation of the disaster prevention system according to the first embodiment.
  • FIG. 6 is a diagram for explaining the operation of the disaster prevention system according to the first embodiment.
  • 7 is a diagram illustrating an example of a processing configuration of a local government server according to the first embodiment;
  • FIG. FIG. 8 is a diagram for explaining the operation of the resident registration unit according to the first embodiment;
  • FIG. 9 is a diagram showing an example of a resident information database according to the first embodiment.
  • 10 is a diagram illustrating an example of a processing configuration of an evacuation information control unit according to the first embodiment
  • FIG. 11 is a flowchart illustrating an example of the operation of an evacuation information control unit according to the first embodiment
  • FIG. 12 is a diagram for explaining the operation of the evacuation information control unit according to the first embodiment
  • FIG. 13 is a diagram showing an example of a shelter information database according to the first embodiment.
  • 14 is a diagram for explaining the operation of the evacuation information control unit according to the first embodiment
  • FIG. 15 is a diagram for explaining the operation of the evacuation information control unit according to the first embodiment
  • FIG. 15 is a diagram for explaining the operation of the evacuation information control unit according to the first embodiment
  • FIG. 16 is a diagram illustrating an example of a processing configuration of a hospital server according to the first embodiment
  • FIG. FIG. 17 is a diagram showing an example of a patient information database according to the first embodiment
  • 18 is a diagram for explaining the operation of the sharing control unit according to the first embodiment
  • FIG. 19 is a sequence diagram illustrating an example of the operation of the disaster prevention system according to the first embodiment
  • FIG. FIG. 20 is a diagram showing an example of a resident information database according to the second embodiment.
  • FIG. 21 is a diagram showing an example of a schematic configuration of a disaster prevention system according to the second embodiment.
  • 22 is a diagram illustrating an example of a processing configuration of a reception terminal according to the second embodiment;
  • FIG. 23 is a diagram illustrating an example of a processing configuration of a local government server according to the second embodiment
  • FIG. FIG. 24 is a diagram illustrating an example of a processing configuration of a hospital server according to the second embodiment
  • FIG. 25 is a sequence diagram showing an example of the operation of the disaster prevention system according to the second embodiment.
  • FIG. 26 is a diagram for explaining the third embodiment.
  • 27 is a diagram illustrating an example of a processing configuration of a medical terminal according to the third embodiment
  • FIG. FIG. 28 is a diagram for explaining the operation of the biometric information acquiring unit according to the third embodiment
  • 29 is a diagram illustrating an example of a processing configuration of a local government server according to the third embodiment;
  • FIG. 30 is a diagram illustrating an example of a processing configuration of a hospital server according to the third embodiment
  • FIG. 31 is a sequence diagram showing an example of the operation of the disaster prevention system according to the third embodiment
  • 32 is a diagram illustrating an example of a hardware configuration of a local government server according to the disclosure of the present application
  • FIG. 33 is a diagram for explaining the operation of the local government server according to the modification of the disclosure of the present application.
  • a server device 100 includes a generation unit 101 and a transmission unit 102 (see FIG. 1).
  • the generation unit 101 generates evacuation information including information about evacuation centers to which the residents are guided, based on the residents' health information.
  • the transmission unit 102 transmits the generated evacuation information to the terminal owned by the residents.
  • the server device 100 selects an evacuation center in consideration of the health condition of the residents, and sends information about the selected evacuation center (for example, the name and location of the evacuation center) to the residents. to notify. For example, the server device 100 selects an evacuation center that does not have special facilities for residents who are not concerned about their health condition, and guides them to the evacuation center using the evacuation information. On the other hand, for residents who are concerned about their health, the server device 100 selects an evacuation center where doctors and nurses are stationed or an evacuation center with medical facilities, and uses the evacuation information to select the evacuation center. invite. In this way, the server device 100 can guide residents living in the area to which the evacuation information is transmitted to suitable evacuation centers.
  • the server device 100 selects an evacuation center in consideration of the health condition of the residents, and sends information about the selected evacuation center (for example, the name and location of the evacuation center) to the residents. to notify. For example, the server device 100 selects an evacuation center that does not have special facilities for residents who are not concerned about their health condition, and guides them to the evacuation center
  • FIG. 2 is a diagram showing an example of a schematic configuration of the disaster prevention system according to the first embodiment.
  • the disaster prevention system includes a disaster prevention center, at least one or more hospitals, and at least one or more shelters.
  • the disaster prevention center is managed and operated by local governments.
  • the disaster prevention center is installed, for example, in a city hall or the like.
  • Facilities such as schools and public halls in each region correspond to evacuation centers.
  • Facilities such as schools and public halls are used as "evacuation centers" in the event of a disaster.
  • the disaster prevention center operates and manages the local government server 10.
  • the local government server 10 is a server device that manages disaster prevention for local residents, manages shelters, supports evacuees, and the like.
  • the local government server 10 may be installed in the same building as the building in which the disaster prevention center is installed, or may be installed on the network (on the cloud).
  • Each hospital has a hospital server 20.
  • the hospital server 20 stores patient medical care results (diagnosis results, treatment results).
  • the hospital server 20 stores the patient's medical examination results and the like as an "electronic chart”.
  • the hospital server 20 centrally manages patient's basic information, medical care information on medical treatment, vital data, medication information on medication, and the like by means of electronic charts.
  • the patient's basic information includes information on patient ID (IDentifier), name, date of birth, address, contact information, past diseases, etc.
  • the medical information includes information such as the patient's chief complaint (items to be entered in the medical questionnaire), test results (results of X-rays, etc.), diagnosis name (disease name confirmed by diagnosis; current condition), treatment policy, and the like.
  • Vital data includes information (measurement results, measurement history) on blood pressure, pulse, body temperature, and the like.
  • the medication information includes the name of the prescribed medication, instructions for taking medication (timing of medication, dosage), and the like.
  • Each device shown in FIG. 2 is interconnected.
  • the local government server 10 and the hospital server 20 are connected by wired or wireless communication means, and are configured to be able to communicate with each other.
  • a disaster prevention center may include multiple municipality servers 10 .
  • each hospital may include multiple hospital servers 20 .
  • evacuation information is sent from the disaster prevention center to each resident.
  • the evacuation information includes information about evacuation destinations (for example, names and locations of evacuation centers).
  • evacuation destinations for example, names and locations of evacuation centers.
  • the disaster prevention center confirms the situation and state of each resident, selects a suitable evacuation center for each resident, and urges them to evacuate.
  • the Disaster Prevention Center considers the residents' health conditions and decides which shelters to direct the residents to.
  • the disaster prevention center obtains "health information" of each resident from the hospital (the resident's family hospital) when deciding on the evacuation center. Based on the acquired health information, the disaster prevention center selects a shelter suitable for each resident and guides the resident.
  • the health information is specific information (data) regarding the health of each inhabitant. For example, as the health information, a resident's pre-existing disease, current disease, medication information, and the like are exemplified.
  • residents register their resident information in the municipality server 10 using any means. For example, a resident performs resident registration by operating the terminal 30 possessed by the resident. For example, a resident operates the terminal 30 to access the local government server 10 . More specifically, residents access a WEB page provided by the local government server 10 .
  • parents or children may register resident information on infants, the elderly, etc. in the municipality server 10 on behalf of the residents.
  • Resident information includes personal information (the so-called 4 basic information: name, gender, address, date of birth).
  • the resident information includes the resident's contact information (for example, an e-mail address, telephone number, etc. that can be received by the terminal 30).
  • resident information includes information about the family hospital (hereinafter simply referred to as hospital information).
  • hospital information includes the name of the family hospital, the patient ID issued by the family hospital, and the like.
  • the local government server 10 When the local government server 10 acquires personal information and hospital information from a resident, it generates a resident ID for identifying the resident. The local government server 10 associates the generated resident ID, personal information, hospital information, etc., and stores them in the resident information database. Details of the resident information database will be described later.
  • ⁇ Permission to share data residents who have family hospitals set permission for data sharing (providing data) from the hospital to the disaster prevention center (local government) before or after the resident registration.
  • the resident operates the terminal 30 to access the hospital server 20 of the family hospital (see FIG. 4). More specifically, residents access web pages provided by the hospital server 20 .
  • the hospital server 20 displays a GUI (Graphical User Interface) and an input form as shown in FIG. 5 on the terminal 30 owned by the residents.
  • GUI Graphic User Interface
  • a resident may select “evacuation center information” as the purpose of data sharing, “previous illnesses”, “current illnesses”, and “medication information” as types of shared data, “disaster prevention center” as the data sharing destination, and “ When an evacuation order or more is issued” is input to the hospital server 20.
  • the hospital server 20 manages the information regarding data sharing obtained from the residents as "sharing permission information”.
  • the hospital server 20 associates the patient ID of the resident, the ID of the electronic medical record (medical record ID), and the sharing permission information and stores them in the patient information database. Details of the patient information database will be described later.
  • ⁇ Send evacuation information> When a disaster is expected to occur due to a typhoon, heavy rain, or the like, the person in charge of disaster prevention in the local government inputs an "evacuation information transmission instruction" to the local government server 10 (step S1). For example, the person in charge of disaster prevention inputs an evacuation information transmission instruction to the local government server 10 together with the warning level.
  • the local government server 10 transmits "evacuation information" to local residents. For example, if the alert level is "5", the "evacuation information” corresponds to ensuring emergency safety, if the alert level is "4", evacuation instructions, and if the alert level is "3", the elderly and others are evacuated. Sent to local residents.
  • the municipality server 10 At that time, the municipality server 10 generates evacuation information suitable for each resident (optimized and personalized for each resident) and transmits the evacuation information to the terminal 30 possessed by each resident.
  • the local government server 10 When generating evacuation information, the local government server 10 acquires the health information of residents whose family hospital is set from the family hospital through data sharing. Specifically, the local government server 10 refers to the resident information database and determines whether or not a family hospital is set for the resident to whom the evacuation information is to be sent. If a family hospital is set, the local government server 10 transmits a "data sharing request" to the hospital server 20 of the hospital (step S2).
  • the local government server 10 refers to the resident information database and reads out the patient ID of the resident whose family hospital is set.
  • the local government server 10 transmits to the hospital server 20 a “data sharing request” including the read patient ID.
  • the data sharing request includes the "purpose of use” of the shared data, the "type” of the shared data, and the “shared destination” of the shared data.
  • “evacuation center guidance accompanying the issuance of an evacuation order” is set as the purpose of use of the shared data
  • "current illness” is set as the type of shared data
  • “disaster prevention center” is set as the shared data destination.
  • the hospital server 20 verifies the data sharing request received from the local government server 10.
  • the hospital server 20 that has received the data sharing request searches the patient information database using the patient ID included in the request as a key, and identifies the corresponding chart ID (electronic chart ID) and sharing permission information.
  • the hospital server 20 determines whether or not the "purpose of use” included in the received data sharing request matches the "purpose” and “conditions” included in the specified sharing permission information. Verifies whether or not it matches the "shared party" of the information.
  • the hospital server 20 determines that data sharing with the local government server 10 is possible.
  • the hospital server 20 reads data corresponding to the data type set in the sharing permission information from the corresponding patient's electronic medical record. For example, when data sharing regarding "current disease” is approved, specific disease names such as “stomach cancer” and “lung cancer” are read from the electronic chart.
  • the hospital server 20 transmits a "health information notification" including the patient ID of the patient (resident) whose data is to be shared and the read data (shared data) to the local government server 10 (step S3).
  • the local government server 10 refers to the health information acquired from the hospital server 20 and generates evacuation information suitable for residents (residents whose family hospital is set).
  • the local government server 10 determines that a family hospital is not set for resident A and that resident A is a resident with no health concerns, the local government server 10 guides resident A to shelter B as an evacuation destination. Generate evacuation information such as Shelter B is a normal shelter with no special equipment or personnel.
  • the local government server 10 determines that a family hospital is set for the resident B and that the resident B is a resident with health concerns, the local government server 10 guides the resident B to the evacuation center A as an evacuation destination. Generate evacuation information.
  • Evacuation center A is an evacuation center where doctors and nurses are stationed and medical facilities are substantial.
  • the local government server 10 transmits the generated evacuation information to the terminal 30 possessed by each resident (step S4).
  • Each resident confirms the evacuation information displayed on the terminal 30 and evacuates to the evacuation center described in the evacuation information.
  • FIG. 7 is a diagram showing an example of a processing configuration (processing modules) of the local government server 10 according to the first embodiment.
  • the local government server 10 includes a communication control section 201 , a resident registration section 202 , an evacuation information control section 203 and a storage section 204 .
  • the communication control unit 201 is means for controlling communication with other devices. For example, the communication control unit 201 receives data (packets) from the hospital server 20 . Also, the communication control unit 201 transmits data to the hospital server 20 . The communication control unit 201 transfers data received from other devices to other processing modules. The communication control unit 201 transmits data acquired from other processing modules to other devices. In this manner, other processing modules transmit and receive data to and from other devices via the communication control unit 201 .
  • the communication control unit 201 has a function as a receiving unit that receives data from another device and a function as a transmitting unit that transmits data to the other device.
  • the resident registration unit 202 is a means for realizing the above-described resident registration.
  • the resident registration unit 202 is means for acquiring resident information of each of a plurality of residents who may become evacuees in the future. More specifically, the resident registration unit 202 acquires resident information including hospital information by any means.
  • the resident registration unit 202 may acquire resident information from the terminal 30 operated by the resident.
  • the resident may send a document containing resident information or an external storage device storing the resident information to the disaster prevention center, and the staff of the center may input the resident information to the local government server 10 .
  • the resident registration unit 202 may provide residents with a GUI or an input form for entering resident information.
  • the resident registration unit 202 may display a GUI as shown in FIG. 8 on the terminal 30 of the resident.
  • the resident operates the terminal 30 and inputs the information shown in FIG.
  • the resident presses the “determine” button, and inputs personal information (name, contact information, etc.) and hospital information to the local government server 10 .
  • the resident registration unit 202 generates a resident ID for identifying residents.
  • the resident ID may be any information that can uniquely identify a registered resident.
  • the resident registration unit 202 may number a unique value for each resident registration and use it as a resident ID.
  • the resident registration unit 202 may acquire information corresponding to the resident ID (for example, identification information issued by a public institution) from the resident.
  • the resident registration unit 202 associates the generated resident ID, personal information, and hospital information and stores them in the resident information database (see FIG. 9).
  • the resident information database shown in FIG. 9 is an example, and is not meant to limit the items to be stored.
  • biometric information of residents for example, facial images and feature amounts generated from the facial images
  • the contact information such as the phone number of the family hospital may be registered in the resident information database.
  • the patient ID is identification information issued by the family hospital. For example, an ID written on a patient registration card or the like corresponds to the patient ID.
  • the evacuation information control unit 203 is means for controlling evacuation information. As shown in FIG. 10 , the evacuation information control section 203 includes submodules consisting of a transmission instruction acquisition section 211 , a target residents selection section 212 , a shared data acquisition section 213 and an evacuation information generation section 214 .
  • FIG. 11 is a flow chart showing an example of the operation of the evacuation information control unit 203 according to the first embodiment.
  • the transmission instruction acquisition unit 211 acquires an "evacuation information transmission instruction" from the person in charge of disaster prevention in the local government (step S101). Specifically, the transmission instruction acquisition unit 211 displays a GUI, an input form, and the like for inputting an evacuation information transmission instruction on a disaster prevention person terminal (not shown in FIG. 6 and the like) used by the disaster prevention person.
  • the transmission instruction acquisition unit 211 displays a GUI as shown in FIG. 12 on the terminal of the person in charge of disaster prevention.
  • the person in charge of disaster prevention selects an alert level and an area for issuing evacuation information.
  • the target resident selection unit 212 selects residents to whom evacuation information is to be transmitted (step S102).
  • the target resident selection unit 212 refers to the resident information database and selects residents of the area (area where evacuation information is to be issued) input by the person in charge of disaster prevention.
  • the target resident selection unit 212 refers to the address field of the resident information database and extracts residents (entries) residing in areas where evacuation information is issued. The extracted residents are the residents to whom the evacuation information is to be transmitted.
  • the shared data acquisition unit 213 is means for acquiring the health information of the resident from the resident's family hospital.
  • the shared data acquisition unit 213 acquires health information from the hospital server 20 through data sharing.
  • the shared data acquisition unit 213 acquires health information by transmitting a data sharing request regarding health information to the hospital server 20 of the family hospital.
  • the shared data acquisition unit 213 confirms the hospital information of each resident extracted as a transmission target of the evacuation information, and determines whether or not a family hospital is set (step S103).
  • Step S103 If the family hospital is not set (Step S103, No branch), the shared data acquisition unit 213 does not perform any particular operation. In this case, the processing after step S106 is executed.
  • the shared data acquisition unit 213 If the family hospital is set (step S103, Yes branch), the shared data acquisition unit 213 generates a data sharing request and transmits the generated data sharing request to the hospital server 20 (step S104).
  • the shared data acquisition unit 213 refers to the hospital information and acquires the hospital name and patient ID of the family hospital.
  • the shared data acquisition unit 213 identifies the hospital server 20 to which the data sharing request is sent from the hospital name.
  • the shared data acquisition unit 213 acquires the destination of the data sharing request by referring to table information that stores the hospital name and the IP (Internet Protocol) address of the hospital server 20 in association with each other.
  • the shared data acquisition unit 213 generates a data sharing request including the patient ID and information about the shared data to be acquired (purpose of use, data type, data sharing destination), and transmits the data sharing request to the hospital server 20 .
  • the type of shared data is set as “Current disease”, and the shared data is shared with “Disaster prevention center”.
  • the type of data to be shared (whether to be acquired from the hospital) is based on the policy of the Disaster Prevention Center. For example, a policy for acquiring "current disease”, a policy for acquiring "previous disease” and “current disease”, and a policy for acquiring "previous disease”, "current disease” and “medication information” are set in advance in the local government server 10. .
  • the local government server 10 can create more accurate evacuation information.
  • the number of types of data to be acquired by sharing is small, there is a high possibility that permission has been obtained from the residents, but it is difficult for the local government server 10 to create more accurate evacuation information.
  • the person in charge of disaster prevention or the like determines the type of data to be acquired through sharing (determines a policy) in consideration of these advantages and disadvantages.
  • the shared data acquisition unit 213 receives a response to the data sharing request (step S105). If data sharing is not permitted, shared data acquisition unit 213 receives a negative response. In this case, the shared data acquisition unit 213 does not perform any particular operation.
  • the shared data acquisition unit 213 may treat the residents for whom the shared data could not be acquired as residents for whom no family hospital has been set.
  • the shared data acquisition unit 213 receives a positive response. That is, the shared data acquisition unit 213 receives the “health information notification” from the hospital server 20 .
  • the health information notification includes patient ID and health information.
  • health information is specific data (information) corresponding to the data type set in the data sharing request.
  • specific disease names such as "stomach cancer” and “lung cancer” are notified to the local government server 10 as health information.
  • the evacuation information generation unit 214 is means for generating evacuation information.
  • the evacuation information generation unit 214 generates evacuation information including information about evacuation centers to which residents are guided, based on the health information of each resident.
  • the evacuation information generation unit 214 selects an evacuation destination (evacuation center) to guide the residents to whom the evacuation information is to be transmitted (step S106). At this time, for example, the evacuation information generation unit 214 selects evacuation destinations to guide residents based on the health condition of the target residents and the characteristics of each evacuation center.
  • the evacuation information generation unit 214 refers to the evacuation center information database as shown in FIG. 13 and reads the characteristics of each evacuation center.
  • the shelter information database stores the shelter ID, name, location, and characteristics of each shelter in association with each other. Moreover, as shown in FIG. 13, some shelters have no features, while others have multiple features.
  • the evacuation center information database shown in FIG. 13 is an example and is not meant to limit the items to be stored.
  • the contact information of each shelter may be registered in the shelter information database.
  • the capacity of each shelter may be registered in the shelter information database.
  • the evacuation information generation unit 214 refers to the residents' health information and the characteristics of each evacuation center, and selects an evacuation center that matches the health condition of the residents.
  • the evacuation information generation unit 214 selects an evacuation center that does not have any particular characteristics for residents who are not concerned about their health condition (residents who do not have a family hospital set; residents who do not need to consider health information). do.
  • the evacuation information generator 214 selects shelter B shown in FIG. In this way, the evacuation information generation unit 214 can positively select the normal evacuation center B, where doctors and nurses are not stationed, for residents who are not concerned about their health condition.
  • the evacuation information generation unit 214 For residents whose health information needs to be taken into consideration (residents whose family hospital is set), the evacuation information generation unit 214 generates the Choose a shelter. For example, if the current illness requires observation by a doctor or the like, the evacuation information generation unit 214 selects an evacuation center where doctors and nurses are stationed. In this case, the evacuation information generator 214 selects shelter A and shelter C shown in FIG.
  • the evacuation information generation unit 214 may select a normal evacuation center (for example, evacuation center B) depending on the content of the current illness. For example, in the case of an actual condition such as a "broken finger," it is assumed that no special consideration is required for the residents, so the normal shelter B is selected. Alternatively, the evacuation information generation unit 214 may select the normal evacuation center B for residents whose family hospital is set but who are clearly judged to have no health problems based on their health information.
  • a normal evacuation center for example, evacuation center B
  • evacuation center B for example, evacuation center B
  • the evacuation information generation unit 214 may select the normal evacuation center B for residents whose family hospital is set but who are clearly judged to have no health problems based on their health information.
  • the residents' health conditions and selection of evacuation shelters may be performed based on predetermined table information or the like, or may be performed using a learning model implemented in the local government server 10.
  • the local government server 10 may be equipped with a learning model that, when a current disease is input, outputs the characteristics of an evacuation center suitable for the current disease.
  • the evacuation information generating unit 214 selects an evacuation center with a resident doctor or nurse or an evacuation center with medical facilities for residents who are determined to have health concerns based on their health information. .
  • the evacuation information generation unit 214 may select an evacuation center based on the medication information and the characteristics of the evacuation center. For example, the evacuation information generation unit 214 may select an evacuation center that is always stocked with medicines that residents are taking. For example, in the example of FIG. 13, shelter C is selected for residents taking medicine A.
  • the evacuation information generation unit 214 generates evacuation information based on the alert level input by the person in charge of disaster prevention and the selected evacuation center (step S107). For example, evacuation information as shown in FIG. 14 is generated for residents who are not concerned about their health condition (residents whose health information does not need to be considered). On the other hand, evacuation information as shown in FIG. 15 is generated for residents whose health information needs to be considered.
  • the evacuation information control unit 203 transmits the generated evacuation information to the terminal 30 owned by the residents (step S108).
  • the evacuation information control unit 203 transmits evacuation information to each resident's contact information (for example, an e-mail address that can be received by the terminal 30) listed in the resident information database.
  • the evacuation information control unit 203 returns to step S102 and continues the process if there are residents whose evacuation information is to be transmitted (step S109, Yes branch).
  • the evacuation information control unit 203 terminates the process if there are no residents whose evacuation information is to be transmitted (step S109, No branch).
  • the storage unit 204 is means for storing information necessary for the operation of the local government server 10.
  • a resident information database In the storage unit 204, a resident information database, a shelter information database, and the like are constructed.
  • FIG. 16 is a diagram showing an example of the processing configuration (processing modules) of the hospital server 20 according to the first embodiment.
  • the hospital server 20 includes a communication control section 301, a permission information acquisition section 302, a sharing control section 303, and a storage section 304.
  • the communication control unit 301 is means for controlling communication with other devices. For example, the communication control unit 301 receives data (packets) from the local government server 10 . Also, the communication control unit 301 transmits data to the local government server 10 . The communication control unit 301 passes data received from other devices to other processing modules. The communication control unit 301 transmits data acquired from other processing modules to other devices. In this way, other processing modules transmit and receive data to and from other devices via the communication control unit 301 .
  • the communication control unit 301 has a function as a receiving unit that receives data from another device and a function as a transmitting unit that transmits data to the other device.
  • the license information acquisition unit 302 is means for acquiring shared license information.
  • a user who wishes to make settings for data sharing at his or her family hospital accesses the website managed and operated by the hospital and logs into an account for managing patient information, etc. At that time, the user enters the patient ID assigned to him/herself into the home page.
  • the consent information acquisition unit 302 acquires the patient ID and specifies a user (patient) who wishes to set data sharing consent.
  • the permission information acquisition unit 302 displays a GUI as shown in FIG. 5 on the terminal 30 owned by the user.
  • the license information acquisition unit 302 acquires the purpose of data sharing, data type, data sharing destination, and conditions for data sharing from the terminal 30 .
  • the permission information acquisition unit 302 stores the acquired sharing permission information (purpose, data type, data sharing destination, conditions) in the patient information database.
  • the permission information acquisition unit 302 associates the patient ID, chart ID, and sharing permission information and stores them in the patient information database (see FIG. 17).
  • the patient information database shown in FIG. 17 is an example, and is not intended to limit the items to be stored.
  • the patient's biological information for example, facial images and feature values generated from the facial images
  • patient ID and chart ID are generated at the time of the patient's first visit, and are added to the patient information database when these IDs are generated.
  • Generation of patient IDs and generation and management of electronic medical charts including medical chart IDs are obvious to those skilled in the art, and since they are different from the gist of the disclosure of the present application, detailed descriptions thereof will be omitted.
  • the sharing control unit 303 is means for controlling data sharing. The operation of the sharing control unit 303 will be described with reference to FIG. FIG. 18 is a flow chart showing an example of the operation of the sharing control unit 303 according to the first embodiment.
  • the sharing control unit 303 receives a data sharing request from an external device (local government server 10) (step S201).
  • the sharing control unit 303 verifies the acquired data sharing request.
  • the sharing control unit 303 performs two verifications (two-step verification).
  • the sharing control unit 303 searches the patient information database using the patient ID included in the data sharing request as a key, and identifies the corresponding sharing permission information (step S202).
  • the sharing control unit 303 verifies whether or not the "purpose of use” included in the data sharing request matches the "purpose” and “conditions” included in the specified sharing permission information (first verification; step S203). ).
  • the sharing control unit 303 determines that the first verification for data sharing has succeeded.
  • the sharing control unit 303 determines that the first verification for data sharing has failed.
  • step S204 If the first verification fails (step S204, No branch), the sharing control unit 303 sets the data sharing disabled (step S205).
  • step S204 If the first verification succeeds (step S204, Yes branch), the sharing control unit 303 executes the second verification (step S206). Specifically, the sharing control unit 303 verifies whether or not the sharing destination included in the data sharing request matches the “sharing destination” of the sharing permission information.
  • the sharing control unit 303 performs the second verification for data sharing. judged to be successful.
  • the sharing control unit 303 performs the second data sharing for data sharing. verification has failed.
  • step S207 If the second verification fails (step S207, No branch), the sharing control unit 303 sets the data sharing disabled (step S205).
  • step S207 If the second verification succeeds (step S207, Yes branch), the sharing control unit 303 sets data sharing to be permitted (step S208).
  • the sharing control unit 303 transmits a response to the data sharing request (step S209).
  • the sharing control unit 303 transmits a negative response to that effect to the local government server 10.
  • the sharing control unit 303 reads out the chart ID corresponding to the patient ID included in the data sharing request from the patient information database.
  • the sharing control unit 303 uses the medical record ID to identify the electronic medical record of the person subject to data sharing.
  • the sharing control unit 303 reads items (items in the data type field of the patient information database) for which "permission" is set in the sharing permission information among the specified items described in the electronic medical record.
  • the sharing control unit 303 retrieves the data labeled "current disease” from the electronic medical record. read out. For example, specific disease names such as “stomach cancer” and “lung cancer” are read.
  • the sharing control unit 303 When the sharing control unit 303 reads data for which data sharing is permitted, it generates a health information notification including the read data and the patient ID of the target person (patient) with whom the data is to be shared, and transmits the information as a data sharing request. It is transmitted to the source (shared destination; local government server 10). Health information notifications are treated as acknowledgments to data sharing requests.
  • the storage unit 304 is means for storing information necessary for the operation of the hospital server 20.
  • a patient information database a database constituting an electronic medical record, and the like are constructed.
  • the hospital server 20 stores, in the storage unit 304, sharing permission information regarding at least part of the data described in the patient's electronic medical record being shared with the local government server 10.
  • Examples of the terminal 30 include mobile terminal devices such as smartphones, mobile phones, game machines, and tablets, computers (personal computers, notebook computers), and the like.
  • the terminal 30 can be any equipment or device as long as it can receive operations from residents and communicate with the local government server 10 or the like. Also, since the configuration of the terminal 30 and the like are obvious to those skilled in the art, detailed description thereof will be omitted.
  • FIG. 19 is a sequence diagram illustrating an example of the operation of the disaster prevention system according to the first embodiment.
  • the local government server 10 acquires an evacuation information transmission instruction from the person in charge of disaster prevention (step S01).
  • the local government server 10 selects residents to whom evacuation information is to be sent (step S02).
  • the local government server 10 transmits a data sharing request to the hospital server 20 of the family hospital (step S03).
  • the hospital server 20 Upon receiving the data sharing request, the hospital server 20 verifies the request (step S04). The hospital server 20 verifies the utilization purpose and sharing destination of the data sharing request.
  • the hospital server 20 reads specific data corresponding to the data type for which the patient has consented to data sharing from the patient's electronic medical record.
  • the hospital server 20 transmits a health information notification including the read data to the local government server 10 (step S05).
  • the hospital server 20 verifies the data sharing request using the sharing permission information, and if the verification of the data sharing request is successful, reads the data corresponding to the type of data approved by the patient from the electronic medical record.
  • the hospital server 20 notifies the local government server 10 of the read data as health information.
  • the local government server 10 Upon receiving the health information notification, the local government server 10 selects a shelter to guide the resident based on the resident's health condition (health information) (step S06).
  • the local government server 10 generates evacuation information including information on the selected evacuation center (name and location of the evacuation center) and transmits it to the terminal 30 possessed by the residents (step S07).
  • the terminal 30 outputs the received evacuation information (step S08). For example, the terminal 30 responds by displaying the evacuation information on a monitor or reading the evacuation information from a speaker.
  • the local government server 10 selects residents living in an area designated by the person in charge of disaster prevention from among a plurality of residents, and selects the terminals 30 owned by the selected residents. Send evacuation information to At that time, the local government server 10 acquires the selected residents' health information from the hospital server 20 by data sharing. The local government server 10 selects a shelter to guide residents to based on the acquired health information. As a result, residents who are concerned about their health will choose shelters with full-time medical facilities and full-time doctors. On the other hand, ordinary evacuation shelters are selected for residents who do not have health concerns. With such a function of the local government server 10, healthy people do not have to evacuate to an evacuation center with sufficient medical facilities, etc., and residents who are concerned about their health can more reliably evacuate to the evacuation center.
  • the local government server 10 identifies residents who have arrived at the evacuation center by biometric authentication.
  • the local government server 10 provides the family hospital (hospital server 20) with information on the identified residents.
  • residents input their own biometric information (for example, facial images) to the local government server 10 .
  • the resident registration unit 202 of the local government server 10 generates a feature amount from the face image, associates the feature amount (biological information) with the resident ID, etc., and stores the result in the resident information database (see FIG. 20).
  • FIG. 21 is a diagram showing an example of a schematic configuration of a disaster prevention system according to the second embodiment. As shown in FIG. 21, each shelter is provided with a reception terminal 40 that receives refugees. Since the reception terminal 40 installed in each evacuation center can have the same configuration and operation, the following description will focus on the configuration of the reception terminal 40 installed in the evacuation center A.
  • the reception terminal 40 photographs the evacuee and acquires the face image.
  • the reception terminal 40 transmits to the local government server 10 a “evacuee visit notice” including the acquired face image and the shelter ID assigned to each shelter.
  • the local government server 10 performs matching processing using the acquired face images to identify residents who have arrived at the evacuation center.
  • the municipality server 10 reflects the evacuation destination of the residents in the resident information database (see the evacuation site field in FIG. 20).
  • the residents whose family hospital is set (ID31 residents) evacuate to shelter A, and the residents who also have their family hospital set (ID32 residents) evacuate to shelter B. is registered in the resident information database. It should be noted that the resident with ID 32 should have been guided to evacuate to shelter A, but is assumed to have evacuated to shelter B for some reason.
  • Evacuation center B is a normal evacuation center where doctors and nurses are not stationed.
  • the local government server 10 accesses the resident information database regularly or at a predetermined timing.
  • the local government server 10 extracts residents who have a family hospital and who are evacuating to a shelter. In the example of FIG. 20, residents with ID31 and ID32 are extracted.
  • the local government server 10 transmits "patient evacuation destination information" to the extracted family hospital of the resident.
  • the patient evacuation destination information includes information on evacuation destinations of residents (patients at family hospitals) and patient IDs.
  • patient evacuation destination information indicating that a patient with pID31 has evacuated to evacuation center A for hospital A
  • the indicated patient evacuation site information is transmitted respectively.
  • the hospital server 20 that receives the patient evacuation destination information notifies the patient's evacuation destination to doctors, nurses, etc.
  • a doctor or the like can grasp the evacuation destination of the patient of his/her own hospital, and can judge whether or not the evacuation destination is appropriate. For example, a patient in hospital B is evacuated to a normal evacuation site where no doctor is stationed, and the doctor of hospital B determines whether the evacuation site is appropriate.
  • FIG. 22 is a diagram showing an example of a processing configuration (processing modules) of the reception terminal 40.
  • the reception terminal 40 includes a communication control unit 401 , a biological information acquisition unit 402 , an evacuee visit notification unit 403 , and a storage unit 404 .
  • the communication control unit 401 is means for controlling communication with other devices. Specifically, the communication control unit 401 receives data (packets) from the local government server 10 . The communication control unit 401 also transmits data to the local government server 10 . The communication control unit 401 transfers data received from other devices to other processing modules. The communication control unit 401 transmits data acquired from other processing modules to other devices. In this manner, other processing modules transmit and receive data to and from other devices via the communication control unit 401 .
  • the communication control unit 401 has a function as a receiving unit that receives data from another device and a function as a transmitting unit that transmits data to the other device.
  • the biometric information acquisition unit 402 is means for controlling the camera device (the camera device provided in the reception terminal 40) and acquiring the biometric information (eg, face image) of the evacuees in front of them.
  • the biological information acquisition unit 402 captures an image of the front of the device periodically or at a predetermined timing.
  • the biometric information acquisition unit 402 determines whether or not the acquired image contains a face image of a person, and if the face image is contained, extracts the face image from the acquired image data.
  • the biometric information acquisition unit 402 may extract a face image (face region) from image data using a learning model learned by a CNN (Convolutional Neural Network).
  • the biometric information acquisition unit 402 may extract a face image using a method such as template matching.
  • the biometric information acquisition unit 402 delivers the extracted face image to the evacuee visit notification unit 403 .
  • the evacuees' visit notification unit 403 is means for notifying the local government server 10 of evacuees' arrival.
  • the evacuee visit notification unit 403 generates an “evacuee visit notification” including the acquired face image and shelter ID, and transmits it to the local government server 10 .
  • the shelter ID is shared between the reception terminal 40 and the local government server 10 by any means.
  • the system administrator staff of the disaster prevention center
  • the storage unit 404 is means for storing information necessary for the operation of the reception terminal 40 .
  • FIG. 23 is a diagram showing an example of a processing configuration (processing modules) of the local government server 10 according to the second embodiment.
  • a resident evacuation destination management unit 205 and a patient evacuation destination notification unit 206 are added to the configuration of the local government server 10 according to the first embodiment.
  • the resident evacuation destination management unit 205 is a means of managing residents who have evacuated to evacuation centers.
  • the resident evacuation destination management unit 205 receives a notification of the arrival of the evacuee from the reception terminal 40 installed at the evacuation center. Since the notification includes the biometric information (face image) of the evacuee, the resident evacuation destination management unit 205 extracts the face image from the evacuee visit notice. The resident evacuation destination management unit 205 generates a feature amount from the acquired face image.
  • the resident evacuation destination management unit 205 extracts the eyes, nose, mouth, etc. from the face image as feature points. After that, the resident evacuation destination management unit 205 calculates the positions of the feature points and the distances between the feature points as feature amounts, and generates a feature vector (vector information that characterizes the face image) composed of a plurality of feature amounts.
  • a feature vector vector information that characterizes the face image
  • the resident evacuation destination management unit 205 sets the feature amount calculated based on the face image acquired from the reception terminal 40 as a matching target, and performs matching processing with the feature amount registered in the resident information database. More specifically, the resident evacuation destination management unit 205 sets the calculated feature value (feature vector) as a matching target, and compares it with a plurality of feature values registered in the resident information database in 1:N ( N is a positive integer, and so on) to perform matching.
  • the resident evacuation destination management unit 205 calculates the degree of similarity between the feature amount to be matched and each of the plurality of feature amounts on the registration side. Chi-square distance, Euclidean distance, or the like can be used for the degree of similarity. Note that the greater the distance, the lower the similarity, and the closer the distance, the higher the similarity.
  • the resident evacuation destination management unit 205 selects a feature amount (a feature amount with the highest similarity) that is closest to the feature amount to be matched among the feature amounts registered in the resident information database and whose degree of similarity is equal to or greater than a predetermined value. Identify.
  • the resident evacuation site management unit 205 sets the shelter ID (name of the shelter) notified from the shelter in the shelter field of the entry corresponding to the specified feature amount.
  • the resident evacuation site management unit 205 determines that the resident corresponding to the face image notified from the evacuation center is not registered as a resident unless an entry having a feature amount with a degree of similarity equal to or greater than a predetermined value is registered in the resident information database. I judge. In this case, the resident evacuation destination management unit 205 does not have to perform any particular operation, or may perform statistical processing such as tallying the number of users who have not registered as residents.
  • the patient evacuation destination notification unit 206 is a means of notifying the hospital of the patient's evacuation destination set by the family hospital.
  • the patient evacuation destination notification unit 206 accesses the resident information database periodically or at a predetermined timing.
  • the patient evacuation destination notification unit 206 extracts residents who have a family hospital set and who are evacuating to an evacuation center.
  • the patient evacuation destination notification unit 206 transmits patient evacuation destination information including patient ID and information on the patient's evacuation destination (evacuation center name, contact information, etc.) to the extracted family hospital of the resident. In addition, there is no need to notify the hospital of evacuation destinations for the same residents multiple times.
  • FIG. 24 is a diagram showing an example of the processing configuration (processing modules) of the hospital server 20 according to the second embodiment. Referring to FIG. 24, a patient information providing unit 305 is added to the configuration of the hospital server 20 according to the first embodiment.
  • the patient information provision unit 305 is a means for providing hospital staff (doctors, nurses, etc.) with information regarding evacuation destinations for patients in their own hospital.
  • the patient information provision unit 305 Upon receiving the patient evacuation destination information, the patient information provision unit 305 generates "patient information" based on the patient evacuation destination information. For example, the patient information providing unit 305 identifies the patient's name and electronic medical record from the patient ID included in the patient evacuation site information. The patient information providing unit 305 generates patient information including information on the evacuation destination of the patient (name of the evacuation center, contact information), the name of the patient, and information written in the electronic medical record.
  • the patient information providing unit 305 displays the generated patient information on a liquid crystal monitor or the like connected to the hospital server 20. Alternatively, the patient information providing unit 305 may transmit the generated patient information to a doctor terminal or a nurse terminal used by doctors, nurses, and the like.
  • FIG. 25 is a sequence diagram showing an example of the operation of the disaster prevention system according to the second embodiment.
  • the reception terminal 40 When the reception terminal 40 detects an evacuee, it acquires the biometric information (face image) of the evacuee. The reception terminal 40 transmits an evacuee visit notification including the acquired face image to the local government server 10 (step S11).
  • the local government server 10 that has received the evacuees' visit notice identifies the evacuees by matching processing using the evacuees' biometric information (step S12).
  • the local government server 10 registers the specified evacuation destination of the evacuees in the resident information database.
  • the local government server 10 If a family hospital is set for the evacuees, the local government server 10 generates patient evacuation destination information and transmits it to the hospital server 20 of the family hospital (step S13).
  • the hospital server 20 generates patient information (information about the evacuation center and information including the patient's electronic medical record) regarding the patient who is evacuating to the evacuation center based on the patient evacuation destination information (step S14).
  • the hospital server 20 provides the generated patient information to doctors, nurses, etc. of the hospital (step S15).
  • the reception terminal 40 installed at each evacuation center transmits to the local government server 10 the evacuees' arrival notification including the biometric information of the evacuees who have visited.
  • the local government server 10 identifies the evacuees who have come to the shelter by a collation process using the biometric information contained in the evacuees' visit notification.
  • the local government server 10 transmits the patient evacuation destination information including the evacuation destination of the evacuees who have come to the hospital to the hospital server 20 of the identified family hospital of the resident.
  • a doctor or the like at a family hospital can know the place where the patient of his/her own hospital has evacuated, and can examine and verify the evacuation destination. For example, if the patient's evacuation destination is determined to be inappropriate, the doctor of the family hospital can contact the evacuation center and invite the patient to his or her own hospital.
  • the medical terminal 50 includes a display device visible by a doctor and a display device visible by a patient.
  • a camera is installed in the display device that can be visually recognized by the patient, and is configured to photograph the patient's face.
  • Evacuees who evacuated to a shelter where a doctor is stationed can receive a doctor's diagnosis regularly or at a predetermined timing.
  • a doctor uses the medical terminal 50 to make a diagnosis.
  • the doctor operates the medical terminal 50 and confirms the electronic medical record of the evacuee (patient) in front of him.
  • the medical terminal 50 acquires biometric information (for example, face image) of the patient in front of the patient.
  • the medical terminal 50 transmits an authentication request including the acquired face image to the local government server 10 .
  • the local government server 10 identifies the patient through authentication processing using the biometric information included in the authentication request.
  • the local government server 10 transmits the specified patient's hospital information (hospital name and patient ID of the family hospital) to the medical terminal 50 .
  • the medical terminal 50 identifies the family hospital from the hospital name, and transmits an "electronic medical chart provision request" including the patient ID to the hospital server 20 of the identified family hospital.
  • the hospital server 20 searches the patient information database using the patient ID included in the electronic medical record provision request as a key to identify the patient.
  • the hospital server 20 identifies the electronic medical record based on the identified patient's medical record ID, and reads out the contents thereof.
  • the hospital server 20 transmits to the medical terminal 50 a response (response to the electronic medical chart provision request) including the read electronic chart.
  • the medical terminal 50 displays the received electronic chart.
  • the doctor diagnoses the patient while checking the electronic chart.
  • FIG. 27 is a diagram showing an example of the processing configuration (processing modules) of the medical terminal 50.
  • medical terminal 50 includes communication control section 501 , biometric information acquisition section 502 , authentication request section 503 , electronic medical record acquisition section 504 , and storage section 505 .
  • the communication control unit 501 is means for controlling communication with other devices. Specifically, the communication control unit 501 receives data (packets) from the local government server 10 . The communication control unit 501 also transmits data to the local government server 10 . The communication control unit 501 passes data received from other devices to other processing modules. The communication control unit 501 transmits data acquired from other processing modules to other devices. In this manner, other processing modules transmit and receive data to and from other devices via the communication control unit 501 .
  • the communication control unit 501 has a function as a receiving unit that receives data from another device and a function as a transmitting unit that transmits data to the other device.
  • the biometric information acquisition unit 502 is means for controlling the camera device and acquiring biometric information (for example, facial images) of the evacuee in front of them.
  • the biometric information acquisition unit 502 acquires a facial image of a resident (patient) in front of the patient according to an operation by a doctor or the like.
  • the biometric information acquiring unit 502 may display a GUI for obtaining the patient's consent while displaying the acquisition of the patient's facial image and the purpose of acquiring the facial image.
  • the biometric information acquisition unit 502 may display a GUI as shown in FIG.
  • the biometric information acquisition unit 502 passes the acquired face image to the authentication request unit 503 .
  • the authentication requesting unit 503 is means for requesting the local government server 10 to authenticate the patient.
  • the authentication requesting unit 503 generates an authentication request including the acquired face image, and transmits the authentication request to the local government server 10 .
  • the authentication requesting unit 503 receives authentication results (authentication success, authentication failure) from the local government server 10 . If the authentication result is authentication failure, the authentication requesting unit 503 notifies the doctor and the patient to that effect. At this time, the authentication requesting unit 503 displays a message such as "Electronic chart cannot be obtained because resident registration is not done at the disaster prevention center.”
  • the authentication requesting unit 503 passes the authentication result (a positive response including hospital information) to the electronic medical chart acquisition unit 504 .
  • the electronic medical record acquisition unit 504 extracts the patient ID included in the hospital information.
  • the electronic medical chart acquisition unit 504 transmits an electronic medical chart provision request including the extracted patient ID to the hospital server 20 (the hospital server 20 of the hospital included in the hospital information).
  • the electronic medical chart acquisition unit 504 displays the acquired electronic medical chart on a display device that can be viewed by the doctor.
  • the storage unit 505 is means for storing information necessary for the operation of the medical terminal 50.
  • FIG. 29 is a diagram showing an example of a processing configuration (processing modules) of the local government server 10 according to the third embodiment. Referring to FIG. 29, an authentication unit 207 is added to the local government server 10 according to the first embodiment.
  • the authentication unit 207 is means for processing authentication requests received from the medical terminal 50 .
  • the authentication unit 207 performs biometric authentication using the biometric information extracted from the authentication request and the biometric information of each of a plurality of residents stored in advance in the resident information database.
  • the authentication unit 207 extracts biometric information (face image) included in the authentication request. Authentication unit 207 calculates a feature amount from the extracted face image. The authentication unit 207 sets the feature amount calculated based on the face image as a matching target, and performs matching processing with the feature amount registered in the resident information database. The authentication unit 207 calculates the degree of similarity between the feature amount to be matched and each of the plurality of feature amounts on the registration side.
  • the authenticating unit 207 performs authentication of the person-to-be-authenticated if, among the plurality of feature values registered in the resident information database, there is no feature value whose similarity to the target feature value is equal to or greater than a predetermined value. judged to have failed.
  • the authentication unit 207 If the authentication fails, the authentication unit 207 notifies the medical terminal 50, which is the source of the authentication request, of the failure (authentication failure). The authentication unit 207 transmits a negative response indicating authentication failure to the medical terminal 50 .
  • the authentication unit 207 identifies the feature amount (entry) closest to the feature amount to be matched. do.
  • the authentication unit 207 determines that authentication has succeeded if hospital information is set in the specified entry.
  • the authentication unit 207 determines that authentication has failed if hospital information is not set in the identified entry.
  • the authentication unit 207 transmits to the medical terminal 50 an affirmative response including the hospital information (family hospital name, patient ID) of the specified entry.
  • FIG. 30 is a diagram showing an example of the processing configuration (processing modules) of the hospital server 20 according to the third embodiment. Referring to FIG. 30, an electronic chart provision unit 306 is added to the configuration of the hospital server 20 according to the first embodiment.
  • the electronic medical record provision unit 306 is means for providing the information described in the patient's electronic medical record to the evacuation center (medical terminal 50).
  • the electronic medical chart provision unit 306 Upon receiving the electronic medical chart provision request, the electronic medical chart provision unit 306 searches the patient information database using the patient ID included in the electronic medical chart provision request as a key, and identifies the corresponding medical chart ID. The electronic medical chart providing unit 306 acquires an electronic medical chart corresponding to the specified medical chart ID.
  • the electronic medical chart providing unit 306 transmits the acquired electronic medical chart to the medical terminal 50 .
  • FIG. 31 is a sequence diagram showing an example of the operation of the disaster prevention system according to the third embodiment.
  • the medical terminal 50 acquires the evacuees' biometric information with the evacuees' consent.
  • the medical terminal 50 transmits an authentication request including the acquired biometric information to the local government server 10 (step S21).
  • the local government server 10 Upon receiving the authentication request, the local government server 10 executes authentication processing using the biometric information of the authentication request and the biometric information registered in the resident information database (step S22).
  • the local government server 10 transmits the hospital information of the successful authentication person (the person to be authenticated who was determined to be authenticated successfully; the evacuee in front of the medical terminal 50) to the medical terminal 50 (step S23).
  • the medical terminal 50 extracts the patient ID from the hospital information and transmits an electronic medical record provision request including the extracted patient ID to the hospital (hospital server 20) described in the hospital information (step S24).
  • the hospital server 20 reads the electronic chart corresponding to the patient ID and transmits it to the medical terminal 50 (step S25).
  • the medical terminal 50 acquires hospital information from the local government server 10 and acquires the patient's electronic medical record from the hospital server 20 .
  • the medical terminal 50 can also acquire the electronic chart directly from the hospital server 20 .
  • residents register their own biometric information (for example, facial images) in the hospital server 20 of their family hospital.
  • the hospital server 20 generates a feature amount from the face image, associates the feature amount (biological information) with the patient ID or the like, and stores the feature amount in the patient information database.
  • the doctor asks the patient (evacuee) about the family hospital and inputs it into the medical terminal 50.
  • the medical terminal 50 acquires patient's biometric information (face image).
  • the medical terminal 50 transmits an electronic medical chart provision request including the biometric information to the hospital server 20 of the input hospital.
  • the hospital server 20 identifies the patient by biometric authentication and reads out the corresponding electronic medical record.
  • the hospital server 20 transmits the read electronic chart to the medical terminal 50 .
  • the hospital server 20 in this case may have an "authentication unit" inside. Since the operation of the authentication unit can be the same as the operation of the authentication unit 207 of the local government server 10, detailed description will be omitted.
  • electronic medical record information may be shared between the hospital server 20 and the medical terminal 50 .
  • the patient may set permission for data sharing to the medical terminal 50 in the hospital server 20 .
  • the purpose of data sharing is "examination at an evacuation center”
  • the type of data to be shared is “electronic medical record”
  • the destination of data sharing is “medical terminal (evacuation center)”
  • the condition for sharing data is "examination by a doctor”.
  • Content may be set.
  • the medical terminal 50 may transmit to the hospital server 20 a data sharing request regarding electronic medical records.
  • the disaster prevention system further includes the medical terminal 50.
  • the medical terminal 50 transmits an authentication request including the biometric information of the person to be authenticated to the local government server 10 .
  • the local government server 10 identifies the person to be authenticated using the biometric information included in the authentication request, and transmits information on the family hospital of the identified person to be authenticated to the medical terminal 50 .
  • the medical terminal 50 requests the family hospital to provide the electronic chart of the person to be authenticated. In this way, a doctor at the evacuation center can refer to the patient's (evacuee's) electronic medical record, and can perform more reliable medical treatment and diagnosis.
  • the third embodiment when acquiring the patient's biological information, it is possible to obtain the patient's consent to sharing the electronic medical record information. That is, in the disclosure of the present application, by appropriately separating information shared with organizations such as local governments and information shared among doctors, both user privacy protection and user convenience are achieved.
  • FIG. 32 is a diagram showing an example of the hardware configuration of the local government server 10. As shown in FIG. 32
  • the local government server 10 can be configured by an information processing device (so-called computer), and has the configuration illustrated in FIG.
  • the local government server 10 includes a processor 311, a memory 312, an input/output interface 313, a communication interface 314, and the like.
  • Components such as the processor 311 are connected by an internal bus or the like and configured to be able to communicate with each other.
  • the configuration shown in FIG. 32 is not intended to limit the hardware configuration of the local government server 10.
  • the local government server 10 may include hardware not shown, and may not have the input/output interface 313 as necessary. Also, the number of processors 311 and the like included in the local government server 10 is not limited to the example shown in FIG.
  • the processor 311 is, for example, a programmable device such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), DSP (Digital Signal Processor). Alternatively, processor 311 may be a device such as FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit), or the like. The processor 311 executes various programs including an operating system (OS).
  • OS operating system
  • the memory 312 is RAM (Random Access Memory), ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), or the like.
  • the memory 312 stores an OS program, application programs, and various data.
  • the input/output interface 313 is an interface for a display device and an input device (not shown).
  • the display device is, for example, a liquid crystal display.
  • the input device is, for example, a device such as a keyboard or mouse that receives user operations.
  • the communication interface 314 is a circuit, module, etc. that communicates with other devices.
  • the communication interface 314 includes a NIC (Network Interface Card) or the like.
  • the functions of the local government server 10 are realized by various processing modules.
  • the processing module is implemented by the processor 311 executing a program stored in the memory 312, for example.
  • the program can be recorded in a computer-readable storage medium.
  • the storage medium can be non-transitory such as semiconductor memory, hard disk, magnetic recording medium, optical recording medium, and the like. That is, the present invention can also be embodied as a computer program product.
  • the program can be downloaded via a network or updated using a storage medium storing the program.
  • the processing module may be realized by a semiconductor chip.
  • the hospital server 20, the terminal 30, the reception terminal 40, and the medical terminal 50 can also be configured by information processing devices like the local government server 10, and their basic hardware configuration is the same as that of the local government server 10. Description is omitted.
  • the reception terminal 40 and the medical terminal 50 may be provided with a camera device for photographing the person to be authenticated.
  • the municipality server 10 which is an information processing device, is equipped with a computer, and the function of the municipality server 10 can be realized by causing the computer to execute a program. Moreover, the local government server 10 executes the control method of the local government server 10 by the program.
  • system input of the electronic medical record by the doctor is not explained, but the system input of the electronic medical record may be performed during the face-to-face diagnosis or during the online consultation.
  • electronic medical charts may be entered into the system by any method.
  • the local government server 10 acquires the health information of each resident from the family hospital has been described.
  • the local government server 10 may acquire the health information from the residents themselves or their families.
  • residents may also register their health information in the system (local government server 10) at the time of resident registration. That is, the disaster prevention system disclosed in the present application may use the health information described in the electronic medical record, or may use the health information self-reported by the residents.
  • evacuation centers may be selected based on current and pre-existing conditions.
  • evacuation centers may be determined in advance which information is prioritized when determining an evacuation center.
  • the local government server 10 may generate not only evacuation information as shown in FIGS. 33).
  • the local government server 10 may set the resident's home as the starting point and the selected evacuation center as the ending point, calculate the route, and include it in the evacuation information.
  • the local government server 10 may generate evacuation information including the type, characteristics, etc. of the proposed evacuation shelter.
  • the local government server 10 may refer to the resident information database and provide useful information to the person in charge of disaster prevention. For example, the local government server 10 calculates the total amount of medicine required for each evacuation center from the medication information of each resident and the evacuation destination information. The local government server 10 presents the calculated total amount to the person in charge of disaster prevention. Alternatively, the local government server 10 may request a pharmaceutical company or the like to deliver calculated medicines. In this way, the local government server 10 can grasp the attributes of the evacuees for each evacuation center, so that it can take measures such as making advance preparations for the delivery of medicine.
  • the local government server 10 may transmit the evacuation information to the supporter of the support-requiring person when the target of the evacuation information transmission is the "evacuation support-requiring person". That is, the evacuation information (evacuation destination) may be shared between the person requiring support and the supporter.
  • the local government server 10 may transmit a data sharing request to each hospital server 20, or may set priorities according to attributes of residents and hospitals. For example, if a hospital specializing in internal medicine and a hospital specializing in surgery are set as family hospitals, the local government server 10 may prioritize the hospital specializing in internal medicine as a data sharing destination.
  • the local government server 10 may set the name of the resident, etc., instead of the patient ID.
  • a data sharing permission is set in the hospital server 20 for the purpose of evacuation center guidance.
  • the hospital server 20 may be set for other purposes regarding data sharing.
  • the hospital server 20 may be set with a data sharing permission for the purpose of calculating insurance premiums.
  • the insurance company becomes the data sharing destination.
  • the hospital server 20 may change the data types selectable by the resident according to the purpose selected by the resident. For example, as described in the above embodiment, if the purpose is evacuation shelter guidance, "previous disease”, “current disease”, and “medicine information” are displayed as candidates for data sharing, and if the purpose is to calculate insurance premiums , "medication information" may not be displayed as a candidate for data sharing.
  • the hospital server 20 may prepare options such as "when evacuation information is issued” and options such as "when a disaster is expected due to heavy rain or a typhoon”.
  • the municipality server 10 can also determine that it is better to transport a person to a hospital than to evacuate to an evacuation center, depending on the health information of the residents. In this case, the local government server 10 may arrange an emergency vehicle for the resident.
  • the local government server 10 may inquire of the hospital listed in the hospital information about the treatment of the residents.
  • the person in charge of disaster prevention inputs the warning level and the target area for transmission of evacuation information to the local government server 10 .
  • the person in charge of disaster prevention may also input a "policy" regarding data sharing to the local government server 10 as well.
  • the person in charge of disaster prevention may determine the policy to be input (the type of data to be acquired through data sharing) according to the type and scale of the expected disaster.
  • the local government server 10 may select a shelter to guide based on the current location of the residents and the location of their residence. Specifically, the local government server 10 may select the nearest evacuation shelter to the residents from among suitable evacuation shelters for the residents and provide guidance.
  • the reception terminal 40 transmits the evacuees' arrival notification to the local government server 10 .
  • the notification may be sent by a monitoring camera or the like installed in the evacuation center.
  • the means for identifying residents may be other methods and means.
  • personal authentication using an electronic certificate written on a My Number card may be used.
  • password authentication using an ID and password may be used.
  • the local government server 10 may issue a resident ID generated at the time of resident registration to the resident, and the issued resident ID may be presented to the reception terminal 40 .
  • the terminal 30 converts the resident ID issued at the time of resident registration into a two-dimensional code, and the resident operates the terminal 30 and presents the two-dimensional code to the reception terminal 40 to identify the resident. may be performed.
  • the resident information database and the evacuation center information database are configured inside the local government server 10, but these databases may be configured on an external database server or the like. That is, some functions of the local government server 10 may be implemented in another server. More specifically, the above-described "resident registration unit (resident registration means)", “evacuation information control unit (evacuation information control means)", etc. may be installed in any device included in the system.
  • the municipality server 10 may confirm the identity of the residents at the time of resident registration. Specifically, the local government server 10 acquires an identification document (for example, a passport, a driver's license, etc.) in which the biometric information is described together with the biometric information and personal information of the residents. The local government server 10 performs one-to-one matching using the biometric information of the identification document and the biometric information obtained from the residents. The local government server 10 may perform resident registration when the collation is successful.
  • an identification document for example, a passport, a driver's license, etc.
  • the local government server 10 performs one-to-one matching using the biometric information of the identification document and the biometric information obtained from the residents.
  • the local government server 10 may perform resident registration when the collation is successful.
  • each device local government server 10, hospital server 20, etc.
  • data transmitted and received between these devices may be encrypted.
  • a patient's electronic medical record and the like are transmitted and received between these devices, and it is desirable to transmit and receive encrypted data in order to appropriately protect this information.
  • each embodiment may be used alone or in combination.
  • additions, deletions, and replacements of other configurations are possible for some of the configurations of the embodiments.
  • the industrial applicability of the present invention is clear, and the present invention can be suitably applied to a disaster prevention system that assists residents in evacuating.
  • [Appendix 1] a generation unit that generates evacuation information including information on evacuation sites to which the residents are guided, based on the health information of the residents; a transmitting unit that transmits the generated evacuation information to a terminal owned by the resident; A server device.
  • [Appendix 2] The server device according to appendix 1, further comprising an acquisition unit that acquires the health information from the resident's family hospital.
  • [Appendix 3] The server device according to appendix 2, wherein the acquisition unit acquires the health information by transmitting a data sharing request regarding the health information to a hospital server of the family hospital.
  • the server device according to any one of appendices 1 to 3, wherein the generation unit selects an evacuation center that matches the health condition of the residents, and generates the evacuation information including information about the selected evacuation center. .
  • the generation unit selects an evacuation shelter where a doctor or a nurse resides or an evacuation shelter equipped with medical facilities for the residents who are determined to have health concerns based on the health information. Server equipment as described.
  • Appendix 6 6.
  • the server device according to any one of Appendices 1 to 5, further comprising a storage unit that stores information about the resident's family hospital.
  • [Appendix 7] a local government server that selects residents living in an area designated by a person in charge of disaster prevention from among a plurality of residents and transmits evacuation information to terminals possessed by the selected residents; a hospital server; including The system, wherein the local government server acquires the health information of the selected residents from the hospital server by data sharing, and selects a shelter to guide the selected residents based on the acquired health information.
  • the hospital server stores sharing permission information regarding at least part of the data described in the patient's electronic medical record being shared with the municipality server.
  • [Appendix 9] 9. The system according to appendix 8, wherein the municipality server transmits a data sharing request including purpose of use, data type and sharing destination to the hospital server.
  • the hospital server verifies the data sharing request using the sharing permission information, and if the verification of the data sharing request is successful, reads data corresponding to the type of data approved by the patient from the electronic medical record. 9. The system according to appendix 9, wherein the read data is notified to the local government server as the health information. [Appendix 11] 11. The system according to appendix 10, wherein the sharing permission information includes information on the purpose of the data sharing, the type of data to be shared, the destination of the data sharing, and the conditions for sharing the data.
  • the reception terminal transmits to the local government server an evacuee visit notification including the biometric information of the evacuee who has visited,
  • the local government server identifies the evacuees who have visited by a collation process using the biometric information included in the evacuees' visit notice, and stores the evacuees who have visited the evacuees in the hospital server of the family hospital of the identified residents.
  • patient evacuation information including evacuation destinations is transmitted.
  • [Appendix 13] further comprising a medical terminal installed in the evacuation center; the medical terminal transmits an authentication request including the biometric information of the person to be authenticated to the local government server; The local government server identifies the person to be authenticated by using the biometric information included in the authentication request, and transmits information about the identified person's family hospital to the medical terminal, The system according to appendix 7, wherein the medical terminal requests the primary hospital to provide the electronic medical record of the person to be authenticated.
  • Appendix 15 The computer installed in the server device, a process of generating evacuation information including information on evacuation sites to be guided to the residents, based on the health information of the residents; a process of transmitting the generated evacuation information to a terminal owned by the resident; A computer-readable storage medium that stores a program for executing

Landscapes

  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Educational Administration (AREA)
  • Epidemiology (AREA)
  • Development Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Public Health (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Alarm Systems (AREA)

Abstract

住民に適した避難所を案内するサーバ装置を提供する。サーバ装置は、生成部と、送信部と、を備える。生成部は、住民の健康情報に基づいて、当該住民に案内する避難所に関する情報を含む避難情報を生成する。送信部は、生成された避難情報を住民が所持する端末に送信する。

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 (15)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023523896A JPWO2022249434A5 (ja) 2021-05-28 サーバ装置、システム、サーバ装置の制御方法及びプログラム
PCT/JP2021/020332 WO2022249434A1 (ja) 2021-05-28 2021-05-28 サーバ装置、システム、サーバ装置の制御方法及び記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/020332 WO2022249434A1 (ja) 2021-05-28 2021-05-28 サーバ装置、システム、サーバ装置の制御方法及び記憶媒体

Publications (1)

Publication Number Publication Date
WO2022249434A1 true WO2022249434A1 (ja) 2022-12-01

Family

ID=84228489

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/020332 WO2022249434A1 (ja) 2021-05-28 2021-05-28 サーバ装置、システム、サーバ装置の制御方法及び記憶媒体

Country Status (1)

Country Link
WO (1) WO2022249434A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010057075A (ja) * 2008-08-29 2010-03-11 Fujitsu Ltd 災害情報通知システム、災害情報通知方法及び災害情報通知プログラム
JP2014183419A (ja) * 2013-03-19 2014-09-29 Nec Corp 情報配信システム、情報配信ネットワークシステム、情報配信方法及び情報配信プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010057075A (ja) * 2008-08-29 2010-03-11 Fujitsu Ltd 災害情報通知システム、災害情報通知方法及び災害情報通知プログラム
JP2014183419A (ja) * 2013-03-19 2014-09-29 Nec Corp 情報配信システム、情報配信ネットワークシステム、情報配信方法及び情報配信プログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Cooperation with medical information. Expansion of information sharing in preparation for the Nankai Trough", RISKTAISAKU, vol. 43, 25 May 2014 (2014-05-25), pages 17 - 20 *
KIMURA, HIRONORI: "Cloud utilization for BCP in regional core hospitals", IT VISION, vol. 28, 25 June 2013 (2013-06-25), pages 52 - 54 *
NISHIZAKI, HIROYASU: "Cooperation with medical institutions at the time of disaster - Building a disaster medical care network using business chat", JAPAN AGENCY FOR LOCAL AUTHORITY INFORMATION SYSTEMS, vol. 6, no. 4, 1 July 2019 (2019-07-01), pages 24 - 27 *

Also Published As

Publication number Publication date
JPWO2022249434A1 (ja) 2022-12-01

Similar Documents

Publication Publication Date Title
US20230402140A1 (en) Patient-centric health record system and related methods
KR102144532B1 (ko) 블록체인 기반의 cPHR 서비스 운용 방법
JP6570691B1 (ja) 個人医療情報集約システム
US10622104B2 (en) System and method utilizing facial recognition with online (social) network to access casualty health information in an emergency situation
JP2015028772A (ja) 介護支援システム
JP2023086135A (ja) 救急医療支援システム
US20110307518A1 (en) Medical Record Management Using Fingerprint ID
WO2013002122A1 (ja) 患者情報を記憶する記憶媒体及びプログラム
JP2016148999A (ja) 医療支援システム、その作動方法及び医療支援プログラム並びに医療支援装置
JP2020095592A (ja) 個人医療情報システム
US20230215524A1 (en) Information system, information terminal, immunity certificate management system, information processing method, and non-transitory computer readable medium
KR102110388B1 (ko) 지역적 블록체인 기반의 cPHR 서비스 운용 방법
US11501861B2 (en) System and method to access casualty health information in an emergency situation
WO2022249434A1 (ja) サーバ装置、システム、サーバ装置の制御方法及び記憶媒体
JP2002073807A (ja) 医療情報システム、医療情報サーバ装置、医療情報端末装置および医療情報管理方法
KR100474797B1 (ko) 사이버 병원 시스템 및 이의 운용 방법
KR102371738B1 (ko) 약품 코드 생성 장치 및 방법
JP2011028330A (ja) 医療情報システム及びプログラム
JP7442371B2 (ja) 患者情報管理装置、患者情報管理方法、及び患者情報管理プログラム
WO2022044199A1 (ja) サーバ装置、避難所管理システム、サーバ装置の制御方法及び記憶媒体
JP7452670B2 (ja) サーバ装置、避難所管理システム及びサーバ装置の制御方法
JP2008310574A (ja) 副作用情報管理システム、副作用情報管理方法、副作用情報管理プログラム
KR102144540B1 (ko) 응급 상황을 위한 블록체인 기반의 cPHR 서비스 운용 방법
JP7151779B2 (ja) 救護情報提供システム、救護情報提供方法、及び、プログラム
WO2022269924A1 (ja) サーバ装置、システム、サーバ装置の制御方法及び記憶媒体

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21943079

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023523896

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21943079

Country of ref document: EP

Kind code of ref document: A1