CN110504008A - 一种医疗信息管理方法、系统、计算机设备及存储介质 - Google Patents

Abstract

本申请公开了一种医疗信息管理方法、系统、计算机设备及存储介质，在该方案中，由区块链节点接收医院系统的扣费请求，并调用智能合约按照扣费请求对患者智能合约进行扣费，将扣费结果信息上传至区块链，此外，还需要接收医院系统发送的诊疗信息，并确定扣费结果信息与诊疗信息的映射结果，将映射结果上传至区块链。由于在本方案中扣费信息以及诊疗信息均被上传至区块链，使扣费信息以及诊疗信息可以被公开，而且保证不会被篡改，从而提高了医疗信息数据的可信度。

Description

一种医疗信息管理方法、系统、计算机设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种医疗信息管理方法、系统、计算机设备及存储介质。

背景技术

目前，人们在医院进行住院医疗时，通常会涉及三个环节，患者预存费用、医院在对患者治疗期间从预存费用中进行扣费、以及最后患者进行加结账。传统的方案中，医疗费用以及相关明细信息都是由医院集中化管理，对病人不透明，使病人对医疗信息数据缺乏信任，而且医疗信息数据也存在被篡改的风险。

因此，如何提高医疗信息数据的可信度，是本领域技术人员需要解决的技术问题。

发明内容

有鉴于此，本申请提供了一种医疗信息管理方法、系统、计算机设备及存储介质，以在在应用程序代码中检测出内存分配代码。

为实现上述目的，一方面，本申请提供了一种医疗信息管理方法，包括：

接收医院系统发送的扣费请求；

调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链；

接收医院系统发送的诊疗信息；

调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

可选地，所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链，包括：

调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费；

判断所述患者智能合约的余额是否大于或等于待扣费用，所述待扣费用为与所述扣费请求对应的待扣费用；

若否，则记录所述扣费结果信息为扣费失败信息，将所述扣费结果信息添加至区块链；

所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链之后，还包括：

向所述患者系统发送补充余额的通知；

接收所述患者系统发送的补充余额，并更新所述患者智能合约中的余额，以完成所述扣费请求。

又一方面，本申请提供了一种医疗信息管理系统，包括：

扣费请求接收模块，用于接收医院系统发送的扣费请求；

扣费模块，用于调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链；

诊疗信息接收模块，用于接收医院系统发送的诊疗信息；

映射结果确定模块，用于调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

又一方面，本申请提供了一种计算机设备，包括：

处理器和存储器；

其中，所述处理器用于执行所述存储器中存储的程序；

所述存储器用于存储程序，所述程序至少用于：

接收医院系统发送的扣费请求；

调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链；

接收医院系统发送的诊疗信息；

调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

又一方面，本申请提供了一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如上所述的医疗信息管理方法。

本申请实施例提供的一种医疗信息管理方法，由区块链节点接收医院系统的扣费请求，并调用智能合约按照扣费请求对患者智能合约进行扣费，将扣费结果信息上传至区块链，此外，还需要接收医院系统发送的诊疗信息，并确定扣费结果信息与诊疗信息的映射结果，将映射结果上传至区块链。由于在本方案中扣费信息以及诊疗信息均被上传至区块链，使扣费信息以及诊疗信息可以被公开，而且保证不会被篡改，从而提高了医疗信息数据的可信度。

本申请由区块链节点接收医院系统的扣费请求，并调用智能合约按照扣费请求对患者智能合约进行扣费，将扣费结果信息上传至区块链，此外，还需要接收医院系统发送的诊疗信息，并确定扣费结果信息与诊疗信息的映射结果，将映射结果上传至区块链。由于在本方案中扣费信息以及诊疗信息均被上传至区块链，使扣费信息以及诊疗信息可以被公开，而且保证不会被篡改，从而提高了医疗信息数据的可信度。

附图说明

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

图1示出了本申请实施例的一种医疗信息管理方法所适用的硬件组成框架示意图；

图2示出了本申请实施例的一种医疗信息管理方法的一种流程示意图；

图3示出了本申请实施例的一种医疗信息管理方法的一种流程示意图；

图4示出了本申请实施例的一种医疗信息管理方法的一种流程示意图；

