核赔依据的生成方法及装置与流程

本发明属于计算机技术领域，尤其涉及一种核赔依据的生成方法及装置。

背景技术：

在对投保者的理赔申请进行赔付操作时，现有技术主要通过理赔审核人员手动录入理赔申请的核赔依据。在这里，核赔依据是指保险公司对于客户的理赔申请进行审核后得出相关赔付结论的事实依据，其中赔付结论包括正常给付、非正常给付-兼拒付/解约类、非正常给付-协议类、非正常给付-通融类、拒付等。然而，大多数的理赔申请为正常给付案件，核赔依据的内容大同小异，因此，理赔审核人员在录入核赔依据时存在工作重复、工作效率低的问题，且录入的过程繁琐，容易导致不规范操作，导致了较高的人力成本。

技术实现要素：

鉴于此，本发明实施例提供了一种核赔依据的生成方法及装置，以实现自动生成核赔依据，降低理赔审核人员的工作量，提高工作效率。

第一方面，提供了一种核赔依据的生成方法，所述生成方法包括：

当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件；

校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据；

若是时，生成所述理赔申请事件对应的赔付依据。

进一步地，所述校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据包括：

判断所述理赔申请事件的赔付结论是否为正常给付；

若为正常给付时，获取所述理赔申请事件对应的投保者的投保信息；

校验所述投保信息是否满足预设的多个校验项，以确定是否可自动生成所述理赔申请事件对应的核赔依据。

进一步地，所述校验所述投保信息是否满足预设的多个校验项，以确定是否可自动生成所述理赔申请事件对应的核赔依据包括：

判断所述投保信息中的赔付结论是否为正常给付、申请原因是否为疾病医疗或者意外医疗、无核保结论是否为非标体通过、所述理赔申请事件是否为非外币险、所述理赔申请事件是否无勘察记录、所述理赔申请事件是否无新增附约、所述理赔申请事件是否无保全复效。

进一步地，所述生成所述理赔申请事件对应的赔付依据包括：

获取所述投保者的事故时间、疾病名称、医院名称以及投保产品名称；

将所述事故时间、疾病名称、医院名称以及投保产品名称载入预设的核赔模板，以生成核赔依据；

显示所述核赔依据，以提示理赔审核人员对所述核赔依据进行修改、确认，并在所述理赔审核人员确认之后将所述核赔依据保存至oracle数据库中。

进一步地，所述生成方法还包括：

若所述投保信息不满足所述校验项中的任意一项或者多项时，确定不可自动生成所述理赔申请事件对应的核赔依据；

输出审核结果，并跳转至人工录入界面，以提示理赔审核人员手动录入核赔依据。

第二方面，提供了一种核赔依据的生成装置，所述生成装置包括：

获取模块，用于当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件；

校验模块，用于校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据；

生成模块，用于在校验模块的校验结果为是时，生成所述理赔申请事件对应的赔付依据。

进一步地，所述校验模块还包括：

判断单元，用于判断所述理赔申请事件的赔付结论是否为正常给付；

第一获取单元，用于若为正常给付时，获取所述理赔申请事件对应的投保者的投保信息；

校验单元，用于校验所述投保信息是否满足预设的多个校验项，以确定是否可自动生成所述理赔申请事件对应的核赔依据。

进一步地，所述校验单元具体用于：

判断所述投保信息中的赔付结论是否为正常给付、申请原因是否为疾病医疗或者意外医疗、无核保结论是否为非标体通过、所述理赔申请事件是否为非外币险、所述理赔申请事件是否无勘察记录、所述理赔申请事件是否无新增附约、所述理赔申请事件是否无保全复效。

进一步地，所述生成模块还包括：

第二获取单元，用于获取所述投保者的事故时间、疾病名称、医院名称以及投保产品名称；

生成单元，用于将所述事故时间、疾病名称、医院名称以及投保产品名称载入预设的核赔模板，以生成核赔依据；

显示及存储单元，用于显示所述核赔依据，以提示理赔审核人员对所述核赔依据进行修改、确认，并在所述理赔审核人员确认之后将所述核赔依据保存至oracle数据库中。

进一步地，所述生成装置还包括；

录入模块，用于若所述投保信息不满足所述校验项中的任意一项或者多项时，确定不可自动生成所述理赔申请事件对应的核赔依据；输出审核结果，并跳转至人工录入界面，以提示理赔审核人员手动录入核赔依据。

与现有技术相比，本发明实施例通过设置对理赔申请事件的校验过程，当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件；然后校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据；若是时，则生成所述理赔申请事件对应的赔付依据；从而实现了在理赔申请发生时自动生成对应的核赔依据，有效地简化了理赔审核人员的工作量，提高了工作效率，且避免了人工录入中的不规范操作，进一步规范了核赔依据的生成过程。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。

