ACM通信
实践
访问控制和医疗保健记录:谁拥有数据?
来源:盖蒂图片社
您不必是具有多年医疗保健数据管理经验的专家，也可以得出这个领域是一团糟的结论。去一趟医院、诊所或药店就能让你相信这一点。几十年来，医疗记录的保存受到传统的拖累，又被分割成互不相干、几乎无法沟通的竖井，让所有试图将其统一起来的努力都付诸东流。
潜在的原因再明显不过了:每个诊所、医院、诊所和药房都运行着自己独立的记录管理系统。平台和技术因组织而异，几乎没有任何共享信息的规定。
但是，如果以一种更以患者为中心的方式来处理这些记录，使用系统和网络，使数据可以被所有的医生、诊所、医院和药房随时共享，一个人可能选择与之共享或有机会访问这些记录呢?而且，更激进的是，如果被认为真正拥有数据的是患者而不是提供者呢?
正是有了这样的想法，多伦多一家名为Health-Chain的初创公司开始创建一个平台，根据患者和他们的不同提供者之间建立的关系来管理患者的药物资料。
理查德·麦克唐纳:问题是谁真正拥有这些记录，谁负责保管它们，以及谁需要访问它们。
这一愿景成为HealthChain CTO面临的挑战大卫埃文斯利用在金融行业25年的投资组合管理和定量研究系统的工作经验。在他转向医疗保健行业之前的几年里，他发现自己对应用新兴数字身份和区块链技术创建更高效政府服务的可能性越来越感兴趣。现在，他有机会将其中一些想法付诸实践。
为了深入了解HealthChain是如何应对药物配置管理挑战的，Evans在这里加入了讨论理查德·麦克唐纳最近退休的IBM杰出工程师特里Coatta他是总部位于温哥华的初创公司Marine Learning Systems的首席技术官，致力于开发一个学习平台。
理查德·麦克唐纳:作为经常去医生办公室甚至医院的人，我们都知道记录对那些手术是多么重要。从历史上看，这是以纸质记录的形式保存在塞满东西的文件柜里。但现在，随着医疗行业在全面进入21世纪方面姗姗来迟，电子记录似乎也逐渐被纳入其中圣世纪。随着这一过程的继续推进，问题就出现了:谁真正拥有这些记录，谁负责管理它们，以及谁需要访问它们。你认为这些不同的医疗机构在监护责任方面需要解决的一些关键问题是什么?
大卫·埃文斯:就像你说的，在这一点上，有些医生使用计算机系统，有些则不用。那些使用计算机进行记录的人通常使用一些被称为EMR(电子医疗记录)系统的本地化仪器(也被称为EHR(电子健康记录)系统，这取决于国家和使用情况)。就谁拥有这些记录而言，任何将病人的详细信息输入EMR系统的医生都要对该信息的准确性负责。话虽如此，当涉及到病人的完整医疗记录的所有权时，越来越多的人认为这些信息应该属于病人。
目前的事实是，任何病人的记录实际上都分散在任意数量的竖井数据库中，因为当你从一家诊所到另一家或从一家药店到另一家时，每个数据库都会为你创建一个新的记录。在确定谁拥有这些记录时，我倾向于将每个医生负责在自己的系统中维护的信息与某个特定患者一生中收集的所有医疗信息的总和区分开来。虽然很多人认为这是属于患者的信息，但目前的现实是，患者实际上甚至不享有访问这些数据的权利，对如何使用这些数据几乎没有控制权。
特里COATTA:为了弄清楚这些竖井，你说的是集中的数据库还是在不同的医生办公室维护的许多小型的个人数据库?
埃文斯:它本质上是两者的混合。市面上有很多独立的医生诊所，就他们使用计算机系统的程度而言，它们可能不过是一台台式机或笔记本电脑上运行的一个数据库。
出于同样的原因，有跨越多个地点的医疗保健团队。安大略最大的一个诊所有37个不同的诊所地点，它们都共享一个托管在云中的EMR实现。但我相信，即使是实施组织，医生也只能看到那些访问他们的特定诊所的病人的信息。
麦当劳:从一个在这些诊所工作的管理员的角度来看，这是什么样子的?
埃文斯:即使EMR应用已经到位，也有许多老化的技术需要应对。此外，在早期，我们被警告不要走进医生的办公室，期望被允许改变工作流程。自20世纪80年代以来，这些技术并没有取得太大进步，这是有原因的。医生们已经习惯了。由于某些过时的设计选择，他们本能地知道自己需要在这个特定的页面上点击三次标签。是的，这可能很愚蠢，但这是一种他们早就习惯了的设计。
COATTA:这些不同的网站之间是否存在整合的故事?显然，如果世界上到处都是这些数据竖井，您会认为应该有一些与信息交换相关的标准。还是说这里就像西部大荒?
埃文斯:这方面最有前途的全球标准是FHIR，它代表快速医疗保健互操作性资源。它是一个标准，经过了多年的多次迭代，它的重点是互操作性。
它并非没有缺点，但FHIR绝对是目前不同系统之间互操作性的最佳资源。尽管如此，仍然存在大量数据复制的空间，而且它基本上只用于一次性的数据传输。也就是说，目前还没有一个FHIR网络可以让所有这些不同的数据库以任何方式保持同步。或者至少我从未见过类似的东西。
麦当劳:我是否认为病人对他们的信息的处理几乎没有发言权?
埃文斯:这绝对是正确的。如果你看看健康隐私标准，它们都强调患者的同意。但就所有的实际目的而言，似乎唯一存在的同意是默示同意，因为就目前的情况而言，没有任何切实可行的机制可以让患者就如何使用他们的数据提供或收回同意。也就是说病人几乎完全脱离了大局。
另一方面，医疗服务提供者之间也没有以任何患者可能合理期望的方式共享信息。如果你总是去同一家诊所，他们已经认识你，随时都有你的记录。但是，如果因为某种原因，你发现你需要去其他的诊所，或者最终被送进了急诊室，你很有可能成为那里治疗你的人的一张白纸。他们不会知道你对什么过敏。他们不会知道你有什么先决条件。他们不会知道你在吃什么药。所以，这意味着他们将不得不四处寻找所有的信息，他们可以从你或家庭成员。
COATTA:这听起来完全是一团糟，那么你现在正试图解决这个问题的哪一部分呢?
埃文斯:借用区块链世界的一个术语，我们正在努力向医疗界提供一个共享账簿。我们的目标是提供患者记录的视图，不仅医生和药剂师能够共享，而且患者也可以使用。这在今天是有可能实现的。
我们的主要目标之一是从病人的角度跟踪所有这些信息:他们使用什么药房?他们去哪些诊所就诊?哪些医生在这些诊所治疗他们?那么，我们所说的病人护理圈中的每一个参与者是如何被授权访问病人的记录的呢?此外，我们能否在患者的数据如何被使用和访问方面为患者提供透明度和一些控制?
COATTA:这听起来像是一个令人钦佩的目标，但你真的能实现吗?听起来你好像在试图移动这个不动的物体。
埃文斯:实际上，我不会说我们要移动或更换任何东西。事实上，根据规定，我们不能更换现有的电子病历系统。我们的目标当然不是捕获一个EMR需要保留的所有数据，因为每个托管组织，也就是每个医疗保健提供者仍然对维护自己的记录负有法律责任。
然而，当他们继续更新每个病人的药物资料的一些细节时，我们希望做的是与所有这些电子病历集成，这样他们就可以保持关于这些病人记录的共享状态的最新信息，同时也可以利用这种信息，使病人的护理圈中的每个人都可以随时查看它。
我们绝不是想要改变世界，而只是想让医生、药房和患者能够在患者使用过的所有不同供应商之间共享患者处方历史的共同视图。这本身就是一个足够大的挑战，也是一个重要的目标，但它也比试图取代所有的EMR系统要实际得多。
麦当劳:看来，解决这个问题的关键之一是跟踪病人是谁，并有办法在所有这些不同的方面识别他们，同时显然还要管理访问控制。你能详细说明一下这个问题吗，特别是关于数字身份的问题?
埃文斯:当然，系统需要唯一的标识符。到目前为止，这意味着我们能够通过发给病人的医疗卡号来识别病人。同样，我们通过医生的执照号码来识别医生，通过药店的认证号码来识别药店。但我们也需要能够接受当今世界接受的其他一些标识符，所以我们正在努力提出一个更健壮的注册过程。但是，这实际上可以归结为采取任何必要的步骤来防止在系统中存在同一患者、医生或药剂师的多个配置文件。
Hyperledger Fabric和Hyperledger ComposerHealthChain建立在经过验证的、熟悉的开源软件基础上，对通用部署没有明显的障碍。
然而，对使用HealthChain形成的患者和提供者网络的访问仅限于有资格的参与者，他们反过来只能被授予对某些信息资产的访问权，并被允许在这些信息资产上执行特定的功能集。
这意味着，访问控制列表最终可能被证明是解决长期以来医疗保健数据管理僵局的关键，因为它们不仅是将对对象的访问绑定到每个参与者类型的手段，而且是定义任何给定对象上允许的操作的手段。
麦当劳:既然您已经告诉了我们您的应用程序的目标是什么，那么请告诉我们您实际做了什么。
埃文斯:首先，我们使用的是Hyperledger Fabric和Hyperledger Composer，它们都来自Linux基金会支持的一个与区块链相关的项目。Fabric基本上围绕区块链组件提供了一堆工具，它有效地为我们提供了所有传入的幂等事务请求的不可磨灭的记录。我们认为这些事务是“智能合约”，但在任何情况下，它们都是更新状态的事务。也就是说，超级账本结构为我们提供了一种维护全球状态数据库的方法。
底层的数据库技术是CouchDB，它为我们提供了处理JSON (JavaScript对象表示法)对象的对象存储，使用MapReduce对所有这些JSON对象结构应用索引并执行快速查询。对我们来说，作为Fabric一部分的另一项重要技术是Kafka，它提供了高性能的消息流。它提供了对等点之间的事件通知，以及向其他进程传递通知。
与此同时，Hyperledger Composer是构建在Fabric之上的一个框架，它可以帮助您定义Hyperledger世界认为的商业网络，在这个网络中，网络中的所有参与者以及网络预期要管理的所有各种资产都被标识出来，以及控制规则，控制所有不同参与者及其各自资产之间的访问。在我们的案例中，我们利用这种业务模型语言为专门为管理处方记录而设计的业务网络定义规则。
麦当劳:为了实现这个目标，您的架构做了哪些新奇的事情?
埃文斯:超级账本结构是所谓的许可或私有区块链，它要求每个人都有一个被区块链识别的身份。一旦您获得了身份，您还将获得PKI(公钥基础设施)证书，然后您可以使用该证书来识别自己的身份。我应该补充一点，区块链通常非常擅长分发一堆密钥。不幸的是，他们并不擅长管理这些密钥。所以，如果你正在构建一个利用区块链或PKI的系统，你将需要想出自己的方法来管理这些密钥。
我们已经构建了一个微服务架构，它位于整个超级账本堆栈的顶部，它专注于将经过认证的用户与他们各自的密钥或证书进行匹配。完成此操作后，就可以执行幂等事务并使用属于该个人的密钥进行数字签名。
另一个方面是，一个人可以在同一个网络上拥有多个凭据。这一点也必须加以管理。显然，每个人在某个时候都可以成为患者，所以我们所有人都有资格获得患者证书。只有一些人有资格成为医生，所以他们需要提供系统认可的适当证书。也会有临床管理人员需要使用该系统。即使他们没有开处方的资格，他们也可以输入处方草稿供医生稍后批准。这意味着一个用户可能与多个密钥搜索相关联，每个密钥搜索定义了他们在业务网络中被允许做的一组不同的事情。
这就是访问控制的用武之地。与网络上的某个人相关联的每一种参与者类型决定了允许谁执行特定的功能。如果您恰好在平台上拥有多个密钥，那么每个密钥代表您被授权执行的一组不同的事情。例如，如果您是一名患者，您通过HealthChain的Portage api查询系统以“显示所有患者”，那么您将返回的唯一记录将是您自己的记录。另一方面，医生可能会说:“给我看看所有叫鲍勃的病人。”但这并不意味着医生应该看到整个系统中所有姓鲍勃的病人的记录。这只是意味着医生应该看到那些叫鲍勃的病人的记录，这些病人把那个医生列为他们的护理圈子的一部分。
COATTA:但如果我有多个键，您会在单个标识的上下文中为我管理所有这些键吗?
埃文斯:这是一个有点模糊的概念。除了定义参与者类型之外，我们还定义了可以与HealthChain网络集成的不同应用程序类型。例如，这允许我们确保，如果您从诊所的EMR应用程序连接，则只允许您以医生或诊所管理员的身份连接。用你的病人证书来连接是没有意义的。
另一个例子是，医生通常从多个诊所应用程序进行连接，因此与应用程序实例相关联的证书确保我们知道医生从哪个诊所进行连接，因为在身份验证时颁发给医生的授权令牌对于该应用程序实例是惟一的。无论Dr. Jones碰巧从哪个临床应用程序连接，都将使用Dr. Jones的凭证在网络上签署事务。
麦当劳:但如果琼斯医生与某个特定的药房或诊所有关系，同时又恰好在某个特定的医院工作，你如何才能解决这个问题呢?听起来好像每个特定事务都有一个组织标记。
埃文斯:完全正确。我们记录了每个处方者被授权代表哪个诊所或医院的位置。每个申请证书都与一个特定的诊所地点绑定。通过这种方式，我们能够防止医生欺骗他们的通信地点。
尽管长期以来，人们一直主张让患者自己决定谁应该访问他们的医疗记录，但事实证明，最令人信服的理由可能是一个非常简单的技术原因。传统的前提是，这些信息属于提供者，因此确定谁可以接收更新需要处理大量患者的数据，或者依赖于一些数据连接。相反，从病人的角度来看这个难题，它很快就会变成简单地确定病人以前与哪些医生打交道，然后就把它留在那个优雅得多的方法上。
随着更多的元数据围绕已定义的患者-提供者关系积累起来，以患者为中心的方法也可能带来各种各样的新可能性。至少，这可以使在比目前可能的更细粒度的级别上调优访问控制成为可能。
麦当劳:超级账本技术最初是如何吸引您使用这个平台的?
埃文斯:首先，作为平台基础的CouchDB数据库技术已经被证明非常健壮，而且具有很强的扩展性。数据以JSON格式管理，FHIR和其他数据标准通常支持这种格式。
同样令人欣慰的是，卡夫卡被用来处理消息传递。在我在金融领域工作的这些年里，Kafka被证明是高速交易系统的有力竞争者。也就是说，我对Hyperledger Fabric的底层技术栈非常着迷。
当然，Hyperledger Fabric栈包含一个区块链数据结构，它捕获交易请求的不可磨灭记录。人们将许多不同的东西与区块链联系在一起，但本质上，它只是被复制的事务的数据结构，其好处是安全性和冗余性。因此，这里有了Fabric，这是一种专注于确保状态数据库与它处理过的所有事务保持同步的技术，同时也确保每个对等体都获得状态的复制副本。如果由于某种原因，有人设法直接访问其中一个对等点并试图修改数据，则该节点将从网络中删除。区块链的这个易篡改属性为底层数据提供了另一个安全性维度。这些安全特性加上底层堆栈的健壮性，使我们对Hyperledger Fabric技术有了信心。
麦当劳:稍早之前，您引用了一个示例，该示例建议根据特定情况的要求调整用户的访问权限。这告诉我，要么还有相当数量的工作要做，以反映能够涵盖这些情况的政策，要么你有一些规定，允许诊所管理员在个案的基础上处理这类异常情况。总的来说，当这些问题出现时，你们是如何处理的?
埃文斯:我们马上面临的一个挑战是找到正确的模式来管理病人与各自的处方医生和医疗提供者之间的关系。我们最初采用了传统的关系数据建模方法，从提供者的角度考虑问题。但我们发现，从提供者的角度来看，每个药剂师、诊所地点和医生最终都会得到他们曾经治疗过或服务过的任何病人的参考资料。因此，我们将不得不处理与每个提供者相关的大量患者。
从这里开始，我们转向了一个不同的关系概念，我们开始考虑连接表或连接对象，以保持对每个参与方的引用，有效地创建中心关系对象。不过，我们在那里遇到的挑战与Hyperledger Composer访问控制的约束有关。基本上，任何给定的访问控制都定义了一个参与者、一个资产、参与者应该拥有的对资产的访问类型以及一个约束。这样做的问题是，通过在评估这些资产的访问控制时引入第三个映射对象，我们将无法访问映射对象所需的所有数据，从而正确地评估是否应该授予该访问权。
这让我们再次尝试通过观察谁真正拥有这些关系来解决这个问题。从那时起，事情开始变得更加自然。我们现在把这些关系作为病人档案的一部分。采用以患者为中心的方法的一大优点是，患者概要文件提供了实施访问控制所需的所有信息。然后，如果一个和病人没有关系的人想要查看他们的记录，我们可以问，“这个病人和这个试图获取记录的人有关系吗?”
麦当劳:这完全背离了从临床或药学的角度来研究事物的常规。
大卫·埃文斯:我们的目标是提供一个病人记录的视图，不仅医生和药剂师能够共享，而且病人也可以使用。这在今天是有可能实现的。
埃文斯:没错，这才是真正让人兴奋的地方。很明显，这可能导致各种各样的新可能性，因为我们才刚刚开始将更多的元数据附加到这些关系中。例如，考虑这样一个场景:一个病人出现在一家他从未去过的医院的急诊室。这意味着那里的医生无法调出这个病人的任何记录。对于这种时间紧迫的情况，最好包括一些条款，允许打破玻璃，有时间限制的访问病人的记录，可能只在接下来的24小时左右。
我们正在探索的另一种可能性是建立一种基于锁盒的安全机制。基本上，对于每个病人，我们已经有了病人与之有某种联系的所有组织或个人的记录，所以我们可以将这些知识与与每一种关系相关的密码密钥结合起来。然后，使用这些键，我们可以更进一步，以便向查找患者医疗保健号码的特定提供者提供的标识符实际上对于该特定患者关系是惟一的。这实际上相当于一种从源头就匿名化数据访问的机制。
TERRY COATTA:如果世界上有这么多数据仓库，你会认为应该有一些与信息交换相关的标准。还是说这里就像西部大荒?
这里的要点是，当我们查看将更多元数据附加到这些关系中时，我们可以开始在非常细粒度的级别上对这些访问控制进行真正的微调。
麦当劳:在此过程中，你还应对了哪些挑战?
埃文斯:我们沮丧了一段时间，因为我们很难从CouchDB实现中获得性能。我们最终引入了Elasticsearch功能，该功能利用来自事务的事件来触发更新，从而实现更快的搜索功能。不过，那是有点黑。因此，我很高兴地说，我们已经找到了如何更有效地优化和将索引应用到CouchDB的方法，这意味着我们已经成功地减少了使用Elasticsearch增强功能的需要。尽管如此，在这个过程中，我们对CouchDB以及索引提供的可能性有了更好的理解。
COATTA:现在您对Hyperledger Fabric有了更多的了解，也了解了如何优化CouchDB的性能，那么您对其他希望遵循类似路径的开发人员有什么建议呢?
埃文斯:DevOps, DevOps, DevOps。这是因为这里真正需要的是极端自动化。我们非常幸运地拥有一个非常擅长DevOps的团队。我们能够将我们的测试网环境从IBM基础设施迁移到AWS (Amazon Web Services)，同时设法保存我们所有的数据和密钥以及它们所隐含的访问权限。既然我们已经使用了AWS基础设施，我们将能够进一步扩展。同样，当其他人开始向这个方向发展时，他们将发现几乎所有的基础设施都涉及Docker容器。我们还确保任何给定的微服务将只接受来自其他受信任服务的TLS(传输层安全)安全通信。
因为我们现在所处的世界是这样的，仅仅成为一名开发人员是不够的。您还需要专注于自动化您的开发环境和理解您的发布过程，因为事情发展得太快了，不能忽视这一点。在您学习如何有效地管理密钥之前，有许多令人头痛的事情要经历。而且，您需要从一开始就考虑为测试目的播下环境种子，以便稍后有多个配置选项可以方便地用于执行各种可伸缩性和性能测试。
对于所有那些希望在某个时候发现自己处于某种区块链环境中的开发人员，我想说的是，必须记住这些环境需要永远保持活跃。您从一个起源块开始，然后从那里继续，密钥被分发给每个用户和组织，他们曾经是链的一部分。必须有一些合理的方法来管理……永远的本质上。所以，正如我所说:DevOps, DevOps, DevOps是关键。
数字图书馆是由计算机协会出版的。版权所有©2019 ACM, Inc.
没有发现记录