JP7652248B2 - system - Google Patents

Description

The present invention relates to a server device, a system, a control method for a server device, and a storage medium.

When a large-scale disaster such as a typhoon is predicted, residents will evacuate to evacuation shelters. Various technologies are being developed to facilitate the evacuation of residents.

Patent Document 1 describes a system for providing evacuation shelter information during a disaster that provides disaster victims, including residents, with evacuation shelter information suited to their respective circumstances during a disaster, and guides them to the evacuation shelter most suitable for them, or allows each victim to determine their own evacuation destination. The system in Patent Document 1 includes a server for providing evacuation shelter information. The server is equipped with a registration processing unit and a query processing unit. The registration processing unit registers the user's resident information during a disaster, including information on priority items when searching for evacuation shelter information, in the disaster resident information database, based on information in a resident information database including the user's basic resident register information. The query processing unit searches for evacuation shelter information based on the resident information during a disaster, and provides the evacuation shelter information to the user.

In addition, recent developments in information processing and communication technologies have made it possible for patients to receive medical treatment online.

For example, Patent Document 2 describes a server that supports remote medical care, which allows medical institutions to share prescriptions with pharmacies and enables patients to smoothly receive their medication.

JP 2014-041507 A Patent No. 6781491

As mentioned above, when a large-scale disaster is predicted, residents will evacuate to evacuation shelters. There are often multiple evacuation shelters to which residents can evacuate, but residents often cannot decide which shelter to evacuate to.

However, this problem cannot be solved by applying the technologies disclosed in the above-mentioned Patent Documents 1 and 2. This is because the disclosure in Patent Document 1 only deals with selecting residents to evacuate on a priority basis. Furthermore, the disclosure in Patent Document 2 is a document about online medical care, and is unrelated to residents' selection of evacuation shelters.

The primary objective of the present invention is to provide a server device, a system, a control method for a server device, and a storage medium that contribute to guiding residents to appropriate evacuation shelters.

According to a first aspect of the present invention, a server device is provided that includes a generation unit that generates evacuation information including information on a shelter to which a resident is directed based on the resident's health information, and a transmission unit that transmits the generated evacuation information to a terminal carried by the resident.

According to a second aspect of the present invention, a system is provided which includes a municipal server and a hospital server which selects residents who live in an area designated by a disaster prevention officer from among a plurality of residents and transmits evacuation information to a terminal carried by the selected residents, wherein the municipal server acquires health information of the selected residents from the hospital server by data sharing, and selects an evacuation shelter to which the selected residents should be directed based on the acquired health information.

According to a third aspect of the present invention, a method for controlling a server device is provided, in which the server device generates evacuation information including information on evacuation shelters to which the residents should be directed based on the residents' health information, and transmits the generated evacuation information to a terminal carried by the resident.

According to a fourth aspect of the present invention, a computer-readable storage medium is provided that stores a program for causing a computer mounted on a server device to execute a process of generating evacuation information including information regarding evacuation shelters to which residents should be directed based on health information of the residents, and a process of transmitting the generated evacuation information to a terminal carried by the resident.

According to each aspect of the present invention, a server device, a system, a method for controlling a server device, and a storage medium are provided that contribute to guiding residents to appropriate evacuation shelters. Note that the effects of the present invention are not limited to the above. The present invention may achieve other effects instead of or in addition to the effects.

FIG. 1 is a diagram for explaining an overview of an embodiment. FIG. 2 is a diagram illustrating 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. FIG. 7 is a diagram illustrating an example of a processing configuration of the local government server according to the first embodiment. FIG. 8 is a diagram for explaining the operation of the resident registration unit according to the first embodiment. FIG. 9 is a diagram illustrating an example of a resident information database according to the first embodiment. FIG. 10 is a diagram illustrating an example of a processing configuration of the evacuation information control unit according to the first embodiment. FIG. 11 is a flowchart illustrating an example of the operation of the 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 illustrating an example of the evacuation shelter information database according to the first embodiment. FIG. 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. 16 is a diagram illustrating an example of a processing configuration of the hospital server according to the first embodiment. FIG. 17 is a diagram illustrating an example of a patient information database according to the first embodiment. FIG. 18 is a diagram for explaining the operation of the shared control unit according to the first embodiment. FIG. 19 is a sequence diagram showing an example of the operation of the disaster prevention system according to the first embodiment. FIG. 20 is a diagram illustrating an example of a resident information database according to the second embodiment. FIG. 21 is a diagram illustrating an example of a schematic configuration of a disaster prevention system according to the second embodiment. FIG. 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. 24 is a diagram illustrating an example of a processing configuration of the 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. FIG. 27 is a diagram illustrating an example of a processing configuration of a medical terminal according to the third embodiment. FIG. 28 is a diagram for explaining the operation of the biometric information acquiring unit according to the third embodiment. FIG. 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 the 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. FIG. 32 is a diagram illustrating an example of a hardware configuration of a local government server according to the present disclosure. FIG. 33 is a diagram for explaining the operation of the local government server according to the modified example of the present disclosure.

First, an overview of one embodiment will be described. The reference numbers in the drawings are added to each element for convenience as an example to aid in understanding, and the description of this overview is not intended to be limiting. Furthermore, unless otherwise specified, the blocks shown in each drawing represent functional units rather than hardware units. The connection lines between blocks in each drawing include both bidirectional and unidirectional. The unidirectional arrows are used to show the main signal (data) flow diagrammatically, and do not exclude bidirectionality. In this specification and drawings, elements that can be described in the same way may be given the same reference numbers to avoid duplicated explanations.

The server device 100 according to one embodiment includes a generating unit 101 and a transmitting unit 102 (see FIG. 1). The generating unit 101 generates evacuation information including information about the evacuation shelter to which the resident is directed based on the resident's health information. The transmitting unit 102 transmits the generated evacuation information to a terminal carried by the resident.

When sending evacuation information to residents, the server device 100 selects a shelter taking into consideration the resident's health condition and notifies the resident of information related to the selected shelter (e.g., the name and location of the shelter). For example, for residents with no health concerns, the server device 100 selects a shelter that does not have any special facilities, and uses the evacuation information to guide the resident to the shelter. In contrast, for residents with health concerns, the server device 100 selects a shelter with a doctor or nurse on-site or a shelter equipped with medical facilities, and uses the evacuation information to guide the resident to the shelter. In this way, the server device 100 can guide residents living in the area to which the evacuation information is sent to a shelter that is suitable for them.

Specific embodiments are described in further detail below with reference to the drawings.

[First embodiment]
The first embodiment will be described in more detail with reference to the drawings.

[System Configuration]
Fig. 2 is a diagram showing an example of a schematic configuration of a disaster prevention system according to the first embodiment. As shown in Fig. 2, the disaster prevention system includes a disaster prevention center, at least one or more hospitals, and at least one or more evacuation shelters.

Disaster prevention centers are managed and operated by local governments. Disaster prevention centers are set up in city halls, for example. Local schools, community centers, and other facilities serve as evacuation shelters. Schools, community centers, and other facilities are used as "evacuation shelters" 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 is responsible for managing disaster prevention for local residents, operating evacuation shelters, supporting evacuees, etc. The local government server 10 may be installed in the same building as the disaster prevention center, or it may be installed on a network (on the cloud).

Each hospital is equipped with a hospital server 20. The hospital server 20 stores the patient's medical results (examination results, treatment results). The hospital server 20 stores the patient's medical results, etc. as "electronic medical records." The hospital server 20 centrally manages the patient's basic information, medical information related to medical treatment, vital data, medication information related to medication, etc. through the electronic medical records.

A patient's basic information includes information on the patient ID (identifier), name, date of birth, address, contact information, medical history, etc. Medical information includes the patient's chief complaint (information written on the medical questionnaire), test results (results of X-rays, etc.), diagnosis (name of disease confirmed by diagnosis; current symptom), treatment plan, etc. Vital data includes information on blood pressure, pulse, body temperature, etc. (measurement results, measurement history). Medication information includes the name of prescribed medication and medication instructions (timing of taking medication, dosage), etc.

The functions of the hospital server 20 provided at each hospital can be identical, so the following explanation will focus on the hospital server 20 installed at Hospital A.

Each device shown in Figure 2 is connected to each other. For example, 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.

The configuration of the disaster prevention system shown in FIG. 2 is an example and is not intended to be limiting. For example, a disaster prevention center may include multiple local government servers 10. Similarly, each hospital may include multiple hospital servers 20.

[Operation Overview]
Next, an outline of the operation of the disaster prevention system according to the first embodiment will be described.

