服务辅助系统、服务辅助方法及程序与流程

本发明涉及服务辅助系统、服务辅助方法及程序。

背景技术：

在看护机构和/或医疗提供机构中，居住于此的老年人可能发生各种事故。这些事故的原因、因素、危险因素及为了预防事故而应注意的事项等根据事故的种类和/或发生状况而存在多种不同。另外，为了确定多种多样的事故的原因等，需要相应的知识和/或经验。另外，为了该事故的分析、今后的应对和/或预防措施的制定，也会花费大量的时间和劳力。

专利文献1公开了如下技术，即，在生成护理计划时，提取与由用户选择的评估项目的组合图像一致的援助目标项目。

现有技术文献

专利文献

专利文献1：日本专利第3889189号公报

技术实现要素：

技术问题

将已发生的案例的原因、因素、危险因素及案例应注意的事项等提示给工作人员等的技术没有被提出。根据案例的种类和/或发生状况的不同，发生案例的原因等也各种各样，无法统一地确定。而且因为某种想法等，还存在工作人员忽略这样的真正的原因等被疏忽的危险性。

因此，本发明的目的在于，提供服务辅助系统、服务辅助方法及程序，其能够出于多方面的角度提示已发生的案例的能思考到的原因、因素、危险因素及注意事项等。

技术方案

本发明的一个方式的服务辅助系统具备：原因数据库，其针对每种案例的种类存储数据组，所述数据组与针对和案例的发生有关的各事件的各原因关联；接收部，其接收包含有发生的案例的种类和案例的发生状况的输入；匹配部，其使接收到的发生状况与存储于原因数据库的与接收到的案例的种类对应的数据组进行匹配；输出部，其输出匹配部中的匹配所获得的结果的原因。

本发明的一个方式的服务辅助方法包含：接收包含有发生的案例的种类和案例的发生状况的输入的步骤；使接收到的发生状况与存储于原因数据库的数据组中的与接收到的案例的种类对应的数据组进行匹配的步骤，所述原因数据库针对每种案例的种类存储数据组，所述数据组与针对和案例的发生有关的各事件的各原因有关；输出匹配所获得的结果的原因的步骤。

本发明的一个方式的程序在计算机中执行：接收包含有发生的案例的种类和案例的发生状况的输入的步骤；使接收到的发生状况与存储于原因数据库的数据组中的与接收到的案例的种类对应的数据组进行匹配的步骤，所述原因数据库针对每种案例的种类存储数据组，所述数据组与针对和案例的发生有关的各事件的各原因有关；输出匹配所获得的结果的原因的步骤。

技术效果

根据本发明，能够以多方面的观点提示发生的案例的原因、因素、危险因素及注意事项等。

附图说明

图1是示意地表示在看护机构发生的摔倒事故的因素的一个例子的图。

图2是表示利用方式的一个例子的图。

图3是表示服务辅助系统的结构和用户终端的结构的例子的框图。

图4是表示数据库部和匹配部的详细结构的例子的图。

图5是表示摔倒事故的事故报告的制作画面的一个例子的图。

图6是表示输入区域、与输入区域对应的发生状况记录组的图。

图7是表示输入区域、与输入区域对应的发生状况记录组的图。

图8是表示与外在因素有关的输入记录的例子的图。

图9是表示与内在因素有关的输入记录的例子的图。

图10是示意地表示原因记录的例子的图。

图11是用于说明匹配处理的示意图。

图12是用于说明纵向匹配和交叉匹配的图。

图13是表示匹配结果画面的一个例子的图。

图14是表示分析结果画面的例子的图。

图15是表示用户终端的控制方法的一个例子的流程图。

图16是表示服务辅助系统中的服务辅助方法的一个例子的流程图。

图17是表示匹配处理的一个例子的流程图。

图18是表示匹配处理的详细处理的一个例子的流程图。

图19是表示遵循预定规则的处理的一个例子的流程图。

符号说明

210服务辅助系统、

220、220a、220b用户终端、

311通信部、

312存储控制部、

313存储部、

314接收部、

315数据库、

316匹配部、

317输出部、

320输入部、

321通信部、

323显示部、

324显示控制部、

325存储部、

326存储控制部、

401关键词提取部、

402输入记录取得部、

403匹配规则保持部、

404匹配方法确定部、

405匹配处理执行部、

406匹配结果输出部、

450发生状况数据库、

451摔倒事故发生状况数据库、

452误吞·窒息事故发生状况数据库、

453药物事故发生状况数据库、

460原因数据库、

461摔倒事故原因数据库、

462误吞·窒息事故原因数据库、

463药物事故原因数据库。

具体实施方式

[用语的说明]

对本实施方式中说明的用于进行说明。

“工作人员”：机构院长、管理者、护理经理(计划制定担当者)、服务提供责任人、看护工作人员、机构护工、护理人员、功能训练指导员、生活辅导员、生活辅助工作人员及接待事务员等进行与机构相关的工作的人员。

“利用者”：利用本实施方式中说明的系统的人员。作为具体的例子，列举机构的工作人员。

“服务被提供者”：接受机构和/或经营者提供的服务的人员。可以不必入住机构，也包括外来接受一部分服务的人员。在以下实施方式中，列举入住到看护机构的入住者为例子对服务被提供者进行说明。需要说明的是，服务被提供者也可以是像接受门诊看护和/或住宅访问看护等服务的人员那样没有入住到机构的人员，在以下说明的实施方式中，也可以将两者混合说明。

参照附图，对本发明的优选实施方式进行说明。需要说明的是，在各图中，标注相同附图标记的部件具有同一或相同结构。

[事故的因素的说明]

图1是示意地表示在看护机构发生的事故的因素的一个例子的图。图1表示发生摔倒事故的因素多元化的例子。例如，如果将产生摔倒事故的因素大体分为两个，则划分为内在因素和外在因素。

内在因素是指，由入住者本人引起的因素，在摔倒事故中，是入住者的身体·生理的因素，疾病·疾患·症状、正服用的药物等与入住者本人有关的各种因素。例如图1所示，能够进一步分类为身体·生理的因素、疾病·疾患·症状因素、药物因素。例如，作为身体·生理的因素的例子，可列举“是高龄？”、“有摔倒的既往史？”、“有感官下降和/或运动不足等？”、“有失眠、便秘、身体状况欠佳等？”、“产生判断力等的下降？”、“是与平常不同的状态？”等。作为疾病·疾患·症状的因素，列举高血压等循环系统器官的疾病·疾患·症状、和/或脑神经系统的疾病·疾患·症状、和/或心理性疾病·疾患·症状、和/或骨折、肌肉无力等运动功能降低等。作为药物因素，列举正在服用的药物的种类、和/或正在服用的药物的数量等。例如，也有因药物副作用而头晕，而产生摔倒事故。

外在因素是指，因入住者本人以外的因素引起的因素，是包含机构的建筑物的结构和/或房间等的环境、入住者穿在身上的衣服和/或鞋子、拐杖和/或轮椅等使用工具、和/或机构的工作人员的技能、知识、经验、援助方法和/或如何参与、信息共享和/或各种培训等与机构的经营管理有关的事项等在内的因素。例如图1所示，能够划分为环境因素、机构/工作人员因素。作为环境因素的例子，有周边环境和/或身边环境。例如，可列举在走廊有台阶、存在易滑倒的地面的情况等周边环境、和/或正使用拐杖等使用器具、和/或穿在脚上的拖鞋等鞋子等为例子。机构/工作人员因素列举例如工作人员的援助方法等、机构内的信息共享、公知方法、和/或评估·计划和/或工作人员的经营管理等。需要说明的是，上述因素的例子仅是一个例子而已，不限于此。

