具体实施方式

通常，在用户就医过程中，当医生开具医疗订单后，用户需要先支付医疗订单对应的费用，然后才能获取医疗订单对应的医疗资源，例如，才能去取药、化验、检查等。然而，由于医院的客流量通常非常大，因此，用户在支付医疗订单时通常需要在交费窗口处或自助机处排队，这会加长用户的就医时间，导致用户的就医效率低，降低了用户的就医体验。

另外，目前可以通过智能终端来进行交费，例如，当医生开具医疗订单后，可以通过手机扫码来进行支付，但是这本质上并未改变用户的就医流程，仍然需要用户先支付订单再获取订单对应的医疗资源，依然存在用户就医效率低的问题。

鉴于此，本说明书的实施例提出了一种先享后付的信用就医方案，使得用户在就医过程中无需花费时间进行订单支付，极大地提升了用户的就医效率，提升用户的就医体验。

为使本说明书一个或多个实施例的目的、技术方案和优点更加清楚，下面将结合本说明书具体实施例及相应的附图对本说明书一个或多个实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本说明书一个或多个实施例保护的范围。

应当理解，尽管在本申请文件中可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。

以下结合附图，详细说明本说明书各实施例提供的技术方案。

图1为本说明书实施例提供的一种信用支付方法的整体方案流程示意图。在本说明书的实施例中，支付服务系统中可以包括支付客户端和支付服务端，其中，支付客户端可以是安装于用户使用的终端设备上的应用程序或小程序。如图1所示，在用户授权的情况下，支付服务系统可以冻结用户的账户资源，并通知医院信息系统，由医院信息系统标记信用就医用户。由此，当信用就医用户实际就医时，可以在未支付医疗订单的情况下先获取到医疗订单对应的医疗资源，例如，可以在未支付挂号单的情况下取号，可以在未支付诊间订单的情况下取药、检查、化验等。而对于未支付且已获取医疗资源的订单，可以由支付服务系统来基于已冻结的账户资源进行结算。

其中，所述支付服务系统可以包括第三方支付平台系统。所述医院信息系统可以是指利用计算机软硬件技术和网络通信技术等现代化手段，对医院及其所属各部门的人流、物流、财流进行综合管理，对在医疗活动各阶段产生的数据进行采集、存储、处理、提取、传输、汇总，加工形成各种信息，从而为医院的整体运行提供全面的自动化管理及各种服务的信息系统。在本说明书的实施例中，所述医院信息系统具体可以包括满足医疗要求的医疗信息系统。所述医疗信息系统，具体可以是包括账户维护、支付、取药、化验等各个就诊环节管理的信息的系统。

基于该方案，使得用户在就医过程中无需花费时间进行订单支付，从而提升用户的就医效率，改善用户的就医体验。

接下来，将针对说明书实施例提供的一种就医先享后付方法结合附图进行具体说明。

图2为本说明书实施例提供的一种信用支付方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于支付服务系统的程序，具体地，可以为搭载于支付服务系统的服务器的程序。

如图2所示，该流程可以包括以下步骤：

步骤202：接收对于用户的待支付医疗订单的结算请求；所述用户已获得所述待支付医疗订单对应的医疗资源；所述结算请求中携带结算账户标识。

其中，所述结算请求可以是医院信息系统生成并发送给支付服务系统的。所述用户可以是就医用户。所述用户已获得所述待支付医疗订单对应的医疗资源，可以意味着，所述用户是具有信用就医权限的用户。所述信用就医权限为，在未支付医疗订单的情况下使用未支付的所述医疗订单对应的医疗资源的权限。

在本说明书的实施例中，在接收到信用就医用户的待支付医疗订单之前，支付服务系统需要先建立用户的信用就医权限。具体地，在接收对于用户的待支付医疗订单的结算请求之前，还可以包括：获取信用就医权限申请请求，所述信用就医权限申请请求中携带所述用户的用户标识；然后，响应于所述信用就医权限申请请求，建立所述用户的信用就医权限。

在可选的实施例中，在建立所述用户的信用就医权限之前，需要对所述用户的信用资质进行评价，从而降低待支付医疗订单无法被结算的情况的发送概率，以保障医院在用户信用就医过程中的权益。

具体地，在建立所述用户的信用就医权限之前，还可以包括：根据所述用户的用户标识，获取所述用户的信用评价信息；然后根据所述信用评价信息，判断所述用户是否满足预设信用条件，得到第一判断结果。由此，所述建立所述用户的信用就医权限，具体可以包括：若所述第一判断结果表示所述用户满足所述预设信用条件，则建立所述用户的信用就医权限。

其中，可选地，可以在获取信用就医权限申请请求后，建立所述用户的信用就医权限之前，对所述用户的信用资质进行评价。

或者，可选地，可以在获取信用就医权限申请请求之前，进行对所述用户的信用资质的评价。在这种情况下，在根据所述用户的用户标识，获取所述用户的信用评价信息之前，还可以包括：获取预定触发请求，所述预定触发请求中可以携带所述用户的用户标识。具体地，所述获取预定触发请求，可以是获取医疗资源预定请求。在实践中，所述医疗资源获取请求可以包括挂号请求。

