基于区块链的医疗信息共享方法、装置、设备和存储介质与流程

基于区块链的医疗信息共享方法、装置、设备和存储介质
【技术领域】
1.本发明涉及信息共享技术领域，具体地涉及一种基于区块链的医疗信息共享 方法、装置、设备和存储介质。


背景技术：

2.虽然电子病历在中国各大城市已经被广泛采用，但医院提供的小程序和app 通常只能满足患者日常的预约、挂号、付费等需求，患者想查看或打印自己的临 床医疗信息只能亲自去相应的科室或在医院的自助机器上获取，患者对自身的临 床医疗信息缺乏自由访问、控制甚至删除的权利。
3.而且，临床医疗信息属于高度敏感的隐私信息，难以在医院、甚至是科室之 间共享，然而一些病情相对复杂的患者的治疗方案常常涉及多个科室和医院间的 合作。例如，患者张三在a医院住院，但是a医院缺乏某个治疗必须的医疗器械， 张三需要到b医院做治疗。如果临床医疗信息不能共享，会极大地耗费患者和医 生、医生和医生之间的沟通和时间成本。在上述例子中，张三需要把从a医院拿 到的检查结果和历史治疗方案带到b医院，两个医院的医生可能还需要就治疗方 案进行沟通。而且这些检查结果和方案通常是纸质文件或ct等胶片文件，容易 丢失和被损坏，一旦发生这种情况，病人就需要重新回a医院打印相关资料甚至 重新做检查，费时费力很不方便。
4.此外，在日常生活中个人常常需要向第三方机构提供临床医疗信息，例如签 订保险合同需要提供身体检查报告，申请赔付的时候需要提供医院的就诊记录和 治疗方案，甚至出现医疗纠纷的时候向法院提交就诊记录和治疗方案。但是患者 缺乏对临床医疗信息的控制权，需要亲自到医院打印或领取检查报告再送到第三 方机构，耗费时间成本。也因为这些过程涉及利益，且对于医疗数据缺乏有效的 校验方式，患者可能会通过造假临床医疗数据进行医疗诈骗和骗保行为。
5.目前，为了解决医疗数据的保存、共享和校验，其中一种解决方案是用户实 名注册之后为用户分配唯一账户，临床信息用医生用户的公钥加密形成医疗密文， 储存到云服务器，医疗密文的储存位置的url和索引信息上链。此解决方案中， 病人和第三方用户如果需要查看临床信息，需要经过医生许可并用私钥解密医疗 密文。医疗密文储存在只有医院医生才能使用的云服务器，不利于信息的共享和 流通。另一种解决方案是使用传统的数字签名的形式，将用户的敏感信息经过编 码加密处理，数字签名颁发机构为用户分配密钥对。用户同意临床信息共享之后， 医院或医疗机构用户的公钥对已加密的临床信息进行解密，上传至区块链共享系 统，并向患者用户返回上传信息的哈希值作为防篡改的存证。所上传共享的临床 信息对第三方机构(例如药企和研究性机构)开放，由于信息是脱敏的，保护了 患者用户的身份隐私安全。
6.然而，在现有的上述解决方案当中，至少存在以下问题：
7.第一，医疗数据的所有权并不在患者用户，临床信息并非用户可携带的，数 据一旦生成，因为患者需要经过医生用户同意才能查看病历信息，使用不变。
8.第二，上链信息无法被查询和溯源。
9.第三，上述解决方案的上链地址往往是唯一的(比如对用户的公钥经过两次 哈希运算得到的上链地址)，第三方观察者(例如链上不参与交易的的其他成员) 很容易通过聚类分析等大数据分析手段判断地址的所有者的基本信息，假如未来 有大量用户数据上链，可以对地址所有者进行详细的数据画像，极端情况下甚至 可以判断出地址所有者的身份，这种匿名方式是“伪匿名的”，可能会暴露客户 的隐私。


技术实现要素：