In the disaster prevention system according to the first embodiment, when a disaster is expected to occur, evacuation information is transmitted from the disaster prevention center to each resident. The evacuation information includes information regarding the evacuation destination (e.g., the name and location of the evacuation shelter). When transmitting the evacuation information, the disaster prevention center checks the situation and condition of each resident, selects an appropriate evacuation shelter for each resident, and encourages them to evacuate. In particular, the disaster prevention center determines the evacuation shelter to which the resident should be directed, taking into consideration the resident's health condition.

When deciding on an evacuation shelter, the disaster prevention center obtains each resident's "health information" from the hospital (the resident's primary care hospital). Based on the obtained health information, the disaster prevention center selects an appropriate evacuation shelter for each resident and guides the resident to the shelter. Note that health information is specific information (data) about the health of each resident. For example, health information may include a resident's medical history, current illness, medication information, etc.

<Resident registration>
First, local residents pre-register their own information with the local government (disaster prevention center) (see FIG. 3). In the following description, the information that residents register with the local government server 10 is referred to as "resident information."

Residents register resident information in the local government server 10 using any means. For example, the resident operates the terminal 30 that he or she owns to register as a resident. For example, the resident operates the terminal 30 to access the local government server 10. More specifically, the resident accesses a WEB page provided by the local government server 10.

For residents who have difficulty registering information themselves, such as young children or elderly people, parents or children may register resident information regarding young children, elderly people, etc. on their behalf on the local government server 10.

Resident information includes personal information (the so-called four basic pieces of information: name, gender, address, and date of birth). Resident information also includes the resident's contact information (for example, an email address and telephone number that can be received by terminal 30).

In addition to the above information, resident information also includes information about the resident's regular hospital (hereinafter referred to simply as hospital information). Specifically, the name of the regular hospital, the patient ID issued by the regular hospital, etc. are included in the "hospital information."

In addition, residents who do not have a regular hospital do not need to register hospital information with the disaster prevention center (municipality server 10).

When the local government server 10 acquires personal information and hospital information from a resident, it generates a resident ID to identify 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.

<Data sharing permission>
A resident who has a family hospital sets up a permission for the hospital to share data (provide data) with the disaster prevention center (local government) before or after the above-mentioned resident registration. For example, the resident operates the terminal 30 to access the hospital server 20 of the family hospital (see FIG. 4). More specifically, the resident accesses a WEB page provided by the hospital server 20.

On the web page, the resident gives permission to provide to an external party all or part of the data recorded in the electronic medical record stored and managed by the family hospital. For example, the hospital server 20 displays a GUI (Graphical User Interface) and an input form as shown in Figure 5 on the terminal 30 held by the resident.

Residents operate the terminal 30 to input into the hospital server 20 the "purpose" of data sharing, the "type" of data to be shared, the "destination" of the data, and the "conditions" for sharing the data.

For example, a resident inputs into the hospital server 20 the purpose of data sharing "evacuation shelter information," the types of data to be shared "pre-existing conditions," "current conditions," and "medication information," the data sharing destination "disaster prevention center," and the condition for data sharing "when an evacuation order or greater is issued."

The hospital server 20 manages the information regarding data sharing acquired from the above residents as "sharing permission information." The hospital server 20 associates the resident's patient ID, electronic medical record ID (medical record ID), and sharing permission information and stores them in the patient information database. Details of the patient information database will be described later.

The above resident registration and data sharing permission are preparations that are made before a disaster occurs. Next, with reference to Figure 6, we will explain the operation of the disaster prevention system when a disaster occurs.

<Evacuation information transmission>
When a disaster is expected to occur due to a typhoon, heavy rain, or the like, a disaster prevention officer of a local government inputs an "evacuation information transmission instruction" to the local government server 10 (step S1). For example, the disaster prevention officer inputs the evacuation information transmission instruction to the local government server 10 together with an alert level.

In response to the instruction, the local government server 10 transmits "evacuation information" to local residents. For example, if the alert level is "5," "urgent safety assurance" is transmitted to local residents, if the alert level is "4," an evacuation order is transmitted to local residents, and if the alert level is "3," "evacuation information" is transmitted to local residents in response to the respective instructions.

At that time, the local government server 10 generates evacuation information suitable for each resident (optimized and personalized for each resident) and transmits the evacuation information to the terminal 30 carried by each resident.

When generating evacuation information, for residents who have a set family hospital, the local government server 10 acquires the resident's health information from the family hospital through data sharing. Specifically, the local government server 10 refers to the resident information database and determines whether or not the resident to whom the evacuation information is to be sent has a family hospital. If a family hospital has been set, the local government server 10 sends a "data sharing request" to the hospital server 20 of that hospital (step S2).

Specifically, the local government server 10 refers to the resident information database and reads out the patient ID of the resident who has a family hospital set up. The local government server 10 sends a "data sharing request" including the read-out patient ID to the hospital server 20.

In addition to the patient ID, the data sharing request includes the "purpose of use" of the shared data, the "type" of the shared data, and the "recipient" of the shared data. For example, the purpose of use of the shared data is set to "evacuation shelter guidance when an evacuation order is issued," the type of shared data is set to "current symptoms," and the recipient of the shared data is set to "disaster prevention center."

The hospital server 20 verifies the data sharing request received from the local government server 10.

When the hospital server 20 receives a data sharing request, it searches the patient information database using the patient ID included in the request as a key, and identifies the corresponding medical record ID (electronic medical record ID) and sharing permission information.

The hospital server 20 verifies whether the "purpose of use" included in the received data sharing request matches the "purpose" and "conditions" included in the sharing permission information identified above, and whether the destination of the shared data matches the "destination" in the sharing permission information.

If these verifications are successful, the hospital server 20 determines that data sharing with the local government server 10 is possible. In this case, the hospital server 20 reads data corresponding to the data type set in the sharing permission information from the electronic medical record of the patient. For example, if data sharing regarding "current symptoms" has been consented to, specific disease names such as "stomach cancer" or "lung cancer" are read from the electronic medical record.

The hospital server 20 sends a "health information notification" to the local government server 10, which includes the patient ID of the patient (resident) who is the subject of data sharing and the read data (shared data) (step S3).

The local government server 10 refers to the health information obtained from the hospital server 20 and generates evacuation information appropriate for residents (residents who have a designated family hospital).

For example, if the local government server 10 determines that resident A does not have a regular hospital and has no health concerns, it generates evacuation information that guides resident A to evacuation shelter B as an evacuation destination. Evacuation shelter B is a normal evacuation shelter with no special equipment or personnel.

Alternatively, if the local government server 10 determines that resident B has a designated family hospital and is concerned about his or her health, it generates evacuation information that guides resident B to evacuation shelter A as an evacuation destination. Evacuation shelter A is a shelter with doctors and nurses on-site and is well-equipped with medical facilities.

The local government server 10 transmits the generated evacuation information to the terminals 30 carried by each resident (step S4).

Each resident will check the evacuation information displayed on their terminal 30 and evacuate to the evacuation shelter listed in the evacuation information.

Next, we will explain in detail each device included in the disaster prevention system related to the first embodiment.

[Municipality server]
7 is a diagram showing an example of a processing configuration (processing module) of the local government server 10 according to the first embodiment. Referring to FIG. 7, the local government server 10 includes a communication control unit 201, a resident registration unit 202, an evacuation information control unit 203, and a storage unit 204.

The communication control unit 201 is a means for controlling communication with other devices. For example, the communication control unit 201 receives data (packets) from the hospital server 20. The communication control unit 201 also transmits data to the hospital server 20. The communication control unit 201 passes the data received from the other devices to the other processing modules. The communication control unit 201 transmits the data acquired from the other processing modules to the other devices. In this way, the other processing modules transmit and receive data with the other devices via the communication control unit 201. The communication control unit 201 has a function as a receiving unit that receives data from other devices and a function as a transmitting unit that transmits data to the other devices.

The resident registration unit 202 is a means for realizing the above-mentioned resident registration. The resident registration unit 202 is a means for acquiring resident information for each of a number 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.

For example, the resident registration unit 202 may acquire the resident information from a terminal 30 operated by the resident. Alternatively, the resident may send a document containing the resident information or an external storage device storing the resident information to a disaster prevention center, and a staff member of the center may input the resident information into the local government server 10.

The resident registration unit 202 may provide the resident with a GUI or an input form for inputting resident information. For example, the resident registration unit 202 may display a GUI such as that shown in FIG. 8 on the resident's terminal 30.

The resident operates the terminal 30 to input the information shown in Figure 8. When the resident has completed inputting the information, he or she presses the "OK" button and inputs the personal information (name, contact details, etc.) and hospital information into the local government server 10.