在实际应用时，可以接收支付服务系统的客户端发送的携带所述用户的用户标识的挂号请求；之后，可以对所述用户的信用资质进行评价，若信用评价结果表明所述用户符合预设信用条件，则可以向所述客户端发送包含有信用就医选项的页面显示信息；进而，可以接收到所述客户端在所述信用就医选项被选择的情况下发送的信用就医权限申请请求。

可选地，所述获取所述用户的信用评价信息，并根据所述信用评价信息判断所述用户是否满足预设信用条件，具体可以包括，调用医保局的数据接口，来确定所述用户是否为医保局的黑名单用户。若所述用户不是黑名单用户，则可以建立所述用户的信用就医权限。

或者，可选地，所述获取所述用户的信用评价信息，并根据所述信用评价信息判断所述用户是否满足预设信用条件，具体可以包括，根据所述用户的历史信用行为信息，计算确定所述用户的信用评级。其中，所述历史信用行为信息可以包括所述用户的信用服务使用和履约信息等，不限于此。其中，用于计算确定所述用户的信用评价的方法，可以根据需要选择，例如，可以使用专家经验模型、机器学习模型、深度学习模型等现有技术中的方法，在此不再赘述。

在本说明书的实施例中，在实际建立所述用户的信用就医权限前，需要对授权账户的账户资源进行冻结，以确保医院在用户信用就医过程中的利益。

具体地，所述信用就医权限申请请求中还可以携带有结算账户标识，所述结算账户标识对应的账户可以用于为相应的信用就医用户的待支付医疗订单进行支付。相应地，在判断所述用户是否满足预设信用条件，得到第一判断结果之后，还可以包括：若所述第一判断结果表示所述用户满足所述预设信用条件，则可以对所述结算账户标识对应的账户中的预冻结额度的账户资源进行冻结。

其中，所述预冻结额度可以是由医院信息系统预先指定的，具体地，可以是由用户所挂号的医院的信息系统所指定的；或者，可以是由支付服务系统计算出的。在实践中，可以根据所述用户的资源预定请求中所要预定的具体医疗项目来确定或计算得到所述预冻结额度。

具体可选地，所述医疗资源预定请求中还可以携带有预定医疗项目信息。由此，在获取医疗资源预定请求之后，还可以：根据所述预定医疗项目信息，确定与所述医疗资源预定请求对应的需要对账户资源进行预冻结的预冻结额度。

例如，当所述医疗资源预定请求为挂号请求时，所述挂号请求中可以携带所述用户的用户标识和挂号项目信息，并且所述挂号项目信息中可以包含挂号医院信息、挂号科室信息或挂号医生信息中的至少一者。由此，基于所述挂号项目信息可以确定出需要冻结的预冻结额度。

在实践中，所述医疗资源预定请求中可以携带有用户标识，由此，当确定出需冻结的预冻结额度后，并对结算账户标识对应的账户中的预冻结额度的账户资源进行冻结后，可以建立所述用户标识、所述结算账户标识以及所述结算账户标识对应的账户中预冻结的账户资源的所述预冻结额度三者之间的关联关系。该关联关系可以用于，当对携带所述用户标识的订单进行结算时，可以根据该关联关系确定相应的结算账户，并使用该结算账户中预冻结额度的账户资源来对所述订单进行结算。

在本说明书的实施例中，支付服务系统在确定用户的信用资质和冻结相应的结算账户的账户资源后，可以建立所述用户的信用就医权限。在实践中，为了便于用户在就医过程中，医院信息系统能够及时识别出就医用户是否具有信用就医权限，可以在医院信息系统中建立所述用户的信用就医权限。

具体地，所述建立所述用户的信用就医权限，具体可以包括：向医院信息系统发送权限建立通知信息；所述权限建立通知信息中携带所述用户的用户标识；所述权限建立通知信息用于表示所述支付服务系统确定所述用户符合被授予信用就医权限的条件。

在实际应用时，所述权限建立通知信息中还可以携带有所述结算账户标识以及所述结算账户标识对应的账户中预冻结的账户资源的预冻结额度。由此，所述医院信息系统可以建立所述用户标识、所述结算账户标识以及所述结算账户标识对应的账户中预冻结的账户资源的所述预冻结额度三者之间的关联关系。该关联关系可以用于，当医院信息系统中生成一个订单后，可以通过确定订单携带的用户标识对应的结算账户的预冻结额度中的剩余额度是否足够，来确定是否允许当前订单走先享后付的就医流程。

步骤204：响应于所述结算请求，使用所述结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作。

所述结算账户标识对应的账户，在下文中也可以简称为结算账户。

所述预冻结资源可以是指，设置为不可用于支付除设定订单之外的订单的账户资源。在本说明书的实施例中，所述设定订单可以是与医疗资源预定请求中携带的医疗资源提供方标识(例如，医院标识)对应的订单。

如上文已经描述的，已获得所述待支付医疗订单对应的医疗资源的所述用户，具有信用就医权限，而在设置所述用户的信用就医权限之前，可以预先冻结相应的结算账户中的账户资源。由此，当支付服务系统接收到携带有结算账户标识的结算请求后，能够使用结算账户标识对应的账户中的预冻结资源来执行对于结算请求中的待支付医疗订单的支付。

在本说明书的实施例中，所述预冻结资源，可以是所述结算账户中冻结的实际账户资金，或者，可以是所述结算账户中冻结的信用账户资金。

