CN109785164A - 一种意外险核责数据处理方法、服务器及计算机可读介质 - Google Patents

Abstract

本申请实施例公开了一种意外险核责数据处理方法、服务器及计算机可读介质，涉及对意外险核责数据的分析处理，其中方法包括：接收申请人终端发送的意外险理赔请求，所述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间；根据所述被保险人身份信息、保险事故的出险原因、所述保险事故的发生地点和所述保险事故的发生时间获取所述保险事故的核责信息；根据所述保险事故的核责信息和意外险核责规则确定所述意外险理赔请求对应的保险事故的保险责任。通过本申请实施例，可以有效的提升意外险理赔核责的工作效率，节省人力成本，统一核责标准，避免在核责过程中人为主观因素带来的偏差。

Description

一种意外险核责数据处理方法、服务器及计算机可读介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种意外险核责数据处理方法、服务器及计算机可读介质。

背景技术

在日常生活中，意外是不可预期的，意外会给人们的身体带来不同程度的伤害。为了弥补意外伤害带来的损失，人们都会选择给自己或家人购买一份意外保险。对于意外保险，用户和保险公司都比较关心的便是保险的理赔。在理赔过程中，比较重要的环节便是核责。

然而，在传统的意外保险理赔的核责过程中，一般都是由相应的理赔专员根据对应的保险理赔条款或规则进行人工处理的，处理程序复杂、效率低，而且不同的理赔专员对于理赔条款的理解不一致，可能造成理赔的标准不一致，难以避免人为主观因素给核责过程带来的偏差，给用户带来极大的不便。

发明内容

本申请实施例提供一种意外险核责数据处理方法，可有效的提升意外险理赔核责的工作效率，节省人力成本，统一核责标准，避免人为主观因素带来的偏差。

第一方面，本申请实施例提供了一种意外险核责数据处理方法，该方法包括：

接收申请人终端发送的意外险理赔请求，所述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间；

根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台，根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息；

根据所述保险事故的核责信息和意外险核责规则确定所述意外险理赔请求对应的保险事故的保险责任，所述意外险核责规则包以下规则中的至少一项：验证被保险人是否意外身故、验证被保险人是否遭受意外伤残、验证被保险人是否遭受一般意外伤害。

可选的，在所述接收申请人终端发送的意外险理赔请求之后，所述方法还包括：

根据所述保险事故的出险原因判断所述意外险理赔请求对应的保险事故是否为突发性的、非本意的且非疾病的事故；

若所述保险事故为突发性的、非本意的且非疾病事故，则确定所述意外险理赔请求对应的保险事故是属于意外事故，触发所述根据所述被保险人身份信息、所述保险事故的发生地点和所述保险事故的发生时间获取所述保险事故的核责信息的操作；

若判断所述意外险理赔请求对应的保险事故不属于意外事故，则向所述申请人终端发送反馈信息，所述反馈信息用于提示申请人所述意外险理赔请求对应的保险事故不属于意外事故。

可选的，所述根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台包括：

根据所述保险事故的原因判断所述保险事故的属性，所述保险事故的属性包括普通意外伤害、意外伤残、意外身故；

根据所述保险事故的发生地点和所述保险事故的属性确定所述获取所述核责信息的第三方平台；

所述根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息包括：

根据所述保险事故的属性和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息。

可选的，所述根据所述保险事故的属性和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息包括：

若所述保险事故的属性为普通意外伤害，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台获取第一核责信息，所述第一核责信息包括所述被保险人的普通意外伤害诊断书和病历；

若所述保险事故的属性为意外伤残，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台获取第二核责信息，所述第二核责信息包括所述被保险人的意外伤残诊断书和病历，以及从所述保险事故的发生地点所在的医疗机构平台或司法机构平台获取被保险人的伤残鉴定证明；

若所述保险事故的属性为意外身故，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台或司法机构平台获取第三核责信息，所述第三核责信息包括所述被保险人的死亡证明和死亡原因。

可选的，所述根据所述保险事故的核责信息和意外险核责规则确定所述保险事故的保险责任包括：

若所述保险事故的属性为普通意外伤害，则根据所述被保险人的普通意外伤害诊断书和病历验证所述被保险人是否遭受一般意外伤害，若是，则确定所述保险事故的保险责任为医疗保险责任；

若所述保险事故的属性为意外伤残，则根据所述意外伤残诊断书和所述病历以及所述伤残证明验证所述被保险人是否遭受意外伤残，若是，则确定所述保险事故的保险责任为伤残保险责任；

若所述保险事故的属性为意外身故，则根据所述死亡证明和所述死亡原因验证所述被保险人是否意外身故，若是，则确定所述保险事故的保险责任为身故保险责任。

可选的，在所述根据所述保险事故的核责信息和意外险核责规则确定所述保险事故的保险责任之后，所述方法还包括：

根据所述被保险人身份信息获取被保险人的投保信息，所述投保信息包括所述被保险人的投保险种以及每个投保险种对应的保险期限；

获取所述投保信息中每个意外险种对应的保险条款；

