编辑

通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

远程患者监控

Azure Data Lake Storage
Azure Databricks
Azure 事件中心
Azure 机器学习
Azure Synapse Analytics
Power BI

医疗系统、医院和大型医师诊所正朝着居家医疗计划（也称为远程患者监控）的方向转变。 远程患者监控属于临床护理的一部分，通过此方法，可以根据个性化护理计划参数使用远程健康设备访问并传送患者活动和生理数据。

本文介绍如何设计一种使用 Azure Health Data Services 和设备来实现智能远程患者监控的解决方案。 该解决方案将有助于缓和组织在大规模构建此类解决方案时必须面对的诸多设备集成挑战。

体系结构

使用医疗保健设备和 Azure 服务的远程患者监控体系结构示意图。

下载此体系结构的 Visio 文件。

数据流

  1. 患者设备生成活动和生理数据。 然后，使用可用的 Microsoft 开源 (OSS) SDK 之一从设备中提取数据，并通过 Azure 事件中心引入。

  2. Life365.health 平台支持 300 多种可生成活动和生理数据的设备。Life365 API 将患者监控设备中的活动和生理数据引入 Azure 事件中心。

  3. Azure 医疗技术服务从事件中心拉取设备测量值，将其转换为 FHIR 格式（快速医疗保健互操作性资源 (FHIR®)），然后将其传递到 Azure FHIR 服务。 Azure Health Data Services 工作区是医疗保健服务实例（例如 FHIR 和医疗技术服务）的逻辑容器。

  4. 在 Azure FHIR 服务中创建、更新或删除 FHIR 资源时，Azure Health Data Services 工作区向事件订阅者发送通知消息。 通知可以发送到多个终结点来触发自动化，包括启动工作流或发送电子邮件和短信。

  5. FHIR 分析管道以增量方式将未进行匿名化处理的 FHIR 数据导出到 Azure Data Lake，使其可供各种 Azure 数据服务进行分析。 也可利用相应工具（例如 Microsoft 开源健康数据匿名化工具）对导出的数据进行匿名化处理。 默认根据 HIPAA 安全港方法进行匿名化处理，你可以视需要对该方法进行延伸和修改。

    重要

    此数据流中导出的 FHIR 数据是原始数据，其中包括 PHI 信息。 去标识化过程可用于从数据中移除个人标识符，从而将数据用于研究或共享目的。 如果需要去标识化的数据集，则必须在导出数据之前使用上述工具采取措施来对数据进行匿名化处理。

  6. 使用 Azure Synapse、Azure Databricks 和 Azure 机器学习 (ML) 服务中的 Spark 池进一步分析 Parquet 和 JSON 格式的 FHIR 数据。

  7. 在 Azure Synapse 的无服务器 SQL 池中创建 SQL 视图。 根据 Azure Data Lake 中的 Parquet 文件为每项 FHIR 资源创建 SQL 视图。 根据这些视图，数据工程师和开发人员可以在 Microsoft SQL Management Studio 或任何其他 SQL 编辑器中编写本机 SQL 来查询 FHIR 资源。

  8. 使用 Power BI 和适用于 FHIR 的 Power Query 连接器直接从 FHIR 服务 API 终结点导入数据并为数据构形。 Power BI 还提供 Parquet 和 SQL 连接器，用于直接以 Parquet 格式或通过 Synapse 中的 SQL 视图访问 FHIR 资源。

组件

设备

消费级设备

Microsoft 提供各种开源 SDK，用于从各种消费级设备传输数据，再通过 Azure 事件中心引入数据：

支持 Life365.health 的医疗设备

Life365.health 平台可与 300 多种蓝牙监控设备集成，以便通过 Azure 事件中心引入数据。 这些设备涵盖多种类别和多家 OEM，从肺活量计、温度计、体重计、服药提醒器，到活动跟踪器、血糖仪、血压计、EKG/ECG、胎心仪、心率监视器、脉搏血氧仪、睡眠追踪器，不一而足。 Life365 应用还支持手动记录从非蓝牙设备获取的读数。 此体系结构利用 Life365 API 将设备测量值从 Life365 设备引入事件中心。

其他

虽然上述选项有助于简化操作，但此体系结构支持任何可通过中间 API 直接或间接地安全引入到事件中心的类似数据源。

