用于远程健康监测和与医疗保健系统的集成

描述

它是什么

该概念验证展示了如何制造低成本设备，用于远程健康监测和与医疗保健系统的集成。预期的应用是：

• 对高危患者进行临时远程监控，例如疑似 COVID-19 感染。
• 用于大型医院住院患者的可穿戴无线监视器，由于墙壁厚且面积大，现有无线覆盖（wifi、蓝牙）不可靠。低能耗设备通过与现有医院电子健康记录系统 (EHR) 的数据集成，为持续监测患者提供了新的机会。
• 无需传统的有线或无线基础设施即可对居住在疗养院的患者进行生命体征监测。与现有市政或初级健康记录系统的数据集成。
• 无需安装网络基础设施即可对居家护理患者进行医疗和安全监控。城市和全国的低功耗广域网覆盖消除了现有的家庭健康监测限制。

这与其他 COVID-19 检测解决方案有何不同

在最近的黑客马拉松中，许多项目都专注于通过测量 SPO2、心率、温度等来检测 COVID-19 症状。该项目为如何将这些数据提供给医疗保健提供者提供了一个实用的解决方案，以便可以采取适当的措施。这些设备可以使用相同的电池运行数月。

怀疑感染 COVID-19 的患者可以通过互联网或电话联系当地卫生服务机构，并在第二天通过邮件发送设备。然后，患者将定期使用该设备，并将测量结果直接发送到她的电子健康记录中，直到她被认为健康或需要医疗护理。

借助 LoRaWAN，可以以目前可用的最低投资覆盖城市和整个国家。一个 300 欧元的网关可以覆盖 10 多公里的半径，在农村地区可以覆盖 20 多公里。我帮助我的家乡与只有几个网关的爱好者一起报道了我的家乡。

我相信一个开放的、社区构建的网络，例如The Things Network 。与数千个单独的专用网络相比，这种可能性是无与伦比的。还有其他用于构建专用网络的选项，例如使用The Things Industries Enterprise或其他完全自定义的实现。

我的背景

自 2004 年以来，我一直是北欧主要电子医疗记录系统的系统开发人员。我后来的特别兴趣是物联网和低功耗、远程设备可以为远程医疗做什么。这些都是我自己的观点和作品。

问题

整合：仅在一个国家，您就会发现数百个不同的医疗保健系统，涵盖私立和国立医院、初级保健诊所和市政服务，例如家庭护理、儿童/家庭健康诊所，以及众多不同类型的专科诊所。由于健康相关领域众多、复杂性和组织差异，这些系统和机构之间的医疗记录交换通常落后于其他行业。再加上跨越各国医疗保健语言、文化和传统的复杂性，很快就会发现，创建将传感器数据映射到每个其他医疗保健系统的临床数据结构的自定义集成是一项不可能完成的任务。

沟通：容易获得或提出的解决方案都依赖于对设备的实用性施加很大限制的通信技术。如果设备的使用寿命超过几天，则 Wifi 需要比电子设备本身更大的电池。该范围降低了室内应用的可用性，即使在医院内，基础设施也很复杂、成本很高，而且覆盖率通常不是 100%。不过，最大的担忧是如何处理 wifi 凭据。我没有看到适用于少数几个已知网络的解决方案，并且通常根本不处理离线管理。蓝牙/BLE 是对电池节省的巨大改进，但对范围的严格限制会减少与手机配对的使用。这种配对适用于拥有此类手机的世界人口中的低比例，但它在医疗机构环境中不起作用。医生根本无法监控诊所或医院中不断涌现的患者，更不用说以这种方式进行家庭护理了。

电池寿命：医疗保健提供者依靠大量不同的便携式设备来监测患者的生命体征。例如体温计、心率监测器、心电图监测器、数字血压计等等。他们中的大多数人的共同点是它们在大量使用时可靠，并且可以持续数月而无需充电或更换电池。然而，它们不与任何电子医疗记录系统连接，并且依赖于将测量值写入笔记或以活页夹的形式写入医疗图表。测量结果通常会以口头方式传达，直到护士轮班结束，然后最终将其输入电子记录。连接的设备必须相对于未连接的设备持续使用。

解决方案

一体化：

幸运的是，在过去十年中，人们在创建可用于模拟临床事件、测量、诊断和资源的标准方面付出了巨大的努力。这些标准有不同的目标：

• 相似和不同的医疗保健系统之间的互操作性
• 系统内临床数据的结构化和动态持久性