根据所述投保信息中每个意外险种对应的保险条款、所述保险事故的发生时间、所述保险事故的出险原因以及每个投保险种对应的保险期限确定承担所述保险事故的保险责任的所述第一相关险种，所述第一相关险种为所述投保信息中的一个或多个意外险险种。

可选的，所述根据所述相关险种中每个意外险种对应的保险条款、所述保险事故的发生时间、所述保险事故的出险原因以及每个投保险种对应的保险期限确定承担所述保险事故的保险责任的所述相关险种包括：

确定所述保险事故的发生时间在保险期限内的第二相关险种，所述第二相关险种为所述投保信息中的一个或多个意外险险种；

确定保险条款与所述保险事故的出险原因相匹配的第一相关险种，所述第一相关险种为所述第二相关险种中的一个或多个意外险险种。

第二方面，本申请实施例提供了一种服务器，该服务器包括：

接收单元，用于接收申请人终端发送的意外险理赔请求，所述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间；

第一获取单元，用于根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台，根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息；

处理单元，用于根据所述保险事故的核责信息和意外险核责规则确定所述意外险理赔请求对应的保险事故的保险责任，所述意外险核责规则包以下规则中的至少一项：验证被保险人是否意外身故、验证被保险人是否遭受意外伤残、验证被保险人是否遭受一般意外伤害。

可选的，所述服务器还包括：

判断单元，用于根据所述保险事故的出险原因判断所述意外险理赔请求对应的保险事故是否为突发性的、非本意的且非疾病的事故；

所述处理单元，用于在所述判断单元判断所述保险事故为突发性的、非本意的且非疾病的事故，则确定所述意外险理赔请求对应的保险事故是属于意外事故，根据所述被保险人身份信息、所述保险事故的发生地点和所述保险事故的发生时间获取所述保险事故的核责信息的操作；

反馈单元，用于在所述判断单元判断所述意外险理赔请求对应的保险事故不属于意外事故时，向所述申请人终端发送反馈信息，所述反馈信息用于提示申请人所述意外险理赔请求对应的保险事故不属于意外事故。

可选的，所述第一获取单元包括：

第二判断单元，用于根据所述保险事故的原因判断所述保险事故的属性，所述保险事故的属性包括普通意外伤害、意外伤残、意外身故；

第二确定单元，用于根据所述保险事故的发生地点和所述保险事故的属性确定所述获取所述核责信息的第三方平台；

所述第一获取单元，用于根据所述保险事故的属性和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息。

可选的，所述第一获取单元，用于若所述保险事故的属性为普通意外伤害，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台获取第一核责信息，所述第一核责信息包括所述被保险人的普通意外伤害诊断书和病历；若所述保险事故的属性为意外伤残，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台获取第二核责信息，所述第二核责信息包括所述被保险人的意外伤残诊断书和病历，以及从所述保险事故的发生地点所在的医疗机构平台或司法机构平台获取被保险人的伤残鉴定证明；若所述保险事故的属性为意外身故，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台或司法机构平台获取第三核责信息，所述第三核责信息包括所述被保险人的死亡证明和死亡原因。

可选的，所述处理单元，用于若所述保险事故的属性为普通意外伤害，则根据所述被保险人的普通意外伤害诊断书和病历验证所述被保险人是否遭受一般意外伤害，若是，则确定所述保险事故的保险责任为医疗保险责任；若所述保险事故的属性为意外伤残，则根据所述意外伤残诊断书和所述病历以及所述伤残证明验证所述被保险人是否遭受意外伤残，若是，则确定所述保险事故的保险责任为伤残保险责任；若所述保险事故的属性为意外身故，则根据所述死亡证明和所述死亡原因验证所述被保险人是否意外身故，若是，则确定所述保险事故的保险责任为身故保险责任。

可选的，所述服务器还包括：

第二获取单元，用于根据所述被保险人身份信息获取被保险人的投保信息，所述投保信息包括所述被保险人的投保险种以及每个投保险种对应的保险期限；

所述第二获取单元，用于获取所述投保信息中每个意外险种对应的保险条款；

第三确定单元，用于根据所述投保信息中每个意外险种对应的保险条款、所述保险事故的发生时间、所述保险事故的出险原因以及每个投保险种对应的保险期限确定承担所述保险事故的保险责任的所述第一相关险种，所述第一相关险种为所述投保信息中的一个或多个意外险险种。

可选的，所述第三确定单元，用于确定所述保险事故的发生时间在保险期限内的第二相关险种，所述第二相关险种为所述投保信息中的一个或多个意外险险种；确定保险条款与所述保险事故的出险原因相匹配的第一相关险种，所述第一相关险种为所述第二相关险种中的一个或多个意外险险种。

第三方面，本申请实施例提供了另一服务器，包括处理器、存储器和通信模块，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码来执行上述第一方面及其任一种可选方式的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行上述第一方面及其任一种可选方式的方法。

