我们的目标是开发一个概念验证系统，用于患者和提供者交换葡萄糖数据( 图2)根据以下规范:(1)患者控制，(2)全数字化，(3)互操作，(4)分布式记录和存储数据。 病人自控意味着患者除了提供交换同意外，还可以向选定的各方授予数据访问权。 数字指定以数字格式交换数据(从BG远程传感器采集到上传到医生的EHR)，最大限度地减少任何潜在的手动数据输入错误。 系统互操作性指定如果患者同意，BG远程传感器生成的数据可以由来自不同医疗保健方的另一个信息系统读取(利用快速医疗保健互操作性资源[FHIR]标准)。 分布式日志记录和数据存储这意味着BG传感器产生的所有数据都以防篡改的方式存储在多个分布式节点上，而不是单一的集中式数据仓库。

我们的系统由四个主要模块组成:(1)数据转换模块，将来自设备传感器的原始BG数据转换为FHIR标准记录;(2)数据处理模块，将生成的FHIR记录转换为可逆转和可链接风险最小的格式;(3)数据存储和日志记录模块，将转换后的FHIR记录上传到DLT;(4)密钥交换模块，允许为FHIR记录交换建立患者-提供者通信通道。

将DLT的数据实际集成到医生的电子病历中超出了本工作的范围，因为它依赖于电子病历系统和集成引擎。然而，在提议的设计中使用FHIR标准应该使这一过程相对简单。此外，我们假设在这个用例中，医生将以季度为周期从系统中提取数据，而不是连续的实时数据。这一抽样选择基于当前患者-提供者的工作流程和跨越多个卫生保健系统的指南(例如，在德国，糖尿病患者每季度与医生进行一次拜访，以审查和更新疾病管理计划)。

当患者脱机或出现网络连接问题时，数据缓存的问题也超出了这项工作的范围。通常，有两个点可以缓存数据:(1)在BG传感器和/或(2)在用于从传感器读取数据的移动设备上。然而，数据缓存实现的确切架构高度依赖于传感器和设备制造商。通常，这些制造商利用不同的库提供访问不同的安全存储解决方案(例如，三星Galaxy设备将是ARM的TrustZone)。

考虑到目前关于什么技术适合PHI匿名化的争论，并且由于目前没有患者-提供者数据交换的标准设计，我们为我们的概念证明系统提出了两种不同的变体。这两种变体都旨在遵守GDPR，并试图以各自的方式将逆转和链接的风险降至最低，各有利弊。这两种变体由相同的四个模块组成，但在某种意义上不同的是，一个完全基于名为IOTA的公共分布式账本，我们称之为“公共IOTA”，另一个则将IOTA公共分布式账本与另一个名为星际文件系统(IPFS)的私有分布式文件系统结合起来，我们称之为“公共IOTA +私有IPFS”。这两种变化的总结可以在 图3，并在其后提供每个模块的更详细描述。

