CN111598709B - 医保数据处理系统、方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种医保数据处理系统、方法、装置、设备及存储介质，该系统中，客户端在第一用户界面上显示医保图形码，医保图形码携带签约有信用结算的医保电子凭证；平台服务器接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带医保电子凭证和信用结算订单，调用信用机构对应的第二服务器对信用结算订单进行结算，得到第一结算结果；客户端在第二用户界面上显示第一和第二结算结果，第二结算结果是采用医保结算的结果。用户可以通过一次扫码，由上述医保数据处理系统完成医保项目和自费项目的结算，无需到窗口排队缴费，也无需在客户端上执行繁复的费用支付操作，提高了用户的就医效率。

Description

医保数据处理系统、方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种医保数据处理系统、方法、装置、设备及存储介质。

背景技术

社会医疗保险(即医保)是国家和社会为向保障范围内的劳动者提供患病时基本医疗需求保障而建立的社会保险制度。用户在就医过程中可以通过出示医保卡对医疗账单中允许报销费用进行支付。

示例性的，用户经过挂号、就诊、窗口排队缴费之后进行排队检查或者取药。在上述就诊过程中用户需要出示医保卡，由医生在医保凭证下开具检查单或者药单；在上述窗口排队缴费过程中，若检查单或者药单中存在自费项目，用户还需要出示医保卡支付报销费用，之后进行自费项目的费用支付。

上述用户使用医保卡就医的过程，其步骤繁琐，导致用户的就医效率很低。

发明内容

本申请实施例提供了一种医保数据处理系统、方法、装置、设备及存储介质，可以采用医保图形码在就医过程中高效的完成各项费用支付。所述技术方案如下：

根据本申请的一个方面，提供了一种医保数据处理系统，该系统包括：客户端和平台服务器；

客户端，用于在第一用户界面上显示医保图形码，医保图形码携带有医保电子凭证，医保电子凭证签约有信用结算；

平台服务器，用于接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单；

平台服务器，用于调用信用机构对应的第二服务器对信用结算订单进行结算处理，将第二服务器的第一结算结果发送至第一服务器和客户端；

客户端，用于在第二用户界面上显示结算结果，结算结果包括第一结算结果和第二结算结果，第二结算结果是由第三服务器发送至第一服务器的医保电子凭证对应的医保结算的结果。

根据本申请的另一方面，提供了一种医保数据处理方法，该方法应用于客户端中，该方法包括：

在第一用户界面上显示医保图形码，医保图形码携带有医保电子凭证，医保电子凭证签约有信用结算；

在第二用户界面上显示结算结果，结算结果包括第一结算结果和第二结算结果；第一结算结果是由平台服务器接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，调用信用机构对应的第二服务器对信用结算订单进行结算处理，之后返回第一服务器和客户端的，信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单；第二结算结果是由第三服务器发送至第一服务器的医保电子凭证对应的医保结算的结果。

根据本申请的另一方面，提供了一种医保数据处理方法，该方法应用于平台服务器中，该方法包括：

接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，医保电子凭证是从客户端上显示的医保图形码中获取得到的，医保电子凭证签约有信用结算，信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单；

调用信用机构对应的第二服务器对信用结算订单进行结算处理；

将第二服务器的第一结算结果发送至第一服务器和客户端。

根据本申请的另一方面，提供了一种医保数据处理装置，该装置包括：

显示模块，用于在第一用户界面上显示医保图形码，医保图形码携带有医保电子凭证，医保电子凭证签约有信用结算；

显示模块，还用于在第二用户界面上显示结算结果，结算结果包括第一结算结果和第二结算结果；第一结算结果是由平台服务器接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，调用信用机构对应的第二服务器对信用结算订单进行结算处理，之后返回第一服务器和客户端的，信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单；第二结算结果是由第三服务器发送至第一服务器的医保电子凭证对应的医保结算的结果。

根据本申请的另一方面，提供了一种医保数据处理装置，该装置包括：

接收模块，用于接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，医保电子凭证是从客户端上显示的医保图形码中获取得到的，医保电子凭证签约有信用结算，信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单；

调用模块，用于调用信用机构对应的第二服务器对信用结算订单进行结算处理；

发送模块，用于将第二服务器的第一结算结果发送至第一服务器和客户端。

根据本申请的另一方面，提供了一种电子设备，上述电子设备包括处理器和存储器，上述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，上述至少一条指令、至少一段程序、代码集或指令集由上述处理器加载并执行以实现如上一个方面所述的医保数据处理方法，或者，如上另一个方面所述的医保数据处理方法。

根据本申请的另一方面，提供了一种计算机可读存储介质，上述计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，上述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如上一个方面所述的医保数据处理方法，或者，如上另一个方面所述的医保数据处理方法。

根据本申请的另一方面，提供了一种计算机程序产品或计算机程序，上述计算机程序产品或计算机程序包括计算机指令，上述计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取上述计算机指令，处理器执行上述计算机指令，使得上述电子设备执行如上一个方面所述的医保数据处理方法，或者，如上另一个方面所述的医保数据处理方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

在本申请提供的医保数据处理系统中，用户可以通过在客户端上展示医保图形码，在就医开始即由医疗机构通过扫描获取医保图形码中携带的医保电子凭证，在用户就医完成之后，由医疗机构对应的第一服务器向客户端对应的平台服务器发送信用结算下单请求，该信用结算下单请求携带了医保电子凭证和信用结算订单，由于医保电子凭证签约有信用结算，因此，平台服务器可以调用信用机构对应的第二服务器对信用结算订单进行结算处理，也即对用户就医的自费项目进行费用支付；且由第一服务器调用第三服务器进行医保结算。所以，在就医过程中，用户可以通过一次扫码，由医保数据处理系统完成医保项目和自费项目的结算，无需到窗口排队缴费，也无需在客户端上执行繁复的费用支付操作，以分别对医保项目和自费项目进行缴费，提高了用户的就医效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一个示例性实施例提供的医保数据处理系统的结构框图；

图2是本申请另一个示例性实施例提供的医保数据处理系统的结构框图；

图3是本申请一个示例性实施例提供的医保数据处理方法的流程图；

图4是本申请一个示例性实施例提供的信用结算的界面示意图；

图5是本申请另一个示例性实施例提供的信用结算的界面示意图；

图6是本申请一个示例性实施例提供的信用结算的签约方法的流程图；

图7是本申请另一个示例性实施例提供的信用结算的界面示意图；

图8是本申请另一个示例性实施例提供的信用结算的界面示意图；

图9是本申请一个示例性实施例提供的信用结算的授权方法的流程图；

图10是本申请另一个示例性实施例提供的信用结算的界面示意图；

图11是本申请另一个示例性实施例提供的信用结算的界面示意图；

图12是本申请另一个示例性实施例提供的信用结算的界面示意图；

图13是本申请另一个示例性实施例提供的信用结算的界面示意图；

图14是本申请一个示例性实施例提供的信用结算的解约方法的流程图；

图15是本申请另一个示例性实施例提供的信用结算的界面示意图；

图16是本申请一个示例性实施例提供的信用结算的解约/签约方法的流程图；

图17是本申请另一个示例性实施例提供的医保数据处理方法的流程图；

图18是本申请一个示例性实施例提供的医保数据处理装置的框图；

图19是本申请另一个示例性实施例提供的医保数据处理装置的框图；

图20是本申请一个示例性实施例提供的服务器的结构框图；

图21是本申请一个示例性实施例提供的终端的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

对本申请中涉及的名词进行解释如下；

医保电子凭证：由国家医保机构统一签发，是基于医保基础信息库为全体参保人员生成的医保身份识别电子介质。医保电子凭证通过实名/实人认证技术，采用加密算法形成的电子标识，具有安全可靠、认证唯一的重要特点。参保人员可以通过医保电子凭证享受各类在线医疗保障服务，包括医保业务办理、医保账户查询、医保就诊和药单支付等。

在线医保结算：在医保机构以及医疗机构之外的第三方机构的客户端上绑定医保电子凭证，以采用第三方机构提供的在线结算服务来实现用户就医时的医保结算与信用结算。示例性的，基于公众号或者小程序生态，通过医保电子凭证打通医疗机构的医保结算功能与信用结算功能，同时支持用户不需要医保卡即可在线医保结算的场景、以及在线信用结算的场景。

图1示出了本申请一个示例性实施例提供医保数据处理系统100的结构框图。平台服务器110上存储有用户信息，该用户信息是经过实名认证的真实信息。示例性的，用户信息包括医保电子凭证111和实名112。可选地，用户还在平台服务器上开通了在线医保结算113与信用结算114。

