继上文讲到的互联网保险产品设计那点事（一）后，笔者继续从财险理赔角度入手做进一步深入分析。
1. 前言
在互联网保险行业中，非保险产品供应侧的企业的业务流程大致是相似的。如下图：
在上述的三个业务流程步骤中，从产品设计的角度考量，最具有保险专业特性的模块为项目运营管理。
在互联网保险经代类企业中：
1. 项目运营管理产品设计核心偏重于保险产品管理以及保单保全管理；
2. 产品设计难点：
保险产品管理（偏重核保规则配置）；
保险产品投保管理（偏重投保流程客制化配置）；
在互联网保险服务类企业中：
1. 项目运营管理产品设计核心偏重于保险保全管理以及保险理赔管理；
2. 产品设计难点：
保险产品管理（偏重理赔规则配置）；
保单保全管理（偏重保单额度规则及流程配置）；
本文就互联网保险服务类企业的核心模块（理赔）的产品设计进行分享。
本文的理赔模块的业务选择范围：
企业范围：TPA企业
险种范围：健康险
用户维度：B2B2C
业务维度：团险
选择原因：目前互联网保险行业中，健康险的团险理赔与互联网场景契合度最高，也最为复杂之一。
2. 理赔产品设计
2.1 理赔业务流程
上图所示为健康险中理赔场景的业务处理流程，一个理赔案件的处理流程从立案收单到结案申请书输出为一个完整的理赔预处理流程。
为什么称为完整的理赔预处理流程，而不是完整的理赔处理流程呢？
因为这里缺失了【保额扣减】的环节。这一环节是当赔案经过理算引擎理赔得出预计赔付金额后，会根据结算引擎（额度扣减规则）的运算得出实际赔付金额。当得到实际赔付金额后，整个理算流程才会完成。然而保单保额的管理角色的扮演者在不同的客户场景中是不同。有的保险项目中，保额的管理者是被保险企业或保险产品供应侧企业；有的保险项目中，保额的管理者是理赔处理方。
因为保额管理以及赔案结算引擎本身复杂度也较高，因而会在后续的文章中单独分享，在此就不展开分享。
2.2 收单模块
2.2.1 业务场景
被保险人在申请保险理赔服务后，通过线上(如：APP)或线下(如：快递邮寄)的方式，将索赔申请书，身份证明等理赔所需相关申请材料递交到理赔处理方的动作，称为收单。
2.2.2 收单方式
根据实际业务场景大体分为以下几种收单方式：
赔案资料线上方式上传：如通过APP上传或通过制定网页上传；
赔案资料快递寄送：被保险人通过邮寄的方式将资料递交给理赔方；
赔案资料送货上门：被保险人亲自将理赔材料送到理赔方所在企业；
收单人员批量收取：理赔方指派专业人员去被保险企业或被保险人所在地批量收取材料；
2.2.3 收费模式
在通过指派专业收单人员进行批量收单时，会产生人力成本，进而会发生服务变现的方式，主要收费方式有以下几种：
按年收取收单服务费：如：2019年驻场收单费用为50万元；
按人收取收单服务费：如：驻场收单人员每人每月5000元；
按次收取收单服务费：如：每次收单服务收取服务费200元；
按件收取收单服务费：如：每个案件的全流程服务费20元；
2.2.4 设计难点
显而易见的难点：对于收单人员和收单计划的合理管理和收取的理赔案件管理，如何保障每个案件及每个案件所包含的所有材料均未有遗失且可被逐一追溯？
对于赔案时效的管理和跟踪（收单时效：一个理赔案件从收单开始到录入系统的时间限制）；
对于收单服务费的费率表的维护和结算管理；
在收单时，会对收取材料类目错误或收取材料内容错误进行打回重新收取的管理。
其他难点。。。
2.2.5 设计思路
针对第1和第2难点：
基本方案：人员管理，人员月度任务排期，整体理赔模块的案件流转监控体系等。
优化方案：收单任务池，任务自动分配，任务抢单机制等；
针对第3难点：
基本方案：是提供客制化的费率规则模板。
但从本质讲，规则模板并未解决用户需求，因为这个需求的用户并不是对外用户而且对内用户，即销售及业务管理者。销售和业务管理者的本质需求是可以便捷的维护和管理费率表（所录即所见）。而使用规则模板的解决方案只降低了开发成本，并未达到便捷管理的需求。
优化方案：通过交叉决策表替代规模模板来维护和管理费率表。
针对第4难点，这类问题是整个理赔流程皆有的异常流程处理机制，需要了解整个理赔流程的异常流程分支后，进行统一化处理。
其他难点也有很很多，这主要根据险种和客制化需求不同而不同。
2.3 扫描模块
2.3.1 业务场景
在收单后，将收取的理赔案件的纸质化资料通过扫描设备转化为电子影像件，方便后续的理赔自动动作执行。
2.3.2 设计难点
扫描阶段的难点并不在互联网产品设计中，而在硬件设备的扫描SDK中，此处要考究产品的点主要在于录入方式是通过人工化录入还是自动化录入（ICR识别技术，注意是ICR而非OCR）
扫描阶段有一个小难点：
如何保障在扫描执行中不会漏扫案件？
因理赔案件材料数目及类目不足而需补扫或重新扫描时，如何不打乱整个赔案序列或不影响扫描效率？（赔案序列即为批量收单时根据被保险人递交顺序生成的批量序列，此序列因规定不可更改）
2.3.3 设计思路
难点1，并不在此处分享，会在后续录入环节中分享。
难点2，此处涉及具体产品设计内容并不延伸讨论。总的讲，了解业务后，解决方法多种多样。
2.4 录入模块
2.4.1 业务场景
将扫描环节生成的理赔案件的电子影像件的理算所需内容录入到理算系统中。
2.4.2 录入方式
根据实际研发能力分为以下2种收单方式：
人工录入：成本较ICR略低，但准确率低，不足70%；
ICR识别录入：小业务量下，成本较高，大业务量下，成本较低，准确率在少量人工干预下可达到95%及以上；
2.4.3 设计难点
因为我们要通过互联网的方式实现自动化理赔，那么理赔的核心理算环节的准确率则至关重要。保证理算准确率的有三个关键因素：理算基础数据，理算规则，理算流程。而录入环节则是保证理算基础数据的准确性。
在健康险中，理算的基础数据有哪些呢？
索赔申请书的字段数据；
身份证明的字段数据；
病例的字段数据；
发票及支付凭证的字段数据；
消费项目清单的字段数据；
其他客制化需求的资质证明数据等；
以上的资料中录取准确性差异最大的模块为发票和消费项目清单，此处就发票进行简单的介绍。
健康险下，发票类型大致分为：门诊发票，住院发票，增值税发票(购药使用)；
而发票模板由于各省市的发票模板各有不同，大体上可针对门诊发票和住院发票，又分为【通用发票模板】【北京发票模板】【上海发票模板】【解放军(医院)发票模板】。
针对发票模块所需要录入的信息，主要有以下几点：
1. 发票号：方便进行发票验真。
2. 发票类型：上文已述。
3. 发票所属医疗机构；
4. 发票日期：门诊发票为单个日期，住院发票为住院日期和出院日期。
5. 发票所属疾病的ICD10编码： 国际疾病分类（international Classification of diseases ,ICD），是依据疾病的某些特征，按照规则将疾病分门别类，并用编码的方法来表示的系统
6. 发票金额字段：
发票合计金额：发票的总计金额；
医保统筹支付金额：统筹支付就是用统筹帐户资金支付参保人相关医疗费用。帐户支付，也就是用参保人的医保卡在药店或门诊的刷卡消费行为。医保统筹管理，由个人帐户和统筹帐户组成；
分类自负（自付二）：指基本医疗保险支付部分费用项目中，先由参保人员个人按规定比例或差额进行现金自付的费用。合计结算前的自负部分，比如乙类自负10%；
自负（自付一）：指医保结算范围内的医疗费用。合计结算后自负部分，比如说退休自负10%；
自费：指医疗保险基金支付范围外的药品、医疗服务项目费用及《浙江省基本医疗保险、工伤保险和生育保险药品目录》、《浙江省基本医疗保险医疗服务项目目录》内的限定支付费用和超标准以上部分费用；
三方支付：其他报销。
2.4.4 设计思路
此处在大多数非大理赔服务方(即赔案年处理量低于500万件)，采用的录入方式是人工录入。那么就要考量如何更有效更准确的进行赔案录入。需要结合企业业务现状，录入人员技能强弱，人力成本，进行合理的录入功能产品拆分，保障在同等人力成本下，录入的效率和准确性得以显著提高。
需结合下一环节（理算）的需求，将一些通用的理算环节的预处理流程事先在录入环节得以实现，这部分会在理算中讲解。
2.5 理算模块
2.5.1 理算场景
将通过人工或自动化的方式计算赔案的实际赔付金额。
2.5.2 理算基础公式
门诊保险金计算公式：
预计赔付金额 = （发票核准金额 – 免赔金额）* 赔付比例
住院保险金计算公式：
预计赔付金额 = （发票核准金额 – 免赔金额）* 赔付比例
津贴保险金计算公式：
预计赔付金额 = 每日津贴 *（赔付天数 – 免赔天数）（赔付天数 <= 单次最长天数）；
以上计算公式仅为基础理算公式，实际业务因为保险产品的客制化需求各不相同，即理算规则模型各不相同。
理算规则示例参考如下：
示例1：
关于跨年度案件理赔（住院）核实结果参照以下方案：
1. 津贴 =（前年度天数 * 前年度津贴）+（当年度天数 * 当年度津贴）
2. 住院医疗费用 =（发票合计金额 – 医保统筹支付金额 – 非医保金额）* 前年赔付比例 * 前年度天数 / 总天数+（发票合计金额 – 医保统筹支付金额 – 非医保金额）* 当年赔付比例 * 当年度天数/总天数
3. 赔付比例：员工100%，家属50%；
4. 住院天数：若为0.5天，则按1天计算，若为9.5天，则按9天计算。
5. 第三方赔付金额，按照以下公式的结果取小值进行理算：
理算合理金额1 = 总金额– 统筹– 第三方赔付
理算合理金额2 =（发票合计金额 – 医保统筹支付金额 – 非医保金额）* 赔付比例；
示例2：
示例3：
示例4：
2.5.3 设计难点
从以上示例，可发现理算规则模型各式各样，参照标准范围极广。因而如何更好更便捷的维护和使用理算规则，是自动理算引擎的核心难点。理算引擎由于内容复杂，会作为单独的章节在后续讲解。
2.6 复核模块
2.6.1 业务场景
在录入和理算环节都存在复核场景的存在，复核即对有异议的赔案进行重新审查。如
录入环节中，录入人员对赔案资料中非标准化数据的录入存疑时，执行赔案挂起操作，赔案被标记为疑问件，此时就需要复核岗的介入。
理算环节中，对于单独赔案申请理赔金额超过5000或多次被退单拒赔的案件需要复核岗进行结果审核；
2.6.2 设计难点
此模块需要对全理赔流程的异常流程分支进行整合梳理和归纳分类。区分
是否需要暂停理赔时效；
必须复核的规则时什么？
…
2.7 结案模块
2.7.1 业务场景
在完成理算和复核环节后，如赔案的被保险人的保单的保额的管理权限不属于理赔方时，赔案流程跳转到结案环节。如保额管理权限属于理赔方，则跳转到赔案的实际赔付金额计算环节。
PS：如不属于理赔方时，默认实际赔付金额与预计赔付金额相等。
2.7.2 设计难点
当理赔方不是保险产品供应侧（保险公司）时，理赔方需向保险公司输出赔案结案申请和赔案结案数据。因各保险公司的数据导入规则和导入通道各不相同，因而结案时需根据保险公司需求进行数据对接。
对结案数据的管理和结案纸质原件的文档管理。
结案数据与被保险人的属性关联，用户的健康管理。
…
本期就分享到这，下一期主要分享一下关于理赔核心—理算引擎的相关内容。
