会员体验
专利管家（专利管理）
工作空间（专利管理）
风险监控（情报监控）
数据分析（专利分析）
侵权分析（诉讼无效）
联系我们
交流群
官方交流：
QQ群： 891211   
微信请扫码    >>>
现在联系顾问~
首页 / 专利库 / 计算机网络 / 对等网络 / 处理医疗数据的方法及系统

处理医疗数据的方法及系统

阅读：1005发布：2021-02-27

IPRDB可以提供处理医疗数据的方法及系统专利检索，专利查询，专利分析的服务。并且本发明实施例公开了处理医疗数据的方法及系统。其中，该方法包括：对等网络中第一节点向对等网络发送医疗数据请求；在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。本发明实施例增强了医疗数据的可靠性，改善了人们的医疗体验。，下面是处理医疗数据的方法及系统专利的具体信息内容。

1.一种处理医疗数据的方法，包括：

对等网络中的第一节点向所述对等网络发送医疗数据请求；

在所述第一节点通过所述对等网络的全网身份验证并取得全网对所述医疗数据请求的共识后，所述医疗数据请求被记录到所述对等网络的一个或多个网络节点处存储的区块链中。

2.根据权利要求1所述的方法，还包括：

所述第一节点从所述对等网络中获取来自第二节点针对所述医疗数据请求的医疗数据应答，所述第二节点为所述第一节点以外的其他节点中的任意一个或多个节点；

其中，在所述医疗数据应答被记录到所述对等网络的一个或多个网络节点处存储的区块链中之前，所述第二节点通过了所述对等网络的全网身份验证，并取得全网对所述医疗数据应答的共识。

3.根据权利要求1所述的方法，其中，所述医疗数据请求包括：注册身份、查询医疗相关数据、上传医疗相关数据、下载医疗相关数据和结算医疗相关费用请求中的至少一种，其中，所述医疗相关数据包括：所述第一节点的属性信息、所述第二节点的属性信息、医疗方案信息、医疗费用信息、医疗周期信息、康复效果信息和医疗评价信息中的一种或者多种。

4.根据权利要求3所述的方法，还包括：

所述第二节点对待实施的医疗方案进行预先评估，预先评估的信息包括与所述待实施的医疗方案相关的第一医疗费用信息、第一医疗周期信息和第一康复效果信息中的一种或者多种；

所述预先评估的信息在获得全网共识后被记录至所述区块链中。

5.根据权利要求4所述的方法，还包括：

所述第一节点根据经过预先评估的医疗方案的实际实施情况，获取与所述预先评估的信息对应的实际实施的信息，所述实际实施的信息包括第二医疗费用信息、第二医疗周期信息和第二康复效果信息中的一种或者多种；

所述第一节点将所述预先评估的信息与所述实际实施的信息相比较；

所述第一节点根据所述比较结果和比较内容的权重对所述实际实施的医疗方案进行评分；

在所述实际实施的信息和所述评分在获得全网共识后被记录至所述区块链中。

6.根据权利要求3所述的方法，还包括：

所述第二节点在所述区块链内查询一个或者多个医疗方案信息、以及与所述一个或者多个医疗方案信息对应的医疗相关数据；

所述第二节点根据查询结果制定优化的医疗方案信息。

7.根据权利要求2所述的方法，还包括：基于所述医疗数据请求的目的，将所述第一节点与所述第二节点的作用进行变更。

8.一种处理医疗数据的系统，包括：

发送单元，用于对等网络中第一节点向所述对等网络发送医疗数据请求；

共识单元，用于在所述第一节点通过所述对等网络的全网身份验证并取得全网对所述医疗数据请求的共识后，所述医疗数据请求被记录到所述对等网络的一个或多个网络节点处存储的区块链中。

9.根据权利要求8所述的系统，还包括：

获取单元，用于所述第一节点从所述对等网络中获取来自第二节点针对所述医疗数据请求的医疗数据应答，所述第二节点为所述第一节点以外的其他节点中的任意一个或多个节点；

其中，在所述医疗数据应答被记录到所述对等网络的一个或多个网络节点处存储的区块链中之前，所述第二节点通过了所述对等网络的全网身份验证，并取得全网对医疗数据应答的共识。

10.根据权利要求8所述的系统，其中，所述医疗数据请求包括：注册身份、查询医疗相关数据、上传医疗相关数据、下载医疗相关数据和结算医疗相关费用请求中的至少一种，其中，所述医疗相关数据包括：所述第一节点的属性信息、所述第二节点的属性信息、医疗方案信息、医疗费用信息、医疗周期信息、康复效果信息和医疗评价信息中的一种或者多种。

11.根据权利要求10所述的系统，还包括：

信息评估单元，用于所述第二节点对待实施的医疗方案进行预先评估，预先评估的信息包括与所述待实施的医疗方案相关的第一医疗费用信息、第一医疗周期信息和第一康复效果信息中的一种或者多种，所述预先评估的信息在获得全网共识后被记录至所述区块链中。

12.根据权利要求11所述的系统，还包括：

信息采集单元，用于所述第一节点根据经过预先评估的医疗方案的实际实施情况，获取与所述预先评估的信息对应的实际实施的信息，所述实际实施的信息包括第二医疗费用信息、第二医疗周期信息和第二康复效果信息中的一种或者多种；

信息比较单元，用于所述第一节点将所述预先评估的信息与所述实际实施的信息相比较；

评分单元，用于所述第一节点根据所述比较结果和比较内容的权重对所述实际实施的医疗方案进行评分，在所述实际实施的信息和所述评分在获得全网共识后被记录至所述区块链中。

13.根据权利要求10所述的系统，还包括：

信息检索单元，用于所述第二节点在所述区块链内查询一个或者多个医疗方案信息、以及与所述一个或者多个医疗方案信息对应的医疗相关数据；

方案制定单元，用于所述第二节点根据查询结果制定优化的医疗方案信息。

14.根据权利要求9所述的系统，还包括：

作用变更单元，基于所述医疗数据请求的目的，将所述第一节点与第二节点的作用进行变更。

15.一种处理医疗数据的方法，包括：

对等网络中第二节点响应于医疗数据请求，所述第二节点向所述对等网络发送医疗数据应答；

在所述第二节点通过所述对等网络的全网身份验证并取得全网对所述医疗数据应答的共识后，所述医疗数据应答被记录到所述对等网络的一个或多个网络节点处存储的区块链中；其中，所述医疗数据请求是第一节点向所述对等网络发送的请求，在所述第一节点通过所述对等网络的全网身份验证并取得全网对医疗数据请求的共识后，所述医疗数据请求被记录到所述对等网络的一个或多个网络节点处存储的区块链中。