由此，即使列举出一个例子而概括了摔倒事故，但作为该事故的因素，还包含各种各样的因素。另外，也有因为结合了这些因素中的多个而发生摔倒事故的情况。而且，作为事故的种类，不仅是摔倒事故，还能够产生例如误吞·窒息事故和/或药物事故等。这些事故的因素中包含有与摔倒事故的因素独立存在的各种因素。由此，对于发生在看护机构的入住者身上的各种事故，大多是因为各种因素交织在一起而发生的。另外，也有工作人员的知识和/或经验不足、系统的追踪不足的情况，导致陷入不足的分析，其结果是，有可能导致应对和/或预防措施不当。

因此，在本实施方式中，针对每种事故的种类，将可能发生事故的各种原因、因素及危险因素等体系化而进行数据库化。例如，以成为相同等级结构的数据的方式进行数据库化。并且，在事故发生时，利用者输入与事故发生的状况(包含事故发现的状况。以下相同。)相关的信息，使输入的信息与存储于体系化(例如，结构化、等级化)的数据库的信息按照预定的规则进行匹配。然后基于匹配的结果，给原因候补进行打分。其结果是，将例如得分高的原因候补显示在用户终端上。由此，对事故的原因分析进行辅助。

[整体结构]

图2是表示本实施方式的利用方式的一个例子的图。服务辅助系统210能够构成为服务装置，与多个用户终端220a、220b连接。在图2中，表示两个用户终端，但是用户终端的数量可以是任意数量。将多个用户终端统称为用户终端220。用户终端220及服务辅助系统210通过互联网及lan(localareanetwork：局域网)等网络彼此连接。

用户终端220是由看护机构的工作人员所使用的信息处理终端。在本实施方式中，利用者包括看护机构的工作人员。利用者能够参照显示在用户终端220上的信息等，来确定提供服务所需的信息等。

服务辅助系统210是记录有与所提供的服务相关的数据的服务器等信息处理装置。用户终端220能够基于从服务辅助系统210发送的数据，将信息显示在用户终端220上。另外，服务辅助系统210以例如登录的方式来管理利用者，也能够将与用户终端220的利用者对应的数据发送到用户终端220。

图3是表示本实施方式的服务辅助系统210的结构与用户终端220的结构的例子的框图。

[用户终端的结构]

用户终端220具有输入部320、通信部321、显示部323、显示控制部324、存储部325及存储控制部326。用户终端220能够是例如平板终端、智能手机及计算机等各种信息处理终端。

向输入部320输入来自利用者的操作指示。

通信部321在用户终端220与服务辅助系统210的通信部311之间发送接收各种数据。即，通信部321作为接收部及发送部而起作用。

显示部323显示包含后述的事故报告的制作画面在内的各种画面。例如，显示部323能够使液晶显示器及有机el(electroluminescence：电致发光)显示器等。

显示控制部324对显示在显示部323上的信息进行控制。

存储部325存储各种数据。例如，存储部325存储用于制作事故报告的数据。存储部325可以是hdd(harddiscdrive：硬盘驱动器)和/或闪存等各种存储介质。

存储控制部326向存储部325写入各种数据，或者从存储部325读取各种数据。

用户终端220能够具有未图示的cpu(centralprocessingunit：中央处理单元)、ram(randomaccessmemory：随机存取存储器)及闪存或hdd。闪存或hdd可以与上述存储部325共用，也可以另设。通过将存储于闪存或hdd等的程序暂时被ram读取，并且cpu执行被ram读取的程序，由此cpu能够作为图3所示的用户终端220的各部分而起作用。在此，列举了用软件实现的结构为例子而进行说明，但是也可以由硬件、固件、及软件中的任一者构成。图3仅是表示结构的一个例子而以，用户终端220也可以包含其他结构。另外，不限于记载于图3结构全是必要结构。

[服务器的结构]

接着，对服务辅助系统210的结构进行说明。服务辅助系统210具有通信部311、存储控制部312、存储部313、接收部314、数据库315、匹配部316及输出部317。

通信部311通过互联网及lan等网络的接口在服务辅助系统210与用户终端220之间进行数据的接收发送。即，通信部311作为发送部及接收部而起作用。

存储控制部312向存储部313写入各种数据，或者从存储部313读取各种数据。

存储部313用于存储各种数据。例如，存储部313存储入住者接受提供的服务的预定和实际业绩的数据。存储部313可以是hdd(harddiscdrive：硬盘驱动器)和/或闪存等各种存储介质。

接收部314接收包含发生的案例(例如事故)的种类和案例(例如事故)的发生状况在内的各种信息的输入。例如，接收部314能够接收在通信部311接收到的从用户终端220发送来的信息的输入。以下，作为案例的一个例子，以事故为例子进行说明。

数据库315按照案例(事故)的种类，存储例如将与案例(事故)的发生(包括发现。以下相同)有关系的各事件体系化(例如结构化、等级化)而得的数据组。作为事故的种类，列举例如摔倒事故、误吞·窒息事故及药物事故。也就是说，在该情况下，存储与针对摔倒事故的各事件的各原因有关的数据组、与针对误吞·窒息事故的各事件的各原因有关的数据组、与针对药物事故的各事件的各原因有关的数据组。需要说明的是，在此，列举三个事故的种类为例子进行说明，但是不限于此。另外，为了方便说明，将存储部313与数据库315分开说明，但是也可以将两者共同地构成。

匹配部316使在接收部314接收到的发生状况与存储于数据库315的、与接收到的案例(事故)的种类对应的数据组进行匹配。在后面进行详细说明。

输出部317输出由匹配部316的匹配的结果获得的原因的信息。例如，输出部317能够经由通信部311将原因的信息发送到用户终端220。

服务辅助系统210能够具有未图示的cpu、ram及闪存或hdd。闪存或hdd可以与上述存储部313通用，也可以另设。通过将存储于闪存或hdd等的程序暂时读取至ram，并且cpu执行读取到ram的程序，从而cpu能够作为图3所示的服务辅助系统210的各部分而起作用。在此，列举用软件实现的结构为例子进行说明，但是也可以由硬件、固件及软件中的任一者构成。

服务辅助系统210的各部分中的至少一部分可以通过多个信息处理装置的分散处理来实现。另外，服务辅助系统210可以按照从未图示的云服务器等下载下来的程序来执行处理。图3仅是表示结构的一个例子而已，服务辅助系统210可以包含其他结构。另外，图3所记载的结构的全部并不一定都是不需的要件。

图4是表示数据库315和匹配部316的详细结构的例子的图。在本实施方式中，数据库315具有发生状况数据库450和原因数据库460。发生状况数据库450针对每种事故的种类都具有数据库。在图4的例子中，发生状况数据库450具有摔倒事故发生状况数据库451、误吞·窒息事故发生状况数据库452及药物事故发生状况数据库453。原因数据库460也与发生状况数据库450相同地，针对每种事故的种类都具有数据库。在图4的例子中，原因数据库460具有摔倒事故原因数据库461、误吞·窒息事故原因数据库462及药物事故原因数据库463。需要说明的是，能够通用化的原因也可以通过具有事故通用原因数据库465而共享。

