懷疑感染 COVID-19 的患者可以通過互聯(lián)網(wǎng)或電話聯(lián)系當?shù)匦l(wèi)生服務機構(gòu)，并在第二天通過郵件發(fā)送設備。然后，患者將定期使用該設備，并將測量結(jié)果直接發(fā)送到她的電子健康記錄中，直到她被認為健康或需要醫(yī)療護理。

物聯(lián)網(wǎng)世界部署

?

借助 LoRaWAN，可以以目前可用的最低投資覆蓋城市和整個國家。一個 300 歐元的網(wǎng)關可以覆蓋 10 多公里的半徑，在農(nóng)村地區(qū)可以覆蓋 20 多公里。我?guī)椭业募亦l(xiāng)與只有幾個網(wǎng)關的愛好者一起報道了我的家鄉(xiāng)。

LoRaWAN 的低成本物聯(lián)網(wǎng)覆蓋

?

我相信一個開放的、社區(qū)構(gòu)建的網(wǎng)絡，例如The Things Network 。與數(shù)千個單獨的專用網(wǎng)絡相比，這種可能性是無與倫比的。還有其他用于構(gòu)建專用網(wǎng)絡的選項，例如使用The Things Industries Enterprise或其他完全自定義的實現(xiàn)。

我的背景

自 2004 年以來，我一直是北歐主要電子醫(yī)療記錄系統(tǒng)的系統(tǒng)開發(fā)人員。我后來的特別興趣是物聯(lián)網(wǎng)和低功耗、遠程設備可以為遠程醫(yī)療做什么。這些都是我自己的觀點和作品。

問題

整合：僅在一個國家，您就會發(fā)現(xiàn)數(shù)百個不同的醫(yī)療保健系統(tǒng)，涵蓋私立和國立醫(yī)院、初級保健診所和市政服務，例如家庭護理、兒童/家庭健康診所，以及眾多不同類型的專科診所。由于健康相關領域眾多、復雜性和組織差異，這些系統(tǒng)和機構(gòu)之間的醫(yī)療記錄交換通常落后于其他行業(yè)。再加上跨越各國醫(yī)療保健語言、文化和傳統(tǒng)的復雜性，很快就會發(fā)現(xiàn)，創(chuàng)建將傳感器數(shù)據(jù)映射到每個其他醫(yī)療保健系統(tǒng)的臨床數(shù)據(jù)結(jié)構(gòu)的自定義集成是一項不可能完成的任務。

溝通：容易獲得或提出的解決方案都依賴于對設備的實用性施加很大限制的通信技術。如果設備的使用壽命超過幾天，則 Wifi 需要比電子設備本身更大的電池。該范圍降低了室內(nèi)應用的可用性，即使在醫(yī)院內(nèi)，基礎設施也很復雜、成本很高，而且覆蓋率通常不是 100%。不過，最大的擔憂是如何處理 wifi 憑據(jù)。我沒有看到適用于少數(shù)幾個已知網(wǎng)絡的解決方案，并且通常根本不處理離線管理。藍牙/BLE 是對電池節(jié)省的巨大改進，但對范圍的嚴格限制會減少與手機配對的使用。這種配對適用于擁有此類手機的世界人口中的低比例，但它在醫(yī)療機構(gòu)環(huán)境中不起作用。醫(yī)生根本無法監(jiān)控診所或醫(yī)院中不斷涌現(xiàn)的患者，更不用說以這種方式進行家庭護理了。

電池壽命：醫(yī)療保健提供者依靠大量不同的便攜式設備來監(jiān)測患者的生命體征。例如體溫計、心率監(jiān)測器、心電圖監(jiān)測器、數(shù)字血壓計等等。他們中的大多數(shù)人的共同點是它們在大量使用時可靠，并且可以持續(xù)數(shù)月而無需充電或更換電池。然而，它們不與任何電子醫(yī)療記錄系統(tǒng)連接，并且依賴于將測量值寫入筆記或以活頁夾的形式寫入醫(yī)療圖表。測量結(jié)果通常會以口頭方式傳達，直到護士輪班結(jié)束，然后最終將其輸入電子記錄。連接的設備必須相對于未連接的設備持續(xù)使用。

解決方案

設備原型

?

一體化：