应当理解，本说明书一个或多个实施例所述的方法中，部分步骤的顺序可以根据实际需要调整，或者可以省略部分步骤。

图2中的方法，通过在具有信用就医权限的用户未支付医疗订单的情况下获取医疗订单对应的医疗资源后，支付服务系统接收针对用户的待支付医疗订单的携带有结算账户标识的结算请求，并响应于结算请求来使用结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作，使得，用户在就医过程中可以在未支付医疗订单的情况下先享用相应的医疗资源，无需花费时间或者排队进行医疗订单的支付，减少了用户的就医过程耗时，提高了用户的就医效率，提升了用户的就医体验。

基于图2的方法，本说明书实施例还提供了该方法的一些具体实施方式，下面进行说明。

在本说明书的实施例中，当使用所述结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作之后，还可以：解除对所述结算账户标识对应的账户中剩余资源的冻结。

在实践中，在解除对所述结算账户标识对应的账户中剩余资源的冻结之前，还需要确定，是否还有与该结算账户标识对应的已建立但未支付的医疗订单。如果不存在所述已建立但未支付的医疗订单，则可以解冻所述剩余资源；如果存在所述已建立但未支付的医疗订单，则需要先对所述已建立但未支付的医疗订单支付后，然后可以解除所述剩余资源。

具体地，在解除对所述结算账户标识对应的账户中剩余资源的冻结之前，还可以包括：查询与所述结算账户标识对应的目标医疗订单的订单状态信息；所述订单状态信息包括订单属性信息和订单支付状态信息。由此，可以基于所述订单状态信息，来解除对所述剩余资源的冻结。

其中，所述订单属性信息可以包括第一属性信息或第二属性信息。其中，所述第一属性信息可以用于表示，相应的医疗订单对应的医疗资源可在未支付的情况下被提供；所述第二属性信息可以用于表示，相应的医疗订单对应的医疗资源在被提供前需要支付。通常，当医疗订单被建立时，可以确定医疗订单的订单属性。例如，当生成挂号单后、当医生开单后，可以确定挂号单、诊间订单的订单属性为第一属性或第二属性。

所述订单支付状态信息可以包括已使用或未使用。其中，所述已使用的订单支付状态可以用于表示，用户已使用相应医疗订单对应的医疗资源；所述未使用的订单使用状态可以用于表示，用户尚未使用相应医疗订单对应的医疗资源。通常，当医疗订单被建立后，其订单使用状态默认为未使用状态。将医疗订单的订单使用状态设置为已使用状态的时机，可以是，例如当用户基于挂号单取号时以及基于诊间订单取药、检查、化验时；或者可以是，例如当用户在医院信息系统的终端上确认要执行前述操作时，具体如，用户在医院信息系统的终端上执行取药确认操作时、用户在化验室或检查室门口的终端上进行刷卡排队操作时。

在实践中，所述基于所述订单状态信息，来解除对所述剩余资源的冻结，具体可以包括：若所述订单状态信息表示存在订单属性为第一属性且订单使用状态为已使用的订单，则需要：先使用所述结算账户标识对应的账户中的预冻结资源，执行对于所述目标医疗订单中的待支付医疗订单的支付操作；然后，再解除对剩余资源的冻结。

在实际应用时，用户可能会主动要求解除对已冻结的账户资源的冻结。例如，可以在支付服务系统接收到接收对于用户的待支付医疗订单的结算请求之前，就要求解除对于结算账户中的预冻结资源的解冻。

具体地，可以获取资源解冻请求，所述资源解冻请求中携带所述结算账户标识，所述资源解冻请求用于请求解冻所述预冻结资源中的剩余资源；然后，可以响应于所述资源解冻请求，查询与所述结算账户标识对应的目标医疗订单的订单状态信息，其中，所述订单状态信息包括订单属性信息和订单支付状态信息；再基于所述订单状态信息，解除对所述剩余资源的冻结。

在本说明书的实施例中，可以在对结算账户中的预冻结额度的账户资源进行冻结后，建立用户的信用就医权限，与之相对应的，当解除对所述结算账户中预冻结资源中剩余资源的解冻后，则需要及时解除所述用户的信用就医权限。

具体地，所述解除对所述剩余资源的冻结之后，还可以包括：在预设时间内，向医院信息系统发送资源解冻信息，所述资源解冻信息中携带所述结算账户标识，所述资源解冻信息用于表示所述支付服务系统已对所述预冻结资源中的剩余资源执行解冻。由此使得，医院信息系统能够及时更新所述用户的信用就医权限。

在上述的信用就医支付方案的基础上，本说明书的实施例还提供了医保信用就医支付方案。具体地，在实际应用中，用户在医疗订单中的实际花费可能一部分需要通过自费结算，即，可以使用结算账户中的资金结算，此处，可能还存在另一部分需要通过医保结算。

在本说明书的实施例中，所述支付服务系统可以保管有所述用户的医保电子凭证信息。所述医保电子凭证，可以是由国家医保信息平台统一签发的、基于医保基础信息库为全体参保人员生成的医保身份识别电子介质。例如，支付服务系统可以是在用户的授权下，从医保信息系统获取的所述用户的医保电子凭证信息并预先存储以便在用户需要时调用。