Azure 服务（数据收集和存储）

  • Azure 事件中心 - 一种完全托管的实时数据引入服务，它简单、可靠、可缩放。 每秒从任何源流式传输数百万个事件，以生成动态数据管道，并立即响应业务挑战。 在此体系结构中，它用于收集和汇总设备数据，继而将数据传输到 Azure Health Data Services。

  • Azure Health Data Services 是一组基于开放标准和框架的托管 API 服务，它们支持用于改进医疗保健的工作流，还提供可缩放的安全医疗保健解决方案。 此示例体系结构中使用的服务包括：

    • Azure Health Data Services 工作区 - 为其他 Azure Health Data Services 实例提供一个容器，从而创建可在其中传输受保护的健康信息的合规性边界 (HIPAA、HITRUST)。

    • Azure FHIR 服务 - 便于在云中安全地存储和交换受保护的健康状况信息 (PHI)。 设备数据转换为基于 FHIR 的观测资源，用于支持远程患者监控。

    • Azure 医疗技术服务 - Microsoft Cloud for Healthcare 的基石，用于支持远程患者监控。 MedTech 是一种平台即服务 (PaaS)，使你能够收集各种医疗设备中的准实时数据，并将其转换为符合 FHIR 的服务格式，然后将其存储在 FHIR 服务中。 借助医疗技术服务的设备数据转换功能，可以将各种数据转换为统一的 FHIR 格式，从而在云环境中提供安全的健康数据管理。

      医疗技术服务对于远程患者监控非常重要，因为医疗保健数据在来自不同或不兼容的设备、系统或格式时，可能难以访问或分析。 医疗信息不易于访问可能会阻碍临床见解和患者医疗保健计划的获取。 将健康数据统一转换为 FHIR 格式的功能使医疗技术服务得以成功链接设备、健康数据、实验室和远程面对面护理。 因此，此功能有助于发现重要的临床见解并捕获趋势，从而为临床医生、护理团队、患者和家庭提供支持。 它还可以帮助连接到新设备应用程序，并支持高级研究项目。 正如可以根据使用场景制定个性化的护理计划，远程患者监控方案和使用场景也因个性化需求而异。

  • Azure 事件网格 - 每当创建、更新或删除 (CUD) FHIR 资源时，Azure Health Data Services 事件服务都会生成事件。 这些事件可通过 Azure 事件网格播发到下游使用者，以处理基于事件的数据。

Azure 服务和工具（数据分析）

  • FHIR 分析管道 - 一个用于生成组件和管道 OSS 项目，这些组件和管道用于将 FHIR 数据矩形化并将其从 Azure FHIR 服务器移动到 Azure Data Lake。 在此体系结构中，数据被转换为 JavaScript 对象表示法 (JSON) 和 Parquet 格式，供各种 Azure 数据服务进行分析。

  • 健康数据匿名化工具 - 由 Microsoft 医疗保健团队提供支持的 OSS 项目可帮助对本地或云中的医疗保健数据进行匿名化处理，以用于研究和公共卫生等二次用途。 匿名化核心引擎使用配置文件为不同的数据元素和数据类型指定不同的参数以及匿名化方法。

  • Azure Synapse Analytics - 一种无限制的分析服务，可将数据集成、企业数据仓库和大数据分析结合在一起。 借助它可使用无服务器或专用选项，根据自己的情况随意大规模查询数据。 Azure Synapse 将这些领域结合在一起，以统一的体验引入、探索、准备、转换、管理和提供数据，来满足即时 BI 和机器学习的需求。

  • Apache Spark 池 - Apache Spark 是并行处理框架，支持使用内存中处理来提升大数据分析应用程序的性能。 Azure Synapse Analytics 中的 Apache Spark 是 Apache Spark 在云中的一种 Microsoft 实现。 使用 Azure Synapse 可以在 Azure 中轻松创建和配置无服务器 Apache Spark 池。 Azure Synapse 中的 Spark 池与 Azure 存储和 Azure Data Lake Generation 2 存储兼容。 因此，可以使用 Spark 池来处理 Azure 中存储的数据。

  • Azure Databricks - 已针对 Microsoft Azure 云服务平台进行优化的数据分析平台。 Databricks 为数据分析师、数据工程师、数据科学家以及机器学习工程师提供一个统一的分析平台。 提供了三种环境用于开发数据密集型应用程序：Databricks SQL、Databricks Data Science & 工程和 Databricks 机器学习。

  • Azure ML - 一种用于加速和管理机器学习项目生命周期的 Azure 云服务。 机器学习专业人员、数据科学家和工程师可以在日常工作流中使用它：训练和部署模型，以及管理 MLOps。 可以在 Azure 机器学习中创建模型，也可以使用从开源平台构建的模型，例如 Pytorch、TensorFlow 或 scikit-learn。 MLOps 工具有助于监控、重新训练和重新部署模型。

  • Power BI - 提供企业级自助式分析，使你能够：

    • 使用商业智能为所有人打造数据驱动型文化。
    • 使用行业领先的数据安全功能（包括敏感度标签、端到端加密和实时访问监控）确保数据安全，以便进一步分析 FHIR 数据。

  • 与 Power BI 一起使用的 Power Query 连接器包括：

  • SQL Server Management Studio - 一个桌面应用，用于针对 SQL 数据存储（例如 Azure Synapse Analytics SQL 池）创建本机 SQL 查询。