幸運的是，在過去十年中，人們在創(chuàng)建可用于模擬臨床事件、測量、診斷和資源的標準方面付出了巨大的努力。這些標準有不同的目標：

• 相似和不同的醫(yī)療保健系統(tǒng)之間的互操作性
• 系統(tǒng)內(nèi)臨床數(shù)據(jù)的結(jié)構(gòu)化和動態(tài)持久性

這個概念驗證的目的是展示創(chuàng)建新設備的能力，這些設備依賴于這些標準來與已建立的系統(tǒng)交換測量值，而不是比較標準。我個人認為，在緊迫的情況下，最好選擇一個標準，而不是依賴每個系統(tǒng)的自定義集成。如果需要，從一個標準映射到另一個標準更容易實現(xiàn)。在這個項目中，我專注于openEHR和快速醫(yī)療保健互操作性資源 ( FHIR )

通信：LoRaWAN 已被確立為遠程、低功耗傳感器應用的實用、低成本和獨立替代方案。Combined with an appropriate selection of microcontrollers, sensors, actuators and displays battery life of months and years is achievable. NB-IoT 是此應用程序的另一個合適選擇，您可以查看我之前的項目進行比較。這個 PoC 的整體架構(gòu)與通信的選擇無關，我認為應該為各個應用程序選擇正確的工具。

電池壽命：為了實現(xiàn)數(shù)月或數(shù)年的電池壽命，我為這個項目精心選擇了組件：

• 具有超低電流消耗的微控制器。
• lpwan（LoRaWAN 或 NB-IoT）作為數(shù)據(jù)載體。
• 低電流消耗的傳感器。本項目中使用的 MAX30101 是一個不錯的選擇，分線只是為了便于原型設計。該項目可能會使用更多的節(jié)能傳感器進行發(fā)展。
• eInk 顯示在更新之間不消耗電流。顯示將在使用之間保持不變。

服務架構(gòu)

只要流量低，該項目中使用的所有服務都可以免費使用。我認為您可以在免費層中部署足夠的設備來執(zhí)行有價值的測試。

服務的架構(gòu)和選擇是以下要求和所需功能的結(jié)果：

• lpwan-agnostic：到目前為止，我已經(jīng)構(gòu)建了依賴 LoRaWAN、NB-IoT 和 Wifi 的設備。隨著技術的發(fā)展，我希望對新型通信盡可能開放。
• 可擴展性：我希望能夠盡可能多地改變系統(tǒng)的行為，而不需要大量的開發(fā)周期。某些部件不太可能需要更改，并且可以針對速度和低資源要求進行優(yōu)化。
• 最終用戶定制：允許預期的醫(yī)療機構(gòu)定制視圖、規(guī)則和未來的擴展使用。這將是診所和醫(yī)院的 IT 管理員。實際的最終用戶、臨床醫(yī)生不需要知道來自設備的數(shù)據(jù)是如何進入電子醫(yī)療記錄的。
• Azure IoT Central：我已經(jīng)使用 Azure IoT Hub 幾年了。Azure IoT Central 建立在此之上，我想使用這個項目來看看我能在多大程度上利用這個很好的抽象來解決所提出的問題。這可以通過隱藏有關 IoT 中心、分析等的許多復雜性來加快實施時間。
• 與技術無關的集成：盡可能依賴 REST/JSON、gRPC/Protocol Buffers、MQTT、OAuth 等標準與每個外部醫(yī)療保健系統(tǒng)集成。這將為盡可能多的系統(tǒng)類型提供最佳選擇，并始終為不支持這些標準的遺留系統(tǒng)提供中間集成。

申請流程

這將是為該項目迭代制作的設備中的標準流程：

1. 設備通過 LoRaWAN 進行身份驗證并將測量結(jié)果發(fā)送到物聯(lián)網(wǎng) (TTN)。

2. TTN 應用程序?qū)?shù)據(jù)轉(zhuǎn)換為結(jié)構(gòu)化消息并調(diào)用托管在 Azure 中的 webhook。

3. 托管的 Azure IoT Central 網(wǎng)橋作為 Azure Functions HTTP 觸發(fā)器（應用服務）運行，并從 TTN 中提取相關信息。然后，此信息將作為消息發(fā)布到 Azure IoT Central。

