CN113888129A - 理赔审核的配置方法、装置及后台服务器 - Google Patents

Abstract

本申请提出一种理赔审核的配置方法、装置及后台服务器，该方法包括：根据用户发起的理赔请求，生成理赔任务；获取理赔任务对应的理赔流程，理赔流程包括按照预设的网关流转规则组成的多个流程节点；对理赔流程中包括的至少一个流程节点配置业务审核功能；检测到第一流程节点的业务审核功能被触发，根据第一流程节点、理赔流程和理赔任务进行理赔计算得到第一流程节点的第一运算结果；第一流程节点为至少一个流程节点中的任意一个，可以针对不同的客户，不同的场景，不同的业务，不同的TPA，不同的保司定制化理赔流程。

Description

理赔审核的配置方法、装置及后台服务器

技术领域

本申请涉及一种保险业务数据计算技术领域，尤其涉及一种理赔审核的配置方法、装置及后台服务器。

背景技术

现有技术中的保险业务数据的理赔审核方法中，大多采用硬编码的方式，每一种业务类型的理赔流程都需要对应设置对应的业务逻辑算法，使得理赔流程固定化，理赔流程中的所有业务审核环节都需要人工参与，并且，当理赔审核流程需要改变时，需要修改理赔流程中所有的相关业务逻辑算法的代码，系统的维护成本高，扩展性低。

发明内容

本申请实施例提供一种理赔审核的配置方法、装置及后台服务器，以解决相关技术存在的问题，技术方案如下：

第一方面，本申请实施例提供了一种理赔审核的配置方法，包括：根据用户发起的理赔请求，生成理赔任务；获取理赔任务对应的理赔流程，理赔流程包括按照预设的网关流转规则组成的多个流程节点；对理赔流程中包括的至少一个流程节点配置业务审核功能；检测到第一流程节点的业务审核功能被触发，根据第一流程节点、理赔流程和理赔任务进行理赔计算得到第一流程节点的第一运算结果；第一流程节点为至少一个流程节点中的任意一个。

第二方面，本申请实施例提供了一种理赔审核的配置装置，包括：生成模块，用于根据用户发起的理赔请求，生成理赔任务；获取模块，用于获取理赔任务对应的理赔流程，理赔流程包括按照预设的网关流转规则组成的多个流程节点；配置模块，用于对理赔流程中包括的至少一个流程节点配置业务审核功能；计算模块，用于检测到第一流程节点的业务审核功能被触发，根据第一流程节点、理赔流程和理赔任务进行理赔计算得到第一流程节点的第一运算结果；第一流程节点为至少一个流程节点中的任意一个。

第三方面，本申请实施例提供了一种后台服务器，该后台服务器包括：存储器和处理器。其中，该该存储器和该处理器通过内部连接通路互相通信，该存储器用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，使得该处理器执行上述各方面任一种实施方式中的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储计算机程序，当计算机程序在计算机上运行时，上述各方面任一种实施方式中的方法被执行。

上述技术方案中的优点或有益效果至少包括：可以针对不同的客户，不同的场景，不同的业务，不同的TPA，不同的保司定制化理赔流程。

上述概述仅仅是为了说明书的目的，并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外，通过参考附图和以下的详细描述，本申请进一步的方面、实施方式和特征将会是容易明白的。

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请公开的一些实施方式，而不应将其视为是对本申请范围的限制。

图1为本申请示例性实施例的可配置化理赔流程的整体架构设计图；

图2为本申请示例性实施例的理赔审核的配置方法的流程图；

图3A～图3C为本申请示例性实施例的理赔流程的逻辑设计示意图；

图4为本申请示例性实施例的理赔审核的配置装置的结构框图；

图5为申请示例性实施例的用于实现理赔审核的配置方法的后台服务器的结构图；

具体实施方式

在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的精神或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的而非限制性的。

下面对本申请实施例涉及的专业术语进行解释。

Flowable工作流引擎：Flowable是一个流行的轻量级的采用Java开发的业务流程引擎。Flowable工作流引擎，通过流程定义创建流程实例，查询和访问流程相关的实例与数据等。

TPA：是医疗保险第三方管理公司(Third Party Administrator for GroupMedical Insurance，TPA)的简称。其业务包括提供新契约与保全服务、处理理赔、提供客户服务、提供医疗服务机构网络、安排医疗费用结算服务等。

元数据：描述数据的数据，对理赔业务实体进行了全面的数据描述，可以明确字段的变化，字段的特性，更方便快捷的使用该数据。

