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

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

?

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

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

?

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

我的背景

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

問(wèn)題

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

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

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

解決方案

設(shè)備原型

?

一體化：

幸運(yùn)的是，在過(guò)去十年中，人們?cè)趧?chuàng)建可用于模擬臨床事件、測(cè)量、診斷和資源的標(biāo)準(zhǔn)方面付出了巨大的努力。這些標(biāo)準(zhǔn)有不同的目標(biāo)：

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

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

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

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

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

服務(wù)架構(gòu)

只要流量低，該項(xiàng)目中使用的所有服務(wù)都可以免費(fèi)使用。我認(rèn)為您可以在免費(fèi)層中部署足夠的設(shè)備來(lái)執(zhí)行有價(jià)值的測(cè)試。

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

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

申請(qǐng)流程

這將是為該項(xiàng)目迭代制作的設(shè)備中的標(biāo)準(zhǔn)流程：

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

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

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

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

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

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

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

在之前的項(xiàng)目中，我已經(jīng)演示了如何用 NB-IoT 和一些移動(dòng)運(yùn)營(yíng)商提供的平臺(tái)代替第 1 點(diǎn)和第 2 點(diǎn)。

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

用于 FHIR 的 Azure API

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

用于 FHIR 的 Azure API

?

openEHR 實(shí)例

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

執(zhí)行

硬件

物料清單

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

工具

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

• 可靠的非開(kāi)關(guān)實(shí)驗(yàn)室電源
• 帶串行解碼的示波器
• Otii Arc能耗分析儀

原理圖

原理圖

?

設(shè)備代碼

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

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

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

現(xiàn)在我可以添加真正的密鑰，而無(wú)需 git 嘮叨未分級(jí)的更改。當(dāng)然，現(xiàn)在這些值只存在于您的本地計(jì)算機(jī)上。我還沒(méi)有找到一種很好的方式來(lái)使用公共存儲(chǔ)庫(kù)，同時(shí)仍然保留一些秘密，請(qǐng)?zhí)岢鼋鉀Q方案。

我不會(huì)列出設(shè)備的整個(gè) Arduino 代碼，而是指出一些感興趣的領(lǐng)域，并將源代碼留給您。

蚱蜢開(kāi)發(fā)板

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

面包板有助于在焊接過(guò)程中對(duì)齊排針

?

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

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

?

有關(guān)低功耗開(kāi)發(fā)的替代開(kāi)發(fā)板和深入指南，請(qǐng)查看我的郵箱傳感器項(xiàng)目。

電子墨水顯示屏

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

SPI串行解碼

?

?

SPI解碼

?

SPI 解碼需要示波器上有 4 個(gè)通道。

MAX30101傳感器

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

我不得不移動(dòng)一個(gè)零歐姆 SMD 跳線來(lái)將電源從 5v 切換到 3v。一個(gè)精細(xì)的烙鐵頭非常有助于實(shí)現(xiàn)這一點(diǎn)。

跳線設(shè)置為 5 伏

?

?

烙鐵頭

?

?

跳線設(shè)置為 3 伏

?

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

上拉電阻

?

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

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

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

節(jié)電

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

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

請(qǐng)參閱Grasshopper 低功耗使用的具體細(xì)節(jié)。

服務(wù)

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

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

const char *appEui = "70B3D57ED00xxxxx";

const char *appKey = "9F147263E75F162820F6FF8890Bxxxxx";

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

?

在 TTN 應(yīng)用程序中，我們需要定義一個(gè)腳本來(lái)解碼通過(guò) LoRa 從設(shè)備傳輸?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;

}

我們將不得不添加一個(gè)集成，一個(gè) webhook，它將為在 TTN 中收到的每條消息調(diào)用。此 webhook 的 url 是在 Azure IoT Central Bridge for The Things Network 下的步驟中創(chuàng)建的。

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

我推薦本指南以運(yùn)行新的空白 IoT Central 應(yīng)用程序。

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

?

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

適用于 HR 和 SPO2 的 IoT Central 模板

?

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

每個(gè)設(shè)備的云設(shè)置

?

?

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

?

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

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

Azure IoT Central 設(shè)備橋

?

Bridge 的部署模板

?

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

來(lái)自 IoT Central 應(yīng)用程序的憑據(jù)

?

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

?

因此，請(qǐng)確保npm install報(bào)告成功，無(wú)論需要多長(zhǎng)時(shí)間。是的，并確保在運(yùn)行之前導(dǎo)航到控制臺(tái)中的正確文件夾！

npm 安裝

?

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

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

網(wǎng)絡(luò)鉤子

?

希望您現(xiàn)在有消息從您的設(shè)備通過(guò) TTN 流入 IoT Central。Azure 有很多工具可用于查看指標(biāo)和錯(cuò)誤以找出問(wèn)題所在。有很多基礎(chǔ)需要覆蓋，并且根據(jù)您的背景，期望花一些時(shí)間來(lái)學(xué)習(xí)不同的機(jī)制。

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

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

?

谷歌云醫(yī)療 API

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

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

谷歌云醫(yī)療 API

?

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

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

Azure Functions HTTP 觸發(fā)器

?

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

項(xiàng)目依賴

?

要訪問(wèn)適當(dāng)?shù)?Google Cloud API，我們需要通過(guò) NuGet 添加依賴項(xiàng)；Google.Apis.CloudHealthcare（在撰寫本文時(shí)v1beta1，v1似乎是同步的）。

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

關(guān)于 Google Healthcare API 的注意事項(xiàng)

該 API 會(huì)自動(dòng)生成不同風(fēng)格的編程語(yǔ)言。對(duì)于 c#.net 版本，我想我一定是一個(gè)早期的適配器，因?yàn)榛竟δ懿黄鹱饔谩?/font>ReadRequest、CreateRequest 和 PatchRequest 在官方客戶端庫(kù)中都被破壞了。您可以在我發(fā)布在存儲(chǔ)庫(kù)（#1522 、#1595 ）上的問(wèn)題中找到錯(cuò)誤描述和解決方法。

簡(jiǎn)而言之，為了讓 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 是一個(gè)擴(kuò)展方法：

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開(kāi)發(fā)和調(diào)試了整個(gè)功能。

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

?

獲取網(wǎng)址

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

獲取函數(shù)地址

?

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

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

結(jié)果

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

完成概念驗(yàn)證

?

結(jié)論

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

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

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

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

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