发生状况数据库450及原因数据库460都针对每个事故的种类，存储将与事故的发生相关的各事件体系化(结构化、等级化)而得的数据组。发生状况数据库450和原因数据库460分别存储有经过体系化(结构化、等级化)后的包含多个记录的数据组。在本实施方式中，将存储于发生状况数据库450的记录称为“发生状况记录”。将存储于原因数据库460的记录称为“原因记录”。在本实施方式中，原因记录包含与发生状况记录通用的数据结构。例如，某发生状况记录的第n项(n是自然数)的项目与原因记录的第n项的项目是存储同种项目的数据的结构。也就是说，与事故的发生相关的同种的事件彼此存储在发生状况记录及原因记录的第n项中。在本实施方式中，将n的值为“1”的项目处理成等级最高的项目，将项目的等级处理成随着n的值的增加而变低。

需要说明的是，原因记录除了与和发生状况记录通用的数据结构关联以外，还与“应捕捉的观点和/或原因的候补”这样的表示事故发生的各种因素等的数据关联。也就是说，原因数据库460存储有与针对和事故的发生相关的各事件的各原因有关的数据组。后面对发生状况记录和原因记录进行详细说明。

匹配部316具有关键词提取部401、输入记录取得部402、匹配规则保持部403、匹配方法确定部404、匹配处理执行部405及匹配结果输出部406。

关键词提取部401基于与通过接收输入得到的发生状况相关的信息，提取用于检索数据库的关键词。例如，在图5(后述)所示的在用户终端220的显示部323显示的事故报告的制作画面500上，包含有用于输入发生事故的情况的状况的输入区域。关键词提取部401能够基于输入到输入区域的信息而提取关键词。例如，在摔倒事故的情况下，输入“房间”作为“发现·发生场所”的关键词，或者输入“床位”作为更详细的信息。在该情况下，关键词提取部401将“房间”及“床位”作为关键词而提取。另外，利用自然语言解析等方法和/或软件等，将输入的文字分解为为单词和/或短语，可以生成一个或多个关键词。

输入记录取得部402从发生状况数据库450中选择通过接收部314接收输入的、与发生的事故的种类对应的数据库。例如，在通过输入接收到的事故的种类为“摔倒事故”的情况下，输入记录取得部402选择摔倒事故发生状况数据库451。并且，输入记录取得部402利用由关键词提取部401提取的关键词，检索所选择的摔倒事故发生状况数据库451，将全部包含了关键词的发生状况记录作为输入记录而取得。所取得到的输入记录用于与存储于原因数据库460的原因记录进行匹配处理。输入记录被输送到匹配方法确定部404。

匹配规则保持部403保持匹配规则。在本实施方式中，通过将与输入记录和原因记录对应的项目彼此(第n项彼此)进行比较，进行匹配处理。由此，在本实施方式中，将比较第n项彼此的匹配处理称为“横向匹配”。在本实施方式中，对基本上利用该横向匹配进行匹配处理的例子进行说明，但是对于包含特定项目(或者特定的关键词)的输入记录，执行其他匹配方法。在后面进行详细说明。

匹配方法确定部404参照保持于匹配规则保持部403的匹配规则，来确定输入记录的匹配方法。

匹配处理执行部405按照由匹配方法确定部404确定的匹配方法，针对与事故的种类对应的原因数据库460进行使用输入记录的匹配处理。在如上所述事故的种类为摔倒事故的情况下，匹配处理执行部405针对摔倒事故原因数据库461执行匹配处理。例如，匹配处理执行部405判定包含于处理对象的输入记录的第n项的关键词是否与包含于处理对象的原因记录的第n项的关键词一致。并且，在一致的情况下，将根据与该第n项对应的加权得到的得分与在处理对象的原因记录积累的得分相加。针对摔倒事故原因数据库461的处理对象候补的全部原因记录执行这样的匹配处理(横向匹配处理)。另外，改变处理对象的输入记录并进行上述匹配处理。进行匹配后的得分通过累积而相加，因此，其结果是，与输入记录的一致度高的原因记录的得分高。

匹配结果输出部406输出由匹配处理执行部405得到的匹配处理的结果。作为由匹配处理执行部405得到的匹配处理的结果，算出各原因记录的得分。匹配结果输出部406能够将算出的得分超过预定阈值的原因记录作为匹配处理的结果而输出。或者，匹配结果输出部406可以不将原因记录本身输出，而将与原因记录关联的“应捕捉到的观点和/或原因的候补”这样的表示事故发生的各种因素等的数据作为匹配结果输出。

接着，列举具体的例子对匹配处理进行详细说明。

图5是表示在用户终端220的显示部323显示的、摔倒事故的事故报告的制作画面500的一个例子的图。事故报告是指，在发生事故的情况(或者在发现事故的情况)下，记载了该事故的内容和/或应对状况、原因的分析、今后的应对和/或预防措施等的报告。用户终端220的利用者(看护机构的工作人员)按照制作画面500输入所需的事项。另外，已在未图示的其他画面上输入的事项也可以反映在制作画面500上。

输入区域501是用户终端220的利用者输入发现摔倒事故的日期时间·发生摔倒事故的日期时间的区域。输入区域502是用户终端220的利用者输入发现摔倒事故的状况·发生摔倒事故的状况的区域。输入区域503是用户终端220的利用者输入发现摔倒事故的场所·发生摔倒事故的场所的区域。输入区域504是用户终端220的利用者输入发现摔倒事故的发现者的区域。图5的制作画面500示例输入区域的一部分，例如通过滑动画面，而将输入其他输入区域的画面显示在显示部323上。

图6表示滑动图5的制作画面500或者用其他画面显示的输入区域601、602、603、包含与这些输入区域对应的事件的发生状况数据库450的发生状况记录组610、620、630。发生状况记录组610、620、630是与外在因素有关的记录组。如图1所说明的，在外在因素中，按种类分类，在图6的例子中，表示了存在“发现·发生场所”的种类、障碍物“障碍物”的种类及“身边”的种类的例子。

列举发生状况记录组610为例对存储于发生状况数据库450的发生状况记录的数据结构进行说明。发生状况记录具有上述等级化的结构。在图6的例子中，将最高级的等级显示为“lv1”，伴随着等级降低，增加“lv2”、“lv3”和等级数量。因为图6是图1所说明的与“外在因素”有关的记录，所以在最高级的等级的项目中包含“外在”的数据。另外，因为记录组610是“发现·发生场所”的种类的记录组，所以在“lv2”的等级的项目中包含“场所”的数据。在之后的等级的项目中包含含有可在输入区域601输入的项目在内的记录。如图6所示，伴随着从最高级的等级朝向低级的等级，发生状况记录设定更详细的(具体的)内容。

在输入区域601中，列举多个能够利用复选框进行标记的事项作为发现·发生场所的候补。在该例子中，标记“房间”。另外，在“房间”中还包含单选按钮，能够指定房间中的详细的场所。在该例子中，选择“厕所”。利用输入部320输入到在用户终端220的显示部323上显示那样的输入区域601中的信息被从用户终端220发送到服务辅助系统210。