该模块与两种设计都相同，可将连续BG系统的原始数据转换为FHIR标准。HL7创建FHIR的目的是促进不同医疗保健系统之间的医疗保健相关数据的互操作交换，使医疗保健信息更容易在各种各样的设备上向提供者和个人提供，并允许第三方开发人员提供可以轻松集成到现有系统中的医疗应用程序[ 16- 18］．

基于firir的记录是由一组称为“资源”的模块化组件构建的，这些组件具有标准的、一致的数据元素，在共享实体之间具有一致的含义。所有资源都共享一组公共特性，包括(1)资源标识和元数据，(2)人类可读的XHTML摘要，(3)标识资源的URL，以及(4)一组定义的数据元素(每种类型的资源都有不同的数据元素集)。

为了便于使用和标准化目的，我们使用了符合gatt标准的蓝牙连续葡萄糖监测系统(Dexcom G4 PLATINUM) [ 19］．该设备每10分钟产生一次BG测量。通过为每个生成的血糖数据测量(mmol/L)填写FHIR观察蓝图，将这个连续血糖监测系统的数据转换为FHIR记录。该模块的输出是每个BG测量的一个FHIR JavaScript对象标记(JSON)文件。

密钥交换模块允许建立患者-提供者通信通道，以交换FHIR记录。在这个密钥交换过程中，双方交换加密密钥，允许他们专门交换加密消息。本模块的设计依赖于数据记录和存储层;因此，在这个作品中也使用了两种变体。

对于公共IOTA设计，在匿名化步骤之后，包含一个BG FHIR记录的JSON文件的大小从2509字节减少到857字节。在公共IOTA +私有IPFS设计的聚合步骤中 ，我们结合了BG FHIR记录，相当于四分之一的患者监测。这导致JSON文件的大小约为34mb。在聚合之后，并在应用JavaScript Obfuscator之后，文件的大小增加到64mb。最后，在应用AES256-GCM加密后，生成的文件的大小为93 MB。重要的是要注意，加密时间取决于加密算法和使用的处理硬件。在这项研究中，使用AES256-GCM算法和三星Galaxy S8设备(2.3Ghz四核Exynos M2 Mongoose)，加密一个93 MB的文件只花了不到0.1秒，从总体事务时间来看，这是可以忽略不计的。

通过公共IOTA和私有IPFS设计中描述的远程设置 ，我们能够在平均10.9 (SD 3.1)秒内远程交换密钥并建立安全连接(发送请求:平均5.2,SD 1.8秒;接受请求:平均5.8秒，标准差1.3秒)通过IOTA Tangle ( 表1)．

基于DLT的系统在帮助改善卫生信息交换方面具有巨大潜力。然而，它们的设计需要符合最新的法规(如GDPR)，以将不适当的处理和/或存储的风险降至最低。在这项研究中，我们通过设计和开发一个考虑到重要监管因素的概念验证系统，评估了一种特定的DLT (IOTA)在BG数据交换方面的潜力。从用户的角度来看，这些系统还应满足令人满意的性能和可用性;因此，我们使用各种方法来测试我们设计的性能。

鉴于目前关于数据匿名化的开放问题，目前还不存在一个最佳的系统。因此，我们设计了两种变体。每种方法都有各自的优缺点，包括(1)数据反转风险，(2)数据链接风险，(3)处理时间，(4)文件大小兼容性，以及(5)整体系统复杂性。这一评估总结在 表2．

反转风险表示能够从匿名或修改过的数据重构原始数据的风险。在公开的IOTA设计中，考虑到上传到Tangle的FHIR记录删除了任何个人数据，这种风险是不适用的。对于公共IOTA加上私有IPFS设计，上传到Tangle中的散列是多个处理层(聚合、混淆和加密)的结果。在计算上，将这个散列逆向工程到原始文件是一项庞大的任务，因为它需要试验大量可能的输入组合，其大小从几个字节到数百tb不等。即使在未来，随着计算的自然进步，也很难想象有可能从一个46个字母的散列(即93 MB的模糊和加密数据)中提取数据。

可链接性风险表示，通过检查使用模式或上下文，或通过与其他信息的比较，可能将匿名数据链接到个人的风险。在公开的IOTA设计中，通过跟踪数据上传到Tangle的频率，再读取实际BG水平，就有可能将这些信息与特定的个人联系起来。一种可能的解决方案是对原始BG级别进行加密。但是，在GDPR的影响下，任何加密算法在未来都是容易被逆转的[ 9];因此，加密的原始数据有可能被解密，真实的葡萄糖水平就会显示出来。鉴于文献中报告的匿名健康记录重新识别的案例[ 13]，应该注意不要假定匿名的PHI可以毫无风险地上传到公共DLT。在患者和提供者之间的第一次预约期间交换多个密钥可能是减少每个MAM流的PHI量的另一种解决方案，从而减少本设计中的链接风险。这一解决方案在本工作中尚未探索过。

对于公共IOTA加上私有IPFS设计，每个结果哈希都是唯一的，因此没有明显的方法来交叉分析数据，从而确定这些数据属于谁。

得到的消息事务时间与之前的研究一致[ 22］．IOTA DLT上消息的总体较低事务时间(平均在6.1到38.1秒之间)表明这两种设计都可以用于连续数据流。这里需要注意的是，根据定义，一个MAM消息实际上包含三个事务，理论上可以并行执行。通过实现此代码优化(除中所示的平均时间) 表1到3时，每个消息创建和附件的实际平均时间将分别为1175 ms和848 ms。这将导致通过MAM发送的每个IOTA消息总共大约2秒。

硬件加速[ 27的PoW，可以达到300毫秒的PoW时间。外部API的总体响应时间为848 ms，这意味着API的瓶颈约为548 ms。为了实现更快的事务时间，用户可以设置自己的硬件加速IOTA节点，而不是使用集中的API服务。增加运行自己PoW的用户数量也会增加网络的整体健康状况，因为它增加了去中心化的特性。

具体到公共IOTA +私有IPFS设计，由于哈希本身几乎是即时的，主要的限制因素是网络的上传速度。对于本设计，作为一般建议，我们建议仅在连接到快速WLAN网络时将大文件上传到IPFS网关。

最后，还需要注意的是，考虑到季度咨询的用例，对于供应商读取BG数据，公共IOTA设计将受益于将季度数据“预取”到供应商的EHR中。对于公共IOTA +私有IPFS设计，考虑到相对较低的读取时间(可根据要求获得)，我们认为不需要预取。

在公共IOTA设计中，通过MAM创建和发送消息所需的时间完全取决于文件的大小。因此，使用这种设计可能不适合交换较大的文件。在公共IOTA +私有IPFS设计中，因为散列通常比初始数据小得多，而且可以用来识别数据本身，所以我们可以得出这样的结论:这种设计非常适合大文件的交换。

在总体设计复杂度方面，公共IOTA设计与公共IOTA +私有IPFS设计相比明显简化。特别是两个特性，使第二种设计更加复杂:(1)数据处理模块中涉及的多个步骤需要额外的处理，这可能导致更大的文件大小(例如，使用量子安全NTRU加密导致文件大小为821 MB)(2)私有IPFS集群的设置需要额外的实现工作。

本文选择的用例集中在患者和医生之间远程交换BG测量值，医生在会诊期间定期“读取”数据，以审查和更新糖尿病管理计划。然而，我们也相信，这两种设计都可以用于单个BG测量的连续流(即实时数据交换和监测)，以及其他类型的远程健康数据交换(如Cohen等人提出的用例[ 30.])。

这一领域的相关工作分为两类:(1)使用区块链改善医疗保健数据访问和互操作性，(2)评估如何在考虑数据隐私条例的情况下使用区块链。

描述使用区块链解决互操作性障碍的首批作品之一是由MedRec团队撰写的[ 31］．在这项工作中，提出了一个基于工作证明激励的许可区块链网络，以促进EHR数据共享和认证。在这项工作之后，Zhang等人[ 32更进一步，描述了如何安全、可扩展地共享EHR数据，以改善协同临床决策支持。具体而言，提出了一种基于firir的智能合约系统用于交换健康数据，其中区块链存储加密的元数据，而链下解决方案用于临床数据。

这项工作确实提出了一个基于fhirr的提供者-提供者解决方案，尽管我们的工作为患者-提供者数据交换提出了一个补充的基于fhirr的解决方案。关于基于firir的互操作性的主题，Peterson等人[ 33描述了一个使用新型共识机制的区块链解决方案:基于firir的“互操作性证明”。这种方法的独特之处在于，它将安全性和互操作性作为其核心设计的中心原则。

与之前的研究相比，需要注意的是另外两篇文章将区块链定位为患者-提供者数据交换工具，而不是提供者-提供者数据交换工具。市川等人[ 34]开发了一个移动健康系统，使用手机应用程序，使患者和提供者能够交换信息，但其特定目标是失眠认知行为治疗。巴尔萨里等人[ 35]提出了一个用例，利用印度移动电话的高普及率和独特的ID系统的可用性，促进5亿多印度公民与其提供者之间的健康数据交换。

Zyskind等人此前曾描述过根据数据隐私法规使用区块链[ 36跨越三个领域:数据所有权、数据透明度和可审核性以及访问控制。本文描述了一种类似于我们第二个提议设计的方法，即链上解决方案与区块链外存储相结合，构建一个关注隐私的个人数据管理平台。相反，Al Omar等人[ 37]，认为数据交换的去中心化方法可能无法确保整体隐私，因此应用了额外的加密功能和数据处理程序来加密患者数据并确保匿名性。

在这项工作中，我们通过提出两种设计来实现使用这种技术交换PHI，从而解决GDPR和DLT之间的一些紧张点。然而，未来的工作需要更详细地解决剩余的冲突点，例如如何在由多个医疗保健利益攸关方组成的公共DLT生态系统中确定数据控制者，或者如何收集和管理个人对处理医疗数据的明确同意。

同样重要的是要注意本研究中提出的设计的一些局限性。首先，使用患者手机的NFC芯片进行密钥交换目前是不现实的，因为这需要每个医生的办公室都有一个连接到设施的EHR的NFC阅读器。替代方法可以是面对面的密钥交换方法或安全的本地无线网络。其次，在我们的测试中，连续血糖监测设备每10分钟产生一个数据点，这意味着一天内大量的电池使用可能会创建所有的FHIR记录。对设备电池的实际影响可能构成一个需要进一步调查的重要限制。

最后，还需要指出的是，这项研究中的实验只在三星Galaxy S8上进行。使用该设备的CPU进行本地资源哈希计算;因此，可以预期，不同的移动设备将需要不同的时间来创建和附加FHIR资源。

基于dld的健康数据交换系统的设计需要仔细考虑各自的用例。在本文中，我们提出并开发了两种可能的设计，旨在符合最近的数据隐私法规，最大限度地减少不当数据处理的风险，并返回令人满意的性能和可用性。一种设计完全基于公共分布式账本IOTA，另一种设计使用IOTA加上私有IPFS集群。我们的研究结果表明，第一种设计实现起来更简单，但需要特别注意，以最小化个人数据链接的风险，而第二种设计允许交换更大的文件，但代价是更高的复杂性。