描述

問題

患者想知道為什么他們必須重復醫療信息，以及為什么一旦記錄在案他們就無法訪問這些信息。

臨床醫生想知道為什么他們必須花時間重復輸入相同的信息，以及為什么他們無法從其他醫療保健提供者甚至同一家醫院的子系統訪問患者的健康史。

來自https://www.iota.org/verticals/ehealth

傳統上，醫療保健數據被孤立在不同的機構中，甚至在一個機構中。這些孤島阻礙了有意義的數據共享和重用，并限制了可提供的護理質量。要接受治療，一個人可能需要就一次事件咨詢多個提供者。當個人從初級保健診所轉到醫院再轉到專科診所并再次返回時，記錄不會無縫共享，從而降低了他們的護理連續性。

盡管許多國家最近進行了政治冒險，但我們的數據在醫療保健專業人員之間的共享并不令人滿意，基本醫療信息被多次復制。隨著能夠監測臨床參數的消費設備數量急劇增加，孤島的數量正在爆炸式增長。

該項目探討了讓患者完全擁有醫療信息的可能性，以及與相關醫療保健提供者共享這些信息的能力。它引入了分布式健康記錄 (DHR) 的概念。這適用于使用 IOTA、Azure Sphere 和 openEHR 進行安全醫療家庭監控的示例。

我的背景

憑借在北歐國家開發主要電子醫療記錄 (EHR) 系統 15 年的經驗，我對醫學期刊的復雜性和系統之間的互操作性有著第一手的經驗。此外，我正在運用我在保護低功耗物聯網設備方面的知識。

這是個人的

今年早些時候，我利用業余時間在低功耗微控制器上使用 LPWAN 技術對健康監測設備進行了原型設計。三月的一天，在工作時，我的心跳毫無征兆地停止了。在我被送往醫院之前，我的同事為我進行了心肺復蘇術并使用除顫器使我蘇醒。

發現了一種遺傳性疾病 LQTS，我最終得到了植入式心律轉復除顫器 (ICD)。該設備是未來事件的保障，它還與向我當地醫院報告遙測數據的基站進行通信。雖然這些技術已證明對健康有很大好處，但我對安全問題和數據可用性很感興趣。

第一個問題讓我想到了我是騎兵，并對我自己的原型的安全性提出了質疑。到目前為止，這將我帶到了 Azure Sphere MT3620 及其安全重點。

醫療保健行業已采用計算機化的連接技術來更快地部署改進的醫療設備。當今市場上超過一半的醫療設備都在軟件上運行：植入式；診斷機；監控設備。這些技術具有驚人的拯救生命、快速診斷和提高生活質量的能力，因此安全故障就是未能保護人類生命。

我還發現，我的 ICD 報告的數據最終在醫院的一個單獨的斷開連接的子系統中，并且不能立即提供給其他醫院、診所、醫院外的急診室甚至同一醫院內的其他病房。這意味著，如果我在度假期間最終進了急診室，他們不太可能知道我的 ICD 前一天晚上是否報告了故障。在我國，患者可以登錄國家門戶網站并閱讀健康記錄。ICD 的數據不受此限制，我只能猜測，由于技術不兼容。

系統之間缺乏互操作性和健康數據的可用性是 IOTA 的用武之地，也是這個概念驗證的主要關注點。

建筑學

我不相信有人可以將 IOTA 種子和多個密碼的管理留給各種患者。89 歲的 Maud 因頭暈去看醫生時不會背誦她的 81 個字符的 IOTA 種子或高安全密碼。我提出的解決方案是將 IOTA 中患者擁有的醫療數據與已經在許多國家實施的國家患者門戶整合。您會信任該方創建和維護您的醫療錢包，并且您會允許或拒絕醫療保健從業者在需要時訪問它。對于喜歡冒險的人，可以在門戶中訪問種子。此外，存儲在 Tangle 中的實際醫療數據將被加密。

技術

該項目是一個概念驗證 (PoC)，由以下部分組成：

• 帶有Mikro Elektronika Mikroe 心率 4傳感器的Azure Sphere 入門套件，能夠感應患者的心率和血液氧化。
• 用于路由和顯示遙測數據的Azure IoT Central應用程序。它還將設備與患者相關聯，并定義觸發操作的規則。
• 一個無服務器的Azure Functions ，用于組合openEHR觀察并將測量值分配給正確的患者錢包/分布式健康記錄。
• 與IOTA Tangle 的集成。

