CN110228738B - 灾害信息处理装置以及灾害信息通知方法 - Google Patents

Abstract

本发明的实施方式涉及一种灾害信息处理装置以及灾害信息通知方法。本发明提供一种在有因灾害等导致电梯停止而难以接诊的医院的情况下、将其他能够接诊的医院通知用户的灾害信息处理装置以及灾害信息通知方法。本发明的实施方式的灾害信息处理装置具备第1受理部、存储部、处理部及输出部。第1受理部受理建筑物的电梯运行状况。存储部存储医院信息和用户信息。处理部根据电梯运行状况、医院信息及用户信息来算出能够接诊用户的医院的候选。输出部输出医院的候选。

Description

灾害信息处理装置以及灾害信息通知方法

本申请以日本专利申请2018-039010(申请日期：03/05/2018)为基础，根据该申请而享受优先权。本申请通过参考该申请而包含该申请的全部内容。

技术领域

本发明的实施方式涉及一种灾害信息处理装置以及灾害信息通知方法。

背景技术

以往，当发生广域灾害时，根据灾害的发生状况，存在建筑物内的电梯停止、或者某些情况下该电梯暂时无法利用的情况。当电梯停止时，在利用该建筑物的利用者的移动、运送时会产生不便，因此期望早点恢复运行。

发明内容

本发明要解决的问题在于，提供一种在有因灾害等导致电梯停止而难以接诊的医院的情况下、将其他能够接诊的医院通知给用户的灾害信息处理装置以及灾害信息通知方法。

本发明的实施方式的灾害信息处理装置具备第1受理部、存储部、处理部及输出部。第1受理部受理表示感知到异常的建筑物的电梯的运行状况的信息。存储部存储多个医院的医院信息和表示用户的宿疾或负责医院的用户信息。处理部根据所述第1受理部受理到的医院的电梯的所述运行状况、所述多个医院的医院信息以及所述用户信息，来算出能够接诊所述用户信息所示的用户的医院的候选。输出部将通过所述处理部的算出获得的能够接诊用户的医院的候选输出至所述用户能够确认的终端。

根据上述构成的灾害信息处理装置，能将最佳医院通知用户。

附图说明

图1为表示实施方式所涉及的灾害信息通知方法的一例的整体系统图。

图2为表示实施方式所涉及的控制设备的管制运转控制的处理的一例的图。

图3为表示实施方式所涉及的医院信息相关的设定表的一例的图。

图4为表示实施方式所涉及的运行状况信息相关的设定表的一例的图。

图5为表示实施方式所涉及的用户信息相关的设定表的一例的图。

图6为表示实施方式所涉及的电梯监视装置所进行的灾害通知处理的次序的一例的流程图。

图7为表示实施方式所涉及的输出至终端的通知画面的构成的一例的图。

图8为表示变形例1所涉及的灾害通知处理的一例的流程图。

图9为表示变形例1所涉及的第2受理部所进行的受理处理的一例的图。

图10为表示变形例1所涉及的输入表单信息的一例的图。

图11为表示变形例4所涉及的电梯监视装置的功能块的构成的一例的图。

图12为表示变形例4所涉及的日志的一例的图。

图13为表示变形例4所涉及的电梯监视装置发布最新的候选医院的次序的一例的流程图。

图14为表示变形例4所涉及的通知画面的显示内容的更新例的图。

具体实施方式

下面，参考附图，对实施方式所涉及的灾害信息处理装置以及灾害信息通知方法进行说明。再者，关于实施方式所涉及的灾害信息处理装置，以下展示运用于电梯监视装置的情况下的一例。

[实施方式]

图1为表示实施方式所涉及的灾害信息通知方法的一例的整体系统图。图1所示的灾害信息通知系统1具有如下构成，该构成包含电梯EV1、EV2、…等设备、在服务中心等中远程监视电梯EV1、EV2、…的电梯监视装置10以及灾害信息的输出目的地的终端11。电梯EV1、EV2、…等设备由各建筑物A1、A2、…配备。灾害信息是电梯监视装置10从各建筑物A1、A2、…的电梯EV1、EV2、…获得的后文叙述的与灾害相关的信息。

各建筑物A1、A2、…是用户所利用的医院、公寓等。在各建筑物A1、A2、…中配备有电梯EV1、EV2、…。这些电梯EV1、EV2、…由建筑物内的控制设备12的控制屏12-1等控制运转。此外，各建筑物A1、A2、…中设置有感知地震、火灾等异常而将异常信号输出至控制设备12的异常感知传感器21。并且，在本实施方式中，电梯EV1、EV2、…中设置有能从控制设备12读取的存储部22。

存储部22例如为电梯EV1、EV2、…的操作屏等的存储器。存储部22连接在通信电缆的端部，该通信电缆捆束在从控制设备12延伸至各电梯EV1、EV2、…的控制电缆上。另外，存储部22也能以无线标签的形式设置在电梯EV1、EV2、…中。在该情况下，控制设备12对读出器等送出指令来获取信息。读出器设置于移动的电梯EV1、EV2、…或者移动的电梯EV1、EV2、…的通过路径等。

存储部22中存储利用该建筑物的用户的用户信息D1。在该建筑物为医院的情况下，存储部22中进而存储包含该建筑物的医院名称、医院的诊疗信息等的医院信息D3。用户信息D1中包含用户的负责医院名称和能够判别诊疗科目的信息(诊疗信息)。例如，医院的电梯的存储部22中包含该医院的利用者的诊疗信息。此外，公寓的电梯的存储部22中包含其居住人员的诊疗信息。诊疗科目也可为病名、治疗内容等。下文中，在未特别限定于诊疗科目的情况下，有时会将诊疗科目以上位概念称为“诊疗信息”。

电梯监视装置10根据从各建筑物A1、A2、…等获得的信息，通过数据库制作系统10-1来制作数据库，算出医院可否接诊、最佳医院。电梯监视装置10经由网络N1而在与远程监视终端装置12-2之间收发数据，该远程监视终端装置12-2用于各建筑物A1、A2、…内的控制设备12与电梯监视装置10进行通信。电梯监视装置10与终端11经由网络N2收发数据。作为网络N1，考虑专线。网络N2考虑手机网、互联网等。数据库制作系统10-1的详情将于后文叙述。