平台服务器110与医疗机构对应的第一服务器120之间通过有线或者无线网络进行连接。示例性的，上述医疗机构可以包括医院、社区康复中心、药店等。在第一服务器120中设置有信用就医功能121，该信用就医功能121支持用户在就医过程中通过平台服务器110实现在线医保结算113与信用结算114。示例性的，第一服务器110上承载有医疗系统，医护人员通过上述医疗系统为用户提供挂号服务、缴费服务、开具检查单服务、以及开具药单服务等；该医疗系统中设置有上述信用就医功能121，在医疗人员为用户开具检查单或者药单之后，该医疗系统向平台服务器请求对检查单与药单进行信用结算，由平台服务器实现对检查单或者药单的信用结算之后，将结算结果返回至医疗系统，实现信用就医功能121。

可选地，医疗机构对应的第一服务器120上设置有信用对账功能，即将第一服务器120中通过平台服务器110进行信用结算订单结算的账单、与平台服务器110中对第一服务器120发送的信用结算订单结算的账单进行一一核对。

平台服务器110与信用机构对应的第二服务器130之间通过有线或者无线网络进行连接。在第二服务器130上提供了免密支付通道131，可选地，若医保电子凭证111签约有信用结算114，则平台服务器110可以调用第二服务器130提供的免密支付通道131对信用结算订单进行免密支付。示例性的，上述信用结算订单可以包括挂号单、检查单和药单对应的至少一种缴费订单。可选地，在第二服务器130中为信用结算订单设置有专项额度132，即第二服务器130中设置了专用于信用结算订单支付的一项资金。示例性的，一个用户每个月内可以通过信用结算完成10万元的订单支付；或者，一个用户通过信用结算完成的每笔订单均需要在2万元以内。

可选地，上述专项额度132是根据用户的信用信息发放的。当一个用户在信用机构的信用度越高，对应发放的专项额度132就越高。示例性的，用户可以通过提高自身信用度来提升专项额度132，比如，在信用机构对应的第二服务器130上存储的用户信息的完善度为80％，对应的专项额度132为每个月2万元；用户在第二服务器130上完善自身信息，将用户信息的完善度提高至95％，提高自身的可信任度，对应的专项额度132则可以提升至每个月5万元。

可选地，上述专项额度132是根据用户的参保信息发放的。比如，可以根据用户的参保额度来确定发放额度，参保额度越高，对应的发放额度就越高。可选地，在第二服务器130中为信用结算订单设置有信用还款133。示例性的，信用还款包括在指定时间内还清从专项额度中借取的资金额度。

信用机构对应的第二服务器130中还存储有信用结算的签约信息。示例性的，上述签约信息是用户在平台服务器110上开启信用结算功能时与信用机构签约的信息。可选地，医疗机构还可以查询用户的信用结算的签约信息。示例性的，医疗机构对应的第一服务器120向平台服务器110发送对上述签约信息的查询请求；平台服务器110响应上述查询请求，从信用机构对应的第二服务器130中获取签约信息，将签约信息返回至第一服务器120；最终，第一服务器120对签约信息获取成功。

平台服务器110与医保机构对应的第三服务器140之间通过有线或者无线网络进行连接。第三服务器140为平台服务器110提供用户的医保信息的查询服务。示例性的，第三服务器140上承载有医保系统，医保系统上设置有查询入口141，医保系统中还记载了用户的医保参保状态142，平台服务器110调用查询入口141从医保系统中查询用户的医保参保状态142。医保参保状态包括指示用户参保或者未参保的信息、以及用户参保的保险种类。示例性的，当用户的医保参保状态指示用户的医疗保险处于参保状态，则表示用户具有通过医疗保险对部分就医费用进行报销的资格。医保机构对应的第三服务器140还提供了医保结算服务。第一服务器120可以向第三服务器140请求对医保电子凭证对应的医保处方进行医保结算。第一服务器120还与第三服务器140对医保电子凭证对应的医保处方进行结算确认，之后才对自费部分生成自费订单(即信用结算订单)。

平台服务器110与用户终端150之间通过有线或者无线网络进行连接。用户终端150是指用户持有的电子设备；用户终端150上安装且运行有平台服务器110对应的客户端151，该客户端151上绑定有医保电子凭证，用户可以通过客户端151来展示医保电子凭证。示例性的，对于上述医保电子凭证，在用户终端150前台运行客户端151，通过客户端151展示上述医保电子凭证；医疗机构通过扫描设备对客户端151上展示的医保电子凭证进行扫描识别，将扫描识别到的医保电子凭证上传至第一服务器120中，随着用户就医的进度将上述医保电子凭证与就医信息从一个环节传递至下一个环节。比如，医生为医保电子凭证001的持有者开具了药单，该药单与该医保电子凭证001对应传输至缴费环节，在完成缴费后传输至药房，以对照该药单为医保电子凭证001的持有者抓药。

示例性的，用户终端150可以包括智能手机、平板电脑、电子书阅读器、MP3(MovingPicture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)播放器、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机中、笔记本电脑的至少一种。

本领域技术人员可以知晓，上述第一服务器、第二服务器、第三服务器、以及平台服务器等可以是服务器集群，服务器集群可以包括一台服务器、多台服务器、云计算平台和虚拟化中心中的至少一种。上述用户终端的数量可以更多或更少。比如上述用户终端可以仅为一个，或者上述用户终端为几十个或几百个，或者更多数量，本申请实施例对用户终端的数量和设备类型不加以限定。

请参考图2，示出了本申请另一个示例性实施例提供的医保数据处理系统的结构框图，以对本申请提供的医保数据处理系统200的功能进行详细描述，该医保数据处理系统200包括客户端210、平台服务器220、第一服务器230、第二服务器240、以及第三服务器250；

客户端210，用于在第一用户界面上显示医保图形码，医保图形码携带有医保电子凭证，医保电子凭证签约有信用结算；

平台服务器220，用于接收医疗机构对应的第一服务器230发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，信用结算订单是第一服务器230与医保机构对应的第三服务器250，对医保电子凭证对应的医保处方进行结算确认后的自费订单；

平台服务器220，用于调用信用机构对应的第二服务器240对信用结算订单进行结算处理，将第二服务器240的第一结算结果发送至第一服务器230和客户端210；

客户端210，用于在第二用户界面上显示结算结果，结算结果包括第一结算结果和第二结算结果，第二结算结果是由第三服务器250发送至第一服务器230的医保电子凭证对应的医保结算的结果。

在一些实施例中，平台服务器220，还用于接收医疗机构对应的第一服务器230发送的签约查询请求；根据签约查询请求调用信用机构对应的第二服务器240查询医保电子凭证的签约信息，将签约信息返回至第一服务器230。

在一些实施例中，平台服务器220，还用于在医保电子凭证开启有信用结算的使用权限时，将签约信息和使用权限的启用信息返回至第一服务器230。

在一些实施例中，信用结算订单是第一服务器230在确认医保电子凭证签约有信用结算后，将至少两个信用结算订单合并后生成的合并订单。

在一些实施例中，合并订单是由第一服务器230在接收到就医结束信号后，将至少两个信用结算订单进行合并得到的；

其中，就医结束信号是第一服务器230对应的医疗客户端210在接收到医护人员触发的就医结束操作后，发送至第一服务器230的；或者，就医结束信号是第一服务器230在指定时间自动触发生成的。

在一些实施例中，合并订单所需结算的结算金额小于医保电子凭证签约的信用结算额度。

在一些实施例中，信用结算订单是第一服务器230与第三服务器250对医保电子凭证对应的医保处方进行预结算后生成的；

或者，信用结算订单是第一服务器230与第三服务器250对医保电子凭证对应的医保处方进行试结算后生成的。

在一些实施例中，平台服务器220，还用于向客户端210发送信用结算的授权请求页面；

客户端210，还用于显示授权请求页面；在接收到授权操作时，向平台服务器220发送授权信号；

平台服务器220，还用于根据授权信号向第二服务器240发送医保电子凭证进行签约；在接收到第二服务器240发送的签约信息时，向医保机构对应的第三服务器250同步签约信息。

在一些实施例中，平台服务器220，还用于根据授权信号向第二服务器240发送医保电子凭证；在接收到第二服务器240根据医保电子凭证发送的查询请求时，向第二服务器240发送医保电子凭证对应的用户信息和参保信息，用户信息和参保信息用于与第二服务器240签约信用结算。

在一些实施例中，平台服务器220，还用于向客户端210发送信用结算的解约请求页面；

客户端210，还用于显示解约请求页面；在接收到解约操作时，向平台服务器220发送解约信号；