它旨在用于監測患者：

• 在家自行管理
• 在家庭護理的監督下
• 在療養院自我管理或監督
• 自我管理或在醫院和診所的監督下

先決條件

• 代表患者的兩個或多個 IOTA 種子。我建議在電腦和手機上安裝Trinity 錢包來驗證結果。我們將使用devnet ，盡管由于缺少價值交易，這對 PoC 來說并不重要。
• 免費的Azure IoT Central帳戶。
• 用于創建 Azure Functions的免費Azure帳戶。這可以被任何網絡服務器技術/托管所取代，但示例代碼基于 dotnet core 2.1。
• 視覺工作室 2017/2019。
• 用于開發設備應用程序的Azure Sphere SDK 。
• GIT用于下載源代碼。
• 用于配置 MT3620 的azsphere命令行實用程序。

可選，但強烈推薦

• 用于監視消息的IoT Central Explorer 工具。
• RequestBin用于臨時捕獲和診斷 http 請求。
• 用于手動生成 http 請求的郵遞員。
• Ocean Health Systems 原型編輯器，用于探索openEHR數據結構。

傳感器

對于此 PoC，我使用了一個傳感器來通過血管系統的脈搏來估算心率 (HR)。它還可以讀取血液中含氧量 (SpO2) 的飽和度。

監測 SpO2（院外）可用于解決肺部血液氧合不足的許多健康問題。它可以警告患有肺炎和慢性阻塞性肺病（哮喘、肺氣腫）的患者健康狀況惡化。這對囊性纖維化患者至關重要。它還可用于監測急性氣道炎癥，例如支氣管炎、鼻炎、鼻竇炎，尤其是對于可能無法改變惡化狀態的兒童和患者。

其他可隨時用于此類院外監測的傳感器及其用例包括：

• ECG/EKG - 檢測 A-fib（心動過速）、v-fib、心動過緩（低心率）、早搏（心悸、LQTS）。
• 溫度——發燒、生育/排卵、低代謝率、敗血癥（免疫系統受損的患者）。
• 壓力墊 - 褥瘡，癡呆癥患者的運動。
• 血糖 - 糖尿病
• 血壓 - 藥物并發癥、壓力、心臟病。

代碼

Azure Sphere 設備的代碼基于一些示例作為起點。當按下按鈕 B 時，它會讀取傳感器，并希望您將手指放在二極管上。傳輸此數據并同步一些設置。

Azure Sphere Starter Kit 的安裝和首次注冊有詳細記錄，并且在運行此應用程序之前是必需的。這將告訴您需要在 app_manifest.json 中配置什么以允許 IoT Central 上的設備。

將MT3620 用戶指南放在手邊。

我創建了一個新存儲庫，并從https://github.com/Azure/azure-sphere-samples存儲庫中復制了 AzureIoT 示例。這是創建 IoT Central 或 IoT 中心連接的應用程序的良好起點。

MikroE 點擊心率 4

MikroE Click-boards 有一個廣泛的庫庫。但是，它們與 Azure Sphere MT3620 的純 C 語言環境不兼容。無賴。已經為 I2C 土壤濕度傳感器移植了其中一個庫后，我準備啟動我的示波器并放上一大壺咖啡。

我訂購了 MikroE Heart Rate 4 模塊，因為我看過 James Flynn 的作品。示例代碼無需修改即可運行，節省了大量時間。謝謝詹姆斯！閱讀他的博客以了解更多信息。

然而，我發現截至 2019 年 9 月，使用模數轉換 (ADC) 功能，就像大多數傳感器所做的那樣，合并這兩個起點并不是直截了當的。一個問題是，要將 ADC 用于 I2C 通信，您需要以 Azure Sphere API 版本 2 Beta 為目標。在撰寫本文時，這在項目屬性下的“目標 API 集”下表示為“2+Beta1905”，但可能會發生變化。

以 Azure IoT Hub/Central 為起點更改 API 版本會導致各種編譯錯誤。我修復了大部分但不是全部。使用 clickboard_demos 示例作為起點并合并 Azure IoT 庫的依賴項確實有效。

另一個問題是 MT3620 的硬件定義。這兩個示例針對不同的定義，具有不同的名稱，并且 sample_hardware.json 和 app_manifest.json 需要一致。決定一個并深入研究引出線，無論如何你都需要掌握它。