在服务辅助系统210中，关键词提取部401基于从用户终端220送信来的信息，提取关键词。在该例子中，作为“发现·发生场所”的种类的关键词，基于发送来的数据，将“房间、厕所”提取为关键词。接着，输入记录取得部402从摔倒事故发生状况数据库451，取得与该关键词对应的发生状况记录作为输入记录。也就是说，在图6的例子中，作为“发现·发生场所”的种类的输入记录，在记录组610中取得记录611。

同样地，根据在输入区域602中输入的事项，从障碍物“障碍物”的种类的记录组620中取得对应的输入记录，根据在输入区域603中输入的事项，从“身边”的种类的记录组630中取得对应的输入记录。

也就是说，在图6的例子中，根据在输入区域601、602、603中输入的事项，输入记录取得部402取得发生状况记录611、621、622、631、632、633作为输入记录。这样的输入记录如后所述用于匹配处理。

图7表示滑动图5的制作画面500或在其他画面显示的输入区域701、703、包含于图5的制作画面的输入区域501、与这些输入区域对应的发生状况数据库450的记录组710。记录组710是与内在因素有关的记录组。在内在因素中，将种类分类为“事故时的行动”、“与平常不同的状态”、“疾病·疾患·症状”、“药物”。在图7的例子中，表示“事故时的行动”的种类的发生状况记录的例子。

记录组710与以图6的外在因素说明的内容相同地，包含与可在输入区域701输入的事项对应的各记录，关键词提取部401基于从用户终端220发送来的信息，提取关键词。记着，输入记录取得部402从摔倒事故发生状况数据库451，取得与该关键词对应的发生状况记录作为输入记录。也就是说，在图7的例子中，在“事故时的行动”的种类的记录组710中，取得记录711、712、713。

需要说明的是，在图7所示的内在因素的情况下，除了该种类的在输入区域中输入的信息以外，还能够将在其他输入区域中输入的信息用作记录的预定项目的关键词。例如，因为在输入区域501中输入发现事故时的发现日期时间·发生事故时的发生日期时间，所以关键词提取部401基于该输入的日期时间，提取时间段的关键词。例如，如图表721所示，预先准备将作为事故报告的发现·发生日期时间而输入的值与时间段对应的图表。关键词提取部401参照图表721，例如确定时间段是“早晨”、是“白天”、是“夜晚”、还是“深夜”。并且，如记录组730所示，输入记录取得部402在记录组710的“lv6”的等级，取得包含该关键词(在该例子中，是“夜晚”)的记录组730作为输入记录。也就是说，通过转用已在其他输入区域中输入的值，能够节约再次输入的时间，并且即使漏输入，输入记录取得部402也能够取得适当的记录作为输入记录。

同样地，输入区域703是与“事故时的行动”的种类对应的输入区域以外的输入区域，表示选择事故发生状况的区域。图表722是将输入到该输入区域703的值与对应的关键词对应的图表。关键词提取部401基于在输入区域703中输入的值和图表722，确定是在“援助中”、是在“非援助中”、还是不输入任何内容的“null”。并且，如记录组730所示，输入记录取得部402在记录组710的“lv7”的等级，取得包含该关键词(在该例子中，是“援助中”)的记录组作为输入记录。

需要说明的是，由此，参照在其他输入区域中输入的值的图表信息、和/或表示输入参照而获得的关键词的输入口的各种信息可以保持于匹配规则保持部403，关键词提取部401及输入记录取得部402能够参照保持于匹配规则保持部403的匹配规则，进行处理。

同样地，输入记录取得部402也取得作为其他种类的“与平常不同的状态”、“疾病·疾患·症状”及“药物”的输入记录。

图8是表示与由输入记录取得部402取得的外在因素有关的输入记录的例子的图。按照利用图6说明的处理，取得各种类的输入记录。匹配处理执行部405进行将这样获得的各种类的各输入记录与存储于原因数据库460的各原因记录匹配的处理。需要说明的是，如图7所说明的，如项目801和/或项目802所示，作为外在因素而处理的项目被设定为内在因素的特定项目的关键词等以某种类而处理的项目也用于其他种类。

图9是表示与由输入记录取得部402取得的内在因素有关的输入记录的例子的图。按照利用图7说明的处理，取得各种类的输入记录。在项目951包含图8的项目801及项目802的关键词。需要说明的是，在目前为止的例子中，在输入区域，预先利用单选按钮及复选框等规定了值，对直接使用规定的值(关键词)的方式进行了说明，但是不限于此。例如，如项目960所示，假设在输入区域的选择项中有“沐浴后疲劳”这样的项目的情况。在该情况下，关键词提取部401例如项目955所示地将“沐浴”设定为关键词，并且，能够如项目956所示地设定“沐浴疲劳”。关键词提取部401可以按照例如保持于匹配规则保持部403的规则，进行这样的关键词的提取。

另外，目前为止列举了预先在输入区域包含选择项的方式为例进行说明，但是输入区域也可以是自由记入栏。在该情况下，关键词提取部401可以基于输入的信息，提取关键词。

接着，对原因数据库460的结构进行说明。

图10是示意地表示包含于原因数据库的原因记录的例子的图。包含于原因数据库460的原因记录与包含于发生状况数据库450的发生状况记录相同地包含等级结构。

例如，图10(a)表示与外在因素有关的原因记录的结构的例子，原因记录中的第一部分1001是与图8的输入记录(发生状况记录)的结构相同的结构。

其中，针对设定于发生状况记录的各项目的关键词，原因记录是可设定该关键词的同义词、代名词、别名、其他语言、释义、措辞等的方式。这是因为，即使在发生例如包含于发生状况记录的各项目的关键词的记载模糊等的情况下，也利用匹配处理使其一致。例如，如果列举“床位”这样的项目为例进行说明，则在原因记录的“床位”的项目中，可以存在记载模糊等而设定“床”、“chuang”、“chuangwei”“bed”(“べっと”“べっど”“ベット”“bed”)等那样的多个关键词。

另外，在原因记录中还包括第二部分1002。第二部分1002包含与各第一部分1001的内容对应的、“应捕捉到的观点和/或原因的候补”这样的表示事故发生的各种因素等的数据。也就是说，原因记录可以说是与针对和事故的发生相关的事件(第一部分1001)的原因(第二部分1002)关联的数据。

图10(b)表示与内在因素有关的原因记录的结构的例子，与外在因素相同，原因记录中的第一部分1051是与图9的输入记录(发生状况记录)的结构相同的结构，原因记录中的第二部分1052包含与第一部分1051的内容对应的、“应捕捉到的观点和/或原因的候补”这样的表示事故发生的各种因素等的数据。

图11是用于说明按照匹配方法确定部404所确定的匹配方法而利用匹配处理执行部405执行的匹配处理的示意图。

在说明匹配处理前，首先，对匹配方法确定部404所确定的匹配方法的种类进行说明。匹配方法确定部404参照保持于匹配规则保持部403的匹配规则，确定与输入记录对应的匹配方法。作为本实施方式中的匹配方法的种类，有“横向匹配”、“纵向匹配”、“交叉匹配”。当然，这仅是一个例子而已，可以考虑“随机匹配”和/或“全部匹配”等其他多种匹配方法，因此不限于此。以下，对各匹配方法进行说明。

[横向匹配]