The resident registration unit 202 also generates a resident ID for identifying the resident. The resident ID may be any information that can uniquely identify a registered resident. For example, the resident registration unit 202 may assign a unique value each time a resident is registered as the resident ID. Alternatively, the resident registration unit 202 may obtain information equivalent 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 Figure 9). Note that the resident information database shown in Figure 9 is an example and is not intended to limit the items to be stored. For example, the resident's biometric information (e.g., a facial image or features generated from the facial image) may be registered in the resident information database. Alternatively, contact information such as the telephone number of the patient's regular hospital may be registered in the resident information database. Note that the patient ID is identification information issued by the patient's regular hospital. For example, the ID written on a patient's appointment card corresponds to the patient ID.

The evacuation information control unit 203 is a means for controlling evacuation information. As shown in FIG. 10, the evacuation information control unit 203 has sub-modules consisting of a transmission instruction acquisition unit 211, a target resident selection unit 212, a shared data acquisition unit 213, and an evacuation information generation unit 214.

The operation of the evacuation information control unit 203 will be described with reference to Figure 11. Figure 11 is a flowchart 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 a disaster prevention officer of a local government (step S101). Specifically, the transmission instruction acquisition unit 211 displays a GUI, an input form, etc. for inputting an evacuation information transmission instruction on a disaster prevention officer terminal (not shown in FIG. 6, etc.) used by the disaster prevention officer.

For example, the transmission instruction acquisition unit 211 displays a GUI such as that shown in Fig. 12 on the disaster prevention officer terminal. The disaster prevention officer selects the alert level and the area for which evacuation information is to be issued.

The target resident selection unit 212 selects residents to whom evacuation information is to be sent (step S102). The target resident selection unit 212 refers to the resident information database and selects residents in the area entered by the disaster prevention officer (area for which evacuation information is to be issued). The target resident selection unit 212 refers to the address field of the resident information database and extracts residents (entries) who live in the area for which evacuation information is to be issued. The extracted residents are the residents to whom evacuation information is to be sent.

The shared data acquisition unit 213 is a means for acquiring health information of a resident from the resident's family hospital. The shared data acquisition unit 213 acquires health information from the hospital server 20 by data sharing. The shared data acquisition unit 213 acquires health information by sending a data sharing request regarding the health information to the hospital server 20 of the family hospital.

The shared data acquisition unit 213 checks the hospital information of each resident extracted as a recipient of the above evacuation information and determines whether or not a regular hospital has been set (step S103).

If a family hospital has not been set (step S103, No branch), the shared data acquisition unit 213 does not perform any special operation. In this case, the processing from step S106 onwards is executed.

If a regular hospital is set (step S103, Yes branch), the shared data acquisition unit 213 generates a data sharing request and sends the generated data sharing request to the hospital server 20 (step S104).

Specifically, the shared data acquisition unit 213 refers to the hospital information and acquires the hospital name and patient ID of the patient's regular hospital.

The shared data acquisition unit 213 identifies the hospital server 20 to which the data sharing request is to be 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 in correspondence with the IP (Internet Protocol) address, etc., of the hospital server 20.

The shared data acquisition unit 213 generates a data sharing request including the above-mentioned patient ID and information regarding the shared data to be acquired (purpose of use, data type, data sharing destination), and sends it to the hospital server 20.

The purpose of using the shared data will be set to "provide information on evacuation shelters when evacuation orders are issued." Of the contents set above, "issuing evacuation orders" will change depending on the alert level entered by disaster prevention personnel.

In addition, the type of shared data is set as "current symptoms," and the destination of the shared data is set as "disaster prevention center." The type of data to be shared (acquired from the hospital) is based on the policy of the disaster prevention center. For example, a policy for acquiring "current symptoms," a policy for acquiring "pre-existing symptoms" and "current symptoms," and a policy for acquiring "pre-existing symptoms," "current symptoms," and "medication information" are set in advance in the local government server 10.

If more types of data are to be acquired through sharing, there is a high possibility that residents will reject the sharing, but the local government server 10 will be able to create more accurate evacuation information. On the other hand, if fewer types of data are to be acquired through sharing, there is a high possibility that residents will give their permission, but it will be difficult for the local government server 10 to create more accurate evacuation information. Disaster prevention personnel, etc. will decide the types of data to acquire through sharing (decide the policy) taking into account 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, the shared data acquisition unit 213 receives a negative response. In this case, the shared data acquisition unit 213 does not perform any special operation. The shared data acquisition unit 213 may treat a resident for whom shared data could not be acquired as a resident who does not have a set family hospital.

If data sharing is permitted, the shared data acquisition unit 213 receives a positive response. That is, the shared data acquisition unit 213 receives a "health information notification" from the hospital server 20. The health information notification includes the patient ID and health information.

As mentioned above, the health information is specific data (information) corresponding to the data type set in the data sharing request. As in the above example, when a request is made to share data on "current symptoms," 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 a means for generating evacuation information. The evacuation information generation unit 214 generates evacuation information including information regarding the evacuation shelter to which the resident is directed based on the health information of each resident.

The evacuation information generation unit 214 selects an evacuation destination (shelter) to which the residents to whom the evacuation information is to be sent (step S106). At that time, for example, the evacuation information generation unit 214 selects an evacuation destination to which the residents to whom the evacuation information is to be sent based on the health status of the target residents and the characteristics of each shelter.

The evacuation information generation unit 214 refers to a shelter information database as shown in Fig. 13 and reads out the characteristics of each shelter. As shown in Fig. 13, the shelter information database stores the shelter ID, name, location, and characteristics of each shelter in association with each other. Also, as shown in Fig. 13, there are shelters with no characteristics and shelters with multiple characteristics.

Note that the evacuation shelter information database shown in FIG. 13 is an example and is not intended to limit the items to be stored. For example, contact information for each evacuation shelter may be registered in the evacuation shelter information database. Alternatively, the number of people that each evacuation shelter can accommodate (capacity) may be registered in the evacuation shelter information database.

The evacuation information generation unit 214 refers to the residents' health information and the characteristics of each evacuation shelter, and selects a shelter that suits the resident's health condition.

For example, the evacuation information generation unit 214 selects an evacuation shelter that does not have any special features for residents with no health concerns (residents who do not have a regular hospital set; residents whose health information does not need to be taken into consideration). In this case, for example, the evacuation information generation unit 214 selects evacuation shelter B shown in FIG. 13. In this way, the evacuation information generation unit 214 can proactively select a regular evacuation shelter B, which does not have a doctor or nurse on-site, for residents with no health concerns.

For residents whose health information needs to be taken into consideration (residents who have a set family hospital), the evacuation information generation unit 214 selects a shelter based on the resident's health information (current illness in the above example) and the characteristics of the shelter. For example, if the current illness is an illness that requires observation by a doctor, the evacuation information generation unit 214 selects a shelter where a doctor or nurse is on-site. In this case, the evacuation information generation unit 214 selects shelter A or shelter C as shown in FIG. 13.

Depending on the current condition, the evacuation information generation unit 214 may select a regular evacuation shelter (e.g., evacuation shelter B). For example, if the current condition is a "broken finger," it is assumed that no special consideration is required for the resident, and so regular evacuation shelter B is selected. Alternatively, the evacuation information generation unit 214 may select regular evacuation shelter B for a resident who has a designated family hospital but is clearly determined to have no health problems based on health information.

The selection of the resident's health condition and the evacuation shelter may be based on predetermined table information, etc., or may be performed using a learning model implemented in the local government server 10. For example, the local government server 10 may be implemented with a learning model that, when a current symptom is input, outputs the characteristics of a shelter that matches the current symptom.

In this way, for residents who are determined to have health concerns based on their health information, the evacuation information generation unit 214 selects an evacuation shelter where a doctor or nurse is on-site, or an evacuation shelter equipped with medical facilities.

When the evacuation information generating unit 214 acquires "medication information" through data sharing, it may select an evacuation shelter based on the medication information and the characteristics of the evacuation shelter. For example, the evacuation information generating unit 214 may select an evacuation shelter that keeps the medication taken by the resident in stock. For example, in the example of FIG. 13, evacuation shelter C is selected for a resident who is taking medication A.

The evacuation information generation unit 214 generates evacuation information based on the alert level input by the disaster prevention officer and the selected evacuation shelter (step S107). For example, for residents with no health concerns (residents whose health information does not need to be taken into consideration), evacuation information such as that shown in Figure 14 is generated. In contrast, for residents whose health information needs to be taken into consideration, evacuation information such as that shown in Figure 15 is generated.

The evacuation information control unit 203 transmits the generated evacuation information to the terminal 30 carried by the resident (step S108). The evacuation information control unit 203 transmits the evacuation information to the contact information of each resident listed in the resident information database (e.g., an email address that the terminal 30 can receive).

If there are any remaining residents to whom evacuation information is to be sent (step S109, Yes branch), the evacuation information control unit 203 returns to step S102 and continues processing. If there are no remaining residents to whom evacuation information is to be sent (step S109, No branch), the evacuation information control unit 203 ends processing.