16.一种处理医疗数据的系统，包括：

应答单元，用于对等网络中第二节点响应于医疗数据请求，所述第二节点向所述对等网络发送医疗数据应答；

共识单元，用于在所述第二节点通过所述对等网络的全网身份验证并取得全网对所述医疗数据应答的共识后，所述医疗数据应答被记录到所述对等网络的一个或多个网络节点处存储的区块链中；其中，所述医疗数据请求是第一节点向所述对等网络发送的请求，在所述第一节点通过所述对等网络的全网身份验证并取得全网对医疗数据请求的共识后，所述医疗数据请求被记录到所述对等网络的一个或多个网络节点处存储的区块链中。

17.一种处理医疗数据的方法，包括：

对等网络中第一节点向所述对等网络发送医疗数据请求；

在所述第一节点通过所述对等网络的全网身份验证并取得全网对医疗数据请求的共识后，所述医疗数据请求被记录到所述对等网络的一个或多个网络节点处存储的区块链中；

所述对等网络中第二节点响应于所述医疗数据请求，所述第二节点向所述对等网络发送医疗数据应答；

在所述第二节点通过所述对等网络的全网身份验证并取得全网对所述医疗数据应答的共识后，所述医疗数据应答被记录到所述对等网络的一个或多个网络节点处存储的区块链中。

18.一种处理医疗数据的系统，包括：

发送单元，用于对等网络中第一节点向所述对等网络发送医疗数据请求；

第一共识单元，用于在所述第一节点通过所述对等网络的全网身份验证并取得全网对医疗数据请求的共识后，所述医疗数据请求被记录到所述对等网络的一个或多个网络节点处存储的区块链中；

应答单元，用于所述对等网络中第二节点响应于所述医疗数据请求，所述第二节点向所述对等网络发送医疗数据应答；

第二共识单元，用于在所述第二节点通过所述对等网络的全网身份验证并取得全网对所述医疗数据应答的共识后，所述医疗数据应答被记录到所述对等网络的一个或多个网络节点处存储的区块链中。

19.一种处理医疗数据的系统，包括：

显示器；

存储器，用于存放程序；

处理器，用于执行所述存储器存储的程序，所述程序使得所述处理器执行以下操作：对等网络中第一节点向所述对等网络发送医疗数据请求；

所述在第一节点通过所述对等网络的全网身份验证并取得全网对医疗数据请求的共识后，所述医疗数据请求被记录到所述对等网络的一个或多个网络节点处存储的区块链中；

所述对等网络中第二节点响应于所述医疗数据请求，所述第二节点向所述对等网络发送医疗数据应答；

在所述第二节点通过所述对等网络的全网身份验证并取得全网对所述医疗数据应答的共识后，所述医疗数据应答被记录到所述对等网络的一个或多个网络节点处存储的区块链中。

说明书全文

处理医疗数据的方法及系统

技术领域

[0001] 本发明涉及互联网技术领域，尤其涉及一种处理医疗数据的方法及系统。

背景技术

[0002] 随着人们生活水平的提高，人们对医疗保健日益重视。医疗数据可涉及到个人隐私，亦或涉及医疗机构的相关信息，该类信息敏感度较高。目前，医疗数据的记录、存储和共享等操作通常在集中式的控制网络里进行，具体的操作可由医疗机构或者第三方机构提供的网络平台或服务器来执行。在现有的集中式控制的网络里，医疗机构或者第三方机构提供的网络平台节点或服务器节点相当于其中的主节点，其他个人用户节点以及监督机构节点等均为从节点。通常，从节点只可间接访问部分的医疗数据，无法进行写入、修改等操作。此种数据集中处理的方式存在以下问题：
[0003] 1、医患双方无法直接进行数据交互，使得医疗数据无法直接被需求方获取。
[0004] 2、医疗机构或者第三方机构的服务器相对集中，故主节点容易受到网络的攻击而导致网络瘫痪。
[0005] 3、主节点不仅处理数据的压力大，而且处理数据的时间长。
[0006] 4、医疗数据不透明，医疗数据容易篡改甚至泄露。

发明内容

[0007] 鉴于以上所述一个或多个问题，本发明实施例提供了一种处理医疗数据的方法及系统。
[0008] 一方面，本发明实施例提出一种处理医疗数据的方法。该方法包括：
[0009] 对等网络(Peer-to-peer networking，P2P)中第一节点向对等网络发送医疗数据请求。
[0010] 在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0011] 其中，在P2P网络环境中，彼此连接的多台计算机之间都处于对等的地位，各台计算机有相同的功能，无主从之分，一台计算机既可作为服务器，设定共享资源供网络中其他计算机所使用，又可以作为工作站，整个网络一般来说不依赖专用的集中服务器，也没有专用的工作站。网络中的每一台计算机既能充当网络服务的请求者，又对其他计算机的请求做出响应，提供资源、服务和内容。通常这些资源和服务可以包括：信息的共享和交换、计算资源(如CPU计算能力共享)、存储共享(如缓存和磁盘空间的使用)、网络共享、打印机共享等。
[0012] 另一方面，本发明实施例提出了一种处理医疗数据的系统。该系统包括：
[0013] 发送单元，用于对等网络中第一节点向对等网络发送医疗数据请求；
[0014] 共识单元，用于在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0015] 又一方面，本发明实施例提供一种处理医疗数据的方法。该方法包括：
[0016] 对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答；
[0017] 在第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中；
[0018] 其中，医疗数据请求是第一节点向对等网络发送的请求，在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0019] 另一方面，本发明实施例提供一种处理医疗数据的系统，该系统包括：
[0020] 应答单元，用于对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答；
[0021] 共识单元，在该第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中；
[0022] 其中，医疗数据请求是第一节点向对等网络发送的请求，在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0023] 又一方面，本发明实施例还提供一种处理医疗数据的方法，该方法包括：
[0024] 对等网络中第一节点向对等网络发送医疗数据请求；
[0025] 在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中；
[0026] 对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答；
[0027] 在该第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0028] 又一方面，本发明实施例还提供一种处理医疗数据的系统，该系统包括：
[0029] 发送单元，用于对等网络中第一节点向对等网络发送医疗数据请求；
[0030] 第一共识单元，用于在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中；
[0031] 应答单元，用于对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答；
[0032] 第二共识单元，用于在该第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0033] 再一方面，本发明实施例提供一种处理医疗数据的系统，该系统包括：
[0034] 显示器；
[0035] 存储器，用于存放程序；
[0036] 处理器，用于执行存储器存储的程序，程序使得处理器执行以下操作：
[0037] 对等网络中第一节点向对等网络发送医疗数据请求；
[0038] 在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中；
[0039] 对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答；
[0040] 在第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0041] 一方面，本发明实施例根据对等网络中所有节点无主从之分，其身份地位一致的特性，利用对等网络中其他节点对第一节点进行全网身份验证，从而防止了由单个中心节点(主节点)验证所带来的验证误差，以及避免了单个中心节点受攻击造成的网络瘫痪风险。
[0042] 另一方面，本发明的实施例通过全网共识确保了处理的医疗数据准确一致。
[0043] 又一方面，通过将处理的医疗数据写入区块链中，不仅可以防止医疗数据篡改，增加了医疗数据的安全性和透明度，改善人们的医疗体验。