本申请实施例通过接收申请人发送的意外险理赔请求，然后在根据意外险理赔请求中的保险事故出险原因初步确定保险事故为意外事故后，根据上述意外险理赔请求中的被保险人身份信息、保险事故的出险原因、所述保险事故的发生地点和所述保险事故的发生时间获取保险事故的核责信息；接着根据所述保险事故的核责信息和意外险核责规则确定所述保险事故的保险责任；最后根据所述保险事故的保险责任来自动判断被保险人投保的保险险种中，哪些保险可以申请理赔，以避免用户在申请保险理赔时不能将所有可以申请理赔的险种都申请理赔。通过本申请实施例，可以有效的提升意外险理赔核责的工作效率，节省人力成本，统一核责标准，避免在核责过程中人为主观因素带来的偏差，且用户在理赔时不需要自己收集理赔时需要的核责信息，也不需要自己判断申请哪些险种的理赔。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种意外险核责数据处理方法的示意流程图；

图2是本申请实施例提供的另一种意外险核责数据处理方法的示意流程图；

图3是本申请实施例提供的一种服务器的示意框图；

图4是本申请实施例提供的一种设备示意框图；

图5是本申请实施例提供的一种服务器结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

意外保险是指投保人缴纳一定数额的保险费，保险人承诺于被保险人，在遭遇特定范围内的灾害事故，致身体受到伤害而造成残废或死亡时，给付保险金的行为或合同。

这里的身体是指被保险人的自然躯体，不包括假肢、假牙、假眼等人工安置的非天然部分。这里所指的造成被保险人意外伤害的灾害事故应具备外来的、突发的、非本意的和非疾病的四大要素。

意外伤害保险中所称意外伤害是指，在被保险人没有预见到或违背被保险人意愿的情况下，突然发生的外来致害物对被保险人的身体明显、剧烈地侵害的客观事实。这里所指的突然发生的外来致害物应具备外来的、突发的、非本意的和非疾病的四大要素。

所谓突发的，是指人体受到猛烈而突然的侵袭所形成的伤害。伤害的原因与结果之间具有直接瞬间的关系。如交通事故中的撞车、天空坠落物体的砸压等引起的伤害、死亡则是突发的，瞬间完成的。长期在某种环境条件下工作造成身体的伤害，不属于意外伤害，如长期在恶劣环境下工作造成的职业病，与突发偶然形成身体的伤害是有区别的，前者不属于伤害保险的范围。

所谓非本意的，是指非当事人所能预见，非本人意愿的不可抗力事故所致的伤害，对于伤害的结果是意外，而原因非意外的伤害不能认定为意外伤害，如在高速公路上以超过限速标准的速度驾驶导致的身体伤害。对于这种完全可以预料的，也是完全可以防止的伤害，不属于意外伤害。

所谓非疾病的，是指损害的造成不是由被保人身体本身的因素或疾病引起的。如骨质疏松导致的病理性骨折，或肝炎病毒引起的爆发性肝炎均为疾病所致的伤害。

参见图1，图1是本申请实施例提供的一种意外险核责数据处理方法的示意流程图，如图1所示，该方法可包括：

101：接收申请人发送的意外险理赔请求，上述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间。

在本申请实施例中，当上述被保险人发生意外险保险事故时(例如，意外身故、意外伤残等)，申请人(可以是被保险人本人或被保险人的家人或亲戚)通过有线或无线终端设备登录意外险理赔平台的网站或App等来向意外险理赔平台发起意外险理赔请求。当意外险理赔平台接收到上述意外险理赔请求之后，则上述意外险理赔平台根据上述意外险理赔请求中的保险事故的出险原因来判断该保险事故是否为突发性的、非本意的且非疾病的事故；若所述保险事故为突发性的、非本意的且非疾病的事故，则确定所述意外险理赔请求对应的保险事故是属于意外事故，触发执行步骤102，若所述保险事故不是突发性的、非本意的且非疾病的事故，则确定所述意外险理赔请求对应的保险事故不属于意外事故，则根据上述保险事故的出险原因生成反馈信息，然后向上述申请人终端发生该反馈信息，以便提示申请人该保险事故不属于意外事故，因此不能申请意外保险理赔。

例如，在申请人终端发送的意外险理赔请求中的保险事故的出险原因为“突发性心脏病死亡”，则在意外险理赔平台接收到意外险理赔请求之后，从上述意外险理赔请求中提取出保险事故的出险原因，并对其进行智能识别(例如语义识别)，判断出被保险人是由于疾病(心脏病)导致的身故，根据对意外事故的定义确定该保险事故不属于意外事故；然后生成反馈信息(包括反馈理由)，并将该反馈信息发送给申请人终端，例如该反馈信息可以是“您好，由于XXX是因为心脏病导致的死亡，属于疾病死亡的范畴，不属于意外事故，因此不能申请意外保险理赔，谢谢！”

102：根据上述被保险人身份信息、保险事故的出险原因、上述保险事故的发生地点和上述保险事故的发生时间获取上述保险事故的核责信息。