The memory unit 204 is a means for storing information necessary for the operation of the local government server 10. A resident information database, an evacuation shelter information database, etc. are constructed in the memory unit 204.

[Hospital Server]
Fig. 16 is a diagram showing an example of a processing configuration (processing module) of the hospital server 20 according to the first embodiment. Referring to Fig. 16, the hospital server 20 includes a communication control unit 301, a permission information acquisition unit 302, a sharing control unit 303, and a storage unit 304.

The communication control unit 301 is a means for controlling communication with other devices. For example, the communication control unit 301 receives data (packets) from the local government server 10. The communication control unit 301 also transmits data to the local government server 10. The communication control unit 301 passes the data received from the other devices to the other processing modules. The communication control unit 301 transmits data acquired from the other processing modules to the other devices. In this way, the other processing modules transmit and receive data with the other devices via the communication control unit 301. The communication control unit 301 has a function as a receiving unit that receives data from other devices and a function as a transmitting unit that transmits data to the other devices.

The permission information acquisition unit 302 is a means for acquiring sharing permission information. A user who wishes to set up data sharing with their family hospital accesses the website managed and operated by the hospital and logs in to an account for managing patient information, etc. At that time, the user enters the patient ID assigned to them into the website. The permission information acquisition unit 302 acquires the patient ID and identifies the user (patient) who wishes to set up data sharing permission.

When a user accesses a page for setting up data sharing permission, the permission information acquisition unit 302 displays a GUI such as that shown in Fig. 5 on the terminal 30 held by the user. The permission information acquisition unit 302 acquires from the terminal 30 the purpose of data sharing, the type of data, the data sharing destination, and the conditions for data sharing.

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 stores the patient ID, medical record ID, and sharing permission information in association with each other in the patient information database (see FIG. 17).

Note that the patient information database shown in FIG. 17 is an example and is not intended to limit the items to be stored. For example, the patient's biometric information (e.g., a facial image or features generated from the facial image) may be registered in the patient information database.

In addition, a patient ID and a medical record ID are generated at the time of the patient's first visit, and when these IDs are generated, they are added to the patient information database. The generation of patient IDs and the generation and management of electronic medical records including medical record IDs are clear to those skilled in the art, and are not within the spirit of the present disclosure, so detailed explanations will be omitted.

The sharing control unit 303 is a means for controlling data sharing. The operation of the sharing control unit 303 will be explained with reference to FIG. 18. FIG. 18 is a flowchart 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 (municipality server 10) (step S201).

The sharing control unit 303 verifies the acquired data sharing request. The sharing control unit 303 performs two verifications (two-stage verification).

First, 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 the "purpose of use" included in the data sharing request matches the "purpose" and "conditions" included in the sharing permission information identified above (first verification; step S203).

For example, if the purpose approved by the patient is "evacuation shelter guidance," the condition for data sharing is "when an evacuation order or higher is issued," and the purpose of using the shared data is "evacuation shelter guidance following the issuance of an evacuation order," the sharing control unit 303 determines that the first verification for data sharing has been successful.

On the other hand, if the purpose approved by the patient is "evacuation shelter guidance," the condition is "when an evacuation order or higher is issued," and the purpose of using the shared data is "provision of diet information," the sharing control unit 303 determines that the first verification for data sharing has failed.

If the first verification fails (step S204, No branch), the sharing control unit 303 sets the data to be unshareable (step S205).

If the first verification is successful (step S204, Yes branch), the sharing control unit 303 executes the second verification (step S206). Specifically, the sharing control unit 303 verifies whether the sharing destination included in the data sharing request matches the "sharing destination" in the sharing permission information.

For example, if the patient grants permission to share data with a disaster prevention center and the sharing destination included in the data sharing request is also the disaster prevention center, the sharing control unit 303 determines that the second verification for data sharing has been successful.

On the other hand, if the patient has given permission for data sharing to the disaster prevention center, but the sharing destination included in the data sharing request is a "sports gym," the sharing control unit 303 determines that the second verification for data sharing has failed.

If the second verification fails (step S207, No branch), the sharing control unit 303 sets the data to be unshareable (step S205).

If the second verification is successful (step S207, Yes branch), the sharing control unit 303 sets the data to be shareable (step S208).

The sharing control unit 303 sends a response to the data sharing request (step S209).

If data sharing is not possible, the sharing control unit 303 sends a negative response to that effect to the local government server 10.

If data sharing is possible, the sharing control unit 303 reads the medical record 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 with whom data is to be shared. The sharing control unit 303 reads out the items in the identified electronic medical record that are set to "Agreement" in the sharing permission information (items in the data type field of the patient information database).

For example, as shown in the first row of FIG. 17, if the data type for which data sharing is permitted is "current symptom," the sharing control unit 303 reads data labeled as "current symptom" from the electronic medical record. For example, a specific disease name such as "stomach cancer" or "lung cancer" is read.

When the sharing control unit 303 reads out data for which data sharing has been permitted, it generates a health information notification that includes the read out data and the patient ID of the subject (patient) of data sharing, and transmits the information to the sender of the data sharing request (the sharing destination; local government server 10). The health information notification is treated as a positive response to the data sharing request.

The memory unit 304 is a means for storing information necessary for the operation of the hospital server 20. A patient information database, a database constituting an electronic medical record, etc. are constructed in the memory unit 304. The hospital server 20 stores in the memory unit 304 sharing permission information regarding the data sharing with the local government server 10 of at least a portion of the data recorded in the patient's electronic medical record.

[Device]
Examples of the terminal 30 include mobile terminal devices such as smartphones, mobile phones, game consoles, and tablets, as well as computers (personal computers, laptop computers), etc. The terminal 30 can be any equipment or device that can accept operations from residents and communicate with the local government server 10, etc. Furthermore, the configuration of the terminal 30 is clear to those skilled in the art, so a detailed description will be omitted.

[System Operation]
Next, the operation of the disaster prevention system according to the first embodiment will be described. Note that the description of the operation related to the resident registration and the data sharing permission will be omitted. Fig. 19 is a sequence diagram showing an example of the operation of the disaster prevention system according to the first embodiment.

The local government server 10 receives an instruction to send evacuation information from the disaster prevention officer (step S01).

The local government server 10 selects residents to whom evacuation information is to be sent (step S02).

If the selected resident is a resident whose health condition needs to be taken into consideration (if the resident has a set family hospital), the local government server 10 sends a data sharing request to the hospital server 20 of the family hospital (step S03).

Upon receiving the data sharing request, the hospital server 20 verifies the request (step S04). The hospital server 20 verifies the purpose of use and the sharing destination of the data sharing request.

If the verification is successful, the hospital server 20 reads out specific data from the patient's electronic medical record that corresponds to the data type for which the patient has consented to data sharing. The hospital server 20 sends a health information notification including the read out data to the local government server 10 (step S05).

In this way, the hospital server 20 verifies the data sharing request using the sharing permission information, and if the data sharing request verification is successful, reads out data corresponding to the type of data authorized by the patient from the electronic medical record. The hospital server 20 notifies the local government server 10 of the read out data as health information.

Upon receiving the health information notification, the local government server 10 selects an evacuation shelter to which the resident should be directed based on the resident's health condition (health information) (step S06).

The local government server 10 generates evacuation information including information about the selected evacuation shelter (the name and location of the evacuation shelter) and transmits it to the terminal 30 carried by the resident (step S07).

The terminal 30 outputs the received evacuation information (step S08). For example, the terminal 30 takes action such as displaying the evacuation information on a monitor or reading the evacuation information from a speaker.

As described above, in the disaster prevention system according to the first embodiment, the local government server 10 selects residents who live in an area designated by the disaster prevention officer from among a plurality of residents, and transmits evacuation information to the terminal 30 carried by the selected resident. At that time, the local government server 10 acquires health information of the selected resident from the hospital server 20 by data sharing. The local government server 10 selects an evacuation shelter to which the resident will be directed based on the acquired health information. As a result, for residents with health concerns, an evacuation shelter with a doctor on-site and ample medical facilities is selected. In contrast, for residents with no health concerns, a normal evacuation shelter is selected. Due to the function of the local government server 10 in this way, healthy people will not evacuate to an evacuation shelter with ample medical facilities, and residents with health concerns can more reliably evacuate to the above-mentioned evacuation shelter.

In addition, by allowing residents to set the types of data that can be shared with the hospital, information that residents do not want to be made known to outsiders can be appropriately protected. In other words, rather than providing electronic medical record information directly to the disaster prevention center (local government; local government server 10), conditions and scope restrictions are set for data sharing, so that residents' privacy is appropriately protected.

Second Embodiment
Next, the second embodiment will be described in detail with reference to the drawings.