图5示出了本申请实施例的一种医疗信息管理方法的一种流程示意图；

图6示出了本申请实施例的一种医疗信息管理方法的一种流程示意图；

图7示出了本申请实施例的一种医疗信息管理系统的一个实施例的组成结构示框图；

图8示出了本申请实施例的一种计算机设备的一个实施例的组成结构示意图。

具体实施方式

传统的方案中，医疗费用以及相关明细信息都是由医院集中化管理，对病人不透明，使病人对医疗信息数据缺乏信任，而且医疗信息数据也存在被篡改的风险。而本方案提供一种医疗信息管理方法、系统、计算机设备及存储介质，可以提高医疗信息数据的可信度。

为了便于理解，先对本申请的医疗信息管理方法对应的方案所适用的硬件组成框架进行介绍。可以参见图1，其中，图1示出了本申请一种医疗信息管理方法所适用的硬件组成框架示意图。

请参考图1，由图1可知，该硬件组件框架可以包括患者节点设备11、医院节点设备12、区块链网络13、其中区块链网络13中包括多个区块链节点130。其中，患者节点设备11中安装有患者系统，医院节点设备12中安装有医院系统。区块链网络节点130存储有智能合约，通过智能合约管理医疗信息。

其中患者节点设备11、医院节点设备12的数量均可以是一个或一个以上，患者节点设备11、医院节点设备12与区块链网络13之间国通网络实现通信连接。患者节点设备具体可以是移动终端也可以是PC端，医院节点设备12具体可以是PC端、也可以是医疗检查仪器，网络可以是无线网络(如WIFI等)，也可以是有线网络；既可以是互联网，也可以是局域网。

举例说明，请参考图2，患者节点设备11通过与区块链网络13交互，更新患者智能合约中的金额，医院节点设备12向区块链网络13发送扣费请求后，区块链网络13中的节点调用医院智能合约，并根据扣费请求在患者这能合约中进行扣费，并将扣费结果信息进行共识、添加至区块链；医院节点设备12向区块链网络13发送诊疗信息，区块链网络13中的节点调用医院智能合约将诊疗信息与扣费结果信息进行映射，将映射结果添加至区块链。

结合以上共性，参见图3，其示出了本申请一种医疗信息管理方法一个实施例的流程图，本实施例的方法可以包括：

S101，接收医院系统发送的扣费请求。

S102，调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链。

医院智能合约被同步在每一个区块链节点上，在接收到扣费请求后，区块链节点调用医院智能合约，医院智能合约被执行时向患者智能合约地址进行扣费，并记录扣费结果信息，将扣费结果信息上传至区块链。

扣费结果信息具体包括扣费金额以及是否扣费成功的信息。

在一种实现方式中，所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链之前，还包括：

利用所述医院系统的标识信息验证所述扣费请求是否合法；

若是，则继续执行所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链的步骤。

需要说明的是，在接收到医院系统发送的扣费请求后，区块链节点需要对请求进行验证，验证该扣费请求是否为医院系统所发的扣费请求，具体验证方法可以采用公私钥签名的验证方法进行。

在另一种实现方式中，所述方法还包括：

接收所述患者系统发送的扣费门限值；

将所述扣费门限值更新至所述医院智能合约；

相应的，所述调用医院智能合约以根据所述扣费请求在所述患者智能合约中进行扣费，包括：

调用所述医院智能合约判断所述扣费请求对应的待扣费用是否小于或等于所述扣费门限值；

若是，则在所述患者智能合约中进行扣除所述待扣费用。

具体的，在本方案中，患者系统可以设置单次扣费的门限值，在门限值范围内的扣费金额才能够被直接扣取，否则需要患者系统的授权。

在区块链节点接收到扣费门限值后，将扣费门限值更新至医院智能合约，医院智能合约被执行时，首先判断当前扣费请求对应的待扣费用是否小于或等于扣费门限值，若是，则直接扣取相应的费用，否则可以向患者系统发送扣费通知，以使患者系统授权相应的费用扣取请求，或者调整扣费门限值。

S103，接收医院系统发送的诊疗信息。

在本方案中，为了使扣费请求对应的费用信息更加可信，还需要将与患者系统对应的诊疗信息上传至区块链。首先接收医院系统发送的诊疗信息，该诊疗信息中包括患者的标识信息以及具体的诊疗数据。