附图说明

[0044] 为了更好地理解本发明，下面结合附图对本发明的具体实施方式进行描述。
[0045] 通过阅读以下参照附图对非限制性实施例所作的详细描述，本发明的其他特征、目的和优点将会变得更明显。其中，相同或相似的附图标记表示相同或相似的特征。
[0046] 图1为可以应用于本发明实施例的示例性系统架构；
[0047] 图2为本发明医疗数据处理方法的第一个实施例的流程示意图；
[0048] 图3为本发明医疗数据处理方法的第二个实施例的流程示意图；
[0049] 图4为本发明区块链内各种医疗数据的记录示意图；
[0050] 图5为本发明医疗数据处理方法的第三个实施例的流程示意图；
[0051] 图6为本发明医疗数据处理方法的第四个实施例的流程示意图；
[0052] 图7为本发明处理医疗数据的系统的第一个实施例的功能结构示意图；
[0053] 图8为本发明处理医疗数据的系统的第二个实施例的功能结构示意图；
[0054] 图9为本发明处理医疗数据的系统的第三个实施例的功能结构示意图；
[0055] 图10为本发明处理医疗数据的系统的第一实施例的结构示意图；
[0056] 图11为本发明处理医疗数据的系统的第二实施例的结构示意图。

具体实施方式