4. 在 IoT Central 中，我可以轉(zhuǎn)換數(shù)據(jù)并為進一步處理、過濾和規(guī)則制作漂亮的模板。從這里我可以為不同類別的設備定義規(guī)則，并讓新消息觸發(fā) webhook 以集成到外部醫(yī)療保健系統(tǒng)。

5. webhook 是無服務器 Azure 函數(shù)，可將設備消息中的值轉(zhuǎn)換為 openEHR 或 FHIR 格式。然后將這些格式發(fā)布到具有特定授權和其他要求的外部電子醫(yī)療記錄系統(tǒng)。在這個項目中，我使用了一個Google Healthcare API的實例作為一個虛構(gòu)醫(yī)院的外部 EHR 示例。

6. 外部 EHR 以 openEHR 或 FHIR 格式接收測量結(jié)果并根據(jù)需要進行處理。

7. 外部醫(yī)療保健提供者的臨床醫(yī)生現(xiàn)在可以在患者記錄中找到測量值。

在之前的項目中，我已經(jīng)演示了如何用 NB-IoT 和一些移動運營商提供的平臺代替第 1 點和第 2 點。

第 4 點提出了一種可能性，即提供外部系統(tǒng)可以訂閱的 pub/sub 代理，但我尚未對此進行探索。

用于 FHIR 的 Azure API

為什么我沒有使用Azure API for FHIR而不是 Google Healthcare API？上次我為 FHIR 設置 Azure API 實例時，我每月分配的 Azure 積分在兩周內(nèi)用完。我認為這是服務流程中的錯誤。我寧愿在這個項目中同時使用兩者，以進一步證明我的觀點。由于時間限制和服務器資源使用的不確定性，我選擇了安全選項。一旦時間允許，我會進行新的嘗試。

用于 FHIR 的 Azure API

?

openEHR 實例

我還希望演示與 openEHR 界面的集成。我還沒有找到免費測試實例的提供者。然而，我計劃將此 PoC 與我專業(yè)開發(fā)的 EHR 系統(tǒng)提供的 openEHR 界面集成。

執(zhí)行

硬件

物料清單

• 具有 LoRa 無線電的低功耗 Arduino 兼容開發(fā)板
• MAX30101或類似的分線器
• 3.6伏電池
• 電子墨水顯示屏
• 原型面包板
• 原型跳線

工具

這些是可選的，但對于調(diào)試和理解組件之間發(fā)生的事情以及優(yōu)化節(jié)能非常方便

• 可靠的非開關實驗室電源
• 帶串行解碼的示波器
• Otii Arc能耗分析儀

原理圖

原理圖

?

設備代碼

該設備的代碼可以在存儲庫中找到。它分為兩個文件，其中secrets.h包含 The Things Network 的網(wǎng)絡和應用程序密鑰。

為了省略將私有憑據(jù)添加到源代碼存儲庫，我執(zhí)行了以下操作：我創(chuàng)建了一個文件 secrets.h 并添加了占位符密鑰。然后我提交并將其推送到倉庫。此外，我運行了以下命令以忽略進一步的更改：

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

現(xiàn)在我可以添加真正的密鑰，而無需 git 嘮叨未分級的更改。當然，現(xiàn)在這些值只存在于您的本地計算機上。我還沒有找到一種很好的方式來使用公共存儲庫，同時仍然保留一些秘密，請?zhí)岢鼋鉀Q方案。

我不會列出設備的整個 Arduino 代碼，而是指出一些感興趣的領域，并將源代碼留給您。

蚱蜢開發(fā)板

Grasshopper 是集成 LoRa 無線電的低功耗開發(fā)板的不錯選擇。可在此處找到全面的描述、設置說明、示例代碼和訂購信息。您可以自己生產(chǎn) PCB并組裝組件。

面包板有助于在焊接過程中對齊排針

?

對于具有平行引腳排列行的 PCB 焊接頭，我建議使用面包板進行對齊。只是不要加熱引腳太久，否則面包板上的插座會融化。

優(yōu)質(zhì)的焊臺讓焊接成為一種有趣的體驗

?

有關低功耗開發(fā)的替代開發(fā)板和深入指南，請查看我的郵箱傳感器項目。

電子墨水顯示屏