这个概念验证的目的是展示创建新设备的能力，这些设备依赖于这些标准来与已建立的系统交换测量值，而不是比较标准。我个人认为，在紧迫的情况下，最好选择一个标准，而不是依赖每个系统的自定义集成。如果需要，从一个标准映射到另一个标准更容易实现。在这个项目中，我专注于openEHR和快速医疗保健互操作性资源 ( FHIR )

通信：LoRaWAN 已被确立为远程、低功耗传感器应用的实用、低成本和独立替代方案。Combined with an appropriate selection of microcontrollers, sensors, actuators and displays battery life of months and years is achievable. NB-IoT 是此应用程序的另一个合适选择，您可以查看我之前的项目进行比较。这个 PoC 的整体架构与通信的选择无关，我认为应该为各个应用程序选择正确的工具。

电池寿命：为了实现数月或数年的电池寿命，我为这个项目精心选择了组件：

• 具有超低电流消耗的微控制器。
• lpwan（LoRaWAN 或 NB-IoT）作为数据载体。
• 低电流消耗的传感器。本项目中使用的 MAX30101 是一个不错的选择，分线只是为了便于原型设计。该项目可能会使用更多的节能传感器进行发展。
• eInk 显示在更新之间不消耗电流。显示将在使用之间保持不变。

服务架构

只要流量低，该项目中使用的所有服务都可以免费使用。我认为您可以在免费层中部署足够的设备来执行有价值的测试。

服务的架构和选择是以下要求和所需功能的结果：

• lpwan-agnostic：到目前为止，我已经构建了依赖 LoRaWAN、NB-IoT 和 Wifi 的设备。随着技术的发展，我希望对新型通信尽可能开放。
• 可扩展性：我希望能够尽可能多地改变系统的行为，而不需要大量的开发周期。某些部件不太可能需要更改，并且可以针对速度和低资源要求进行优化。
• 最终用户定制：允许预期的医疗机构定制视图、规则和未来的扩展使用。这将是诊所和医院的 IT 管理员。实际的最终用户、临床医生不需要知道来自设备的数据是如何进入电子医疗记录的。
• Azure IoT Central：我已经使用 Azure IoT Hub 几年了。Azure IoT Central 建立在此之上，我想使用这个项目来看看我能在多大程度上利用这个很好的抽象来解决所提出的问题。这可以通过隐藏有关 IoT 中心、分析等的许多复杂性来加快实施时间。
• 与技术无关的集成：尽可能依赖 REST/JSON、gRPC/Protocol Buffers、MQTT、OAuth 等标准与每个外部医疗保健系统集成。这将为尽可能多的系统类型提供最佳选择，并始终为不支持这些标准的遗留系统提供中间集成。

申请流程

这将是为该项目迭代制作的设备中的标准流程：

1. 设备通过 LoRaWAN 进行身份验证并将测量结果发送到物联网 (TTN)。

2. TTN 应用程序将数据转换为结构化消息并调用托管在 Azure 中的 webhook。

3. 托管的 Azure IoT Central 网桥作为 Azure Functions HTTP 触发器（应用服务）运行，并从 TTN 中提取相关信息。然后，此信息将作为消息发布到 Azure IoT Central。

4. 在 IoT Central 中，我可以转换数据并为进一步处理、过滤和规则制作漂亮的模板。从这里我可以为不同类别的设备定义规则，并让新消息触发 webhook 以集成到外部医疗保健系统。

5. webhook 是无服务器 Azure 函数，可将设备消息中的值转换为 openEHR 或 FHIR 格式。然后将这些格式发布到具有特定授权和其他要求的外部电子医疗记录系统。在这个项目中，我使用了一个Google Healthcare API的实例作为一个虚构医院的外部 EHR 示例。

6. 外部 EHR 以 openEHR 或 FHIR 格式接收测量结果并根据需要进行处理。

7. 外部医疗保健提供者的临床医生现在可以在患者记录中找到测量值。

在之前的项目中，我已经演示了如何用 NB-IoT 和一些移动运营商提供的平台代替第 1 点和第 2 点。

第 4 点提出了一种可能性，即提供外部系统可以订阅的 pub/sub 代理，但我尚未对此进行探索。

用于 FHIR 的 Azure API

为什么我没有使用Azure API for FHIR而不是 Google Healthcare API？上次我为 FHIR 设置 Azure API 实例时，我每月分配的 Azure 积分在两周内用完。我认为这是服务流程中的错误。我宁愿在这个项目中同时使用两者，以进一步证明我的观点。由于时间限制和服务器资源使用的不确定性，我选择了安全选项。一旦时间允许，我会进行新的尝试。

openEHR 实例

