描述

它是什么

該概念驗證展示了如何制造低成本設備，用于遠程健康監測和與醫療保健系統的集成。預期的應用是：

• 對高危患者進行臨時遠程監控，例如疑似 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處于非常早期的開發階段，而且我在之前的項目中主要介紹了這一點，因此我決定專注于新的領域，并在稍后再回到這個領域。

它需要對電子醫療保健和遠程醫療的當前狀態有相當多的了解，才能充分了解此類應用程序的含義。我堅信這是一條將贏得患者和醫療保健提供者的途徑。