一旦我弄清楚接線，顯示代碼就是一項快速的工作。我在 Adafruit依靠這個出色的指南。為了弄清楚接線，我必須閱讀Grasshopper 的原理圖才能找到 SPI 引腳。我使用帶有 SPI 串行解碼功能的示波器來驗證我有正確的引腳并且信號看起來在范圍內(nèi)。

SPI串行解碼

?

?

SPI解碼

?

SPI 解碼需要示波器上有 4 個通道。

MAX30101傳感器

讀取 SPO2 和脈沖傳感器基于SparkFun 分線板提供的示例和庫。

我不得不移動一個零歐姆 SMD 跳線來將電源從 5v 切換到 3v。一個精細的烙鐵頭非常有助于實現(xiàn)這一點。

跳線設置為 5 伏

?

?

烙鐵頭

?

?

跳線設置為 3 伏

?

MAX30101 使用 I2C 進行通信。這需要適當?shù)纳侠?a target='_blank' class='arckwlink_none'>電阻值。我在以前的指南中介紹了引體向上，請查看它們以獲取更多詳細信息。通過使用示波器進行實驗和測量，我確定了 1k2 歐姆值。

上拉電阻

?

傳感器對測量手指的位置和壓力??非常敏感。這就是您會在大多數(shù)屏幕截圖中看到明顯錯誤讀數(shù)的原因。為了解決這個問題，必須制作一個固定在手指上的適當外殼。

定制外殼和原型制作的后續(xù)步驟

我最近做了一些類似的原型，我決定跳過下一步來創(chuàng)建一個更適合生產(chǎn)的原型。這將涉及從面包板移動到可以安裝在 3D 打印外殼內(nèi)的 PCB 焊接三明治。我不認為我會在這一步中學到足夠的知識來證明努力的合理性，而是開始計劃創(chuàng)建一個單板 PCB，替換分線器。我還將開始使用 SLA 3D 打印，以創(chuàng)建更接近最終產(chǎn)品的外觀更專業(yè)的外殼。這將是這個正在進行的項目的下一個階段。

節(jié)電

由于時間限制，我沒有完成電源優(yōu)化的過程。當該設備的電子設備最終確定為單板 PCB 時，我將優(yōu)化代碼并將其共享到存儲庫中。以下是我以前的項目列表，展示了如何實現(xiàn)數(shù)月和數(shù)年的電池壽命：

• 郵箱傳感器，包括The Things Virtual Conference 2020 研討會
• 土壤傳感器
• 床位占用監(jiān)視器

請參閱Grasshopper 低功耗使用的具體細節(jié)。

服務

物聯(lián)網(wǎng)

按照本指南在 TTN創(chuàng)建一個新應用程序。我們將假設您擁有現(xiàn)有的 LoRaWAN 覆蓋范圍或已通過 TTN 設置您自己的網(wǎng)關。注冊您的設備，以便您可以訪問必要的密鑰。我使用 OTAA 作為身份驗證方法。

const char *appEui = "70B3D57ED00xxxxx";

const char *appKey = "9F147263E75F162820F6FF8890Bxxxxx";

物聯(lián)網(wǎng)設備

?

在 TTN 應用程序中，我們需要定義一個腳本來解碼通過 LoRa 從設備傳輸?shù)淖止?jié)。在 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 中收到的每條消息調(diào)用。此 webhook 的 url 是在 Azure IoT Central Bridge for The Things Network 下的步驟中創(chuàng)建的。

Azure 物聯(lián)網(wǎng)中心

我推薦本指南以運行新的空白 IoT Central 應用程序。

創(chuàng)建 Azure IoT Central 應用程序

?

我為我的心率/SPO2 設備創(chuàng)建了一個新模板，并根據(jù)需要添加了功能。您可以在 repo 中找到模板并將其導入您自己的應用程序中。

適用于 HR 和 SPO2 的 IoT Central 模板

?

已創(chuàng)建兩個云屬性以啟用用戶關聯(lián)。當發(fā)給患者時，設備需要以某種方式連接。對于此 PoC，這是直接在 IoT Central 自定義表單中完成的，但云屬性可通過 IoT 中心 API 進行操作。Encounter ID 是 FHIR 數(shù)據(jù)存儲中需要的快捷方式，但會被用于查找最合適的公開遭遇或創(chuàng)建新遭遇的算法替換。患者 ID 是一個 UUID，它將通過社會安全號碼或其他標準映射到外部系統(tǒng)中的患者。系統(tǒng)之間的非患者識別 ID 幾乎永遠不會相同，因此這會帶來復雜性。這些問題是我專業(yè)工作的很大一部分并且是可以解決的，我選擇在這個 PoC 中簡化它們。

