Python實現動圖生成：輕松創建自定義表情包
主要醫療 API 類型和示例。
但首先，我們將探討特定于醫療保健的數據交換標準，這些標準對于了解醫療保健 API 的工作原理至關重要。
醫療保健行業堅持數據標準，幫助行業系統和專業人士保持一致。您可以從我們的文章《醫療保健數據標準》中了解有關整個行業使用的代碼和格式的更多信息。在這里，我們將只關注與通過 API 進行數據交換相關的最關鍵規范。
FHIR 是 Fast Healthcare Interoperability Resources 的縮寫，是主要的行業標準，專為共享醫療保健數據而開發，特別是電子健康記錄。它利用在 HTTPS （HTTP Secure） 協議上實施的 REST API 架構，使衛生系統能夠以 JSON 和 XML 格式交換數據。
FHIR 背后的理念是將患者記錄表示為一組資源，或具有相同大小和結構的獨立數據塊。每個資源都有一個唯一的 ID，并包含一小部分信息（例如，化驗結果或藥物詳細信息）。根據查詢，基于 FHIR 的 API 檢索合并到較大文檔中的單個資源或組合。
FHIR 數據模型。來源： HL7 FHIR 版本 4
根據互操作性規則，醫療保健提供商和付款人必須實施 FHIR，才能通過健康應用程序向患者提供臨床和索賠數據的某些元素。
但是，預計隨著時間的推移，該標準將在整個行業中得到廣泛采用，所有醫療數據都將構建為小型、離散的資源。
USCDI 代表 United States Core Data for Interoperability。它定義了一組強制性數據片段，這些數據應患者的請求通過其 FHIR API 公開。
USCDI 中的數據元素與 FHIR 中的數據元素一致，并屬于更大的數據類，例如
USCDI 的第二個版本現在處于草案階段，包含兩個新類別：診斷成像和遭遇信息。
USCDI 第二版中的數據類和元素。來源： HeathIT.gov
通常，通過醫療保健 API 的數據可以歸類為受保護的健康信息 （PHI）。 因此，它受隱私和安全標準的約束，旨在防止未經授權訪問和濫用敏感信息。
在美國，這些標準由《健康保險流通與責任法案》（HIPAA） 規定。除其他外，它解釋了必須使用哪些技術和程序來保證適當的安全級別。在歐盟，健康數據受《通用數據保護條例》（GDPR） 保護。
這兩項法律都授予患者訪問其個人信息的權利，并要求大多數醫療保健 API 符合 HIPAA 或 GDPR 標準。這意味著數據必須僅對授權用戶開放，并在傳輸前進行加密。
SMART是 Substitutable Medical Apps & Reusable Technology（可替代的醫療應用程序和可重復使用的技術）的縮寫。其目的是概述如何安全地將使用 FHIR 的 EHR 系統與第三方應用程序集成。除其他外，SMART 規定應用 OAth2.0 身份驗證協議。不過，HIPAA 和其他法規的合規性不在其范圍之內。
該框架支持患者和提供者應用程序，這些應用程序可以作為獨立解決方案啟動，也可以直接插入 EHR 系統。
牢記標準，讓我們繼續討論 FHIR API 在醫療保健領域的預期用例 — 訪問電子健康記錄。
公開的數據：存儲在一個健康 IT 系統中的USCDI 數據元素和其他患者信息
使用它們構建什么：面向患者的健康應用程序、遠程醫療平臺、用于跟蹤和監控治療計劃的患者管理解決方案、對現有患者門戶的增強。
自然，領先的 EHR 供應商早在互操作性規則生效之前就率先遵守這些規則。在這里，我們將回顧來自市場份額最大的 EHR 系統的 FHIR 資源，即
四大醫院和衛生系統加起來覆蓋了近 80% 的美國醫院和衛生系統，因此它們的 API 值得更仔細研究。
超過 2.5 億美國患者的健康記錄在 Epic 生態系統中。通過 Epic on FHIR API 提供對此數據的訪問。開發人員可以創建將檢索 50 多個數據元素的應用程序，包括但不限于 USCDI 集。
Epic 提供了一個自助式測試沙盒，用于在上線之前嘗試集成并了解其行為。響應和支持的操作（搜索、讀取、創建）因使用應用程序的用戶（患者或醫務工作者）而異。
Epic 不會驗證開發人員或使用 FHIR API 設計軟件的許可。因此，您對您的產品及其對所有適用法規的遵守情況負全部責任。
Cerner 覆蓋近 1 億美國患者，提供支持 30 多種 FHIR 資源的 Ignite API。可以搜索、讀取它們，在某些情況下，還可以創建或更新它們。
除此之外，Cerner 還有一個單獨的 API 可以從其人口健康管理平臺 Healthelntent 檢索數據。它能從多個數據源自動生成病人記錄，而不是從單一文件中提取信息片段。API 僅適用于企業對企業解決方案。
該公司的開放沙盒允許開發人員在沒有身份驗證的情況下測試他們的應用程序。完成后，軟件必須經過可能需要 10 到 14 周的驗證過程。
針對 Cerner API 構建的應用程序的驗證過程。來源：Cerner 的開放開發人員計劃
排名第一的急癥護理和家庭健康 EHR 使客戶端應用程序能夠通過Patient Health Data APIs與其數據庫進行交互。這些API允許對16種與USCDI數據類別相一致的數據資源進行只讀訪問。
為了針對真實的 MEDITECH EHR 測試項目，該公司有一個名為 Greenfield 的開發環境。該沙盒包括詳細的文檔、來自獲得許可的 MEDITECH 開發人員的技術支持以及在線論壇。
但是，此選項僅適用于 MEDITECH Expanse 客戶。要獲得此身份，您必須通過特殊表單提交有關您和應用程序用途的數據。然后，只需等待并希望您的提交獲得批準。
2020 年，Allscripts 被評為門診和住院醫院的頂級 EHR 供應商。該公司總共連接了 2000 萬患者。其 FHIR API 將第三方鏈接到 Allscripts 的所有產品。
目前，API 適用于 14 個 USCDI 類。開發人員可以在相應的沙盒環境中測試他們的集成。要使用支持 FHIR 的 API，您只需注冊 Open Allscripts Developer Program （ADP） 即可。但是，此選項僅允許構建患者端應用程序。想要連接到 Allscripts 產品的健康公司必須成為 ADP 集成商，這將授予他們使用公司專有 API 的權利。
公開的數據：從各種來源收集的患者 USCDI 和非 USCDI 數據
用它們構建什么：健康和保健應用程序、疾病和藥物管理工具、遠程醫療平臺。
閱讀主要文章 Health Data APIs
這個基于 FHIR 的 API 系列的代表是供應商中立的，這意味著它們從廣泛的來源提取患者數據，包括 EHR 系統和可穿戴設備。以下是此類整合患者數據 API 的三個示例。
可通過不同 API 訪問的 FHIR 元素。
| API名稱 | 集成的健康系統數量 | 功能描述 | 安全性措施 |
| Apple Health Records API | 500+ | 與多個健康系統集成，整合數據到一個文檔中，在iOS設備上顯示。使用OAuth 2.0協議進行身份驗證。 | 數據傳輸加密，不通過Apple網絡。在設備上，內容受iPhone密碼、Touch ID或Face ID保護。 |
| Human APIs | 2.64億患者覆蓋 | 連接到實驗室、EHR系統、藥房和患者門戶，提取數據，AI算法幫助轉換為FHIR兼容格式。 | 未明確提及。 |
| Particle Health API | 3億患者記錄 | 提供對EHR系統的訪問，與藥房和實驗室集成，數據轉換API將傳統數據集轉換為FHIR文件。 | 未明確提及。 |
公開的功能：NLP 引擎和機器學習算法，用于從非結構化醫療文檔中獲取見解
使用它們構建什么：健康分析解決方案、臨床決策支持系統、精準醫療工具。
閱讀主要文章 Health Data APIs
Amazon、Google 和 Microsoft等科技巨頭也努力通過推出強大的 API 來攝取和分析不同格式的醫療數據，從而擴大其在數字醫療保健領域的影響力。
| API名稱 | 功能描述 | 支持的數據格式 | 安全性與合規性 | 其他特點 |
| Amazon Comprehend Medical APIs | 自動從臨床文檔中提取有意義的組件并與醫療編碼系統連接，識別并刪除受保護健康信息 (PHI) | 支持非結構化臨床文本 | 符合HIPAA要求，使用HTTPS加密連接 | 支持英語文本，與其他AWS服務集成，按需付費 |
| Google Cloud Healthcare API | 支持醫療保健標準，包括從各種來源導入數據，轉換為FHIR格式，去除PHI，存儲、管理和分析DICOM文件 | 支持FHIR、HL7v2、DICOM | 遵循HIPAA法規，使用Google Cloud的安全基礎設施 | 支持DICOM和FHIR集成，機器學習集成，可擴展性與彈性 |
| Azure Health Data Services | 基于云的解決方案，支持FHIR和DICOM標準，轉換舊設備或專有設備格式中的數據為FHIR | 支持FHIR、DICOM | 符合HIPAA、GDPR和CCPA等合規性要求 | 支持機器學習、分析和AI工具，提供專用鏈接、客戶管理的密鑰和日志記錄 |
暴露的數據： 關于疾病、健康風險和保持健康方法的循證內容
用它們構建什么：網站、門戶和擴展，以教育患者和醫生、患者參與解決方案。
閱讀主要文章 Health Data APIs
公共衛生信息 API 處理建議、統計數據、調查和其他有價值的數據，這些數據由醫學專家系統地審查。
| API名稱 | 功能描述 | 支持的數據格式 | 安全性與合規性 | 其他特點 |
| ODPHP MyHealthfinder Content API | 與醫院網站集成，提供基于年齡、性別和習慣的健康提示 | JSON 和 XML | 至少每兩年審查一次，由ODPHP監督 | 易于集成，提供個性化健康建議 |
| WHO data API (Athena API) | 集成第三方應用程序與全球健康觀察站（GHO），按國家/地區收集統計數據 | 默認XML，支持JSON | 世界衛生組織構建 | 覆蓋廣泛健康主題，如兒童營養、免疫接種 |
| HHS Content Syndication APIs | 整合來自HHS合作伙伴的新聞、文章、調查等 | JSON 和 XML | 由美國衛生與公眾服務部（HHS）提供 | 支持多語言，適用于多種平臺和應用 |
數據公開： 有關藥物、其副作用和藥物相互作用的詳細信息
用它們構建什么：藥房管理系統、電子處方和 EHR 系統的臨床決策支持模塊、計算機化醫囑輸入 （CPOE） 系統、患者門戶、處方依從性應用程序。
閱讀主要文章 Medicine and Drug Data APIs和 Drug Interaction Checker APIs
藥物數據在哪里積累，可信度如何？要回答這些問題，我們必須追蹤醫藥信息的旅程，從制藥商到醫療專業人員、普通消費者和衛生系統。
注冊。 藥品制造商、重新包裝商或重新貼標商必須向美國食品藥品監督管理局 （FDA） 注冊新藥商品。為此，制藥公司以結構化商品貼標 （SPL） 格式提交注冊和上市信息。
獲得 NDC。根據提交的內容，商品將獲得唯一的 10 位或 11 位國家藥品代碼 （NDC）。它由貼標機代碼、產品代碼和包裝代碼組成。FDA 在 NDC 目錄中發布所有列出的標識符，該目錄每天更新。但分配 NDC 代碼并不意味著該藥物已獲得 FDA 批準。
NDC 格式示例。來源：NDC 列表
DailyMed 出版物。 FDA 將在美國銷售的藥物信息發送到其官方網站 DailyMed，該網站由美國國家醫學圖書館 （NLM） 于 2005 年推出。通過 DailyMed，衛生系統、醫生和普通用戶可以公開獲得有關處方藥及其副作用的可靠數據。
將 NDC 代碼與 RxNorm 名稱連接。 除了 DailyMed，NLM 還維護和更新 RxNorm 臨床藥物詞匯表。與 NDC 相比，RxNorm 概念唯一標識符 （RxCUI） 與藥物成分、強度和劑型相關聯。例如，鹽酸西替利嗪 5 MG 口服片劑具有單個 RxCUI （1014676），但與 25 個 NDC 代碼相關聯，分別對應于不同的標簽和包裝規格。
RxNorm 旨在促進互操作性，是衛生系統之間數據交換的首選標準。
因此，關鍵藥物數據 API 以某種方式與上述組織之一相關并支持 SPL、NDC 和/或 RxNorm 標準也就不足為奇了。
所有參與藥品數據標準化和推廣的主要聯邦參與者都擁有免費的公共 API，旨在提高開放性和教育消費者。
反過來，商業技術提供商使用廣泛的數據源，從上述公共數據集到研究數據庫和醫學期刊。通常，此類服務還提供藥物相互作用檢查功能。
通過 API 進行藥物相互作用檢查。
openFDA API 是一個開源平臺，可以訪問有關動物和人類藥物、醫療設備、食品、煙草等的數據。至于人類藥物，該平臺涵蓋
所有 API 都以 JSON 格式返回響應。值得注意的是，并非 openFDA API 提供的所有信息都經過臨床或生產用途的驗證。
| API名稱 | 功能描述 | 支持的數據格式 | 其他特點 |
| openFDA APIs | 提供有關動物和人類藥物、醫療設備、食品、煙草等的數據。涵蓋不良事件報告、藥物標簽、NDC編號、藥物召回信息等。 | JSON | 所有信息未經臨床或生產用途驗證。 |
| DailyMed RESTful API | 檢索SPL信息，包括NDC代碼、產品級RxCUI代碼、打包描述、藥物名稱、藥物類別。 | JSON 和 XML | 支持HTTP GET方法，提供數據檢索功能。 |
| RxNorm API | 提取JSON和XML格式的信息，連接到藥物相互作用數據集，提供RxNorm詞匯和相關數據。 | JSON 和 XML | 由NLM、NIH和HHS提供，支持藥物名稱標準化和互操作性。 |
| DrugBank API | 通過NDC編號、RxNorm代碼等搜索超過100,000種藥物，提供藥物相互作用數據庫，每天更新。 | JSON、XML 和 SQL | 獨立集成就緒API，提供廣泛的藥物信息和相互作用數據。 |
First DataBank （FDB） 維護著廣泛使用的藥物數據庫，稱為 MedKnowledge。它包含
第三方開發人員可以使用 FDB Cloud Connector API 將數據庫連接到現有的衛生系統
IBM Micromedex 是最大的藥物信息在線數據庫之一。它為不同的目標群體提供了兩個基于 JSON 的 API 選項。Summary Drug API 使護士、保險公司和患者能夠獲得有關藥物的一般問題的答案。In-Depth Drug API 適用于需要有關復雜護理詳細信息的醫療專業人員。
暴露的數據： 可能的病癥、護理建議
用它們構建什么：診斷前決策支持工具、呼叫中心和急診科護理的分診解決方案、健康聊天機器人和自我診斷患者應用程序。
閱讀主要文章 Symptom Checker APIs
本模塊的目標是告知患者病情的可能原因，并幫助醫生在診斷前階段做出更好的決策。
癥狀檢查器 API 的工作原理。
典型的癥狀檢查器結合了
以下是高級癥狀檢查器 API 的幾個示例。
| API名稱 | 功能描述 | 癥狀和疾病覆蓋范圍 | 準確率 | 數據格式支持 | 個人信息要求 | 集成系統 |
| Infermedica API | AI診斷引擎，具有NLP功能，捕獲癥狀和風險因素 | 1,500種癥狀，800種病癥 | 93% | 未明確說明 | 不要求提供個人信息，符合HIPAA規定 | 未明確說明 |
| Mayo Clinic API | AI算法連接知識庫數據與患者輸入，確定癥狀并提供指導 | 300多種常見癥狀 | 未明確說明 | JSON和XML | 未明確說明 | 未明確說明 |
| Isabel Healthcare API | 癥狀檢查器API，整合可能的診斷清單 | 10,000多種疾病 | 96% | XML和JSON | 未明確說明 | 預先集成Cerner和Epic等EHR系統 |
功能和公開的數據： 醫療文件操作、預約管理、患者記錄、安全視頻訪問。
使用它們構建什么：遠程醫療系統、調度工具、用于遠程護理的醫生和患者應用程序。
閱讀主要文章： Telehealth APIs
在談到遠程護理服務時，遠程醫療和遠程醫療是兩個經常互換使用的術語。這包括但不限于患者數據交換、遠程訪問、預約安排和實驗室測試訂購。讓我們看看一些在設計時考慮了遠程醫療的 API。
遠程醫療軟件的 API。
| API名稱 | 功能描述 | 特點 |
| DrChrono API | 允許開發人員在 DrChrono 之上構建自定義解決方案，DrChrono 是一個為 iPad 和 iPhone 提供遠程醫療功能的 EHR 系統。 | 支持預約安排、患者病歷數據交換和管理醫療文檔。 |
| Health Gorilla FHIR-based APIs | 連接到美國近 65000 家醫療機構，提取醫療文檔。NLP 引擎從文本和圖像文件中提取信息，支持電子測試訂單提交和實驗室結果獲取。 | 連接廣泛，NLP 功能強大，支持 FHIR 格式數據管理。 |
| Bluestream API | 專為醫院設計，快速嵌入虛擬護理到工作流程。 | 提供符合 HIPAA 標準的視頻訪問、虛擬約會安排和實時活動跟蹤。集成時間取決于服務數量。 |
目前，醫療保健在 API 使用方面仍然落后于其他行業。專家列舉的主要障礙包括
客戶通常使用金融或travel APIs來一鍵訪問其個人數據并更改服務提供商。醫療保健何時會看到這種級別的 API 采用？沒有人知道，但 2022 年即將到來的互操作性截止日期和 COVID-19 帶來的挑戰顯然正在將這一日期拉近。
原文鏈接：https://www.altexsoft.com/blog/healthcare-api-overview/