计算服务：约定一些元数据表达式的配置方式，然后按照一定的规则解析该表达式已得到相应的结果。

请参阅图1所示，图1是本申请实施例提供的可配置化理赔流程的整体架构设计图。

该整体框架中涉及的各个服务包括：数据服务、消息服务、日志服务和BI报表分析服务，其中：

数据服务：依托于元数据，封装了数据库增删改查API，并搭建了数据仓，数据湖，以支持BI报表服务，AI机器学习，大数据行为分析等。

消息服务：封装了微信推送、短信、邮件、钉钉等等各种消息通知API。

日志服务：依托于kibana实现数据可视化，数据探索，跟踪系统请求负载，对查询定位理赔流程中的各种问题都非常便捷。

BI报表分析服务：对理赔时效、理赔正确率、员工审核工作量、客户理赔率等等一系列理赔流程中关注的问题提供了服务支持以及可视化的操作页面。

由于Flowable本身提供了流程图画布，可以灵活变更流程节点、流程流向、网关以及各种事件定义，为了实现理赔流程的可配置化功能，需要将Flowable工作流引擎接入理赔业务系统，具体可以通过以下过程实现：

1.梳理出来理赔流程中所有的业务审核行为，具体包括：通过，拒绝，重新指派人员，申请领导复核，回退，撤案等，对应flowable提供的通过，拒签，会签，加签，回退，撤销等能力来支持。

2.由于要实现理赔审核的灵活配置，实现针对不同业务场景的可定制化，配置多种多样的网关流转条件，所以在Flowable提供的能力基础上再做一层业务封装，先梳理出理赔审核业务的全量流程节点包括：报案、TPA对接、初审、复核、理算、初审+理算、延迟受理-补录、延迟受理-收单、保司直付交接、打款审批、财务打款、结案，然后针对各个流程节点在业务进行各种审核操作时，配置流程节点变更的所有的网关条件，这样在理赔流程中配置了相应的网关条件组合，就可以实现业务的不同审核操作，对应各种不同的流程行为，可针对不同的客户，不同的保司，走不同的理赔流程，走到同一流程节点，触发不同的业务审核事件，以应对客户的定制化需求。

3.每个流程节点的处理人员可通过Flowable提供的基础能力，固定配置，也可通过业务封装分配人员事件，实现符合公司业务处理流程的定制化分配人员功能。

4.TPA节点可通过Spring Cloud开源的nacos配置中心，实现任意切换TPA来源。

5.保司直付交接节点可延伸第二条可配置化的保司交接子流程，实现针对不同的保司，有不同的处理方式，方便业务人员处理。

本申请的可配置化理赔流程的整体架构相比现有技术，具有以下有益效果：1、可以非常清晰的定制理赔流程，例如，可以针对不同的客户，不同的场景，不同的业务，不同的TPA，不同的保司定制化理赔流程；2、可以监控理赔流程中的各种数据，并对其进行业务分析，生成可视化报表；3、利用机器学习和大数据能力对用户行为分析，提供针对用户个人习惯的定制化服务；4、业务框架成熟，对于小额案件，可以实现从报案到结案的全自动化理赔流程，无需业务人员介入。

基于图1所示的可配置化理赔流程的整体架构，图2示出根据本申请一实施例的理赔审核的配置方法的流程图。如图2所示，该理赔审核的配置方法可以包括：

步骤S201：根据用户发起的理赔请求，生成理赔任务。

步骤S202：获取理赔任务对应的理赔流程，该理赔流程包括按照预设的网关流转规则组成的多个流程节点。

步骤S203：对理赔流程中包括的至少一个流程节点配置业务审核功能。

步骤S204：检测到第一流程节点的业务审核功能被触发，根据第一流程节点、理赔流程和理赔任务进行理赔计算得到第一流程节点的第一运算结果；该第一流程节点为该至少一个流程节点中的任意一个。

在一种可能的实施方式中，步骤S201中根据用户发起的理赔请求，生成理赔任务，可以通过以下过程实现：接收用户发起的理赔请求；根据该理赔请求获取案件信息和票据信息；根据该案件信息和该票据信息生成包括业务实体的理赔任务。

在一种可能的实施方式中，业务实体包括理赔主业务实体、用户实体、方案实体、产品实体、用户保障实体中的任意种组合。可选的，本申请实施例中的理赔任务包括业务实体是理赔主业务实体、用户实体、方案实体、产品实体、用户保障实体，其中，主业务实体中携带用户的相关信息，例如用户的属性信息，其他业务实体，用于进行相关的理赔计算。