我还希望演示与 openEHR 界面的集成。我还没有找到免费测试实例的提供者。然而，我计划将此 PoC 与我专业开发的 EHR 系统提供的 openEHR 界面集成。

执行

硬件

物料清单

• 具有 LoRa 无线电的低功耗 Arduino 兼容开发板
• MAX30101或类似的分线器
• 3.6伏电池
• 电子墨水显示屏
• 原型面包板
• 原型跳线

工具

这些是可选的，但对于调试和理解组件之间发生的事情以及优化节能非常方便

• 可靠的非开关实验室电源
• 带串行解码的示波器
• Otii Arc能耗分析仪

原理图

设备代码

该设备的代码可以在存储库中找到。它分为两个文件，其中secrets.h包含 The Things Network 的网络和应用程序密钥。

为了省略将私有凭据添加到源代码存储库，我执行了以下操作：我创建了一个文件 secrets.h 并添加了占位符密钥。然后我提交并将其推送到仓库。此外，我运行了以下命令以忽略进一步的更改：

git update-index --assume-unchanged secrets.h

现在我可以添加真正的密钥，而无需 git 唠叨未分级的更改。当然，现在这些值只存在于您的本地计算机上。我还没有找到一种很好的方式来使用公共存储库，同时仍然保留一些秘密，请提出解决方案。

我不会列出设备的整个 Arduino 代码，而是指出一些感兴趣的领域，并将源代码留给您。

蚱蜢开发板

Grasshopper 是集成 LoRa 无线电的低功耗开发板的不错选择。可在此处找到全面的描述、设置说明、示例代码和订购信息。您可以自己生产 PCB并组装组件。

对于具有平行引脚排列行的 PCB 焊接头，我建议使用面包板进行对齐。只是不要加热引脚太久，否则面包板上的插座会融化。

有关低功耗开发的替代开发板和深入指南，请查看我的邮箱传感器项目。

电子墨水显示屏

一旦我弄清楚接线，显示代码就是一项快速的工作。我在 Adafruit依靠这个出色的指南。为了弄清楚接线，我必须阅读Grasshopper 的原理图才能找到 SPI 引脚。我使用带有 SPI 串行解码功能的示波器来验证我有正确的引脚并且信号看起来在范围内。

 

SPI 解码需要示波器上有 4 个通道。

MAX30101传感器

读取 SPO2 和脉冲传感器基于SparkFun 分线板提供的示例和库。

我不得不移动一个零欧姆 SMD 跳线来将电源从 5v 切换到 3v。一个精细的烙铁头非常有助于实现这一点。

 

 

MAX30101 使用 I2C 进行通信。这需要适当的上拉电阻值。我在以前的指南中介绍了引体向上，请查看它们以获取更多详细信息。通过使用示波器进行实验和测量，我确定了 1k2 欧姆值。

传感器对测量手指的位置和压力​​非常敏感。这就是您会在大多数屏幕截图中看到明显错误读数的原因。为了解决这个问题，必须制作一个固定在手指上的适当外壳。

定制外壳和原型制作的后续步骤

我最近做了一些类似的原型，我决定跳过下一步来创建一个更适合生产的原型。这将涉及从面包板移动到可以安装在 3D 打印外壳内的 PCB 焊接三明治。我不认为我会在这一步中学到足够的知识来证明努力的合理性，而是开始计划创建一个单板 PCB，替换分线器。我还将开始使用 SLA 3D 打印，以创建更接近最终产品的外观更专业的外壳。这将是这个正在进行的项目的下一个阶段。

节电

由于时间限制，我没有完成电源优化的过程。当该设备的电子设备最终确定为单板 PCB 时，我将优化代码并将其共享到存储库中。以下是我以前的项目列表，展示了如何实现数月和数年的电池寿命：

• 邮箱传感器，包括The Things Virtual Conference 2020 研讨会
• 土壤传感器
• 床位占用监视器

请参阅Grasshopper 低功耗使用的具体细节。

服务

物联网

按照本指南在 TTN创建一个新应用程序。我们将假设您拥有现有的 LoRaWAN 覆盖范围或已通过 TTN 设置您自己的网关。注册您的设备，以便您可以访问必要的密钥。我使用 OTAA 作为身份验证方法。

const char *appEui = "70B3D57ED00xxxxx";

const char *appKey = "9F147263E75F162820F6FF8890Bxxxxx";

在 TTN 应用程序中，我们需要定义一个脚本来解码通过 LoRa 从设备传输的字节。在 repo 中找到代码并将其输入到 Payload Formats (Custom) 下。

