电子健康记录的健康链区块链:发展研究

简介

长期以来，人们一直认为电子健康档案应跨时间和空间保存，并可在法律规定的任何时间和地点查阅[1］．在数字化的第一阶段，我们将患者的病史存储在医疗保健提供者的管辖范围内，而不管电子医疗记录是否在本地服务器上[2]或在云端[3.］．这种电子病历管理系统与传统的纸质病历系统没有本质区别，因为信息技术只是将病历管理从纸质文件夹转移到了硬盘上。emr不会超出执业范围[4)，他们通过传真或签署文件去其他公司，这很耗时。

在第二阶段，授权医生和工作人员在多个医疗保健组织中创建、管理和咨询电子病历，允许不同电子病历系统之间的互操作性[5］．也就是说，电子病历拥有在医疗保健提供者之间共享医疗信息的能力，并在多个医疗保健组织之间跟踪患者的信息[6］．在美国，电子病历交换涉及一个公共平台，即全国健康信息网络，该网络是一套标准、服务和政策，可在互联网上安全交换健康信息[7］．

然而，技术和法律障碍阻碍了这些系统的采用。首先，当电子病历存储在分布式或以机构为中心的模型下时，这些系统在数据可用性、数据完整性和检索率方面表现不佳[8］．其次，人们总是担心隐私和数据泄露问题。9]当电子健康记录超出他们的控制范围时，即使医疗保健提供者和政府机构声称这些系统符合《健康保险携带与责任法案》(HIPAA) [10］．毕竟，自2005年以来，有11,581,616,452条记录被打破，这是通过政府机构或可核实的媒体来源报道的[11］．第三，患者报告的数据并不总是记录在患者的电子病历中，因为医生与患者的沟通并不总是可能的，这影响了护理质量[12］．因此，精准医疗需要一种患者报告机制[13］．

本文针对上述问题提出了HealthChain。它是一个区块链[14-16]，即由记录组成的不断增长的块列表，并使用加密散列进行链接[17］．区块链有几个优点。首先，区块链是一个分布式点对点数据库，其中数据可用性、数据完整性和响应时间得到了保证[18，19］．区块链可促进电子健康的物联网安全[20.］．其次，区块链在治理模型下运行，该模型强制执行所有参与者同意的业务逻辑。因此，我们可以利用智能合约或链码来调节访问控制策略[21-23并实现HIPAA合规。第三，区块链由其利益相关者集体管理，其中一些利益相关者有权在区块中记录不可追溯更改的数据[24］．在我们的设计中，甚至患者也可以报告个人健康记录(PHRs) [5在账簿上。在我们看来，将区块链技术应用于电子病历系统，标志着数字化第三阶段的到来。

具体而言，由于以下特征，拟议的健康链与其他EHR区块链不同。首先，HealthChain是一个联盟区块链[25］．多个组织，即医院、保险供应商和政府机构，共同组成了该联盟。业务逻辑由联盟一开始商定的治理模型决定，而不是其他医疗区块链的无信任模型[26-28］．其次，HealthChain在以下方面表现良好:数据可用性、数据完整性和检索成功率，即即使少数服务器崩溃，HealthChain也始终在线。真正的电子病历被存储，因为它们是由有效的利益相关者签署的。由于负载平衡，我们可以在任何时候成功地访问分类帐。第三，HealthChain使用权威证明(PoA)作为其共识协议。指定的、经过身份验证的、可信任的订购者负责生成有效的区块，也就是说，只要这些区块由这些订购者之一签署，它们就会被所有参与者接受。PoA不同于其他共识协议，例如工作量证明[21，29，30.]和实用拜占庭容错(PBFT) [31-33］．第四，不同的用户在HealthChain中拥有不同的chaincode应用程序编程接口(api)，这是由治理模型指定的。因此，我们可以定义用户与账本交互的方式，并实现访问控制策略。第五，HealthChain在实验环境中表现良好。本文使用以下四个指标来评估性能:读延迟、读吞吐量、事务延迟和事务吞吐量[34］．

在本文中，我们构建了一个EHR联盟区块链，命名为HealthChain，它比传统的EHR系统和最近提出的其他医疗区块链具有优势。此外，我们通过特定于区块链的指标来评估健康链的性能。

方法

HealthChain图表

该联盟由以下三种组织组成:医院、保险公司和政府机构。我们的实验HealthChain包括每种类型的两个，如图所示图1．对等体A和B分别是两家医院的服务器，它们分别为医生(如Alice和Betty)、实验室技术员和护士三种用户的客户端应用程序提供服务。对等点C和D是由两个各自的保险提供商提供的服务器，它们为审计人员的客户提供服务。对等点E和F是分别属于两个政府机构的服务器，它们为以下五种用户的客户端应用程序提供服务:监管机构、患者、家庭成员、研究人员和急救人员。此外，政府机构为三类组织提供一个定购机构和三个证书颁发机构(ca)。请注意，这些服务器可以位于云中、组织的数据中心中，也可以位于一台机器上。

‎ 查看此图

虽然HealthChain网络中没有集中式节点，但组织在治理模型下聚集在一起，该模型规范所有参与者(如对等点和用户)的行为。治理模型反映了真实场景中医疗保健的业务逻辑。它规定了用户与账本交互的方式，并实现了电子病历的隐私性和保密性。HealthChain通过会员服务提供商(MSP)、链码和共识协议的组合实现治理模型。下面将解释这些组件，并介绍构成网络的所有节点的角色。

ca是受信任的权威机构，为参与者生成证书和密钥材料。MSP是由这些ca实现的，因为生成的证书可以提供关于组织的有效身份的信息。此外，HealthChain中的所有参与者都可以相互验证，MSP有助于实现细粒度访问和跟踪参与者的行为。

对等点组成了我们网络的物理结构。分布式账本和链码在它们之间共享，如图所示图1．他们都在支持和承诺HealthChain中的同行。作为认可的同行，他们由联盟指定在模拟中执行链代码。chaincode实现api，这些api被分为不同的组，授予不同的用户[32]，也就是说，链码指定了谁对账本的哪个部分有什么访问权限，并实现了法律要求的细粒度访问[1］．在图1，我们列出了供医生、患者、监管机构和研究人员使用的api。

作为提交对等体，他们验证区块并将其提交到他们的账本副本。最重要的是，它们检查执行EHR请求的人的身份，以及将EHR事务打包到块中的人的身份。这就是为什么健康链采用的共识协议被称为PoA。

订购者受到所有组织的信任，他们负责以先到先得的方式将电子病历订购到一个区块。块写入者(即，排序者)的签名包含在块中。在提交之前，对等体必须确保签名来自一个经过身份验证和授权的定序者，也就是说，一个块的有效性取决于定序者的身份。

身份和匿名化

ca分发X.509证书以识别服务器和客户端。X.509证书用于事务的生命周期。例如，EHR请求中包含客户端的证书。同时，EHR响应包括背书服务器的证书。在实施HealthChain的访问控制时，chaincode从交易请求中提取证书，获取客户端的身份，并查询访问是否被授权。

考虑到隐私保护，当研究人员通过api访问分类帐时，患者和医疗保健提供者的身份需要匿名化。在匿名化过程中，我们使用身份的哈希而不是身份本身。因此，身份保密，但患者和医疗保健提供者之间的关系得以保留。具体来说，Hyperledger Fabric采用SHA256作为默认的hash算法。计算患者ID与时间戳的哈希值。引入时间戳的目的是防止在查询之间获得相同的散列。

用户的访问权限

HealthChain是一个分布式的、只能追加的账本，由许多具有不同访问权限的用户共享。为了实现隐私和可用性之间的微妙平衡，实现了对分类账的细粒度访问。图2说明了HealthChain中用户的访问权限:写权限、读权限、授权权限和匿名EHRs的读权限。

‎ 查看此图

患者管理和控制对PHRs的访问，概念上包括患者报告的信息和EHRs。前者包括各种内容，如人口统计学，过敏，以及从仪器收集的监测数据[5］．后者指由医生和工作人员更新的医疗记录。患者可授权其家庭成员或医疗服务提供者书写和阅读其健康信息[35]，降低数据复制的风险，并跟踪其健康状况的可能趋势和变化。

医生、护士、急救人员和实验室技术人员管理和控制对自己更新的电子病历的访问。此外，他们可以在未经患者授权的情况下，使用或披露受保护的健康信息用于治疗、付款或医疗保健操作[36］．因此，它们具有向其他覆盖实体授予写或读权限的授权权限，从而在医疗保健组织之间共享ehr。

监管机构和保险公司只有对账本的读取权限。监管机构，如卫生与公众服务部，确保健康链的业务逻辑得到很好的尊重，所有参与者都行为得当。当有争议时，他们可以根据账本做出决定，账本是防篡改和不可伪造的[37］．保险公司根据HealthChain上的记录处理医疗索赔并评估其有效性。

研究人员从事疾病监测等公共卫生活动。由于数据聚合过程的透明度，HealthChain可以为此目的提供可靠的数据[32］．但是，账本上的数据在用于隐私保护之前应该匿名化。

授权的实施

授权由树形数据结构表示，如图3．所有访问权限都由患者(即树的根)授权。父节点授予子节点读、写和授权等权限。例如，患者将所有三个权限授予Alice医生，Alice医生将所有三个权限授予Betty医生，依此类推。此外，其他三个角色(即监管者、审计员和研究人员)只能读访问分类帐。树形数据结构是授权的逻辑设计，而分类账上的记录或事务是授权的物理实现。

‎ 查看此图

中给出了寻址认证和授权的算法图4，由chaincode实现。关键部分是三个决策符号，代表事务成功的先决条件。首先，只有联盟成员才能访问账本;其他人根本没有权利。其次，不同类型的用户对链码api有不同的访问权限，即使是在同一个联盟中。第三，如果一个用户没有得到另一个用户的授权，就不能访问另一个用户的数据。例如，如果一个名为Carl的人想要提交关于一个名为Steve的病人的遭遇记录，他需要满足以下三个条件:他来自联盟内的一家医院，他是一名医生，他拥有Steve的授权。

‎ 查看此图

电子病历的类型和生命周期

不同的用户提交的电子病历有不同的种类。为了简洁起见，图5只列出其中的四个，说明了人口统计、遭遇记录、测试结果和授权记录的数据结构。例如，就诊记录包括:患者ID、患者姓名、医生ID、主诉、体检、评估、计划。

‎ 查看此图

每个EHR都对应一个交易，需要执行并最终包含在分类账中。所有电子病历都有相同的生命周期[16]，详见图6，解释如下:

1. 当Alice医生需要在账本上记录遭遇记录时，她的客户端应用程序会向认可的同行发送一个EHR请求。请求被格式化为通过chaincode api的远程过程调用[38］．
2. 背书的对等体检查传入请求的有效性(格式、签名和访问权限)。然后，请求由chaincode处理，它输出一个EHR响应，包括返回值、读集和写集。
3. Alice的客户端检查传入响应的签名，将响应和签名组装到EHR事务中，并将事务发送给定序者。
4. 排序器只是接收来自所有客户机(包括Alice的客户机)的事务，按时间顺序排序，并创建一个事务块。然后，排序器将块交付给网络中的所有对等点。
5. 每个对等体检查传入块的有效性，包括签名和版本号。之后，区块被提交到分类帐中，Alice提交的EHR也是如此。

‎ 查看此图

分类账的结构

账本是电子病历跨越时空的数据库。如图7，它的结构是相互链接的块，每个块包含按时间顺序排列的EHR事务。

一个块由以下三个部分组成:报头、EHR事务和元数据。报头包括区块号、之前的区块哈希和当前的区块哈希。EHR事务由医生和患者等用户提交。元数据包括时间戳以及定序者的证书和签名。此外，一个EHR交易由以下六个字段组成:交易ID、链码名称、EHR请求、EHR响应、用户和对端签名。

区块n+1的前一个区块哈希值等于区块n的当前区块哈希值，这样区块是相互链接的;因此得名区块链。HealthChain和其他区块链之间最大的区别是区块不需要包含nonce字段来实现给定的加密哈希值模式。区块的有效性只依赖于PoA，而不是工作量证明。因此，HealthChain可以实现低事务延迟。

‎ 查看此图

结果

实验环境

HealthChain的原型是用Hyperledger Fabric v1.4.1实现的，Hyperledger Fabric是一个企业级许可分布式账本平台[16］．它部署在Intel Xeon E5-26xx v4 2.4 GHz CPU和2gb RAM的机器上，运行Ubuntu 16.04.1 LTS。所有的服务器都是用Docker 18.06.01 -ce构建的，也就是说，所有的对等点和排序器都被虚拟化到共享硬件和操作系统内核的容器中[39］．HealthChain网络由Docker Compose创建，这是一个用于定义和运行多容器Docker应用程序的工具[40］．

此外，批处理超时和批处理大小这两个参数对HealthChain的性能影响较大。前者表示创建一个块之前等待的最大时间，后者是一个块中EHR事务的最大数量。不管先满足哪一个，都会生成块。本文在参数变化的情况下对HealthChain的性能进行了测试。我们将每个事务运行三次，文中给出了延迟和吞吐量的平均值。

健康链的工作实例

在本节中，我们将展示一个示例来说明HealthChain如何工作。注意，所有的任务都是通过chaincode api完成的图1．医疗资料摘自以前的一份报告[41］．

首先，史蒂夫·苹果耐心的客户准备个人信息。因此，以下人口统计记录被提交到分类帐。

其次，当Steve决定去看一位名叫Carl Savem的医生时，他提交了一份授权记录，以授予医疗保健许可。因此，医生能够在分类帐上执行读、写，甚至授权操作。

第三，Carl在了解Steve对健康状况的感受并做了体检后，进入诊断和治疗说明。

第四，为了检查血脂谱是否有变化，卡尔还写了一份授权记录，要求一位名叫约翰·多伊的技术人员提供测试。

最后，无名氏在账本上写了以下报告。

此外，当研究人员阅读上述遭遇笔记时，HealthChain中的匿名化方案生效，产生如下记录。前三个项是原始记录和时间戳中相应项的哈希值。

安全测试

我们从三个方面测试了HealthChain的安全性。首先，患者试图访问不可用服务器peer E上的账本。下面的命令查询ID为P01的患者的遭遇记录，但由于peer E的域名为peer0.org3.health.com不可用，查询失败。将peer0.org3.health.com替换为peer0.org1.health.com，即对等体A的域名后，由于对端A仍然可用，命令执行成功。

其次，无效用户试图访问分类帐。但是，由于身份无法验证，该操作立即被系统拒绝。删除Steve Apple的数字证书后，上述命令执行失败，返回如下信息。

第三，医生试图篡改电子病历。然而，EHR的历史记录记录在分类帐上。我们可以查询P01的遭遇记录历史。不难看出，“体检”已经从“无急性窘迫”变成了“急性窘迫”。

综上所述，HealthChain在数据可用性、访问控制和数据完整性方面表现良好。

测试场景:一次读取

读取操作是指检索或查询EHRs，账本没有变化。用户可自行或他人提交的电子病历。我们可以在这里给出一些用例。医生询问病人的人口统计数据或以前医生的诊断。患者阅读医生的医疗记录或实验室技术员的化验结果[24］．保险公司检查电子病历以确认其必要性。读时延是指从提交EHR读请求到返回EHR响应之间的时间，对应于步骤1和步骤2图6．

表1显示不同参数条件下单个读操作的示例数据。可以看出，无论参数如何，HealthChain的读延迟都在0.1 s左右。例如，第一行显示的是Alice医生从对等体a检索EHR时的读操作过程。她在0 s时发送了一个EHR请求，对等体a在0.136 s时完成检索，在0.142 s时返回了一个EHR响应。因此，当批处理超时为20 s，批处理大小为1000时，读时延为0.142 s。这两个参数是不相关的，因为在读取过程中没有生成块。

测试场景:并发读取

通常，许多用户同时从分类帐中读取数据，并且读取操作在重叠的时间段内执行。例如，医生、患者和保险提供商可以根据需要同时从分类帐中读取电子病历。读吞吐量是指在特定时间段内完成的读操作数量，表示为RPS (reads per second)。

表2显示不同参数条件下1000并发读的示例数据。可以观察到，在不同参数的情况下，HealthChain的每台服务器的读吞吐量都在10 RPS左右。例如，第一行显示的是用户同时从对端A检索EHRs的1000个并发读操作的过程。第一个EHR请求发生在0秒，对端A在97.513秒完成第1000次读取，在97.521秒完成第1000次响应。因此，当批处理超时为20 s，批处理大小为1000时，读吞吐量达到10.259 RPS。这两个参数是不相关的，因为没有区块写在分类账上。此外，由于一个对等体上的读操作与另一个对等体上的读操作是相互独立的，所以整个网络的读吞吐量是所有对等体的吞吐量的总和。

测试场景:一次写入

写操作指的是将ehr提交到账本，其中涉及到更改。用户可以创建并提交有关患者的电子病历。我们可以在这里列出一些用例。医生在与病人会面后制作会面记录，或在住院期间制作病程记录。患者更新人口统计资料或报告其临床状况[22］．实验室技术人员报告测试结果。事务延迟是指从提交EHR写请求到EHR事务在网络中广泛可用之间的时间，对应于所有五个步骤图6．

表3显示具有不同参数条件的单个写操作的示例数据。可以看出，事务延迟取决于这两个参数。例如，第一行显示Alice医生向分类帐提交EHR时写入操作的过程。她在0秒发送了一个EHR请求，peer A在0.118秒认可了EHR, orderer在20.166秒生成了一个包含EHR事务的块。随后，6个对等体分别在20.370 s、20.352 s、20.379 s、20.379 s、20.363 s和20.379 s将区块提交到账本。因此，所有对等体上的EHR事务在最晚的时间(20.379 s)是可用的。因此，当批处理超时为20 s，批处理大小为1000时，事务延迟为20.379 s。

中解释事务延迟表3．在第一种和第三种情况下，定序者在创建块之前必须分别等待20秒和2秒，因为只有一个传入的EHR事务需要打包到块中，并且批处理超时首先发生。在第二种情况下，批大小为1，并且恰好有一个EHR事务，因此批大小首先得到满足，并且定序者在创建块之前不必等待20秒。

测试场景:并发写入

通常，许多用户同时写入分类帐，并且写入操作在重叠的时间段内执行。例如，医生、患者和实验室技术人员可以根据需要同时将电子病历写入分类帐。事务吞吐量是指网络在特定时间段内提交的EHR事务数，表示为每秒事务数(TPS)。

表4显示不同参数条件下1000个并发写的示例数据。可以看出，事务吞吐量是由这两个参数决定的。例如，第一行显示了当用户试图同时向分类帐提交ehr时1000个并发写操作的过程。第一个EHR请求发生在0秒，对等体A在132.224秒完成第1000个背书，订购者在139.930秒生成最后一个区块。随后，网络中的6个对等体分别在141.498 s、141.936 s、141.933 s、141.400 s、141.042 s和141.976 s提交最后一个块。因此，所有对等体上的1000个EHR事务在最晚的时间(141.976秒)是可用的。因此，事务吞吐量达到7.043 TPS，批处理超时为20秒，批处理大小为1000。

我们可以把交易吞吐量计算在内表4．在第一种情况下，区块每20秒创建一次。因为处理1000个事务需要20秒以上的时间，所以批处理超时首先发生。在第二种情况下，由于批处理大小为1，因此每个EHR事务都会创建块。在第三种情况下，区块每10个EHR事务创建一次。因为处理10个事务的时间不到2秒，所以批处理大小首先发生。可以观察到，交易吞吐量与生成的区块数量成反比。生成更多的块增加了由八卦协议引起的网络拥塞的可能性[16］．

讨论

健康连锁的特点

根据以上内容，将HealthChain的特点总结如下。首先，HealthChain是被允许的。与公共无许可网络不同，所有用户(如医生和患者)都由MSP认证，因此彼此可以识别，而不是匿名和完全不受信任。未经授权或未知的用户不允许访问分类帐。其次，健康链是不可变的，也就是说，一旦电子病历被添加到链中，它们就不能被更改。此仅追加属性依赖于区块通过哈希引用相互链接的事实。因此，HealthChain是患者治疗史的权威来源。第三，HealthChain是透明的。卫生保健利益相关者聚集在一起构成区块链网络，没有人控制整个系统。用户发起的每个操作都会根据治理模型进行检查，该模型规范并监视所有参与者的行为。 Furthermore, EHRs like encounter notes and lab results are shared among covered users, who know what is going on during the course of treatment. Fourth, HealthChain is HIPAA compliant with the privacy rule and security rule. Privacy policies are implemented through chaincode. The use of patient information is denied without authorization. Patients have final control over the EHRs, and they can grant write and read permissions to other covered entities. Besides, HealthChain exploits the Transport Layer Security (TLS) protocol to provide communication security over the network [16］．第五，健康链是可扩展的。并不是所有的对等点都参与到事务执行中，也不是所有的排序者都参与到块生成中。因此，允许并行事务执行和块生成，并且HealthChain可以轻松支持更多的节点，尽管在我们的实验环境中只有六个对等点和一个orderer。第六，HealthChain业绩良好。即使在我们的实验环境中，读延迟大约为0.1 s，每个对等体的读吞吐量大约为10 RPS。HealthChain在批处理大小为1的情况下实现了约0.4 s的事务延迟，支持约7 TPS的事务吞吐量，批处理超时为20 s，批处理大小为1000。相比之下，比特币和以太坊分别需要600秒和10秒在账本上写一笔交易[42］．

参数设置

HealthChain的性能受到许多变量的影响，如网络大小和硬件限制。在这里，我们讨论了我们在实验中配置的两个参数，即批处理超时和批处理大小。

为了获得良好的性能，我们应该考虑允许的最大事务延迟来调整批处理超时，并根据指示在特定时期内提交给订购方的EHR事务数量的速率来设置批处理大小。这两个参数应分别与允许的延迟和速率成比例。从实验中可以看出，当只有一个EHR事务且批处理大小为1时，HealthChain获得的事务延迟最小。当有1000个事务且批处理大小为1000时，它可以实现最高的事务吞吐量。

限制

HealthChain的原型有两个缺点。首先，唯一的排序器会导致单点故障。如果orderer失败，则无法将EHR事务排序到一个块中，导致整个系统故障。为了解决这个问题，我们可以部署一个由一组排序服务节点和一个Kafka集群及其ZooKeeper集成[16］．这不仅有助于构建一个容错崩溃系统，还可以通过负载平衡提高性能。

其次，读延迟随着账本的增长而增加。考虑到只追加写操作，分类帐被实现为磁盘上的文件。同时，读操作在HealthChain中也很常见。然而，电子病历可能随着时间的推移分散在文件中，导致搜索困难。为了解决这个问题，我们可以在分类帐上创建一个患者索引，使读取操作更快。

结论

在这项研究中，我们构建并评估了HealthChain，这是一个在治理模型下运行的EHR联盟区块链。它保证了数据的可用性和数据完整性。它提供链码api来适应不同客户端的需求，并实现细粒度的访问控制。此外，还介绍了一种电子病历的匿名化方法。HealthChain采用PoA作为共识算法。实验中观察了HealthChain的功能。我们通过延迟和吞吐量来描述系统的性能。