其中，上述核责信息为能够直接或间接的确定该保险事故为意外事故的信息，上述核责信息可以包括被保险人的普通意外医疗信息(例如被保险人的诊断书、病历等)、被保险人的意外伤残信息(例如，伤残证明等)、被保险人意外身故信息，以及一些能够确定保险事故为意外性质事故的信息(例如能确定该保险事故为突发的、非本意的以及非疾病的信息)等。

在本申请实施例中，在上述意外险理赔平台受理上述意外险理赔请求，并根据上述保险事故的出险原因初步判断出该保险事故属于意外事故之后，上述意外险理赔平台需要获取保险事故的核责信息，并对上述意外险核责信息进行验证，以便后续意外险理赔平台根据上述保险事故的核责信息对上述意外险保险事故进行核责处理。

具体的，上述根据上述被保险人身份信息、上述保险事故的发生地点和上述保险事故的发生时间获取上述保险事故的核责信息可以包括：根据上述保险事故的原因判断上述保险事故的属性，其中，上述保险事故的属性包括普通意外伤害、意外伤残、意外身故；然后，根据上述保险事故的发生地点和上述保险事故的属性确定上述获取上述核责信息的第三方平台；最后，根据上述保险事故的属性和上述保险事故的发生时间以及上述被保险人身份信息从上述第三方平台获取上述保险事故的核责信息。其中，上述第三方平台包括但不限于医疗机构平台、其他保险公司、行政服务平台、交通管理平台、企业管理平台、社保部门、司法机构平台等。

作为一种可选的实施方式，上述根据上述保险事故的属性和上述保险事故的发生时间以及上述被保险人身份信息从上述第三方平台获取上述保险事故的核责信息具体可以包括：若上述保险事故的属性为普通意外伤害，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台获取第一核责信息，上述第一核责信息包括上述被保险人的普通意外伤害诊断书和病历；若上述保险事故的属性为意外伤残，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台获取第二核责信息，上述第二核责信息包括上述被保险人的意外伤残诊断书和病历，以及从上述保险事故的发生地点所在的医疗机构平台或司法机构平台获取被保险人的伤残鉴定证明；若上述保险事故的属性为意外身故，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台或司法机构平台获取第三核责信息，上述第三核责信息包括上述被保险人的死亡证明和死亡原因。

例如，上述获取保险事故的核责信息可以包括：获取医务平台的查询权限，根据上述被保险人的身份信息从上述医务平台数据库中获取上述被保险人的病历、诊断、手术等信息。

103：根据上述保险事故的核责信息和意外险核责规则确定上述意外险理赔请求对应的保险事故的保险责任。

其中，上述意外险核责规则包以下规则中的至少一项：验证被保险人是否意外身故、验证被保险人是否遭受意外伤残、验证被保险人是否遭受一般意外伤害。可以理解的是，对于不同的意外险种具有不同的核责规则，因此，上述核责规则并不包括所有的责规则。

在本申请实施例中，当上述意外险理赔平台获取到上述保险事故的核责信息后，意外险理赔平台则根据上述保险事故的核责信息和上述意外险核责规则对上述保险丝事故进行核责处理。

具体的，若上述保险事故的属性为普通意外伤害，则根据上述被保险人的普通意外伤害诊断书和病历验证上述被保险人是否遭受一般意外伤害，若是，则确定上述保险事故的保险责任为医疗保险责任；若上述保险事故的属性为意外伤残，则根据上述意外伤残诊断书和上述病历以及上述伤残证明验证上述被保险人是否遭受意外伤残，若是，则确定上述保险事故的保险责任为伤残保险责任；若上述保险事故的属性为意外身故，则根据上述死亡证明和上述死亡原因验证上述被保险人是否意外身故，若是，则确定上述保险事故的保险责任为身故保险责任。

作为一种可选的实施方式，上述意外险理赔平台除了根据意外险理赔请求去获取核责信息之外，还可以根据上述意外险理赔请求获取责任免除信息。其中，在本申请实施例中，上述核责信息指在意外险保险事故中，能够确定或评估保险事故是否在保险责任范围内的信息，上述责任免除指在保险责任范围内，当满足责任免除条件时，保险人不负责承担给付保险金的责任；责任免除信息指能够评估或确定上述责任免除的信息。

具体的，若上述意外险理赔平台获取到上述责任免除信息，并对其进行验证无误之后，则上述意外险理赔平台确定保险人(即保险公司)不对上述保险事故承担保险责任。

例如，假设一种意外险需要承担的保险责任为：在保险期间内，若被保险人(被保险人)意外死亡，则保险人给付约定意外身故保险金，则上述责任认定死亡证明，死亡原因等信息。上述责任免除可以包括被保险人酒后驾车导致意外死亡时，或者被保险人因战争、军事冲突暴乱等原因造成的意外死亡时，保险人不负责承担给付保险金的责任。可以理解的是，上述例子只是作为本申请实施例的一个范例，并不对上述核责信息和责任免除信息进行限定，其具体限定可以参照具体的保险条款。

