案例研究
PDF访问控制与医疗保健记录：数据归谁所有？
与 David Evans、Richard McDonald 和 Terry Coatta 的讨论
即使您不是拥有多年医疗保健数据管理经验的专家，也能得出结论，这个领域一团糟。随便去一家医院、诊所或药房看看就能让您确信这一点。由于历史遗留问题和各自为政的碎片化，各系统之间几乎无法沟通，几十年来，医疗保健记录一直让所有试图统一它的努力受挫。
根本原因再明显不过：每个诊所、医院、医务所和药房都运行着自己独立的记录管理系统。平台和技术因组织而异，几乎没有为共享任何信息做出规定。
但是，如果这些记录以更以患者为中心的方式处理，使用允许所有医生、诊所、医院和药房轻松共享数据的系统和网络（患者可以选择与他们共享数据，或者在必要时访问这些机构），情况会怎样？更激进一点，如果数据的所有者被认为是患者，而不是提供者，又会怎样？
正是带着这些想法，一家位于多伦多的名为 HealthChain 的初创公司着手创建一个平台，用于根据患者与其各种提供者之间建立的关系来管理患者的用药档案。
这个愿景成为了 HealthChain 首席技术官 David Evans 所面临的挑战，他借鉴了自己在金融行业投资组合管理和定量研究系统方面 25 年的工作经验。在转向医疗保健领域的几年里，他发现自己越来越对将新兴的数字身份和区块链技术应用于创建更高效的政府服务的可能性感到好奇。现在，他有机会将其中一些想法付诸实践。
为了深入了解 HealthChain 如何应对药物档案管理挑战，Evans 在此与最近退休的 IBM 杰出工程师 Richard McDonald 以及位于温哥华的初创公司 Marine Learning Systems 的首席技术官 Terry Coatta 进行了讨论，Marine Learning Systems 致力于开发学习平台。
理查德·麦克唐纳 作为时不时去医生办公室甚至医院的人，我们都知道记录保存对这些机构的运作有多么重要。从历史上看，这采取了纸质记录的形式，保存在塞得满满的文件柜中。但是，随着医疗行业姗姗来迟地全面进入 21 世纪，电子记录似乎也越来越多地被采用。随着这一进程的不断推进，问题也随之而来，即谁真正拥有这些记录，谁负责保管它们，以及谁需要访问它们。您认为目前这些医疗机构需要解决的托管责任方面有哪些关键问题？
戴维·埃文斯 正如您所说，目前有些医生使用计算机系统，有些则不使用。使用计算机记录的医生通常使用一些本地化的设备，称为 EMR（电子病历）系统（也称为 EHR（电子健康记录）系统，具体取决于国家和使用情况）。就保存在这些系统上的记录的所有权而言，任何将患者详细信息输入 EMR 系统的医生都对其信息的准确性负责。话虽如此，当谈到患者完整医疗记录的所有权时，越来越多的人认为这些信息理应属于患者。
目前的实际情况是，任何患者的记录实际上都分散在许多孤立的数据库中，因为当您从一家诊所转到另一家诊所，或从一家药房转到另一家药房时，每家机构都会为您创建一份新的记录。在确定这些记录的所有权时，我倾向于区分每位从业人员负责在其自己的系统上维护的信息，与在患者一生中收集的关于该特定患者的所有医疗信息的总和。虽然许多人认为这些信息属于患者，但目前的现实是，患者实际上甚至无法访问这些数据，并且几乎无法控制数据的使用方式。
特里·科塔 为了明确这些孤岛，您说的是集中式数据库，还是仅仅是在不同医生办公室维护的许多小型独立数据库？
DE 本质上是两者的混合。有很多独立的医生办公室，如果他们使用计算机系统，那可能仅仅是在台式机或笔记本电脑上运行的数据库。
同样，也有跨多个地点的医疗保健团队。安大略省最大的医疗保健团队之一拥有 37 个不同的诊所地点，所有这些地点都共享一个托管在云端的 EMR 实施方案。但我认为，即使是该实施方案的组织方式也是如此，医生只能看到在其特定诊所地点就诊的患者的信息。
RM 从在其中一家诊所工作的管理员的角度来看，情况如何？
DE 即使在正在运行的 EMR 应用程序中，也有很多老化的技术需要应对。此外，早期我们就曾被警告过，不要走进医生办公室就期望被允许改变工作流程。这些技术自 80 年代以来就未必有太大进步是有原因的。医生们已经习惯了它们。他们下意识地知道需要在某个特定页面上按三次 Tab 键，这要归因于某些过时的设计选择。是的，这可能很愚蠢，但这是他们早已习惯的设计。
TC 这些不同站点之间有集成方案吗？显然，如果世界上到处都是这些数据孤岛，您会认为应该有一些与信息交换相关的标准。还是说基本上就是一片混乱？
DE 最有希望的全球标准是 FHIR，它是快速医疗保健互操作性资源的首字母缩写。这是一个多年来经过多次迭代的标准，它专注于互操作性。
FHIR 并非没有缺陷，但它绝对是目前不同系统之间互操作性的最佳资源。不过，仍然存在大量数据重复的空间，而且它本质上仅用于一次性数据传输。也就是说，目前没有使用 FHIR 网络，所有这些不同的数据库以任何方式保持同步。或者至少我从未见过任何类似的东西。
RM 我是否可以认为患者对如何处理他们的信息几乎没有发言权？
DE 完全正确。如果您查看健康隐私标准，它们都强调患者同意。但实际上，唯一似乎存在的同意类型是默示同意，因为就目前的情况而言，患者无法使用任何实际机制来提供或撤回对其数据使用方式的同意。也就是说，患者几乎完全被排除在外。
另一方面是，信息在提供者之间也没有以患者可能合理期望的任何方式共享。如果您总是去同一家诊所，他们已经认识您，并且可以随时查阅您的记录。但是，如果出于某种原因，您发现需要去其他诊所或最终进了急诊室，那么对于在那里治疗您的任何人来说，您很可能是一张白纸。他们不会知道您有什么过敏症。他们不会知道您有什么既往病史。他们不会知道您正在服用什么药物。因此，这意味着他们将不得不赶紧从您或家人那里搜集他们能找到的所有信息。
TC 这听起来简直是一团糟，那么您现在试图解决这个问题中的哪个部分？
DE 借用区块链世界的一个术语，我们正在努力为医疗界交付一个共享账本。我们的目标是提供一个患者记录的视图，不仅医生和药剂师可以共享，而且患者也可以使用。这在今天实际上是可能的。
我们的主要目标之一是从患者的角度跟踪所有这些信息：他们使用哪些药房？他们去哪些诊所？哪些医生在这些诊所为他们看病？以及患者关怀圈（我们是这样称呼它的）中的每个参与者是如何被授权访问患者记录的？此外，我们能否在患者数据的使用和访问方面为患者提供透明度和一定的控制权？
TC 这听起来是一个令人钦佩的目标，但您真的能实现它吗？这听起来像是您可能在试图移动不可动摇的东西。
DE 实际上，我不会说我们正在努力移动或替换任何东西。事实上，根据规定，我们被禁止替换现有的 EMR 系统。我们绝对不是旨在捕获 EMR 需要保留的所有数据，因为每个托管组织（即每个医疗保健提供者）仍然对维护自己的记录负有法律责任。
但是，随着他们继续更新每个患者的药物档案，并提供一定程度的详细信息，我们希望做的是与所有这些 EMR集成，以便他们可以保持这些患者记录的共享状态为最新，同时还以这样一种方式利用这些信息，即患者关怀圈中的每个人都可以轻松查看它。
我们绝对不是想改变世界，而只是想让医生、药房和患者能够跨患者随着时间推移使用过的所有不同提供者，共享患者处方历史的共同视图。这本身就是一个足够大的挑战，也是一个重要的目标，但它也比试图替换所有 EMR 系统要实际得多。
RM 这个问题的关键之一似乎与跟踪患者身份以及以某种方式跨所有这些不同方识别他们有关，同时还需要管理访问控制，这显而易见。您能否详细阐述一下这一点，特别是围绕数字身份的问题？
DE 该系统当然需要唯一标识符。到目前为止，这意味着我们能够通过发给患者的医保卡号来识别患者。同样，我们通过医生的执业证号和药房的认证号来识别医生和药房。但我们也需要能够接受当今世界上接受的其他一些标识符，因此我们正在努力制定更强大的注册流程。但这实际上归结为采取一切必要措施，以防止系统上为同一患者、医生或药剂师设置多个个人资料。
HealthChain 构建在成熟、熟悉的开源软件（Hyperledger Fabric 和 Hyperledger Composer）的基础之上，在普遍部署方面没有任何明显的障碍。
然而，对使用 HealthChain 形成的患者和提供者网络的访问仅限于经过身份验证的参与者，这些参与者反过来也仅被授予对其允许执行特定功能的信息资产的访问权限。
这意味着，最终，访问控制列表可能被证明是解决长期存在的医疗保健数据管理僵局的关键，因为它们不仅是将对象访问权限绑定到每种参与者类型的方式，也是定义允许对任何给定对象执行的操作的方式。
RM 既然您已经告诉我们您希望通过您的应用程序实现什么目标，那么请告诉我们您实际做了什么。
DE 嗯，首先，我们正在使用 Hyperledger Fabric 和 Hyperledger Composer，这两者都来自 Linux 基金会支持的与区块链相关的项目。Fabric 基本上围绕区块链组件提供了一系列工具，这有效地为我们提供了所有传入的幂等事务请求的不可磨灭的记录。我们将这些事务视为“智能合约”，但在任何情况下，它们都是更新状态的事务。也就是说，Hyperledger Fabric 为我们提供了一种维护全局状态数据库的方法。
底层数据库技术是 CouchDB，它为我们提供了一个对象存储，用于处理 JSON（JavaScript 对象表示法）对象，并使用 MapReduce 来应用索引并对所有这些 JSON 对象结构执行快速查询。对我们来说，Fabric 附带的另一项重要技术是 Kafka，它提供了高性能的消息流。这为对等方之间的事件通知以及向其他进程传递通知提供了支持。
与此同时，Hyperledger Composer 是一个构建在 Fabric 之上的框架，旨在帮助您定义 Hyperledger 世界所认为的业务网络，其中标识了网络中的所有参与者，以及网络预期管理的所有各种资产，以及管理所有不同参与者及其各自资产之间访问的控制规则。在我们的案例中，我们利用这种业务模型语言来定义专门为管理处方记录而设计的业务网络的规则。
RM 您的架构在实现这一目标方面有哪些新颖之处？
DE Hyperledger Fabric 是所谓的许可型（或私有）区块链，它要求每个人都拥有该区块链认可的身份。一旦您获得身份，您还会获得 PKI（公钥基础设施）证书，然后您可以使用这些证书来识别自己。我应该补充一点，区块链通常非常擅长分发大量密钥。不幸的是，它们在管理这些密钥方面并不那么擅长。因此，如果您正在构建一个利用区块链（或一般而言的 PKI）的系统，您将需要提出自己的密钥管理方法。
我们构建了一个微服务架构，它位于整个 Hyperledger 堆栈之上，专注于将经过身份验证的用户与其各自的密钥或证书进行匹配。一旦完成，就可以使用属于该个人的密钥执行和数字签名幂等事务。
另一个维度是，一个人可以在同一网络上拥有多个凭据。这也必须进行管理。显然，每个人都可能在某个时候成为患者，因此我们所有人都有资格获得患者凭据。然而，只有一部分人有资格成为医生，因此他们需要出示系统认可的适当凭据。还需要临床管理人员使用该系统。即使他们没有开处方的凭据，他们也可能能够输入处方草稿，供医生稍后批准。这意味着一个用户可能与多个密钥相关联，每个密钥都定义了他们被允许在业务网络中执行的不同操作集。
这就是访问控制的用武之地。与网络上的人员关联的每种参与者类型都决定了谁被允许执行特定功能。如果您碰巧是在平台上拥有多个密钥的人，则每个密钥都代表一组不同的您有权执行的操作。例如，如果您是患者，并且您通过 HealthChain 的 Portage API 查询系统以“显示所有患者”，那么您只会收到您自己的记录。另一方面，医生可能会说，“显示所有名为 Bob 的患者”。但这并不意味着应该向医生显示整个系统中所有名为 Bob 的患者的记录。这只是意味着应该向医生显示那些已将该特定医生列为他们关怀圈一部分的名为 Bob 的患者的记录。
TC 但是，如果我拥有多个密钥，您会在单个身份的上下文中为我管理所有这些密钥吗？
DE 这是一个有点棘手的概念。除了定义参与者类型之外，我们还定义了可以与 HealthChain 网络集成的不同应用程序类型。例如，这使我们能够确保如果您从诊所的 EMR 应用程序连接，您只能以医生或诊所管理员的身份连接。您使用患者凭据连接是没有意义的。
作为另一个示例，医生通常从多个诊所应用程序连接，因此与应用程序实例关联的证书可确保我们知道医生是从哪个诊所连接的，因为在身份验证时发给医生的授权令牌对于该应用程序实例是唯一的。无论琼斯医生可能从哪个诊所应用程序连接，都将使用琼斯医生的凭据对网络上的事务进行签名。
RM 但是，如果琼斯医生与某个特定的药房或诊所有关系，但恰好也在某个特定的医院工作，您将如何理清这一点？这听起来好像每个特定事务都可能有一个组织标记。
DE 完全正确。我们保留每位处方者被授权代表其行事的诊所或医院地点的记录。并且每个应用程序证书都绑定到一个特定的诊所地点。通过这种方式，我们能够防止医生欺骗他们通信的地点。
尽管长期以来一直有政策论点认为应该让患者自己决定谁应该被授予访问其医疗保健记录的权限，但事实证明，最令人信服的原因可能被证明是一个非常简单的技术原因。传统的假设是，这些信息属于提供者，因此确定谁可以接收更新需要要么筛选大量患者的数据，要么依赖于一些数据连接。相反，通过从患者的角度来看待这个难题，它可以很快地解决为简单地确定患者以前与哪些提供者有过往来，并就此作罢，这是一种更为优雅的方法。
恰好以患者为中心的方法也可能带来各种新的可能性，因为围绕已定义的患者-提供者关系积累了更多元数据。至少，这可以使访问控制在比当前可能的更精细的级别进行调整。
RM Hyperledger 技术的哪些方面最初吸引您使用该平台？
DE 首先，平台底层的 CouchDB 数据库技术已被证明非常强大且具有很强的扩展能力。数据以 JSON 格式管理，FHIR 和其他数据标准通常都支持这种格式。
同样令人放心的是，Kafka 被用于处理消息传递。在我在金融领域工作的这些年中，Kafka 已被证明是高速交易系统中的有力竞争者。总而言之，我变得非常喜欢 Hyperledger Fabric 的底层技术堆栈。
当然，Hyperledger Fabric 堆栈包含一个区块链数据结构，用于捕获事务请求的不可磨灭的记录。人们将许多不同的事物与区块链联系起来，但从本质上讲，它只是一个用于事务的数据结构，它是复制的，其优点是安全性和冗余性。因此，您现在拥有 Fabric，这是一项专注于确保状态数据库与它已处理的所有事务保持同步的技术，同时还确保每个对等方都获得状态的复制副本。如果出于某种原因，有人设法直接访问其中一个对等方并尝试修改数据，则该节点将从网络中删除。正是区块链的这种防篡改特性为底层数据提供了又一个安全维度。这些安全特性，加上底层堆栈的强大功能，使我们确信了 Hyperledger Fabric 技术。
RM 您稍早前引用了一个示例，该示例表明能够根据特定情况的特定要求调整用户的访问权限。这告诉我，要么还需要在编程方面做大量工作来反映能够涵盖这些情况的策略，要么您有一些规定允许诊所管理员在个案基础上处理这些异常情况。总的来说，当这些实施问题出现时，您是如何处理它们的？
DE 我们一开始面临的挑战之一与弄清楚管理患者与其各自处方者和医疗提供者之间关系的正确模型有关。我们最初从提供者的角度出发，采用了传统的关联数据建模方式来思考问题。但我们发现，通过采用提供者的视角，每个药剂师、诊所地点和医生最终都将引用他们曾经治疗或服务过的任何患者。结果，我们将不得不处理与每个提供者关联的大量患者。
从那里，我们转向了不同的关联概念，我们开始从连接表或连接对象的角度进行思考，这些表或对象将保留对每一方的引用，从而有效地创建中心关系对象。然而，我们在那里遇到的挑战与 Hyperledger Composer 访问控制的约束有关。基本上，任何给定的访问控制都定义了一个参与者、一个资产、该参与者应该对该资产拥有的访问类型以及一个约束。问题在于，通过在评估这些资产的访问控制时引入第三个映射对象，我们将无法访问映射对象所需的所有数据，以正确评估是否应该授予该访问权限。
这促使我们再次尝试解决这个问题，方法是只关注谁真正拥有这些关系。那时，事情开始变得更加自然。我们现在将这些关系作为患者档案的一部分保留。采用以患者为中心的方法的一个主要优势是，患者档案提供了强制实施访问控制所需的所有信息。然后，如果某个与患者没有关系的人想要查看他们的记录，我们可以直接询问，“患者是否与这个试图访问记录的人有关系？”
RM 这与开发主要从诊所或药房的角度看待事物的东西的规范大相径庭。
DE 完全正确，这正是它真正令人兴奋的地方。很明显，这可能会带来各种新的可能性，因为我们才刚刚开始将更多元数据附加到这些关系上。例如，考虑这样一种情况：患者出现在他们以前从未去过的医院的急诊室。这意味着那里的医生无法调出该患者的任何记录。对于这种时间紧迫的情况，最好加入某种规定，允许对患者的记录进行破门而入、限时访问，可能仅限接下来的 24 小时左右。
我们正在探索的另一种可能性将更像是一种基于保险箱的安全机制。基本上，对于每位患者，我们都已经记录了患者与之有某种联系的所有组织或个人，因此我们可以将这些知识与与每种关系关联的加密密钥结合起来。然后，使用这些密钥，我们可以更进一步，使呈现给正在查找患者医保号码的特定提供者的标识符实际上对于该特定患者关系是唯一的。实际上，这将相当于一种在源头匿名化数据访问的机制。
这里的重点是，当我们考虑将更多元数据附加到这些关系时，我们可以开始在非常精细的级别上真正微调这些访问控制。
RM 在此过程中，您还解决了哪些其他挑战？
DE 我们有一段时间感到沮丧，因为我们很难从 CouchDB 实施方案中获得性能。我们最终引入了一个 Elasticsearch 功能，该功能利用事务中的事件来触发更新，从而实现更快的搜索功能。但这有点像 hack。因此，我很高兴地说，我们此后弄清楚了如何更有效地优化 CouchDB 并应用索引，这意味着我们已设法减少了使用 Elasticsearch 增强功能的需求。尽管如此，在此过程中，我们对 CouchDB 以及索引在那里提供的可能性有了更好的理解。
TC 既然您对 Hyperledger Fabric 以及如何优化 CouchDB 性能有了更多的了解，您会为其他希望走类似道路的开发人员提供哪些建议？
DE DevOps，DevOps，DevOps。这是因为这里真正需要的是极限自动化。我们非常幸运地拥有一个在 DevOps 方面非常强大的团队。我们能够将我们的测试网环境从 IBM 基础设施迁移到 AWS（亚马逊网络服务），同时设法保留了我们所有的数据和密钥，以及它们所暗示的访问权限。现在我们已经迁移到 AWS 基础设施，我们将能够进一步扩展。同样，随着其他人开始朝着这个方向发展，他们会发现几乎所有基础设施都涉及 Docker 容器。我们还确保任何给定的微服务都只接受来自其他受信任服务的 TLS（传输层安全）保护的通信。
而且由于我们现在在这样的世界中运行，仅仅成为一名开发人员是不够的。您还需要专注于自动化您的开发环境并了解您的发布过程，因为事态发展太快了，不能不掌握这一点。在您学会如何有效地管理密钥之前，有很多麻烦需要经历。您需要从一开始就考虑为测试目的播种您的环境，以便稍后您可以拥有多种配置选项，您可以随时使用这些选项来执行各种可扩展性和性能测试。
至于所有期望在某个时候发现自己身处某种区块链环境的开发人员，我想说重要的是要记住，这些环境需要永远保持活力。您从创世区块开始，然后从那里继续，密钥分发给曾经是链一部分的每个用户和组织。必须有一些合理的方法来管理它……基本上是永远。所以，正如我所说：DevOps，DevOps，DevOps 是关键。
版权所有 © 2019，所有者/作者所有。出版权已许可给 。
最初发表于 Queue 第 17 卷，第 2 期—
在 数字图书馆 中评论本文
更多相关文章
Queenie Luo, Michael J. Puett, Michael D. Smith - “透视”大象
许多人求助于基于互联网的软件平台，如谷歌、YouTube、维基百科，以及最近的 ChatGPT，来寻找他们问题的答案。大多数人倾向于信任谷歌搜索，因为它声称其使命是从“多个角度传递信息，以便您可以形成自己对世界的理解”。然而，我们的工作发现，涉及复杂主题的查询产生的结果侧重于狭隘的文化主导观点，而这些观点与搜索短语中使用的语言相关。我们将这种现象称为语言偏见，本文通过佛教和自由主义这两个复杂主题的例子展示了它是如何发生的。
Yifei Wang - 从开放访问到有保障的信任
过去十年见证了数据保护法规的出现和加强。对于软件工程师来说，这个新时代提出了独特的挑战：当完整的数据访问（您最强大的工具之一）逐渐被取消时，您如何保持平台的精确性和有效性？任务很明确：重塑工具包。我们感知、处理和试验数据的方式需要彻底改革，才能在这个勇敢的新世界中航行。
Nigel Smart, Joshua W. Baron, Sanjay Saravanan, Jordan Brandt, Atefeh Mashatan - 多方计算：为了保护隐私，进行数学运算
多方计算基于复杂的数学，在过去十年中，MPC 已被用作保护敏感数据的最强大工具之一。MPC 现在是协议的基础，这些协议让一组参与方在私有输入池上进行交互和计算，而不会泄露这些输入中包含的任何数据。最后，只显示结果。这可能常常会产生深远的影响。
Miguel Guevara, Damien Desfontaines, Jim Waldo, Terry Coatta - 差分隐私：默认追求保护
差分隐私于 2006 年首次正式提出，是一种基于严格的数学隐私定义的途径，该定义允许形式化和证明系统提供的针对重新识别的保证。虽然差分隐私在一段时间内已被理论家接受，但事实证明，它的实施是微妙而棘手的，实际应用才刚刚开始变得可用。迄今为止，美国人口普查局以及许多科技公司都采用了差分隐私，但这对于许多人来说，这意味着什么以及这些组织如何实施其系统仍然是一个谜。
© 保留所有权利。