网络保险产品设计:保险索赔

在上述关于网络保险产品设计的事情(1)之后，笔者继续从财产保险理赔的角度做进一步的深入分析

1。序言

在互联网保险业中，非保险产品供应商的业务流程大致相似。下图:

在以上三个业务流程步骤中，从产品设计的角度来看，最具保险专业特色的模块是项目运营管理

:

1。项目运营管理产品设计的核心是保险产品管理和保单保存管理。

2。产品设计的难点:

保险产品管理(强调核保规则的分配)；保险产品保险管理(强调保险流程的定制配置)；

互联网保险服务企业:

1。项目运营管理产品设计的核心是保险保全管理和保险索赔管理；

2。产品设计难点:

保险产品管理(强调索赔规则配置)；索赔管理(部分自动索赔流程的定制配置)；策略保存管理(强调策略配额规则和流程配置)；

本文分享了互联网保险服务企业核心模块(理赔)的产品设计。

本文理赔模块的业务选择范围为

业务范围:TPA业务覆盖范围:健康保险用户维度:B2B2B2C业务维度:团体保险

选择原因:在当前的互联网保险业中，健康保险的团体保险理赔与互联网场景的契合度最高，是最复杂的之一。

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:

基本方案:人员管理、人员月度任务调度、总索赔模块的案例流程监控系统等优化方案:收集任务池、自动任务分配、任务抓取机制等。

针对第三个难点:

基本方案:提供定制的费率规则模板

但从本质上来说，规则模板没有解决用户的需求，因为这种需求的用户不是外部用户，而是内部用户，即销售和业务经理销售和业务经理的基本要求是轻松维护和管理费率表(记录的就是看到的)但是，使用规则模板的解决方案只能降低开发成本，不能满足方便管理的要求。

优化方案:通过用交叉决策表替代比例模板来维护和管理费率表

是针对第四个困难的。这种问题是一种异常的过程处理机制，存在于整个理赔过程中。在了解整个理赔流程的异常流程分支后，需要统一处理。

还有许多其他困难，主要是根据保险类型和定制需求而有所不同。

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录入模式

根据实际研发能力分为以下两种入库模式:

手工录入:成本略低于ICR，但准确率较低，不到70%；ICR识别录入:小业务量下成本较高，大业务量下成本较低，少量人工干预准确率可达95%以上；

2.4.3设计难度

由于我们要通过互联网实现自动理赔，理赔核心调整环节的准确性至关重要保证平差精度的关键因素有三个:基础数据的平差、平差规则和平差过程输入环节是为了保证基础数据的准确性

为健康保险调整的基本数据是什么？索赔申请表

字段数据；身份证明的现场数据；案例的现场数据；发票和付款凭证的字段数据；消耗项目列表的字段数据；其他定制要求的资格认证数据等。；

以上数据中准确性差异最大的模块是发票和消费项目列表。以下是发票的简要介绍。根据

健康保险，发票类型大致可分为:门诊发票、住院发票和增值税发票(用于药品采购)；

和发票模板可分为[普通发票模板】、[北京发票模板】、[上海发票模板】、[解放军(医院)发票模板]一般用于门诊发票和住院发票，因为发票模板因省市而异。

主要包括以下需要在发票模块中输入的信息:

1。发票号码:便于发票验证

2。发票类型:如上所述

3。发票所属的医疗机构；

4。发票日期:门诊发票是单日期，住院发票是住院日期和出院日期

5。发票所属疾病的ICD10代码:国际疾病分类(ICD)，系统

6。发票金额字段:

发票总金额:根据疾病的某些特征和疾病的分类，按照规则和编码方式表示的发票总金额；医疗保险统筹支付金额:统筹支付是用统筹账户的资金支付被保险人的相关医疗费用。账户支付，即在药房使用参保人的医疗保险卡或门诊卡消费的行为医疗保险的整体管理由个人账户和整体账户组成。分类自筹(自筹二级):指参保个人在基本医疗保险的部分项目中，按规定比例或差额以现金支付的费用。结算前自筹部分合计，如乙类自筹10%；自筹(自筹1):指医疗保险结算范围内的医疗费用。总结算后，自收自支部分，如退休自收自支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业务场景

199存在于输入和调整阶段。审查意味着重新审查有争议的赔偿案件例如，在

录入阶段，当录入人员对薪酬案例数据中非标准化数据的录入有疑问时，薪酬案例将被暂停，薪酬案例将被标记为可疑案例，因此需要审核岗位的介入。在调整过程中，要求审查员额审查索赔额超过5 000英镑或多次被驳回的个人赔偿案件的结果。

2.6.2设计难度

本模块需要对整个理赔流程的异常流程分支进行整合、整理和分类区分

是否需要暂停理赔时限；理赔是否需要向保险产品供应方发起索赔查询；必须审查的规则是什么？……2.7结案模块

2.7.1业务场景

在完成调整和审查流程后，如果被保险人的赔偿案件保单的管理权限不属于理赔方，赔偿案件流程跳转至结案流程如果保险金额管理权限属于索赔人，将跳转到赔偿案件的实际赔偿金额计算环节。

PS:如果不属于索赔人，默认实际赔偿金额等于预期赔偿金额

2.7.2设计难度

当理赔方不是保险产品供应方(保险公司)时，理赔方需要向保险公司输出理赔申请和理赔数据由于各保险公司的数据导入规则和导入渠道不同，结案时需要根据保险公司的需要进行数据对接。关闭数据管理和关闭纸质原件的文档管理结算数据与被保险人的属性和用户的健康管理相关。...

本期将分享这一点，下一期将主要分享索赔核心——调整引擎的相关内容。本文

最初由@ yang三际发表。每个人都是产品经理。未经允许，禁止转载

图片。它来自Unsplash，基于CC0协议