在一种可能的实施方式中，步骤S202中获取理赔任务对应的理赔流程，可以通过以下过程实现：根据该理赔任务包括的该业务实体，确定该用户的属性信息；从预先配置的多个候选理赔流程中，选择与该属性信息匹配的候选理赔流程作为该理赔任务对应的理赔流程。

需要说明的是，本申请实施例中预先配置多个候选理赔流程。如3A～图3C给出3种不同属性信息对应的3中不同的候选理赔流程的示意图。

可选的，业务实体包括用户实体时，根据用户实体，确定用户的属性信息。业务实体不包括用户实体时，根据理赔任务包括的业务实体，确定用户的属性信息。

在一种可能的实施方式中，步骤S203中对理赔流程中包括的至少一个流程节点配置业务审核功能时，对该至少一个流程节点中的每个流程节点，对每个流程节点都配置审批通过功能和审批拒绝功能。

其中，步骤S203中，检测到第一流程节点接收到第二运算结果，确定检测到第一流程节点的业务审核功能被触发，第二运算结果为与第一流程节点存在网关流转关系的第二流程节点的运算结果。

可选的，步骤S203中，检测到该第一流程节点接收到第二审核结果，确定检测到第一流程节点的业务审核功能被触发，第二审核结果为与该第一流程节点存在网关流转关系的第二流程节点的审核结果，第二流程节点的审核结果为第二流程节点根据业务人员的审核操作生成的审核结果。

在一种可能的实施方式中，步骤S204中根据第一流程节点、理赔流程和理赔任务进行理赔计算得到第一流程节点的第一运算结果，通过以下过程实现：根据第一流程节点、理赔流程和理赔任务包括的业务实体进行理赔计算得到第一流程节点对应的第一运算结果。

可选的，本申请实施例中，在第一运算结果符合预设条件时，向用户发送设定消息，提醒用户进行相关的操作，或提醒用户关注理赔结果。

示例性的，根据上述可配置化的理赔审核框架，通过一个具体的示例来进行具体说明，具体包括以下部分：

1.理赔流程绑定理赔主业务实体A,理赔主业务实体A关联其他业务实体，包括：用户实体B，方案实体C，产品实体D，用户保障实体E等等，具体可通过元数据可应用理赔主业务实体A及理赔主业务实体A相关所有实体的字段及其特性。

2.用户发起理赔请求时，只需要提交理赔图片，点击发起理赔请求。后端服务器收到用户的理赔请求后，记录相关的理赔主业务实体数据,得到理赔主业务实体ID，然后启动理赔流程，理赔流程会根据理赔主业务实体ID和配置的网关条件，自动化决定执行哪条业务的理赔流程。比如VIP有VIP定制的理赔流程，VIP标签属于用户实体C的业务属性，这时在网关上配置C.property＝VIP即可使得该用户发起理赔请求时自动执行VIP定制流程。所有的实体及相关实体的字段在flowable中都通过元数据及计算服务进行接入，利用各个实体各个字段的特性实现了理赔流程的多样化配置。

3.理赔审核流程相关的审核人员的业务操作只有两个：审批通过，审批拒绝。但是相同的操作，对于不同的理赔流程可以配置不同的处理。这样对于审核人员非常方便，可以让审核人员聚焦于自己负责的业务，而不用关心怎么流转，流转给谁。以理算核赔环节举例，此环节业务人员针对TPA返回的结果以及理赔流程自动理算的结果进行核对，无误后点击通过即可。后台服务器收到业务的通过请求，理赔流程进行推进，有一种场景比如，理赔金额大于3000，要进行线下收单，那么理赔流程就可以在该理算核赔环节之后配置网关条件，A.pay_amount>3000理赔流程指派到线下收单节点，即可实现该功能。同样的，如果业务收单通过后，还需要进行理算核赔，理算流程可以配置展示回退按钮，只是按钮的名称是通过，这样业务人员看到的是通过按钮，但是实际对应的理赔流程是业务回退，对于业务审核非常友好。

4.在理赔审核流程中可定制添加消息服务，比如理赔流程配置了发送短信，业务人员可定制化配置短信模板，理赔流程触发发送短信的时候，可根据配置的元数据表达式通过理赔主业务实体ID得到具体的数据，这样就实现了短信的可配置化多样性的发送。

