互联网保险产品核心之引擎篇

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

继上文讲到的 互联网保险产品设计那点事(二):保险理赔 后,笔者继续从理算引擎角度入手做进一步深入分析。

互联网保险产品核心之引擎篇

01 前言

作为一个深耕互联网保险领域的产品经理,随着不断深入的接触保险业,会时常听到【XX引擎】这类名词。那么在互联网保险中,常见的有哪几类业务处理引擎呢?

  1. 核保业务处理引擎
  2. 理算业务处理引擎
  3. 核赔风控决策引擎

本章承接上一章保险理赔的内容,具体介绍一下在什么是 理算业务处理引擎 ,以及理算引擎的业务主流程及产品难点。

理算:核赔的关键环节之一,指保险人在核赔过程中按照法律规定和保险合同的相关规定、根据保险事故的实际情况计算并确认理赔金额的一个过程。它作为理赔过程中最关键的环节一方面要维护了保险公司的利益,另一方面也要兼顾被保险人的利益,做到公平、合法、事实求实,遵循保险利益原则、最大诚信原则以及补偿原则等基本原则。

02 理算业务流程

如同上面的概念介绍的一样,理算就是 根据保险合同的相关规则,将被保险人提供的消费凭证与报销证明进行一一校验,并计算出合理的理赔金额的过程。 而互联网保险的产品价值,就是将这一 复杂 的校验和计算过程通过互联网的方式降低人力成本,提高核赔准确率。本文,通过健康险中的团险,简单讲一下理算流程。

在健康险中,团险的大多应用场景为企业为员工购买企业补充医疗险或商业保险。险种包含如下几类:「门急诊医疗」「住院医疗」「住院津贴」「女性生育」「意外医疗」「疾病医疗」「XX伤残」「XX身故」等等。以上几类在团险健康险的理赔中,出险频次最高的主要为「门急诊医疗」「住院医疗」「住院津贴」,可以说业务量占比超50%是稳稳的。

互联网保险产品核心之引擎篇

上图是我归纳设计的健康险的理算流程(此处PS:各家对于理赔理算的流程并不相同,此处PM需结合具体的业务特点进行整理设计。本文介绍的流程仅为抛转引玉的作用)

  • 赔案数据导入:主要在理赔的录入环节中实现,将赔案所需理算的各个数据字段导入到理算引擎中。
  • 预计赔付理算:通过保险合同的理赔规则,通过赔案数据计算出预计赔付金额。
  • 实际赔付理算:通过保险合同的剩余保额和保额的扣减规则,通过预计赔付金额计算出实际赔付金额。
  • 结案:赔案理算流程结束,输出结案通知书于被保险人和承保人。

本章主要针对上面四个流程中的 【预计赔付理算】 这个环节进行简单分享。

03 预计赔付理算流程

互联网保险产品核心之引擎篇

3.1 赔案数据拆单

在理算实际业务场景中,一份理赔案件中大多会包含多张发票,而理算师需要将每张发票对应的理赔金额一一算出后,再进行整份理赔案件的理赔金额的计算。因此在自动理算中的第一步就是将一份理赔案件根据规则进行拆单。

如上图,一份理赔案件,可根据赔案层,就诊层,发票层进行三层拆分。

  • 赔案层:一份完整的理赔案件为一个赔案;
  • 就诊层:就诊层是一个虚拟概念,即针对「同一天,同一科室,同一疾病为的发票集合」为一次就诊。
  • 发票层:一张发票为一次理算流程的最小单元集,同一张发票可能对应一个或多个疾病。

为什么要如上的规则进行对理赔案件的拆分呢?原因:同一发票,

  • 因为针对不同的疾病,所以赔付方案不同;
  • 因为针对不同医院和科室,赔付赔付方案不同;
  • 因为不同时间,所以赔付方案不同;

3.2 支付凭证校验

在健康险中,大多数支付凭证为医疗类的发票。那么在赔案拆分后,金额计算之前,需要对发票是否在保险合同规定的理赔范围内进行校验。校验流程主要如上图:

  • 发票时间是否为赔案所属团体保单的保险期间的判定规则;
  • 发票类型是否为赔案所属保险计划的责任范围的判定规则;
  • 发票机构是否为赔案所属保险计划的保障机构的判定规则;
  • 发票疾病是否为赔案所属保险计划的保障疾病的判定规则;
  • 发票药品是否为赔案所属保险计划的保障药品的判定规则。

如果发票信息未通过以上校验,那么该发票为拒赔发票。如果发票信息通过以上校验,那么该发票可以进入下一环节。

3.3 凭证责任匹配

在该环节,是将发票与保险合同的某一保险责任进行关联。因为同一发票可能属于多个疾病的报销凭证,而每个疾病对应的保险责任可能不同。所以此处发票可能会与多个保险责任。根据保险中的医疗险的【不获利原则】,不能对同一消费明细进行重复理赔。因而如何精准的设计关联规则至关重要。

3.4 核准金额计算

在发票与责任确定关联后,则可以计算发票的核准金额,核准金额的计算公式根据保险合同的规定不同而不同。核准金额不会超过发票的总计金额。此处的扣减项在上一章【互联网保险产品设计那点事(二):保险理赔】已有说明。