图3为本说明书实施例提供的一种信用支付方法的整体方案流程示意图。如图3所示，医保信用就医场景下，一方面，在用户授权的情况下，支付服务系统可以冻结用户的账户资源，并通知医院信息系统，由医院信息系统标记信用就医用户，由此，当信用就医用户实际就医时，可以在未支付医疗订单的情况下先获取到医疗订单对应的医疗资源；另一方面，在用户授权的情况下，用户就诊医院的医院信息系统可以从支付服务系统获取用户的医保电子凭证信息。由此，医院信息系统能够基于用户的医保电子凭证信息与医保系统交互，实现待支付订单中医保部分的结算，并且，通过与支付服务系统交互，基于预冻结的账户资源实现待支付订单中自费部分的结算。

在具体的实施例中，所述使用所述结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作之前，还可以包括：响应于医院信息系统的请求，向医院信息系统发送所述用户的医保电子凭证信息；所述医保电子凭证信息用于作为医保结算的凭证。

可选地，所述向医院信息系统发送所述用户的医保电子凭证信息之前，还可以包括：获取对于所述用户的医保电子凭证信息的使用授权操作；所述使用授权操作用于，授予所述支付服务系统将所述用户的所述医保电子凭证信息发送给所述医院信息系统的权限。

在实践中，在获取对于所述用户的医保电子凭证信息的使用授权操作之后，还可以包括：向所述医院信息系统发送凭证获取授权信息；所述凭证获取授权信息中携带所述用户的用户标识；所述凭证获取授权信息用于被所述医院信息系统作为为所述用户建立医保电子凭证可用标签的依据。建立医保电子凭证可用标签的好处在于，在应用时，医院信息系统仅对于具有凭证可用标签的用户的相应的待支付医疗订单结算时向支付服务系统请求获取用户的医保电子凭证信息，而无需针对所有的用户的待支付订单均向支付服务系统发起凭证获取请求，这在一定程度上减少了数据交互量，降低了数据传输负担，提升了信息处理效率。

在本说明书实施例的信用就医先享后付方案场景中，用户可以在支付客户端上发起资源预定请求(例如，挂号请求)，从而触发后续获取用户的预授权、确定用户的信用就医权限以及为信用就医用户的待支付订单进行结算的流程。

而在实际应用时，用户可以在支付客户端上为本人或者为他人发起资源预定请求，例如，用户A可以基于自己的账户为用户B挂号。在这种情况下，可以获取用户A的预授权操作，冻结用户A的账户中的资源，确定用户B的信用就医权限以及使用用户A的账户中的预冻结资源为用户B的待支付订单进行结算。

在医保信用就医的场景下，需要获取用户的医保电子凭证信息，而由于用户的医保电子凭证信息通常是需要与用户的账户绑定的，因此，在医保信用就医场景下，通常需要进行医疗资源预定的账户的持有者与使用医疗资源的就医者的身份一致，以避免出现无法完成医保代扣结算的情况。

具体地，所述向医院信息系统发送所述用户的医保电子凭证信息之前，还可以包括：判断所述结算账户对应的账户用户标识与所述用户标识是否一致，得到第二判断结果。由此，所述向医院信息系统发送所述用户的医保电子凭证信息，具体可以包括：若所述第二判断结果表示所述账户用户标识与所述用户标识一致，则向医院信息系统发送所述用户的医保电子凭证信息。在实际应用时，所述判断所述结算账户对应的账户用户标识与所述用户标识是否一致的操作可以在用户预授权时执行的。

在本说明书的实施例中，在用户授予所述支付服务系统将所述用户的所述医保电子凭证信息发送给所述医院信息系统的权限之后，随时可以主动解除该授权。

具体地，所述获取对于所述用户的医保电子凭证信息的使用授权操作之后，还可以包括：获取对于所述用户的医保电子凭证信息的使用授权解除操作；所述使用授权解除操作用于，解除所述支付服务系统将所述用户的所述医保电子凭证信息发送给所述医院信息系统的权限。

在实践中，在获取对于所述用户的医保电子凭证信息的使用授权解除操作之后，还可以包括：向所述医院信息系统发送凭证获取授权解约信息；所述凭证获取授权解约信息中携带所述用户的用户标识；所述凭证获取授权解约信息用于被所述医院信息系统作为删除所述用户的医保电子凭证可用标签的依据。

与上述应用于支付服务系统的信用支付方法相对应地，本说明书的实施例还提供了应用于医院信息系统的信用支付方法。

图4为本说明书实施例提供的一种信用支付方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于医院信息系统的程序，具体地，可以为搭载于医疗信息系统的程序。

如图4所示，该流程可以包括以下步骤：

步骤402：获取用户的待支付医疗订单；所述用户已获得所述待支付医疗订单对应的医疗资源。

其中，所述用户可以是具有信用就医权限的用户。所述获取用户的待支付医疗订单，具体可以包括：获取所述用户的用户标识对应的目标医疗订单；然后，从所述目标医疗订单中确定出待支付医疗订单，即，从所述目标医疗订单中确定出订单属性为第一属性且订单使用状态为已使用的订单。