In the first embodiment, a case has been described in which a resident sets his/her regular hospital as shared data that can be provided to the local government (disaster prevention center) in the event of a disaster. The local government uses the data shared from the hospital to provide evacuation shelters based on each resident's health condition. The local government uses health information (past illnesses, current illnesses, medication information, etc.) to determine an evacuation destination personalized for each resident. That is, in the first embodiment, the configuration and operation of the system before the resident evacuates to a shelter have been described.

In the second embodiment, data utilization after evacuation is described. Specifically, the local government server 10 identifies residents who have arrived at an evacuation shelter through biometric authentication. The local government server 10 provides information about the identified residents to the family hospital (hospital server 20).

Below, we will mainly explain the differences between the first and second embodiments.

In the second embodiment, a resident inputs his/her biometric information (e.g., a facial image) to the local government server 10. The resident registration unit 202 of the local government server 10 generates features from the facial image, and stores the features (biometric information) in the resident information database in association with a resident ID, etc. (see FIG. 20).

Figure 21 is a diagram showing an example of the schematic configuration of a disaster prevention system according to the second embodiment. As shown in Figure 21, each evacuation shelter is equipped with a reception terminal 40 that receives evacuees. Note that the configuration and operation of the reception terminals 40 installed at each evacuation shelter can be the same, so the following explanation will focus on the configuration, etc. of the reception terminal 40 installed at evacuation shelter A.

When evacuation information is acquired, residents evacuate to an evacuation shelter. The evacuees move in front of the reception terminal 40 installed at the evacuation shelter.

The reception terminal 40 photographs the evacuees and acquires facial images. The reception terminal 40 transmits a "refugee arrival notification" to the local government server 10, which includes the acquired facial images and the evacuation shelter IDs assigned to each evacuation shelter.

The local government server 10 performs a matching process using the acquired facial image to identify the resident who has arrived at the evacuation shelter. The local government server 10 reflects the resident's evacuation destination in the resident information database (see the evacuation shelter field in Figure 20).

In the example of Figure 20, it is registered in the resident information database that a resident with a set family hospital (resident with ID 31) has evacuated to shelter A, while a resident with a set family hospital (resident with ID 32) has evacuated to shelter B. Note that resident with ID 32 would have been instructed to evacuate to shelter A, but it is assumed that for some reason he evacuated to shelter B. Shelter B is a normal shelter with no doctors or nurses on-site.

The local government server 10 accesses the resident information database periodically or at a specified timing. The local government server 10 extracts residents who have a designated family hospital and who have evacuated to an evacuation shelter. In the example of Figure 20, residents with IDs 31 and 32 are extracted.

The local government server 10 transmits "patient evacuation destination information" to the extracted resident's family hospital. The patient evacuation destination information includes information on the evacuation destination of the resident (patient at the family hospital) and the patient ID. In the example of Figure 20, patient evacuation destination information is transmitted to Hospital A indicating that patient with pID31 has evacuated to evacuation shelter A, and patient evacuation destination information is transmitted to Hospital B indicating that patient with pID41 has evacuated to evacuation shelter B.

The hospital server 20 that receives the patient evacuation destination information notifies doctors, nurses, etc. of the patient's evacuation destination. Doctors, etc. can understand the evacuation destination of their hospital's patients and can determine whether the evacuation destination is appropriate or not. For example, patients at Hospital B are evacuated to a regular evacuation shelter where no doctors, etc. are on-site, and the doctors, etc. at Hospital B determine whether the evacuation destination is appropriate or not.

The processing configuration of each device relating to the second embodiment will be explained.

[Reception terminal]
Fig. 22 is a diagram showing an example of a processing configuration (processing module) of the reception terminal 40. Referring to Fig. 22, the reception terminal 40 includes a communication control unit 401, a biometric information acquisition unit 402, a refuge arrival notification unit 403, and a storage unit 404.

The communication control unit 401 is a 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 passes the data received from the other devices to the other processing modules. The communication control unit 401 transmits data acquired from the other processing modules to the other devices. In this way, the other processing modules transmit and receive data with the other devices via the communication control unit 401. The communication control unit 401 has a function as a receiving unit that receives data from other devices and a function as a transmitting unit that transmits data to the other devices.

The biometric information acquisition unit 402 is a means for controlling a camera device (a camera device provided in the reception terminal 40) and acquiring biometric information (e.g., facial images) of evacuees in front of the device. The biometric information acquisition unit 402 captures an image in front of the device periodically or at a specified timing. The biometric information acquisition unit 402 determines whether the acquired image contains a human facial image, and if a facial image is included, extracts the facial image from the acquired image data.

Note that the facial image detection process and facial image extraction process performed by the biometric information acquisition unit 402 can use existing technology, so detailed explanations will be omitted. For example, the biometric information acquisition unit 402 may extract a facial image (face area) from image data using a learning model trained by a CNN (Convolutional Neural Network). Alternatively, the biometric information acquisition unit 402 may extract a facial image using a method such as template matching.

The biometric information acquisition unit 402 passes the extracted facial image to the evacuee arrival notification unit 403.

The evacuee arrival notification unit 403 is a means for notifying the local government server 10 of the arrival of an evacuee. The evacuee arrival notification unit 403 generates a "evacuee arrival notification" including the acquired facial image and evacuation shelter ID, and transmits it to the local government server 10.

The evacuation shelter ID is shared between the reception terminal 40 and the local government server 10 by any means. For example, a system administrator (a disaster prevention center staff member) may assign an evacuation shelter ID to each evacuation shelter and set the assigned evacuation shelter ID in the reception terminal 40.

The memory unit 404 is a means for storing information necessary for the operation of the reception terminal 40.

[Municipality server]
Fig. 23 is a diagram showing an example of a processing configuration (processing module) of the local government server 10 according to the second embodiment. Referring to Fig. 23, 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 for managing residents who have evacuated to evacuation shelters. The resident evacuation destination management unit 205 receives a notification of an evacuee's arrival from a reception terminal 40 installed at the evacuation shelter. Since the notification includes the evacuee's biometric information (facial image), the resident evacuation destination management unit 205 extracts the facial image from the evacuee arrival notification. The resident evacuation destination management unit 205 generates features from the acquired facial image.

Existing technology can be used for the process of generating features, so a detailed description will be omitted. For example, the resident evacuation destination management unit 205 extracts the eyes, nose, mouth, etc. from the facial image as feature points. The resident evacuation destination management unit 205 then calculates the position of each feature point and the distance between each feature point as feature amounts, and generates a feature vector (vector information that characterizes the facial image) consisting of multiple feature amounts.

The resident evacuation destination management unit 205 sets the feature amount calculated based on the face image acquired from the reception terminal 40 as the object of matching, and performs a matching process with the feature amount registered in the resident information database. More specifically, the resident evacuation destination management unit 205 sets the calculated feature amount (feature vector) as the object of matching, and performs a 1:N (N is a positive integer, the same below) matching with the multiple feature amounts registered in the resident information database.

The resident evacuation destination management unit 205 calculates the similarity between the feature to be compared and each of the multiple feature values on the registration side. The similarity can be calculated using chi-square distance, Euclidean distance, or the like. 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 identifies the feature that is closest to the feature to be compared (the feature with the highest similarity) among the features registered in the resident information database, for which the similarity is equal to or greater than a predetermined value. The resident evacuation destination management unit 205 sets the evacuation shelter ID (the name of the evacuation shelter) notified by the evacuation shelter in the evacuation shelter field of the entry corresponding to the identified feature.

If an entry having a feature value with a similarity equal to or greater than a predetermined value is not registered in the resident information database, the resident evacuation destination management unit 205 determines that the resident corresponding to the face image notified from the evacuation shelter is not registered. In this case, the resident evacuation destination management unit 205 does not need to perform any special operation, or may perform statistical processing such as tallying up the number of users who are not registered.

The patient evacuation destination notification unit 206 is a means for notifying hospitals of the evacuation destination of patients who have a designated family hospital. The patient evacuation destination notification unit 206 accesses the resident information database periodically or at a specified timing. The patient evacuation destination notification unit 206 extracts residents who have a designated family hospital and have evacuated to an evacuation shelter.

The patient evacuation destination notification unit 206 transmits information about the patient's evacuation destination (such as the name of the evacuation shelter and contact information) and the patient ID to the extracted resident's family hospital. Note that there is no need to notify the hospital of the evacuation destination multiple times for the same resident.

[Hospital Server]
Fig. 24 is a diagram showing an example of a processing configuration (processing module) 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 of providing hospital staff (doctors, nurses, etc.) with information regarding evacuation destinations for patients at the hospital.

Upon receiving the patient evacuation destination information, the patient information providing 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 destination information. The patient information providing unit 305 generates patient information including information on the patient's evacuation destination (name of the evacuation shelter, contact information), the patient's name, and information written in the electronic medical record.