需要说明的是，在前述方案中已经说明，医院节点设备具体可以包括一个或多个，在本方案中，医院系统具体可以是不同医生用户所适用的普通计算机设备中的系统，由医生用户输入诊疗信息后，再将诊疗信息发送至区块链网络，也可以是医院的医疗检查仪器中的系统，将医疗检查仪器连接网络，在完成一个患者用户的医疗检查后，将诊疗信息发送至区块链网络。

S104，调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

具体的，触发医院智能合约，将对应同一患者用户的诊疗信息与扣费结果信息进行映射，得到映射结果，将映射结果进行共识，添加至区块链。

由此可见，本申请实施例提供的一种医疗信息管理方法，由区块链节点接收医院系统的扣费请求，并调用智能合约按照扣费请求对患者智能合约进行扣费，将扣费结果信息上传至区块链，此外，还需要接收医院系统发送的诊疗信息，并确定扣费结果信息与诊疗信息的映射结果，将映射结果上传至区块链。由于在本方案中扣费信息以及诊疗信息均被上传至区块链，使扣费信息以及诊疗信息可以被公开，而且保证不会被篡改，从而提高了医疗信息数据的可信度。

在一种可能的情况中，为了方便医院系统进行扣费，可以由患者系统预先授权医院系统一定的初始额度，以便于医院系统直接对初始额度进行扣费。

请参见图4，在上述实施例的基础上，所述接收医院系统发送的扣费请求之前，还包括：

S201，接收患者系统发送的初始额度授权请求。

需要说明的是，初始额度授权请求包括具体的初始额度以及对应的医院系统，初始额度即可以被医院智能合约扣取的额度。

S202，调用患者智能合约以更新所述患者系统的初始额度与余额。

具体的，患者用户的余额信息均由患者智能合约管理，在更新初始额度是，首先需要调用患者智能合约，扣减相应的余额来增加其初始额度。

区块链节点调用患者智能合约更新患者系统对应的初始额度以及余额，需要说明的是，余额即发生扣费事件后初始额度中所剩余的额度。

S203，调用医院智能合约以更新所述患者系统的初始额度。

具体的，调用医院智能合约，在医院智能合约中更新患者系统的初始额度，从而在执行扣费请求时，医院智能合约即可按照初始额度来向患者智能合约进行扣费。

S204，调用医院智能合约以根据所述扣费请求在所述患者智能合约的初始额度中进行扣费。

可见，在本方案中，医院智能合约在进行扣费时，可以直接从患者系统授权的初始额度中进行扣费，无需再向患者系统发送扣费请求，使扣费流程更加简便快捷。

请参见图5，本申请实施例提供了一种医疗信息管理方法，具体包括：

S301，接收所述患者系统发送的结账请求。

患者系统将结账请求发送至区块链节点，以触发结账事件。

需要说明的是，结账请求被发送到区块链节点后，为了保证请求的真实可靠性，可以对结账请求进行验证，具体可以通过公私钥验证患者系统标识签名的方式进行。

S302，调用所述医院智能合约以获取对应所述患者智能合约的账本信息，所述账本信息包括所述扣费结果和所述患者智能合约中的余额。

触发医院智能合约，获取对应患者智能合约的账本信息，账本信息包括了患者系统对应的扣费结果以及当前的余额。需要说明的是，扣费结果具体包括已完成扣费的扣费请求以及未完成扣费的扣费请求，当扣费结果中存在未完成扣费的扣费请求时，不能够立即执行结账的操作，还需要等待患者系统完成相应的扣费请求。

S303，判断所述患者智能合约是否存在未完成的扣费请求。

S304，若是，则向所述患者系统发送提示信息。

在本方案中，当患者智能合约对应的扣费结果中存在未完成的扣费请求时，向患者系统发送提示信息，提示信息的具体内容在本方案中不做具体限定，例如可以包括结账失败的标识、未完成的扣费请求的信息等，从而使患者系统继续执行扣费相关的操作，如，向智能合约账户中增加余额。

S305，若否，则记录结账标识，将所述余额与所述结账标识作为结账信息上传至区块链。