基于本说明书的实施例的方案，在用户就医的过程中，当建立医疗订单时，可以根据用户是否具有信用就医权限，来设置订单的订单属性，例如，将具有信用就医权限的用户的医疗订单的订单属性设置为第一属性；之后，在用户基于第一属性的医疗订单获取相应医疗资源后，可以将订单的使用状态设置为已使用。由此，在用户获取相应医疗资源后，可以再执行对于第一属性且已使用的医疗订单的支付。在本说明书的实施例中，待支付医疗订单可以是指订单属性为第一属性且订单使用状态为已使用的医疗订单。

在本说明书的实施例中，所述信用支付方法可以包括：生成所述用户的目标医疗订单；所述目标医疗订单中携带有所述用户的用户标识；然后，基于所述用户标识，查询所述用户是否具有信用就医权限，得到第一查询结果；所述信用就医权限为，在未支付医疗订单的情况下使用未支付的所述医疗订单对应的医疗资源的权限；若所述第一查询结果表示所述用户具有信用就医权限，则将所述目标医疗订单的订单属性设置为第一属性；所述第一属性的医疗订单对应的医疗资源可在未支付的情况下被提供。

其中，所述生成所述用户的目标医疗订单，具体可以包括，例如，生成所述用户的挂号单，生成所述用户的诊间订单等各种用于获取医疗资源的订单。

其中，所述目标医疗订单的订单使用状态默认为未使用状态。所述未使用的订单使用状态，可以用于表示，用户尚未使用相应医疗订单对应的医疗资源；从另一个角度来讲，可以用于表示，尚未从所述结算账户标识对应的账户中的预冻结额度中扣除所述目标医疗订单对应的订单金额值，换言之，所述目标医疗订单尚未使用所述结算账户标识对应的账户中的预冻结额度。

在可选的实施例中，用户的所述信用就医权限可以是基于支付服务系统发送的权限建立通知信息而建立的。具体地，在查询所述用户是否具有信用就医权限之前，还可以包括：获取支付服务系统发送的权限建立通知信息；所述权限建立通知信息中携带所述用户的用户标识；所述权限建立通知信息用于表示所述支付服务系统确定所述用户符合被授予信用就医权限的条件；然后，可以基于所述权限建立通知信息，授予所述用户信用就医权限。所述授予所述用户信用就医权限的方式，具体可以包括，建立所述用户的信用就医标签；所述信用就医标签用于表示所述用户具有信用就医权限。

在实际应用时，医院信息系统获得支付服务系统发送的权限建立通知信息，则表明所述用户符合被授予信用就医权限的条件，具体地，可以包括：所述支付服务系统已经确定所述用户满足预设信用条件、所述支付服务系统已经对所述结算账户标识对应的账户中的预冻结额度的账户资源执行了冻结等。

在本说明书的实施例中，当支付服务系统对所述结算账户标识对应的账户中的预冻结额度的账户资源执行了冻结之后，可以将预冻结额度信息发送给医院信息系统。由此，医院信息系统可以在用户对应的医疗订单建立之后，判断预冻结额度中的剩余额度是否大于当前医疗订单的订单金额，从而确定是否将该医疗订单设置为第一属性的订单。

具体地，由支付服务系统向医院信息系统发送的所述权限建立通知信息中，还携带所述支付服务系统中的结算账户标识以及所述结算账户标识对应的账户中预冻结的资源的预冻结额度信息。所述目标医疗订单中还携带订单金额信息。那么，在将所述目标医疗订单的订单属性设置为第一属性之前，还可以包括：若所述第一查询结果表示所述用户具有信用就医权限，则获取与所述用户标识对应的预冻结额度的当前剩余额度；并判断所述目标医疗订单对应的订单金额值是否小于或等于所述当前剩余额度，得到第三判断结果。所述将所述目标医疗订单的订单属性设置为第一属性，具体可以包括：若所述第三判断结果为是，则将所述目标医疗订单的订单属性设置为第一属性。另外，若所述第三判断结果为否，则可以将所述目标医疗订单的订单属性设置为第二属性；第二属性的医疗订单对应的医疗资源在被提供前需要支付。

基于前述方案，由于在将用户的订单确定为先享后付的第一属性前，预先判断了是否有足够支付该订单的冻结资源，由此，能够在确保用户先享后付以提升就医体验的同时，保障了医疗资源提供方的权益不会受损。

在实际应用时，在生成用户的目标医疗订单之后，用户可以基于已生成的目标医疗订单来或获取相应的医疗资源。例如，基于挂号单取号，或者，基于诊间订单取药、化验、检查等，不限于此。

在本说明书的实施例中，所述信用支付方法还可以包括：接收针对所述用户的目标医疗订单对应的医疗资源的资源获取请求；然后响应于所述资源获取请求，将所述目标医疗订单的订单使用状态设置为已使用。并且，可以响应于所述资源获取请求，来更新所述预冻结资源的剩余额度。

可选地，所述响应于所述资源获取请求，将所述目标医疗订单的订单使用状态设置为已使用，具体可以包括：响应于所述资源获取请求，获取所述目标医疗订单的订单属性信息；然后判断所述目标医疗订单的订单属性是否为第一属性，得到第四判断结果；若所述第四判断结果为是，则将所述目标医疗订单的订单使用状态设置为已使用。

