企业应用区块链的正确姿势

本文以一个完整方案为例向大家展示如何利用公有链解决医疗领域的一些痛点展示企业应用区块链。

最近一年区块链被炒得热火朝天，然而私有链已被证伪，联盟链也备受质疑，仅剩的公有链除了发币、菠菜、爱西欧以外还没有让大众看到更多价值。本文以一个完整方案为例，向大家展示如何利用公有链解决医疗领域的一些痛点，这可能才是企业应用区块链的正确姿势。

​

 

MedRec++

摘要

本文提出一种基于公有链实现的医疗数据管理方案，使得人们能够掌管个人的医疗数据，方便在患者授权的情况下不同机构间的数据共享。MIT提出的MedRec方案试图解决这个问题，但由于其基于私有链，所能提供的公信力有限。在解决了公有链可能导致的患者身份泄漏问题、评估了性能及费用后，我们提出了基于公有链的方案。将区块链技术应用于医疗领域，实现患者对个人医疗数据的掌控，打通医院间数据的传输通道，改善患者转诊服务，更好的支持国家的分级诊疗体系建设。将医疗数据交还给患者，可以更好的保护患者隐私，此外，还将有助于医疗数据的商业化，推进医疗AI的发展，最终使患者受益。

1.引言

随着近些年互联网技术的发展，人们可以很方便的传输数据、获取信息，然而关系到个人健康的医疗数据，管理系统却还很落后。医疗机构每天有大量健康数据产生，却因为无法实现跨区域共享，分散存储于各个数据孤岛。

纵观欧美发达国家，为加强个人健康管理，促进医疗协作、提高医疗质量并降低医疗成本，各国政府都在鼓励医疗机构开放健康数据给患者。目前我国也已由医院信息化、临床信息化向区域信息化发展，但较发达国家还存在差距。随着患者对于掌控个人医疗数据需求的增加，以及更深层次互联互通的不断推进，可以预见，将医疗数据交还给患者、实现数据互通、数据访问接口统一，将是未来的发展方向。

基于这一发展趋势，我们提出一种基于区块链的医疗数据管理方案。借助区块链的去中心化、匿名、不可篡改等特性，解决信任、隐私保护以及医疗数据的防篡改等问题。实现患者对个人医疗数据的访问管理及授权机制，实现不同机构、患者间的多方信任及数据流通。

我们参考了MedRec的设计，将匿名的医疗数据存储于链下，而链上仅存储数据索引、数据Hash、以及数据权限等关键信息。不同于MedRec，我们认为将用户身份信息存储于链上也是不必要的，因此改由认证机构CA实现这部分功能，在不影响公信力的前提下降低成本并增加安全性。此外由于私有链及联盟链在2C的场景下公信力存疑，我们尝试基于公有链实现，使其能够具备更强的公信力。

2.系统结构

我们的系统主要由三部分构成：CA、Blockchain、Network Nodes。

​

CA为授权机构，记录用户身份与公钥的映射关系。除了记录数据外，还负责用户身份的核实，响应用户的查询请求并对异常访问给予限制，授权第三方数据存储节点等。

​

Blockchain为区块链，记录患者与医疗数据的关联、医疗数据的索引等关键信息。区块链数据公开可查，但这并不会导致患者隐私的暴露，因为Patient地址到Pointer地址的关联利用加密技术实现了隐藏。

​

Network Nodes为数据存储节点，用于保存脱敏后的医疗数据。医院可以自己搭建节点，为节省成本也可对接经由CA认证的第三方数据存储节点。

​

 

内部引入三类对象：Provider、Patient、Pointer。

​

Provider为数据提供者，他们能够从CA查询患者的公钥，并向系统提交患者的医疗数据。可以为每个医生各分配一个Provider账户，或者医院共用一个。

​

Patient为患者，自己掌管私钥，公钥及身份信息提交给CA进行登记，并可以随时更换新公钥以更好的保护隐私。

​

Pointer为医疗数据指针，记录数据Hash、权限、存储节点编号等。

​

任何中心化的系统里，系统维护者都具备最高权限，用户需要信任系统的安全性以及管理者的人品。而去中心化系统则不需要这样的信任，去中心化系统里任何人都不具备凌驾于他人的特权，写入区块链的内容无法被篡改，借此解决医疗数据的防篡改问题。每个用户掌握自己的私钥，意味着不能被冒充，也不能对所签署的信息进行抵赖，借此实现用户对数据的授权机制。

3.实现细节

以UTXO模型举例，添加一条医疗数据需要两笔交易，为保证更好的隐私保护，最好避免两笔交易之间的关联被挖掘。如Tx2由Provider A发起，则Tx1由其他CA认证的账户发起，甚至错开一定时间。同一时间段新增的数据越多，Tx1、Tx2的关联越难被发现。

 

交易有可能是多输入多输出类型，因不影响分析，这里进行了简化。

上图为Provider A提交Patient B的医疗数据D时产生的两笔交易，Pointer D的内容记录于Tx2的OP_Return字段。

 

因为我们基于公有链，为隐匿Patient与Pointer之间的关联，我们用到加密算法的一个特性，下面以F代表椭圆曲线公钥创建函数进行说明。