终端11例如为用户终端、设置在避难所的显示器等。用户终端可列举桌面型PC(Personal Computer)、智能手机、平板电脑终端、手机、传真机、打印机等。

(灾害信息通知方法)

在以上那样的灾害信息通知系统1中，当发生广域灾害时，首先，发生了灾害的地区的建筑物内异常感知传感器21作出反应，该建筑物内的控制设备12检测到源于异常感知传感器21的异常信号(S1)。

当检测到异常信号时，控制设备12进行管制运转来检查建筑物内的各电梯EV1、EV2、…的动作，针对各电梯EV1、EV2、…而收集能够运行或不可运行等运行状况(运行状况信息D2)(S2)。管制运转和通过管制运转收集的运行状况信息D2将在后文列举一例来进行叙述。

接着，控制设备12从存储部22获取用户信息D1和医院信息D3，并将该用户信息D1、医院信息D3以及收集到的运行状况信息D2经由网络N1发送至电梯监视装置10(S3)。再者，医院信息D3是该建筑物为医院的情况下的例子。

电梯监视装置10接收感知到异常而从1个或多个建筑物发送的各信息，并制作数据库，在这些信息中含有医院信息D3的情况下，根据数据库来进行用于算出医院的候选的处理(S4)。数据库是存储多个医院的医院信息和表示用户的宿疾或负责医院的用户信息的“灾害信息处理装置所配备的存储部”的一例。电梯监视装置10将感知到异常而从1个或多个医院发送的医院信息D3和用户信息D1设定至各种表格并加以存储。再者，医院信息D3、用户信息D1可预先存储在电梯监视装置10中，也可从外部数据库等获取。关于从外部数据库获取医院信息D3的情况的一例，将在后文中作为变形例3加以展示。

电梯监视装置10例如根据接收到的运行状况信息D2来检查医院的电梯可否运行，在电梯不可运行的情况下，判定为难以接诊的状况。继而，电梯监视装置10以该医院的用户信息(对应于用户信息D1)中包含的各用户为对象，从其他的医院信息(对应于医院信息D3)中提取能够接诊各用户各自的诊疗科目的其他医院的候选。

此外，在像综合医院等那样用于升降至诊断室或检查室等的电梯根据诊疗科目而不同的情况下，电梯监视装置10根据运行状况信息D2、针对每一诊疗科目而检查电梯可否运行。于是，若处于一部分诊疗科目的接诊较为困难的状况，则电梯监视装置10以该医院的用户信息D1中的设定了该一部分诊疗科目的受诊的用户为对象、从医院信息中提取能够接诊各用户各自的诊疗科目的其他医院的候选。在该情况下，通过利用各电梯EV1、EV2、…中设置的存储部22来存储与各电梯EV1、EV2、…相对应的诊疗科目的用户信息，由此，能够按照每一电梯EV1、EV2、…来管理用户。

接着，电梯监视装置10将算出的各用户各自的医院的候选输出至各用户能够确认的终端11(S5)。

接着，对灾害信息通知系统1的各装置的具体构成和处理流程进行说明。再者，关于各建筑物A1、A2、…，在建筑物所具有的现有设备中，能够通过具有规定的用户信息D1的存储部22的设置、收集运行状况信息D2的管制运转等收集处理的执行等来实施。因而，关于各建筑物A1、A2、…，对存储部22的用户信息D1的数据构成、控制设备12进行的运行状况信息D2的收集处理进行说明。此外，关于用户的终端11，是智能手机、显示器等能够进行信息的输出的终端。它们的构成广为人知。为了使得本实施方式的主要构成易于理解，省略终端11的构成相关的说明。

(控制设备12进行的收集处理)

首先，对各建筑物A1、A2、…的控制设备12收集各建筑物内的电梯EV1、EV2、…的运行状况信息D2的处理进行说明。此处，以异常感知传感器21对地震作出了反应的情况下的控制设备12的管制运转控制的处理为例进行说明。

图2为表示控制设备12的管制运转控制的处理的一例的图。如图2所示，控制设备12监视异常感知传感器21的输出，判定该输出是否为“P波”或者“特低级别的加速度值”以上(S21)。假定异常感知传感器21的输出不是“P波”或者“特低级别的加速度值”以上(S21：否判定)。在该情况下，控制设备12认为各电梯EV1、EV2、…在正常运转(S22)，针对各电梯EV1、EV2、…在运行状况信息D2中设定表示“能够运行”的信息(S23)。

另一方面，在异常感知传感器21的输出为“P波”或者“特低级别的加速度值”以上的情况下(S21：是判定)，控制设备12判定异常感知传感器21的输出是否表现出“低级别的加速度值”以上(S24)。此处，在异常感知传感器21的输出不是“低级别的加速度值”以上的情况下(S24：否判定)，表示地震规模为“特低级别的加速度值”的范围。接着，控制设备12判定各电梯EV1、EV2、…是否正在行驶(S25)。在电梯不是正在行驶的情况下(S25：否判定)，控制设备12将该电梯停止60秒左右后(S26)，返回至正常运转(S27)，针对该电梯在运行状况信息D2中设定表示“能够运行”的信息(S28)。

此外，在电梯正在行驶的情况下(S25：是判定)，控制设备12判定能否在10秒左右停靠至最近楼层或紧急停靠楼层(S29)。在能在10秒左右停靠至最近楼层或紧急停靠楼层的情况下(S29：是判定)，转移至步骤S26。

在无法在10秒左右停靠至最近楼层或紧急停靠楼层的情况下(S29：否判定)，控制设备12检查该电梯的紧急停止安全装置是否正常(S30)，在正常的情况下(S30：是判定)，转移至步骤S26。

在紧急停止安全装置不正常的情况下(S30：否判定)，控制设备12使运转休止(S31)，针对该电梯在运行状况信息D2中设定表示“不可运行”的信息(S32)。