“横向匹配”是如上所述，在使输入记录的各项目与包含于原因数据库的原因记录的各项目进行匹配时，使各相同等级水平的相同项目彼此匹配的处理。例如，如果利用图11的例子进行说明，则使“发现·发生场所”的种类的输入记录1110的最高级的等级(lv1)的项目与包含于原因记录组1151的原因记录1152的最高级的等级(lv1)的项目彼此匹配。具体地说，将包含于输入记录1110的最高级的等级(lv1)的项目的关键词与包含于原因记录1152的最高级的等级(lv1)的项目的关键词进行比较，判定是否一致。在一致的情况下，将使用了与输入记录的加权系数1102对应的加权的得分与累积于该原因记录1152的得分(初始值为0)相加。接着，将“发现·发生场所”的种类的输入记录1110的第二级的等级(lv2)的项目与包含于原因记录组1151的原因记录1152的第二级的等级(lv2)的项目彼此匹配。并且，在图11的例子中，如果最低级的等级(lv7)与(lv7)的项目彼此的匹配结束，则接下来进行发生状况记录1110与包含于原因记录组1151的下一个原因记录1153的匹配处理。

由此，进行“发现·发生场所”的种类的输入记录1110与包含于“发现·发生场所”的种类的原因记录组的全部原因记录的匹配。如果输入记录1110的处理结束，则将发生状况记录组1101的中的“发现·发生场所”的种类的下一个输入记录1111用作处理对象的输入记录，同样地进行匹配处理。

如果使用“发现·发生场所”的种类的输入记录的匹配处理结束，则接下来，进行作为下一个种类的“障碍物”的种类的输入记录与原因记录组1151中的障碍物“障碍物”的种类的原因记录的匹配处理。

在本实施方式中，根据等级来设定加权系数1102。具体地说，加权系数1102是等级越低，加权越大的系数。如上述各例子所说明的，本实施方式中的发生状况记录及原因记录伴随着等级下降，而设定更详细的项目。例如，如果列举“发现·发生场所”的种类为例，则在高级的等级中设定“房间”的情况下，在其下级的一等级设定“床位”，再下一级的等级设定“双层床位”等。越是更详细的项目，应捕捉到的观点和/或原因的候补也就越是具体的内容。因此，通过使用等级越低则加权越大的加权系数1102，能够提高详细项目一致的情况下的原因记录的得分。因此，容易选择具体的“应捕捉到的观点和/或原因的候补”。

需要说明的是，在图11的例子中，说明了针对每个种类都进行处理的例子，但是如上所述，发生状况记录及原因记录的最高级的等级能够包含“内在因素”或“外在因素”的项目，最高级的下一个等级能够包含“发现·发生场所”等种类的项目。因此，也可以是忽略种类，针对处理对象的输入记录，将所有的原因记录作为处理对象进行处理的方式。

[纵向匹配]

图12是用于说明“纵向匹配”和“交叉匹配”的图。对“纵向匹配”进行说明。“纵向匹配”是利用特定种类的输入记录的特定等级的关键词，仅与各原因记录中的预定等级的项目进行匹配的处理。由此，称为仅将各原因记录中的特定等级作为对象进行匹配、也就是说，沿列方向(纵向)进行匹配。由此，进行跨种类的匹配。利用保持于匹配规则保持部403的匹配规则，预先定于该特定种类的特定等级。也就是说，在匹配方法确定部404从输入记录取得部402接收到输入记录的情况下，匹配方法确定部404参照保持于匹配规则保持部403的匹配规则，判定是否适合“纵向匹配”。并且，在适当的情况下，匹配方法确定部404确定利用包含于该项目中的关键词，进一步执行“纵向匹配”的处理。需要说明的是，在该项目中不包含关键词的情况下，不执行处理。

列举具体的例子而进行说明。作为匹配规则，预先定义以下内容。即，定义执行设定于特定种类的特定项目的关键词与各原因记录的特定等级的项目的匹配的匹配规则。并且，例如，在处理对象的输入记录的“与平常不同的状态”种类的等级(lv5)中包含“头晕”这样的关键词的情况下，匹配方法确定部404确定针对“事故时的行为”、“疾病·疾患·症状”、“药物”种类的等级(lv5)进行“纵向匹配”。

需要说明的是，“纵向匹配”是相对于“横向匹配”而追加进行的匹配处理，在对包含特定的关键词(例如“头晕”)的输入记录进行处理时，也对该处理对象的输入记录进行“横向匹配”本身的处理。

匹配处理执行部405针对与由匹配规则定义的该特定的关键词(头晕)对应的特定项目，按照定义的匹配规则，跨种类仅对特定的等级的项目进行检索。并且，如果是一致的项目，则将对应于该项目的加权与在包含该项目的原因记录累积的得分相加。例如，作为产生头晕的原因，考虑身体的原因、疾病的症状、药物的影响等各种情况。因此，例如，在“与平常不同的状态”的种类，在包含“头晕”作为与平常不同的状态的情况下，检索“事故时的行动”的种类的“移动”的项目，检索“疾病·疾患·症状”的种类的“症状”的项目，检索“药物”的种类的“副作用”的项目。其结果是，例如，在“事故时的行动”的原因记录中包含“adl(activitiesofdailyliving：日常生活活动)/体力下降”作为原因的原因记录的得分高，或者在“疾病·疾患·症状”的原因记录中包含“痴呆的周边症状”、“脑血管疾患”作为原因的原因记录的得分高，或者在“药物”的原因记录中包含“安眠药”、“抗焦虑药”、“抗癫痫药物”作为原因的原因记录的得分高。

根据这样的处理，能够尽可能广泛地收集原因的可能性。除此以外，将得分高的内容提示给利用者，进行督促利用者确认的处理。因此，在“头晕”等考虑到多方面原因的情况下，加上包含该原因的可能性的原因记录的得分。因此，能够减少因利用者的经验等的不同而疏忽的事项。也就是说，在利用者(工作人员)输入发生状况时，因为与不能从该输入的信息中立刻注意到的原因相关的原因记录的得分高，所以提高对利用者不能注意到的原因进行注意的可能性。另外，因为纵向匹配能够针对还包括等级较低的等级(规定了详细项目的等级)在内的多个等级而进行，所以如上所述，增加一致的情况下的加权。因此，由于与纵向匹配一致的原因记录的得分相对于与纵向匹配不一致的原因记录的得分更高，所以在上述例子中，提高与“头晕”的原因关联的原因记录的得分，进一步提高选出为匹配结果的可能性。

[交叉匹配]

接着，对“交叉匹配”进行说明。在输入记录的处理对象的项目为特定种类的特定等级的项目的情况下，交叉匹配将选择了该发生状况的输入记录重新取得到输入记录取得部402。并且，是利用重新取得的输入记录，进行上述匹配处理的处理。换言之，是在输入记录的处理对象的项目是某特定种类的特定等级的项目的情况下，利用包含于项目的关键词，与不同种类的不同等级的项目进行匹配的处理。针对作为交叉匹配的对象的特定种类的特定等级的项目和关键词等，匹配规则保持部403预先定义匹配规则。需要说明的是，在该项目不包含关键词的情况下，不执行处理。