其中，所述已使用的订单使用状态，可以用于表示，用户已经使用了相应医疗订单对应的医疗资源；从另一个角度来讲，可以用于表示，已经从所述结算账户标识对应的账户中的预冻结额度中扣除所述目标医疗订单对应的订单金额值，换言之，所述目标医疗订单已经使用所述结算账户标识对应的账户中的预冻结额度。需要说明的是，此处的使用指的是，在医院信息系统中进行记账处理，而从结算账户中扣除医疗资源的操作需要在结算时由支付服务系统执行。

在实际应用时，对于具有信用就医权限的用户，医院信息系统可以与该用户的用户标识对应地，存储建立该用户的信用就医权限时授权冻结账户资源的结算账户标识，以及，该结算账户中预冻结的账户资源的预冻结额度，即，建立用户标识、结算账户标识与预冻结额度三者之间的关联关系。在用户就医过程中，当用户请求获取订单对应的医疗资源时，可以从所述预冻结额度中扣除订单对应的订单额度，并记录预冻结额度中的剩余额度。

所述资源获取请求中可以携带所述用户的用户标识。而更新所述预冻结资源的剩余额度，具体可以包括：确定与所述用户标识对应的预冻结额度的当前剩余额度；从所述当前剩余额度中扣除所述目标医疗订单对应的订单金额值，得到更新后的剩余额度。

步骤404：确定与所述待支付医疗订单对应的支付账户标识。

步骤406：向订单结算系统发送携带所述支付账户标识的结算请求。

在本说明书的实施例中，所述订单结算系统，可以是指用于与医院信息系统进行交互以完成用户的待支付医疗订单的支付的系统。具体地，所述订单结算系统可以包括支付服务系统，或者，可以包括医保系统。所述支付账户标识可以是指用于对待支付订单对应的订单金额进行结算的账户的标识。具体地，所述支付账户标识可以包括预先设置的、支付服务系统中的结算账户标识，在实践中，可以是手机号、邮箱账号、身份证号等，不限于此；或者，可以包括与就医用户对应的、在医保系统中的用户账户标识，例如，医保电子凭证标识，在实践中，可以是身份证号等信息。

可选地，所述确定与所述待支付医疗订单对应的支付账户标识，具体可以包括：确定支付服务系统中与所述待支付医疗订单对应的结算账户标识；生成携带所述结算账户标识的第一结算请求。相应地，所述向订单结算系统发送携带所述支付账户标识的结算请求，具体可以包括：向所述支付服务系统发送所述第一结算请求；所述第一结算请求用于，请求所述支付服务系统使用所述结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作。

如上文已描述的，由于在建立用户的信用就医权限时，已经建立了用户标识、结算账户标识之间的关联关系。因此，当需要进行结算时，可以根据待支付医疗订单中携带的用户标识，来确定出相应的结算账户标识。

可选地，所述确定与所述待支付医疗订单对应的支付账户标识，具体可以包括：从支付服务系统获取所述用户的医保电子凭证信息。所述确定与所述待支付医疗订单对应的支付账户标识之后，还可以包括：基于所述用户的所述医保电子凭证信息和所述待支付医疗订单信息，确定所述待支付医疗订单对应的预结算信息；所述预结算信息中包括与所述待支付医疗订单对应的医保待付金额信息；然后，基于所述预结算信息，生成第二结算请求；所述第二结算请求用于，请求医保信息系统执行对所述医保待付金额的结算。由此，所述向订单结算系统发送携带所述支付账户标识的结算请求，具体可以包括：向所述医保信息系统发送所述第二结算请求。

其中，从支付服务系统获取所述用户的医保电子凭证信息之前，还可以包括：查询所述用户是否具有医保电子凭证可用标签。若所述查询结果表示与所述用户的用户标识对应地存储有医保电子凭证可用标签，则可以向支付服务系统请求获取所述用户的医保电子凭证信息。其中，所述医保电子凭证可用标签是基于所述支付服务系统发送的凭证获取授权信息所建立的。

在实际应用时，可以在需要发起结算请求时，实时从支付服务系统来获取所述用户的最新的医保电子凭证信息。所述从支付服务系统获取所述用户的医保电子凭证信息，具体可以包括：向所述支付服务系统发送用于获取所述用户的医保电子凭证信息的凭证获取请求；所述凭证获取请求中携带有所述用户的用户标识；然后，接收所述支付服务系统发送的响应于所述凭证获取请求返回的所述用户的医保电子凭证信息。

可选地，所述预结算信息中还可以包括与所述待支付医疗订单对应的自费待付金额信息。所述确定与所述待支付医疗订单对应的支付账户标识之后，还可以包括：基于所述预结算信息，生成第三结算请求；所述第三结算请求用于，请求支付服务系统执行对所述自费待付金额的结算；由此，所述向订单结算系统发送携带所述支付账户标识的结算请求，具体可以包括：向所述支付服务系统发送所述第三结算请求。

在实践中，在对用户的就医订单结算时，医院信息系统可以向当地医保局请求进行预结算，医保局可以根据用户的参保情况、检查项目、订单金额等因素，将待结算的订单总金额拆分为医保待付金额和自费待付金额，其中，医保待付金额由医保承担，自费待付金额由用户承担。