MT3620 RDB 的示例硬件抽象

在 azure-sphere-samples\Hardware\mt3620_rdb\ 下找到文件 sample_hardware.json 并添加您需要的 GPIO。我加了

{"Name": "SAMPLE_HR4_INT", "Type": "Gpio", "Mapping": "MT3620_RDB_HEADER1_PIN8_GPIO", "Comment": "MT3620 RDB: GPIO2 is exposed on header 1 pin 8"}

訪問心率的中斷引腳 4. 我怎么知道要使用哪個 GPIO？我可以在 Click-board 上直觀地看到哪個引腳被標記為 INT，也可以在產品頁面上找到它。

MT3620用戶指南在 Azure Sphere MT3620 初學者工具包的 Click 套接字 1 上說明了這對應的 GPIO 引腳。

該名稱SAMPLE_HR4_INT將在 app_manifest.json 中引用并解析為正確的 pin 地址。來自一個簡單的 Arduino 世界，這感覺過于復雜和混亂。我讓 10 歲的孩子在一個小時內用 Arduinos 脈沖 LED，這太抽象了。我希望 Microsoft 對此進行簡化（僅表示引腳編號）或添加可視化工具。

如果您需要訪問 INT 引腳以了解手指何時覆蓋傳感器，則為您的模塊使用 Click 插座 1 或 2 并不重要。

與 I2C 通信共享同一總線，并且電線相互連接。I2C 總線已經定義好了，不用管了：

{"Name": "SAMPLE_LSM6DS3_I2C", "Type": "I2cMaster", "Mapping": "MT3620_RDB_HEADER4_ISU2_I2C", "Comment": "MT3620 RDB: Connect external LSM6DS3 to I2C using header 4, pin 6 (SDA) and pin 12 (SCL)"}

我邀請您進一步檢查客戶端應用程序或 HR4 示例以了解傳感器的使用方式。不要擔心計算測量值的算法。

Azure IoT Central 遙測

其余代碼主要是關于將遙測數據同步和推送到 IoT Central。查看 azure-sphere-samples/Samples/AzureIoT 以獲取獨立示例。

Azure 物聯網中心應用程序

我熟悉 Azure IoT Hub，所以我選擇在這個項目中使用 IoT Central。底層機制大同小異，但您可以用很少的代碼或不用代碼實現很多。設置應用程序有詳細記錄，請按照本指南了解更多信息。

我的應用程序定義了一個具有以下功能的設備模板：

• 遙測心率和 SpO2。
• 設備心跳事件。
• 狀態 LED（用于調試、檢查連接）和 NPR Id 的設置。NPR Id 是我用來將讀數分配給正確患者的 IOTA 錢包的國家患者標識符。當將設備分配給患者進行家庭監護時，操作員將使用此設置。對于在多個患者中使用，可以使用 NFC、Chirp 、條形碼或類似物來激活正確的患者。
• 傳感器版本和 NPR Id 的屬性。
• 帶有 webhook 的規則，用于觸發 Azure Functions 以創建 IOTA 事務。

您可能會在“設置”和“屬性”下注意到 NPR Id，稍后會詳細介紹。

Azure IoT Central的深入指南。有關webhooks的更多信息。

我建議使用RequestBin來調試和探索 http 負載。請注意，您必須每 48 小時創建一個新地址。

為了監視從設備到 Azure IoT Central 的遙測，我使用了工具iotc-explorer 。

Azure 函數

Azure Functions 的目的是為全國患者門戶提供服務并執行以下操作：

• 從有效負載遙測數據中提取 NPR Id（國家患者標識符）和設備標識符。
• 找到映射到患者的 IOTA 種子。這將是國家患者門戶下的一個單獨注冊表，但在本 PoC 中為簡潔起見進行了簡化。
• 從傳感器讀數創建一個 openEHR 兼容的數據結構，觀察。這將通過訪問 openEHR 模板存儲庫來完成，但在本 PoC 中為簡潔起見進行了簡化。
• 代表患者為每個測量創建 IOTA 交易。

我花了很多時間嘗試讓該功能訪問設備數字孿生模型，以獲取定義為操作員設置的患者標識符。這是不可靠的，并且似乎搞砸了設備身份驗證。我認為根本原因在于 Azure 函數和實例狀態的性質。

我已經將所需的 ID、NPR Id 作為設置，但這不是觸發 Webhook 時 IoT Central 發送的負載的一部分。