另一方面，在异常感知传感器21的输出为“低级别的加速度值”以上的情况下(S24：是判定)，控制设备12判定该电梯是否正在行驶(S33)。继而，若该电梯不是正在行驶(S33：否判定)，则控制设备12在将该电梯停止后的状态下(S34)针对该电梯在运行状况信息D2中设定表示“不可运行”的信息。其后，当通过自动恢复运转或者检修人员的检修(S36)使得运转回到正常运转时(S37)，控制设备12针对该电梯将运行状况信息D2的“不可运行”更新为“能够运行”(S38)。

在异常感知传感器21的输出为“低级别的加速度值”以上的情况下(S24：是判定)，假定电梯正在行驶(S33：是判定)。在该情况下，控制设备12判定该电梯能否在10秒左右停靠至最近楼层或紧急停靠楼层(S39)。在该电梯无法在10秒左右停靠好的情况下(S39：否判定)，控制设备12紧急停止该电梯(S40)，并转移至步骤S42。

另一方面，在该电梯能在10秒左右停靠好的情况下(S39：是判定)，控制设备12判定安全装置是否暂时工作而电梯已变成停止的状态(S41)。在否定的情况下(S41：否判定)，控制设备12判定异常感知传感器21的输出是否表现出“高级别的加速度值”以上(S42)。此处，在异常感知传感器21的输出不是“高级别的加速度值”以上的情况下(S42：否判定)，表示地震规模为“低级别的加速度值”的范围。在该情况下，接着，控制设备12判定安全装置是否正常(S43)，在安全装置正常的情况下(S43：是判定)，转移至步骤S34。

在安全装置不正常的情况下(S43：否判定)，控制设备12停止该电梯(S44)，针对该电梯在运行状况信息D2中设定表示“不可运行”的信息(S45)。

另一方面，在异常感知传感器21的输出为“高级别的加速度值”以上的情况下(S42：是判定)，表示地震规模为“高级别的加速度值”的范围。在该情况下，控制设备12进行紧急救出运转并休止运转(S46)，针对该电梯在运行状况信息D2中设定表示“不可运行”的信息(S47)。

再者，在安全装置暂时工作而电梯已变成停止状态的情况下(S41：是判定)，控制设备12针对该电梯在运行状况信息D2中设定表示“不可运行”的信息(S45)。

如上所述，当异常感知传感器21对地震作出反应时，控制设备12会实施管制运转，针对该建筑物内的各电梯EV1、EV2、…在运行状况信息D2中设定可否运行的信息。

(电梯监视装置10的构成)

电梯监视装置10具有控制部51(参考图1)、HDD(Hard Disk Drive)及通信接口。它们经由总线等连接在一起。

控制部51为具备CPU(Central Processing Unit)、ROM(Read Only Memory)及RAM(Random Access Memory)的计算机构成。控制部51通过由CPU执行ROM的程序来进行运算处理、电梯监视装置10的各部的控制处理。RAM用作CPU的作业区域等。

HDD具备磁盘，根据来自控制部51的命令来进行来自磁盘的数据的读出、数据向磁盘的写入等。HDD存放后文叙述的数据库(“存储部”的一例)等。

通信接口连接至网络N1、网络N2，是与通信目的地收发数据的例如以太网(注册商标)板。

电梯监视装置10的数据库制作系统10-1具备控制部51。图1中展示了控制部51中的功能块的构成的一例。通过由控制部51的CPU执行程序来实现各种功能。图1中展示了第1受理部101、处理部103及输出部104作为其中的主要功能。

第1受理部101受理从各建筑物A1、A2、…的控制设备12发送的电梯EV1、EV2、…的运行状况信息D2。具体而言，通信接口接收从各建筑物A1、A2、…的控制设备12发送的发送数据。发送数据中包含运行状况信息D2和用户信息D1，在该建筑物为医院的情况下，进而包含医院信息D3。根据来自通信接口的通知等，第1受理部101将运行状况信息D2、用户信息D1及医院信息D3作为处理对象交给处理部103。

处理部103制作包含运行状况信息D2、用户信息D1及医院信息D3的数据库，并根据该数据库算出医院能否接诊、其他能够接诊的医院的候选。例如，处理部103从运行状况信息D2的设定中读取医院内的各诊疗科目的接诊状况。继而，处理部103将与运行状况信息D2一同发送的用户信息D1中该医院的诊疗科目负责的各用户作为对象来进行处理。具体而言，处理部103进行该医院能否接诊用户的受诊科目的判定，在该医院难以接诊的情况下，进行进而从其他医院信息D3中提取其他医院的候选的处理等。

输出部104将处理部103的判定结果(算出结果)也就是负责医院的接诊状况的结果、各用户各自的最佳的医院的候选输出至相应的各用户的终端11。

(表格)

接着，展示数据库所具备的表格的一例。

图3为表示医院信息D3相关的设定表的一例的图。图3的(a)所示的各诊疗科目表T1是以“医院单位”来设定“诊疗科目”和以该“诊疗科目”为目的地的“电梯的识别信息”的表格。处理部103从医院信息D3中提取医院的诊疗科目相关的列表和用于利用各诊疗科目的电梯EV1、EV2、…的信息而设定至各诊疗科目表T1。此处，作为一例，展示了“第1医院”、“第2医院”、“第3医院”相关的3个诊疗科目表T1，其他省略了图示，但其他医院相关的诊疗科目表中同样也有这些内容。

图3的(b)所示的医院位置信息表T2是设定医院的地点的表格。处理部103从医院信息D3中提取位置信息(纬度信息、经度信息)作为医院的地点，从而设定至医院位置信息表T2。

具体而言，在图3的(a)所示的各诊疗科目表T1的例子中，处理部103在“诊疗科目”项目中设置所有医院的诊疗科目(“内科”、“外科”等)，针对各诊疗科目中的每一方，若有对应的电梯，则设定“○”。“×”表示不相符(没有对应的电梯)。

例如，在“第1医院”的诊疗科目表T1中，在各电梯EV1、EV2、…中的“EV1”中，对“内科”和“外科”设定有“○”。此外，在“EV2”中，对“耳鼻科”设定有“○”。这表示在“第1医院”中，可以通过各电梯EV1、EV2、…中的“EV1”来利用“内科”和“外科”，可以通过“EV2”来利用“耳鼻科”。根据此处的内容还得知，“第1医院”包含“内科”、“外科”、“耳鼻科”作为诊疗科目。