[0057] 为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的一个或多个其他实施例，都属于本发明保护的范围。
[0058] 下面将详细描述本发明的各个方面的特征和示例性实施例。需要说明的是，在下面的详细描述中，提出了许多具体细节，以便对本发明进行全面理解。但是，对于本领域技术人员来说，本发明可以在不需要这些具体细节中的一些细节的情况下实施。
[0059] 在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，在一些情况下，不详细示出或描述公知结构、单元或者操作步骤以避免模糊本发明的主要技术创意。
[0060] 需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以改变连接关系，改变步骤顺序，或者相互进行不同的组合。下面将参考附图并结合实施例来详细说明本申请。
[0061] 图1示出了可以应用本申请实施例的示例性系统架构100。
[0062] 如图1所示，系统架构100可以包括节点101、节点102、节点103和对等网络104。为了说理简单且说理清楚，下面仅以节点101、节点102和节点103组成的对等网络进行说明。应该理解，图1中的节点的数目仅仅是示意性的。根据实现需要，该系统架构100可以具有任意数目的终端设备、网络和服务器。下面各实施例均可以应用本实施例的系统架构进行数据交互或者处理。
[0063] 其中，节点101、节点102和节点103可以是用户的手持终端设备，具体可以是各种电子设备。这些电子设备包括但不限于个人电脑、智能手机、平板电脑、个人数字助理、服务器、医疗物联设备等。节点101、节点102和节点103可以安装有各种通讯客户端应用，例如即时通信工具、邮箱客户端、社交平台软件、音频视频软件等。其中，这些节点具有存储器和逻辑运算处理器、控制元件等。这些节点可以发送数据请求，或者可以接收数据请求，还可以并对数据进行分析、验证和存储等处理，并可以将处理结果进行反馈。
[0064] 对等网络104用以在节点101、节点102和节点103之间提供通信链路的介质。对等网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等。在对等网络环境中，彼此连接的各个节点都处于对等的地位，各个节点具有相同的功能，无主从之分。对等网络中，通常不依赖专用的集中服务器，也没有专用的工作站。一台计算机既可作为服务器，设定共享资源供网络中其他计算机所使用，又可以作为工作站。对等网络中的每个节点既能充当网络服务的请求者，又对其他计算机的请求做出响应，提供资源、服务和内容。通常这些资源和服务包括：信息的共享和交换、计算资源(如CPU计算能力共享)、存储共享(如缓存和磁盘空间的使用)、网络共享、打印机共享等。
[0065] 对等网络104中的参与者，例如节点101、节点102和节点103，共享他们所拥有的一部分硬件资源(如具有处理能力、存储能力、网络连接能力的设备及打印机等)。这些共享资源通过对等网络104提供服务和内容，能被其他对等节点直接访问而无需经过中间实体。在此网络中的参与者既是资源、服务和内容的提供者，又是资源、服务和内容的获取者。其中，节点101可以是第一节点，节点102和节点103可以是第二节点，第一节点(节点101)可以向对等网络104发起医疗数据请求，第二节点(节点102、103)可以进行医疗数据应答等。可以理解，根据请求和应答的内容的不同，第一节点和第二节点的角色可以进行调换。
[0066] 一方面，本发明实施例根据对等网络中所有节点无主从之分，其身份地位一致的特性，利用对等网络中其他节点对第一节点进行全网身份验证，从而防止了由单个中心节点单一验证所带来的验证误差，以及避免了单个中心节点受攻击造成的网络瘫痪风险。
[0067] 另一方面，本发明的实施例通过全网共识确保了处理的医疗数据准确一致。
[0068] 又一方面，通过将处理的医疗数据写入区块链中，不仅可以防止医疗数据篡改，增加了医疗数据的安全性和透明度，改善人们的医疗体验。
[0069] 图2为本发明医疗数据处理方法的第一个实施例的流程示意图。
[0070] 在S201中，对等网络中的第一节点向对等网络发送医疗数据请求。
[0071] 在本实施例中，对等网络是由多个对等的网络节点组成。第一节点可以是图1所示的节点101。在其他的实施例中，第一节点可以是图1中的节点102或者节点103。正如图1部分内容所述，具体节点是没有限制的。节点的形式可以根据具体医疗数据请求的内容进行针对性的设置，节点的数量也可以根据对等网络的规模或者医疗数据的内容进行灵活设置。
[0072] 在S202中，在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0073] 其中，全网验证不是绝对意义上的全网中所有节点都进行验证，即不需要对等网络中第一节点外的所有第二节点进行验证。具体的，可以考虑一些实际特殊的情况进行不同的设置。例如可以考虑节点是否在线的情况，来设置除第一节点外的所有在线的节点对第一节点进行验证。还例如可以设置成只要达到所有在线的节点中80％的节点对第一节点进行验证就可以。另外，也可以设置第一节点对自身进行验证。
[0074] 在本实施例中，第一节点需要通过对等网络中第二节点(节点102和103)的身份验证。例如具体验证可以是验证第一节点的身份信息和/或加密信息。该身份信息例如可以是标识第一节点身份的ID号。该ID号例如可以是16位或者32位由随机数字组合而成的一个数据串。如此设置的ID号可以防止网络攻击盗用ID号。该加密信息例如可以是公钥和私钥。这里的公钥与私钥可以是通过一种算法得到的一个密钥对，该密钥对可以是一个公钥和一个私钥。公钥是密钥对中公开的部分，私钥则是非公开的部分。使用这个密钥对的时候，如果用其中一个密钥加密一段数据，需要用另一个密钥解密。公钥或私钥可以利用HASH算法生成，例如Sha-256等，也可以用RSA公钥加密等算法生成公钥和私钥。
[0075] 这样，只有获取了密钥数据后才能对已经加密的医疗数据进行查看、拷贝等操作。如此设置，可以加强网络通信时的数据安全，使得敏感的医疗数据不会被泄露。
[0076] 在本实施例中，共识可以是在没有中心控制节点的分布式系统中，多个参与网络节点对交易、数字记录、电子证据等系统数据的正确性进行验证并达成一致意见的机制。该共识可以通过工作量证明PoW(Proof of Work)、权益证明PoS(Proof of Stake)和委托权益证明DPoS(Delegated proof-of-stake)、瑞波共识RCP(Ripple Consensus)及Stellar协议等来达成数据一致。例如可以将PoW机制与PoS机制进行混合来弥补单一机制的不足，从而加强数据共识的效果，确保医疗数据处理的可靠性。
[0077] 其中，共识不是绝对意义上的全网中所有节点都达成一致意见。具体的，可以考虑一些实际特殊的情况进行不同的设置。例如可以考虑节点是否在线的情况，来设置除第一节点外的所有在线的节点达成意见一致。还例如可以设置成只要达到所有在线的节点中80％的节点达成意见一致就可以。另外，也可以设置第一节点对自身进行共识。
[0078] 在全网验证身份合法的基础上，再进行全网共识验证，是为了确保在没有中心服务节点的对等网络中，有信用问题的节点都不能通过验证，且每个节点的数据保持一致。这样可以防止恶意节点的网络攻击，增加了网络的健壮性。
[0079] 在本实施例中，医疗数据请求可以包括：注册身份、查询医疗相关数据、上传医疗相关数据、下载医疗相关数据和结算费用的请求中的至少一种。其中，医疗相关数据包括：第一节点的属性信息(例如医院在网络上所注册信息，具体例如但不限于：医院的资质、规模、科室、联系方式等)、第二节点的属性信息(例如病人在网络上的注册信息，具体例如但不限于：姓名、年龄、病史等)、医疗方案信息、医疗费用信息、医疗周期信息、康复效果信息和医疗评价信息中的一种或者多种。其中，医疗数据请求和医疗相关数据也可以根据实际需求进行灵活变化，这些均在本发明的保护范围内。
[0080] 在一些可选的实施例中，第二节点可以对待实施的医疗方案进行预先评估。预先评估的信息可以包括与待实施的医疗方案相关的第一医疗费用信息、第一医疗周期信息和第一康复效果信息。预先评估的信息在获得全网共识后被记录至区块链中。由此，通过与医疗方案进行预先评估，改善了人们的医疗体验。
[0081] 其中，预先评估的信息被记录至区块链中后就无法修改，如果预先评估的信息涉嫌欺诈，可以由一个专门的网络节点(其身份可以是监管机构或者是仲裁机构)对其进行监管或者处罚。由此，增强了区块链中的数据的权威性和透明性。
[0082] 在一些可选的实施例中，第一节点根据经过预先评估的医疗方案的实际实施情况，获取与预先评估的信息对应的实际实施的信息，实际实施的信息包括第二医疗费用信息、第二医疗周期信息和第二康复效果信息。第一节点将预先评估的信息与实际实施的信息相比较。第一节点根据比较结果和比较内容的权重(权重根据需要进行不同设置，例如医疗费用信息的权重为30％，医疗周期信息的权重为20％，康复效果信息的权重为50％)对实际实施的医疗方案进行评分。在实际实施的信息和评分获得全网共识后被记录至区块链中。由此，通过第一节点(病人)对第二节点(医院)进行评分，让其拥有了话语权，改善了用户的体验。
[0083] 其中，如果实际实施的信息比预先评估的信息要好，评分就会很高，如果实际实施的信息比预先评估的信息要差，评分就会低些，如果预先评估的信息涉嫌欺诈，可以由一个专门的网络节点(其身份是监管机构或者是仲裁机构)对其进行监管或者处罚。当然，评分也需要客观公正，其评分被记录至区块链中后将无法修改，如果评分涉嫌欺诈，也可以由一个专门的网络节点(其身份是监管机构或者是仲裁机构)对其进行监管或者处罚。由此，增强了区块链中的数据的权威性和透明性。
[0084] 在一些可选的实施例中，在第二节点区块链内查询一个或者多个医疗方案信息、以及与一个或者多个医疗方案信息对应的医疗相关数据，第二节点根据查询结果制定实际实施的医疗方案信息。
[0085] 其中，制定的实际实施的医疗方案信息可以根据费用、效果、评分等参数进行综合判定。具体实现方式可以为这些参数设置权重，根据权重为医疗方案进行品种和评分。由此，通过医疗数据共享，可以借鉴已有的医疗方案，并在其基础上不断进行改进和优化，节约了社会资源，提升了医疗技术水平。
[0086] 图3为本发明医疗数据处理方法的第二个实施例的流程示意图。如图3所示，处理医疗数据的方法可以包括以下步骤：
[0087] S301：对等网络中的第一节点向对等网络发送医疗数据请求。
[0088] S302：在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0089] S303：第一节点从对等网络中获取来自第二节点针对医疗数据请求的医疗数据应答，第二节点为第一节点以外的其他节点中的任意一个或多个节点。
[0090] 其中，在医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中之前，第二节点通过了对等网络的全网身份验证，并取得全网对医疗数据应答的共识。
[0091] 本实施例是在图2所述实施例的基础上增加了第二节点的应答步骤，即增加了步骤S303。
[0092] 具体的，应答数据可以包括具体的应答内容以及用户授权列表。该用户授权列表例如可以是允许访问该应答数据的用户ID列表。用户可以通过设置授权的权限，使得只有授权用户列表中的用户才可以看到应答数据。如此设置可以防止隐私数据泄露，保证了医疗数据的安全性。
[0093] 在一些可选的实施例中，还可以通过设置数据加密等操作来控制应答数据的访问权限。具体设置的方法和设置的权限可以根据实际需要进行个性化设置，此方面不做限制。
[0094] 本实施例的步骤S301和S302可以与图2实施例中的步骤S201和S202相同。其中，应答步骤中的验证方式与共识方式等内容可以参见图2实施例中的方式，具体内容在此不再赘述。下面将结合图4来描述区块链内各种医疗数据的记录情况。
[0095] 图4为本发明区块链内各种医疗数据的记录示意图。
[0096] 如图4所示，本实施例布置了6个节点，分别是：个人用户、医院、医疗设备、医学研究机构、监管机构和其他机构的节点。这6个节点可以根据各自目的，两两直接进行数据交互。其中，各自的目的，例如可以是个人用户向医院查询医疗方案的目的，或者是医学研究机构向其他机构收集医疗方案的目的，再或者是个人用户向医疗设备查询身体检查数据的目的等。具体交互的数据分别按时间顺序记录至区块链中。具体可以记录医疗数据请求和医疗数据应答。例如，医疗数据记录1、医疗数据记录2……医疗数据记录N分别按时间顺序记录至区块链的一个用于存储除区块内，该区块还可以记录了当前区块的HASH值、前一区块的HASH值和时间戳等信息。再例如，医疗数据记录1、医疗数据记录2……医疗数据记录M分别按时间顺序记录至区块链的另一个区块内，该区块还可以记录了当前区块的HASH值、前一区块的HASH值和时间戳等信息。其中，N和M分别为自然数。HASH值可以用于生成公钥或私钥。可以理解，HASH值可以更换成常规的校验数据。
[0097] 在本实施例中，可以基于医疗数据请求的目的，将各个节点的作用进行变更。具体变更实施例的实现方式如下所示：
[0098] 如果判定医疗数据请求的目的是查询医疗方案，那么就设置个人用户的作用是向医院请求查询医疗方案，而医院的作用是向个人用户提供医疗方案。如果判定医疗数据请求的目的是医疗方案的征集，那么就设定个人用户的作用将从请求者转换为应答者，医院的作用将从应答者转换为请求者。在上述作用变更之后，医院可以发起医疗方案的征集请求。该医疗方案通常是疑难的医疗方案，医院希望通过采集网络中各个节点的方案，整理生成最终的医疗方案，或者直接采纳所采集的某个方案。个人用户可以根据医院的请求做出相应的应答，向医院提供医疗方案。如此设置，可以拓展各个节点的功能，简化了医疗数据获取流程，改善了用户体验。
[0099] 下面分别以注册身份、查询医疗相关数据、上传医疗相关数据、下载医疗相关数据和结算医疗相关费用这五个方面来详细描述医疗数据的处理的实现方式。
[0100] 可以理解，此处医疗相关可以是直接与医疗相关，也可以与医疗间接相关，只要是有关医疗目的就可以，此方面不做限制。
[0101] 需要说明的是，下面各实施例中的方案的细节内容可以参考上述各实施例中的相应内容，相同或者类似的内容不再赘述。
[0102] 第一实施例描述了个人用户节点向注册节点申请注册身份的实现方式。
[0103] 步骤1：个人用户节点发送注册请求。具体可以采用向对等网络广播注册请求的方式。
[0104] 步骤2：全网节点验证该个人用户的身份。例如验证该用户之前是否已经提交过注册申请。再例如，验证该用户是否存在恶意的历史行为。具体恶意的历史行为可以是攻击网络的行为或者欠款的行为等。
[0105] 步骤3：在该个人节点通过对等网络的全网身份验证后，还需要取得全网对申请注册请求的共识。
[0106] 步骤4：在达成上述共识之后，注册申请的请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0107] 步骤5：注册节点响应该注册请求，该注册节点在通过全网身份验证后，注册节点还需要获取全网对注册申请的应答的共识。
[0108] 步骤6：在共识达成后，注册申请的应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0109] 其中，该注册申请的应答可以是为该个人用户分配一个全网唯一的身份ID、公钥和私钥等。
[0110] 第二实施例描述了个人用户节点向医院查询医疗相关数据的实现方式。
[0111] 步骤1：个人用户节点发送向医院查询医疗相关数据的请求。该医疗相关数据例如是医疗方案。
[0112] 步骤2：全网节点验证该个人用户的身份。例如，验证该用户是否存在恶意的历史行为。具体恶意的历史行为可以是攻击网络的行为或者欠款的行为等。
[0113] 步骤3：该个人节点在通过对等网络的全网身份验证后，还需要取得全网对查询数据请求的共识。
[0114] 步骤4：在达成上述共识之后，查询医疗医疗相关数据的请求记录到对等网络的一个或多个网络节点处存储的区块链中。
[0115] 步骤5：医院节点响应该查询医疗相关数据的请求，在该医院节点通过全网身份验证后，还需要获取全网对查询医疗相关数据请求的应答的共识。
[0116] 步骤6：在共识达成后，查询医疗相关数据的应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0117] 具体的，应答记录可以包括以下内容：医疗数据记录标识、医疗服务申请者身份信息、医疗服务提供者身份信息、治疗方案信息、治疗过程信息、治疗结果信息、医疗费用信息、时间信息、认证信息和加密信息等。
[0118] 第三实施例描述了个人用户节点向医院上传医疗相关数据的实现方式。
[0119] 步骤1：个人用户节点发送向医院上传医疗相关数据的请求。该数据例如是医疗所征集的医疗方案等。
[0120] 步骤2：全网节点验证该个人用户的身份。例如，验证该用户是否存在恶意的历史行为。具体恶意的历史行为可以是攻击网络的行为或者欠款的行为等。
[0121] 步骤3：在该个人节点通过对等网络的全网身份验证后，还需要取得全网对上传医疗相关数据请求的共识。
[0122] 步骤4：在达成上述共识之后，上传医疗相关数据的请求记录到对等网络的一个或多个网络节点处存储的区块链中。
[0123] 步骤5：医院节点响应该上传医疗相关数据的请求，在该医院节点通过全网身份验证后，还需要获取全网对上传医疗相关数据请求的应答的共识。
[0124] 步骤6：在共识达成后，上传医疗相关数据的应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0125] 第四实施例描述了个人用户节点向医院下载医疗相关数据的实现方式。
[0126] 本实施例与上面第三实施中数据上传的原理类似，区别在于需要将上传医疗相关数据的请求更换成下载医疗相关数据的请求，验证和共识的方法也类似，在此不再赘述二者相同或者相似的内容。
[0127] 第五实施例描述了个人用户节点向医院支付医药费的实现方式。
[0128] 步骤1：个人用户节点发送向医支付医疗费的请求。
[0129] 步骤2：全网节点验证该个人用户的身份。例如，验证该用户是否存在恶意的历史行为。具体恶意的历史行为可以是攻击网络的行为或者欠款的行为等。
[0130] 步骤3：在该个人节点通过对等网络的全网身份验证后，还需要取得全网对向医支付医疗费的请求的共识。
[0131] 步骤4：在达成上述共识之后，支付医药费的请求记录到对等网络的一个或多个网络节点处存储的区块链中。
[0132] 步骤5：医院节点响应该支付请求，在该医院节点通过全网身份验证后，还需要获取全网对支付医药费请求的应答的共识。
[0133] 步骤6：在共识达成后，支付医药费的应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0134] 需要说明的是，上述实施例中，除了个人用户外，具有区块链交互能力的智能医疗设备也可以作为参与者加入对等网络中，进行医疗设备数据的查询、上传等操作。其中，智能医疗设备指具有网络通信功能的医疗设备，具有区块链模块，可运行区块链协议，可自动接收、处理区块链节点发过来的信息，并将信息发布至区块链参与节点。
[0135] 第六实施例将结合上述5个实施例，详细描述多个运用场景的综合医疗数据处理的实现方式。
[0136] 步骤1：个人用户节点提交注册申请，通过身份验证后获得全网唯一的身份ID及公私钥。
[0137] 具体的，个人用户提交注册申请的信息可以包括用户个人信息、医疗信息、紧急联系人信息等。验证的方式可以是查询区块链历史区块链中是否已经存在该用户信息，比如个人信息是否已经注册。
[0138] 在本实施例中，个人节点可以向对等网络广播申请注册，由某个注册节点提供注册。如此，网络中一个或多个节点是对等的，不存在中心控制节点。网络中一个或多个节点都可以直接进行交互信息，可以防止网络攻击的问题。
[0139] 在一些可选的实施例中，个人节点可以向中心控制节点(例如主节点或中心节点)申请注册。该中心节点可以视为区块链的一个特殊节点，运行区块链协议。在完成申请注册之后，该个人节点与中心节点之外的其他的关系都是对等的，他们可以直接进行交互信息，而无需再受中心节点的制约。如此，在受到网路攻击的时候，不会因为中心节点受到攻击而导致全网瘫痪。
[0140] 步骤2：个人用户节点申请获取医疗数据。
[0141] 在本实施例中，个人用户需要获取全网内除该个人用户之外的一个或多个节点验证。该验证方式具体可以是权限判断和历史医疗信息查询。
[0142] 在本实施例中，该用户节点可以预先设置医疗机构以及紧急联系人权限。比如一般将用户信任的医疗机构或紧急联系人开放历史医疗信息查询权限等。具体权限设置的实现方式可以如下所示：
[0143] 个人用户首先生成一条权限设置记录。该记录可以包括：记录唯一标识、医疗机构ID、权限名称、发布时间、权限有效期、医疗机构的签名信息。然后，个人用户将该记录信息发布给全网的区块链节点进行全网验证，请求写入区块链中。区块链节点收到该记录信息后，利用医疗用户公钥签名，并验证权限设置记录信息的有效性，比如医疗机构ID是否正确等。如果通过验证，且当全网节点达成共识认可该记录信息有效后，该信息就被写入区块链中，永久生效，权限设置完成。
[0144] 在本实施例中，医疗数据的申请可以分为两种情况：医疗用户(可以是个人用户，也可以是集体用户)自主申请。医疗服务提供者(例如医院)协助用户申请医疗服务。第二种情况一般发生在医疗用户因突发状况急需救治时。
[0145] 在本实施方式中，医疗服务提供者可以向区块链发布服务质量承诺记录，例如治疗类型、治疗周期、治疗费用、治疗效果等信息，由全网共识验证。服务质量承诺将是用户选择医疗服务提供者的重要参考，一旦无法完成承诺，用户将在评价结果中予以体现，也可以申请监管机构仲裁惩罚。
[0146] 其中，医疗用户自主申请的实现方式可以如下所示：
[0147] 医疗用户自主申请医疗服务，上传医疗诊断所需信息如病因、病史、发病症状等信息，进而选择自己信任的医疗机构。医疗服务选择，可以采用平台推荐和用户自主选择相结合的方式。通过区块链医疗数据记录、医疗评价结果记录，平台可以根据用户条件推荐最佳匹配的医疗服务提供者，而匹配条件可以由用户指定，匹配条件不仅包括治疗方案、治疗评价、治疗费用，还包括其他用户的评价结果信息。
[0148] 具体的，医疗用户选择医疗机构前，首先需要查询医疗机构名称，由于区块链节点存储了完整的区块链历史信息，因而可以方便本地查询一个或多个医疗机构名称。在选好医疗机构后，医疗用户上传医疗诊断信息即生成一条医疗诊断数据信息，在全网共识后，该信息记录至区块链。医疗诊断数据信息可以包含诊断数据信息唯一标识、医疗用户ID、病症描述、发病原因、病史、发布时间、医疗用户签名等信息。其中，医疗机构协助申请的实现方式可以如下所示：
[0149] 在用户可能会因为发病等原因失去自主医疗申请能力的情况下，将由其他主体为用户申请服务。协助申请的主体可以为医疗机构(如用户家人通过拨打急救电话通知的医疗机构)、医疗平台(用户家人或紧急联系人通过医疗平台特殊通道申请服务)或者医疗物联设备(如心跳检测设备，可以自动告警并通知相关医疗机构)。
[0150] 在本实施例中，申请者可以对医疗服务权限判断。具体可以判断申请者是否具有享受服务的权限，同时医疗服务提供者是否具备服务提供的权限。判断是否具备服务权限可以根据本地查询区块链的权限设置的历史记录进行。
[0151] 具体的，医疗服务提供者(医疗机构)首先对用户身份进行验证，判断申请者是否具有享受服务的权限。如果具备服务权限，则可以提供进一步的服务。如果不具备服务权限，则需要根据用户病情严重程度判断是否启用紧急服务模式，即打破权限限制为用户提供服务。
[0152] 步骤3：医疗机构(例如医疗服务提供者或者医院)为用户提供医疗数据，并将该医疗数据写入区块链存储。
[0153] 在本实施例中，医疗服务提供者可以制定医疗方案，医疗方案制定过程中，医疗服务提供者可以通过区块链查询其他医疗机构公开的医疗方案、医疗记录，从而更好地制定合理医疗方案。在得到用户(或授权人)的治疗许可和签名后，对用户进行治疗。治疗方案、治疗过程、治疗结果等信息在得到全网共识后写入区块链中。具体写入区块链中的信息可以如下面表(1)所示：
[0154]医疗数据记录标识
医疗服务申请者
医疗服务提供者
治疗方案信息
治疗过程信息
治疗结果信息
医疗费用信息
时间戳
医疗机构与用户联合签名
[0155] 表(1)
[0156] 可以理解，写入表(1)的信息的内容和格式可以根据实际需要进行变化或者加密处理，但是，一旦写入区块链，写入的信息将无法改变。
[0157] 在本实施例中，医疗服务机构进行历史医疗信息查询，包括病史、治疗史等，以便于做出正确的诊断。医疗机构需要查询判断自身是否具备查询申请者历史医疗信息的权限。如果不具备，则向医疗平台申请启用紧急查询许可，医疗平台将根据用户病情严重程度判断是否允许医疗机构查询用户历史医疗信息。
[0158] 在具备了上述条件后，医疗机构可以根据个人用户所指定医疗方案，在得到用户(或授权人)的治疗许可和签名后，对用户提供相应的医疗数据。然后，将治疗方案、治疗过程、治疗结果等信息将写入区块链。
[0159] 其中，医疗平台可以是特殊的节点，该节点具有中心节点的功能。
[0160] 步骤4：医疗机构向个人用户收取医疗费用。
[0161] 具体的，医疗服务提供结束，费用结算可以分为：用户申请费用结算；医疗机构根据智能合约等脚本进行结算。
[0162] 在结算申请通过验证后，医疗机构接收费用结算申请，进行资金划转，从用户账户余额中划转费用到医疗机构账户，并进行全网发布共识验证。费用结算后，生成费用结算记录。该结算记录可以包括费用结算记录唯一标识、费用发送者ID、费用接收者ID、费用类型、费用数额、时间戳、费用发送者签名信息。
[0163] 步骤5：医疗服务结束后，用户可以对医疗服务进行评价，比如采用打分的方式，评价结果也将作为评价数据记录纳入区块链存储验证。评价结果记录包括：评价结果记录标识、评价医疗数据记录标识、医疗服务提供者评价得分、治疗结果评价、治疗费用评价、用户签名和时间戳等。
[0164] 步骤6：医疗机构或医疗设备制造商发起医疗方案征集请求，参与者进行响应，并获得奖励。
[0165] 具体的，医疗机构或医疗设备制造商进行医疗方案征集，一般采用区块链脚本(如智能合约)发布，形式如治疗方案众筹奖励合约。治疗方案参与者(例如个人用户)响应征集请求，并制定医疗方案。将制定的医疗方案上传，并进行全网发布验证。验证通过后，生成医疗方案记录。该记录可以包括医疗方案记录唯一标识、方案制定者ID、方案发布范围、方案描述、时间戳、费用制定者签名等信息。之后，医疗方案发起方进行方案状态监测，并判断方案满足要求，并将判断结果发布到医疗平台，进行全网验证，验证之后，生成方案判断记录。该记录可以包括判断方案全网唯一标识、医疗方案记录唯一标识、判定者ID、认可程度(比如打分)、判断结果描述、时间戳、方案判定者签名等信息。医疗方案征集期限到达后，医疗平台根据方案及认可度，发放奖励，并在全网发布共识验证。根据本地存储的区块链中的方案判定记录，即可查询方案认可度。根据认可度，平台生成奖励发放记录。该记录包括奖励发放记录唯一标识、奖励发送者ID、奖励接收者ID、奖励类型、奖励方案记录标识、奖励数额、时间戳和奖励发送者签名等信息。
[0166] 图5为本发明医疗数据处理方法的第三个实施例的流程示意图。
[0167] 如图5所示，处理医疗数据的方法可以包括以下步骤：
[0168] S501：对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答。
[0169] S502：在该第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0170] 其中，医疗数据请求是第一节点向对等网络发送的请求，在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0171] 本实施例是从第二节点这侧进行了描述，而图3所示实施例是从第一节点那侧进行了描述，二者原理相同。图3流程中的细节内容同样适用于本实施例，此部分相同或者相似的内容不再赘述。
[0172] 图6为本发明医疗数据处理方法的第四个实施例的流程示意图。
[0173] 如图6所示，处理医疗数据的方法，该方法包括：
[0174] S601：对等网络中第一节点向对等网络发送医疗数据请求。
[0175] S602：在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0176] S603：对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答。
[0177] S604：在该第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0178] 本实施例分别从第一节点和第二节点这两侧进行了描述，而图3所示实施例是从第一节点那侧进行了描述，图5所示实施例是从第二节点那侧进行了描述，他们的原理相同。上述各实施例中的细节内容同样适用于本实施例，此部分内容不再赘述。
[0179] 图7为本发明处理医疗数据的系统的第一个实施例的功能结构示意图。
[0180] 如图7所示，该系统可以包括：发送单元和共识单元。其中：
[0181] 发送单元可以用于对等网络中第一节点向所述对等网络发送医疗数据请求。
[0182] 共识单元可以用于在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0183] 在一些可选的实施例中，在上述各实施例的基础上还可以增加获取单元。其中，获取单元可以用于第一节点从对等网络中获取来自第二节点针对医疗数据请求的医疗数据应答，第二节点为第一节点以外的其他节点中的任意一个或多个节点。在医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中之前，第二节点通过了对等网络的全网身份验证，并取得全网对医疗数据应答的共识。
[0184] 在一些实施例中，医疗数据请求可以包括：注册身份、查询医疗相关数据、上传医疗相关数据、下载医疗相关数据和结算医疗相关费用请求中的至少一种。其中，医疗相关数据包括：第一节点的属性信息、第二节点的属性信息、医疗方案信息、医疗费用信息、医疗周期信息、康复效果信息和医疗评价信息中的一种或者多种。
[0185] 在一些可选的实施例中，在上述各实施例的基础上还可以增加信息评估单元。该信息评估单元可以用于第二节点对待实施的医疗方案进行预先评估，预先评估的信息包括与待实施的医疗方案相关的第一医疗费用信息、第一医疗周期信息和第一康复效果信息，预先评估的信息在获得全网共识后被记录至区块链中。
[0186] 在一些可选的实施例中，上述各实施例的基础上还可以增加信息采集单元、信息比较单元和评分单元。其中：
[0187] 信息采集单元可以用于第一节点根据经过预先评估的医疗方案的实际实施情况，获取与预先评估的信息对应的实际实施的信息，实际实施的信息包括第二医疗费用信息、第二医疗周期信息和第二康复效果信息。
[0188] 信息比较单元可以用于第一节点将预先评估的信息与实际实施的信息相比较。
[0189] 评分单元可以用于第一节点根据比较结果和比较内容的权重对实际实施的医疗方案进行评分，在所述实际实施的信息和所述评分在获得全网共识后被记录至所述区块链中。
[0190] 在一些可选的实施例中，上述各实施例的基础上还可以增加信息检索单元和方案制定单元。其中：
[0191] 信息检索单元可用于在第二节点所述区块链内查询一个或者多个医疗方案信息、以及与一个或者多个医疗方案信息对应的医疗相关数据。
[0192] 方案制定单元可以用于第二节点根据查询结果制定实际实施的医疗方案信息。
[0193] 在一些可选的实施例中，在图7所示实施例的基础上还可以增加作用变更单元。其中，作用变更单元可基于医疗数据请求的目的，将第一节点与第二节点的作用进行变更。
[0194] 在一些实施例中，共识可以通过POW、POS及DPOS机制中的至少一种来达成数据一致。
[0195] 图8为本发明处理医疗数据的系统的第二个实施例的功能结构示意图。
[0196] 如图8所示，该系统可以包括：应答单元和共识单元。其中：
[0197] 应答单元可以用于对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答。
[0198] 共识单元可以用于在第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0199] 其中，医疗数据请求是第一节点向对等网络发送的请求，在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0200] 图9为本发明处理医疗数据的系统的第三个实施例的功能结构示意图。
[0201] 如图9所示，该系统包括：发送单元、第一共识单元、应答单元和第二共识单元。其中：
[0202] 发送单元可以用于对等网络中第一节点向对等网络发送医疗数据请求。
[0203] 第一共识单元可以用于在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0204] 应答单元可以用于对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答。
[0205] 第二共识单元可以用于在第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0206] 需要说明的是，上述图7和图8中的共识单元可以采用相同的功能单元，也可以采用不同的功能单元来实现。同理，图9中第一节点的共识单元和第二节点的共识单元也可以采用相同或者不能的功能单元来实现，此方面内容均不做限制。处理医疗数据的系统与处理医疗数据的方法相对应，二者具有类似的功能，可以解决类似的技术问题，因此，二者相同或者相似的地方不再赘述。
[0207] 图10为本发明处理医疗数据的系统的第一实施例的结构示意图。
[0208] 如图10所示，处理医疗数据的系统可以包括：显示器、存储器和处理器。其中：
[0209] 存储器可以用于存放程序。处理器可以用于执行存储器存储的程序，程序使得所述处理器执行以下操作：
[0210] 对等网络中第一节点向对等网络发送医疗数据请求；在第一节点通过对等网络的全网身份验证并取得全网对医疗数据请求的共识后，医疗数据请求被记录到对等网络的一个或多个网络节点处存储的区块链中；对等网络中第二节点响应于医疗数据请求，该第二节点向对等网络发送医疗数据应答；在第二节点通过对等网络的全网身份验证并取得全网对医疗数据应答的共识后，医疗数据应答被记录到对等网络的一个或多个网络节点处存储的区块链中。
[0211] 图11为本发明处理医疗数据的系统的第二实施例的结构示意图。
[0212] 如图11所示，该系统1100可以包括中央处理单元(CPU)，其可以根据存储在只读存储器(ROM)中的程序或者从存储部分加载到随机访问存储器(RAM)中的程序而执行各种适当的动作和处理。在RAM中，还存储有系统操作所需的各种程序和数据。CPU、ROM以及RAM通过通信总线彼此相连。输入/输出(I/O)接口也连接至总线。
[0213] 以下部件连接至I/O接口：包括键盘、鼠标等的输入部分；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分；包括硬盘等的存储部分；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分。通信部分经由诸如因特网的网络执行通信处理。驱动器也根据需要连接至I/O接口。可拆卸介质，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器上，以便于从其上读出的计算机程序根据需要被安装入存储部分。
[0214] 在一些可选的实施例中，各个节点也可以采用图10和11的结构图。
[0215] 但是，需要明确，本发明并不局限于上文所描述并在图中示出的特定配置和处理。并且，为了简明起见，这里省略对已知方法技术的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神之后，作出各种改变、修改和添加，或者改变步骤之间的顺序。
[0216] 以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者他们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。
[0217] 本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；不定冠词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。
[0218] 本发明可以以其他的具体形式实现，而不脱离其精神和本质特征。例如，特定实施例中所描述的算法可以被修改，而系统体系结构并不脱离本发明的基本精神。因此，当前的实施例在所有方面都被看作是示例性的而非限定性的，本发明的范围由所附权利要求而非上述描述定义，并且，落入权利要求的含义和等同物的范围内的全部改变从而都被包括在本发明的范围之中。
相关专利内容
标题 发布/更新时间 阅读量
监视对等网络-专利编号CN107690777A 2020-05-11 1048
带保护的对等网络-专利编号CN101297278B 2020-05-12 571
对等网络的安全协议-专利编号CN102427457A 2020-05-13 949
移动对等网络-专利编号CN101444113A 2020-05-11 1206
把设备连接到对等网络-专利编号CN1934830A 2020-05-14 278
对等网络平台的架构-专利编号CN101388898B 2020-05-13 564
对等网络连通性状态-专利编号CN102893274B 2020-05-12 782
安全对等网络设置-专利编号CN103765981B 2020-05-14 693
对等网络-专利编号CN101431529B 2020-05-11 1028
对等网络-专利编号CN101431529A 2020-05-11 1046
高效检索全球专利

IPRDB是专利检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据，专利查询、专利分析。

电话：13651749426

侵权分析

IPRDB的侵权分析产品是IPRDB结合多位一线专利维权律师和专利侵权分析师的智慧，开发出来的一款特色产品，也是市面上唯一一款帮助企业研发人员、科研工作者、专利律师、专利分析师快速定位侵权分析的产品，极大的减少了用户重复工作量，提升工作效率，降低无效或侵权分析的准入门槛。

立即试用

对等网络热门专利
热门文章

IPRDB

最新中国发明专利 最新美国发明专利 技术领域 专利库 专利分类库 国际专利分类库

热门服务

会员版试用 API 数据接口 找代理 知嘟嘟专利交易 排行榜 大学排行榜 专利百科

关于我们

平台介绍 战略合作 网站地图

友情链接

知嘟嘟专利交易 国家知识产权局 中国商标网

联系方式


©2019-2023 上海吉码数字技术有限公司 版权所有，并保留所有权利 沪ICP备20016256号-6 沪公网安备31011702005475号