本申请的技术方案，最大改进点在于将理赔模型进行全面元数据化，并无缝接入了流程引擎flowable，这样在流程画布的配置过程中就可以按照业务实体，通过规则化的表达式全面定制理赔流程，而且变更业务审核流程对于业务人员来说毫无影响，具体业务人员还是聚焦于日常的业务处理操作，只通过简单的通过，拒绝就实现了多样化的理赔审核流程的流转。

需要说明的是，尽管以Flowable工作流引擎作为示例介绍了理赔流程的整体框架如上，但本领域技术人员能够理解，本申请应不限于此。事实上，用户完全可根据个人喜好和/或实际应用场景灵活设定工作流引擎，只要能够实现理赔流程的可定制化即可。

这样，通过定制的理赔流程，根据本申请上述实施例的理赔流程能够根据业务需要实现多样化的理赔审核流程。

图4示出根据本发明一实施例的理赔审核的配置装置的结构框图。如图4所示，该装置可以包括：

生成模块401，用于根据用户发起的理赔请求，生成理赔任务；

获取模块402，用于获取该理赔任务对应的理赔流程，该理赔流程包括按照预设的网关流转规则组成的多个流程节点；

配置模块403，用于对该理赔流程中包括的至少一个流程节点配置业务审核功能；

计算模块404，用于检测到第一流程节点的业务审核功能被触发，根据该第一流程节点、该理赔流程和该理赔任务进行理赔计算得到该第一流程节点的第一运算结果；该第一流程节点为该至少一个流程节点中的任意一个。

在一种可能的实施方式中，该生成模块401具体用于：

接收用户发起的理赔请求；

根据该理赔请求获取案件信息和票据信息；

根据该案件信息和该票据信息生成包括业务实体的理赔任务。

在一种可能的实施方式中，该计算模块404具体用于：

根据该第一流程节点、该理赔流程和该理赔任务包括的该业务实体进行理赔计算得到该第一流程节点对应的第一运算结果。

在一种可能的实施方式中，该获取模块402具体用于：

根据该理赔任务包括的该业务实体，确定该用户的属性信息；

从预先配置的多个候选理赔流程中，选择与该属性信息匹配的候选理赔流程作为该理赔任务对应的理赔流程。

在一种可能的实施方式中，该业务实体包括理赔主业务实体、用户实体、方案实体、产品实体、用户保障实体中的任意种组合。

在一种可能的实施方式中，该配置模块403具体用于：

针对该至少一个流程节点中的每个流程节点，对该每个流程节点都配置审批通过功能和审批拒绝功能。

在一种可能的实施方式中，该计算模块404具体用于，检测到该第一流程节点接收到第二运算结果，该第二运算结果为与该第一流程节点存在网关流转关系的第二流程节点的运算结果。

在一种可能的实施方式中，该装置还包括：发送模块(图中未示出)，用于在该第一运算结果符合预设条件时，向该用户发送设定消息。

本发明实施例各装置中的各模块的功能可以参见上述方法中的对应描述，在此不再赘述。

图5示出根据本发明一实施例的后台服务器的结构框图。如图5所示，该后台服务器包括：存储器510和处理器520，存储器510内存储有可在处理器520上运行的计算机程序。处理器520执行该计算机程序时实现上述实施例中的理赔审核的配置方法。存储器510和处理器520的数量可以为一个或多个。

该后台服务器还包括：

通信接口530，用于与外界设备进行通信，进行数据交互传输。

如果存储器510、处理器520和通信接口530独立实现，则存储器510、处理器520和通信接口530可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器510、处理器520及通信接口530集成在一块芯片上，则存储器510、处理器520及通信接口530可以通过内部接口完成相互间的通信。

本发明实施例提供了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现本申请实施例中提供的方法。

本申请实施例还提供了一种芯片，该芯片包括，包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行本申请实施例提供的方法。

本申请实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行申请实施例提供的方法。