相对于此，在“第2医院”的诊疗科目表T1中，在2台电梯“EV1”和“EV2”中，“内科”都是“×”。也就是说，可知“第2医院”不包含“内科”。此外，在“第3医院”的诊疗科目表T1中，在2台电梯“EV1”和“EV2”中，“外科”都是“×”，可知“第3医院”不包含“外科”。

再者，在从医院信息D3未获得表示各诊疗科目与电梯EV1、EV2、…的分类的信息的情况下，处理部103在该医院的诊疗科目表T1中也能不以电梯单位来分开设定。在这种情况下，处理部103在该医院的诊疗科目表T1中设置代表性地表示电梯EV1、EV2、…的“EV0”，在“EV0”的记录中设定“内科”、“外科”、“耳鼻科”等的“○”、“×”。

图4为表示运行状况信息D2相关的设定表的一例的图。图4的(a)展示了因检测到地震等灾害而从各建筑物A1、A2、…发送来的运行状况信息D2的设定表(运行状况信息设定表T3)的一例。在运行状况信息设定表T3中，通过处理部103而按照每一记录来设定各建筑物A1、A2、…的运行状况信息D2。

在一例的运行状况信息设定表T3中，展示了从4个建筑物(“第1医院”、“第2医院”、“第3医院”、“第1公寓”)发送了运行状况信息D2时的设定。例如，对于“第1医院”，根据运行状况信息D2而设定灾害发生日期时间“2017年11月9日、10：30”以及表示各电梯EV1、EV2、…的“能够运行”或“不可运行”的信息。再者，对于“第2医院”和“第3医院”，由于电梯只设定有“EV1”和“EV2”，因此，“EV3”视为没有信息而以“-”表示。

图4的(b)展示了处理部103根据运行状况信息设定表T3的设定而生成的判定表T4的一例。一例中展示的判定表T4是处理部103根据各医院的诊疗科目表T1的设定和运行状况信息设定表T3的设定来生成的。由此，判定表T4展示出各医院的诊疗科目的接诊状况。例如，在运行状况信息设定表T3中，“第1医院”的所有电梯都是“不可运行”。这表示“第1医院”无法接诊患者。因此，在判定表T4的“第1医院”中设定的是所有诊疗科目都不可接诊的“△”。在判定表T4中，“○”表示可以接诊，“△”表示不可接诊，“×”表示没有对应的诊疗科目。如此，处理部103能够随时生成判定表T4，并根据生成的最新的判定表T4，以诊疗科目单位来寻找接诊目的地的医院。

图5为表示用户信息D1相关的设定表的一例的图。图5所示的设定表(用户信息表T5)具有“用户识别信息”、“医院名称”、“受诊科目”、“终端信息”作为设定项目。这些数据是由处理部103根据发送的用户信息D1来设定的。这些数据中含有个人信息。因此，可以在存储部22中存储用户登记时分配的唯一的识别码来作为用户信息D1。在该情况下，在电梯监视装置10中，根据各识别码而从数据库等进行查询来提取“用户识别信息”、“医院名称”、“受诊科目”及“终端信息”的数据。此处，所谓“终端信息”，是指用户的智能手机等终端11中登记的各种地址(MAC(Media Access Control address)地址、E-mail地址等表示终端11的发送目的地的信息)。

(提取医院的候选的处理的流程)

接着，对电梯监视装置10中的灾害通知处理的次序进行说明。

图6为表示电梯监视装置10(控制部51)所进行的灾害通知处理的次序的一例的流程图。该处理是通过由电梯监视装置10接收从检测到灾害的发生的各建筑物A1、A2、…发送的发送数据而开始。在建筑物为医院的情况下，发送数据中还包含医院信息D3。

首先，控制部51受理来自各建筑物A1、A2、…的各发送数据中包含的用户信息D1、运行状况信息D2及医院信息D3(S101)。

接着，控制部51针对从各建筑物A1、A2、…发送的上述用户信息D1、上述运行状况信息D2及上述医院信息D3来制作数据库(S102)。在本实施方式所示的例子中，控制部51将上述用户信息D1的数据设定至用户信息表T5(参考图5)，将上述运行状况信息D2的数据设定至运行状况信息设定表T3(参考图4的(a))。此外，控制部51将上述医院信息D3的数据设定至诊疗科目表T1(参考图3的(a))和医院位置信息表T2(参考图3的(b))。继而，控制部51根据各医院的诊疗科目表T1(参考图3的(a))的设定和运行状况信息设定表T3的设定来生成判定表T4(参考图4的(b))。

判定表T4的生成具体是由处理部103以如下方式进行。首先，处理部103从各医院的诊疗科目表T1中针对每一电梯而提取与各电梯相对应的诊疗科目，在运行状况信息设定表T3中，提取相应的医院和表示电梯的运行状况的信息。继而，若表示上述运行状况的信息为“能够运行”，则处理部103在判定表T4中对医院名称和该医院的各诊疗科目设定“○”，若是“不可运行”，则设定“△”。“×”表示没有诊疗科目，这在前面也有过说明。

例如，在第1医院的诊疗科目表T1中，设定有电梯EV1通往“内科”的楼层和“外科”的楼层、电梯EV2通往“耳鼻科”的楼层这一内容。另一方面，在运行状况信息设定表T3中，“第1医院”的“EV1”和“EV2”都是“不可运行”。因而，在判定表T4中，“第1医院”的“内科”、“外科”及“耳鼻科”为“△”。

此外，在第2医院的诊疗科目表T1中，设定有电梯EV1通往“外科”的楼层、电梯EV2通往“耳鼻科”的楼层这一内容。另一方面，在运行状况信息设定表T3中，“第2医院”的“EV1”为“能够运行”，“EV2”为“不可运行”。因而，在判定表T4中，“第2医院”的“外科”为“○”，“耳鼻科”为“△”。由于未设置有“内科”，因此“内科”为“×”。

接着，控制部51针对用户信息表T5中设定的各用户、根据判定表T4来判定负责医院的诊疗科目能否接诊患者(S103)。