图1是本发明第一实施例提供的核赔依据的生成方法的实现流程图；

图2是本发明第一实施例提供的核赔依据的生成方法中步骤s102的具体实现流程图；

图3是本发明第一实施例提供的核赔依据的生成方法中步骤s103的具体实现流程图；

图4是本发明第二实施例提供的核赔依据的生成方法的实现流程图；

图5是本发明第三实施例提供的核赔依据的生成装置的组成结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例通过设置对理赔申请事件的校验过程，当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件；然后校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据；若是时，则生成所述理赔申请事件对应的赔付依据；从而实现了在理赔申请发生时自动生成对应的核赔依据，有效地简化了理赔审核人员的工作量，提高了工作效率，且避免了人工录入中的不规范操作，进一步规范了核赔依据的生成过程。本发明实施例还提供了相应的核赔依据的生成装置，以下分别进行详细的说明。

图1是本发明第一实施例提供的核赔依据的生成方法的实现流程。

在本发明实施例中，所述核赔依据的生成方法应用于终端设备上，所述终端设备包括但不限于计算机、服务器等。参阅图1，所述核赔依据的生成方法包括：

在步骤s101中，当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件。

在本发明实施例中，可以从以下三个方面触发核赔依据生成请求：1、通过客户端终端上的app触发自主申请理赔功能，比如平安金管家app；2、通过平安寿险门店柜员机柜面触发理赔申请；3、通过保险业务员终端的app触发理赔申请，比如口袋eapp。在这里，客户端终端、柜员机以及业务员终端可以通过有线或者无线的方式与所述终端设备连接通信。在核赔依据生成请求触发之后，所述客户端终端、柜员机以及业务员终端再将所述核赔依据生成请求发送至所述终端设备，终端设备则按照与所述客户端终端、柜员机以及业务员终端对应的方式获取待处理的理赔申请事件。其中，如果是通过app提起理赔申请，则理赔申请事件对应的申请材料通过终端拍照的方式上传获得；如果是通过柜员机柜面提起理赔申请，则理赔申请事件对应的申请材料通过柜员机扫描的方式获得。保险业务员将所述申请材料中的身份证信息、医疗诊治资料等录入成文本信息，并保存到核心oracle数据库中。

在步骤s102中，校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据。

在这里，本发明实施例可以对指定的理赔申请事件自动生成核赔依据，并且预先建立了该指定的理赔申请事件对应的校验项。然后结合所述理赔申请事件的赔付结论、投保者的投保信息，来确定所述理赔申请事件是否为该指定的理赔申请事件，进而确定是否可自动生成所述理赔申请事件对应的核赔依据。

由于统计得到理赔审核人员手动录入理赔申请的核赔依据时，大多数的理赔申请为正常给付案件。因此，这里以正常给付案件为实例对步骤s102中的校验过程进行说明。图2示出了本发明第一实施例提供的核赔依据的生成方法中步骤s102的具体实现流程。

参阅图2，所述步骤s102包括：

在步骤s1021中，判断所述理赔申请事件的赔付结论是否为正常给付。

在这里，如前所述，保险业务员将所述申请材料中的身份证信息、医疗诊治资料等录入成文本信息，并保存到核心oracle数据库中，然后理赔审核人员借助上述文本信息，判断所述理赔申请事件是否正常给付，若是，则设置所述理赔申请事件的赔付结论为正常给付。终端设备根据所述理赔审核人员的设置操作获得所述理赔申请事件对应的赔付结论，并判断是否为正常给付。

在步骤s1022中，若为正常给付时，获取所述理赔申请事件对应的投保者的投保信息。

在这里，所述投保者的投保信息包括但不限于投保者最初提供的投保信息，还包括保全变更信息。

在步骤s1023中，校验所述投保信息是否满足预设的多个校验项，以确定是否可自动生成所述理赔申请事件对应的核赔依据。

可选地，在本发明实施例中，所述校验项为是否可自动生成所述理赔申请事件对应的核赔依据的判断标准。终端设备依据该校验项来校验投保信息，进而确定是否执行核赔依据生成操作。

作为本发明的一个优选实例，对于上述赔付结论为正常给付的理赔申请事件，若终端设备能够自动生成核赔依据，则所述理赔申请事件对应的投保者的投保信息满足：赔付结论为正常给付、申请原因为疾病医疗或意外医疗、无核保结论为非标体通过、非外币险、无勘察记录、无协谈记录、无新增附约、无保全复效。则所述步骤s1023具体可以包括：

判断所述投保信息中的赔付结论是否为正常给付、申请原因是否为疾病医疗或者意外医疗、无核保结论是否为非标体通过、所述理赔申请事件是否为非外币险、所述理赔申请事件是否无勘察记录、所述理赔申请事件是否无新增附约、所述理赔申请事件是否无保全复效。