10.有鉴于此，本发明提供一种信息共享方法、装置、设备和存储介质，通过子 地址生成的一次性地址作为上链地址，第三方无法通过简单的对比将共享地址和 上链地址联系起来，从而有利于患者的隐私保护。
11.一方面，本发明实施例提供了一种基于区块链的医疗信息共享方法，包括：
12.根据患者的子地址生成上链地址和交易公钥，所述子地址是根据患者的签名 私钥生成的；
13.将患者临床信息对应的哈希值以所述上链地址发送至预先建立的区块链上 链存证，并对上链信息进行签名；
14.将所述交易公钥、所述临床信息的明文及所述临床信息的哈希值以及所述上 链地址发送至所述患者客户端；
15.向患者客户端发送临床信息共享请求，确定患者同意共享，则根据患者的子 地址生成新的上链地址作为共享地址，并将患者的临床信息通过所述共享地址共 享。
16.可选的，所述方法还包括：
17.所述患者客户端还被配置为根据患者和所述上链地址的对应关系生成地址 私钥。
18.可选的，患者客户端生成子地址的步骤，具体包括：
19.患者客户端获取患者账户的签名私钥并将所述签名私钥乘以椭圆曲线生成 器点生成签名公钥；
20.根据所述签名私钥派生出共享私钥，并根据所述共享私钥生成共享公钥；
21.根据所述签名私钥、所述签名公钥、所述共享私钥和所述共享公钥生成子地 址。
22.可选的，在将患者的临床信息通过所述共享地址共享之前，还包括：验证临 床信息的患者签名和医生签名。
23.可选的，患者客户端获取患者账户的签名私钥的步骤具体包括：
24.向预先建立的区块链发送患者注册请求，所述注册请求包括患者的身份信息；
25.预先建立的区块链上的证书颁发机构用于验证患者身份信息，验证通过则为 患者生成签名私钥发送并存储至所述患者客户端。
26.可选的，所述证书颁发机构还响应于医生客户端发送的医生注册请求，验证 医生的身份信息、科室信息和医院信息，为医生用来对临床信息签名的医生密钥 对。
27.另一方面，本发明实施例提供了一种信息共享装置，包括：
28.生成模块，用于根据患者的子地址生成上链地址和交易公钥；
29.上链存证模块，用于将患者临床信息对应的哈希值以所述存证地址发送至预 先
建立的区块链上链存证，并对上链信息进行签名；
30.发送模块，用于将所述交易公钥、所述临床信息的明文及所述临床信息的哈 希值以及所述上链地址发送至所述患者客户端，所述患者客户端还被配置为根据 患者和所述上链地址的对应关系生成地址私钥验证模块。
31.另一方面，本发明实施例提供了一种信息共享设备，包括存储器和处理器， 所述存储器用于存储包括程序指令的信息，所述处理器用于控制程序指令的执行， 所述程序指令被处理器加载并执行上述的信息共享方法的步骤。
32.另一方面，本发明实施例提供了一种存储介质，所述存储介质包括存储的程 序，其中，在所述程序运行时控制所述存储介质所在设备执行上述的信息共享方 法。
33.本发明实施例提供的技术方案中，使用根据患者的子地址生成的一次性地址 作为上链地址，上链地址、子地址以及患者(即用户)唯一的签名私钥之间没有 明显的联系，除了患者外的第三方均不能识别上链地址的归属，上链信息虽然不 能删除，但是其数据与患者本身的关系只有用户可以证明，有利于保护患者隐私； 临床信息链下由患者保存副本，数据对于患者来说有携带性；上链信息经由医生 签名，确保数据源头的真实性；将临床信息的哈希值上链，确保了数据不被篡改； 设置上链地址存证临床信息，设置共享地址共享病例信息，且共享地址和上链地 址是两个没有关联的地址，共享不记录交易公钥，而是通过交易公钥生成的，第 三方无法通过简单的对比将共享地址和上链地址联系起来，安全性更高。
【附图说明】
34.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用 的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施 例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根 据这些附图获得其它的附图。
35.图1是本发明一实施例所提供的一种基于区块链的医疗信息共享方法的流程 示意图；
36.图2为本发明一实施例所提供的基于区块链的医疗信息共享方法在患者初次 看诊时的流程示意图；
37.图3是本发明一实施例所提供的基于区块链的医疗信息共享方法在患者后续 看诊时的流程示意图；
38.图4是本发明又一实施例所提供的基于区块链的医疗信息共享方法在第三方 机构验证患者临床信息时的流程图；
39.图5是本发明一实施例提供的一种信息共享设备的示意图。
【具体实施方式】
40.为了更好的理解本发明的技术方案，下面结合附图对本发明实施例进行详细 描述。
41.应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施 例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下 所获得的所
有其它实施例，都属于本发明保护的范围。
42.在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在 限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、
ꢀ“
所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
43.应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系， 表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲 和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是 一种“或”的关系。
44.图1为本发明一实施例提供的基于区块链的医疗信息共享方法的流程示意图， 如图1所示，该方法包括以下步骤：
45.步骤s1，根据患者的子地址生成上链地址和交易公钥，所述子地址是根据患 者的签名私钥生成的；
46.步骤s2，将患者临床信息对应的哈希值以所述上链地址发送至预先建立的区 块链上链存证，并对上链信息进行签名；
47.步骤s3，将所述交易公钥、所述临床信息的明文及所述临床信息的哈希值以 及所述上链地址发送至所述患者客户端；
48.步骤s4，向患者客户端发送临床信息共享请求，确定患者同意共享，则根据 患者的子地址生成新的上链地址作为共享地址，并将患者的临床信息通过所述共 享地址共享。
49.需要说明的是，如图2所示，本发明又一实施例提供的一种基于区块链的医 疗信息共享系统的组成示意图，该系统包括：患者客户端(面向患者)、医生客 户端(面向医生)、证书颁发机构和其他第三方机构(比如保险公司、第三方研 究院、研究院的研究员用户等)，其中，证书颁发机构确认患者的身份信息，为 患者生成签名私钥，保存在用户钱包(即患者客户端)。同样的，证书颁发机构 还用于确认医生的身份信息和医院信息，为医生账户分配用来对临床信息(或病 历信息)签名的密钥对，医生通过医生客户端将患者的临床信息(患者某一次的 问诊记录形成一条对应的临床信息，同一患者关于同一个疾病的多次的问诊记录 形成的有时间顺序的临床信息为患者的病历。)上链存证，这里，预选建立的区 块链可以为医疗信息共享联盟链。患者和医生等用户通过证书颁发机构注册加入 医疗信息共享联盟链。证书颁发机构能够是一个第三方的具有身份验证功能的身 份管理系统，也可以是链上具有证书颁发权限的组织用户(例如医院、第三方机 构)，负责认证和颁发证书，管理属于链上身份，也可以创建共享通道和邀请成 员作为共享节点加入共享通道等，共享通道能够是属于该联盟链下的私有通信子 网，数据对其他非该通道成员不可见。共享通道按照需求在这个联盟链上可以是 多个的，医生可以根据用药、疾病类型等选择一个或多个通道进行临床信息共享。
50.本发明的一些具体实施例中，患者客户端生成子地址的步骤，具体包括以下 步骤：
51.患者客户端获取患者账户的签名私钥并将所述签名私钥乘以椭圆曲线生成 器点生成签名公钥；
52.根据所述签名私钥派生出共享私钥，并根据所述共享私钥生成共享公钥；
53.根据所述签名私钥、所述签名公钥、所述共享私钥和所述共享公钥生成子地 址。
54.在本技术的一些具体实施例中，患者客户端获取患者账户的签名私钥的步骤 具
体包括：
55.向预先建立的区块链发送患者注册请求，所述注册请求包括患者的身份信息；
56.预先建立的区块链上的证书颁发机构用于验证患者身份信息，验证通过则为 患者生成签名私钥发送并存储至所述患者客户端。
57.在本技术的一些具体实施例中，所述证书颁发机构还响应于医生客户端发送 的医生注册请求，验证医生的身份信息、科室信息和医院信息，为医生用来对临 床信息签名的医生密钥对。
58.在本技术的一些具体实施例中，所述方法还包括：
59.所述患者客户端还被配置为根据患者和所述上链地址的对应关系生成地址 私钥。
60.在本技术的一些具体实施例中，在将患者的临床信息通过所述共享地址共享 之前，还包括：验证临床信息的患者签名和医生签名。
61.在本技术的又一些具体实施例中，本发明实施例提供了一种信息共享装置， 包括：
62.生成模块，用于根据患者的子地址生成上链地址和交易公钥；
63.上链存证模块，用于将患者临床信息对应的哈希值以所述存证地址发送至预 先建立的区块链上链存证，并对上链信息进行签名；
64.发送模块，用于将所述交易公钥、所述临床信息的明文及所述临床信息的哈 希值以及所述上链地址发送至所述患者客户端，所述患者客户端还被配置为根据 患者和所述上链地址的对应关系生成地址私钥验证模块。
65.本发明的一些具体实施例中，使用根据患者的子地址生成的一次性地址作为 上链地址，上链地址、子地址以及患者(即用户)唯一的签名私钥之间没有明显 的联系，除了患者外的第三方均不能识别上链地址的归属，上链信息虽然不能删 除，但是其数据与患者本身的关系只有用户可以证明，有利于保护患者隐私；临 床信息链下由患者保存副本，数据对于患者来说有携带性；上链信息经由医生签 名，确保数据源头的真实性；将临床信息的哈希值上链，确保了数据不被篡改； 设置上链地址存证临床信息，设置共享地址共享病例信息，且共享地址和上链地 址是两个没有关联的地址，共享不记录交易公钥r_1，而是通过交易公钥生成的， 第三方无法通过简单的对比将共享地址和上链地址联系起来，安全性更高。
66.在本技术的一些具体实施例中，本发明实施例提供了一种信息共享设备，包 括存储器和处理器，所述存储器用于存储包括程序指令的信息，所述处理器用于 控制程序指令的执行，所述程序指令被处理器加载并执行上述的信息共享方法的 步骤。
67.在本技术的一些具体实施例中，本发明实施例提供了一种存储介质，所述存 储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执 行上述的信息共享方法。
68.为了便于理解下面以具体案例结合场景对本发明提供的方法进行详细说明。
69.案例1：患者小红初次去a医院皮肤科看病
70.该案例说明中使用的数学符号标识参见表1：
71.表1
72.名称标识示例用户公钥大写字母或以pubkey表示xiaohong_a，pubkey_wang用户私钥小写字母或以prikey表示xiaohong_a，prikey_wang，p_1地址或交易编号大写字母+编号(c_1,d_1)，r_1，p_1临床信息cl+编号cl1，cl2上链的哈希值h1，h2，h3h1＝hash(cl1，nonce)随机数noncehash(cl1，nonce)
73.场景1：小红初次注册和使用本系统(即基于区块链的医疗信息共享系统)
74.患者小红计划去医院a看病。参见图2，本发明提供的方法在患者初次看诊 时的流程如下：
75.1、用户注册：通过证书颁发机构验证注册请求，具体为：
76.在本技术的一些具体实施例中，本发明实施例提供了一种存储介质，所述存 储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执 行上述的信息共享方法。
77.2、患者用户登录客户端：登录时通过用户名密码以及生物识别手段(例如 指纹)验证用户身份，具体为：
78.用户通过自己设定的用户名以及密码或者人脸识别以及指纹识别等生物识 别手段登录钱包(即用户设备)。钱包为小红生成公钥xiaohong_b(具体过程 为能够为钱包把xiaohong_b乘以椭圆曲线的生成器点g，得到公钥xiaohong_b)， 组成签名密钥对{xiaohong_b，xiaohong_b}。钱包还能通过xiaohong_b为患者 小红派生出用作授权的共享私钥xiaohong_a，派生出共享公钥xiaohong_a，组 成共享密钥对{xiaohong_a，xiaohong_a}。
79.小红根据问诊需求，假设是a医院皮肤科王医生，在钱包端生成子地址 (c_1,d_1)，子地址(c_1,d_1)通过上述两对原始密钥对生成，具体为：
80.d_1＝xiaohong_b+h(xiaohong_a,1)*g；
81.c_1＝xiaohong_a*d_1；
82.小红把这个地址标记为“a医院皮肤科王医生”，即虚拟身份，并在看诊 的时候把这个子地址提供给王医生，提供的方式可以是地址生成一个二维码，医 生扫描二维码即可。
83.3、问诊：医生客户端根据患者的子地址生成上链地址p和交易公钥r，具 体为：
84.医生客户端接收到子地址(c_1,d_1)，生成本次看诊(为了便于描述，本 次看诊计为第一次看诊a)的交易公钥r_1和一次性地址p_1：。
85.p_1＝h(s*c_1)*g+d_1；
86.r_1＝s*d_1，s是随机数；
87.其中，交易公钥是写入临床信息的这次操作的识别公钥，一次性地址是该临 床信息经过哈希函数处理之后的编码上链的地址。
88.4、临床信息存证：明文临床信息发送给患者用户，临床信息的哈希值通过 地址p上链，具体为：
89.王医生使用私钥prikey_wang对写入的临床信息签名，(在此之前，证书 颁发机构
确认医生的身份信息和医院信息，为医生账户分配用来对病历信息签名 的密钥对{prikey_wang,pubkey_wang})，明文临床信息发送给小红，临床信 息的哈希值通过地址p上链。小红的钱包中显示在地址(c_1,d_1)下有一个交 易r_1，上链地址为p_1,上链信息为临床信息的哈希值h1：
90.h1＝hash(cl1，初始值)。
91.5、向患者用户提出临床信息共享申请，判断患者是否同意，如果是则医生 客户端或者智能合约生成新的上链地址(即共享地址)，将患者的临床信息通过 该共享地址上链储存。
92.6、结束：患者的临床信息共享完成。
93.通过本场景，至少存在以下有益效果：
94.1)医院或医生不必在本地数据库中储存患者的身份信息，写入临床信息的 时候也不用一再输入患者的个人身份信息，医生可以通过用户提供的公钥 xiaohong_a和xiaohong_b生成的子地址(c_1,d_1)就可以写入临床信息并通 过钱包或智能合约计算哈希值上链存证,因为用户身份的合法性在用户注册和用 户登录的时候已经被验证了。
95.2)小红的临床信息的哈希值h1以一次性地址p_1上链，同时在链上会记 录交易公钥r_1，交易公钥是随机生成的(s是随机数)。用户或攻击者或者医 生很难通过计算机穷举的方式生成一个新的r'_1伪造这份临床信息。
96.3)医院在本地服务器上的储存小红的临床信息，以交易公钥r_1作为索引， 但是不必要储存小红的身份信息或者子地址。复诊时，小红通过p_1来证明自己 拥有地址p_1。医生可以通过p_1在链上查询到r_1就可以调用本地储存的临 床信息cl1。具体可参见下面的见场景2和场景3。此外，医院本地储存可以是 有时限的，譬如说重症医学或者慢性病的治疗是一个长期的过程，所以储存病历 的时间比较长，可以到5年以上。门诊记录的临床信息和病历可以是短期储存在 本地，一到两年就可以删除。这样可以节省本地储存的空间，也能保护患者的隐 私。
97.场景2：小红去a医院皮肤科王医生处复诊：
98.参见图3，本发明提供的方法在患者后续看诊的流程如下：
99.1、患者用户登录客户端：登录时通过用户名密码以及生物识别手段(例如 指纹)验证用户身份，具体为：
100.小红已经在本系统注册，用账户和密码(更安全的也可以经过多重验证，例 如加上手势密码、指纹识别等生物识别技术)登录钱包。
101.2、钱包(即患者客户端)生成地址私钥p验证地址p(即上链地址)的归 属，获得公钥r，在数据库中查找对应的临床信息，具体为：
102.需要说明的是，数据库可以为医院本地数据库，为了快速检索，医院可以在 本地服务器上储存患者的临床信息，并以交易公钥r_1作为索引，作为优选， 无需储存患者的身份信息或者子地址。
103.由于是复诊，王医生需要调用小红上一次的临床信息。小红可以通过私钥p_1 证明地址p_1的归属(即通过私钥p_1查找小红名下有几个对应的上链地址)。
104.p_1＝h(xiaohong_a*r_1)+xiaohong_b+h(xiaohong_a,i)
105.p_1＝p_1*g
106.王医生的医生客户端或链上智能合约通过p_1查找本地数据库或者链上信 息，复诊时，小红通过p_1来证明自己拥有地址p_1。医生可以通过p_1在链 上查询到r_1就可以调用本地储存的临床信息cl1。
107.同样的，医生客户端根据患者的子地址(c_1,d_1)，生成本次看诊(本次 看诊计为第二次看诊)的交易公钥r_2和一次性地址p_2，和cl1的写入过程 一样写入新的临床信息cl2，临床信息cl2的哈希值h2以一次性地址p_2为 上链地址上链。以此类推，小红第三次去复查生成r_3和p_3，新的临床信息 cl3，新的上链信息为h3。
108.h1＝hash(cl1，初始值)
109.h2＝hash(cl2,h1)
110.h3＝hash(cl3,h2)
111.参见上述场景1的步骤，将第二次看诊形成的新的临床信息存证：明文临床 信息发送给患者用户，临床信息的哈希值通过地址p_2上链，具体过程不再赘述，
112.3、向患者用户提出临床信息共享申请，判断患者是否同意，如果是则医生 客户端或者智能合约生成新的上链地址(即共享地址)，将患者的临床信息通过 该共享地址上链储存。
113.6、结束：患者的临床信息共享完成。
114.这样设计的主要目的是：
115.1)生成第一个上链哈希值的临床信息cl1加上了初始值(随机数)，下一 个临床信息cl2与前一个临床信息的哈希值h1组成新的上链哈希h2。患者可 以根据医生需求选择性的提供多个地址(例如p_1、p_2和p_3)给医生或者只 提供最新(例如p_3)的上链地址给医生。通过哈希值链接组成有时间的先后顺 序、可追溯源头和过往病史的“病历链”尤其是对一些慢性病或者重症疾病的治 疗来说非常的重要。
116.2)对于有核查病历完整度的第三方机构(例如保险公司)来说，可以通过 简单的哈希计算就判断出病人提供的信息是否完整的，规避了借助提供不完整的 病历信息进行保险诈骗等欺瞒诈骗行为，详细应用场景见案例3和案例4。
117.场景3：小红去a医院皮肤科张医生处复诊
118.1、登录客户端：
119.小红已经在本系统注册，用账户和密码(更安全的也可以经过多重验证，例 如加上手势密码、指纹识别等生物识别技术)登录钱包。由于王医生不在，小红 只能在张医生处复诊。因此张医生需要调用小红前几次的临床信息。小红通过钱 包生成地址私钥p_1，p_2和p_3，验证链上存证地址p_1、p_2和p_3的归属 权，通过验证后钱包自动发送给张医生。张医生的客户端或链上智能合约通过三 个地址p_1、p_2和p_3查找链上信息，得到链上记录r_1，r_2和r_3，在 本地数据库中查找小红的病历，即小红前三次看诊的临床信息组成的“病历链”。 张医生的客户端自动填上小红最后一次看诊的临床信息cl3的哈希值h3,并使用 小红提供的子地址生成该次看诊的交易公钥r_4和一次性地址p_4，上链信息 为h4＝hash(cl4,h3)。
120.具体的，这里可能存在以下两种场景：
121.场景3.1：小红使用和上一次看诊相同的子地址(c_1,d_1)去a医院皮肤 科张医生处复诊；张医生的客户端自动填上小红最后一次看诊的临床信息cl3 的哈希值h3,并使用
小红提供的子地址(c_1,d_1)生成r_4和p_4，上链信息 为h4＝hash(cl4,h3)。
122.场景3.2：小红使用新子地址去a医院皮肤科张医生处复诊；小红为张医生 创建了新的子地址(c_2,d_2)，即
123.d_2＝xiaohong_b+h(xiaohong_a,2)*g
124.c_2＝xiaohong_a*d_2
125.张医生的客户端或者通过智能合约生成r_4和p_4：
126.r_4＝s*d_2，s是随机数
127.p_4＝h(s*c_2)*g+d_2
128.同场景3.1所述，小红通过钱包生成地址私钥p_1，p_2和p_3，验证链上 存证地址p_1、p_2和p_3的归属权，通过验证后钱包自动发送给张医生。张 医生的客户端或链上智能合约通过三个地址p_1、p_2和p_3查找链上信息， 得到链上记录r_1，r_2和r_3，在本地数据库中查找小红的病历，即小红前 三次看诊的临床信息组成的“病历链”。张医生的客户端自动填上小红最后一次 看诊的临床信息cl3的哈希值h3,并使用小红提供的子地址(c_1,d_1)生成 r_4和p_4，上链信息为h4＝hash(cl4,h3)。
129.与场景3.1的区别是，钱包显示小红有两个子地址(c_1,d_1)和(c_2,d_2)。 (c_1,d_1)下有三个链上存证，地址为p_1、p_2和p_3。(c_2,d_2)下有 一个链上存证，地址为p_4。在这种情况中，使用新的子地址并没有影响“病历 链”的形成，上链信息为：
130.h1＝hash(cl1，初始值)
131.h2＝hash(cl2,h1)
132.h3＝hash(cl3,h2)
133.h4＝hash(cl4,h3)
134.案例2：小红的临床信息共享
135.该案例说明中使用的数学符号标识参见表2：
136.表2
137.名称标识示例用户公钥大写字母或以pubkey表示xiaohong_a，pubkey_wang用户私钥小写字母或以prikey表示xiaohong_a，prikey_wang，p_1地址或交易编号大写字母+编号(c_1,d_1)，r_1，p_1临床信息cl+编号cl1，cl2上链的哈希值h1，h2，h3h1＝hash(cl1，nonce)
138.场景4：小红初次注册和使用本系统
139.小红的钱包接收医生客户端发来的共享病历请求，钱包告知匿名保护、共享 病历的目的、共享的对象(通道有几家医院或机构)以及共享的作用等。这里需 要说明的是，通过共享通道共享的临床信息不包含病人的身份信息(姓名、出生 年月、身份证号码和手机号码等)，共享的病历可以用作第三方研究机构对特定 疾病的研究或者药企对某种药物效果的追踪。共享的通道按照需求在这个联盟链 上可以是多个的，医生可以根据用药、疾病类型等选择一个或多个通道进行临床 信息共享。小红同意上链共享，钱包生成h(xiaohong_b*r_1)*g并提供给 医生的客户端，医生客户端或智能合约接收请求，构建共享地址p'_1，cl1以 p'_1为地址在共享通道上链：以王医生的客户端为例，pubkey_wang为王
医生 的用户公钥：
140.p'_1＝h(xiaohong_b*r_1)*g+pubkey_wang；
141.假如小红不同意共享，拒绝共享请求，(h(xiaohong_a*r_1)*g)不 存在。医生客户端或智能合约则不在能构建出共享地址p'_1。
142.场景5：小红复诊的临床信息共享
143.如场景4所述，钱包告知匿名保护、共享病历的目的、共享的对象(通道有 几家医院或机构)以及共享的作用等。
144.小红同意上链共享，钱包生成h(xiaohong_b*r_2)*g并提供给医生的 客户端，医生客户端或智能合约接收请求，构建共享地址p'_2，cl2以p'_2 为地址在共享通道上链：以王医生的客户端为例，pubkey_wang为王医生的用 户公钥：
145.p'_2＝h(xiaohong_b*r_2)*g+pubkey_wang；
146.依次类推，
147.p'_3＝h(xiaohong_b*r_3)*g+pubkey_wang；
148.同时，以张医生的客户端为例，pubkey_zhang为张医生的用户公钥：
149.p'_4＝h(xiaohong_b*r_4)*g+pubkey_zhang。
150.本方案在场景4和场景5实现了以下几个目的：
151.1)通道之间的数据不互通，只有通道成员可以看到该通道的上链内容。假 如医生或者该医院选择将小红的临床信息共享至a医院的共享通道，则没有加入 该通道的b医院就无法调用这份临床信息。假如医院或医生选择将小红的临床信 息共享至a医院和b医院皮肤科的科室共享通道，则a医院和b医院的其他科 室医生无法查看和调用这份临床信息。
152.2)p_1和p'_1是两个没有关联的地址，p'_1不记录交易公钥r_1，而通 过r_1生成的，第三方观察者无法通过简单的对比将p_1和p'_1联系起来。
153.3)h(xiaohong_b*r_1)*g＝p'_1-pubkey_wang，p'_1和 pubkey_wang是公开的信息，因此h(xiaohong_b*r_1)*g可以通过程序 进行批量的计算和整理，但是由于哈希函数的特性，逆运算获得b和r_1的可 能性可以视作0，用户的私钥和r_1不会被泄露。
154.4)由于r_1，r_2，r_3和r_4是随机生成的(r_i＝s*d_i,s为随机数)， 也就是说，p'_1，p'_2，p'_3和p'_4是随机生成的地址，他们之间没有直接的 联系，观察者无法通过观察到这些临床信息之间的关系。
155.5)将临床信息上链到共享通道的是拥有共享通道成员身份的a医院的医生， 小红没有共享通道的成员身份，所以无法查看自己的上链信息。但是小红可以通 过提供h(xiaohong_b*r_2)*g和写入病历医生的公钥证明p'_i地址的归属。
156.案例3：小红去b医院皮肤科李医生处复诊
157.场景6：一般的的复诊流程
158.小红因为一些特殊原因，需要去b医院的皮肤科李医生处复诊，b医院也加 入了本方案所述的临床信息共享联盟链，同时是与a医院的皮肤科同属一个共享 通道的成员。
159.小红可以选择将复诊所需本地保存的明文病历通过链下的途径发送给李医生。 为了将临床信息cl5的哈希值上链存证，小红给李医生提供子地址(c_2,d_2)， 构建出r_5和p_5，以及最后一次在看病的临床信息上链地址p_4。本次复诊 后上链哈希值为h5＝hash(cl5，h4)。
160.场景7：小红不向李医生提供最后一次看病的临床信息上链地址p_4
161.小红将复诊所需本地保存的明文病历通过链下的途径发送给李医生，还有子 地址(c_2,d_2)，构建出r_5和p_5。因为一些原因，小红不告知李医生最后 一次看病的临床信息上链地址p_4。这样会破坏“病历链”的形成，上链的哈希 值为:
162.h5＝hash(cl5，初始值)。
163.这种情况对临床信息的上链存证没有影响，只是上链的信息不能构成一个有 时间排列、前后顺序的哈希链。对患者看病的需求和医生查看过往病史的需求来 说可能不是一个很大的问题，但是对于有审核病历真实和完整性的第三方机构来 说，这个情况就比较致命，因为患者可能会隐藏一个或者几个临床信息。在上述 例子中，h1到h4形成一个“病历链”，h5是一个单独存证的临床信息，患者 可以向第三方机构隐藏h5而不被发现(h1-h4形成的哈希链可以通过简单的 通过计算得提供的临床信息是否完整)。
164.其中一个解决方案是，由于医生在向本系统注册医生身份的时候，科室的类 型就被确定了(所属医院有可能会更改)。也就是说，医生向一位患者写入临床 信息和并对信息签名的时候，医生的科室是确定的，不会出现皮肤科医生为耳鼻 喉科的患者写入病历的情况。又由于钱包是使用初始种子派生出来的主密钥对{a,a}和{b,b}生成子地址，无论患者用几个子地址生成上链地址，钱包都可以对 患者挂号和看病以及写入临床信息的医生科室进行计数。例如在小红的例子中， 小红在皮肤科下有5个临床信息，参见表前三个h1-h3是a医院王医生在子地 址(c_1,d_1)写入，h4是a医院张医生写入，链上存证地址p_4用(c_2,d_2) 生成，h5是b医院李医生写入的，链上存证地址p_5用(c_2,d_2)生成。参 见表3，小红在皮肤科下总共有5个临床信息，其中h1-h4形成了“病历链”， h5是单独上链存证的临床信息。因此上链的信息cl中还可以加上签名医生的科 室、客户端下该科室的临床信息总数一同上链储存。患者的钱包客户端可以对特 定科室下的交易计数。此外，使用新的子地址(c_3,d_3)生成cl5的上链地址 p_5也不会影响计数。
165.表3
166.临床信息医院科室/医生子地址上链信息cl1a医院皮肤科/王医生(c_1,d_1)h1＝hash(cl1，初始值)cl2a医院皮肤科/王医生(c_1,d_1)h2＝hash(cl2,h1)cl3a医院皮肤科/王医生(c_1,d_1)h3＝hash(cl3,h2)cl4a医院皮肤科/张医生(c_2,d_2)h4＝hash(cl4,h4)cl5b医院皮肤科/李医生(c_2,d_2)h5＝hash(cl5，初始值)
ꢀꢀꢀ
总数5
167.另外一个解决方案是，当钱包用户需要把病历(系列临床信息)发送给有验 证需求的第三方或者医生时，钱包或者智能合约自动抓取所有子地址下同科室医 生签名的交易，组成一个集合{p_1，p_2，p_3，p_4，p_5}。这个解决方案的 一个延伸是，参考门罗币的环签名实现，通过钱包或者智能合约抓取多个地址发 送给第三方机构，内含用户的所有交易以及其他用户在链上的交易地址，例如 {p_1，p_2，p_3，p_4，p_5，p_a，p_b，p_c，p_d，p_e}，第三方机构无 法识辨哪些地址是的该用户的链上存证地址，但是用户可以使用地址p_i的唯一 密钥p_i证明地址的归属，向第三方机构返回对应地址的哈希值，详细步骤请看 案例3。
168.案例3：保险公司审核小红的临床信息(病历)
169.参见图4，保险公司等其他第三方机构在审核验证前同样通过证书颁发机构 注册加入联盟链(即预先建立的区块链)，即证书颁发机构为机构用户注册机构 用户身份；
170.注册成功之后，第三方机构用户提交临床信息验证申请：即向患者客户端发 送验证请求，验证请求携带机构信息(机构名称、机构地址等)、验证目的等信 息；患者客户端即患者钱包显示第三方机构的信息和验证申请，若得到患者授权 同意验证，则钱包生成地址私钥p验证地址p的归属，根据验证结果，将通过验 证的地址p反馈至第三方机构，即验证通过向第三方机构返回验证信息和链上存 证记录，需要说明的是，链上存证记录可以为上链地址。
171.下面结合案例详细说明，保险公司或者其他第三方机构需要检验小红的病历。 如案例2场景7所述，小红在皮肤科下的临床信息链上存证一共有5个，其中 h1-h4形成了“病历链”，h5是单独上链的临床信息。由于p_1、p_2、p_3、 p_4和p_5是根据小红提供的子地址生成的没有关联的5个链上存证地址(同 时链上还有很多其他人的链上存证地址)。小红要向保险公司证明自己拥有这五 个地址，可以使用私钥p_1证明地址p_i的归属。
172.p_1＝h(xiaohong_a*r_1)+xiaohong_b+h(xiaohong_a,i)
173.p_1＝p_1*g
174.如案例2场景7所述，为了避免小红向第三方机构提供不完整的临床信息 链上存证地址，本发明实施例还提供了如下方案：参考门罗币环签名的实现，利 用钱包或者只能合约抓取多个链上存证地址。本例子中一共5个存证地址{p_1， p_2，p_3，p_4，p_5}，具体实现步骤：
175.a.抓取并提供给第三方机构的地址集合：x＝{p_1，p_2，p_3，p_4，p_5， p_a，p_b，p_c，p_d，p_e}
176.b.向第三方客户端提示小红临床信息的总数：5
177.c.小红使用对应地址的唯一私钥y＝{p_1，p_2，p_3，p_4，p_5}对集合x 签署
178.p的生成公式：p_i＝h(xiaohong_a*r_i)+xiaohong_b+h(xiaohong_a,i)
179.d.验证通过，向第三方机构返回对应地址的哈希值，第三方机构不知道哈希 值对应的是哪几个地址，但是知道小红提供的五个地址的哈希值以及她提供了完 整的病历信息。
180.案例3还适用于所有对患者/用户的个人病史和临床信息有验证需求的场合， 例如保险公司为客户提供重症疾病险的时候需要验证客户的过往病史、打疫苗时 用户向防疫机构出示自己的过往病史、入职时新员工向公司提供入职体检报告、 出国签证时所必须的疫苗种植和身体检查，均可存证至链上供用户后期查询和检 验。
181.这个解决方案的解决了两个在本场景下的重要问题。其一，避免了第三方机 构记录小红提供的5个链上存证地址和小红提供的明文临床信息形成机构的数据 库，以后通过聚类分析等大数据分析对小红的病史和个人生活习惯(活动范围、 饮食习惯、用药及医保状况进而推测出工资水平和涨薪幅度等)，侵犯客户的隐 私；另外，避免了用户因为维护自身利益，向第三方有检验需求的机构提供遗漏 重要信息的病历，隐瞒真实情况，造成诸如骗保等系列问题，为医生或者第三方 机构带来经济、时间和名誉损失，激化医患矛盾。
182.案例4：小程借用小红的存证地址对第三方检验机构隐瞒临床信息
183.小程因为某些个人原因，不希望提供自己的真实临床信息给第三方检验机构， 于是借用了小红的临床信息。小程拿到了小红的临床信息cl1，上链哈希值h1， 链上存证地址p_1和交易公钥r_1。该第三方检验机构收到小程发来的资料， 希望小程通过存证地址唯一的私钥p_1证明该地址的归属。由于(c_1,d_1)是小 红的子地址，p_1(p_1＝h(s*c_1)*g+d_1)是小红初次看诊时a医院王 医生生成的上链存证地址，s是随机数，也就是p_1是随机生成的，无法再次生 成。小红可以使用p_1证明p_1地址的归属。私钥对{xiaohong_a，xiaohong_b} 是小红的私人密钥，小程无法通过自己的密钥对生成p_1。
184.这里，p_1＝h(xiaohong_a*r_1)+xiaohong_b+h(xiaohong_a,i)； 小程无法证明地址p_1是属于自己的，第三方机构可以检验出这个地址并不是小 程所有。
185.本发明实施例提供了一种存储介质，存储介质包括存储的程序，其中，在程 序运行时控制存储介质所在设备执行上述信息共享方法的实施例的各步骤，具体 描述可参见上述信息共享方法的实施例。
186.本发明实施例提供了一种信息共享设备，包括存储器和处理器，存储器用于 存储包括程序指令的信息，处理器用于控制程序指令的执行，程序指令被处理器 加载并执行时实现上述信息共享方法的步骤。具体描述可参见上述信息共享方法 的实施例。
187.图5是本发明实施例提供的一种信息共享设备的示意图。如图6所示，该实 施例的信息共享设备6包括：处理器61、存储器62以及存储在存储62中并可 在处理器61上运行的计算机程序63，该计算机程序63被处理器61执行时实现 实施例中的应用于信息共享方法，为避免重复，此处不一一赘述。或者，该计算 机程序被处理器61执行时实现实施例中应用于信息共享装置中各模型/单元的功 能，为避免重复，此处不一一赘述。
188.信息共享设备6包括，但不仅限于，处理器61、存储器62。本领域技术人 员可以理解，图6仅仅是信息共享设备6的示例，并不构成对信息共享设备6的 限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件， 例如信息共享设备6还可以包括输入输出设备、网络接入设备、总线等。
189.所称处理器61可以是中央处理单元(central processing unit，cpu)，还 可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专 用集成电路(application specific integrated circuit，asic)、现场可编程门阵列 (field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或 者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器 也可以是任何常规的处理器等。
190.存储器62可以是信息共享设备6的内部存储单元，例如信息共享设备6的 硬盘或内存。存储器62也可以是信息共享设备6的外部存储设备，例如信息共 享设备6上配备的插接式硬盘，智能存储卡(smart media card,smc)，安全 数字(secure digital,sd)卡，闪存卡(flash card)等。进一步地，存储器 62还可以既包括信息共享设备6的内部存储单元也包括外部存储设备。存储器 62用于存储计算机程序以及信息共享设备6所需的其他程序和数据。存储器62 还可以用于暂时地存储已经输出或者将要输出的数据。
191.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的 系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在 此不再赘述。
192.在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法， 可以
通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例 如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式， 例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽 略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接 可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或 其它的形式。
193.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显 示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分 布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现 本实施例方案的目的。
194.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也 可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。 上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的 形式实现。
195.上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读 取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使 得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器 (processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质 包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取 存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程 序代码的介质。
196.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明 的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保 护的范围之内。