在实际应用中，当医院信息系统获取到用户的医保电子凭证信息之后，可以通过如下方式获取所述待支付医疗订单的预结算信息：将所述医保电子凭证信息和所述待支付医疗订单信息发送至医保信息系统；所述待支付医疗订单信息中至少包含所述用户标识、订单医疗资源信息以及所述订单医疗资对应的资源金额信息；收所述医保信息系统基于所述医保电子凭证信息和所述待支付医疗订单信息返回的预结算信息，所述预结算信息中包括与所述待支付医疗订单对应的医保待付金额信息和与自费待付金额信息。然后，可以基于所述预结算信息，分别与所述医保系统进行医保待付金额的结算，并与所述支付服务系统进行自费待付金额的结算。

应当理解，本说明书一个或多个实施例所述的方法中，部分步骤的顺序可以根据实际需要调整，或者可以省略部分步骤。

图4中的方法，通过当具有信用就医权限的在获取待支付医疗订单对应的医疗资源后，再对待支付医疗订单进行结算，使得，用户在就医过程中可以在未支付医疗订单的情况下先享用相应的医疗资源，无需花费时间或者排队进行医疗订单的支付，减少了用户的就医过程耗时，提高了用户的就医效率，提升了用户的就医体验。

基于图4的方法，本说明书实施例还提供了该方法的一些具体实施方式，下面进行说明。

在可选的实施例中，在授予所述用户信用就医权限之后，还可以包括：获取支付服务系统发送的资源解冻信息；所述资源解冻信息中携带所述结算账户标识；所述资源解冻信息是在所述支付服务系统对所述结算账户标识对应的账户所述预冻结资源中的剩余资源解冻后的预设时间内发送的；然后，可以响应于所述资源解冻信息，解除所述用户的信用就医权限。

在实际应用时，在支付服务系统对预设的结算账户中的预冻结资源进行解冻之前，可以先查询是否有已使用但未支付的先诊后付订单，当不存在已使用未支付的先诊后付订单的情况下，再执行解冻，以避免造成未支付的订单无法支付、导致医院利益损失的情况。具体地，在获取支付服务系统发送的资源解冻信息之前，还可以包括：获取支付服务系统发送的订单状态信息查询请求；所述订单状态信息查询请求是响应于针对所述预冻结资源中的剩余资源的资源解冻请求生成的；响应于所述订单状态信息查询请求，获取与所述用户的用户标识对应的目标医疗订单的订单状态信息；所述订单状态信息包括订单属性信息和订单使用状态信息；向所述支付服务系统发送所述目标医疗订单的订单状态信息，所述订单状态信息用于作为所述支付服务系统使用所述预冻结资源进行支付的依据。

在可选的实施例中，在医保信用就医过程中，医院信息系统还可以：获取所述支付服务系统发送的所述用户的凭证获取授权解约信息；所述凭证获取授权解约信息中携带所述用户的用户标识；然后，可以根据所述凭证获取授权解约信息，删除所述用户的医保电子凭证可用标签。

在以上实施例的基础上，为了便于理解和进一步说明，本说明书实施例提供了一种实际应用场景下，在支付服务系统预授权信用支付的方案流程示意图，如图5所示。

在图5中，步骤501：用户在支付服务系统的客户端或小程序中预约挂号。

步骤502：支付服务系统可以调用医保局的接口，确定待就医的用户是否为医保局黑名单用户，若不是，则引导用户使用信用就医，例如，可以为用户提供信用就医的选项。

步骤503：若用户选择使用信用就医，则执行步骤504；若用户选择不使用信用就医，则进入常规业务流程。常规业务流程例如，在用户支付挂号费用的情况下完成挂号，且该挂号用户在就诊过程中，需要先支付医疗订单对应的费用，才能使用医疗订单对应的医疗资源。

步骤504：判断是否为本人就医。具体地，可以判断挂号请求中携带的就医用户的用户标识与用于挂号的账户对应的账户用户标识是否一致。若为本人就医，则执行步骤507和步骤508；若不是本人就医，则可以进入自费信用就医流程，可选地，可以执行步骤505和步骤506。

步骤505：若不是本人就医，则可选地，可以提醒用户非本人的信用就医仅支持自费支付，不支持医保支付。

步骤506：若不是本人就医，则可选地，可以再次获取用户是否选择信用就医，在此情况下，若用户选择信用就医，则进入自费信用就医流程；若用户不选择信用就医，则可以进入常规业务流程。

需要说明的是，该实施例中的步骤505和步骤506可以省略，不影响用户进入自费信用就医流程，而之所以设置提醒信息以及获取用户的再次选择操作，在于告知用户非本人就医情况下的信用就医无法使用医保结算，以便用户决定是否继续使用信用支付，提升用户的信用支付方案使用体验。

步骤507：若步骤504判断结果为本人就医，则可选地，可以获取用户的信用就医方式选择操作，具体地，可以由用户选择使用医保信用就医或自费信用就医。在实际应用时，可以默认设置为选择医保信用就医。并且在实践中，可以省略步骤507直接进入医保信用就医流程。

步骤508：在选择医保信用就医的情况下，需要确定用户是否已完成医保支付授权。具体地如，可以判断用户是否已授权医院信息系统从支付服务系统获取用户的医保电子凭证信息以用于进行医保代扣结算，若用户未完成医保支付授权，则需要在获取到所述用户的医保支付授权后执行后续步骤。如果用户始终未完成医保支付授权，则可以进入自费信用就医流程或常规业务流程。

