1.本发明涉及一种智能医疗高并发和大数据量下的高效处理方法及系统，属于医疗软件方法技术领域。
背景技术：
2.根据数据显示，截止到2021年年末，我国60岁及以上人口26736万人，占全国人口的18.9％，其中65岁及以上人口20056万人，占全国人口的14.2％。按国际标准，中国已经进入深度老龄化社会。人口老龄化的社会结构促使了中国互联网医院的飞速发展。随着我国医疗保险工作不断深化，大企业的医保工作纳入和医保定点数据的急剧增加，使得医保网络系统日益庞大，医保交易数据量也持续增加。互联网医院的交易量日益剧增，尤其是线上的医保交易量。但目前已建的医保网络系统所使用的医保交易接口仅适用于医院线下低并发流量的交易，无法安全、稳定地处理线上高并发、大流量的医保交易请求。
技术实现要素：
3.本发明的目的是：保证线上高并发、大流量的医保结算工作的顺利进行，并且保障数据安全和交易稳定。
4.为了达到上述目的，本发明的一个技术方案是提供了一种传统医保支付满足在互联网高并发下的处理方法，其特征在于，包括以下步骤：
5.步骤1、患者使用医保卡信息向互联网医院平台发起就医预约请求，互联网医院平台接收该就医预约请求后，向患者反馈是否预约成功，仅当患者预约成功后，进入步骤2；
6.步骤2、获取待登记建档的患者信息，该患者信息至少包括医保卡信息，将待登记建档的患者信息写进建档队列；
7.步骤3、系统后台基于轮询任务读取建档队列，从建档队列中取出患者信息进行建档；建档完毕后，将已完成建档的患者信息从建档队列中删除；
8.步骤4、若当前患者信息完成建档，则向对应的患者反馈建档完成通知；患者仅在收到建档完成通知后，才能进入步骤5；
9.步骤5、收到建档完成通知的患者通过已建的医保交易接口向已建的医保网络系统发起医保试算请求；医保交易接口每分钟仅能够接收n条医保试算请求，医保试算请求被接收的用户为未被限流的用户，医保试算请求未被接收的用户为被限流的用户；未被限流的用户，完成医保试算后进入步骤6；被限流的用户，则需要等待发起再次试算；
10.步骤6、试算成功的患者通过已建的医保交易接口向已建的医保网络系统发起医保结算请求和/或自费结算请求，等待相应结算机构完成对自费部分的结算并通知医保网络同步成功后，整个医保交易流程结束。
11.优选地，步骤2中所述建档队列为先进先出队列。
12.优选地，步骤3中，轮询任务每次从建档队列中取出m条患者信息分别进行建档，m》n。
13.本发明的另一个技术方案是提供了一种传统医保支付满足在互联网高并发下的处理系统，其特征在于，包括：
14.建档队列模块，向互联网医院平台发起就医预约请求且预约成功的患者的患者信息放入建档队列模块中；
15.轮询任务模块，用于从建档队列模块中获取患者信息；
16.建档模块，用于基于轮询任务模块获得的患者信息进行建档，建档完成后，向患者反馈相关信息；
17.医保试算模块，基于收到建档完成通知的患者通过已建的医保交易接口发送的医保试算请求进行医保试算，医保试算模块通过医保交易接口每分钟仅能够接收n条医保试算请求，医保试算请求被接收的用户为未被限流的用户，医保试算请求未被接收的用户未被限流的用户；未被限流的用户，完成医保试算后进入医保结算模块，被限流的用户，则需要等待发起再次试算；
18.医保结算模块，接受试算成功的患者通过已建的医保交易接口向已建的医保网络系统发起的医保结算请求和/或自费结算请求，完成相关费用的结算并通知医保网络同步成功。
19.优选地，所述该患者信息至少包括医保卡信息。
20.优选地，所述轮询任务模块一次从所述建档队列模块中获取m条患者信息。
21.本发明在不改变传统医保交易接口的情况下，能够保证医保交易在高并发、大流量时依旧有序进行。本发明所公开的技术方案通过对医保结算流程升级和试算规则的建立，能够减少患者医保结算的等待时间，保证线上医保交易快速稳定地进行。
附图说明
22.图1示意了线上医保交易队列处理基本结构；
23.图2示意了本发明的处理流程。
具体实施方式
24.下面结合具体实施例，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。
25.本发明公开的一种传统医保支付满足在互联网高并发下的处理方法基于如图1所示的队列技术，解决医保交易的高并发问题，具体包括以下步骤：
26.步骤1、患者使用医保卡信息向互联网医院平台发起就医预约请求，互联网医院平台接收该就医预约请求后，向患者反馈是否预约成功，若患者预约成功，则进入步骤2，若预约失败，则退出本方法。
27.步骤2、获取待登记建档的患者信息，该患者信息至少包括医保卡信息，将待登记建档的患者信息写进建档队列。本实施例中，建档队列为先进先出队列。
28.步骤3、系统后台基于轮询任务读取建档队列，从建档队列中取出目前最先进入的患者信息进行建档，建档完毕后，将已完成建档的患者信息从建档队列中删除。本实施例
中，该轮询任务每次从建档队列中取出200条患者信息分别进行建档，轮询任务每次处理的患者信息的数量可以根据实际业务场景做配置调整，本发明不做特殊规定。
29.步骤4、若当前患者信息完成建档，则向对应的患者反馈建档完成通知。患者仅在收到建档完成通知后，才能进入步骤5。
30.步骤5、收到建档完成通知的患者通过已建的医保交易接口向已建的医保网络系统发起医保试算请求。医保交易接口每分钟仅可接收100条医保试算请求，以起到限流作用。未被限流的用户，完成医保试算后进入步骤6；被限流的用户，则需要等待发起再次试算。
31.本实施例中，设置的医保试算规则为每分钟可试算100条，本领域技术人员也可以根据实际业务场景对每分钟可试算的数据量做配置调整，本发明不做特殊规定。
32.步骤6、试算成功的患者即可通过已建的医保交易接口向已建的医保网络系统发起医保结算请求和/或自费结算请求，等待相应结算机构完成对自费部分的结算并通知医保网络同步成功后，整个医保交易流程结束。
技术特征：
1.一种传统医保支付满足在互联网高并发下的处理方法，其特征在于，包括以下步骤：步骤1、患者使用医保卡信息向互联网医院平台发起就医预约请求，互联网医院平台接收该就医预约请求后，向患者反馈是否预约成功，仅当患者预约成功后，进入步骤2；步骤2、获取待登记建档的患者信息，该患者信息至少包括医保卡信息，将待登记建档的患者信息写进建档队列；步骤3、系统后台基于轮询任务读取建档队列，从建档队列中取出患者信息进行建档；建档完毕后，将已完成建档的患者信息从建档队列中删除；步骤4、若当前患者信息完成建档，则向对应的患者反馈建档完成通知；患者仅在收到建档完成通知后，才能进入步骤5；步骤5、收到建档完成通知的患者通过已建的医保交易接口向已建的医保网络系统发起医保试算请求；医保交易接口每分钟仅能够接收n条医保试算请求，医保试算请求被接收的用户为未被限流的用户，医保试算请求未被接收的用户为被限流的用户；未被限流的用户，完成医保试算后进入步骤6；被限流的用户，则需要等待发起再次试算；步骤6、试算成功的患者通过已建的医保交易接口向已建的医保网络系统发起医保结算请求和/或自费结算请求，等待相应结算机构完成对自费部分的结算并通知医保网络同步成功后，整个医保交易流程结束。2.如权利要求1所述的一种传统医保支付满足在互联网高并发下的处理方法，其特征在于，步骤2中所述建档队列为先进先出队列。3.如权利要求1所述的一种传统医保支付满足在互联网高并发下的处理方法，其特征在于，步骤3中，轮询任务每次从建档队列中取出m条患者信息分别进行建档，m>n。4.一种传统医保支付满足在互联网高并发下的处理系统，其特征在于，包括：建档队列模块，向互联网医院平台发起就医预约请求且预约成功的患者的患者信息放入建档队列模块中；轮询任务模块，用于从建档队列模块中获取患者信息；建档模块，用于基于轮询任务模块获得的患者信息进行建档，建档完成后，向患者反馈相关信息；医保试算模块，基于收到建档完成通知的患者通过已建的医保交易接口发送的医保试算请求进行医保试算，医保试算模块通过医保交易接口每分钟仅能够接收n条医保试算请求，医保试算请求被接收的用户为未被限流的用户，医保试算请求未被接收的用户未被限流的用户；未被限流的用户，完成医保试算后进入医保结算模块，被限流的用户，则需要等待发起再次试算；医保结算模块，接受试算成功的患者通过已建的医保交易接口向已建的医保网络系统发起的医保结算请求和/或自费结算请求，完成相关费用的结算并通知医保网络同步成功。5.如权利要求4所述的一种传统医保支付满足在互联网高并发下的处理系统，其特征在于，所述该患者信息至少包括医保卡信息。6.如权利要求4所述的一种传统医保支付满足在互联网高并发下的处理系统，其特征在于，所述轮询任务模块一次从所述建档队列模块中获取m条患者信息。
技术总结
本发明的一个技术方案是公开了一种传统医保支付满足在互联网高并发下的处理方法。本发明的另一个技术方案是提供了一种传统医保支付满足在互联网高并发下的处理系统，其特征在于，包括：建档队列模块；轮询任务模块；建档模块；医保试算模块；医保结算模块。本发明在不改变传统医保交易接口的情况下，能够保证医保交易在高并发、大流量时依旧有序进行。本发明所公开的技术方案通过对医保结算流程升级和试算规则的建立，能够减少患者医保结算的等待时间，保证线上医保交易快速稳定地进行。保证线上医保交易快速稳定地进行。保证线上医保交易快速稳定地进行。
技术研发人员：赵丹丹 冯骏 潘铮 曹剑峰 魏馨 金贵元 洪斌 张玮 陈诚 饶斐文 汤庆伟 吴宏 夏寒 李玲玲 蒋会军
受保护的技术使用者：健康云（上海）数字科技有限公司 万达信息股份有限公司
技术研发日：2022.07.26
技术公布日：2022/12/5
再多了解一些
本文用于创业者技术爱好者查询，仅供学习研究，如用于商业用途，请联系技术所有人。