例如，在用户信息表T5中，“User1”是由“第1医院”的“内科”负责这一设定。在判定表T4中，第1医院的“内科”设定的是表示不可接诊的“△”。因此得知，“User1”即便去往第1医院，被“内科”接诊的可能性也较低。另一方面，“User2”在用户信息表T5中是由“第2医院”的“外科”负责这一设定。在判定表T4中，第2医院的“外科”也设定的是表示能够接诊的“○”。因此得知，“User2”在负责的第2医院会被“外科”接诊。

对于在步骤S103中被判定为负责医院的诊疗科目不可接诊的用户，控制部51接着进行选择最佳医院的处理(S104)。

例如，在“User1”的情况下，用户是在“内科”受诊，因此，控制部51从其他医院当中选择被“内科”接诊的最佳地点(按规定的优先顺序决定的医院)。作为处理的具体例，例如，控制部51提取判定表T4中“内科”设定的是“○”的医院。在该例中，作为其中之一，“第3医院”符合这一条件。控制部51针对提取出的各医院(该例中也包括“第3医院”)而决定按规定的优先顺序呈现给用户的医院的候选。例如，控制部51按照基准位置(用户的负责医院、用户的住所、用户的当前位置等)到医院的距离由近到远的顺序排列医院的候选。

继而，控制部51分别指定相应用户的终端11的地址，向指定的地址发布包含该用户相关的候选医院的通知画面信息(S105)。

(输出至终端11的通知画面)

图7为表示终端11上输出的通知画面的构成的一例的图。图7所示的通知画面91中显示了以能够输出的方式嵌入至终端11的用户相关的负责医院的信息910和别的候选医院的信息911而得的信息。该例是“User1”的终端11上的输出例。在图7的输出例中，“User1”的负责医院的患者的接诊状况显示的是“困难”。此外，其他医院的候选按照距离由近到远的顺序进行了列表显示。此外，在地图信息912上重叠有表示各医院的位置的记号和文字。关于地图信息912，可在终端11上输出电梯监视装置10预先存储的地图信息，也可在终端11上输出从外部的地图信息数据库获取到的地图信息。此外，展示医院的位置的方法不限于图7的地图信息912中展示的记号和文字，可任意设定。例如，也可展示基准位置(用户的负责医院、用户的住所、用户的当前位置等)到医院的路径信息。

通过这些显示，“User1”可以判断即便去往负责医院也得不到诊疗的可能性较高，并从候选医院当中找出别的医院。

在本实施方式中，对各建筑物A1、A2、…分别配备有1个异常感知传感器21，针对各处理而展示了一例。另外，也考虑对各电梯EV1、EV2、…中的各方设置有异常感知传感器21的情况。在该情况下，控制设备12可对输出了异常信号的电梯的动作进行检查，对于其余电梯则以能够运行的形式汇集运行状况信息D2。

此外，在本实施方式中，用户信息D1是以由各建筑物A1、A2、…的存储部22存储的形式进行的说明，但并不限于此。例如，也可为电梯监视装置10预先从用户接受登记，也可为电梯监视装置10从外部的数据库等获取。在该情况下，电梯监视装置10还从外部的数据库等获取用户信息D1的各用户的负责医院、住所(公寓)等信息，明确好发送了运行状况信息D2的各建筑物A1、A2、…与用户的对应关系。

在本实施方式中，能在灾害的发生范围内将最佳医院通知用户。

(变形例1)

展示如下变形例：灾害发生时，从电梯监视装置10对用户的终端11进行确认用户的伤势的状况、身体状态等受灾信息的询问，电梯监视装置10能够根据所应答的用户的受灾信息来提取医院的候选。再者，此处是对与实施方式不同的部分进行说明，与实施方式共通的部分的说明酌情从略。

在变形例1中，在实施方式的电梯监视装置10的功能块的构成(参考图1)中，进而设置有第2受理部(未图示)。在变形例1中，输出部104还将输入表单与候选信息一起发送至用户的终端11。输入表单是包含询问用户的伤势的状况(也包括身体状态等)等受灾信息的固定语句等的发送信息。

第2受理部受理从用户的终端11根据输入表单回复的受灾信息。继而，第2受理部将受灾信息交给处理部103，让处理部103再次判定候选医院。此处，“回复”是“应答”的一种方法。

图8为表示变形例1所涉及的灾害通知处理的一例的流程图。此处，为了避免重复的说明，对于实施方式的灾害通知处理的次序(参考图6)相关的处理是作简单说明。

在步骤S104中，当由处理部103提取到宿疾相关的其他候选医院时，输出部104判定是否已对该用户的终端11发送过输入表单(S105-1)。

在未发送过输入表单的情况下(S105-1：否判定)，输出部104将规定的输入表单与上述候选医院一起发送至用户的终端11(S105-2)。

继而，第2受理部判定发送了输入表单的用户是否有回复(S105-3)。例如，第2受理部对一定的回复时间进行计数，在该时间内没有回复的情况下判定无回复(S105-3：否判定)，结束处理。

在一定的回复时间内有回复的情况下(S105-3：是判定)，第2受理部受理该回复内容(作为一例，设为表示用户的伤势的信息)，处理部103进行处理。在该处理中，处理部103在步骤S103中基于用户的伤势的状况、根据判定表T4来再次进行判定，在步骤S104中提取候选医院。

接着，由于已发送过输入表单(S105-1：是判定)，因此，输出部104在通知画面上设定上述伤势相关的候选医院并发送至用户的终端11(S105-4)，本处理结束。

图9为表示第2受理部所进行的受理处理的一例的图。图9中，作为一例，展示了从“User1”收到了伤势的回复的情况下的受理处理。

首先，在灾害发生时，用户信息表T5中，“User1”的“受诊科目”设定的是“内科”(S201)。基于该设定、根据判定表T4来判定“User1”相关的候选医院(S202)，将判定结果和供输入伤势的输入表单发送至“User1”的终端11(S203)。

其后，从“User1”的终端11回复了“磕碰”作为用户的伤势的状况(S204)。于是，第2受理部从诊疗科目表T6查询“磕碰”所属的诊疗科目(S205)，将查询结果的诊疗科目设定至“User1”的“受诊科目”(S206)。