平台服务器220，还用于根据解约信号向第二服务器240发送医保电子凭证进行解约；在接收到第二服务器240发送的解约信息时，向医保机构对应的第三服务器250同步解约信息。

在一些实施例中，平台服务器220，还用于根据解约信号向第二服务器240发送医保电子凭证；在接收到第二服务器240根据医保电子凭证发送的查询请求时，向第二服务器240发送医保电子凭证对应的用户信息和参保信息，用户信息和参保信息用于与第二服务器240解约信用结算。

在一些实施例中，医保电子凭证采用周期更新的动态授权码表示，周期与动态授权码的有效时长对应。

综上所述，本实施例提供的医保数据处理系统，用户可以通过在客户端上展示医保图形码，在就医开始即由医疗机构通过扫描获取医保图形码中携带的医保电子凭证，在用户就医完成之后，由医疗机构对应的第一服务器向客户端对应的平台服务器发送信用结算下单请求，该信用结算下单请求携带了医保电子凭证和信用结算订单，由于医保电子凭证签约有信用结算，因此，平台服务器可以调用信用机构对应的第二服务器对信用结算订单进行支付，也即对用户就医的自费项目进行费用支付；且由第一服务器调用第三服务器进行医保结算。所以，在就医过程中，用户可以通过一次扫码，由医保数据处理系统完成医保项目和自费项目的结算，无需到窗口排队缴费，也无需在客户端上执行繁复的费用支付操作，以分别对医保项目和自费项目进行缴费，提高了用户的就医效率。

请参考图3，示出了本申请一个示例性实施例提供的医保数据处理方法的流程图。本实施例以该方法应用于图1和/或图2所示的医保数据处理系统中为例进行说明，该方法包括：

步骤320，客户端在第一用户界面上显示医保图形码，医保图形码携带有医保电子凭证，医保电子凭证签约有信用结算。

用户终端中安装且运行有上述客户端，在该客户端的第一用户界面上显示医保图形码。可选地，上述医保图形码包括条形码和二维码中的至少一种。示例性的，用户可以通过在客户端上关注的公众号来绑定医保电子凭证，之后通过该公众号来展示上述医保电子凭证；或者，客户端作为宿主程序来运行小程序，通过小程序来绑定医保电子凭证，之后通过小程序来展示上述医保电子凭证。

可选地，医保电子凭证采用周期更新的动态授权码表示，周期与动态授权码的有效时长对应。即在客户端上展示的医保图形码会周期性更新，比如，每三分钟更新一次医保图形码，在时刻00:00开始展示的医保图形码，在时刻00:03失效，且在第一用户界面刷新出新医保图形码，新医保图形码仍携带有医保电子凭证。

医疗机构通过扫描设备来扫描上述医保图形码，从而获得医保图形码携带的医保电子凭证，将上述医保电子凭证上传至医疗机构对应的第一服务器中。医疗机构的工作人员基于上述医保电子凭证为用户提供医疗服务；比如，挂号窗口的工作人员在医保电子凭证下为用户挂号，门诊的医生在医保电子凭证下为用户开具检查单和/或药单等。上述医保电子凭证还签约有信用结算，实现对信用结算订单的结算处理，示例性的，信用结算订单可以包括挂号单、检查单、药单、住院订单对应的至少一种缴费订单。

示例性的，医保机构的工作人员在医保电子凭证下开具信用结算订单之后，触发对信用结算订单的结算流程，由医疗机构对应的第一服务器向平台服务器发送对信用结算订单结算的信用结算下单请求。

步骤340，平台服务器接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单。

上述信用结算下单请求携带的医保电子凭证是扫描医保图形码获得的。信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单。

可选地，信用结算订单是第一服务器与第三服务器对医保电子凭证对应的医保处方进行预结算后生成的。上述预结算是指在信用结算订单生成之前预先对医保结算部分进行结算。即对于就医时的缴费订单包括医保结算部分(即医保报销部分)与自费部分，在请求信用结算之前，第一服务器首先向医保机构对应的第三服务器请求在医保电子凭证下对医保处方对应的医保结算部分进行预结算，其次在第三服务器返回医保结算部分的预结算结果后，第一服务器确定出缴费订单中所需自费的部分，针对自费部分生成自费订单(即信用结算订单)，根据自费订单与医保电子凭证生成信用结算下单请求；向平台服务器发送信用结算下单请求。也就是说，第一服务器首先对用户就医时的费用订单进行核算，计算出医保处方对应的医保结算部分与自费部分，之后请求第三服务器对医保结算部分进行预结算，等待第三服务器返回对医保结算部分预结算的结果，第一服务器再根据预结算的结果来确定自费部分的自费金额，生成自费订单，之后向第二服务器请求对自费订单进行信用结算，最终完成对整个费用订单的支付。

可选地，信用结算订单是第一服务器与第三服务器对医保电子凭证对应的医保处方进行试结算后生成的。试结算是指第一服务器与第三服务器之间确定采用医保结算的结算部分，实际上没有对医保结算部分进行结算。示例性的，在请求信用结算之前，第一服务器首先向第三服务器发送医保处方对应的试结算订单，由第三服务器确定出试结算订单中能够采用医保结算完成的项目，得到试结算结果，且将该试结算结果返回至第一服务器中；第一服务器根据返回的试结算结果来确定出订单中能够采用医保结算的项目，对应生成医保订单，且确定出不能够采用医保结算的项目，对应生成信用结算订单；之后第一服务器调用第二服务器对信用结算订单进行结算处理，调用第三服务器对医保订单进行医保结算，完成就医的所有缴费项目的费用支付。示例性的，自费订单中包括对非医保处方的结算项目；自费订单中还可以包括对医保处方的结算项目，在医保电子凭证下用于医保报销的资金不足时，需要才用自费的方式对医保处方进行结算。

步骤360，平台服务器调用信用机构对应的第二服务器对信用结算订单进行结算处理，将第二服务器的第一结算结果发送至第一服务器和客户端。

平台服务器响应接收到的信用结算下单请求，调用信用机构对应的第二服务器对信用结算订单进行结算处理，第二服务器对信用结算订单处理完成后将第一结算结果返回给平台服务器，再由平台服务器返回给第一服务器与客户端。

示例性的，平台服务器接收到信用结算订单请求之后，确认医保电子凭证是否签约了信用结算，若该医保电子凭证签约了信用结算，平台服务器调用信用机构对应的第二服务器对信用结算订单进行结算处理。示例性的，上述信用机构可以包括金融机构和支付平台中的至少一种。

在一些实施例中，信用结算订单是第一服务器在确认医保电子凭证签约有信用结算后，生成的一个信用结算订单。在上述实施例场景中，用户的就医过程中生成至少两个信用结算订单，每生成一个信用结算订单即对信用结算订单进行订单结算。比如，针对挂号单生成第一信用结算订单后，第一服务器通过平台服务器调用第二服务器对第一信用结算订单进行结算处理；之后针对检查单生成第二信用结算订单，第一服务器通过平台服务器调用第二服务器对第二信用结算订单进行结算处理。

在一些实施例中，信用结算订单是第一服务器在确认医保电子凭证签约有信用结算后，将至少两个信用结算订单合并后生成的合并订单。在上述实施例场景中，用户的就医过程中生成至少两个信用结算订单，在药单对应的信用结算订单生成(即用户就医结束)之后，将上述至少两个信用结算订单合并，生成合并订单，对上述合并订单进行信用结算。比如，针对挂号单生成第一信用结算订单，针对检查单生成第二信用结算订单，针对药单生成第三信用结算订单，在确认用户按照药单取药后，第一服务器将第一信用结算订单、第二信用结算订单与第三信用结算订单合并，生成合并订单，之后第一服务器通过平台服务器调用第二服务器对合并订单进行信用结算。示例性的，第一服务器首先对每个信用结算订单对应的医保报销部分进行医保结算，在完成对医保报销部分的预结算之后，若是用户就医还没有结束，第一服务器将信用结算订单设置为待处理状态，即先不对信用结算订单进行结算处理；若是用户就医结束，第一服务器获取用户的医保电子凭证下至少两个信用结算订单，对至少两个信用结算订单进行合并，即将至少两个信用结算订单上的信用结算项目进行获取，对应生成一个包括至少两个信用结算订单上所有信用结算项目的新订单，对所有的信用结算项目进行统一支付。