每個設備的云設置

?

?

原始設備數(shù)據(jù)

?

用于物聯(lián)網(wǎng)的 Azure IoT Central Bridge

一旦 IoT Central 應用程序運行，就可以將其與物聯(lián)網(wǎng)連接起來。以前我必須從頭開始，制作一個 MQTT 客戶端，將設備消息轉(zhuǎn)發(fā)到 Azure IoT Hub。Microsoft 現(xiàn)在從 repo https://github.com/Azure/iotc-device-bridge提供了一個不錯的部署腳本。

Azure IoT Central 設備橋

?

Bridge 的部署模板

?

在 IoT Central 管理選項卡中找到您的 Scope ID 和 SAS 密鑰。

來自 IoT Central 應用程序的憑據(jù)

?

我遇到的唯一問題是，npm install要么似乎已經(jīng)停止，要么在運行的幾個小時內(nèi)沒有完成。在沒有錯誤反饋的情況下，我繼續(xù)該過程并從負責映射設備消息的 js 腳本中收到了一些奇怪的運行時錯誤。

?

因此，請確保npm install報告成功，無論需要多長時間。是的，并確保在運行之前導航到控制臺中的正確文件夾！

npm 安裝

?

需要采取更多步驟將來自 TTN 的消息容納到底層 IoT 中心。本指南解釋了您需要做的所有事情。

所有這一切的結(jié)果是我們的 TTN 應用程序可以為收到的每條消息調(diào)用一個 HTTP 端點。

網(wǎng)絡鉤子

?

希望您現(xiàn)在有消息從您的設備通過 TTN 流入 IoT Central。Azure 有很多工具可用于查看指標和錯誤以找出問題所在。有很多基礎需要覆蓋，并且根據(jù)您的背景，期望花一些時間來學習不同的機制。

使用Pipedream （以前的 RequestBin）作為調(diào)試工具來查看您的 webhook 發(fā)布的內(nèi)容并幫助反序列化 JSON 有效負載。

Pipedream 作為用于調(diào)試的 HTTP 端點

?

谷歌云醫(yī)療 API

最后，我們將在 IoT Central 中創(chuàng)建一個動態(tài)規(guī)則，將每條消息傳遞給 Google Healthcare API 的一個實例。我將其用作在醫(yī)院運行的實際外部電子醫(yī)療記錄系統(tǒng)的占位符，該系統(tǒng)符合FHIR 。在生產(chǎn)環(huán)境中，可以為每個外部系統(tǒng)創(chuàng)建一個規(guī)則，或者為每個集成添加一個操作。這是擴展時的實用性問題，而不是此 PoC 的主要焦點。請參閱我之前關于如何創(chuàng)建 Google Healthcare API 實例的文章。

需要填充我們將定位的 FHIR 數(shù)據(jù)存儲。這超出了本文的范圍，但存儲庫包含用于創(chuàng)建患者和遭遇的 PowerShell 腳本，以及列出、創(chuàng)建、修補和刪除觀察結(jié)果。該文檔解釋了創(chuàng)建身份驗證令牌的不同方法。

谷歌云醫(yī)療 API

?

為了將來自每個設備的消息轉(zhuǎn)換為 FHIR 格式（或 openEHR），我們將創(chuàng)建一個無服務器 Azure Functions。該項目僅支持幾種類型的臨床觀察，擴展這對于簡單的傳感器來說是微不足道的。我之前關于床位占用傳感器的項目演示了如何使用不同類型的資源狀態(tài)來執(zhí)行此操作。

為了創(chuàng)建函數(shù)，我使用 Visual Studio 和 c#.net core 3 作為語言和運行時。

Azure Functions HTTP 觸發(fā)器

?

我們需要一個可以從外部 webhook 調(diào)用的 HTTP 觸發(fā)器。相比之下，IoT 中心觸發(fā)器是一個函數(shù)，它響應 IoT Central 的底層 IoT 中心上發(fā)布的消息。編寫此函數(shù)受益于一點 c# 和 .net 經(jīng)驗或類似經(jīng)驗，但您可能會從 repo 中復制代碼并進行試驗。