其后，由处理部103以“User1”的最新的设定、根据判定表T4再次判定候选医院(S207)，并由输出部104将再判定结果发送至“User1”的终端11(S208)。

图10为表示发送至终端11的输入表单信息的一例的图。图10所示的输入表单信息913展示了用于受理用户的负伤内容的输入表单。在图10所示的例子中，输入表单信息913具有显示灾害时的主要负伤内容的一览(磕碰、骨折、扭伤、…等)的信息，而且具有与这些信息相对应的复选框913-1。此外，输入表单信息913具有用于受理其他负伤内容的文本输入框913-2。输入表单信息913通过“发送”按钮913-3来受理进行这些输入内容的回复而结束画面的指示。输入表单信息913通过“不发送”按钮913-4来受理不进行基于输入表单的回复而结束画面的指示。

输出部104可将输入表单信息913嵌入至通知画面91(参考图7)来发送，也能以区别于通知画面91的别的输入表单画面的形式发送。

在本变形例1中，电梯监视装置10从用户接收伤势的状况作为受灾信息，提取与该伤势相符的诊疗科目的候选医院。但不限于此，电梯监视装置10也可按照受灾信息的内容对提取候选医院的优先顺序进行规定的加权。例如，电梯监视装置10根据受灾信息来判定用户能不能动，在能动的情况下，通知稍远的医院作为候选，在不能动的情况下，通知较近的医院，根据其程度对医院进行紧急通报。

此外，在本变形例1中，展示的是从电梯监视装置10将输入表单发送至终端11的例子，但发送输入表单的主体可不限于电梯监视装置10。例如，当建筑物感知到灾害时，也可从该建筑物的电梯的无线接入点对附近的用户(主要是位于该电梯或建筑物内等的用户)的终端11发布输入表单信息。用户在各终端11上输入受灾信息，将该受灾信息经由无线接入点发送至电梯监视装置10。在该情况下，电梯监视装置10在从感知到灾害的建筑物发送的用户信息D1中将负责诊疗科目变更为基于送自用户的受灾信息的诊疗科目来提取候选医院。

例如，在公寓中检测到电梯的异常的情况下，从该公寓发送的用户信息D1中包含负伤的居住人员的信息的可能性较高。因此，在变形例1中，电梯监视装置10向从公寓等送来的用户信息D1中设定的用户的终端11发送输入表单来获取居住人员的受灾信息(伤势等信息)。电梯监视装置10根据各居住人员的受灾信息来判定相应诊疗科目，将能够接诊的医院的候选发送至各居住人员的终端11。由此，电梯监视装置10能将与当前的伤势相应的医院的候选呈现至终端11。

(变形例2)

在受灾地区内，通信路径有可能发生断线等而无法再通信。因此，也可通过无线网络来构建各建筑物A1、A2、…内的通信和各建筑物A1、A2、…与电梯监视装置10之间的一部分或所有通信。

例如，在各建筑物A1、A2、…的电梯EV1、EV2、…上设置无线接入点。在该情况下，通过各无线接入点，终端11与控制设备12之间、终端11与电梯监视装置10之间的一部分或全部能够进行无线通信。各无线接入点例如考虑对建筑物内的用户的终端11发送确认用户的受灾信息的输入表单、从各无线接入点回收表示各用户的伤势的状况等的受灾信息等利用形态。

(变形例3)

在实施方式中，作为灾害信息通知系统1的一形态，展示了电梯监视装置10在灾害发生范围内提取候选医院的形态。此处展示电梯监视装置10将灾害发生范围外的医院也包括在内来提取候选医院的变形例。

在变形例3中，电梯监视装置10从外部数据库(医院信息数据库等)获取各医院的医院信息D3。

由于电梯监视装置10从外部获取医院信息D3，因此，在各医院的电梯中设置的存储部22中存储好用户信息D1即可。

电梯监视装置10从检测到灾害的医院受理该医院的用户信息D1和该医院的运行状况信息D2。电梯监视装置10在规定时刻从外部数据库获取医院信息D3。继而，电梯监视装置10根据从外部数据库获取到的医院信息D3将各医院的电梯与诊疗科目的关系设定至诊疗科目表T1(参考图3)。此外，电梯监视装置10在医院位置信息表T2(参考图3)中设定各医院的位置。继而，电梯监视装置10以异常感知传感器21未作出反应的灾害范围外的医院的判定信息也包括在内的方式生成判定表T4(参考图4的(b))。例如，电梯监视装置10在诊疗科目表T1中将灾害范围外的医院的各诊疗科目设定为能够接诊的“○”。通过该设定，电梯监视装置10在生成判定表T4时，对于灾害范围外的医院会在各诊疗科目中设定判定信息“○”。

如此，在判定表T4中设定灾害发生范围的医院和灾害发生范围外的医院。电梯监视装置10根据判定表T4、以规定的优先顺序从灾害范围内和灾害范围外算出负责医院无法接诊的利用者能够利用的医院的候选。例如，电梯监视装置10根据判定信息为“○”的医院、按照基准位置到医院的距离由近到远的顺序而以灾害发生范围外的医院也包括在内的方式排列医院的候选。继而，电梯监视装置10将该算出结果即候选医院发送至利用者的终端11。

再者，医院信息D3较理想为在外部数据库中系统的启动时或者1天1次等酌情设定的时刻改写为最新的数据。最新数据的获取例如是电梯监视装置10请求外部数据库或者从外部数据库接收更新的通知等来进行。

在变形例3中，电梯监视装置10不仅从灾害的发生范围还将灾害的发生范围以外的医院包括在内来提取最适于用户的候选医院。如此，通过将灾害的发生范围以外的医院也包含在候选中，电梯监视装置10能在灾害发生范围内找不到医院的情况下从灾害发生范围外的邻近地区将最佳医院可靠地通知用户。

(变形例4)

展示从灾害信息的第1次发布起经过规定时间后、电梯监视装置10能对用户的终端11发布候选医院的最新信息的变形例。此处，以变形例1的构成中从用户的终端11回复了输入表单的情况为一例对发布最新信息的构成进行展示。再者，此处是对与变形例1不同的部分进行说明，与变形例1共通的部分的说明酌情从略。