若所述投保信息均满足以上校验项时，确定可自动生成所述理赔申请事件对应的核赔依据。

通过上述步骤s1021至s1023，筛选出可自动生成核赔依据的指定的理赔申请事件，保证了终端设备自动生成的核赔依据的准确性。

在可自动生成所述理赔申请事件对应的核赔依据时，则执行步骤s103。

在步骤s103中，生成所述理赔申请事件对应的赔付依据。

本发明实施例预先设置了核赔依据模板，在确定当前的理赔申请事件可自动生成核赔依据后，则调用所述核赔依据模板生成所述理赔申请事件对应的核赔依据。

作为本发明的一个优选实例，图3示出了本发明第一实施例提供的核赔依据的生成方法中步骤s103的具体实现流程。

参阅图3，所述步骤s103包括：

在步骤s1031中，获取所述投保者的事故时间、疾病名称、医院名称以及投保产品名称。

在步骤s1032中，将所述事故时间、疾病名称、医院名称以及投保产品名称载入预设的核赔模板，以生成核赔依据。

可选地，所述核赔依据模板可以为：

事故者于何年何月何日因xx1在xx2治疗,经核实材料事故属实,属保险责任,按《xx3》条款给付保险金，……。

其中，xx1表示疾病名称，xx2表示医院名称，xx3表示投保产品名称。

需要说明的是，上述表述方式仅为本发明实施例提供的核赔依据模板的优选示例，并不用于限制本发明。在其他一些实施例中，也可以通过其他方式来表述。

在步骤s1033中，显示所述核赔依据，以提示理赔审核人员对所述核赔依据进行修改、确认，并在所述理赔审核人员确认之后将所述核赔依据保存至oracle数据库中。

在通过步骤s1032生成核赔依据之后，则输出所述核赔依据，比如通过在终端设备的显示屏上显示所述核赔依据，以使得理赔审核人员可以对所述核赔依据进行修改、确认。在理赔审核人员对所述核赔依据确认之后，则将所述核赔依据保存至oracle数据库中；从而有效地简化了理赔审核人员的工作量，提高了工作效率，且避免了人工录入中的不规范操作。

如前实施例所述，当理赔申请事件对应的投保者的投保信息满足上述的校验项时，则确定终端设备可自动生成所述理赔申请事件对应的核赔依据；当不满足任意一项或者多项校验项时，则终端设备无法生成所述理赔申请事件对应的核赔依据。在图2实施例的基础上，图4示出了本发明第二实施例提供的核赔依据的生成方法的实现流程。

所述核赔依据的生成方法还包括：

在步骤s104中，若所述投保信息不满足所述校验项中的任意一项或者多项时，确定不可自动生成所述理赔申请事件对应的核赔依据。

示例性地，所述投保信息不满足所述校验项中的任意一项或者多项，具体为所述投保信息不满足以下中的一项或者多项：赔付结论为正常给付、申请原因为疾病医疗或意外医疗、无核保结论为非标体通过、非外币险、无勘察记录、无协谈记录、无新增附约、无保全复效。此时，确定终端设备不可自动生成所述理赔申请事件的核赔依据

在步骤s105中，输出审核结果，并跳转至人工录入界面，以提示理赔审核人员手动录入核赔依据。

在这里，本发明实施例通过设置跳转步骤，保留了人工录入核赔依据的功能；对于终端设备不可自动生成核赔依据的理赔申请事件，则输出校验结果，并自动跳转至人工录入界面，以进一步方便理赔审核人员手动录入核赔依据。

本发明实施例通过设置对理赔申请事件的校验过程，当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件；然后校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据；若是时，则生成所述理赔申请事件对应的赔付依据；从而实现了在理赔申请发生时自动生成对应的核赔依据，有效地简化了理赔审核人员的工作量，提高了工作效率，且避免了人工录入中的不规范操作，进一步规范了核赔依据的生成过程。

应理解，在上述实施例中，各步骤的序号的大小并不意味着执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

图5示出了本发明第三实施例提供的核赔依据的生成装置的组成结构，为了便于说明，仅示出了与本发明实施例相关的部分。

在本发明实施例中，所述核赔依据的生成装置用于实现上述图1至图4任一实施例中所述的核赔依据的生成方法，可以是内置于终端设备的软件单元、硬件单元或者软硬件结合的单元。所述终端设备包括但不限于计算机、服务器等。

参阅图5，所述核赔依据的生成装置包括：

获取模块51，用于当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件；

校验模块52，用于校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据；

生成模块53，用于在校验模块的校验结果为是时，生成所述理赔申请事件对应的赔付依据。