項目依賴

?

要訪問適當?shù)?Google Cloud API，我們需要通過 NuGet 添加依賴項；Google.Apis.CloudHealthcare（在撰寫本文時v1beta1，v1似乎是同步的）。

為了被允許調(diào)用 Web API，客戶端需要一種方法來提供憑據(jù)。我在 Google Healthcare 控制臺中創(chuàng)建了令牌，下載了 JSON 文件并將其嵌入到項目中。更合適和更安全的方法是將令牌存儲在 Azure Key Store 中并讓應用程序檢索它。IoT Central Bridge 演示了這是如何完成的。該文件顯然從 repo 中省略了。

關于 Google Healthcare API 的注意事項

該 API 會自動生成不同風格的編程語言。對于 c#.net 版本，我想我一定是一個早期的適配器，因為基本功能不起作用。ReadRequest、CreateRequest 和 PatchRequest 在官方客戶端庫中都被破壞了。您可以在我發(fā)布在存儲庫（#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開發(fā)和調(diào)試了整個功能。

發(fā)布 Azure 函數(shù)

?

獲取網(wǎng)址

在 Azure 門戶中，您可以找到已部署的 Function 并轉(zhuǎn)到Get Function Url 。

獲取函數(shù)地址

?

在 Azure IoT Central 規(guī)則中添加 webhook 操作

最后，在 IoT Central 中，我們將創(chuàng)建一個適用于 PulseOximeterTemplate 的規(guī)則。我將其稱為 PulseOximeterIntegrations，因為我計劃制定一個規(guī)則，每個集成都有多個操作。添加一個Action ，輸入Webhook ，然后使用上一步中的 url。請注意，您必須將設備模板的每個屬性和遙測數(shù)據(jù)添加為過濾器和條件。如果不是，它們將不會成為 webhook 中有效負載的一部分。我找不到這個記錄，如果這是預期的行為，這似乎有點奇怪。

結(jié)果

現(xiàn)在，當設備讀取測量值時，它會更新 eInk 顯示。在睡覺之前，它還會通過 LoRaWAN 將值發(fā)送到 The Things Network。Azure IoT Central Bridge 從 TTN 集成中調(diào)用，并將轉(zhuǎn)換后的消息發(fā)布到底層 IoT 中心代理。該消息再次在 Azure IoT Central 中轉(zhuǎn)換并顯示在不同的視圖中。觸發(fā)規(guī)則，包含值的消息通過 webhook 傳輸?shù)?Azure Functions，每個外部集成一個。這反過來將值轉(zhuǎn)換為 FHIR 消息，并通過 HTTP 調(diào)用將其發(fā)布到 Google Cloud Healthcare 的實例。我沒有時間在 Google Cloud Healthcare 上創(chuàng)建應用程序，但這相當于醫(yī)院電子醫(yī)療記錄系統(tǒng)，例如我專業(yè)開發(fā)的系統(tǒng)。我打算在時間允許的情況下盡快將此 PoC 與該系統(tǒng)集成。與此同時，我已經(jīng)列出包含來自設備的值和元數(shù)據(jù)的觀察結(jié)果的 PowerShell 腳本。

完成概念驗證

?

結(jié)論

這是一系列有關使用新技術進行遠程患者監(jiān)測的相關項目的下一步。此步驟的目的是完成從遠程低功耗設備到模擬醫(yī)院的臨床測量的整個流程。我對結(jié)果很滿意，并且知道接下來要關注什么。

我沒有時間來實現(xiàn)我現(xiàn)有的 openEHR 格式化程序，但您可以在我的第一個使用 Azure Sphere 的患者監(jiān)視器項目中了解它。

我本來想用一個可以更實際地處理的原型來結(jié)束這個階段，但最后我決定我的時間最好跳過一個步驟，專注于創(chuàng)建一個更集成的電子板，從而能夠開始更多的工作。像樣的設備，體積更小。

我最初打算添加使用 Streams 將加密測量發(fā)布到IOTA Tangle 的功能。這只是另一個 Azure Functions，類似于 Google Healthcare 集成。由于時間限制，Streams處于非常早期的開發(fā)階段，而且我在之前的項目中主要介紹了這一點，因此我決定專注于新的領域，并在稍后再回到這個領域。

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