3.5 预计赔付计算

预计理赔金额的计算是根据保险责任对应的规则进行定制化的计算流程。

  • 免赔额:指由保险人和被保险人事先约定,损失额在规定数额之内,被保险人自行承担损失,保险人不负责赔偿的额度。
  • 比例赔付:指保险公司不按实际损失全额承担赔偿责任,而是按照实际损失乘以保险金额与保险价值的比例承担赔偿责任。

在健康险中,常见的三类责任保险金计算公式如下:

  1. 门诊保险金计算公式:预计赔付金额 =(核准金额 – 免赔金额)* 赔付比例
  2. 住院保险金计算公式:预计赔付金额 =(核准金额 – 免赔金额)* 赔付比例
  3. 津贴保险金计算公式:预计赔付金额 = 每日津贴 *(赔付天数 – 免赔天数)

在上述的三类保险金计算公式中,常见的定制化计算需求如下:

保险限额:

  • 在非津贴类的责任中,主要有如下规则:
    • 总限额;
    • 年限额;
    • 日限额;
    • 单次赔付限额;
    • 医疗机构限额;
    • 疾病限额:
    • 最低限额;
    • 等等
  • 在津贴类的责任中,主要有如下规则:
    • 总天数限制;
    • 单次最长天数限制;
    • 每天额度;
    • 累计天数超过1天时的天数取值规则;
    • 累计天数不超过1天时的天数取值规则;
    • 时间跨越保险期间的赔付规则;
    • 等等;

赔付比例:

  • 唯一值:顾名思义,及同一责任只有一个赔付比例,这一类也是醉常见的类型。
  • 阶段取值:当核准金额满足某一范围内,取对应的赔付比例值为该理算流程的赔付比例值。
  • 阶梯求和:与个人所得税计算逻辑类似。

下图即为【阶梯求和】的赔付比例表:

同一个保险产品中赔付比例还会存在因为发票所属疾病不同,医院不同,被保险人年龄不同,职级不同,就诊原因不同,社保类型不同等等而各有不同。

3.6 赔案结果归单

当将每张发票的预计赔付结果计算结束后,将发票的结果归并为就诊结果,再将就诊结果归并为赔案结果。此时赔案的【预计赔付理算】环节即完成。

04 实际赔付理算流程

到这一环节,很多读者可能会存在疑问:已经通过责任规则计算出理赔金额了,为什么不直接结案,而要增加一步【实际赔付理算流程】呢?

因为在健康险的团险保单中,对于保额的管理并不像个体保单那么简单,在团体保单中,出了被保险人外还有被保险企业的存在。因而会大大加深对保额管理的复杂度。在本节会通过一个实际案例,让读者对这一环节有一个较为清晰的理解。

下段为一个实际案例的保额扣减相关的部分规则:

(1)医保报销范围内的,掌握“先用 当年基本医疗个人账户 、再用 历年基本医疗个人账户 、最后 补充医疗个人账户 ”报销原则;

(2)乙类、丙类,在历年基本医疗个人账户下报销;

(3)个人账户报销使用后仍不足报销需享受 单位医疗补助 时,需先扣除当年其家属享受的个人账户家庭共济的总额,再进行单位医疗报销;

(4)关于 单位医疗补助 ,本行对员工的普通门诊补助实行“设立起报点,按比例报销,最高额控制”的办法。起报点以内由员工本人自理,不得报销。在职员工起报点为500元,退休、退职员工不设起报点。报销比例及最高额具体如下:

  1. 实际工龄在30年以上的员工,起报点以上部分医疗费按90%报销,最高报销医疗费1800元(指超额实报数,下同)。
  2. 实际工龄20年至30年(含)的,起报点以上部分医疗费按85%报销,最高报销医疗费1700元。
  3. 实际工龄15年至20年(含)的,起报点以上部分医疗费按80%报销,最高报销医疗费1600元。
  4. 实际工龄10年至15年(含)的,起报点以上部分医疗费按75%报销,最高报销医疗费1500元。
  5. 实际工龄5年至10年(含)的,起报点以上部分医疗费按70%报销,最高报销医疗费1400元。
  6. 实际工龄5年(含)以下的,起报点以上部分医疗费按60%报销,最高报销医疗费1200元。
  7. 退休、退职员工个人账户以外部分医疗费按95%报销,最高报销医疗费2000元。

上述案例规则涉及到同一个被保险人的保额账户下的【基本医疗当年账户】【基本医疗历年账户】【补充医疗账户】【公共医疗账户】【连带被保险人账户】等各类不同维度的子账户,因而设计的保额管理模型样例如下:

此图仅为概念图,真实设计中较改图展现的管理逻辑更为复杂。

因而实际赔付理算流程与预计赔付理算流程的逻辑复杂度相当,需要PM对业务十分了解后,才能更好更完善的设计出符合业务需求的自动理赔系统。

该文仅是理算引擎的冰山一角,希望一些初入互联网保险的PM可以对保险系统有一点初步的了解。

 

本文由 @杨三季 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

随意打赏

提交建议
微信扫一扫,分享给好友吧。