例如，针对利用者没有输入的项目(因此，在输入记录的特定项目不包含关键词的项目)，就像利用者输入了那样进行处理，间接地进行匹配。对具体例子进行说明。例如，假设输入帕金森病作为“疾病·疾患·症状”的情况。此时，利用者虽然知道该入住者是帕金森病，但是还有不知道此人所使用的药物的情况。在该情况下，对于“药物”的种类，处于没有选择药物的状态、也就是说空白。通过使用交叉匹配，即使是这样的空白，也能够将与“药物”有关的输入记录处理为包含与帕金森病关联的药物的名称的输入记录。具体地说，按照在匹配规则保持部403中定义的匹配规则，输入记录取得部402重新取得将与该帕金森病关联的药物的名称包含在“药物”的输入记录所对应的项目的输入记录，将其作为处理对象的输入记录而进行处理。由此，在输入药物的名称的状态下，执行与“药物”的种类有关的横向匹配。

根据这样的处理，能够尽可能广泛地收集原因的可能性。除此以外，将得分高的内容提示给利用者，进行督促利用者确认的处理。因此，能够减少因利用者的经验等的不同而疏忽的事项。也就是说，在利用者(工作人员)输入发生状况时，因为与不能从该输入的信息中立刻注意到的原因有关的原因记录的得分高，所以提高对利用者不能注意到的原因进行注意的可能性。另外，交叉匹配也与纵向匹配相同地，因为在等级较低的等级(规定了详细项目的等级)进行，所以如上所述，一致的情况下加权增大。因此，因为与交叉匹配一致的原因记录的得分相对于与交叉匹配不一致的原因记录的得分更高，所以选出为匹配结果的可能性高。

需要说明的是，在进行交叉匹配时，与基于利用者实际输入的信息而取得的输入记录的加权相比，可以将该特定等级的项目的加权设定得更低。这是因为，输入了实际正在使用的“药物”的名称的情况是实际该入住者正在服用的药物的可靠性高。

由此，匹配处理执行部405按照由匹配方法确定部404确定的匹配方法，分别对输入记录进行匹配处理。其结果是，分别求出原因数据库460的原因记录的得分。匹配结果输出部406输出得分满足预定条件的原因记录。例如，能够输出超过预定阈值的得分的原因记录，或者按照得分最高的顺序输出预定数量的原因记录，或者针对各种类而按照得分从高到低的顺序输出预定数量的原因记录，或者输出设定的数量的分数，或者在没有达到设定的得分的情况下不输出。输出部317将例如包含在匹配结果输出部406所输出的原因记录的第二部分1002、1052的内容、即、“应捕捉到的观点和/或原因的候补”这样的表示事故发生的各种因素等的信息发送到用户终端220。

需要说明的是，由匹配规则保持部403保持的规则在进行检索的基础上，还可以包含如下规则，所述规则规定了在没有下一个项目的情况下，是结束检索、或者继续检索、是限定预定范围而进行检索、还是跳过一段继续检索等。另外，可以包含在执行检索时，根据项目设定全文一致、局部一致的规则。另外，也可以包括根据种类来改变加权系数的规则。另外，匹配规则可以是参照例如互联网上所公开的其他信息等的规则。可以在输入例如帕金森病和关键词的情况下，检测网络等，取得对应的治疗药和/或新药的信息，利用该信息执行交叉匹配。

图13是表示显示在用户终端120的显示部323上的匹配结果画面1300的一个例子的图。在此，按照得分的从高到低排列显示应捕捉到的观点·原因的信息。利用者确认匹配结果画面1300，在复选框1310标注正确的事项。并且，如果利用输入部320输入ok按钮1320的选择指示，则将标注的内容通过通信部321发送到服务辅助系统210。在服务辅助系统210中，将标注的内容确定为应捕捉到的观点和/或原因的事项。并且，存储控制部312存储有在存储部313确定的应捕捉到的观点和/或原因的数据。在进行事故报告的制作时，利用存储控制部312读取如此存储的应捕捉到的观点和/或原因的数据，而自动地进行设定。

图14示出表示最终获得的应捕捉到的观点和/或原因的、观点和/或原因的检索结果画面1400的例子。观点和/或原因的检索结果画面1400在用户终端220的显示部323上显示。(统一术语)

[用户终端的流程图]

图15是表示用户终端220的控制方法的一个例子的流程图。

在步骤s1505中，显示控制部324根据输入到输入部320的指示，将事故报告的制作画面500显示在显示部323上。用户终端220的利用者根据制作画面500，输入各种值及信息等。

在步骤s1510中，通信部321将输入到输入部320的信息发送到服务辅助系统210。之后，在服务辅助系统210执行匹配处理。

在步骤s1515中，显示控制部324基于从服务辅助系统210发送来的信息，将匹配结果画面1300显示在显示部323上。用户终端220的利用者确认正显示在匹配结果画面1300上的内容，选择认为适当的事项。

在步骤s1520中，通信部321基于输入到输入部320的选择指示，将所选择的事项发送到服务辅助系统210。

在步骤s1525中，显示控制部324基于从服务辅助系统210发送来的信息，显示观点和/或原因的检索结果画面1400。

[服务辅助系统210的流程图]

图16是表示服务辅助系统210中的服务辅助方法的一个例子的流程图。

在步骤s1605中，接收部314通过通信部311接收从用户终端220发送来的信息。

在步骤s1610中，匹配部316执行匹配处理。在后面对匹配处理的流程进行说明。

在步骤s1615中，输出部317通过通信部311向用户终端220发送匹配结果。

在步骤s1620中，接收部314通过通信部311，接收在用户终端220选择的事项。

在步骤s1625中，存储控制部312将在步骤s1620中接收到的事项的数据写入存储部313。

在步骤s1630中，输出部317基于在步骤s1620中接收到的事项，通过通信部311向用户终端220发送观点和/或原因的检索结果的信息。

图17是表示步骤s1610的匹配处理的详细处理的一个例子的流程图。

在步骤s1705中，关键词提取部401基于用户在例如事故报告的制作画面500输入的信息，提取针对选择的项目的关键词。

在步骤1710中，输入记录取得部402从发生状况数据库450取得与在步骤s1705中提取的关键词对应的发生状况记录作为输入记录。此时，利用与针对每种事故的种类对应的数据库来取得输入记录。按照种类来取得输入记录。另外，可以在各类别中取得多个输入记录。

在步骤s1715中，匹配方法确定部404参照保持于匹配规则保持部403的匹配规则，确定适用于在步骤s1710中取得的各输入记录的匹配规则。例如，除了“横向匹配”以外，还能够确定“纵向匹配”及“交叉匹配”等各种匹配规则。

在步骤s1720中，匹配处理执行部405利用在步骤s1610中取得的各输入记录，按照在步骤s1615中确定的匹配规则，对存储于原因数据库460的各原因记录进行匹配处理。此时，针对收纳在与事故的种类对应的数据库的原因记录进行匹配处理。匹配处理执行部405根据匹配的结果，将累积于各原因记录的得分相加。

在步骤s1725中，匹配结果输出部406基于在步骤s1720获得的得分，确定匹配结果。例如，将超过预定阈值的原因记录确定为匹配结果的候补。

在步骤s1730中，匹配结果输出部406将在步骤s1725中确定的匹配结果输出到输出部317。

图18是表示步骤s1720的详细处理的一个例子的流程图。

在步骤s1805中，匹配处理执行部405选择处理对象的输入记录内的未处理的项目。从处理对象的输入记录的最高级的等级的项目朝向下级的等级的项目，针对每个项目进行处理。

