大批量理赔数据处理方法、装置、计算机设备及存储介质与流程

1.本技术涉及数据处理技术领域，特别涉及一种大批量理赔数据处理方法、装置、计算机设备及存储介质。


背景技术：

2.保险从诞生到现在，已经成为现代经济社会风险管理的重要手段，成为现代金融体系和社会保障体系的重要组成部分。作为一种投保方式，各大保险公司会与海内外各大医疗机构进行直接或间接合作并进行直接理赔，即当客户购买保险后，会在与保险公司合作的医疗机构内就医，履行条款中的门诊责任、住院责任权益，进而通过医疗机构针对该客户向保险公司进行直接理赔(即e结算)。
3.目前，医疗机构的直接理赔方式是由人工逐条填报客户的就医理赔数据，因数据量较大，逐条填报不仅效率慢、耗时长，还容易出错。到了理赔阶段，会由于数据不全、错误等，导致反复沟通，沟通成本高，且理赔时效低下，影响客户体验。同时，现有的e结算并没有使用防重等校验，偶尔会因网络或误操作等问题，造成数据的重复出现，从而造成重复理赔的可能。此外，现有e结算只能是功能上实现了直接理赔，并没有提升客户理赔的效率、准确性和稳定性。


技术实现要素：

4.本技术提供了一种大批量理赔数据处理方法、装置、计算机设备及存储介质，旨在解决现有的e结算理赔方式存在的理赔时效低下以及没有使用防重等校验会导致重复理赔等技术问题。
5.为解决上述技术问题，本技术采用的技术方案为：
6.一种大批量理赔数据处理方法，包括：
7.制作用于录入理赔数据的excel模板，将所述excel模板上传至e结算系统中；
8.当医疗机构通过所述e结算系统提交理赔申请时，将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件，并将所述excel文件提交至保险公司的云储存平台中；
9.当所述保险公司提交理赔数据时，从所述云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验，并将校验成功的理赔数据提交至理赔系统，所述理赔系统根据理赔数据对所述待理赔案件执行案件理赔。
10.本技术实施例采取的技术方案还包括：所述excel模板包括总表模板和明细模板，所述总表模板用于录入待理赔案件的理赔数据，所述理赔数据至少包括案件号、病例号、患者姓名、生日、案件类型、收费项目及医院信息，所述明细模板用于录入所述总表模板中各项理赔数据的具体明细。
11.本技术实施例采取的技术方案还包括：所述将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件具体为：
12.采用dmz的bucket将所述excel文件上传至保险公司的云储存平台中，并将云存储的key返回给保险公司。
13.本技术实施例采取的技术方案还包括：所述从云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验之前还包括：
14.通过云存储的key从云储存平台中拉取excel文件，对拉取的excel文件进行解析，并判断解析过程中是否存在异常，如果存在异常，则打印日志、将异常信息记录到数据表，并发出异常提示；如果不存在异常，则将解析后的理赔数据写入数据库中。
15.本技术实施例采取的技术方案还包括：所述从云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验，并将校验成功的理赔数据提交至理赔系统具体为：
16.基于juc对所述解析后的理赔数据进行数据校验，并判断校验是否成功，如果校验没有成功，将校验失败的理赔数据以及失败原因归为问题件集合，将所述数据库中该理赔数据对应的案件状态更新为校验失败，并在同一批次中所有理赔数据全部完成校验后，归口问题件集合，并统一向所述医疗机构返回问题邮件；如果校验成功，将所述校验成功的理赔数据提交至理赔系统。
17.本技术实施例采取的技术方案还包括：所述基于juc对所述解析后的理赔数据进行数据校验具体为：
18.将所述解析后的理赔数据存入mysql数据库中，并利用智能校验引擎分别对所述理赔数据进行基础数据校验、重复理赔校验以及保单信息校验；其中，所述基础数据校验包括总表校验以及明细校验，所述基础数据校验的校验项目包括患者生日及账单号是否缺失、账单号是否超长及总金额格式是否错误，所述重复理赔校验的校验项目包括账单是否重复检验、账单是否已提交理赔，所述保单信息校验的校验项目包括保单是否失效、是否退保、保险责任是否使用完；
19.如果所有的校验项目都校验通过，则认为校验成功，如果所有校验项目中至少有一项校验不通过，则认为校验失败。
20.本技术实施例采取的技术方案还包括：所述将校验成功的理赔数据提交至理赔系统，所述理赔系统根据理赔数据对所述待理赔案件执行案件理赔具体为：
21.判断理赔数据是否提交成功，如果提交失败，将提交失败的理赔数据以及失败原因归为问题件集合，将所述数据库中该理赔数据对应的案件状态更新为提交失败，并在同一批次中所有理赔数据全部执行提交后，归口问题件集合，并统一向医疗机构返回问题邮件；如果提交成功，将所述数据库中的案件状态更新为提交成功，根据所述理赔数据执行案件理赔，并通过mq将案件理赔进度同步至数据库。
22.本技术实施例采取的另一技术方案为：一种大批量理赔数据处理装置，包括：
23.模板制作模块：用于制作用于录入理赔数据的excel模板，将所述excel模板上传至e结算系统中；
24.数据提交模块：用于在医疗机构通过所述e结算系统提交理赔申请时，将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件，并将所述excel文件提交至保险公司的云储存平台中；
25.理赔校验模块：用于从所述云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验，并将校验成功的理赔数据提交至理赔系统，所述理赔系统根据理赔数
据对所述待理赔案件执行案件理赔。
26.本技术实施例采取的又一技术方案为：一种计算机设备，所述计算机设备包括：
27.存储有可执行程序指令的存储器；
28.与所述存储器连接的处理器；
29.所述处理器调用所述存储器中存储的所述可执行程序指令，执行如上所述的大批量理赔数据处理方法。
30.本技术实施例采取的又一技术方案为：一种存储介质，存储有处理器可执行的程序指令，所述程序指令用于执行上述的大批量理赔数据处理方法。
31.本技术实施例的大批量理赔数据处理方法、装置、计算机设备及存储介质通过制定excel模板，医疗机构通过e结算提交案件理赔申请时，采用excel模板的方式将理赔数据批量上传至云储存平台，理赔系统对上传数据进行批量解析后，基于juc对理赔数据进行数据校验，根据校验结果进行案件理赔，从而极大的提高了单次作业吞吐量，大大提高了理赔效率，并节省了人力成本。本技术实施例基于juc并发与iobs云存储技术批量处理医疗机构上传的理赔数据，并采用智能校验引擎对理赔数据进行数据校验，提高了数据准确性以及理赔的效率，实现了大批量高效、准确、稳定的案件理赔，有利于提高客户体验。
附图说明
32.图1是本技术第一实施例的大批量理赔数据处理方法的流程示意图；
33.图2是本技术第二实施例的大批量理赔数据处理方法的流程示意图；
34.图3为本技术实施例基于juc对理赔数据进行数据校验的校验流程图；
35.图4为本技术实施例的分布式锁实现过程示意图；
36.图5为本技术实施例的分布式锁解锁示意图；
37.图6为本技术实施例中理赔系统的理赔流程图；
38.图7是本技术实施例大批量理赔数据处理装置的结构示意图；
39.图8是本技术实施例的计算机设备结构示意图；
40.图9是本技术实施例的存储介质结构示意图。
具体实施方式
41.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术的一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
42.本技术中的术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括至少一个该特征。本技术的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。本技术实施例中所有方向性指示(诸如上、下、左、右、前、后
……
)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含
了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
43.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
44.请参阅图1，是本技术第一实施例的大批量理赔数据处理方法的流程示意图。本技术第一实施例的大批量理赔数据处理方法包括以下步骤：
45.s100：制作用于录入理赔数据的excel模板，将所述excel模板上传至e结算系统中；
46.s110：当医疗机构通过所述e结算系统提交理赔申请时，将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件，并将所述excel文件提交至保险公司的云储存平台中；
47.s120：当所述保险公司提交理赔数据时，从所述云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验，并将校验成功的理赔数据提交至理赔系统，所述理赔系统根据理赔数据对所述待理赔案件执行案件理赔。
48.基于上述，本技术第一实施例的大批量理赔数据处理方法通过制定excel模板，医疗机构通过e结算提交案件理赔申请时，采用excel模板的方式将理赔数据批量上传至云储存平台，理赔系统对上传数据进行批量解析后，基于juc对理赔数据进行数据校验，根据校验结果进行案件理赔，从而极大的提高了单次作业吞吐量，大大提高了理赔效率，并节省了人力成本。
49.请参阅图2，是本技术第二实施例的大批量理赔数据处理方法的流程示意图。本技术第二实施例的大批量理赔数据处理方法包括以下步骤：
50.s200：制作用于录入理赔数据的excel模板，将excel模板上传至e结算系统中；
51.本步骤中，excel模板包括总表模板和明细模板，excel模板的表格格式以及内容可根据实际应用场景进行设定，本技术实施例中，总表模板用于录入待理赔案件的理赔数据，所述理赔数据至少包括案件号、病例号、患者姓名、生日、案件类型、收费项目及医院信息等，明细模板用于录入总表模板中各项理赔数据的具体明细。
52.s210：当医疗机构通过e结算系统提交理赔申请时，将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件，并将excel文件提交至保险公司的云储存平台中；
53.本步骤中，生成的excel文件包括总表excel文件以及明细excel文件，其中，总表excel文件中录入的理赔数据包括但不限于案件号、病例号、患者姓名、生日、分单号、账单号、案件类型、就诊时间、科室、数量、收费项目、收费价格、折扣价格、医院信息、诊断、城市等数据，明细excel文件中包括总表excel文件中各项数据的具体明细。在提交excel文件时，由于是外网，可采用dmz(demilitarized zone)的bucket(存储空间)将excel文件一键上传至保险公司的云储存平台(例如iobs)中，并将云存储的key返回给保险公司，同时将excel文件存储在本地作为医疗机构的留底。
54.s220：通过云存储的key从云储存平台中拉取excel文件，对拉取的excel文件进行解析，并判断解析过程中是否存在异常，如果存在异常，执行s230；否则，执行s240；
55.本步骤中，当提交理赔数据时，首先从云储存平台中拉取excel文件，并获取excel文件的inputstream(字节输入流)格式，然后利用alibaba的easyexcel采用一行一行的解析模式对excel文件进行批量解析，并将解析后的理赔数据写入内存中。解析后的理赔数据包括但不限于总表excel文件中的案件号、病例号、患者姓名、生日、分单号、账单号、案件类型、就诊时间、科室、数量、收费项目、收费价格、折扣价格、医院信息等、诊断、城市等案件信息，以及明细excel文件中的总表明细数据。可以理解，批量解析的数据条数可根据实际应用场景进行设定，优选地，本技术实施例设定每200条理赔数据为一个解析批次，即每次解析200条理赔数据。
56.s230：打印日志、将异常信息记录到数据表，并发出异常提示，告知存在异常的数据位置以及异常原因；
57.本步骤中，由于是针对理赔数据处理进行前置阶段，正常情况下不会出现异常，仅见的异常为：理赔数据存在格式错误。本技术实施例通过在前置阶段对理赔数据进行异常判断，如果存在异常则及时退回至医疗机构，便于医疗机构及时修改，避免后续理赔阶段由于数据异常导致的复审及反复沟通，有利于提高理赔效率。
58.s240：将解析后的理赔数据写入内存中，基于juc对解析后的理赔数据进行数据校验，并判断校验是否成功，如果校验没有成功，执行s250；反之，如果校验成功，执行s260；
59.本步骤中，juc(java并发操作)即为java.util.concurrent工具包的简称，本技术实施采用juc中的自定义线程池对解析后的理赔数据进行线程并发处理，线程池参数如下表1所示：
60.表1：线程池参数
[0061][0062][0063]
其中，对于4核8g的服务处理器，核心线程数为4个，其中最高效线程数为2n，由于服务中还有其他作业，不能全部资源占满，因此最大线程数为8。线程存活时间为30秒，队列为1000个，异常拒绝策略为abortpolicy策略，即过载出现异常后，采取抛出策略，将异常数据单独落表，并发邮件提醒进行人工介入。
[0064]
具体的，如图3所示，为本技术实施例基于juc对理赔数据进行数据校验的校验流程图，其具体校验过程包括：首先将解析后的理赔数据存入mysql数据库中，然后进入智能校验引擎，分别对理赔数据进行基础数据校验、重复理赔校验以及保单信息校验；其中，基
础数据校验包括总表校验以及明细校验，基础数据校验的校验项目包括但不限于患者生日及账单号是否缺失、账单号是否超长及总金额格式是否错误等，重复理赔校验的校验项目包括但不限于账单是否重复检验、账单是否已提交理赔等，保单信息校验的校验项目包括但不限于保单是否失效、是否退保、保险责任是否使用完等。如果所有的校验项目都校验通过，则认为校验成功，将该理赔数据提交至理赔系统；如果所有校验项目中至少有一项校验不通过，则认为校验失败，将该理赔数据对应的案件状态更新为校验失败。
[0065]
基于上述，本技术实施例通过智能校验引擎进行数据校验，对数据不全、数据错误或保单失效等理赔数据进行拦截，从而减少了理赔阶段大量的复审及沟通工作，并避免产生不合规的理赔，实现了理赔工作的降本增效。
[0066]
s250:将校验/提交失败的理赔数据以及失败原因等归为问题件集合，将数据库中该理赔数据对应的案件状态更新为校验/提交失败，并在同一批次中所有理赔数据全部执行校验/提交后，归口问题件集合，并统一向医疗机构返回问题邮件；
[0067]
本步骤中，问题件集合使用的juc的copyonwritearraylist集类型，保证其线程安全，并运用juc包中的计数器countdownlatch中的await函数，保证在全部任务执行完成后，统一向医疗机构返回问题邮件，告知医疗机构哪些数据存在问题，便于医疗机构及时修改数据并重新上传。
[0068]
s260：将校验成功的理赔数据提交至理赔系统，并判断理赔数据是否提交成功，如果提交失败，重新执行s250；如果提交成功，执行s270；
[0069]
本步骤中，在理赔提交任务中采用分布式锁防止重复提交作业，并防止由于网络或误操作等导致的幂问题，从而保证了接口稳定性。如图4所示，为本技术实施例的分布式锁实现过程示意图，具体为：
[0070]
1.基于切面、注解挂靠接口；
[0071]
2.采用redission分布式锁，key采取token 方法名 参数的hashcode，其中的redis的数据类型为hash类型；
[0072]
3.采用trylock看门狗机制，任务不处理完，则每10秒进行一次续期，直到任务处理结束，任务结束30秒后解锁，当有其他线程幂等操作时，后续线程会被拦截；
[0073]
4.采用key放入threadlocal，无异常时正常解锁，当异常时，在@afterthrowing中获取该线程的threadlocal中的key,针对key进行解锁；具体如图5所示，为本技术实施例的分布式锁解锁示意图。
[0074]
基于上述，本技术实施例采用幂等防重技术，使得业务系统更加稳健高效，避免出现数据重复，同时避免了由于网络抖动、人抖等误操作产生的幂等重复作业问题。
[0075]
s270：将数据库中的案件状态更新为提交成功；
[0076]
本技术实施例中，理赔提交如果失败则也归入问题件集合，更新数据库为提交失败，如果提交成功则更新数据库状态为提交成功。即不论成功或失败都对数据库进行更新，以保证数据结果的可见性，从而更好的进行业务处理。
[0077]
s280：理赔系统接收提交的理赔数据，根据理赔数据执行案件理赔，并通过mq将案件理赔进度同步至数据库；
[0078]
本步骤中，理赔系统接收到理赔数据后，会同步理赔案件的进度，便于医疗机构及时获取客户理赔进展情况。具体的，如图6所示，为本技术实施例中理赔系统的理赔流程图，
其具体理赔过程包括：理赔系统接收到解析后的理赔数据后，向mq(message queue，消息队列)发送一个初始案件理赔状态，后续如果案件理赔状态变更也会向mq发送案件理赔状态变更消息；同时，通过e结算监听mq中的案件理赔状态，并根据案件号更新mysql数据库；其中，将案件理赔状态实时更新到mysql数据库，便于医疗机构工作人员及时获取最新的案件状态，了解案件理赔进度。其中，mq采用的是rockectmq,发送方为理赔系统，topic宿主也是理赔系统，tags(标签)为定制的,医疗机构针对约定的topic、tags进行监听；在监听到数据后，首先进行数据检验和数据校验，防止重复消费。然后对数据进行异常处理，捕获异常，打印日志并落日志异常表，防止程序报错；最后消费成功后，更新mysql数据库。
[0079]
基于上述，本技术第二实施例的大批量理赔数据处理方法通过制定excel模板，医疗机构通过e结算提交案件理赔申请时，采用excel模板的方式将理赔数据批量上传至云储存平台，理赔系统对上传数据进行批量解析后，基于juc对理赔数据进行数据校验，根据校验结果进行案件理赔，从而极大的提高了单次作业吞吐量，大大提高了理赔效率，并节省了人力成本。本技术实施例基于juc并发与iobs云存储技术批量处理医疗机构上传的理赔数据，并采用智能校验引擎对理赔数据进行数据校验，提高了数据准确性以及理赔的效率，并采用分布式锁提高了系统稳定性，实现了大批量高效、准确、稳定的案件理赔，有利于提高客户体验。
[0080]
在一个可选的实施方式中，还可以：将所述的大批量理赔数据处理方法的结果上传至区块链中。
[0081]
具体地，基于所述的大批量理赔数据处理方法的结果得到对应的摘要信息，具体来说，摘要信息由所述的大批量理赔数据处理方法的结果进行散列处理得到，比如利用sha256s算法处理得到。将摘要信息上传至区块链可保证其安全性和对用户的公正透明性。用户可以从区块链中下载得该摘要信息，以便查证所述的大批量理赔数据处理方法的结果是否被篡改。本示例所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
[0082]
请参阅图7，是本技术实施例大批量理赔数据处理装置的结构示意图。本技术实施例大批量理赔数据处理装置40包括：
[0083]
模板制作模块41：用于制作用于录入理赔数据的excel模板，将所述excel模板上传至e结算系统中；其中，excel模板包括总表模板和明细模板，excel模板的表格格式以及内容可根据实际应用场景进行设定，本技术实施例中，总表模板用于录入待理赔案件的理赔数据，所述理赔数据至少包括案件号、病例号、患者姓名、生日、案件类型、收费项目及医院信息等，明细模板用于录入总表模板中各项理赔数据的具体明细。
[0084]
数据提交模块42：用于在医疗机构通过所述e结算系统提交理赔申请时，将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件，并将所述excel文件提交至保险公司的云储存平台中；其中，生成的excel文件包括总表excel文件以及明细excel文件，其中，总表excel文件中录入的理赔数据包括但不限于案件号、病例号、患者姓名、生日、分单号、账单号、案件类型、就诊时间、科室、数量、收费项目、收费价格、折扣价
格、医院信息、诊断、城市等数据，明细excel文件中包括总表excel文件中各项数据的具体明细。在提交excel文件时，由于是外网，可采用dmz(demilitarized zone)的bucket(存储空间)将excel文件一键上传至保险公司的云储存平台(例如iobs)中，并将云存储的key返回给保险公司，同时将excel文件存储在本地作为医疗机构的留底。
[0085]
理赔校验模块43：用于从所述云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验，并将校验成功的理赔数据提交至理赔系统，所述理赔系统根据理赔数据对所述待理赔案件执行案件理赔；其中，理赔校验模块43对理赔数据进行校验的校验过程包括：通过云存储的key从云储存平台中拉取excel文件，对拉取的excel文件进行解析，并判断解析过程中是否存在异常，如果存在异常，打印日志、将异常信息记录到数据表，并发出异常提示，告知存在异常的数据位置以及异常原因；否则，将解析后的理赔数据写入内存中，并基于juc对解析后的理赔数据进行数据校验：首先将解析后的理赔数据存入mysql数据库中，然后进入智能校验引擎，分别对理赔数据进行基础数据校验、重复理赔校验以及保单信息校验；其中，基础数据校验包括总表校验以及明细校验，基础数据校验的校验项目包括但不限于患者生日及账单号是否缺失、账单号是否超长及总金额格式是否错误等，重复理赔校验的校验项目包括但不限于账单是否重复检验、账单是否已提交理赔等，保单信息校验的校验项目包括但不限于保单是否失效、是否退保、保险责任是否使用完等。如果所有的校验项目都校验通过，则认为校验成功，将该理赔数据提交至理赔系统；如果所有校验项目中至少有一项校验不通过，则认为校验失败，将该理赔数据对应的案件状态更新为校验失败；如果校验失败，将校验/提交失败的理赔数据以及失败原因等归为问题件集合，将数据库中该理赔数据对应的案件状态更新为校验/提交失败，并在同一批次中所有理赔数据全部执行校验/提交后，归口问题件集合，并统一向医疗机构返回问题邮件；如果校验成功，将数据库中的案件状态更新为提交成功，并将理赔数据提交至理赔系统，理赔系统根据理赔数据执行案件理赔，并通过mq将案件理赔进度同步至数据库。进一步地，理赔系统接收到理赔数据后，会同步理赔案件的进度，便于医疗机构及时获取客户理赔进展情况。具体包括：理赔系统接收到解析后的理赔数据后，向mq(message queue，消息队列)发送一个初始案件理赔状态，后续如果案件理赔状态变更也会向mq发送案件理赔状态变更消息；同时，通过e结算监听mq中的案件理赔状态，并根据案件号更新mysql数据库；其中，将案件理赔状态实时更新到mysql数据库，便于医疗机构工作人员及时获取最新的案件状态，了解案件理赔进度。其中，mq采用的是rockectmq,发送方为理赔系统，topic宿主也是理赔系统，tags(标签)为定制的,医疗机构针对约定的topic、tags进行监听；在监听到数据后，首先进行数据检验和数据校验，防止重复消费。然后对数据进行异常处理，捕获异常，打印日志并落日志异常表，防止程序报错；最后消费成功后，更新mysql数据库。
[0086]
本技术实施例的大批量理赔数据处理装置通过制定excel模板，医疗机构通过e结算提交案件理赔申请时，采用excel模板的方式将理赔数据批量上传至云储存平台，理赔系统对上传数据进行批量解析后，基于juc对理赔数据进行数据校验，根据校验结果进行案件理赔，从而极大的提高了单次作业吞吐量，大大提高了理赔效率，并节省了人力成本。本技术实施例基于juc并发与iobs云存储技术批量处理医疗机构上传的理赔数据，并采用智能校验引擎对理赔数据进行数据校验，提高了数据准确性以及理赔的效率，并采用分布式锁提高了系统稳定性，实现了大批量高效、准确、稳定的案件理赔，有利于提高客户体验。
[0087]
请参阅图8，为本技术实施例的计算机设备结构示意图。该计算机设备50包括：
[0088]
存储有可执行程序指令的存储器51；
[0089]
与存储器51连接的处理器52；
[0090]
处理器52用于调用存储器51中存储的可执行程序指令并执行以下步骤：制作用于录入理赔数据的excel模板，将所述excel模板上传至e结算系统中；当医疗机构通过所述e结算系统提交理赔申请时，将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件，并将所述excel文件提交至保险公司的云储存平台中；当所述保险公司提交理赔数据时，从所述云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验，并将校验成功的理赔数据提交至理赔系统，所述理赔系统根据理赔数据对所述待理赔案件执行案件理赔。
[0091]
其中，处理器52还可以称为cpu(central processing unit，中央处理单元)。处理器52可能是一种集成电路芯片，具有信号的处理能力。处理器52还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0092]
本技术实施例的计算机设备通过制定excel模板，医疗机构通过e结算提交案件理赔申请时，采用excel模板的方式将理赔数据批量上传至云储存平台，理赔系统对上传数据进行批量解析后，基于juc对理赔数据进行数据校验，根据校验结果进行案件理赔，从而极大的提高了单次作业吞吐量，大大提高了理赔效率，并节省了人力成本。
[0093]
请参阅图9，图9为本技术实施例的存储介质的结构示意图。本技术实施例的存储介质存储有能够实现以下步骤的程序指令61：制作用于录入理赔数据的excel模板，将所述excel模板上传至e结算系统中；当医疗机构通过所述e结算系统提交理赔申请时，将待理赔案件的理赔数据批量录入excel模板中，生成录入理赔数据后的excel文件，并将所述excel文件提交至保险公司的云储存平台中；当所述保险公司提交理赔数据时，从所述云储存平台中拉取excel文件，对所述excel文件中的理赔数据进行校验，并将校验成功的理赔数据提交至理赔系统，所述理赔系统根据理赔数据对所述待理赔案件执行案件理赔。其中，该程序指令61可以以软件产品的形式存储在上述存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施方式方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序指令的介质，或者是计算机、服务器、手机、平板等终端设备。其中，服务器可以是独立的服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content delivery network，cdn)、以及大数据和人工智能平台等基础云计算服务的云服务器。
[0094]
本技术实施例的存储介质通过制定excel模板，医疗机构通过e结算提交案件理赔申请时，采用excel模板的方式将理赔数据批量上传至云储存平台，理赔系统对上传数据进行批量解析后，基于juc对理赔数据进行数据校验，根据校验结果进行案件理赔，从而极大的提高了单次作业吞吐量，大大提高了理赔效率，并节省了人力成本。
[0095]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以
通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0096]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。以上仅为本技术的实施方式，并非因此限制本技术的专利范围，凡是利用本技术说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本技术的专利保护范围内。