备选方法

Life365.health

Life365.health 的优势在于，通过一个集成点，你就可以将 Life365 生态系统中各种设备的测量值推送到 Azure Health Data Services 中。 还有其他可穿戴设备 API（例如 Garmin Activity API 和 Polar AccessLink API），你可以为其实现类似的集成模式。 但是，这些 API 仅适用于由它们自己的制造商（例如，分别是 Garmin 和 Polar）的设备测量的值。

需要在 Azure Health Data Services 和 Life365 API 之间定义、链接和同步设备和患者。 可以通过在 Azure Health Data Services 和 Life365 API 之间同步患者和设备 ID 来实现此配置。 从本质上讲，首先在 Azure FHIR 服务中创建并链接新的患者和设备。 然后，在 Life365 API 中创建并链接相应的患者和设备。 起初在 Azure Health Data Services 中创建的患者和设备的 ID 随后将在 Life365 API 中的相应患者和设备实体中更新为外部 ID。

Microsoft Cloud for Healthcare

这个示例工作负载提到了一种实现远程患者监控解决方案的方式。 Microsoft Cloud for Healthcare 还提供远程患者监控解决方案。 有关该解决方案的更多信息，请参阅远程患者监控指导教程。

方案详细信息

如今有大量医疗和可穿戴/消费级设备。 为了访问设备测量值/读数，许多家用式监控设备（如血压设备或体重计等）都提供蓝牙连接（例如蓝牙低功耗或其他旧版蓝牙标准）。 还有消费级可穿戴设备和更先进的家用式设备，它们提供 API 连接来访问设备测量值。 在这种情况下，这些设备可将读数直接同步到 API（已启用 Wifi），或者（通过蓝牙）连接到智能手机上的移动应用，使应用能够将读数同步回 API。

问题陈述

鉴于可穿戴设备和医疗设备和连接选项（从蓝牙到 API 规范）种类繁多，加之医疗保健组织内的患者数量庞大，数据集成和编排可能是项艰巨的任务。

可能的用例

  • 临床试验与研究 - 帮助临床研究团队整合并向研究参与者提供广泛的家用式和可穿戴医疗设备。 换句话说，就是为研究参与者提供一个类似自带设备 (BYOD) 的选项。

  • 数据科学和人口健康分析 - 活动和生理数据将以行业 FHIR 标准格式及其他开源数据格式（JSON 和 Parquet）提供。 除了数据格式之外，还提供本机连接器来帮助进行数据分析和转换。 包括适用于 FHIR 的 Power BI 连接器、Synapse Serverless SQL 视图和 Synapse 中的 Spark 集群。

    此解决方案还提供了一种参数化方法来对数据集进行匿名化处理，以用于去标识化研究目的。 可以分析并使用这种“二次用途数据”来找到最佳做法并为临床循证工作流提供支持。 FHIR 服务器中存储的观测结果可用于找到促使获得最佳结局和做法的差异和工作流。

  • 帮助医疗保健提供商 - 提供商将能够：

    • 更好地了解患者的健康状况
    • 为预防性医疗保健创造积极主动的数字医疗保健模式
    • 根据生理指标/通知采取更明智的行动
    • 提供远程生理监控报销途径

  • 患者报告结局 (PRO) 问卷和 PRO 驱动的护理 - 通过使用事件和 PRO 问卷，可以制定个性化的护理计划和护理差异工作流。 患者可对个性化的护理计划拥有更多自主权和控制权，这有助于采用和持续使用。 PRO 驱动的护理也有助于缩短教育与患者结局之间的差距。 通过将教育问卷和 PRO 相关联，RPM 可以通过回答以下问题来为药物、治疗和/或随访护理提供支持：

    • 患者是否正确测量 BP？
    • 是否在正确的时间以正确的频率使用体重计？
    • 我们是否考虑了 PRO 来帮助患者采用和制定个性化护理计划？

    对于使用 iOS 设备的患者，可以使用 Apple ResearchKit 生成问卷应用。 问卷数据由 Azure 事件中心引入，并通过 FHIR 服务提供，就像设备患者活动和生理数据一样。

  • 支持多种类型和更精确的健康设备 - 使用医用和家用医疗设备以近乎实时的方式生成健康数据，以便进行数据引入和分析。