在步骤s1810中，匹配处理执行部405判定在步骤s1805中是否能够选择下一等级的项目。在能够选择下一项目的情况下，进入步骤s1815，在不能的情况下，进入步骤s1835。

在步骤s1815中，匹配处理执行部405判定处理对象的项目是否是符合预定的规则的项目。例如，判定纵向匹配和/或交叉匹配的对象的项目。在符合预定的规则的项目的情况下，进入步骤s1820，在步骤s1820中，匹配处理执行部405执行按照预定的规则的处理。在不符合的情况下，进入步骤s1825。

在步骤s1825中，匹配处理执行部405判定处理对象的项目是否与原因记录的对应的项目的关键词一致。即，进行上述的横向匹配。在一致的情况下，进入步骤s1830。在不一致的情况下，进入步骤s1832。

在步骤s1830中，匹配处理执行部405将与处理对象的项目的加权对应的得分与处理对象的原因记录的得分相加。接着，进入步骤s1832。

在s1832中，匹配处理执行部405判定是否进入下一项目。例如，存在在匹配结果不一致的情况下不想进入下一项目的情况、和/或处理对象的原因记录的结构只到中间等级的项目的情况。在这样的情况下，在当前处理中的项目为lv3的项目的情况下，在步骤s1832不进入下一项目，处理进入步骤s1835。在不是上述情况的时，处理返回步骤s1805。由此，在处理对象的输入记录内的各项目与处理对象的原因记录内的各项目之间，进行匹配处理。

在步骤s1810中，在判定为不能选择下一项目的情况下，进入步骤s1835。

在步骤s1835中，匹配处理执行部405判定是否有下一处理对象的原因记录。在有下一原因记录的情况下，进入步骤s1840。在没有下一原因记录的情况下，因为完成了针对所有的原因记录的处理，所以结束本处理。

在步骤s1840中，匹配处理执行部405更新处理对象的原因记录。

在步骤s1845中，匹配处理执行部405清除输入记录内的已处理完的项目的信息。即，改变为输入记录的各项目是未处理的项目的状态。接着，返回步骤s1805。由此，针对在步骤s1840中更新的处理对象的原因记录，从步骤s1805开始再次进行最高级的项目彼此的横向匹配。

图19是表示步骤s1820的详细处理的一个例子的流程图。

在步骤s1905中，匹配处理执行部405判定处理对象的项目是否是纵向匹配的对象。在是纵向匹配的对象的情况下，进入步骤s1910。在不是纵向匹配的对象的情况下，进入步骤s1935。

在步骤s1910中，匹配处理执行部405执行由匹配规则规定的特定等级的项目的检索。

在步骤s1915中，匹配处理执行部405判定是否与原因记录的特定等级的项目的关键词一致。在一致的情况下，进入步骤s1920，将与输入记录的处理对象的项目的加权对应的得分与在和其一致的原因记录累积的得分相加。接着，进入步骤s1925。

在步骤s1925中，匹配处理执行部405判定处理对象的原因记录是否是处理对象的最终的原因记录。即，判定是否是列方向的最终行。在是最终行的情况下，进入步骤s1935。在不是最终行的情况下，进入步骤s1930，更新处理对象的原因记录，使处理返回步骤s1910。

在步骤s1935中，匹配处理执行部405判定输入记录的处理对象的项目是否是交叉匹配的对象。在是交叉匹配的对象的情况下，进入步骤s1940，在不是交叉匹配的对象的情况，结束本处理。

在步骤s1940中，匹配处理执行部405将在由匹配规则规定的对象项目中输入了由匹配规则规定的特定的关键词的状态下的输入记录追加为未处理的输入记录。由此，进行使用输入了特定的关键词的状态的输入数据的横向匹配。以上是流程图的说明。

至此，列举摔倒事故的情况为例进行说明。以下，除了摔倒事故以外，说明可在看护机构发生的事故、其主要因素的具体例子。除了摔倒事故以外，作为在看护机构发生的事故，列举误吞·窒息事故(以下，称为“误吞事故”。)。在误吞事故中，除了事故时的吃饭的内容、和/或吃饭场所、和/或工作人员的援助方法、和/或工作人员的如何援助这样的外在因素以外，列举入住者的吃饭的方法、和/或身体·生理的因素、和/或疾病·疾患·症状、和/或正在服用的药物等与入住者本人相关的各种内在因素作为误吞事故的因素。在误吞事故中，将原因食品的食品形式、和/或是否使用增稠剂、和/或吃饭时间、和/或吃饭场所、和/或使用工具、和/或假牙等外在因素详细分类。另外，对于工作人员的援助方法和/或参与的方法而言，还包含与厨房的联合，详细分类在饭前、吃饭中、饭后进行怎么样的对应。对于入住者本人而言，将内在因素详细分类至吃饭摄入能力、和/或吃饭时的姿势、和/或吃饭动作、和/或营养状态、和/或食欲·积极性、和/或口腔护理的状况、和/或环境变化、和/或与平常不同的状态、和/或疾病·疾患·症状、和/或正在服用的药物。通过这样地进一步细化事故的发生状况，能够准确地匹配与其关联的原因和/或应捕捉到的观点。作为具体例子，在是患有痴呆的入住者的情况下，将“无法识别食物？；清楚味道和/或温度而进食？”、“影响其他入住者的吃饭；或者没有异食癖行为？；混合食用没问题？”这样的观点列表在匹配结果画面1300上，另外，在是患有帕金森病的入住者的情况下，将“有因手抖而撒手？”这样的观点列表在匹配结果画面1300上。

另外，作为在看护机构中发生的其他事故，有药物事故。在药物事故中，像医生的处方、和/或药房的配药和交付、和/或看护机构的护理人员进行的药剂管理、和/或护理人员或看护职员进行的吃药援助等那样的在入住者服用药剂前的一系列作业流程成为药物事故发生的原因。因此，能够分类为配药药房的因素、和/或护理人员的因素、和/或看护工作人员的因素等外在因素。另外，能够将各分类进一步细化。作为药物事故的原因和/或应捕捉到的观点，例如，能够将药房的错误细化为“配药错误”、“打包错误”、“印刷错误”、“疑问咨询的误解”等。能够将护理人员的错误细化为例如“受领错误”、“使用未经配置的药物”、“错误地安排人员”、“错误地设定计数·计量”、“错误地安排服用时间”、“错误地服用处方天数”、“错误地采用服用方法”、“忘记服用”等。能够将看护工作人员的错误细化为例如“服用错误的药物”、“使错误的人服用”、“弄错服用时间而服用”、“弄错计数·计量而服用”、“弄错服用方法而服用”、“不能服用”等。针对每种发生的情况，都将作为对象的原因和/或应捕捉到的观点列表在匹配结果画面1300上。