步骤509：无论是在医保信用就医流程或自费信用就医流程中，均需要确定用户是否完成自费代扣的授权。具体地，可以判断用户是否已授权支付服务系统对结算账户中的账户资源进行冻结，且授权所述支付服务系统在接收到医院信息系统发送的相应的结算请求时，使用预冻结资源执行对待支付医疗订单的支付。

步骤510：在自费代扣授权完成后，挂号成功。在实践中，可以建立挂号单，并将挂号单设置为第一属性的订单，且默认设置为未使用状态，由此，当用户在实际就医过程中，可以基于该挂号单取号。

另外，本说明书实施例提供了一种实际应用场景下，基于医院信息系统进行医疗订单结算的方案流程示意图，如图6所示。

在图6中，步骤601：通常，可以在用户的当天就诊结束后来进行订单结算。具体地，可以先获取用户对应的订单属性为先享后付的医疗订单，然后基于订单使用状态，判断订单是已使用订单还是未使用订单。后续的结算过程针对已使用订单。

步骤602：对于已使用的待支付订单，可以先基于订单中携带的用户标识，来判断用户是否已签约医保代扣，例如，可以通过确定是否具有医保电子凭证可用标签来判断用户是否已签约医保代扣。若用户已签约医保代扣，则执行步骤603；若用户未签约医保代扣，则直接跳至步骤605。

步骤603：若用户已签约医保代扣，则需要对待支付医疗订单进行订单预结算，得到预结算信息，即，得到待支付的医保待付金额信息和自费待付金额信息。

步骤604：在确定出预结算信息后，可以请求医保系统完成医保待付金额部分的结算。

步骤605：在用户已签约医保代扣的情况下，可以在完成医保待付金额的结算之后或进行医保待付金额的结算同时，请求支付服务系统完成自费待付金额部分的结算。在用户未签约医保代扣的情况下，可以请求支付服务系统完成待支付订单对应的订单金额的结算。至此，可以完成用户信用就医过程中的医疗订单的结算。

基于同样的思路，本说明书实施例还提供了上述方法对应的装置。

图7为本说明书实施例提供的对应于图2的一种信用支付装置的结构示意图。如图7所示，该装置可以包括：

结算请求获取模块702，用于接收对于用户的待支付医疗订单的结算请求；所述用户已获得所述待支付医疗订单对应的医疗资源；所述结算请求中携带结算账户标识；

结算模块704，用于响应于所述结算请求，使用所述结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作。

图8为本说明书实施例提供的对应于图4的一种信用支付装置的结构示意图。如图8所示，该装置可以包括：

待支付订单获取模块802，用于获取用户的待支付医疗订单；所述用户已获得所述待支付医疗订单对应的医疗资源；

支付账户标识确定模块804，用于确定与所述待支付医疗订单对应的支付账户标识；

结算请求发送模块806，用于向订单结算系统发送携带所述支付账户标识的结算请求。

可以理解，上述的各模块是指计算机程序或者程序段，用于执行某一项或多项特定的功能。此外，上述各模块的区分并不代表实际的程序代码也必须是分开的。

基于同样的思路，本说明书实施例还提供了上述方法对应的设备。

图9为本说明书实施例提供的一种信用支付设备的结构示意图。

如图9所示，设备900可以为支付服务系统的服务器，设备900具体可以包括：

至少一个处理器910；以及，

与所述至少一个处理器通信连接的存储器930；其中，

所述存储器930存储有可被所述至少一个处理器910执行的指令920，所述指令被所述至少一个处理器910执行，以使所述至少一个处理器910能够：

接收对于用户的待支付医疗订单的结算请求；所述用户已获得所述待支付医疗订单对应的医疗资源；所述结算请求中携带结算账户标识；

响应于所述结算请求，使用所述结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作。

如图9所示，设备900可以为医院信息系统中的终端设备或服务器，设备900具体可以包括：

至少一个处理器910；以及，

与所述至少一个处理器通信连接的存储器930；其中，

所述存储器930存储有可被所述至少一个处理器910执行的指令920，所述指令被所述至少一个处理器910执行，以使所述至少一个处理器910能够：

获取用户的待支付医疗订单；所述用户已获得所述待支付医疗订单对应的医疗资源；

确定与所述待支付医疗订单对应的支付账户标识；

向订单结算系统发送携带所述支付账户标识的结算请求。

基于同样的思路，本说明书实施例还提供了上述方法对应的计算机可读介质。计算机可读介质上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现以下方法：接收对于用户的待支付医疗订单的结算请求；所述用户已获得所述待支付医疗订单对应的医疗资源；所述结算请求中携带结算账户标识；响应于所述结算请求，使用所述结算账户标识对应的账户中的预冻结资源执行对于所述待支付医疗订单的支付操作。

或者，所述计算机可读指令可被处理器执行以实现以下方法：获取用户的待支付医疗订单；所述用户已获得所述待支付医疗订单对应的医疗资源；确定与所述待支付医疗订单对应的支付账户标识；向订单结算系统发送携带所述支付账户标识的结算请求。

上述对本说明书特定实施例进行了描述，在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可。

本说明书实施例提供的装置、设备与方法是对应的，因此，装置、设备也具有与对应方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置、设备的有益技术效果。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。