应理解的是，上述处理器可以是中央处理器(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(fieldprogrammablegate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(advanced RISC machines，ARM)架构的处理器。

进一步地，可选的，上述存储器可以包括只读存储器和随机存取存储器，还可以包括非易失性随机存取存储器。该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以包括只读存储器(read-onlymemory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以包括随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用。例如，静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic random access memory，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhancedSDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

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

Claims (18)

1.一种理赔审核的配置方法，其特征在于，包括：

根据用户发起的理赔请求，生成理赔任务；

获取所述理赔任务对应的理赔流程，所述理赔流程包括按照预设的网关流转规则组成的多个流程节点；

对所述理赔流程中包括的至少一个流程节点配置业务审核功能；

检测到第一流程节点的业务审核功能被触发，根据所述第一流程节点、所述理赔流程和所述理赔任务进行理赔计算得到所述第一流程节点的第一运算结果；所述第一流程节点为所述至少一个流程节点中的任意一个。

2.根据权利要求1所述的方法，其特征在于，根据用户发起的理赔请求，生成理赔任务，包括：

接收用户发起的理赔请求；

根据所述理赔请求获取案件信息和票据信息；

根据所述案件信息和所述票据信息生成包括业务实体的理赔任务。

3.根据权利要求2所述的方法，其特征在于，根据所述第一流程节点、所述理赔流程和所述理赔任务进行理赔计算得到所述第一流程节点的第一运算结果，包括：

根据所述第一流程节点、所述理赔流程和所述理赔任务包括的所述业务实体进行理赔计算得到所述第一流程节点对应的第一运算结果。

4.根据权利要求2所述的方法，其特征在于，获取所述理赔任务对应的理赔流程，包括：

根据所述理赔任务包括的所述业务实体，确定所述用户的属性信息；

从预先配置的多个候选理赔流程中，选择与所述属性信息匹配的候选理赔流程作为所述理赔任务对应的理赔流程。

5.根据权利要求2-4任一项所述的方法，其特征在于，所述业务实体包括理赔主业务实体、用户实体、方案实体、产品实体、用户保障实体中的任意种组合。

6.根据权利要求1所述的方法，其特征在于，对所述理赔流程中包括的至少一个流程节点配置业务审核功能，包括：

针对所述至少一个流程节点中的每个流程节点，对所述每个流程节点都配置审批通过功能和审批拒绝功能。

7.根据权利要求1所述的方法，其特征在于，检测到第一流程节点的业务审核功能被触发，包括：

检测到所述第一流程节点接收到第二运算结果，所述第二运算结果为与所述第一流程节点存在网关流转关系的第二流程节点的运算结果。

8.根据权利要求1所述的方法，其特征在于，还包括：

在所述第一运算结果符合预设条件时，向所述用户发送设定消息。

9.一种理赔审核的配置装置，其特征在于，包括：

生成模块，用于根据用户发起的理赔请求，生成理赔任务；

获取模块，用于获取所述理赔任务对应的理赔流程，所述理赔流程包括按照预设的网关流转规则组成的多个流程节点；

配置模块，用于对所述理赔流程中包括的至少一个流程节点配置业务审核功能；

计算模块，用于检测到第一流程节点的业务审核功能被触发，根据所述第一流程节点、所述理赔流程和所述理赔任务进行理赔计算得到所述第一流程节点的第一运算结果；所述第一流程节点为所述至少一个流程节点中的任意一个。

10.根据权利要求9所述的装置，其特征在于，所述生成模块具体用于：

接收用户发起的理赔请求；

根据所述理赔请求获取案件信息和票据信息；

根据所述案件信息和所述票据信息生成包括业务实体的理赔任务。

11.根据权利要求10所述的装置，其特征在于，所述计算模块具体用于：

根据所述第一流程节点、所述理赔流程和所述理赔任务包括的所述业务实体进行理赔计算得到所述第一流程节点对应的第一运算结果。

12.根据权利要求10所述的装置，其特征在于，所述获取模块具体用于：

根据所述理赔任务包括的所述业务实体，确定所述用户的属性信息；

从预先配置的多个候选理赔流程中，选择与所述属性信息匹配的候选理赔流程作为所述理赔任务对应的理赔流程。

13.根据权利要求10-12任一项所述的装置，其特征在于，所述业务实体包括理赔主业务实体、用户实体、方案实体、产品实体、用户保障实体中的任意种组合。

14.根据权利要求9所述的装置，其特征在于，所述配置模块具体用于：

针对所述至少一个流程节点中的每个流程节点，对所述每个流程节点都配置审批通过功能和审批拒绝功能。

15.根据权利要求9所述的装置，其特征在于，所述计算模块具体用于，

检测到所述第一流程节点接收到第二运算结果，所述第二运算结果为与所述第一流程节点存在网关流转关系的第二流程节点的运算结果。

16.根据权利要求9所述的装置，其特征在于，还包括：发送模块，

用于在所述第一运算结果符合预设条件时，向所述用户发送设定消息。

17.一种后台服务器，其特征在于，包括：处理器和存储器，所述存储器中存储指令，所述指令由处理器加载并执行，以实现如权利要求1至8任一项所述的方法。

18.一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-8中任一项所述的方法。

Images