可选地，合并订单是由第一服务器在接收到就医结束信号后，将至少两个信用结算订单进行合并得到的。就医结束信号是第一服务器对应的医疗机构在接收到医护人员触发的就医结束操作后，发送至第一服务器的。上述第一服务器与医疗客户端是对应设置的，第一服务器为医疗客户端提供后台服务。示例性的，在用户取药结束后，医护人员在医疗客户端上该用户对应的取药项目上确认取药完成，该取药项目是基于医保电子凭证对应生成的；医疗客户端在接收到确认取药完成的操作后，向第一服务器发送就医结束信号；第一服务器在接收到上述就医结束信号后，对至少两个信用结算订单进行合并且结算。

或者，就医结束信号是第一服务器在指定时间自动触发生成的。示例性的，指定时间为每天的20:00，第一服务器将医保电子凭证对应的至少两个信用结算订单放置在等待任务队列中，当时间到达20:00时，用户没有触发对至少两个信用结算订单的确认支付，第一服务器自动触发生成就医结束信号，之后响应上述就医结束信号，对至少两个信用结算订单进行合并且结算。

可选地，合并订单所需结算的结算金额小于医保电子凭证签约的信用结算额度。示例性的，第一服务器在对至少两个信用结算订单进行合并的过程中，首先从第二服务器中获取信用结算额度；确定第1个信用结算订单与第2个信用结算订单合并后的第一结算金额；响应于第一结算金额小于信用结算额度，对第1个信用结算订单与第2个信用结算订单进行合并，得到第1个中间合并订单；确定第i个中间合并订单与第j个信用结算订单合并后的第二结算金额；响应于第二结算金额小于信用结算额度，对第i个中间合并订单与第j个信用结算订单进行合并，得到第i+1个中间合并订单；响应于第j个信用结算订单为最后一个信用结算订单，将第i+1个中间合并订单确定为合并订单；响应于第二结算金额大于或者等于信用结算额度，将第i个中间合并订单确定为合并订单；其中，i为正整数，j为大于2的正整数。

还需要说明的是，在进行订单合并之前，需要确定至少两个信用结算订单中的每一个信用结算订单的所需结算额度均小于信用结算额度；若存在所需结算额度大于信用结算额度的信用结算订单，在信用结算额度范围内对小于信用结算额度的信用结算订单进行合并且结算；若存在所需结算额度等于信用结算额度的信用结算订单，对等于信用结算额度的信用结算订单进行结算处理。

也就是说，在对至少两个订单合并的过程中，需要保证合并后的订单所需结算的金额不超出信用结算额度。上述信用结算额度是指医保电子凭证签约的信用结算所能提供的结算额度；若此次的合并订单不是第一笔合并订单，信用结算额度则是指信用结算所能提供的结算额度中的剩余额度。

步骤380，客户端在第二用户界面上显示结算结果，结算结果包括第一结算结果和第二结算结果。

上述第二结算结果是由第三服务器发送至第一服务器的医保电子凭证对应的医保结算的结果，即第一服务器调用第三服务器对医保处方进行医保结算后生成的医保结算结果。

客户端接收平台服务器返回的第一结算结果，与第三服务器返回的第二结算结果，在客户端的第二用户界面上显示上述第一结算结果和第二结算结果。示例性的，如图4，在客户端上显示第一用户界面301，第一用户界面301上包括医保图形码302，该医保图形码302携带有用户李*明的医保电子凭证。第一用户界面301上还包括了信用结算的开启/关闭的控制控件303，如图4所示，当圆形滑动标记位于滑动轨道的最右侧时，表示信用结算处于开启状态；如图5所示，当圆形滑动标记位于滑动轨道的最左侧时，表示信用结算处于关闭状态。在信用结算订单支付成功后，在客户端上显示第二用户界面304，第二用户界面304上包括支付成功的字样305、医疗机构的名称306与支付金额307；图5所示结算结果表示用户就医所支付的费用全部采用了信用结算的方式。

示例性的，在对信用结算订单进行信用结算之前，还在客户端上显示第三用户界面，第三用户界面是在平台服务器接收到第一服务器发送的信用结算下单请求之后发送至客户端上的用户界面。第三用户界面上显示信用结算订单的结算明细，第三用户界面上还包括结算控件，当终端接收到结算控件上触发的结算信号时，向平台服务器发送结算请求，平台服务器基于结算请求对信用结算下单请求进行响应。可选地，第三用户界面上显示的结算明细可调整，即对于未执行项目，用户可以删除未执行项目对应的结算明细，之后再对信用结算订单进行确认结算。比如，一份信用结算订单上包括挂号费、检查费、药费三项结算明细，用户在检查完身体之后，不在就医的医疗机构购药，则在对信用结算订单结算时，删除药费这一项结算明细，仅对挂号费与检查费进行结算；其中，对于已执行项目的结算明细，用户是无法操作的，比如，用户在按照检查单检查之后，则用户是无法删除检查单的结算明细的。

综上所述，本实施例提供的信用结算方法，通过客户端中显示医保图形码，在就医时由医疗机构的工作人员通过扫描获取医保图形码中携带的医保电子凭证，以在该医保电子凭证下开具各类单据，在对单据中的医保项目支付完成后，由第一服务器生成各类单据对应的医保订单与信用结算订单，在医保电子凭证签约有信用结算的前提下，由平台服务器调用信用机构对应的第二服务器对信用结算订单进行信用结算，也即对用户就医的自费项目进行费用支付；还由第一服务器调用第三服务器对医保订单进行支付。所以，在就医过程中，用户可以通过一次扫码来完成医保项目和自费项目的结算，无需到窗口排队缴费，也无需在客户端上执行繁复的费用支付操作，以分别对医保项目和自费项目进行缴费，提高了用户的就医效率。

请参考图6，示出了本申请一个示例性实施例提供的签约查询方法的流程图。本实施例以该方法应用于图1和/或图2所示的医保数据处理系统中为例进行说明。该方法包括：

步骤420，平台服务器接收医疗机构对应的第一服务器发送的签约查询请求。

医疗机构可以查询用户的医保电子凭证的签约信息，医疗机构通过第一服务器向平台服务器发送签约查询请求，即上述签约查询请求用于请求查询医保电子凭证的签约信息。

示例性的，该签约查询请求包括医保电子凭证，以对应查询该电子凭证的签约信息。可选地，签约信息包括医保电子凭证签约有信用结算。示例性的，签约信息可以包括签约的信用机构、签约的信用机构的信用结算通道、以及签约的信用结算额度等。示例性的，信用机构的信用结算通道可以包括借记卡支付通道、信用卡支付通道等。

步骤440，平台服务器根据签约查询请求调用信用机构对应的第二服务器查询医保电子凭证的签约信息，将签约信息返回至第一服务器。

平台服务器接收第一服务器发送的签约查询请求，该签约查询请求中包括医保电子凭证。信用机构对应的第二服务器中对应存储有医保电子凭证与签约信息的关系表，第二服务器上还设置有查询入口；平台服务器通过上述查询入口从第二服务器存储的关系表中查询得到医保电子凭证的签约信息，将上述签约信息返回至第一服务器中。

可选地，在医保电子凭证开启有信用结算的使用权限时，平台服务器将签约信息和使用权限的启用信息返回至第一服务器中。可选地，上述签约信息中还可以包括至少两个签约机构的信用结算通道。

示例性的，如图7，在第一用户界面401上显示有信用结算通道的选择控件402，上述选择控件402上还显示有选中的信用结算通道的名称“**银行信用支付”；医保电子凭证上绑定有两个信用结算通道，另一个信用结算通道的名称为“**平台信用支付”。在第一用户界面401上接收到选择控件402上的选择操作，在第一用户界面401上叠加显示通道选择界面403，通道选择界面403上显示有“**银行信用支付”的第一选择控件404与“**平台信用支付”的第二选择控件405；在选择界面403上接收到第二选择控件405上的选中操作时，将使用的信用结算通道从“**银行信用支付”切换为“**平台信用支付”，且在选择控件402上显示“**平台信用支付”的字样。

示例性的，若医保电子凭证签约有信用结算，则在第一用户界面401上显示有信用结算通道的选择控件402、与信用结算的开启/关闭的控制控件406，如图7所示；若医保电子凭证未签约有信用结算，则在第一用户界面401上不显示信用结算通道的选择控件402、与信用结算的开启/关闭的控制控件406，如图8所示。

综上所述，本实施例提供的签约查询方法，医疗机构可以通过平台服务器查询用户为医保电子凭证签约信用机构的信用结算的签约信息，以使医疗机构更加全面地了解用户的就医信息，使得医保电子凭证的信用结算更加具有可信度。

请参考图9，示出了本申请一个示例性实施例提供的信用结算的授权方法的流程图。本实施例以该方法应用于图1和/或图2所示的医保数据处理系统中为例进行说明。该方法包括：