作为一种可选的实施方式，在上述意外险理赔平台述根据上述保险事故的核责信息和意外险核责规则确定上述保险事故的保险责任之后，根据上述被保险人身份信息获取被保险人的投保信息，其中，上述投保信息包括上述被保险人的投保险种以及每个投保险种对应的保险期限；然后，获取上述投保信息中每个意外险种对应的保险条款；最后，根据上述投保信息中每个意外险种对应的保险条款、上述保险事故的发生时间、上述保险事故的出险原因以及每个投保险种对应的保险期限上述确定承担上述保险事故的保险责任的上述第一相关险种，其中，上述第一相关险种为上述投保信息中的一个或多个意外险险种，即从被保险人投保的所有意外保险中确定其中哪些意外保险险种需要对上述保险事故承担上述保险事故的保险责任。

具体的，在上述意外险理赔平台获取到被保险人的投保信息以及投保信息中每个意外险险种对应的保险条款后，首先确定上述保险事故的发生时间在保险期限内的第二相关险种，其中，上述第二相关险种为上述投保信息中的一个或多个意外险险种；然后，确定保险条款与上述保险事故的出险原因相匹配的第一相关险种，上述第一相关险种为上述第二相关险种中的一个或多个意外险险种。

例如，上述意外险理赔平台根据获取到的核责信息和核责规则确定了保险事故的保险责任为意外伤残保险责任，出险的原因是“不小心跌落导致腿部残疾”，出险的时间为xxxx年nn月mm日。首先意外险理赔平台从数据库中获取被保险人的投保信息，投保信息中包括了综合意外险、交通意外险、和短期旅游意外险三种意外险险种；然后意外险理赔平台确定xxxx年nn月mm日在综合意外险和交通意外险的保险期限内；最后意外险理赔平台从上述综合意外险和交通意外险中根据出险原因“不小心跌落导致腿部残疾”确定其匹配的意外险险种为综合意外险，因此在该保险事故中上述综合意外险需要对上述保险事故承担意外伤残保险责任。

可以看出，本申请实施例通过接收申请人发送的意外险理赔请求，然后在根据意外险理赔请求中的保险事故出险原因初步确定保险事故为意外事故后，根据上述意外险理赔请求中的被保险人身份信息、保险事故的出险原因、所述保险事故的发生地点和所述保险事故的发生时间获取保险事故的核责信息；接着根据所述保险事故的核责信息和意外险核责规则确定所述保险事故的保险责任；最后根据所述保险事故的保险责任来自动判断被保险人投保的保险险种中，哪些保险可以申请理赔，以避免用户在申请保险理赔时不能将所有可以申请理赔的险种都申请理赔。通过本申请实施例，可以有效的提升意外险理赔核责的工作效率，节省人力成本，统一核责标准，避免在核责过程中人为主观因素带来的偏差，且用户在理赔时不需要自己收集理赔时需要的核责信息，也不需要自己判断申请哪些险种的理赔。

参见图2，图2是本申请实施例提供的另一种意外险核责数据处理方法的示意流程图，如图2所示，该方法可包括：

201：接收申请人发送的意外险理赔请求。

其中，上述意外险理赔请求包括被保险人身份信息、收益人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间。

202：根据上述保险事故的出险原因判断上述意外险理赔请求对应的保险事故是否属于意外事故。

在本申请实施例中，若判断上述意外险理赔请求对应的保险事故是属于意外事故，则执行步骤204，若判断上述意外险理赔请求对应的保险事故不属于意外事故，则执行步骤203。

203：向上述申请人终端发送反馈信息，上述反馈信息用于提示申请人上述保险事故不属于意外事故。

204：根据上述保险事故的原因判断上述保险事故的属性，上述保险事故的属性包括普通意外伤害、意外伤残、意外身故。

205：根据上述保险事故的发生地点和上述保险事故的属性确定上述获取上述核责信息的第三方平台。

206：根据上述保险事故的属性和上述保险事故的发生时间以及上述被保险人身份信息从上述第三方平台获取上述保险事故的核责信息。

具体的，若上述保险事故的属性为普通意外伤害，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台获取第一核责信息，上述第一核责信息包括上述被保险人的普通意外伤害诊断书和病历；若上述保险事故的属性为意外伤残，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台获取第二核责信息，上述第二核责信息包括上述被保险人的意外伤残诊断书和病历，以及从上述保险事故的发生地点所在的医疗机构平台或司法机构平台获取被保险人的伤残鉴定证明；若上述保险事故的属性为意外身故，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台或司法机构平台获取第三核责信息，上述第三核责信息包括上述被保险人的死亡证明和死亡原因。

207：根据上述保险事故的核责信息和意外险核责规则确定上述保险事故的保险责任。

具体的，若上述保险事故的属性为普通意外伤害，则根据上述被保险人的普通意外伤害诊断书和病历验证上述被保险人是否遭受一般意外伤害，若是，则确定上述保险事故的保险责任为医疗保险责任；若上述保险事故的属性为意外伤残，则根据上述意外伤残诊断书和上述病历以及上述伤残证明验证上述被保险人是否遭受意外伤残，若是，则确定上述保险事故的保险责任为伤残保险责任；若上述保险事故的属性为意外身故，则根据上述死亡证明和上述死亡原因验证上述被保险人是否意外身故，若是，则确定上述保险事故的保险责任为身故保险责任。