The patient information providing unit 305 displays the generated patient information on an LCD 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 a doctor, a nurse, or the like.

[System Operation]
Next, a description will be given of the operation of the disaster prevention system 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.

When the reception terminal 40 detects an evacuee, it acquires the biometric information (facial image) of the evacuee. The reception terminal 40 transmits an evacuee arrival notification including the acquired facial image to the local government server 10 (step S11).

The local government server 10, which has received the notification of the arrival of the evacuee, identifies the evacuee through a matching process using the biometric information of the evacuee (step S12). The local government server 10 registers the evacuation destination of the identified evacuee in the resident information database.

If the evacuee has a regular hospital, the local government server 10 generates patient evacuation destination information and transmits it to the hospital server 20 of the regular hospital (step S13).

Based on the patient evacuation destination information, the hospital server 20 generates patient information (information regarding the evacuation shelter, information including the patient's electronic medical record) regarding the patients who have evacuated to the evacuation shelter (step S14).

The hospital server 20 provides the generated patient information to the hospital's doctors, nurses, etc. (step S15).

As described above, in the second embodiment, the reception terminal 40 installed at each evacuation shelter transmits an evacuee arrival notification including biometric information of the evacuee who has arrived to the local government server 10. The local government server 10 identifies the evacuee who has arrived by a matching process using the biometric information included in the evacuee arrival notification. The local government server 10 transmits patient evacuation destination information including the evacuation destination of the evacuee who has arrived to the hospital server 20 of the identified resident's family hospital. Doctors at the family hospital can know where their patients are evacuated to and can consider and verify the evacuation destination. For example, if the doctor at the family hospital determines that the patient's evacuation destination is inappropriate, he or she can contact the evacuation shelter and take measures such as inviting the patient to his or her own hospital.

[Third embodiment]
Next, a third embodiment will be described in detail with reference to the drawings.

In the third embodiment, as in the second embodiment, the use of data after evacuation will be described. Specifically, a case will be described in which a doctor at an evacuation shelter obtains necessary information from a hospital to diagnose a patient (evacuee).

The following will focus on the differences between the first to third embodiments.

As shown in Fig. 26, all or some of the evacuation shelters in the disaster prevention system according to the third embodiment are equipped with a medical terminal 50 used by doctors and the like. The medical terminal 50 is equipped with a display device visible to the doctor and a display device visible to the patient. In addition, a camera is installed on the display device visible to the patient, and is configured to be able to capture an image of the patient's face.

Evacuees who take refuge at a shelter where a doctor is on-site (shelter A in the above example) can receive a doctor's diagnosis on a regular or specified basis.

The doctor uses the medical terminal 50 to make a diagnosis. The doctor operates the medical terminal 50 to check the electronic medical record of the evacuee (patient) in front of him/her. In doing so, the medical terminal 50 acquires biometric information (e.g., a facial image) of the patient in front of him/her. The medical terminal 50 sends an authentication request including the acquired facial 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. If authentication is successful, the local government server 10 transmits the identified patient's hospital information (the name of the patient's family hospital and the patient ID) to the medical terminal 50.

The medical terminal 50 identifies the family hospital from the hospital name and sends a "request for electronic medical records" 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 request for electronic medical record as a key to identify the patient. The hospital server 20 identifies the electronic medical record based on the medical record ID of the identified patient and reads out its contents.

The hospital server 20 sends a response (response to the request for providing the electronic medical record) including the read electronic medical record to the medical terminal 50.

The medical terminal 50 displays the received electronic medical record. The doctor diagnoses the patient while checking the electronic medical record.

The processing configuration of each device relating to the third embodiment will be explained.

[Medical terminal]
Fig. 27 is a diagram showing an example of a processing configuration (processing module) of the medical terminal 50. Referring to Fig. 27, the medical terminal 50 includes a communication control unit 501, a biometric information acquisition unit 502, an authentication request unit 503, an electronic medical record acquisition unit 504, and a storage unit 505.

The communication control unit 501 is a 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 way, the other processing modules transmit and receive data with other devices via the communication control unit 501. The communication control unit 501 has a function as a receiving unit that receives data from other devices and a function as a transmitting unit that transmits data to other devices.

The biometric information acquisition unit 502 is a means for controlling a camera device and acquiring biometric information (e.g., facial images) of evacuees in front of the evacuees. The biometric information acquisition unit 502 acquires facial images of residents (patients) in front of the evacuees in response to operations by a doctor or the like. At that time, the biometric information acquisition unit 502 may display a GUI for obtaining the patient's consent while displaying that the patient's facial image will be acquired and the purpose of acquiring the facial image. For example, the biometric information acquisition unit 502 may display a GUI as shown in FIG. 28.

Once a facial image of the patient (evacuee) is acquired with the patient's (evacuee's) consent, the biometric information acquisition unit 502 passes the acquired facial image to the authentication request unit 503.

The authentication request unit 503 is a means for requesting authentication regarding the patient from the local government server 10. The authentication request unit 503 generates an authentication request including the acquired facial image and transmits it to the local government server 10.

The authentication request unit 503 receives the authentication result (authentication successful, authentication failed) from the local government server 10. If the authentication result is authentication failure, the authentication request unit 503 notifies the doctor and the patient accordingly. At that time, the authentication request unit 503 displays a message such as "You are not registered as a resident at the disaster prevention center, so you cannot obtain the electronic medical record."

If the authentication result is successful, the authentication request unit 503 passes the authentication result (positive response including hospital information) to the electronic medical record acquisition unit 504.

The electronic medical record acquisition unit 504 extracts the patient ID included in the hospital information. The electronic medical record acquisition unit 504 sends an electronic medical record provision request including the extracted patient ID to the hospital server 20 (the hospital server 20 of the hospital included in the hospital information).

When the electronic medical record acquisition unit 504 acquires the electronic medical record from the hospital server 20, it displays the acquired electronic medical record on a display device that is viewable by the doctor.

The memory unit 505 is a means for storing information necessary for the operation of the medical terminal 50.

[Municipality server]
Fig. 29 is a diagram showing an example of a processing configuration (processing module) 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 a means for processing an authentication request 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 multiple residents pre-stored in the resident information database.

The authentication unit 207 extracts the biometric information (face image) included in the authentication request. The authentication unit 207 calculates features from the extracted face image. The authentication unit 207 sets the features calculated based on the face image as the object of matching, and performs a matching process with the features registered in the resident information database. The authentication unit 207 calculates the similarity between the feature to be matched and each of the multiple features on the registration side.

The authentication unit 207 determines that authentication of the person to be authenticated has failed if there is no feature among the multiple features registered in the resident information database that has a similarity with the feature to be matched that is equal to or greater than a predetermined value.

If the authentication fails, the authentication unit 207 notifies the medical terminal 50, which is the sender of the authentication request, of the failure of the authentication. The authentication unit 207 sends a negative response indicating the failure of the authentication to the medical terminal 50.

If a feature whose similarity with the feature to be matched is greater than or equal to a predetermined value is registered in the resident information database, the authentication unit 207 identifies the feature (entry) that is closest to the feature to be matched.

If hospital information is set in the identified entry, the authentication unit 207 determines that the authentication was successful. If hospital information is not set in the identified entry, the authentication unit 207 determines that the authentication was unsuccessful.

If authentication is successful, the authentication unit 207 sends a positive response to the medical terminal 50 including hospital information (name of the family hospital, patient ID) of the identified entry.

[Hospital Server]
Fig. 30 is a diagram showing an example of a processing configuration (processing module) of the hospital server 20 according to the third embodiment. Referring to Fig. 30, an electronic medical record providing unit 306 is added to the configuration of the hospital server 20 according to the first embodiment.

The electronic medical record providing unit 306 is a means of providing information recorded in the patient's electronic medical record to the evacuation shelter (medical terminal 50).

When an electronic medical record provision request is received, the electronic medical record provision unit 306 searches the patient information database using the patient ID included in the electronic medical record provision request as a key to identify the corresponding medical record ID. The electronic medical record provision unit 306 obtains the electronic medical record corresponding to the identified medical record ID.

The electronic medical record providing unit 306 transmits the acquired electronic medical record to the medical terminal 50.

[System Operation]
Next, a description will be given of the operation of the disaster prevention system 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.

When a doctor diagnoses the evacuee, the medical terminal 50 acquires the evacuee's biometric information with the evacuee's consent. The medical terminal 50 sends an authentication request including the acquired biometric information to the local government server 10 (step S21).

Upon receiving an authentication request, the local government server 10 performs authentication processing using the biometric information in the authentication request and the biometric information registered in the resident information database (step S22).