步骤520，平台服务器向客户端发送信用结算的授权请求页面。

示例性的，在客户端的主用户界面上显示有信用结算入口，通过上述信用结算入口进入信用结算界面；在没有为医保电子凭证签约信用结算时，在上述信用结算界面上显示有信用结算的开通控件；在开通控件上接收的开通操作之后，客户端向平台服务器发送开通信号；平台服务器根据开通信号向客户端发送信用结算的授权请求页面。

步骤540，客户端显示授权请求页面；在接收到授权操作时，向平台服务器发送授权信号。

在客户端上显示接收到的平台服务器发送的授权请求页面；该授权请求页面上包括授权控件，在授权控件上接收到授权操作时，客户端向平台服务器发送授权信号。

步骤560，平台服务器根据授权信号向第二服务器发送医保电子凭证进行签约。

平台服务器接收到授权信号之后，向第二服务器发送医保电子凭证进行签约。示例性的，平台服务器向第二服务器发送签约请求，该签约请求用于请求信用机构对应的第二服务器为医保电子凭证签约信用结算，该签约请求中包括医保电子凭证；第二服务器为医保电子凭证签约信用结算之后，将签约信息发送至平台服务器中。

可选地，平台服务器根据授权信号向第二服务器发送医保电子凭证，在接收到第二服务器根据医保电子凭证发送的查询请求时，向第二服务器发送医保电子凭证对应的用户信息和参保信息，用户信息和参保信息用于与第二服务器签约信用结算。示例性的，第二服务器根据上述用户信息和参保信息进行对医保电子凭证的信用结算的签约资质审核，在审核通过后进行签约，并将签约信息发送至平台服务器中。

步骤580，平台服务器在接收到第二服务器发送的签约信息时，向医保机构对应的第三服务器同步签约信息。

平台服务器接收第二服务器发送的签约信息，且将上述签约信息同步至医保机构对应的第三服务器中。

示例性的，如图10，显示客户端的主用户界面501，主用户界面501上包括信用结算入口502；在信用结算入口502上接收到进入操作时，显示信用结算界面503，若未开通信用结算，在信用结算界面503上包括开通控件504和签约控件505；在开通控件504上接收到开通操作时，通过定位描点从开通控件504的显示位置跳跃至签约控件505的显示位置；在签约控件505上接收到签约操作时，显示授权请求页面，执行签约流程，还在授权请求页面上显示授权控件；在接收到授权控件上的授权操作时，完成医保电子凭证的信用结算的授权，显示用户界面506。示例性的，在未开通信用结算时，信用结算界面503上主要展示了业务介绍，优先展示产品(即信用结算)介绍相关内容。示例性的，信用结算界面503上还包括帮助控件507，可以通过帮助控件507跳转至相关公众号文章，以获知更详细的信用结算的相关内容。

示例性的，如图11，若已开通信用结算，在信用结算界面503上显示有信用结算的使用控件508，可以通过使用控件508直接跳转至用户界面506。若已开通信用结算，在信用结算界面503上还显示有信用结算所支持的医疗机构的第一查看控件509和信用结算的使用记录的第二查看控件510。在接收到第一查看控件509上的查看操作时，显示第一列表界面511，第一列表界面511上包括信用结算支持的至少两个医疗机构对应的列表项，如图12所示；在第一列表界面511上还可以按照支付方式对医疗机构进行筛选，比如，对支付方式进行筛选，触发支付方式的筛选控件512，显示支付选项“刷码支付”、“公众号支付”与“信用支付”，选中“信用支付”，则在第一列表界面511上显示筛选出的支持信用结算的医疗机构。在接收到第二查看控件510上的查看操作时，显示第二列表界面513，第二列表界面513上包括至少一条信用结算的使用记录，如图13所示。示例性的，在已开通信用结算时，将最后签约的信用结算方式作为默认的信用结算方式。

综上所述，本实施例提供的信用结算的授权方法，通过对医保电子凭证授权信用结算，使用户可以通过医保电子凭证实现仅通过刷码来支付订单的功能，无需执行输入密码、确认订单支付等操作步骤，提高了用户的就医效率。

请参考图14，示出了本申请一个示例性实施例提供的信用结算的解约方法的流程图。本实施例以该方法应用于图1和/或图2所示的医保数据处理系统中为例进行说明。该方法包括：

步骤620，平台服务器向客户端发送信用结算的解约请求页面。

示例性的，在医保电子凭证签约有信用结算时，信用结算界面上显示签约管理控件；接收上述签约管理控件上的管理操作，向平台服务器发送管理信号；平台服务器向客户端发送信用结算的解约请求页面。

步骤640，客户端显示解约请求页面，在接收到解约操作时，向平台服务器发送解约信号。

在客户端上显示接收到的平台服务器发送的解约请求页面；该解约请求页面上包括解约控件，在解约控件上接收到解约操作时，客户端向平台服务器发送解约信号。

步骤660，平台服务器根据解约信号向第二服务器发送医保电子凭证进行解约。

平台服务器接收到解约信号之后，向第二服务器发送医保电子凭证进行解约。示例性的，平台服务器向第二服务器发送解约请求，该解约请求用于请求信用机构对应的第二服务器为医保电子凭证解除信用结算的签约，该解约请求中包括医保电子凭证；第二服务器为医保电子凭证解约信用结算之后，将解约信息发送至平台服务器中。

可选地，平台服务器根据解约信号向第二服务器发送医保电子凭证；在接收到第二服务器根据医保电子凭证发送的查询请求时，向第二服务器发送医保电子凭证对应的用户信息和参保信息，用户信息和参保信息用于与第二服务器解约信用结算。

步骤680，平台服务器在接收到第二服务器发送的解约信息时，向医保机构对应的第三服务器同步解约信息。

平台服务器接收到第二服务器发送的解约信息，且将上述解约信息同步至医保机构对应的第三服务器中。

示例性的，如图15，若已开通信用结算，在信用结算页面601上显示有签约管理控件602，接收上述签约管理控件602上的管理操作，向平台服务器发送管理信号；平台服务器向客户端发送信用结算的解约请求页面，解约请求页面上包括解约控件；在解约控件上接收到解约操作时，客户端向平台服务器发送解约信号；平台服务器根据解约信号向第二服务器发送医保电子凭证进行解约，且在接收到第二服务器发送的解约信息时，向医保机构对应的第三服务器同步解约信息。

综上所述，本申请实施例提供的信用结算的解约方法，使得用户可以更加方便的管理信用结算，控制信用结算的签约与解约，提高了用户体验。

请参考图16，示出了本申请一个示例性实施例提供的信用结算的签约/解约方法的流程图。本实施例以该方法应用于图1和/或图2所示的医保数据处理系统中为例进行说明。该方法包括：

步骤701，客户端显示信用结算页面。

在客户端上设置有信用结算页面的入口，通过上述入口可以进入信用结算页面。在信用结算页面上接收到信用结算的开通操作时，向平台服务器发送开通信号。

步骤702，在接收到信用结算页面上的开通信号时，平台服务器判断医保电子凭证是否激活。

平台服务器在接收到信用结算页面上的开通信号时，平台服务器首先判断医保电子凭证是否激活。示例性的，未开通医保电子凭证的使用功能即是指医保电子凭证处于未激活状态，开通医保电子凭证的使用功能即是指医保电子凭证处于激活状态。在医保电子凭证处于未激活状态时，无法通过客户端来展示医保电子凭证的医保图形码；在医保电子凭证处于激活状态时，可以通过客户端来展示医保电子凭证的医保图形码，且处于激活状态的医保电子才可以签约信用结算。

若医保电子凭证未激活，首先执行步骤703，对医保电子凭证进行激活；若医保电子凭证已激活，执行步骤704。

步骤703，平台服务器激活医保电子凭证，返回自步骤701重新开始执行。

步骤704，客户端显示授权请求页面。

在客户端上显示医保电子凭证的信用结算的授权请求页面，授权请求页面用于触发向信用机构对应的第二服务器请求签约信用结算。示例性的，授权请求页面上设置有授权控件，在接收到授权控件上的授权操作时，向平台服务器发送授权信号。

步骤705，在接收到授权请求页面上的授权信号时，平台服务器向信用机构对应的第二服务器发送授权码；客户端显示信用机构页面。

平台服务器在接收到授权请求页面上的授权信号时，生成授权码，向信用机构对应的第二服务器发送该授权码，该授权码是用于请求第二服务器授权医保电子凭证签约信用结算。在向信用机构发送授权码之后，平台服务器接收第二服务器发送的信用机构页面，该信用机构页面用于填写用户信息和参保信息。

