本文主要是介绍《大数据+AI在大健康领域中最佳实践前瞻》---- 智能服务在保险业务中的应用探讨,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
文章大纲
- 简介
- 技术样例前瞻
- demo 样例
- 智能问卷
- 软件技术架构
- 根据保险规则生成标签
- 建立投保人标签库
- 提供数据服务
- 接口设计
- 输入
- 输出
- 原型设计
- 创新性
- 参考文献
简介
互联时代,特别是移动互联网日渐普及之后,大数据的搜集变得更为方便和可行,大数据的应用价值受到了各行各业的关注,甚至大数据本身也成了一个专门产业。保险作为基于大数法则运营发展的商业行为,对大数据的利用有着天然的倾向性。
首先,行业竞争倒逼核保和理赔速度的提升,可能带来核保、核赔质量下降的负面影响。从纯理论角度和最理想化的角度来讲,核保和核赔这两个环节是可以为保险公司屏蔽所有逆选择和道德风险的。但付出的代价是用大量的人力对每个投保和理赔申请都进行大量的细致调查。这在保险公司实际运营中是不可能的。特别是在行业竞争越来越激烈的今天,为提升客户体验,保险公司的投保条件愈发宽松,核保核赔速度快,甚至免核保、免体检、快速赔付已经成为保险公司吸引客户的“标配”所在。各家公司千方百计提高服务速度,核保核赔部门往往要承受客户和销售部门的双重压力。在此情况下,虽然保险公司的保费收入有了较大增长,但是承受的风险冲击将明显增大。公司管理层对业绩增长的期待,或多或少冲淡了本该固若金汤的风控意识。
其次,互联网保险的发展,客观上增加了风险控制的难度。如今,网络销售、移动互联网销售日益被保险公司所重视。各种保险销售网站,成为了保险公司新的保费增长点。甚至客户通过手机微信等软件终端,就可以轻松完成投保或理赔过程,在这种情况下,材料真实性验证难度较大,信息不对称性更为突出,机会型欺诈风险增加。异地出险的增加,也对理赔后续工作提出较高要求,容易出现保险服务流程衔接的空白。在传统保险销售过程中,销售人员与客户面对面地沟通,其实也是一种了解客户的过程。但是互联网保险的发展让这个过程消失。核保部门失去了一道天然屏障。这些都是增加了风险控制的难度。
双核系统是一个人工智能驱动的核保核赔系统。旨在辅助保险公司为投保人提供更优质的保险服务。
双核系统的主要目的是:
- 智能化手段处理大批量居民医疗数据,进行健康分析。
- 为不同公民提供量身定制的核保核赔方案
- 简化保险人员工作流程,提高保险公司保险服务质量。
技术样例前瞻
核保核赔系统,使用业界领先的云服务基础架构,将系统功能封装为服务对外提供,系统的软件技术方案如下。
demo 样例
智能问卷
参照同行业智能问券系统,系统核心功能一般应包括:可配置问券设计平台,问券服务,应答服务共计3种服务,同时问卷内容,应答过程需要分别独立存储。
保险公司的问卷设计业务专家,通过智能问券系统提供的问卷设计功能,对本公司问卷的流程、内容、种类进行设计和编辑(增删改查)。
智能问券系统通过输出可适应各种展示平台和格式的问卷,向保险公司的展业系统输出和集成各种类型的问卷。
通过应答交互接口获取用户问券的应答数据并执行每一步的判断逻辑,并将应答数据和逻辑判断结果返回给保司核心系统,由保司的核心系统中的业务规则做出是否承保等的最终判断。
基于以上功能需求的分析,智能问券的初步技术架构设计如下:
本设计将满足以下一些核心要点:
- 可本地化部署
- RESTFul 接口,适应各种系统集成
- 自定义设置问卷内容,设置及修改各子问题
- 多维度问卷信息获取
项目需要的技术相关人员配置为:
架构师1名,前端工程师1名,后端工程师3名,QA工程师1名,实施工程师1名。
基于上述设计的智能问券项目总周期约为3个月左右【包含实施周期】,总工作量约为44人周 。智能问券项目可分为以下3个阶段:
(1) 产品及系统设计周期(序号1-2)约为2周,工作量需2人周。
(2) 主要开发周期(序号1-6)约为8周,工作量需32人周。
(3) 实施周期(序号7-12)约为2周,工作量需10人周。
软件技术架构
由于不同国家的卫生系统高度分散,因此很难获得跨境活动的公双核平台目前使用Aws redshift作为数据服务承载。Aws s3作为数据持久化备份策略。Aws ApiGateway+Lambda方式作为后台服务响应方。前端采用angular js7.0 或者 VUE 等框架
除此之外,使用AWS IAM 来安全地控制对AWS 数据资源的个人访问权限和组访问权限。并且增加登陆认证确保用户安全登录以及数据请求。
以下是整体软件架构:
根据保险规则生成标签
保险行业关于是否投保有很多的标准。我们可以将其提炼成数据标签形式进行数据描述。核保核赔系统就可以根据数据的标签来决定数据所有人的投保方式,或者将需要进行深度审核的投保人筛选出来,减轻保险员的工作负担。
例如:重疾标签
重疾标签主要是根据国家规定的35种重大疾病。对于历史患有重大疾病的投保人,建立重疾标签。
国家规定的35种重大疾病主要有:
恶性肿瘤、急性心肌梗塞、脑中风后遗症、重大器官移植术或造血干细胞移植术、冠状动脉搭桥术、终末期肾病、多个肢体缺失、急性或亚急性重症肝炎、良性脑肿瘤、慢性肝功能衰竭失代偿期、脑炎后遗症或脑膜炎后遗症、深度昏迷、双耳失聪、双目失明、瘫痪、心脏瓣膜手术、严重阿尔茨海默病、严重脑损伤、严重帕金森病、严重III度烧伤、严重原发性肺动脉高压、严重运动神经元病、语言能力丧失、重型再生障碍性贫血、主动脉手术、终末期肺病、严重多发性硬化、急性出血性坏死性胰腺炎、原发性心肌病、持续植物人状态、坏死性筋膜炎、经输血导致的人类免疫缺陷病毒感染、全身性重症肌无力、肌营养不良症、严重克隆病。
建立投保人标签库
通过在aws EMR集群上对原始数据(投保人历史医疗数据、当次体检数据等)进行ETL处理,选择适配的标签处理模式,对于每一个投保人生成一个特有的标签记录。
目前已经建立的标签库主要有慢性病、重大疾病、医疗金额消费异常、医疗就诊行为异常等标签库。
1.使用EMR连接s3,将数据记录持久化到s3进行存储。
2.将s3上的数据导入到redshift。
3.使用EMR连接redshift,定期将增量化记录同步到redshift数据库中。
提供数据服务
1.登陆验证
使用ApiGateway 进行登陆验证。主要是用来验证用户的合法性以及安全性。
2.数据查询服务
完成登陆验证的用户,可以进一步使用数据服务。数据服务使用flask提供。通过flask连接redshift,根据用户输入的查询条件返回结果。
3.数据标签分布结果
完成登陆验证的用户可以直接查询当前系统的标签分布结果。
接口设计
输入
本系统当前支持基于用户ID的查询输入
输出
展现的字段名称 | column_name | 类型 | 页面展示数据样例 |
身份证号 | id | str | 110104199608155612 |
姓名 | name | str | ** |
性别 | sex | str | 男 |
年龄 | age | int | 28 |
重疾患病风险 | seriousill_label | str | 高 |
重疾患病种类数 | seriousill_count | int | 1 |
重疾中轻微疾病患病风险 | lightill_label | str | 低 |
慢性病患病风险 | chronicill_label | str | 高 |
慢性病患病种类数 | chronicill_count | int | 2 |
医疗消费金额异常 | abnormal_medical_consumption_label | str | 低 |
就诊行为异常 | abnormal_visiting_behavior_label | str | 高 |
核保建议 | underwriting_proposal | str | 请提供1年内体检报告资料和详细病例资料 |
建议体检项目 | recommended_physical_examination | str | 血液检查(空腹血糖,糖化血红蛋白等) 尿液检查 |
核保参考结论 | underwriting_conclusions_reference | str | 寿险:若病情控制良好,不吸烟、不伴有高血压、脑血管疾病等高危因素或严重并发症,且在公司体检各项指标均在正常范围可考虑 加费承保,否则予以延期或拒保。重大疾病及住院:拒保。 |
参考: 基本核保手册
原型设计
登录
创新性
双核平台为保险从业人员提供了一种智能赋能的核保核赔方式。具体创新性提现在以下几点:
1.创造性的通过人工智能算法(分类,聚类,异常检测,预测等算法)进行驱动,对个人健康数据进行有效管理,提升核保核赔建议的准确性。
2.采用批量是式和近实时的方式收集收据,进行数据标签的生成。可以快速的反馈成果至平台操作人员处,提高核保核赔工作的时效性。
3.采用aws用户角色认证以及系统登陆认证,多方面综合保护用户数据安全。
4.采用脱敏脱密系统,进行数据处理,保证数据资产的安全可靠使用。
参考文献
- 模型可解释性在保险理赔反欺诈中的实践
- 商业健康险在医疗健康领域的定位及平台化实施路径
这篇关于《大数据+AI在大健康领域中最佳实践前瞻》---- 智能服务在保险业务中的应用探讨的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!