如果患者智能合约对应的扣费结果中不存在未完成的扣费请求时，则记录结账标识，并将结账标识、余额作为结账信息上传至区块链，以存储结账完成的信息。

可见，本发明实施例通过智能合约实现结账事件，并当患者存在未完成的扣费请求时，不进行结账，并向患者系统发送提示信息，当患者不存在未完成的扣费请求时，记录结账标识，并将结账标识、余额上传至区块链，使结账信息公开、不可篡改。

在另一实施例中：在治疗过程中，余额不在在授权范围内，可进行补缴，减少出院结账时间。

具体的，在一个具体的实施例中，调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链，包括：

调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费；

判断所述患者智能合约的余额是否大于或等于待扣费用，所述待扣费用为与所述扣费请求对应的待扣费用；

若否，则记录所述扣费结果信息为扣费失败信息，将所述扣费结果信息添加至区块链；

所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链之后，还包括：

向所述患者系统发送补充余额的通知；

接收所述患者系统发送的补充余额，并更新所述患者智能合约中的余额。

需要说明的是，补缴授权完成后，智能合约会检测患者是否存在扣费结果信息为扣费失败信息的，如果有，智能合约扣除患者合约地址相应的额度权益，并标记为扣费成功信息。

在本方案中，当患者智能合约的余额不足以完成扣费时，记录扣费失败的信息，并调用智能合约向患者系统发送通知，以使患者系统补充足够的余额，从而完成扣费，从而在结账环节时，可以直接完成结账，无需等待患者系统补缴费用，节省了在结账环节的等待时间。

请参见图6，本申请实施例提供了一种医疗信息管理方法，具体包括：

S401，接收所述医院系统和/或所述患者系统发送的对所述诊疗信息的查看请求。

需要说明的是，在本方案中，为了保证查看请求的真实可靠性，可以对查看请求进行验证，具体可以通过公私钥验证患者系统标识签名的方式进行。

S402，验证所述查看请求的发送方是否有对诊疗信息的查看权限。

在本实施例中，由于诊疗信息是被公开存储在区块链上，任一节点均可以从区块链获取诊疗信息，为了保证诊疗信息的隐私性，在接收到医院系统和/或患者系统发送的对诊疗信息的查看请求时，触发权限管理合约，首先验证查看请求的发送方是否具备查看权限，即，验证该医院系统和/或患者系统是否有对该诊疗信息进行查看的权限。

S403，若有，获取所述诊疗信息，并将所述诊疗信息返回至所述发送方。

在本方案中，具体可以记录返回诊疗信息的内容，该内容具体可以包括诊疗信息的标识、查看请求的发送方的标识、以及查看时间等信息，以便后续对查看请求的相关信息进行追溯。

在一种可能的情况中，所述验证所述查看请求的发送方是否有对诊疗信息的查看权限之后，还包括：

S404，当所述查看请求的发送方没有诊疗信息的查看权限时，记录查看失败信息，并将所述查看失败信息上传至区块链。

需要说明的是，当查看请求的发送方没有诊疗信息的查看权限，也需要记录查看请求失败信息，并将查看失败信息上传至区块链。具体可以记录查看请求的发送方的标识、接收查看请求的时间，以追溯非法访问诊疗信息的请求方的相关信息。

可见，在本方案中，在接收到对于诊疗信息的查看请求时，先利用权限管理合约来验证查看请求的发起方是否具有对该诊疗信息的查看请求，如果有再反馈诊疗信息，从而保证了诊疗信息的隐私性。

另一方面，本申请还提供了一种医疗信息管理系统。参见图7，本申请实施例提供的一种医疗信息管理系统，包括：

扣费请求接收模块501，用于接收医院系统发送的扣费请求；

扣费模块502，用于调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链；

诊疗信息接收模块503，用于接收医院系统发送的诊疗信息；

映射结果确定模块504，用于调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

可选地，所述系统还包括：

扣费请求验证模块，用于利用所述医院系统的标识信息验证所述扣费请求是否合法；

若是，则继续调用所述扣费模块502。

可选地，所述系统还包括：

初始额度授权请求接收模块，用于接收患者系统发送的初始额度授权请求；

第一额度更新模块，用于调用患者智能合约以更新所述患者系统的初始额度与余额；