步骤706，第二服务器通过授权码查询用户信息，调用用户信息查询接口从平台服务器查询用户信息和参保信息。

授权码中包括医保电子凭证，第二服务器通过授权码从平台服务器中查询医保电子凭证对应的用户信息与参保信息。

步骤707，平台服务器通过参保信息查询接口从医保机构对应的第三服务器中查询用户的参保信息。

平台服务器在第二服务器调用用户信息查询接口进行信息查询时，获取自身存储的用户信息，且调用参保信息查询接口从第三服务器中查询医保电子凭证对应的参保信息。

步骤708，平台服务器将用户信息与参保信息返回至第二服务器中。

平台服务器在查询到用户信息与参保信息之后，将用户信息与参保信息返回至第二服务器中。

步骤709，第二服务器将用户信息与参保信息自动填入信用机构页面。

第二服务器将用户信息与参保信息自动填入信用机构页面，信用机构页面上包括确认控件；用户确认信息无误后，触发该确认控件；客户端将确认控件上触发的确认信号发送至第二服务器。

步骤710，第二服务器为医保电子凭证进行信用结算签约或者解约。

第二服务器接收到确认信号之后，基于用户信息与参保信息为医保电子凭证进行信用结算的签约或者解约。

步骤711，第二服务器将签约或者解约信息同步至平台服务器保存。

在签约或者解约完成后，第二服务器将签约或者解约信息同步至平台服务器保存。

步骤712，平台服务器将签约或者解约信息同步至第三服务器保存。

平台服务器接收第二服务器同步的签约或者解约信息，对签约或者解约信息进行保存，且将签约或者解约信息同步至第三服务器保存。

综上所述，本实施例提供的信用结算的签约/解约方法，使得用户可以更加方便的管理信用结算，控制信用结算的签约与解约，提高了用户体验。

请参考图17，示出了本申请一个示例性实施例提供的信用结算方法的流程图。本实施例以该方法应用于图1和/或图2所示的医保数据处理系统中为例进行说明。该方法包括：

步骤801，完成就诊。

步骤802，在客户端上选择信用结算方式或者关闭信用结算。

用户可以在客户端上对医保电子凭证的信用结算方式进行设置；示例性的，对信用结算使用的信用结算通道进行更改，比如，从使用银行信用支付更改为使用平台信用支付。用户还可以在客户端上关闭医保电子凭证的信用结算。

步骤803，在客户端上展示医保图形码。

在开启了医保电子凭证的信用结算的前提下，通过客户端展示医保图形码，该医保图形码携带医保电子凭证。

步骤804，医疗机构通过扫描设备扫描医保图形码。

医疗机构通过扫描设备对医保图形码进行扫描，将扫描得到的医保图形码上传至第一服务器。

步骤805，医疗机构对应的第一服务器向医保机构对应的第三服务器请求对医保图形码进行解码。

医保图形码是按照加密算法生成的医保电子凭证的图形码表示，第一服务器向第三服务器请求对医保图形码进行解码，以获得解码后的医保电子凭证。

步骤806，第三服务器解码后向第一服务器返回参保信息和身份认证信息。

第三服务器对医保图形码解码后得到医保电子凭证，将包括医保电子凭证的参保信息与身份认证信息返回至第一服务器中。身份认证信息用于指示参保信息是由第三服务器返回至第一服务器中的；示例性的，身份认证信息即是ectoken。

步骤807，第一服务器根据图形码符号调用平台服务器进行信用签约查询。

图形码符号即为解码后医保电子凭证的符号表示。第一服务器根据图形码符号调用平台服务器进行信用签约查询，即对医保电子凭证对应的用户信息与参保信息进行查询验证，以确认医保电子凭证符合签约条件。示例性的，图形码符号可以是qr_code。

步骤808，平台服务器基于信用签约查询调用信用机构对应的第二服务器进行信用签约信息确认。

平台服务器基于信用签约查询调用第二服务器进行信用签约信息确认，即对用户信息与参保信息进行确认；当确认成功时，第二服务器获取医保电子凭证的签约信息，将上述签约信息返回至平台服务器。

步骤809，第二服务器向平台服务器返回签约信息。

步骤810，平台服务器向第一服务器返回签约信息、以及结算信息。

平台服务器在接收到签约信息后，将签约信息与结算信息发送给第一服务器；结算信息是指用户是否选择信用结算的信息。

步骤811，第一服务器调用第三服务器进行医保处方试算。

当结算信息指示医保电子凭证可以使用信用结算时，第一服务器首先进行医保处方试算，与第三服务器之间进行医保订单的试结算。

步骤812，第三服务器向第一服务器返回试算结果。

第三服务器在接收到第一服务器的医保处方的医保订单时，进行医保订单的试结算，并将试算结果返回至第一服务器。该过程是模拟医保订单的结算过程，以确定需要自费的结算项目。

步骤813，第一服务器基于图形码符号调用平台服务器的信用结算下单接口，进行信用结算。

第一服务器在接收到医保订单的试算结果后，生成自费订单，调用平台服务器的信用结算下单接口与第二服务器之间进行自费订单的信用结算。

步骤814，平台服务器接收到对信用结算下单接口的调用，调用第二服务器的信用结算接口，进行信用结算。

步骤815，第二服务器向平台服务器返回结算结果。

第二服务器对第一服务器发送的自费订单进行信用结算，在结算完成之后将结算结果返回至平台服务器中。

步骤816，平台服务器通知第一服务器结算成功。

平台服务器接收到第二服务器返回的结算完成的结果后，向第一服务器发送结算成功的通知信息。

步骤817，平台服务器向客户端发送结算结果页面。

平台服务器还在接收到第二服务器返回的结算完成的结果后，向客户端发送结算结果页面，以通知用户自费订单结算成功。

步骤818，第一服务器调用第三服务器进行医保结算。

在信用结算订单结算完成后，第一服务器调用第三服务器对医保订单(即医保处方对应的医保订单)进行结算。

步骤819，第三服务器返回医保结算结果至第一服务器。

第三服务器在对医保订单结算完成后，将医保结算结果返回至第一服务器中。

步骤820，第一服务器处理结算结果，向客户端发送结算消息通知。

第一服务器基于信用结算订单的结算结果与医保订单的结算结果确定就医的费用订单支付完成，向客户端发送结算通知消息，以通知用户医保与自费的就医费用全部结算完成。

综上所述，本实施例提供的医保数据处理方法，通过约定双方鉴权、数据加密、以及基于超文本传输(Hyper Text Transfer Protocol，HTTP)协议的应用程序编程接口(Application Programming Interface，API)来做请求交互，保证了各个环节数据安全，同时还配置了网络地址白名单确保来源请求的合法性。为确保用户授权数据安全性，以授权码的形式透出授权code至合作方服务器，让合作方服务器以后台请求的形式，来请求有鉴权保障的后台接口拉取相关信息。涉及签约完成，签约信息的回流需要进行用户身份比对，确保发起签约和合作方回流的用户一致。

请参考图18，示出了本申请一个示例性实施例提供的医保数据处理装置的框图。该装置可以通过软件、硬件或者二者的结合实现成为终端的部分或者全部，该装置包括：

显示模块920，用于在第一用户界面上显示医保图形码，医保图形码携带有医保电子凭证，医保电子凭证签约有信用结算；

显示模块920，还用于在第二用户界面上显示结算结果，结算结果包括第一结算结果和第二结算结果；第一结算结果是由平台服务器接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，调用信用机构对应的第二服务器对信用结算订单进行结算处理，之后返回第一服务器和客户端的，信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单；第二结算结果是由第三服务器发送至第一服务器的医保电子凭证对应的医保结算的结果。

综上所述，本实施例提供的医保数据处理装置，通过该装置展示医保图形码，在就医开始即由医疗机构通过扫描获取医保图形码中携带的医保电子凭证，在用户就医完成之后，由医疗机构对应的第一服务器向客户端对应的平台服务器发送信用结算下单请求，该信用结算下单请求携带了医保电子凭证和信用结算订单，由于医保电子凭证签约有信用结算，因此，平台服务器可以调用信用机构对应的第二服务器对信用结算订单进行支付，也即对用户就医的自费项目进行费用支付；且由第一服务器调用第三服务器进行医保结算。所以，在就医过程中，用户可以通过一次扫码，由医保数据处理系统完成医保项目和自费项目的结算，无需到窗口排队缴费，也无需在该装置上执行繁复的费用支付操作，以分别对医保项目和自费项目进行缴费，提高了用户的就医效率。

