将个人产生的数据标准化地整合到常规临床护理中

简介

个人生成数据(PGD)是关于个人日常生活和门诊期间健康状况的宝贵信息来源[1］．PGD可以通过应用程序、传感器、可穿戴设备或简单的在线表单获得，我们统称为PGD设备．

为了充分从PGD中提取价值，卫生保健组织必须能够顺利地将来自PGD设备的数据集成到常规临床工作流程中。例如，在一个理想的远程血压监测程序中，临床医生将“规定”一个血压监测计划(例如，在未来两周内每天早上测量血压)。患者将通过蓝牙连接的无线袖口收集并共享血压数据，这些数据将无缝集成到临床工作流程中，供临床医生在患者管理期间查看，例如，根据异常值的家庭血压值通知对家庭药物进行滴定。这个相同的工作流程应该能够适应其他PGD的处方，如血糖、体重或任何临床批准的PGD设备获得的氧饱和度。

然而，目前的远程监测项目往往范围有限，仅针对一种疾病(如高血压、糖尿病或心力衰竭)，仅获取一种类型的远程数据[2，3.](例如，BP或血糖)，并且仅支持有限数量的PGD设备(就品牌/型号而言)。这种限制与当前互联网服务的技术能力是不一致的，在互联网服务中，数据可以用设备不可知的方法交换[4，5］．电子邮件就是一个熟悉的例子。底层标准允许发送和阅读电子邮件，而不受服务提供商、应用程序、浏览器或使用的设备的影响。6］．目前，pgd与诊所的整合缺乏电子邮件的无缝衔接。相反，医疗保健组织与每个设备及其专有数据格式建立并维护自定义连接。这种连接在临床护理中使用PGD设备的成本中占很大一部分[7]，对PGD的使用构成障碍[8］．

这一观点将PGD集成到临床系统和工作流程中作为一种方法PGD集成管道并对该管道的功能组成进行了综述。我们通过将无线BP数据集成到初级保健的例子，将当前的集成状态与基于标准的管道进行对比。我们始终强调数据标准在促进设备不可知方法方面的核心重要性，这些方法需要适应当今医疗保健系统的复杂性、规模和快速发展。

标准化PGD集成管道

概述

在个人设备和医疗机构之间建立自定义连接成本高昂，并导致数据管理效率低下。对于有意通过不同PGD设备远程监控多种类型健康数据的组织，一种方法是为每种数据类型选择1家或几家设备供应商，并为每个设备开发到电子健康记录(EHR)的自定义连接[9］．这种方法不仅冗余、成本高、维护繁重，而且依赖于特定于供应商或设备的自定义连接降低了将来添加或替换新设备的灵活性。

如果我们将PGD集成的3个主要功能组件进行细分，我们就可以确定简化管道的机会:

1. PGD采集:这包括管理面向人的功能(如同意和数据收集)的PGD设备;
2. PGD聚合:该服务管理同意、身份验证和授权;将数据映射为标准格式;提供存储;和第三方的查询端点;
3. PGD消费:第三方(包括EHRs、决策支持系统和分析服务)提供消费PGD的应用程序，为临床医生和患者等用户提供服务(图1)．

目前，每个PGD设备管理自己的采集、存储和数据使用，而每个医疗保健组织充当多个查询端点的第三方，每个查询端点都需要自己集成到临床工作流程中。数据标准将使来自多个设备的PGD通过单个管道流动，而不是多个管道，每个管道服务于一个设备。

‎ 查看此图

PGD采集和数据共享同意书

PGD是通过由健康跟踪应用程序、可穿戴设备和传感器组成的多样化且不断增长的生态系统从患者身上获得的[10］．通常情况下，一款设备需要患者下载一款智能手机应用程序来建立一个账户，并通过蓝牙将数据从设备上拉到智能手机上，存储在设备公司的云上。许多设备提供应用程序或在线仪表板，患者或他们的医生可以在其中查看跟踪数据[11-13］．

一旦设备获取数据，患者直接或通过单独的PGD聚合应用程序同意数据共享，该应用程序将数据提供给第三方解决方案及其用户(图1)．现有的聚合应用程序包括Apple Health、谷歌Fit、CommonHealth、Human API和valid。Apple Health和谷歌Fit分别允许患者与iOS和Android生态系统中的任何参与第三方进一步分享他们的数据，但有一些不透明的规则，第三方可以要求数据，并且不需要任何临床有效性或安全性评估。CommonHealth是一家进入个人健康记录/聚合应用程序领域的非营利组织，它的不同之处在于建立了一个共同信任框架[14患者可以同意将下载的电子病历或设备数据共享给手机上运行的可信应用程序和服务。这个框架是一套中立的、独立的规则，是通过开放社区治理开发的。

可以在不同的粒度级别上授予数据共享同意。患者可以授权他们的临床医生只访问他们的血压数据，而授权他们注册的临床试验访问血压、步数、体重和卡路里跟踪数据。出于隐私或其他原因(例如，在度假期间隐瞒体重数据)，也可以完全或暂时撤销同意。

PGD聚合

一旦患者同意数据共享，聚合应用程序的服务就会处理他们的同意，以调解数据传输。PGD聚合服务组件包括验证第三方数据请求、解析被请求的数据是谁的、管理授权和同意、安全存储数据(如果需要)、将数据映射为标准化格式以及以所需的标准化格式将数据导出到第三方。

身份验证、授权、身份解析和同意管理处理

一般实践

标准工业程序，如OAuth2 [15]用于PGD聚合器和第三方之间的委托授权。委托授权允许患者授权不同的服务访问他们的数据，而不需要服务之间相互公开个人凭据信息。但是，多个服务之间的身份解析具有挑战性，因为患者通常拥有多个医疗保健帐户(例如，他们的诊所、化验室和药房)。

医疗保健帐户(例如EHR服务)中的身份解析是通过患者快速医疗保健互操作性资源(FHIR) id进行调解的。但是，患者对于他们访问的每个健康组织都有不同的FHIR id，并且根据FHIR服务器的后端实现，组织可能为每个患者拥有多个FHIR id。如果没有全国唯一的患者标识符，PGD聚合器将不得不近似患者标识符。将许多FHIR id和设备与应用程序连接起来需要繁琐的授权流程组合，从而进一步复杂化了同意管理，因为PGD聚合器必须将患者的数据共享同意与任何第三方对患者数据的请求进行匹配。同意管理体系结构的复杂性强烈支持标准化的可重用多用途PGD集成管道。

数据存储

PGD聚合器可以根据业务需要传递或存储并转发数据。通过直通，聚合器从手机或设备云中摄取数据，并在每次请求时直接将数据发送给第三方。使用存储转发，聚合器持久化数据。传递方法的好处包括降低成本和安全风险，因为聚合器不存储数据。缺点包括数据访问的延迟增加，无法执行计算(例如，请求值的平均值)，以及需要重复到标准化数据格式的任何映射。在存储转发模型中，数据可以以本机格式或任何标准化格式持久化。

PGD聚合器通常有一个电话组件和一个云组件。有些是PGD(如谷歌Fit)，而其他(如Apple Health, CommonHealth)也汇总EHR数据。Apple Health和CommonHealth将所有同步数据保存在患者的智能手机上;谷歌Fit上传数据至谷歌Cloud。

标准化数据和元数据导出

大多数现有的聚合器使用自己的非标准化格式将PGD导出给第三方[16-18］．相比之下，CommonHealth以标准化格式导出数据:EHR数据以Health Level 7 (HL7) FHIR格式导出，PGD以Open mHealth/IEEE 1752.1格式导出。这一差异至关重要。临床相关的上下文信息对于临床决策是必要的。如图2，“138”的血糖数据在临床上没有意义，除非明确其单位、与饮食或睡眠的关系以及有效时间(即观察结果应用于现实世界的时间，而不是报告数值的时间)。标准化的选择、定义和值集，如图3，对于这些上下文变量(例如，单位的统一度量单位代码[UCUM])，将允许第三方系统可靠且明确地理解PGD值的含义，这是在医疗保健或研究中使用PGD的最低要求。

‎ 查看此图

‎ 查看此图

除了临床相关的上下文信息外，在医疗保健或研究中使用PGD还需要元数据[19，20.-关于数据的数据。示例包括源设备的名称、型号和唯一ID，以及应用程序的唯一ID [21)安装在获取数据的患者智能手机上。表1列出睡眠数字生物标记感兴趣的元数据示例。

虽然出于某种目的而对某些人感兴趣的元数据类型没有止境，但在所有PGD上收集所有可能的元数据是不可行的。然而，必须在所有PGD值上提供最小的关键元数据集，以支持生态系统范围内的质量保证、审计和监管监督。因此，PGD生态系统必须围绕一组核心数据和元数据标准来实现PGD的长期完整性和可用性。数据可以通过PGD设备在输出点进行标准化，或者PGD聚合器可以协调并为标准化PGD提供端点。表2列出了与PGD最相关的标准。在设备层面，IEEE 11073 [22]和FHIR的设备资源[23解决制造、安全、隐私和数据导出问题。对于PGD集成，Open mHealth/IEEE 1752.1.1标准是最直接相关的，它通过超过80个JSON模式涵盖了睡眠、体力活动、心血管和其他领域最广泛使用的PGD变量[24，25］．值集使用来自医学系统化命名法(SNOMED)或逻辑观察标识符名称和代码(LOINC)的术语进行标准化。最小元数据模式用于JSON模式头，带有指向外部持有的元数据信息(例如，UDI注册表)的标准化指针。开放移动健康模式是开源的，对所有人免费，是由开发人员、数据科学家、信息学家、研究人员和临床医生组成的全球利益相关者社区的产出。睡眠、体力活动、元数据和效用模式(单位、时间等)组成了全球标准IEEE 1752.1.1 [25］．

PGD消费

占据PGD集成管道远端的第三方用户包括卫生保健组织、研究人员和患者本身(例如，为血糖控制提供预测分析的应用程序的消费者)。许多第三方希望成为设备不可知论者。例如，一家为血压管理提供决策支持的公司可能希望接受任何fda批准的品牌和型号的无线血压袖带的血压数据。许多第三方可能还需要集成异构数据源，例如协调来自智能手表和专用睡眠传感器的睡眠数据。如果PGD在一个通用的数据和元数据标准中可用，第三方将享受极大的效率，因为不需要推断从不同来源获得的PGD的上下文含义或元数据。来自PGD聚合器的标准化端点将支持一次收集PGD并将它们用于多个目的的理想。

典型案例

家庭血压集成

家庭血压监测(HBPM)计划，即专门的工作人员监测一组高血压患者的家庭血压，以进行治疗支持和调整，已显示出改善血压控制的有效性[27］．因此，卫生保健组织对建立HBPM项目越来越感兴趣[8]，根据几个医疗保险和医疗补助服务中心(CMS)的账单代码，可以报销，但前提是通过无线连接的袖口获取家庭血压测量值，并直接写入医疗保健组织的电子病历[28］．我们通过将无线BP数据集成到EHR的例子来说明PGD集成管道。

现状:家庭血压集成

目前，来自连接设备的家庭bp可以通过几种途径进入HBPM计划。一种方法是让患者手动将家庭bp输入到EHR患者门户。尽管简单，但这种方法有很多缺点。对于语言障碍和技术水平较低的患者来说，使用患者门户网站具有挑战性。29］．手动报告可能导致数据点减少，难以长期维持[30.]，在远程生理监测代码下，CMS不报销人工上报BP数据的评估和管理费用[28］．

另一种方法是医疗保健组织和无线BP袖带公司之间的合作，该公司将为临床医生提供该公司的在线仪表盘。临床医生需要在EHR之外登录公司网站，这严重扰乱了工作流程，通常会遭到临床医生的强烈反对。此外，要获得CMS报销资格，必须构建和维护一个自定义接口，以便将该公司的数据写入EHR。这不仅耗时且昂贵，而且还严重限制了灵活性。添加另一个品牌的袖口将需要一个全新的整合工作和在线仪表盘。只和最初的公司呆在一起的惯性会很大。在快速变化的数字医疗世界，这种“锁定供应商”是不可取的。

一种新兴的方法利用Apple Health和谷歌Fit作为PGD聚合器。在使用Epic系统的加州大学旧金山分校(UCSF)，一个试点项目允许临床医生开出HBPM处方，并将处方显示在患者的MyChart门户网站上。患者使用多种品牌的袖口，将设备的应用程序和MyChart应用程序下载到智能手机上，并使用Apple Health或谷歌Fit获得同意，将他们的血压数据从设备的应用程序导入Epic。输入的数据可以在Epic中查看，评估和管理可以在CMS代码下计费。这种方法具有与设备无关、可计费以及集成到基于ehr的工作流中的优点。然而，它依赖于Epic、MyChart、Apple Health和谷歌Fit的功能和可用性。事实上，在撰写本文时，谷歌Fit已“暂时停止”接受连接的血压值和其他“敏感”健康数据类型，包括体温和氧饱和度[31］．此外，使用PGD聚合器而不使用数据标准驱动的基础设施会损害健壮的PGD验证和使用。例如，设备制造商数据无法从Apple Health或谷歌Fit端点查询。

目标:标准化的家庭血压集成

在整个BP集成管道中使用数据标准的最佳方法提供了许多好处。首先，如果设备供应商遵守数据和元数据标准(例如，Open mHealth/IEEE 1752.1.1)，那么BP和其他PGD的含义和上下文将在源头为后代捕获，这对于下游使用、审计和监管监督是理想的。如果BP数据在源头上没有标准化，基于标准的PGD聚合器(如CommonHealth)可以从多个供应商获取BP数据并将其映射到Open mHealth或FHIR中，以便进行标准化导出。使用基于标准的PGD聚合器的医疗保健组织可以确保BP数据与相同的临床上下文信息和元数据具有一致的格式，无论袖带的品牌或型号如何。单一集成管道中的这种设备不可知的可预测性产生了极大的灵活性:可以集成来自不同设备供应商的多种类型的PGD。

对于卫生保健组织来说，标准化可以促进数据集成到工作流中，并将数据写入EHR进行计费。美国的电子病历现在必须依法支持HL7 FHIR数据和协议标准[32］．这允许EHRs使用SMART-on-FHIR接收和显示PGD [33协议直接在EHR中启动仪表板，而不需要单独登录。加州大学旧金山分校的improve项目采用了这种方法[34]，在BRIDGE SMART-on-FHIR仪表板中显示患者报告的结果和BP数据[35］．使用SMART-on-FHIR将数据显示和决策支持表示从EHR的约束中解放出来。虽然SMART-on-FHIR技术仍处于早期应用阶段，但在增强PGD集成管道的远端方面具有巨大的前景。

数据标准化对卫生保健组织的另一个宝贵好处是提高了数据集成的效率[36］．以通用可预测格式(如Open mHealth/IEEE 1752.1.1)接收PGD的组织无需构建和维护与多个设备供应商的自定义连接，而是可以重用相同的接口，将PGD引入其EHR或临床工作流程。今后，这个单一接口可以容纳数据标准支持的任何新的PGD数据类型。组织可以灵活地切换到支持相同数据标准的任何其他PGD聚合器，因为PGD与EHR的接口保持一致。

最后，只有当患者信任他们的PGD将如何处理，并且收集、同意、理解和共享PGD足够容易时，PGD的承诺才会实现[37］．如果PGD集成管道的标准化减少了数据竖井、多个身份和帐户以及大量不透明的数据共享机制，那么各方之间的信任将得到增强，PGD的完整性和价值将得到提高。

讨论

突出了

今天的移动医疗数据生态系统——多个应用程序、设备和专有聚合器都以自己的数据格式导出数据，几乎没有上下文或元数据——对于释放移动医疗技术的全部功能来改善临床护理来说是次优的。标准是成功实现数据互换性的关键，应该被广泛采用，以实现与设备无关的解决方案和模块化，并简化PGD生态系统，同时支持数据验证和数据完整性。

数字生物标记物验证和应用程序框架的关系

临床护理中PGD解决方案的部署需要超越互操作性和集成。选择和部署移动健康应用程序和传感器有各种框架和最佳实践。HL7的消费者移动健康应用程序功能框架(cMHAFF)提供了行业指南和通用方法来评估移动健康应用程序的“基本特征”，包括但不限于安全、隐私、数据访问、数据导出和条件的透明度/披露[38］．HL7的应用程序数据交换(ADE)项目记录了功能需求，并提供了一个框架，支持移动医疗设备、应用程序和医疗IT基础设施的其他部分之间的数据交换[39］．ADE项目引用了诸如Open mHealth/IEEE 1752.1.1和IEEE 11073等移动健康数据标准。

就其本身而言，cMHAFF和ADE都没有解决移动医疗解决方案的临床有效性或价值。DiMe Playbook是关于开发、选择和部署数字生物标志物的“全面的‘如何’指南”。它涉及数字生物标志物验证、分析验证和临床验证(V3)，以及Open mHealth/IEEE 1752.1.1等标准在数据集成中的作用[40］．

通过设计实现互操作性

就像隐私一样，数据来源和互操作性应该有意地预先设计到系统中，而不是后来硬塞进系统中。41］．对于移动健康生态系统来说，上述框架、官方数据标准和协议以及最佳实践的混合，正开始描绘出一条走出当今碎片化孤岛的道路。特别是对于PGD集成管道，路径包括PGD设备和mHealth应用程序在适当的情况下以Open mHealth/IEEE 1752.1格式导出和使用数字生物标志物;扩展Open mHealth/IEEE 1752.1标准化的数据类型;数据聚合器以当前格式(以确保向后兼容性)和Open mHealth/IEEE 1752.1格式(以向标准化互操作性过渡)导出PGD;最后，广泛采用开放式医疗-FHIR实施指南作为PGD的通用FHIR观察资源概要[42］．这些步骤为生态系统过渡到数据和元数据标准提供了一条滑梯，这些标准本身也在演变，以适应新的数字生物标记和新的元数据框架。需要进一步研究可扩展的元数据获取和管理、生物标记物验证平台以及与更广泛的物联网的互操作性。

结论

来自移动健康应用程序和传感器的PGD的临床价值目前由于难以和低效地集成到常规临床护理中而受到限制。PGD集成管道的主要组成部分包括PGD获取、PGD聚合和第三方解决方案，这些解决方案使用PGD为临床护理和临床研究提供最终价值，同时保持人们对其数据的控制和流程中的信任。整个PGD集成管道的数据和元数据标准化对于确保设备不相关、模块化、灵活、多用途，从而低成本集成到临床工作流程中至关重要。PGD数据有效集成的价值将增加收入流，减少开销，提高数据完整性，促进患者信任。提供基于标准的PGD集成的PGD聚合服务在从今天的摩擦严重的数据生态系统过渡到我们的患者应得的低摩擦互操作系统的过程中发挥着至关重要的作用。负责远程监测和其他PGD项目的卫生领导应该寻求并采用基于流水线的方法，将PGD标准化地整合到临床护理中。