第二额度更新模块，用于调用医院智能合约以更新所述患者系统的初始额度；

相应的，所述扣费模块502，具体用于：

调用医院智能合约以根据所述扣费请求在所述患者智能合约的初始额度中进行扣费。

可选地，所述系统还包括：

扣费门限值接收模块，用于接收所述患者系统发送的扣费门限值；

扣费门限值更新模块，用于将所述扣费门限值更新至所述医院智能合约；

相应的，所述扣费模块502，具体用于：

调用所述医院智能合约判断所述扣费请求对应的待扣费用是否小于或等于所述扣费门限值；

若是，则在所述患者智能合约中进行扣除所述待扣费用。

可选地，所述系统还包括：

结账请求接收模块，用于接收所述患者系统发送的结账请求；

账本信息获取模块，用于调用所述医院智能合约以获取对应所述患者智能合约的账本信息，所述账本信息包括所述扣费结果和所述患者智能合约中的余额；

判断模块，用于判断所述患者智能合约是否存在未完成的扣费请求；

提示信息发送模块，用于所述患者智能合约存在未完成的扣费请求时，向所述患者系统发送提示信息；

结账标识记录模块，用于所述患者智能合约不存在未完成的扣费请求时，记录结账标识，将所述余额与所述结账标识作为结账信息上传至区块链。

可选地，扣费模块502包括：

扣费单元，用于调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费；

余额判断单元，用于判断所述患者智能合约的余额是否大于或等于待扣费用，所述待扣费用为与所述扣费请求对应的待扣费用；

失败信息记录单元，用于所述患者智能合约的余额小于待扣费用时，记录所述扣费结果信息为扣费失败信息，将所述扣费结果信息添加至区块链；

可选地，所述系统还包括：

查看请求接收模块，用于接收所述医院系统和/或所述患者系统发送的对所述诊疗信息的查看请求；

权限验证模块，用于验证所述查看请求的发送方是否有对诊疗信息的查看权限；

诊疗信息发送模块，用于所述查看请求的发送方有对诊疗信息的查看权限时，获取所述诊疗信息，并将所述诊疗信息返回至所述发送方。

可选地，所述系统还包括：

查看失败信息记录模块，用于当所述查看请求的发送方没有诊疗信息的查看权限时，记录查看失败信息，并将所述查看失败信息上传至区块链。

进一步地，本申请实施例还提供了一种计算机设备。图8示出了本申请一种医疗信息管理方法所适用的计算机设备示意图。

由图8可知，该计算机设备60可以包括：处理器61、存储器62、通信接口63、输入单元64和显示器65和通信总线66。

处理器61、存储器62、通信接口63、输入单元64、显示器65、均通过通信总线66完成相互间的通信。

在本申请实施例中，该处理器61，可以为中央处理器(Central Processing Unit，CPU)，特定应用集成电路，数字信号处理器、现成可编程门阵列或者其他可编程逻辑器件等。该处理器可以调用存储器62中存储的程序。具体的，处理器可以执行以下医疗信息管理方法的实施例中计算机设备侧所执行的操作。

存储器62中用于存放一个或者一个以上程序，程序可以包括程序代码，程序代码包括计算机操作指令，在本申请实施例中，该存储器中至少存储有用于实现以上任一医疗信息管理方法的程序。

在一种可能的实现方式中，该存储器62可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、以及至少一个功能(比如对应用程序代码进行编译的功能)所需的应用程序等；存储数据区可存储根据计算机的使用过程中所创建的数据，比如，待检测应用成代码、中间语言代码、内存分配代码位置信息等等。

此外，存储器62也可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

该通信接口63可以为通信模块的接口，如GSM模块的接口。

本申请还可以包括显示器64和输入单元65等等。

当然，图8所示的计算机设备的结构并不构成对本申请实施例中计算机设备的限定，在实际应用中计算机设备可以包括比图8所示的更多或更少的部件，或者组合某些部件。

其中，图8中的计算机设备60可以为终端(如PC机)，也可以为性能高于普通终端的服务器。

在本申请实施例中，计算机设备60可以根据通信接口63利用网络接收外界其他设备发送的待检测应用程序代码；也可以通过自身的输入单元64(如键盘、触摸屏、语音输入设备等)获取待检测应用程序代码。