208：根据上述被保险人身份信息获取被保险人的投保信息，上述投保信息包括上述被保险人的投保险种以及每个投保险种对应的保险期限。

209：获取上述投保信息中每个意外险种对应的保险条款。

210：根据上述投保信息中每个意外险种对应的保险条款、上述保险事故的发生时间、上述保险事故的出险原因以及每个投保险种对应的保险期限上述确定承担上述保险事故的保险责任的上述第一相关险种，上述第一相关险种为上述投保信息中的一个或多个意外险险种。

可以看出，本申请实施例通过接收申请人发送的意外险理赔请求，然后在根据意外险理赔请求中的保险事故出险原因初步确定保险事故为意外事故后，根据上述意外险理赔请求中的被保险人身份信息、保险事故的出险原因、上述保险事故的发生地点和上述保险事故的发生时间从第三方平台获取保险事故的核责信息；最后根据上述保险事故的核责信息和意外险核责规则确定上述保险事故的保险责任最后根据所述保险事故的保险责任来自动判断被保险人投保的保险险种中，哪些保险可以申请理赔，以避免用户在申请保险理赔时不能将所有可以申请理赔的险种都申请理赔。通过本申请实施例，可以有效的提升意外险理赔核责的工作效率，节省人力成本，统一核责标准，避免在核责过程中人为主观因素带来的偏差，且用户在理赔时不需要自己收集理赔时需要的核责信息，也不需要自己判断申请哪些险种的理赔。

本申请实施例还提供一种服务器，该服务器用于执行前述任一项上述的方法的单元。具体地，参见图3，图3是本申请实施例提供的一种服务器的示意框图。本实施例的服务器包括：接收单元310、第一获取单元320以及处理单元330。

接收单元310，用于接收申请人终端发送的意外险理赔请求，上述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间；

第一获取单元320，用于根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台，根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息；

处理单元330，用于根据上述保险事故的核责信息和意外险核责规则确定上述意外险理赔请求对应的保险事故的保险责任，上述意外险核责规则包以下规则中的至少一项：验证被保险人是否意外身故、验证被保险人是否遭受意外伤残、验证被保险人是否遭受一般意外伤害。

可选的，上述服务器还包括：

判断单元340，用于根据上述保险事故的出险原因判断上述意外险理赔请求对应的保险事故是否为突发性的、非本意的且非疾病的事故；

上述处理单元330，用于在所述判断单元判断所述保险事故为突发性的、非本意的且非疾病的事故，则确定上述意外险理赔请求对应的保险事故是属于意外事故时，根据上述被保险人身份信息、上述保险事故的发生地点和上述保险事故的发生时间获取上述保险事故的核责信息的操作；

反馈单元350，用于在上述判断单元判断上述意外险理赔请求对应的保险事故不属于意外事故时，向上述申请人终端发送反馈信息，上述反馈信息用于提示申请人上述意外险理赔请求对应的保险事故不属于意外事故。

可选的，上述第一获取单元包括：

第二判断单元321，用于根据上述保险事故的原因判断上述保险事故的属性，上述保险事故的属性包括普通意外伤害、意外伤残、意外身故；

第二确定单元322，用于根据上述保险事故的发生地点和上述保险事故的属性确定上述获取上述核责信息的第三方平台；

上述第一获取单元320，用于根据上述保险事故的属性和上述保险事故的发生时间以及上述被保险人身份信息从上述第三方平台获取上述保险事故的核责信息。

可选的，上述第一获取单元320，用于若上述保险事故的属性为普通意外伤害，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台获取第一核责信息，上述第一核责信息包括上述被保险人的普通意外伤害诊断书和病历；若上述保险事故的属性为意外伤残，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台获取第二核责信息，上述第二核责信息包括上述被保险人的意外伤残诊断书和病历，以及从上述保险事故的发生地点所在的医疗机构平台或司法机构平台获取被保险人的伤残鉴定证明；若上述保险事故的属性为意外身故，则根据上述保险事故的发生时间和被保险人身份信息从上述保险事故的发生地点所在的医疗机构平台或司法机构平台获取第三核责信息，上述第三核责信息包括上述被保险人的死亡证明和死亡原因。

可选的，上述处理单元330，用于若上述保险事故的属性为普通意外伤害，则根据上述被保险人的普通意外伤害诊断书和病历验证上述被保险人是否遭受一般意外伤害，若是，则确定上述保险事故的保险责任为医疗保险责任；若上述保险事故的属性为意外伤残，则根据上述意外伤残诊断书和上述病历以及上述伤残证明验证上述被保险人是否遭受意外伤残，若是，则确定上述保险事故的保险责任为伤残保险责任；若上述保险事故的属性为意外身故，则根据上述死亡证明和上述死亡原因验证上述被保险人是否意外身故，若是，则确定上述保险事故的保险责任为身故保险责任。