在本发明实施例中，可以从以下三个方面触发核赔依据生成请求：1、通过客户端终端上的app触发自主申请理赔功能，比如平安金管家；2、通过平安寿险门店柜员机柜面触发理赔申请；3、通过保险业务员终端的app触发理赔申请，比如口袋eapp。在这里，客户端终端、柜员机以及业务员终端可以通过有线或者无线的方式与所述终端设备连接通信。在核赔依据生成请求触发之后，所述客户端终端、柜员机以及业务员终端再将所述核赔依据生成请求发送至所述终端设备的获取模块51，获取模块51则按照与所述客户端终端、柜员机以及业务员终端对应的方式获取待处理的里理赔申请事件。其中，如果是通过app提起理赔申请的，则理赔申请事件对应的申请材料通过终端拍照的方式上传获得；如果是通过柜员机柜面提起理赔申请的，则理赔申请事件对应的申请材料通过柜员机扫描的方式获得。然后由保险业务员将所述申请材料中的身份证信息、医疗诊治资料等录入层文本信息，并保存到核心oracle数据库中。

可选地，由于统计得到理赔审核人员手动录入理赔申请的核赔依据时，大多数的理赔申请为正常给付案件。因此，这里以正常给付案件为例进行说明。所述校验模块52还可以包括：

判断单元521，用于判断所述理赔申请事件的赔付结论是否为正常给付；

第一获取单元522，用于若为正常给付时，获取所述理赔申请事件对应的投保者的投保信息；

校验单元523，用于校验所述投保信息是否满足预设的多个校验项，以确定是否可自动生成所述理赔申请事件对应的核赔依据。

进一步地，所述校验单元523具体用于：

判断所述投保信息中的赔付结论是否为正常给付、申请原因是否为疾病医疗或者意外医疗、无核保结论是否为非标体通过、所述理赔申请事件是否为非外币险、所述理赔申请事件是否无勘察记录、所述理赔申请事件是否无新增附约、所述理赔申请事件是否无保全复效。

若所述投保信息均满足以上校验项时，确定可自动生成所述理赔申请事件对应的核赔依据。

可选地，本发明实施例预先设置了核赔依据模板，在确定当前的理赔申请事件可自动生成核赔依据后，则调用所述核赔依据模板生成所述理赔申请事件对应的核赔依据。所述生成模块53还包括：

第二获取单元531，用于获取所述投保者的事故时间、疾病名称、医院名称以及投保产品名称；

生成单元532，用于将所述事故时间、疾病名称、医院名称以及投保产品名称载入预设的核赔模板，以生成核赔依据；

显示及存储单元533，用于显示所述核赔依据，以提示理赔审核人员对所述核赔依据进行修改、确认，并在所述理赔审核人员确认之后将所述核赔依据保存至oracle数据库中。

示例性地，所述核赔依据模板可以为：

事故者于何年何月何日因xx1在xx2治疗,经核实材料事故属实,属保险责任,按《xx3》条款给付保险金，……。

其中，xx1表示疾病名称，xx2表示医院名称，xx3表示投保产品名称。

需要说明的是，上述表述方式仅为本发明实施例提供的核赔依据模板的优选示例，并不用于限制本发明。在其他一些实施例中，也可以通过其他方式来表述。

进一步地，所述生成装置还包括；

录入模块54，用于若所述投保信息不满足所述校验项中的任意一项或者多项时，确定不可自动生成所述理赔申请事件对应的核赔依据；输出审核结果，并跳转至人工录入界面，以提示理赔审核人员手动录入核赔依据。

在这里，本发明实施例通过设置跳转步骤，保留了人工录入核赔依据的功能；对于终端设备不可自动生成核赔依据的理赔申请事件，则由录入模块54输出校验结果，并自动跳转至人工录入界面，以进一步方便理赔审核人员手动录入核赔依据。

综上所述，本发明实施例通过设置对理赔申请事件的校验过程，当接收到核赔依据生成请求时，按照预设方式获取待处理的理赔申请事件；然后校验所述理赔申请事件的赔付结论、投保者的投保信息，以确定是否可自动生成所述理赔申请事件对应的核赔依据；若是时，则生成所述理赔申请事件对应的赔付依据；从而实现了在理赔申请发生时自动生成对应的核赔依据，有效地简化了理赔审核人员的工作量，提高了工作效率，且避免了人工录入中的不规范操作，进一步规范了核赔依据的生成过程。

需要说明的是，本发明实施例中的装置可以用于实现上述方法实施例中的全部技术方案，其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实例中的相关描述，此处不再赘述。

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

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

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

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

另外，在本发明各个实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元、模块单独物理存在，也可以两个或两个以上单元、模块集成在一个单元中。

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

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