相应的，计算机设备60中处理器61可以通过通信总线66从通信接口63或者输入单元64接收待检测应用程序代码，并调用存储器62中存储的程序对待检测应用程序代码进行编译，并对编译得到的中间代码进行检测，以确定内存分配代码的位置信息，从而实现方便的在应用程序代码中检测所有内存分配代码的目的。

另一方面，本申请还提供了一种存储介质，该存储介质中存储有计算机程序，所述计算机程序被处理器加载并执行时，用于实现如上任意一个实施例中所描述的医疗信息管理方法。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (11)

1.一种医疗信息管理方法，其特征在于，包括：

接收医院系统发送的扣费请求；

调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链；

接收医院系统发送的诊疗信息；

调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

2.根据权利要求1所述的方法，其特征在于，所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链之前，还包括：

利用所述医院系统的标识信息验证所述扣费请求是否合法；

若是，则继续执行所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链的步骤。

3.根据权利要求1所述的方法，其特征在于，所述接收医院系统发送的扣费请求之前，还包括：

接收患者系统发送的初始额度授权请求；

调用患者智能合约以更新所述患者系统的初始额度与余额；

调用医院智能合约以更新所述患者系统的初始额度；

所述调用医院智能合约以根据所述扣费请求在所述患者智能合约中进行扣费，包括：

调用医院智能合约以根据所述扣费请求在所述患者智能合约的初始额度中进行扣费。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收所述患者系统发送的扣费门限值；

将所述扣费门限值更新至所述医院智能合约；

所述调用医院智能合约以根据所述扣费请求在所述患者智能合约中进行扣费，包括：

调用所述医院智能合约判断所述扣费请求对应的待扣费用是否小于或等于所述扣费门限值；

若是，则在所述患者智能合约中进行扣除所述待扣费用。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收所述患者系统发送的结账请求；

调用所述医院智能合约以获取对应所述患者智能合约的账本信息，所述账本信息包括所述扣费结果和所述患者智能合约中的余额；

判断所述患者智能合约是否存在未完成的扣费请求；

若是，则向所述患者系统发送提示信息；

若否，则记录结账标识，将所述余额与所述结账标识作为结账信息上传至区块链。

6.根据要求5所述的方法，其特征在于，所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链，包括：

调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费；

判断所述患者智能合约的余额是否大于或等于待扣费用，所述待扣费用为与所述扣费请求对应的待扣费用；

若否，则记录所述扣费结果信息为扣费失败信息，将所述扣费结果信息添加至区块链；

所述调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链之后，还包括：

向所述患者系统发送补充余额的通知；

接收所述患者系统发送的补充余额，并更新所述患者智能合约中的余额，以完成所述扣费请求。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

接收所述医院系统和/或所述患者系统发送的对所述诊疗信息的查看请求；

验证所述查看请求的发送方是否有对诊疗信息的查看权限；

若有，获取所述诊疗信息，并将所述诊疗信息返回至所述发送方。

8.根据权利要求7所述的方法，其特征在于，所述验证所述查看请求的发送方是否有对诊疗信息的查看权限之后，还包括：

当所述查看请求的发送方没有诊疗信息的查看权限时，记录查看失败信息，并将所述查看失败信息上传至区块链。

9.一种医疗信息管理系统，其特征在于，包括：

扣费请求接收模块，用于接收医院系统发送的扣费请求；

扣费模块，用于调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链；

诊疗信息接收模块，用于接收医院系统发送的诊疗信息；

映射结果确定模块，用于调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

10.一种计算机设备，其特征在于，包括：

处理器和存储器；

其中，所述处理器用于执行所述存储器中存储的程序；

所述存储器用于存储程序，所述程序至少用于：

接收医院系统发送的扣费请求；

调用医院智能合约以根据所述扣费请求在患者智能合约中进行扣费，并将扣费结果信息添加至区块链；

接收医院系统发送的诊疗信息；

调用所述医院智能合约将所述诊疗信息与所述扣费结果信息进行映射，并将映射结果添加至区块链。

11.一种存储介质，其特征在于，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如上权利要求1至8任一项所述的医疗信息管理方法。