图11为表示变形例4的电梯监视装置10的功能块的构成的一例的图。在变形例1的功能块的构成中进而设置有计时器201和获取部202。再者，第2受理部301是变形例1中未图示的第2受理部。

计时器201对规定时间进行计数，将该时间经过通知获取部202。此处，作为一例，计时器201从根据灾害发生时的来自用户的受灾信息再次判定的候选医院从输出部104再次发布到用户的终端11时起开始计数。其后，每当经过设定的时间时，计时器210便将该时间经过通知获取部202。例如，在设定成单位间隔为“30分钟”、持续时间为“24小时”的情况下，计时器201每隔30分钟便将设定时间的经过通知获取部202直至24小时过去为止。

每当从计时器201收到设定时间的经过的通知时，获取部202便从各建筑物A1、A2、…获取表示到该设定时间为止的电梯EV1、EV2、…的运行状况的日志(“表示运行频率的信息”的一例)。继而，处理部103对各日志进行解析，生成更新用的运行状况信息D2。

图12为表示上述日志的一例的图。图12的(a)和图12的(b)展示了某一设定时间后的、从第1医院送来的日志D21和从第3医院送来的日志D22。此处是展示的第1医院和第3医院的日志作为一例，但除此以外，获取部202还从第2医院、第4医院等其他医院获取日志。

日志D21是表示第1医院的电梯EV1、EV2、…的运行状况的日志。如日期和时刻两栏所示，日志D21是从“2017年11月9日”的发生时刻10点30分起到1小时后的11点30分为止的日志。日志D22和其他医院的日志也一样，发送的是从“2017年11月9日”的发生时刻10点30分起到1小时后的11点30分为止的日志。图12中展示的是灾害刚发生之后起的全部日志，但各建筑物A1、A2、…也可发送与发送时之前发送的日志的差分。

日志D21中记录了从发生时刻10点30分起到11点27分为止第1医院的电梯EV1和电梯EV2都不可运行(×)这一内容。虽然此处省略了图示，但电梯EV3等其他电梯也与电梯EV1和电梯EV2一样不可运行(×)。继而，在11点28分，电梯EV1和电梯EV2中以“3F”和“2F”的形式记录了目的地楼层，此处，处理部103能够推测运行已恢复。恢复后，电梯的利用较少，因此记录了表示没有电梯的移动的(-)。

在另一日志D22中，记录了第3医院的电梯EV1和电梯EV2在发生时刻10点30分后也都在运行这一内容。继而，记录了从11点27分左右起电梯EV1和电梯EV2分别频繁地往返“3F”和“4F”这一内容，处理部103能够推测开始拥挤起来。

图13为表示再次发布候选医院后电梯监视装置10对用户的终端11发布最新的候选医院用的次序的一例的流程图。图13中，对于变形例1的灾害通知处理的次序(参考图8)予以省略，对步骤S105-4之后的处理进行展示。再者，图13中，为了使得说明易于理解，展示的是针对一位用户的处理次序，但该处理流程是针对各用户来进行。

当步骤S105-4的再次发布完毕时，控制部51通过计时器201开始设定时间的计数(S301)。

接着，当计时器201达到设定时间时，控制部51从各建筑物A1、A2、…获取表示从灾害发生起到该设定时间为止的电梯EV1、EV2、…的运行状况的日志(日志D21、…、日志D22、…)(S302)。

接着，控制部51根据从各日志获得的最新的运行状况信息D2来更新数据库(S303)。具体而言，控制部51根据最新的运行状况信息D2来更新运行状况信息设定表T3(参考图4的(a))的设定，根据运行状况信息设定表T3的更新后的设定来生成判定表(参考图4的(b))。

接着，控制部51针对该用户、根据判定表T4的设定来提取最新的候选医院(S304)。

继而，控制部51指定该用户的终端11的地址而发布包含该用户相关的候选医院的通知画面信息(S305)，结束本处理。

如本处理所示，当达到规定时间时，控制部51以再次算出最新的候选医院并再次发布算出结果的方式进行动作。再者，这一系列动作不限于1次，也可重复多次。例如，在计时器201中设定单位间隔为“30分钟”、持续时间为“24小时”，每隔30分钟便重复上述处理直至24小时过去为止。

接着，对基于最新的运行状况信息D2的运行状况信息设定表T3的设定例和根据该设定再次生成的判定表T4的设定例进行说明。

关于图4的(a)所示的运行状况信息设定表T3，时刻被更新为设定时刻的11点30分。此外，各医院的各电梯EV1、EV2、…的设定被改写。

具体而言，在“第1医院”的日志D21中，灾害发生时，所有电梯EV1、EV2、…都是“不可运行”。但是，通过11点30分左右的EV1、EV2、…的记录数据的解析，预测已在11点28分恢复运行，EV1、EV2、…被改写为“能够运行”。此外，在“第3医院”的日志D22中，灾害刚发生之后电梯EV1、EV2都还是“能够运行”。但是，通过11点30分左右的EV1、EV2的记录数据的解析，将11点27分左右起的频繁的运行预测为拥挤，EV1、EV2都被改写为“拥挤”。

关于图4的(b)所示的判定表T4，第1医院的各诊疗科目从“△”变更为“○”。此外，关于第3医院，虽然内科之前是“○”，但因为“拥挤”而变更为“△”。

因而，在该情况下，在“User1”的终端11上，在10点30分这一时间点，负责医院的患者的接诊状况显示的是“困难”(参考图7)，通过11点30分的更新，变更为表示能够接诊的“可以”。对于“User1”而言，负责医院已可供利用。该情况下，候选医院等其他信息可从通知画面信息中删除。

图14为表示通知画面的内容的更新的一例的图。图14中，作为一例，展示了“User3”的终端11上的通知内容的更新例。图14的(a)为10点30分这一时间点的通知例，图14的(b)为11点30分这一时间点的通知例。像之前说明过的那样，在10点30分这一时间点，第3医院的“内科”是可以利用的。因此，如图14的(a)所示，负责医院的信息910的“患者的接诊”为“可以”。另一方面，在图14的(b)所示的11点30分这一时间点，第3医院的“内科”被判断为“不可”。因此，“患者的接诊”变更为“困难”，在别的候选医院的信息911中呈现“第1医院”等作为候选医院。