可选的，上述服务器还包括：

第二获取单元360，用于根据上述被保险人身份信息获取被保险人的投保信息，上述投保信息包括上述被保险人的投保险种以及每个投保险种对应的保险期限；

上述第二获取单元360，用于获取上述投保信息中每个意外险种对应的保险条款；

第三确定单元370，用于根据上述投保信息中每个意外险种对应的保险条款、上述保险事故的发生时间、上述保险事故的出险原因以及每个投保险种对应的保险期限上述确定承担上述保险事故的保险责任的上述第一相关险种，上述第一相关险种为上述投保信息中的一个或多个意外险险种。

可选的，上述第三确定单元370，用于确定上述保险事故的发生时间在保险期限内的第二相关险种，上述第二相关险种为上述投保信息中的一个或多个意外险险种；确定保险条款与上述保险事故的出险原因相匹配的第一相关险种，上述第一相关险种为上述第二相关险种中的一个或多个意外险险种。

本申请实施例通过接收申请人发送的意外险理赔请求，然后在根据意外险理赔请求中的保险事故出险原因初步确定保险事故为意外事故后，根据上述意外险理赔请求中的被保险人身份信息、保险事故的出险原因、上述保险事故的发生地点和上述保险事故的发生时间从第三方平台获取保险事故的核责信息；最后根据上述保险事故的核责信息和意外险核责规则确定上述保险事故的保险责任最后根据所述保险事故的保险责任来自动判断被保险人投保的保险险种中，哪些保险可以申请理赔，以避免用户在申请保险理赔时不能将所有可以申请理赔的险种都申请理赔。通过本申请实施例，可以有效的提升意外险理赔核责的工作效率，节省人力成本，统一核责标准，避免在核责过程中人为主观因素带来的偏差，且用户在理赔时不需要自己收集理赔时需要的核责信息，也不需要自己判断申请哪些险种的理赔。

参见图4，图4是本申请实施例提供的一种设备，该设备可以为服务器，如图4所示设备包括：一个或多个处理器401；一个或多个输入设备402，一个或多个输出设备403和存储器404。上述处理器401、输入设备402、输出设备403和存储器404通过总线405连接。存储器402用于存储指令，处理器401用于执行存储器402存储的指令。

其中，该设备作为服务器使用的情况下，处理器401用于：接收申请人终端发送的意外险理赔请求，上述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间；根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台，根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息；根据上述保险事故的核责信息和意外险核责规则确定上述意外险理赔请求对应的保险事故的保险责任，上述意外险核责规则包以下规则中的至少一项：验证被保险人是否意外身故、验证被保险人是否遭受意外伤残、验证被保险人是否遭受一般意外伤害。

应当理解，在本申请实施例中，所称处理器401可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

输入设备402可以包括触控板、指纹采传感器(用于采集用户的指纹信息和指纹的方向信息)、麦克风等，输出设备403可以包括显示器(LCD等)、扬声器等。

该存储器404可以包括只读存储器和随机存取存储器，并向处理器401提供指令和数据。存储器404的一部分还可以包括非易失性随机存取存储器。例如，存储器404还可以存储设备类型的信息。

具体实现中，本申请实施例中所描述的处理器401、输入设备402、输出设备403可执行本申请实施例提供的一种意外险核责数据处理方法的第一实施例中所描述的实现方式、第二实施列以及第三实施例中的实现方式，也可执行本申请实施例所描述的服务器的实现方式，在此不再赘述。

在本申请的另一实施例中提供一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现：接收申请人终端发送的意外险理赔请求，上述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间；根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台，根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息；根据上述保险事故的核责信息和意外险核责规则确定上述意外险理赔请求对应的保险事故的保险责任，上述意外险核责规则包以下规则中的至少一项：验证被保险人是否意外身故、验证被保险人是否遭受意外伤残、验证被保险人是否遭受一般意外伤害。

上述计算机可读存储介质可以是前述任一实施例上述的终端的内部存储单元，例如终端的硬盘或内存。上述计算机可读存储介质也可以是上述终端的外部存储设备，例如上述终端上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(Flash Card)等。进一步地，上述计算机可读存储介质还可以既包括上述终端的内部存储单元也包括外部存储设备。上述计算机可读存储介质用于存储上述计算机程序以及上述终端所需的其他程序和数据。上述计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

图5是本申请实施例提供的一种服务器结构示意图，该服务器500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processingunits，CPU)522(例如，一个或一个以上处理器)和存储器532，一个或一个以上存储应用程序542或数据544的存储介质530(例如一个或一个以上海量存储设备)。其中，存储器532和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质530通信，在服务器500上执行存储介质530中的一系列指令操作。

服务器500还可以包括一个或一个以上电源526，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口558，和/或，一个或一个以上操作系统541，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由服务器所执行的步骤可以基于该图5所示的服务器结构。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、服务器、终端设备和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、服务器和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例上述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种意外险核责数据处理方法，其特征在于，包括：