If the authentication is successful, the local government server 10 transmits the hospital information of the authenticated person (the person who is determined to have been successfully authenticated; 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 sends a request for an electronic medical record including the extracted patient ID to the hospital (hospital server 20) listed in the hospital information (step S24).

The hospital server 20 reads the electronic medical record corresponding to the patient ID and transmits it to the medical terminal 50 (step S25).

<Modification of the third embodiment>
In the third embodiment, it has been described that 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. However, the medical terminal 50 can also acquire the electronic medical record directly from the hospital server 20.

In this case, the resident registers his/her own biometric information (e.g., facial image) in the hospital server 20 of the family hospital. The hospital server 20 generates features from the facial image, associates the features (biometric information) with the patient ID, etc., and stores them in the patient information database.

The doctor finds out from the patient (evacuee) which hospital the patient goes to regularly and inputs this information into the medical terminal 50. The medical terminal 50 acquires the patient's biometric information (facial image). The medical terminal 50 sends a request for an electronic medical record including the biometric information to the hospital server 20 of the hospital where the information was input.

The hospital server 20 identifies the patient through biometric authentication and reads out the corresponding electronic medical record. The hospital server 20 transmits the read out electronic medical record to the medical terminal 50.

In this case, the hospital server 20 only needs to have an internal "authentication unit." The operation of the authentication unit can be the same as that of the authentication unit 207 of the local government server 10, so a detailed explanation will be omitted.

In the third embodiment, as in the first embodiment, electronic medical record information may be shared between the hospital server 20 and the medical terminal 50. That is, the patient may set permission for data sharing with the medical terminal 50 in the hospital server 20. For example, the purpose of data sharing may be set as "examination at evacuation shelter", the type of shared data may be set as "electronic medical record", the data sharing destination may be set as "medical terminal (evacuation shelter)", and the condition for data sharing may be set as "examination by a doctor". In this case, the medical terminal 50 may send a data sharing request for the electronic medical record to the hospital server 20.

As described above, the disaster prevention system according to the third embodiment further includes a 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 regarding the identified person's regular hospital to the medical terminal 50. The medical terminal 50 requests the regular hospital to provide the electronic medical record of the person to be authenticated. In this way, a doctor at the evacuation shelter can refer to the patient's (evacuee's) electronic medical record, enabling more reliable medical treatment and diagnosis.

In addition, in the third embodiment, when acquiring a patient's biological information, the patient's consent to sharing the information in the electronic medical record can be obtained. In other words, the disclosure of the present application aims to achieve both protection of user privacy and convenience for users by appropriately separating information shared with organizations such as local governments from information shared among doctors.

Next, we will explain the hardware of each device that makes up the disaster prevention system. Figure 32 is a diagram showing an example of the hardware configuration of the local government server 10.

The local government server 10 can be configured by an information processing device (so-called a computer) and has the configuration shown in Fig. 32. For example, the local government server 10 has a processor 311, a memory 312, an input/output interface 313, a communication interface 314, etc. The components such as the processor 311 are connected by an internal bus or the like and are configured to be able to communicate with each other.

However, 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 an input/output interface 313 as necessary. In addition, the number of processors 311, etc. included in the local government server 10 is not intended to be limited to the example shown in FIG. 32, and for example, the local government server 10 may include multiple processors 311.

The processor 311 is, for example, a programmable device such as a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a DSP (Digital Signal Processor). Alternatively, the processor 311 may be a device such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit). The processor 311 executes various programs including an operating system (OS).

Memory 312 is a RAM (Random Access Memory), a ROM (Read Only Memory), a HDD (Hard Disk Drive), a SSD (Solid State Drive), etc. 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 that accepts user operations such as a keyboard or a mouse.

The communication interface 314 is a circuit, module, etc. that communicates with other devices. For example, the communication interface 314 includes a NIC (Network Interface Card), etc.

The functions of the local government server 10 are realized by various processing modules. The processing modules are realized, for example, by the processor 311 executing a program stored in the memory 312. The program can be recorded on a computer-readable storage medium. The storage medium can be a non-transitory medium such as a semiconductor memory, a hard disk, a magnetic recording medium, or an optical recording medium. 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 that stores the program. The processing modules may also be realized by a semiconductor chip.

In addition, the hospital server 20, the terminal 30, the reception terminal 40, and the medical terminal 50 can also be configured with information processing devices like the local government server 10, and their basic hardware configurations are no different from those of the local government server 10, so a description will be omitted. For example, the reception terminal 40 and the medical terminal 50 may be equipped with a camera device for photographing the person to be authenticated.

The local government server 10, which is an information processing device, is equipped with a computer, and the functions of the local government server 10 can be realized by having the computer execute a program. In addition, the local government server 10 executes a control method for the local government server 10 by the program.

[Modification]
The configuration, operation, etc. of the disaster prevention system described in the above embodiment are merely examples, and are not intended to limit the system configuration, etc.

In the above embodiment, the doctor's input of the electronic medical record into the system is not described, but the electronic medical record may be input into the system during a face-to-face diagnosis or during an online medical consultation. In other words, the electronic medical record may be input into the system by any method.

In the above embodiment, the municipal server 10 has been described as acquiring health information for each resident from a regular hospital. However, the municipal server 10 may also acquire the health information from the resident himself or from the resident's family. Specifically, residents may also register their health information in the system (municipal server 10) when registering as a resident. That is, the disaster prevention system disclosed in the present application may use health information recorded in an electronic medical record, or may use health information self-reported by the resident.

In the above embodiment, a case has been described in which a shelter is selected mainly based on a current condition (current illness), but it goes without saying that a shelter may also be selected based on a previous condition. Alternatively, a shelter may be selected based on a current condition and a previous condition. Alternatively, if "current condition" and "previous condition" can be obtained from the hospital server 20 (if data can be shared), it may be decided in advance which information will be given priority in determining a shelter.

When generating evacuation information, the local government server 10 may generate evacuation information including not only the evacuation information as shown in Figures 14 and 15, but also routes from residents' homes to evacuation shelters (see Figure 33). The local government server 10 may set the resident's home as the starting point and the selected evacuation shelter as the end point, calculate the route, and include it in the evacuation information. Alternatively, as shown in Figure 33, the local government server 10 may generate evacuation information including the type and characteristics of the proposed evacuation shelter.

The local government server 10 may refer to the resident information database and provide information useful to disaster prevention personnel. For example, the local government server 10 calculates the total amount of medicine needed for each evacuation shelter from each resident's medication information and evacuation destination information. The local government server 10 presents the calculated total amount to the disaster prevention personnel. Alternatively, the local government server 10 may request delivery of the calculated amount of medicine from a pharmaceutical company or the like. In this way, the local government server 10 can grasp the attributes of evacuees at each evacuation shelter, and therefore can take measures such as preparing the delivery of medicine in advance.

When the target of the evacuation information is a "person requiring assistance with evacuation," the local government server 10 may also transmit the evacuation information to the supporter of the person requiring assistance. In other words, the evacuation information (evacuation destination) may be shared between the person requiring assistance and the supporter.

Residents who have multiple family hospitals may input hospital information about those multiple family hospitals to the local government server 10. In this case, the local government server 10 may send a data sharing request to each hospital server 20, or may set priorities according to the attributes of the resident and hospital. For example, if two hospitals, one specializing in internal medicine and one 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.

In the above embodiment, a case where a resident's patient ID is set in a data sharing request has been described. However, for a resident for whom a patient ID has not been set, the local government server 10 may set the resident's name, etc., instead of the patient ID.

In the above embodiment, a case has been described in which a data sharing permission for the purpose of evacuation shelter guidance is set in the hospital server 20. However, other purposes related to data sharing may be set in the hospital server 20. For example, a data sharing permission for the purpose of insurance premium calculation may be set in the hospital server 20. In this case, for example, an insurance company is the data sharing destination.

Alternatively, the hospital server 20 may change the types of data that a resident can select depending on the purpose selected by the resident. For example, as described in the above embodiment, if the purpose is to guide residents to evacuation shelters, "pre-existing conditions," "current conditions," and "medication information" are displayed as candidates for data sharing, whereas if the purpose is to calculate insurance premiums, "medication information" may not be displayed as a candidate for data sharing.

In the above embodiment, a case has been described in which a condition for data sharing is set according to the alert level, such as "Evacuation order issued (or higher)." However, to make it easier for residents to understand, the hospital server 20 may provide options such as "When evacuation information is issued" or "When a disaster is expected to occur due to heavy rain or a typhoon."

Depending on the resident's health information, the local government server 10 may also determine that it would be better to transport the resident to a hospital rather than to evacuate to a shelter. In this case, the local government server 10 may take measures such as arranging for an emergency vehicle to be sent to the resident.

Alternatively, if the local government server 10 is unable to determine based on the resident's health information whether or not the resident should evacuate to an evacuation shelter, it may inquire about the treatment of the resident at a hospital listed in the hospital information.

In the above embodiment, a case has been described in which a disaster prevention officer inputs an alert level and an area to which evacuation information is to be sent to the local government server 10. However, the disaster prevention officer may also input a "policy" regarding data sharing to the local government server 10. The disaster prevention officer may decide the policy to be input (the type of data to be obtained through data sharing) depending on the type and scale of the predicted disaster, etc.

When there are multiple shelters to which a resident can be guided, the local government server 10 may select a shelter to which the resident should be guided based on the resident's current location or the location of the resident's home. Specifically, the local government server 10 may select the shelter closest to the resident from among the shelters suitable for the resident and guide the resident to the shelter.

In the second embodiment, it has been described that the reception terminal 40 transmits a notification of an evacuee's arrival to the local government server 10. However, the notification may also be transmitted by a surveillance camera or the like installed at the evacuation shelter.

In the second embodiment, a case where a resident is identified using biometric information has been described. However, the means for identifying a resident may be other methods or means. For example, personal authentication using an electronic certificate printed on a My Number card may be used. Alternatively, password authentication using an ID and a password may be used. Alternatively, the local government server 10 may issue to the resident a resident ID generated at the time of resident registration, and the issued resident ID may be presented to the reception terminal 40. For example, the terminal 30 may convert the resident ID issued at the time of resident registration into a two-dimensional code, and the resident may operate the terminal 30 to present the two-dimensional code to the reception terminal 40, thereby identifying the resident.

In the above embodiment, a case has been described in which the resident information database and the evacuation shelter information database are configured within the local government server 10, but these databases may also be configured in an external database server or the like. That is, some of the 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 implemented in any of the devices included in the system.

In the above embodiment, it was explained that for residents who have a designated family hospital, their health condition is checked and they are guided (possibly guided) to an evacuation shelter where a doctor or nurse is on-site. However, if a resident does not have a designated family hospital and their health condition is unknown, the resident may be guided to an evacuation shelter where a doctor or nurse is on-site as a precaution, taking into consideration the resident's age, etc.

The local government server 10 may verify the identity of a resident when registering the resident. Specifically, the local government server 10 acquires an identity document (e.g., a passport, a driver's license, etc.) containing biometric information along with the resident's biometric information, personal information, etc. The local government server 10 performs a one-to-one match using the biometric information on the identity document and the biometric information acquired from the resident. If the match is successful, the local government server 10 may register the resident.

The form of data transmission between each device (municipal server 10, hospital server 20, etc.) is not particularly limited, but the data transmitted between these devices may be encrypted. Patient electronic medical records, etc. are transmitted between these devices, and in order to appropriately protect this information, it is desirable to transmit and receive encrypted data.

In the flow diagrams (flowcharts, sequence diagrams) used in the above explanation, multiple steps (processes) are described in order, but the order of execution of the steps performed in the embodiments is not limited to the order described. In the embodiments, the order of the steps shown in the diagrams can be changed to the extent that does not interfere with the content, such as by executing each process in parallel.

The above embodiments have been described in detail to facilitate understanding of the present disclosure, and it is not intended that all of the configurations described above are required. Furthermore, when multiple embodiments are described, each embodiment may be used alone or in combination. For example, it is possible to replace part of the configuration of an embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of an embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of an embodiment with other configurations.

The above explanation makes clear the industrial applicability of the present invention, and the present invention is particularly applicable to disaster prevention systems that assist residents in evacuating.

A part or all of the above-described embodiments can be described as, but is not limited to, the following supplementary notes.
[Appendix 1]
A generation unit that generates evacuation information including information on a shelter to which the resident is guided based on the health information of the resident;
A transmission unit that transmits the generated evacuation information to a terminal carried by the resident;
A server device comprising:
[Appendix 2]
The server device according to claim 1, further comprising an acquisition unit that acquires the health information from the resident's family hospital.
[Appendix 3]
The server device described in Appendix 2, wherein the acquisition unit acquires the health information by sending a data sharing request regarding the health information to a hospital server of the family hospital.
[Appendix 4]
The server device according to any one of claims 1 to 3, wherein the generation unit selects a shelter that is suitable for the health condition of the residents and generates the evacuation information including information about the selected shelter.
[Appendix 5]
The server device described in Appendix 4, wherein the generation unit selects an evacuation shelter with a doctor or nurse on-site or an evacuation shelter equipped with medical equipment for a resident who is determined to have health concerns based on the health information.
[Appendix 6]
6. The server device according to any one of claims 1 to 5, further comprising a storage unit configured to store information regarding the resident's family hospital.
[Appendix 7]
A local government server that selects residents who live in an area designated by a disaster prevention officer from among the plurality of residents, and transmits evacuation information to a terminal carried by the selected resident;
A hospital server;
Including,
The system comprises: the local government server acquiring health information of the selected resident from the hospital server through data sharing; and selecting an evacuation shelter to which the selected resident will be guided based on the acquired health information.
[Appendix 8]
The system described in Appendix 7, wherein the hospital server stores sharing permission information regarding the sharing of at least a portion of the data contained in the patient's electronic medical record with the local government server.
[Appendix 9]
The system of claim 8, wherein the local government server sends a data sharing request to the hospital server, the data sharing request including the purpose of use, the type of data, and the sharing destination.
[Appendix 10]
The system described in Appendix 9, wherein 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 from the electronic medical record corresponding to the type of data authorized by the patient, and notifies the local government server of the read data as the health information.
[Appendix 11]
The system of claim 10, wherein the sharing permission information includes information regarding the purpose of the data sharing, the type of data to be shared, the recipients of the data sharing, and the conditions for sharing the data.
[Appendix 12]
Further comprising a reception terminal installed at the evacuation shelter,
The reception terminal transmits a notification of an evacuee's arrival to the local government server, the notification including biometric information of the evacuee who has arrived at the local government server;
The system described in Appendix 7, in which the local government server identifies the visiting evacuee by performing a matching process using the biometric information contained in the evacuee arrival notification, and transmits patient evacuation destination information, including the evacuation destination of the visiting evacuee, to the hospital server of the identified resident's family hospital.
[Appendix 13]
Further comprising a medical terminal installed in the evacuation shelter;
The medical terminal transmits an authentication request including biometric information of the person to be authenticated to the local government server;
The local government server identifies the person to be authenticated using the biometric information included in the authentication request, and transmits information about the person's family hospital to the medical terminal;
The system described in Appendix 7, wherein the medical terminal requests the family hospital to provide the electronic medical records of the authenticated person.
[Appendix 14]
In the server device,
generating evacuation information including information regarding a shelter to which the resident is directed based on the resident's health information;
A method for controlling a server device, the method comprising: transmitting the generated evacuation information to a terminal carried by the resident.
[Appendix 15]
A computer installed in the server device
A process of generating evacuation information including information regarding a shelter to which the resident is directed based on the resident's health information;
A process of transmitting the generated evacuation information to a terminal carried by the resident;
A computer-readable storage medium that stores a program for executing the above.

The disclosures of the above cited prior art documents are incorporated herein by reference. Although the embodiments of the present invention have been described above, the present invention is not limited to these embodiments. Those skilled in the art will understand that these embodiments are merely illustrative and that various modifications are possible without departing from the scope and spirit of the present invention. In other words, the present invention naturally includes various modifications and amendments that a person skilled in the art can make in accordance with the entire disclosure, including the scope of the claims, and the technical ideas.

10 Municipal server 20 Hospital server 30 Terminal 40 Reception terminal 50 Medical terminal 100 Server device 101 Generation unit 102 Transmission unit 201 Communication control unit 202 Resident registration unit 203 Evacuation information control unit 204 Memory unit 205 Resident evacuation destination management unit 206 Patient evacuation destination notification unit 207 Authentication unit 211 Transmission instruction acquisition unit 212 Target resident selection unit 213 Shared data acquisition unit 214 Evacuation information generation unit 301 Communication control unit 302 Permission information acquisition unit 303 Shared control unit 304 Memory unit 305 Patient information provision unit 306 Electronic medical record provision unit 311 Processor 312 Memory 313 Input/output interface 314 Communication interface 401 Communication control unit 402 Biometric information acquisition unit 403 Evacuee arrival notification unit 404 Memory unit 501 Communication control unit 502 Biometric information acquisition unit 503 Authentication request unit 504 Electronic medical record acquisition unit 505 Storage unit

Claims (2)

A local government server that selects residents who live in an area designated by a disaster prevention officer from among the plurality of residents, and transmits evacuation information to a terminal carried by the selected resident;
A hospital server;
Including,
The system comprises: the local government server acquiring health information of the selected residents from the hospital server through data sharing; and selecting an evacuation shelter to which the selected residents will be guided based on the acquired health information. The system according to claim 1 , wherein the hospital server stores sharing permission information regarding the sharing of at least a portion of data recorded in a patient's electronic medical record with the local government server.

Images