function Decoder(bytes, port) {

var decoded = {};

if (port === 1)

{

decoded.spo2 = bytes[0];

decoded.hr = bytes[1];

decoded.devtemp = (bytes[2]<<8 | bytes[3])/100;

decoded.voltage = (bytes[4]<<8 | bytes[5])/1000;

}

return decoded;

}

我们将不得不添加一个集成，一个 webhook，它将为在 TTN 中收到的每条消息调用。此 webhook 的 url 是在 Azure IoT Central Bridge for The Things Network 下的步骤中创建的。

Azure 物联网中心

我推荐本指南以运行新的空白 IoT Central 应用程序。

我为我的心率/SPO2 设备创建了一个新模板，并根据需要添加了功能。您可以在 repo 中找到模板并将其导入您自己的应用程序中。

已创建两个云属性以启用用户关联。当发给患者时，设备需要以某种方式连接。对于此 PoC，这是直接在 IoT Central 自定义表单中完成的，但云属性可通过 IoT 中心 API 进行操作。Encounter ID 是 FHIR 数据存储中需要的快捷方式，但会被用于查找最合适的公开遭遇或创建新遭遇的算法替换。患者 ID 是一个 UUID，它将通过社会安全号码或其他标准映射到外部系统中的患者。系统之间的非患者识别 ID 几乎永远不会相同，因此这会带来复杂性。这些问题是我专业工作的很大一部分并且是可以解决的，我选择在这个 PoC 中简化它们。

 

用于物联网的 Azure IoT Central Bridge

一旦 IoT Central 应用程序运行，就可以将其与物联网连接起来。以前我必须从头开始，制作一个 MQTT 客户端，将设备消息转发到 Azure IoT Hub。Microsoft 现在从 repo https://github.com/Azure/iotc-device-bridge提供了一个不错的部署脚本。

在 IoT Central 管理选项卡中找到您的 Scope ID 和 SAS 密钥。

我遇到的唯一问题是，npm install要么似乎已经停止，要么在运行的几个小时内没有完成。在没有错误反馈的情况下，我继续该过程并从负责映射设备消息的 js 脚本中收到了一些奇怪的运行时错误。

因此，请确保npm install报告成功，无论需要多长时间。是的，并确保在运行之前导航到控制台中的正确文件夹！

需要采取更多步骤将来自 TTN 的消息容纳到底层 IoT 中心。本指南解释了您需要做的所有事情。

所有这一切的结果是我们的 TTN 应用程序可以为收到的每条消息调用一个 HTTP 端点。

希望您现在有消息从您的设备通过 TTN 流入 IoT Central。Azure 有很多工具可用于查看指标和错误以找出问题所在。有很多基础需要覆盖，并且根据您的背景，期望花一些时间来学习不同的机制。

使用Pipedream （以前的 RequestBin）作为调试工具来查看您的 webhook 发布的内容并帮助反序列化 JSON 有效负载。

谷歌云医疗 API

最后，我们将在 IoT Central 中创建一个动态规则，将每条消息传递给 Google Healthcare API 的一个实例。我将其用作在医院运行的实际外部电子医疗记录系统的占位符，该系统符合FHIR 。在生产环境中，可以为每个外部系统创建一个规则，或者为每个集成添加一个操作。这是扩展时的实用性问题，而不是此 PoC 的主要焦点。请参阅我之前关于如何创建 Google Healthcare API 实例的文章。

需要填充我们将定位的 FHIR 数据存储。这超出了本文的范围，但存储库包含用于创建患者和遭遇的 PowerShell 脚本，以及列出、创建、修补和删除观察结果。该文档解释了创建身份验证令牌的不同方法。

为了将来自每个设备的消息转换为 FHIR 格式（或 openEHR），我们将创建一个无服务器 Azure Functions。该项目仅支持几种类型的临床观察，扩展这对于简单的传感器来说是微不足道的。我之前关于床位占用传感器的项目演示了如何使用不同类型的资源状态来执行此操作。

为了创建函数，我使用 Visual Studio 和 c#.net core 3 作为语言和运行时。

我们需要一个可以从外部 webhook 调用的 HTTP 触发器。相比之下，IoT 中心触发器是一个函数，它响应 IoT Central 的底层 IoT 中心上发布的消息。编写此函数受益于一点 c# 和 .net 经验或类似经验，但您可能会从 repo 中复制代码并进行试验。

要访问适当的 Google Cloud API，我们需要通过 NuGet 添加依赖项；Google.Apis.CloudHealthcare（在撰写本文时v1beta1，v1似乎是同步的）。