為了解決這個問題，我在 Azure IoT Central 的模板中添加了一個相同的屬性。設備只是將 NPR Id 屬性與設置中的值同步。規則中定義為條件的所有遙測和屬性都在有效負載中傳遞。

要開發和本地調試 Azure Functions，我建議使用Fiddler 、Postman和JSON Editor Online 。請注意，在 Fiddler 中啟用對加密的 http 請求的解碼可能會導致您計算機上的其他應用程序出現故障。

// Connect to a node on one of the main networks.

var repository = new RestIotaRepository(new RestClient("https://nodes.devnet.thetangle.org:443"));

// Get addresses from the Tangle on behalf of the patient's wallet for generating new address for posting reading.

// Would be an external trusted service.

var tangleAddresses = NationalIdentityService.GetTangleAddressesFromNprId(repository, nprId, ((JObject)telemetry).Count);

// Create transactions for the Tangle for each type of reading in payload and bundle together.

// Finalize and sign.

var bundle = CreateTransaction(tangleAddresses, telemetry);

// Send the complete transactions to the Tangle.

repository.SendTrytes(bundle.Transactions, depth: 2, minWeightMagnitude: 9);

請瀏覽服務器代碼以獲取更多詳細信息。

結果

Webhook 的結果是代表患者在 Tangle 上進行的交易。

這些數據現在可用于許多不同的情況，無論醫院、診所或國家。

打開電子病歷

“openEHR”是電子健康技術的名稱，由開放規范、臨床模型和軟件組成，可用于創建標準，并為醫療保健構建信息和互操作性解決方案。openEHR 的各種人工制品由 openEHR 社區生產，由 openEHR 基金會管理，openEHR 基金會是一家成立于 2003 年的國際非營利組織。

openEHR 是一個龐大的主題，超出了本項目描述的范圍。簡而言之，我的實施基于“生命體征”項目的工作，該項目試圖標準化如何描述常見的臨床觀察結果和全球可讀性。我不得不大幅壓縮格式以適應此應用程序。我還對結構的創建進行了硬編碼，省略了模板存儲庫。這是嘗試證明一個概念，而不是完全兼容 openEHR。

邀請您探索 openEHR 臨床知識管理器或下載Ocean Health Systems Archetype Editor以了解有關數據結構的更多信息。

安全

MT3620 在硬件層面有一些非常有趣的安全特性。希望我們能少看到這樣的報道。

得到教訓

• 在開發此項目時，Azure IoT Central 規則中的電子郵件警報從未起作用。
• Azure Sphere 初學者工具包的 Wi-fi 連接在首次配置時非常不穩定。除了我們的主要 5G 網絡之外，我嘗試設置一個輔助 2G wi-fi 網絡，連接變得更加穩定。
• Azure IoT Central 是一個非常好的解決方案。因為我最終花時間開發 Azure IoT 中心可能會節省我一些時間并啟用更多的洞察力和工具。
• openEHR 很復雜，不是一個周末的閱讀。

限制

領域驅動設計領域的專家傾向于同意：電子病歷和醫療保健系統通常屬于軟件設計中最復雜的領域。openEHR 專為復雜健康系統之間的互操作性而設計，需要按比例縮小以適應輕量級設備。

我想為患者的分布式健康記錄歷史制作一個可視化工具，并嘗試將其導入到我使用的 EHR 系統中。這將不得不留給未來的項目。

在未來的項目中，我想嘗試更多類型的傳感器，如前所述。

Tangle 中 openEHR 數據的加密是在開發過程中留下的，AES 加密是最明顯的選擇。

全面部署的潛在成就

如果全世界的每一位患者都獲得其醫療數據的單一來源所有權，那么虐待的風險就會大大降低。這些數據僅在相關時共享并且不會被不必要地復制，這將增加隱私、安全和信任。安全的家庭監控將增加發現健康問題的機會，并減輕晚期疾病醫院和診所的負擔。使用全球適用的數據格式將減少機構之間虐待的來源，并進一步開放患者的跨境安全交流。

現代醫療保健必須轉向其發展方向。

關于使用 IOTA 作為患者擁有的分布式健康記錄的最終想法

項目的核心如期進行，我開始專注于重要的事情。在進行這項工作時，我開始考慮使用屏蔽身份驗證消息(MAM) 作為一種方式，讓感興趣的各方與患者的家庭監控保持同步。這將不得不留給未來的項目。