注意事项

这些注意事项涉及 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。

对许多医疗保健组织来说，提供临床数据和见解非常重要。 下面的方法可将此解决方案中指示的 Azure 服务的故障时间降至最短：

  • 在主要区域中，Data Lake Storage 始终复制三次，可选择选择本地冗余存储 (LRS) 或区域冗余存储 (ZRS)。

  • Azure 事件中心分散了跨数据中心内多个故障域的群集中单个计算机甚至整个机架发生灾难性故障的风险。 有关更多信息，请参阅 Azure 事件中心 - 异地灾难恢复。

  • Databricks 为其数据分析平台提供灾难恢复指南。

  • 机器学习部署可以是多区域的。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。

医疗保健数据通常包括受保护的敏感健康信息 (PHI) 和个人信息。 可使用以下资源来保护此数据：

  • Data Lake Storage 使用 Azure 基于角色的访问控制 (RBAC) 和访问控制列表 (ACL) 来创建访问控制模型

  • Azure Health Data Services 是使用 Microsoft Entra ID（支持 OAuth 2.0 的全球标识提供者）的受保护托管服务的集合。 创建 Azure 健康数据服务的新服务时，默认将使用 Microsoft 管理的密钥来加密你的数据。 有关详细信息，请参阅 Azure Health Data Services 的身份验证和授权。

  • Azure 事件中心提供了通过 Azure 存储服务加密 (SSE) 对静态数据进行加密的功能。 因此，可在事件中心命名空间级别应用 IP 防火墙规则。 还可以配置对专用终结点和虚拟网络的访问。

  • Synapse RBAC 扩展了用于 Synapse 工作区及其内容的 Azure RBAC 功能。 使用 Azure RBAC 可以管理谁可以创建、更新或删除 Synapse 工作区及其 SQL 池、Apache Spark 池和集成运行时。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

可以在 Azure 定价计算器中找到许多 Azure 组件的定价。 最终，此解决方案的定价基于以下因素，比如：

  • 使用的 Azure 服务。
  • 数据量，根据患者/设备的数量以及引入的活动和生理数据类型的数量。
  • 事件中心的容量和吞吐量要求。
  • 执行机器学习训练和部署所需的计算资源：Synapse Spark 池和 Databricks 群集。
  • 可视化和报告解决方案，例如 Power BI。

实现此解决方案时，请考虑基础 Azure Data Lake 的数据保留和存档策略。 利用 Azure 存储生命周期管理来提供自动化方法：

  • 将文件 Blob 向下转换到冷访问层
  • 根据文件的上次修改时间将层存档。

若要详细了解 Life365.health 计划和定价，请查看 Microsoft Azure 市场中的 Life365 API Connect 数据产品/服务

性能效率

性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。

此解决方案提供可缩放的准实时体系结构，用于远程患者监控。 请务必确认多层数据流：从设备和 Life365 API 之间的接口，到通过 Life365 API 和 Azure 事件中心引入，然后在 Azure Health Data Services 的医疗技术服务中进行转换，最后以增量方式导出并匿名化为 Data Lake 格式。 因此，数据流将以近乎实时的方式进行处理，任何下游应用程序和/或集成都应当这样设计。 此解决方案的性能还可进行扩展，能够服务达到企业级规模的大量设备和患者。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

与实现此体系结构相关的技术和资源：