接收申请人终端发送的意外险理赔请求，所述意外险理赔请求包括被保险人身份信息、保险事故的出险原因、保险事故的发生地点和保险事故的发生时间；

根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台，根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息；

根据所述保险事故的核责信息和意外险核责规则确定所述意外险理赔请求对应的保险事故的保险责任，所述意外险核责规则包以下规则中的至少一项：验证被保险人是否意外身故、验证被保险人是否遭受意外伤残、验证被保险人是否遭受一般意外伤害。

2.根据权利要求1所述的方法，其特征在于，在所述接收申请人终端发送的意外险理赔请求之后，所述方法还包括：

根据所述保险事故的出险原因判断所述意外险理赔请求对应的保险事故是否为突发性的、非本意的且非疾病的事故；

若所述保险事故为突发性的、非本意的且非疾病的事故，则确定所述意外险理赔请求对应的保险事故是属于意外事故，触发所述根据所述被保险人身份信息、所述保险事故的发生地点和所述保险事故的发生时间获取所述保险事故的核责信息的操作；

若判断所述意外险理赔请求对应的保险事故不属于意外事故，则向所述申请人终端发送反馈信息，所述反馈信息用于提示申请人所述意外险理赔请求对应的保险事故不属于意外事故。

3.根据权利要求2所述的方法，其特征在于，所述根据保险事故的出险原因和保险事故的发生地点判断获取核责信息的第三方平台包括：

根据所述保险事故的原因判断所述保险事故的属性，所述保险事故的属性包括普通意外伤害、意外伤残、意外身故；

根据所述保险事故的发生地点和所述保险事故的属性确定所述获取所述核责信息的第三方平台；

所述根据所述保险事故的出险原因和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息包括：

根据所述保险事故的属性和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息。

4.根据权利要求3所述的方法，其特征在于，所述根据所述保险事故的属性和所述保险事故的发生时间以及所述被保险人身份信息从所述第三方平台获取所述保险事故的核责信息包括：

若所述保险事故的属性为普通意外伤害，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台获取第一核责信息，所述第一核责信息包括所述被保险人的普通意外伤害诊断书和病历；

若所述保险事故的属性为意外伤残，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台获取第二核责信息，所述第二核责信息包括所述被保险人的意外伤残诊断书和病历，以及从所述保险事故的发生地点所在的医疗机构平台或司法机构平台获取被保险人的伤残鉴定证明；

若所述保险事故的属性为意外身故，则根据所述保险事故的发生时间和被保险人身份信息从所述保险事故的发生地点所在的医疗机构平台或司法机构平台获取第三核责信息，所述第三核责信息包括所述被保险人的死亡证明和死亡原因。

5.根据权利要求4所述的方法，其特征在于，所述根据所述保险事故的核责信息和意外险核责规则确定所述保险事故的保险责任包括：

若所述保险事故的属性为普通意外伤害，则根据所述被保险人的普通意外伤害诊断书和病历验证所述被保险人是否遭受一般意外伤害，若是，则确定所述保险事故的保险责任为医疗保险责任；

若所述保险事故的属性为意外伤残，则根据所述意外伤残诊断书和所述病历以及所述伤残证明验证所述被保险人是否遭受意外伤残，若是，则确定所述保险事故的保险责任为伤残保险责任；

若所述保险事故的属性为意外身故，则根据所述死亡证明和所述死亡原因验证所述被保险人是否意外身故，若是，则确定所述保险事故的保险责任为身故保险责任。

6.根据权利要求1-5任一项所述的方法，其特征在于，在所述根据所述保险事故的核责信息和意外险核责规则确定所述保险事故的保险责任之后，所述方法还包括：

根据所述被保险人身份信息获取被保险人的投保信息，所述投保信息包括所述被保险人的投保险种以及每个投保险种对应的保险期限；

获取所述投保信息中每个意外险种对应的保险条款；

根据所述投保信息中每个意外险种对应的保险条款、所述保险事故的发生时间、所述保险事故的出险原因以及每个投保险种对应的保险期限确定承担所述保险事故的保险责任的所述第一相关险种，所述第一相关险种为所述投保信息中的一个或多个意外险险种。

7.根据权利要求1-5任一项所述的方法，其特征在于，所述根据所述投保信息中每个意外险种对应的保险条款、所述保险事故的发生时间、所述保险事故的出险原因以及每个投保险种对应的保险期限确定承担所述保险事故的保险责任的所述相关险种包括：

确定所述保险事故的发生时间在保险期限内的第二相关险种，所述第二相关险种为所述投保信息中的一个或多个意外险险种；

确定保险条款与所述保险事故的出险原因相匹配的第一相关险种，所述第一相关险种为所述第二相关险种中的一个或多个意外险险种。

8.一种服务器，其特征在于，包括用于执行如权利要求1-7任一权利要求所述的方法的单元。

9.一种服务器，其特征在于，所述服务器包括处理器、存储器和通信模块，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码来执行如权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1-7任一项所述的方法。