为了被允许调用 Web API，客户端需要一种方法来提供凭据。我在 Google Healthcare 控制台中创建了令牌，下载了 JSON 文件并将其嵌入到项目中。更合适和更安全的方法是将令牌存储在 Azure Key Store 中并让应用程序检索它。IoT Central Bridge 演示了这是如何完成的。该文件显然从 repo 中省略了。

关于 Google Healthcare API 的注意事项

该 API 会自动生成不同风格的编程语言。对于 c#.net 版本，我想我一定是一个早期的适配器，因为基本功能不起作用。ReadRequest、CreateRequest 和 PatchRequest 在官方客户端库中都被破坏了。您可以在我发布在存储库（#1522 、#1595 ）上的问题中找到错误描述和解决方法。

简而言之，为了让 CreateRequest 工作，我最终得到了以下代码：

string parent = $"projects/{ProjectId}/locations/{Location}/datasets/{DatasetId}/fhirStores/{FhirStoreId}";

Data.HttpBody createBody = new Data.HttpBody();

var createRequest =

cloudHealthcareService.Projects.Locations.Datasets.FhirStores.Fhir.Create(createBody, parent, "Observation");

JObject response = createRequest.SendAsJObjectAsync(createBody).Result;

其中 SendAsJObjectAsync 是一个扩展方法：

public static async Task SendAsJObjectAsync(this ClientServiceRequest request, HttpBody requestBody){

var httpRequestMessage = request.CreateRequest();

httpRequestMessage.Content = new StringContent(requestBody.Data);

httpRequestMessage.Content.Headers.ContentType = new MediaTypeHeaderValue("application/fhir+json");

var httpResponseMessage = await request.Service.HttpClient.PostAsync(httpRequestMessage.RequestUri.AbsoluteUri, httpRequestMessage.Content);

httpResponseMessage.EnsureSuccessStatusCode();

var responseText = await httpResponseMessage.Content.ReadAsStringAsync();

return JObject.Parse(responseText);}

部署功能

在最终将其部署到 Azure 之前，我使用Postman和Fiddler开发和调试了整个功能。

获取网址

在 Azure 门户中，您可以找到已部署的 Function 并转到Get Function Url 。

在 Azure IoT Central 规则中添加 webhook 操作

最后，在 IoT Central 中，我们将创建一个适用于 PulseOximeterTemplate 的规则。我将其称为 PulseOximeterIntegrations，因为我计划制定一个规则，每个集成都有多个操作。添加一个Action ，输入Webhook ，然后使用上一步中的 url。请注意，您必须将设备模板的每个属性和遥测数据添加为过滤器和条件。如果不是，它们将不会成为 webhook 中有效负载的一部分。我找不到这个记录，如果这是预期的行为，这似乎有点奇怪。

结果

现在，当设备读取测量值时，它会更新 eInk 显示。在睡觉之前，它还会通过 LoRaWAN 将值发送到 The Things Network。Azure IoT Central Bridge 从 TTN 集成中调用，并将转换后的消息发布到底层 IoT 中心代理。该消息再次在 Azure IoT Central 中转换并显示在不同的视图中。触发规则，包含值的消息通过 webhook 传输到 Azure Functions，每个外部集成一个。这反过来将值转换为 FHIR 消息，并通过 HTTP 调用将其发布到 Google Cloud Healthcare 的实例。我没有时间在 Google Cloud Healthcare 上创建应用程序，但这相当于医院电子医疗记录系统，例如我专业开发的系统。我打算在时间允许的情况下尽快将此 PoC 与该系统集成。与此同时，我已经列出包含来自设备的值和元数据的观察结果的 PowerShell 脚本。

结论

这是一系列有关使用新技术进行远程患者监测的相关项目的下一步。此步骤的目的是完成从远程低功耗设备到模拟医院的临床测量的整个流程。我对结果很满意，并且知道接下来要关注什么。

我没有时间来实现我现有的 openEHR 格式化程序，但您可以在我的第一个使用 Azure Sphere 的患者监视器项目中了解它。

我本来想用一个可以更实际地处理的原型来结束这个阶段，但最后我决定我的时间最好跳过一个步骤，专注于创建一个更集成的电子板，从而能够开始更多的工作。像样的设备，体积更小。

我最初打算添加使用 Streams 将加密测量发布到IOTA Tangle 的功能。这只是另一个 Azure Functions，类似于 Google Healthcare 集成。由于时间限制，Streams处于非常早期的开发阶段，而且我在之前的项目中主要介绍了这一点，因此我决定专注于新的领域，并在稍后再回到这个领域。

它需要对电子医疗保健和远程医疗的当前状态有相当多的了解，才能充分了解此类应用程序的含义。我坚信这是一条将赢得患者和医疗保健提供者的途径。