​

若：F(私钥)==公钥

​

则：F((私钥+r)%p)==公钥+F(r)==新公钥

​

其中：r为随机数，(私钥+r)%p==新私钥

​

因此我们让Provider A生成随机数r1，配合从CA获得的Patient B的公钥，最终生成Pointer D的地址，后使用Patient B的公钥对r1进行加密得到R1写入区块链。而Patient B从区块链得到R1后使用私钥解密获得r1，进而配合自己的私钥生成Pointer D的私钥及地址。在此过程中，因为Provider A无需接触Patient B的私钥，所以Patient B有理由相信Pointer D的私钥仅由其本人掌握。

需要说明的是，我们将Patient到Pointer路径隐藏而不是消除是有意义的，比如保险公司想要获得患者医疗数据时，患者可以将数据交给对方，并展示数据和自己的关联。

4.交互流程

这里我们以医院为患者新增数据以及患者拉取数据为例，向读者演示系统的交互流程。为简化问题，我们以医院自建存储节点的情形举例，这里的Provider Node即代表医院端节点，而Patient Node代表患者端节点：

 

① 医院添加新数据

② 向CA查询患者公钥

③ 将相关信息写入区块链

④ 脱敏数据写入数据库

⑤ 患者由区块链获得数据指针

⑥ 向CA查询数据提供者信息

⑦ 患者对信息进行确认

⑧ 向数据存储节点请求数据

⑨ 存储节点核实患者信息

⑩ 确认无误后返回数据给患者端

⑪ 患者端检查数据Hash并存储于本地

类似的交互流程同样适用于医院间及第三方节点间，在获得患者的签名后，他们可以直接从医院拉取数据，并将签名信息作为患者授权的凭证保存。从结果上看这和患者拿到数据后私下发送给第三方并没有本质区别。并且如有需要，我们的方案能够实现，在第三方不直接与患者接触的情况下得到患者的授权并拿到数据，从而保持数据的匿名性。当然，若是转诊的过程中，医院需要核实某些数据的真实性以及完整性，将由患者来出示证明。

另外若医生由于误操作或恶意的将他人的数据关联到不相干的用户地址，用户可以向CA投诉并要求医生作废相应Pointer，否则在用户购买健康险时，这些不真实的数据将可能影响健康评估的得分。

5.数据安全

为使患者的隐私得到更充分保障，患者可以每次就诊都使用不同的地址，CA仅存储最新的用户公钥，而历史公私钥仅由患者本人掌握。并且即使这种情况下，当我们需要向他人出示病例数据时，借助地址之间的关联性，我们依然可以向其证明我们并未隐瞒某些历史。

由于数据存储节点保存的是脱敏数据，且同一患者不同病例数据之间的关联也被隐藏，相较传统方案，本方案在一定程度上降低了数据泄漏的危害。然而，考虑到数据挖掘等相关技术的发展，以及医疗数据的特殊性，仅依靠匿名数据依然有可能分析出患者的真实身份，因此CA应严格把控第三方数据存储节点的资格审核，并要求其做好安全防护。

由于将数据的最高权限交还给了患者，若患者私钥丢失或泄漏，直接影响患者数据的安全。在设计用户APP的时候，需要尽可能避免这类情况的发生，这方面可借鉴加密货币钱包的相关经验。

同MedRec一致，本方案并不保证存储节点及患者端的安全，也并不能解决链外数据版权问题，管理人员应加强IT系统的安全防护，对于数据的使用也需遵循相关法律法规。

6.公链性能及费用

统计数据显示2017年全国医疗卫生机构总诊疗人次达81.8亿人次，粗略估计每人次产生10条医疗记录。若全部采用本方案管理，每条医疗记录需要2次链上交易，TPS需要达到5k，以BSV举例每区块需要占用1G左右区块空间。考虑到可以通过合并交易以提高字节利用率（单输入多输出交易），极限情况每条医疗记录仅需要消耗100字节，每区块需要占用150M空间。由于本方案的采用会是一个逐步推进的过程，伴随网络带宽及交易处理效率的提升，我们认为公链性能是可以满足需求的。

向公有链写入数据需要一定的费用，同样以BSV举例，按照BSV单价500元，以及推荐的1聪每字节计算（1BSV=1E8聪），每增加一条病例数据成本约0.2分钱，远低于打印纸质报告的费用（A5纸约2分钱）。相对于其价值，我们认为费用是很低的。

将来公链性能不及预期或费用超出预期，分叉甚至退化为联盟链也是可接受的。

7.总结

我们提出了一种去中心化的医疗数据管理方案。首先介绍了医院信息化的发展趋势，以及MedRec为此所做的努力，然而它所提供的公信力还有所欠缺。为解决这一问题，我们提出了基于公有链的解决方案，利用其去中心化特性实现了患者隐私的保护以及患者对自身医疗数据的掌控，使得医疗数据的流通变得简单。由于该方案主要借助了公有链本身的功能，实现较为简洁，从而使健壮性以及可扩展性得到保证。

作者：王动666
链接：https://www.jianshu.com/p/a6ff9c818766
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。​​​​