请参考图19，示出了本申请另一个示例性实施例提供的医保数据处理装置的框图。该装置可以通过软件、硬件或者二者的结合实现成为平台服务器的部分或者全部，该装置包括：

接收模块1020，用于接收医疗机构对应的第一服务器发送的信用结算下单请求，信用结算下单请求携带有医保电子凭证和信用结算订单，医保电子凭证是从客户端上显示的医保图形码中获取得到的，医保电子凭证签约有信用结算，信用结算订单是第一服务器与医保机构对应的第三服务器，对医保电子凭证对应的医保处方进行结算确认后的自费订单；

调用模块1040，用于调用信用机构对应的第二服务器对信用结算订单进行结算处理；

发送模块1060，用于将第二服务器的第一结算结果发送至第一服务器和客户端。

综上所述，本实施例提供的医保数据处理装置，用户可以通过在客户端上展示医保图形码，在就医开始即由医疗机构通过扫描获取医保图形码中携带的医保电子凭证，在用户就医完成之后，由医疗机构对应的第一服务器向客户端对应的该装置发送信用结算下单请求，该信用结算下单请求携带了医保电子凭证和信用结算订单，由于医保电子凭证签约有信用结算，因此，该装置可以调用信用机构对应的第二服务器对信用结算订单进行支付，也即对用户就医的自费项目进行费用支付；且由第一服务器调用第三服务器进行医保结算。所以，在就医过程中，用户可以通过一次扫码，由医保数据处理系统完成医保项目和自费项目的结算，无需到窗口排队缴费，也无需在客户端上执行繁复的费用支付操作，以分别对医保项目和自费项目进行缴费，提高了用户的就医效率。

请参考图20，示出了本申请一个示例性实施例提供的服务器1100的结构示意图。该服务器1100可以用于执行上述可选实施例中的医保数据处理方法，具体来讲：

服务器1100包括中央处理单元(Central Processing Unit，CPU)1101、包括随机存取存储器(Random Access Memory，RAM)1102和只读存储器(Read-Only Memory，ROM)1103的系统存储器1104，以及连接系统存储器1104和中央处理单元1101的系统总线1105。服务器1100还包括帮助计算机内的各个器件之间传输信息的基本输入/输出(Input/Output，I/O)系统1106，和用于存储操作系统1113、应用程序1114和其他程序模块1115的大容量存储设备1107。

基本输入/输出系统1106包括有用于显示信息的显示器1108和用于用户输入信息的诸如鼠标、键盘之类的输入设备1109。其中显示器1108和输入设备1109都通过连接到系统总线1105的输入输出控制器1110连接到中央处理单元1101。基本输入/输出系统1106还可以包括输入输出控制器1110以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器1110还提供输出到显示屏、打印机或其他类型的输出设备。

大容量存储设备1107通过连接到系统总线1105的大容量存储控制器(未示出)连接到中央处理单元1101。大容量存储设备1107及其相关联的计算机可读介质为服务器1100提供非易失性存储。也就是说，大容量存储设备1107可以包括诸如硬盘或者只读光盘(Compact Disc Read-Only Memory，CD-ROM)驱动器之类的计算机可读介质(未示出)。

不失一般性，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、闪存(Flash Memory)或其他固态存储其技术，CD-ROM、数字通用光盘(DigitalVersatile Disc，DVD)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器1104和大容量存储设备1107可以统称为存储器。

根据本申请的各种实施例，服务器1100还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器1100可以通过连接在系统总线1105上的网络接口单元1111连接到网络1112，或者说，也可以使用网络接口单元1111来连接到其他类型的网络或远程计算机系统(未示出)。

上述存储器还包括一个或者一个以上的程序，一个或者一个以上程序存储于存储器中，被配置由CPU 1101执行。

请参考图21，示出了本申请一个示例性实施例提供的终端1200的结构框图。该终端1200可以是：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group AudioLayer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts GroupAudio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端1200还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端1200包括有：处理器1201和存储器1202。

处理器1201可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1201可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1201也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1201可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1201还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1202可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1202还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1202中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1201所执行以实现本申请中方法实施例提供的医保数据处理方法。

在一些实施例中，终端1200还可选包括有：外围设备接口1203和至少一个外围设备。处理器1201、存储器1202和外围设备接口1203之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口1203相连。具体地，外围设备包括：射频电路1204、触摸显示屏1205、摄像头1206、音频电路1207和电源1208中的至少一种。

外围设备接口1203可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器1201和存储器1202。在一些实施例中，处理器1201、存储器1202和外围设备接口1203被集成在同一芯片或电路板上；在一些其他实施例中，处理器1201、存储器1202和外围设备接口1203中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路1204用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路1204通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1204将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1204包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路1204可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路1204还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏1205用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1205是触摸显示屏时，显示屏1205还具有采集在显示屏1205的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1201进行处理。此时，显示屏1205还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1205可以为一个，设置终端1200的前面板；在另一些实施例中，显示屏1205可以为至少两个，分别设置在终端1200的不同表面或呈折叠设计；在再一些实施例中，显示屏1205可以是柔性显示屏，设置在终端1200的弯曲表面上或折叠面上。甚至，显示屏1205还可以设置成非矩形的不规则图形，也即异形屏。显示屏1205可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode，有机发光二极管)等材质制备。

摄像头组件1206用于采集图像或视频。可选地，摄像头组件1206包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1206还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路1207可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1201进行处理，或者输入至射频电路1204以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端1200的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1201或射频电路1204的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1207还可以包括耳机插孔。

电源1208用于为终端1200中的各个组件进行供电。电源1208可以是交流电、直流电、一次性电池或可充电电池。当电源1208包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端1200还包括有一个或多个传感器1209。该一个或多个传感器1209包括但不限于：加速度传感器1210、陀螺仪传感器1211、压力传感器1212、光学传感器1213以及接近传感器1214。

加速度传感器1210可以检测以终端1200建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1210可以用于检测重力加速度在三个坐标轴上的分量。处理器1201可以根据加速度传感器1210采集的重力加速度信号，控制触摸显示屏1205以横向视图或纵向视图进行用户界面的显示。加速度传感器1210还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器1211可以检测终端1200的机体方向及转动角度，陀螺仪传感器1211可以与加速度传感器1210协同采集用户对终端1200的3D动作。处理器1201根据陀螺仪传感器1211采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器1212可以设置在终端1200的侧边框和/或触摸显示屏1205的下层。当压力传感器1212设置在终端1200的侧边框时，可以检测用户对终端1200的握持信号，由处理器1201根据压力传感器1212采集的握持信号进行左右手识别或快捷操作。当压力传感器1212设置在触摸显示屏1205的下层时，由处理器1201根据用户对触摸显示屏1205的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

光学传感器1213用于采集环境光强度。在一个实施例中，处理器1201可以根据光学传感器1213采集的环境光强度，控制触摸显示屏1205的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏1205的显示亮度；当环境光强度较低时，调低触摸显示屏1205的显示亮度。在另一个实施例中，处理器1201还可以根据光学传感器1213采集的环境光强度，动态调整摄像头组件1206的拍摄参数。

接近传感器1214，也称距离传感器，通常设置在终端1200的前面板。接近传感器1214用于采集用户与终端1200的正面之间的距离。在一个实施例中，当接近传感器1214检测到用户与终端1200的正面之间的距离逐渐变小时，由处理器1201控制触摸显示屏1205从亮屏状态切换为息屏状态；当接近传感器1214检测到用户与终端1200的正面之间的距离逐渐变大时，由处理器1201控制触摸显示屏1205从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图21中示出的结构并不构成对终端1200的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

本申请还提供了一种电子设备(终端或服务器)，该电子设备包括处理器和存储器，存储器中存储有至少一条指令，至少一条指令由处理器加载并执行以实现上述各个方法实施例提供的医保数据处理方法。

本申请实施例还提供一种计算机可读存储介质，该可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述医保数据处理方法。

提供了一种计算机程序产品或计算机程序，上述计算机程序产品或计算机程序包括计算机指令，上述计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取上述计算机指令，处理器执行上述计算机指令，使得上述电子设备执行如上所述的医保数据处理方法。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，该计算机可读存储介质可以是上述实施例中的存储器中所包含的计算机可读存储介质；也可以是单独存在，未装配入终端中的计算机可读存储介质。该计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述医保数据处理方法。

可选地，该计算机可读存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、固态硬盘(SSD，Solid State Drives)或光盘等。其中，随机存取记忆体可以包括电阻式随机存取记忆体(ReRAM,Resistance RandomAccess Memory)和动态随机存取存储器(DRAM，Dynamic Random Access Memory)。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，上述提到的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (17)