在到目前为止说明的实施方式中，列举可在机构引起的事故为例进行说明，但是不限于此，能够应用各种案例。作为案例的例子，也能够应用在包含事故及有可能发生的事故在内的意外。也就是说，不仅是制作事故报告的情形，也能够应用在日常的业务中发生有可能发生的事故的情况下制作该其报告等的情形。另外，也能够应用在除事故以外的其他业务的案例。例如，列举护理计划。是基于每个入住者的评估结果，导出最恰当的护理计划候补的方式。作为该应用例子的实现方法，将各评估项目分类划分而体系化(结构化、等级化)并数据库化。并且，将护理计划的事例分类划分而体系化(结构化、等级化)并数据库化。除了针对各评估项目的护理计划事例以外，还假设跨分类的情况，因此，如上述摔倒事故那样，也能够保持任意的匹配规则而进行纵向匹配和/或交叉匹配等。作为评估和护理计划两者的分类例，列举“吃饭·水分”、“口腔护理”、“沐浴”、“理发”、“排泄”、“移动·换乘·身体功能”、“睡眠”、“兴趣·活动”、“记忆·认知”、“精神·行动”、“健康管理·医疗护理”、“其他生活”等各种各样的生活的情形和/或入住者的能力和/或热情、特性等。通过基于这样的分类根据入住者的评估制定最恰当的护理计划，从而能够进行综合地考虑·判断了各入住者的能力和/或热情、特性等的具体且恰当的生活的辅助。

另外，作为案例，可以不是发生了问题、或者可发生问题的案件，而是发生了改善、或者可发生改善的案件。例如，在看护机构中，是如下情况，即，在是预定的事件(例如，插花、改变散步的路线、进行与平常不同的语音呼叫等)的情况下，发生某种改善(例如，入住者的心情变好、开始哼歌、比平常健谈等)。由此，针对不是发生了问题或者可发生问题的案件、而是发生了改善或者可发生改善的案例而言，也能够应用上述实施方式所说明的结构及处理。

另外，到目前为止列举主要用于看护机构的方式为例进行了说明，但是不限于此。例如，在医疗提供机构中，也能够产生同种的事故等案例，即使在医疗提供机构中，也可以使用上述服务辅助系统210。另外，服务被提供者可以不必须是老年人和/或患者，而应用在例如将孩子等作为服务被提供者的幼儿园和/或小学生俱乐部等。另外，针对可在学校、工作单位等各种情形引起的案例而言，也能够应用上述实施方式所说明的服务辅助系统210。

对于上述各种数据的体系化、结构化、等级化而言，也能够对数据进行标记而使其具有意义。并且，在各种规则中，没有将安装在搭载有人工智能功能的系统中并进一步限定的数据库作为匹配对象，而是通过将互联网上的很多网页等作为信息源，从而能够实现匹配处理的多样性和高速化。例如，可以基于显示在匹配结果画面1300上的信息、用户通过该匹配结果画面1300选择的事项的信息，适当地改变在匹配规则保持部403中保持的匹配规则。例如，收集很多显示在匹配结果画面1300上的信息和用户通过该匹配结果画面1300选择的事项的信息，利用它们将加权系数最优化。另外，也可以基于用户通过匹配结果画面1300选择的事项的信息，再构建数据库。例如，也可以将利用匹配结果画面1300显示在用户终端220上的内容、用户通过该匹配结果画面1300选择的事项用作教师数据，构建学习模型。并且，也可以采用使用该构建的学习模型作为匹配部而输出匹配结果的结构。学习模型可以与各服务被提供者对应地进行构建，也可以在特定条件下进行分组，并针对每组而构建学习模型。

[变形例]

另外，在到目前为止说明的例子中，列举用户通过图5所示的事故报告进行输入从而进行匹配处理的方式为例进行了说明，但是不限于此。例如，服务辅助系统210可以在预定的时刻自动地读取数据，基于该读取的数据进行匹配处理。根据这样的处理，也能够在例如因身体变化等而发生意外等的情况下，输出警告。

列举看护机构的入住者为例进行说明。在看护机构的现场，谋求工作人员始终对入住者的状态变化和/或危险保持警惕，并进行适当的应对。但是，在工作人员以倒班制提供每日的护理服务的日常情况时，大多不会注意到入住者的状态变化和/或危险。这是因为，存在如果仅抽取一个方面，则不能直接确定为异常状态的情况。例如，像吃饭的摄入量和/或水分摄入量持续预定次数在一定量以下的情况、和/或一定时间没有排泄的情况，和/或体温、脉搏、血压、体重等生命指标在一定期间内为超过规定范围的值的情况等那样地，持续在连续与平常不同的状态的情况下，存在入住者的状态变化和/或发生危险的可能性。上述实施方式能够应用在这样的提醒注意的方式。

对于案例的种类而言，列举体重变化的情况为例进行说明。入住者的体重等数据存储在存储部313等中。因此，接收部314能够在预定的时刻访问存储于该存储部313等的数据，输入存储的数据作为发生状况。并且，将输入来的数据发送到匹配部316。由此，可以在预定时刻自动地进行匹配处理。

原因数据库460能够包含与时间序列的推移有关的项目的记录。例如，在将预定的基准日设为lv1的等级的值(体重)的情况下，lv2的等级的值可以收纳设为基准日的下一日的允许值(体重)的原因记录。并且，匹配部316利用将存储的体重的数据配置为时间序列的项目的输入记录，来进行匹配处理。在该处理的例子中，在lv2以下的等级，在与原因记录的项目(允许值(体重))不一致的情况下，能够使用增大得分的手法。也就是说，在lv2以下的等级的输入记录的项目与lv2以下的等级的原因记录的项目一致的情况(也就是说，是允许范围内的值的情况)下，结束匹配处理，在不一致的情况(也就是说，不是允许范围的值的情况)下，可以使用将得分相加的方式。如果进行这样的处理，将应注意身体变化的值包含于项目的原因记录(例如，对应于体重每日下降的原因记录)的得分变高，从匹配部316输出与该原因记录关联的原因(例如，因为有疾病的可能性，所以注意等)。输出部317也能够将如此从匹配部316输出的匹配结果发送到用户终端220，对用户发出警告。

如以上说明那样，根据本实施方式，基于在机构引起的各种事故的发生状况，导出引起事故的原因和/或应捕捉到的观点的候补，能够辅助事故的分析、应对·预防措施制定。另外，能够容易地追加、改变发生状况数据库450及原因数据库460的记录。因此，需要设定新项目等的情况等的维护容易。

另外，根据本实施方式，即使是没有高级的专业知识和/或经验值的工作人员，只要如实且准确地从选项中选择已发生的事故的状况，就能够将确保了一定水平以上的精度和完整性的、事故的原因和/或应捕捉到的观点的候补列表而显示。因此，能够削减各种专业书籍等资料的调查所花费的时间，并且能够基于列表的内容有效地实施与各相关部分的协作。

另外，根据本实施方式，能够防止疏忽机构的工作人员没有注意的真实的原因等。另外，能够从多方面的观点，给工作人员等利用者提示与事故的发生状况对应的原因、因素、危险因素及注意事项等。

以上说明的实施方式是用于容易理解本发明的内容，不是限定解释本发明的内容。实施方式所具备的各要素和其配置、材料、条件、形状及尺寸等不限于示例的内容，能够进行适当的变更。另外，能够局部置换或组合不同实施方式所示的结构彼此。

用于实现以上说明的本发明的各实施方式的程序可以存储于存储介质。如果利用该存储介质，则能够在机构中以其他用途已经使用的任意的计算机和/或新购入的计算机上装载上述程序。在此，存储上述程序的存储介质可以是非瞬时性的存储介质。虽然非瞬时性的存储介质没有特别限定，但是可以是例如cd-rom等存储介质。