再者，在本例的通知画面91中，即便是电梯被解析为“拥挤”的情况，负责医院的信息910的“患者的接诊”一栏中设定的也是与电梯不可运行的情况相同的“困难”。该设定也可改为“拥挤”，以便能与电梯不可运行的情况区别开来。此外，解析时，处理部103也可根据电梯的频率来推算拥挤度数，由此，将“患者接诊”一栏的设定设为该推算出的“拥挤度数”。

此外，本例是设为如下构成：在电梯监视装置10中设置计时器201，当达到计时器201的设定时刻时，电梯监视装置10从各建筑物A1、A2、…获取日志。但并不限于此。也可为，当各建筑物A1、A2、…检测到灾害时，各建筑物A1、A2、…在灾害发生后的一定期间内将上述日志定期发送至电梯监视装置10，由电梯监视装置10受理该日志。

如此，在变形例4中，电梯监视装置10从各建筑物A1、A2、…获取各时间点的运行状况信息D2的最新信息，将其反映至候选医院的判定，从而将最新的候选医院发布至用户的终端11。例如，即便在负责医院在灾害发生的最初无法接诊患者的情况下，从灾害发生起经过10分钟、30分钟、1小时后等随着时间的经过也会恢复，能够接诊的可能性升高。通过以变形例4的方式构成，用户能在恢复的时间点知晓负责医院已经能够接诊这一情况。此外，即便在提供了其他候选医院能够接诊的信息的情况下，随着时间的经过，也存在患者集中于该医院而导致新的患者的接诊变得困难的情况。在这种情况下，通过以变形例4的方式构成，在经过一定时间后会重新呈现候选医院，由此，用户能够知晓最新的接诊状况。

根据以上叙述过的至少一种实施方式或变形例的灾害信息处理装置以及灾害信息通知方法，通过第1受理部来受理表示感知到异常的建筑物的电梯的运行状况的信息。此外，通过存储部来存储多个医院的医院信息和表示用户的宿疾或负责医院的用户信息。此外，通过处理部，根据第1受理部受理到的医院的电梯的运行状况、多个医院的医院信息以及用户信息来算出能够接诊用户信息所示的用户的医院的候选。此外，通过输出部将通过处理部的算出获得的能够接诊用户的医院的候选输出至用户能够确认的终端。因此，可以根据感知到异常的建筑物的电梯的运行状况来掌握是否有因建筑物的受灾等而难以接诊患者的医院或诊疗科目等，从而能将灾害的发生范围内外能够接诊的医院的候选通知用户。

对本发明的若干实施方式进行了说明，但这些实施方式是作为例子呈现的，并非意欲限定发明的范围。这些实施方式能以其他各种形态加以实施，可以在不脱离发明的主旨的范围内进行各种省略、替换、变更。这些实施方式和其变形包含在发明的范围和主旨内，同样包含在权利要求书中记载的发明及其均等的范围内。

Claims (6)

1.一种灾害信息处理装置，其特征在于，具备：

第1受理部，受理表示感知到异常的建筑物的电梯的运行状况的信息；

存储部，针对多个医院的每一个，存储将诊疗科目和以所述诊疗科目为目的地的电梯的信息对应起来的医院信息和表示用户的宿疾或负责医院以及受诊科目的用户信息；

处理部，根据所述第1受理部受理到的医院的电梯的所述运行状况、所述多个医院的医院信息的所述诊疗科目和所述诊疗科目的所述电梯的信息、以及所述用户信息的所述负责医院和所述受诊科目，来算出能够接诊所述用户信息所示的用户的医院的候选；以及

输出部，将通过所述处理部的算出获得的能够接诊用户的医院的候选输出至所述用户能够确认的终端。

2.根据权利要求1所述的灾害信息处理装置，其特征在于，

还具备第2受理部，所述第2受理部受理在所述终端上输入的用户的受灾信息，

所述处理部根据所述第2受理部受理到的所述受灾信息，来算出能够接诊所述用户的医院的候选。

3.根据权利要求2所述的灾害信息处理装置，其特征在于，

所述输出部对用户的终端进行确认该用户的受灾信息的询问，

所述处理部根据针对所述询问从所述用户应答的受灾信息，来算出能够接诊所述用户的医院的候选。

4.根据权利要求1所述的灾害信息处理装置，其特征在于，

所述处理部根据发送了由所述第1受理部受理到的表示电梯的运行状况的信息的各医院和没有受灾的医院，来算出所述能够接诊的医院的候选。

5.根据权利要求1至3中任意一项所述的灾害信息处理装置，其特征在于，

还具备获取部，在经过了设定时间的情况下，所述获取部从感知到所述异常的所述医院获取表示电梯的运行频率的信息作为表示电梯的运行状况的信息，

所述处理部根据所述获取部获取到的各时间点的表示电梯的所述运行频率的信息来更新能够接诊用户的医院的候选，

所述输出部将所述处理部的更新结果再次输出至所述用户能够确认的终端。

6.一种灾害信息通知方法，其从远程监视电梯的异常的电梯监视装置对用户通知能够利用的医院，该灾害信息通知方法的特征在于，包含如下步骤：

利用电梯来感知异常；

收集表示电梯的运行状况的信息；

将所述电梯的存储部存储的表示用户的负责医院和受诊科目的用户信息和通过所述收集获得的表示所述运行状况的信息发送至所述电梯监视装置；

在所述电梯监视装置中，根据通过接收获得的表示医院的所述运行状况的信息、所述电梯监视装置的存储部中存储的、多个医院的每一个中的将诊疗科目和以所述诊疗科目为目的地的电梯的信息对应起来的医院信息的所述诊疗科目和所述诊疗科目的所述电梯的信息、以及所述用户信息的所述负责医院和所述受诊科目，来算出能够接诊所述用户信息所示的用户的医院的候选；以及

将通过所述算出获得的能够接诊用户的医院的候选输出至所述用户能够确认的终端。

Images