1.一种医保数据处理系统，其特征在于，所述系统包括：客户端和平台服务器；

所述客户端，用于在第一用户界面上显示医保图形码，所述医保图形码携带有医保电子凭证，所述医保电子凭证签约有信用结算；

所述平台服务器，用于接收医疗机构对应的第一服务器发送的信用结算下单请求，所述信用结算下单请求携带有所述医保电子凭证和信用结算订单，所述信用结算订单是所述第一服务器与医保机构对应的第三服务器，对所述医保电子凭证对应的医保处方进行结算确认后的自费订单，所述信用结算订单是所述第一服务器在确认所述医保电子凭证签约有所述信用结算后，将至少两个信用结算订单合并后生成的合并订单；

所述平台服务器，用于调用信用机构对应的第二服务器对所述信用结算订单进行结算处理，将所述第二服务器的第一结算结果发送至所述第一服务器和所述客户端；

所述客户端，用于在第二用户界面上显示结算结果，所述结算结果包括所述第一结算结果和第二结算结果，所述第二结算结果是由所述第三服务器发送至所述第一服务器的所述医保电子凭证对应的医保结算的结果。

2.根据权利要求1所述的系统，其特征在于，所述平台服务器，还用于接收所述医疗机构对应的所述第一服务器发送的签约查询请求；根据所述签约查询请求调用所述信用机构对应的所述第二服务器查询所述医保电子凭证的签约信息，将所述签约信息返回至所述第一服务器。

3.根据权利要求2所述的系统，其特征在于，所述平台服务器，还用于在所述医保电子凭证开启有所述信用结算的使用权限时，将所述签约信息和所述使用权限的启用信息返回至所述第一服务器。

4.根据权利要求1至3任一所述的系统，其特征在于，所述合并订单是由所述第一服务器在接收到就医结束信号后，将所述至少两个信用结算订单进行合并得到的；

其中，所述就医结束信号是所述第一服务器对应的医疗客户端在接收到医护人员触发的就医结束操作后，发送至所述第一服务器的；或者，所述就医结束信号是所述第一服务器在指定时间自动触发生成的。

5.根据权利要求1至3任一所述的系统，其特征在于，所述合并订单所需结算的结算金额小于所述医保电子凭证签约的信用结算额度。

6.根据权利要求1至3任一所述的系统，其特征在于，

所述信用结算订单是所述第一服务器与所述第三服务器对所述医保电子凭证对应的医保处方进行预结算后生成的；

或者，

所述信用结算订单是所述第一服务器与所述第三服务器对所述医保电子凭证对应的医保处方进行试结算后生成的。

7.根据权利要求1至3任一所述的系统，其特征在于，

所述平台服务器，还用于向所述客户端发送所述信用结算的授权请求页面；

所述客户端，还用于显示所述授权请求页面；在接收到授权操作时，向所述平台服务器发送授权信号；

所述平台服务器，还用于根据所述授权信号向所述第二服务器发送所述医保电子凭证进行签约；在接收到所述第二服务器发送的签约信息时，向所述医保机构对应的第三服务器同步所述签约信息。

8.根据权利要求7所述的系统，其特征在于，所述平台服务器，还用于根据所述授权信号向所述第二服务器发送所述医保电子凭证；在接收到所述第二服务器根据所述医保电子凭证发送的查询请求时，向所述第二服务器发送所述医保电子凭证对应的用户信息和参保信息，所述用户信息和所述参保信息用于与所述第二服务器签约所述信用结算。

9.根据权利要求1至3任一所述的系统，其特征在于，

所述平台服务器，还用于向所述客户端发送所述信用结算的解约请求页面；

所述客户端，还用于显示所述解约请求页面；在接收到解约操作时，向所述平台服务器发送解约信号；

所述平台服务器，还用于根据所述解约信号向所述第二服务器发送所述医保电子凭证进行解约；在接收到所述第二服务器发送的解约信息时，向所述医保机构对应的第三服务器同步所述解约信息。

10.根据权利要求9所述的系统，其特征在于，所述平台服务器，还用于根据所述解约信号向所述第二服务器发送所述医保电子凭证；在接收到所述第二服务器根据所述医保电子凭证发送的查询请求时，向所述第二服务器发送所述医保电子凭证对应的用户信息和参保信息，所述用户信息和所述参保信息用于与所述第二服务器解约所述信用结算。

11.根据权利要求1至3任一所述的系统，其特征在于，所述医保电子凭证采用周期更新的动态授权码表示，所述周期与所述动态授权码的有效时长对应。

12.一种医保数据处理方法，其特征在于，所述方法应用于客户端中，所述方法包括：

在第一用户界面上显示医保图形码，所述医保图形码携带有医保电子凭证，所述医保电子凭证签约有信用结算；

在第二用户界面上显示结算结果，所述结算结果包括第一结算结果和第二结算结果；所述第一结算结果是由平台服务器接收医疗机构对应的第一服务器发送的信用结算下单请求，所述信用结算下单请求携带有所述医保电子凭证和信用结算订单，调用信用机构对应的第二服务器对所述信用结算订单进行结算处理，之后返回所述第一服务器和所述客户端的，所述信用结算订单是所述第一服务器与医保机构对应的第三服务器，对所述医保电子凭证对应的医保处方进行结算确认后的自费订单，所述信用结算订单是所述第一服务器在确认所述医保电子凭证签约有所述信用结算后，将至少两个信用结算订单合并后生成的合并订单；所述第二结算结果是由所述第三服务器发送至所述第一服务器的所述医保电子凭证对应的医保结算的结果。

13.一种医保数据处理方法，其特征在于，所述方法应用于平台服务器中，所述方法包括：

接收医疗机构对应的第一服务器发送的信用结算下单请求，所述信用结算下单请求携带有医保电子凭证和信用结算订单，所述医保电子凭证是从客户端上显示的医保图形码中获取得到的，所述医保电子凭证签约有信用结算，所述信用结算订单是所述第一服务器与医保机构对应的第三服务器，对所述医保电子凭证对应的医保处方进行结算确认后的自费订单，所述信用结算订单是所述第一服务器在确认所述医保电子凭证签约有所述信用结算后，将至少两个信用结算订单合并后生成的合并订单；

调用信用机构对应的第二服务器对所述信用结算订单进行结算处理；

将所述第二服务器的第一结算结果发送至所述第一服务器和所述客户端。

14.一种医保数据处理装置，其特征在于，所述装置包括：

显示模块，用于在第一用户界面上显示医保图形码，所述医保图形码携带有医保电子凭证，所述医保电子凭证签约有信用结算；

所述显示模块，还用于在第二用户界面上显示结算结果，所述结算结果包括第一结算结果和第二结算结果；所述第一结算结果是由平台服务器接收医疗机构对应的第一服务器发送的信用结算下单请求，所述信用结算下单请求携带有所述医保电子凭证和信用结算订单，调用信用机构对应的第二服务器对所述信用结算订单进行结算处理，之后返回所述第一服务器和客户端的，所述信用结算订单是所述第一服务器与医保机构对应的第三服务器，对所述医保电子凭证对应的医保处方进行结算确认后的自费订单，所述信用结算订单是所述第一服务器在确认所述医保电子凭证签约有所述信用结算后，将至少两个信用结算订单合并后生成的合并订单；所述第二结算结果是由所述第三服务器发送至所述第一服务器的所述医保电子凭证对应的医保结算的结果。

15.一种医保数据处理装置，其特征在于，所述装置包括；

接收模块，用于接收医疗机构对应的第一服务器发送的信用结算下单请求，所述信用结算下单请求携带有医保电子凭证和信用结算订单，所述医保电子凭证是从客户端上显示的医保图形码中获取得到的，所述医保电子凭证签约有信用结算，所述信用结算订单是所述第一服务器与医保机构对应的第三服务器，对所述医保电子凭证对应的医保处方进行结算确认后的自费订单，所述信用结算订单是所述第一服务器在确认所述医保电子凭证签约有所述信用结算后，将至少两个信用结算订单合并后生成的合并订单；

调用模块，用于调用信用机构对应的第二服务器对所述信用结算订单进行结算处理；

发送模块，用于将所述第二服务器的第一结算结果发送至所述第一服务器和所述客户端。

16.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一段程序，所述至少一段程序由所述处理器加载并执行以实现如权利要求12或13所述的医保数据处理方法。

17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一段程序，所述至少一段程序由处理器加载并执行以实现如权利要求12或13所述的医保数据处理方法。

Images