通過描述上面的解決方案，我們可以對醫療保健 IT 領域的利益相關者有所了解。工程師和業務領導者擁有數據訪問渠道標準化和治理的平臺；一些利益相關者會產生需要發布的數據，因此他們會聯系感興趣的相關方；有些利益相關者為最終用戶建立價值渠道。這些利益相關者聚合多個數據源并創建有價值的產品，然后由最終用戶消費這些數據并得出結論、做出決定。
API 生產者群體 涵蓋了負責設計、開發、發布和測試醫療保健 API 的設計師、架構師、醫療保健產品開發人員和 API 測試人員，這個小組負責定義 API 范圍（內部、外部、限制和授權）。在大型醫療保健 API 數據交換中，生產者可以來自不同的醫療保健機構。
平臺擁有者群體 保證了 API 市場的正常運作，他們維護組件，促進 API 使用者之間的協作，并向 API 生產者提供使用者的反饋。他們承擔了平臺宣傳、平臺支持和社區建設等任務。
API 使用者群體 來自應用程序的開發社區。他們是愿意利用醫療數據并從中獲取價值的創新者。他們可以是人口健康驅動的倡議者、醫療保健初創企業、醫療保健機構、醫院集團和政府，熱衷于改善多方面的醫療保健環境。
成功的醫療保健 API 市場應該包含三個方面的東西：
API 管理 是這個平臺的基本要素，解決了跨領域的架構問題。它封裝了運行庫（網關）、安全層、治理層、分析層和許可管理層。
API 網關的運行庫充當了平臺的入口點，最終與實際數據后端的 EHR 系統連接。它與安全層無縫集成，提供基于令牌的安全性和基于策略的授權。
鑒于通過這些 API 公開的數據的敏感性，API 市場為 API 的開發、發布和全生命周期維護提供了強有力的治理是至關重要的。API 的暴露方式、人員驅動的治理模型、策略管理和依賴性分析都是通過 API 治理層來控制的。
開發人員發布 API 后，他們應該能夠監控、測量和管理已發布的 API，此功能由 API 的分析組件提供。除了基于批處理的分析之外，該層還可以為 API 調用失敗、響應時間突然增加或 API 資源訪問模式變更等方案創建警報。
許可管理層實現工作流程，確保為數據共享、存儲和使用提供必要的許可。這是策略驅動的，有時依賴于基于機器的決策或人為參與。
開發者門戶 發布 API。它讓所有相關方都能夠發現可用的數據流并了解如何使用它們。開發者門戶解決了醫療平臺健康數據的可見性問題。所有專門的醫療保健系統都可以在由提供者機構、醫院或公共醫療保健交易所維護的中央開發者門戶中檢索 API。
使用技術組件構建一個出色的 API 市場只是整個過程的一部分，為了建立成功的醫療保健 API 市場，平臺所有者可以參與以下這些活動：
市場中的 API 可以根據其消費模式進行產品分類。在醫療保健領域，常見的模式包括患者注冊、調度、財務和計費、保險、臨床、輔助、公共健康和物聯網。
注冊 API 用來管理與 EMR 系統相關的注冊功能。通過這些注冊 API，開發人員可以開發與不同 EMR 系統進行集成的接口，用來管理患者特定的數據交換。身份驗證和授權是這些 API 的關鍵需求，因為它們提供了與消費者數據相關的所有后續活動的入口。API 市場中的 API 管理層可以為這些 API 活動提供關鍵的安全構造。
調度 API 的功能包括：安排預約、發送預約提醒、檢查預約時間段以及更新、取消或重新安排預約。調度是醫療保健市場中常用的功能之一，它與各種系統（包括賬單、消息和通知）集成在一起。API 網關運行庫以及集成層可以在這些系統之間提供所需的橋梁，從而為患者提供輕松的調度體驗。
財務 API 用來管理護理提供者機構和各當事方之間的資金交易。這些財務 API 可以進一步細分，例如可以分為計費 API、索賠 API 等。醫療保險在醫療保健行業的財務部門發揮著重要作用。索賠管理系統有助于檢查索賠狀態、取消或調整以及自動付款過賬，它公開的 API 使支付方能夠連接到合作伙伴系統。安全性是這些 API 的關鍵需求之一，特別是強身份驗證和授權。為了支持其中的一些需求，需要有一個能夠與外部身份提供者（IDP）交互的 API 管理平臺。
臨床 API 將基于不同的標準（如 HL7v2、HL7v3 和 FHIR）通過 EHR/EMR 系統來管理臨床數據交換。成熟的 API 平臺具有數據格式轉換功能，因此它可以連接到多個系統，并根據使用者的要求提供數據傳送。這些系統包括一些特殊的數據流，如患者用藥數據、治療計劃、免疫詳細信息和家庭病史，醫生利用這些數據來決定病人的健康狀況。患者可以借助 API 驅動的以患者為中心的應用程序來查看他們的藥物、診斷和病史。這樣可以鼓勵患者更多地參與個人健康診斷，也符合公共醫療政策，例如“有意義使用”政策。
輔助 API 用來管理與核心臨床功能（如藥房、實驗室、放射科等）相分離的系統的信息。這里有一些示例，包括與外部藥房就用藥處方和續藥請求進行通信、用不同的信息系統交換實驗室結果的數據，以及用外部營養系統來管理膳食訂單。通過安全通道（B2B）與外部系統連接是這些 API 的關鍵需求，支持各種安全協議（如 OAuth2、SAML、OIDC）的 API 管理系統將有助于與這些第三方系統安全連接。
公共健康 API 可以用于指導通過交換公眾、聯邦或專業注冊機構可報告臨床數據來跟蹤公共健康。這些 API 能夠提供公共衛生監督所需的數據。公共健康 API 向政府和其他研究機構提供存儲在電子病歷（EMR）中的臨床健康數據，并從這些機構獲取數據，以豐富本地的臨床記錄。這兩項事務都是在給定的標準下進行的，以確保健康數據的隱私。當提供此類數據流時，API 運行庫可以對記錄進行清洗和去識別化，以確保這些數據是匿名的，這是一個成熟 API 運行庫必備的實用功能之一。
近年來，可穿戴健康/活動監測設備呈指數增長。這些數據流開啟了個人健康監控的新維度，通過可消費的平臺公開這些流，可以加速以患者為中心的健康應用程序的創新。
在所提議的解決方案中，我們將系統集成和 API 管理視為兩個不同的組件，需要經過深思熟慮的分析。集成組件應該通過不同的協議和消息格式與不同的醫療保健系統集成。然后，它需要通過統一的接口來轉換和規范化數據。集成層應根據某些策略在必要時清理和匿名化數據，有多個技術棧和框架可用于執行這個任務，比如一些領先的開源產品，如Apache Camel、Apache Synapse、Apache ServiceMix、Spring Integration和Ballerina。
API 管理組件由一組功能組成，包括高性能網關、用于身份驗證的密鑰服務器、用于限制和分析的事件處理器、用于顯示 API 列表的開發者門戶，以及用于許可管理的工作流引擎。一些流行的開源產品封裝了這些功能，包括WSO2 API Manager，Kong API Gateway和Tyk API Gateway。
出于概念驗證的目的，參考實現顯示了每種技術可以被用在什么地方。它偏向于開源平臺和框架，因為它們為不斷發展的平臺提供了很大的靈活性。
在這個實現中，API 管理器支持完整的 API 生命周期管理功能，包括 API 實現、管理、貨幣化、安全和路由 API 流量。這樣一來，來自公開 API 的請求可以通過 API 網關路由到集成組件。
參考實現考慮到了 API 的生命周期——一旦發布 API，就必須棄用以前的版本，并且必須通知訂戶。API 管理解決方案通過生命周期執行器來處理這個問題，因此每個 API 生命周期階段都可以與要采取的操作相關聯，如圖 5 所示。
API 安全也是主要的考慮因素，雖然身份驗證和授權是通過令牌完成的，但細粒度的授權是通過 OAuth 令牌作用域來實現的。作用域可以通過用戶組進行驗證，也可以通過健康數據消費者的一組屬性進行驗證，例如設備、位置等。
API 平臺可以控制如何向第三方公開數據，允許無限或受限訪問策略。API 管理平臺的限制引擎定義了與被允許的請求數和數據使用率相關的規則，并強制執行。
API 管理組件的開發者門戶提供了一個中央樞紐，可以在這里發現、試用和訂閱所有 API。開發者門戶提供了一個創新平臺，記錄了每個 API 可以使用的內容以及如何使用這些數據。開發者門戶對本文中描述的 API 進行分類，允許相關方訂閱這些 API 并將其集成到應用程序中。
API 管理分析提供了訪問最頻繁的 API 及其使用方式的視圖，為多個受眾提供了有用的見解。對于平臺維護人員來說，他們可以知道有關技術能力規劃的決策。API 用戶可以了解健康數據的可用性，API 提供商可以了解在哪里可以得到更多關于數據采集的信息。
一旦 API 調用將請求委托給解決方案的集成層，ApacheSynapse、Camel、Spring Integration 或 Ballerina 等框架就可以執行集成功能。一旦集成框架接收到請求，它將檢查本地注冊表條目，以確定醫院屬于哪個 EHR 系統。這些值可以存儲為文本字符串、XML 或 URL。這也可以通過在文件或數據庫中查找來實現。
通過本地條目檢查之后，將使用消息過濾器來執行驗證，檢查醫院名稱是否保存在本地注冊表條目中。如果未找到醫院，則會將故障信息作為錯誤消息發送回 API，表示該醫院不可用。
<inSequence>
<!--Obtain the value for the respected hospitalName parameter from the local registry-->
<propertyexpression="get-property($url:hospitalName)"name="ehrSystem"scope="default"type="STRING"xmlns:ns="http://org.apache.synapse/xsd"/>
<!--Check if the hospital-Name is located in the local registry entry-->
<filterxpath="boolean(get-property('ehrSystem'))">
<then>
...
</then>
<else>
<logdescription="Fault"level="custom"separator=",">
<propertyname="STATUS"value="Invoke fault "/>
</log>
<payloadFactorymedia-type="json">
<format>{ "Error":{ "errorType":"InvalidParameter","details":"The Hospital-Name parameter is invalid" } }
</format>
<args/>
</payloadFactory>
<propertyname="HTTP_SC"scope="axis2"type="STRING"value="400"/>
<respond/>
</else>
</filter>
</inSequence>代碼塊 1：使用Apache Synapse進行醫院名稱驗證
集成框架使用一個或多個連接器訪問來自不同 EHR 平臺的數據，從而允許用戶與第三方健康供應商（如 Epic、Cerner 等）進行交互。基于 EHR 系統，集成器將確定請求被路由到何處，并調用 Cerner 連接器或 Epic 連接器來獲取來自各自 EHR 系統的數據。
以下的 Synapse 配置（XML）用于初始化 Epic 和 Cerner 連接器并獲取診斷報告數據。
<switchsource="$ctx:ehrSystem">
<caseregex="Cerner">
<!--Initialize the Cerner Connector-->
<cerner.init>
<base>https://fhir-open.sandboxcerner.com/dstu2/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca</base>
</cerner.init>
<!--Search DiagnosticReport Operation→
<cerner.searchDiagnosticReport>
<patient>{$ctx:patient}</patient>
<subject>{$ctx:subject}</subject>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
<count>{$ctx:count}</count>
</cerner.searchDiagnosticReport>
<respond/>
</case>
<case regex="Epic">
<!--Initialize the Epic Connector-->
<epic.init>
<base>https://open-ic.epic.com/FHIR/api/FHIR/DSTU2</base>
</epic.init>
<!--SearchDiagnosticReportOperation→<epic.searchDiagnosticReport>
<id>{$ctx:id}</id>
<patient>{$ctx:patient}</patient>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
</epic.searchDiagnosticReport>
<respond/>
</case>
<default/>
</switch>代碼塊 2：使用Apache Synapse路由到相應的EHR系統
基于 EHR 系統檢索到的響應通過 API 網關發送到 API。
我們在前一節中討論的參考實現考慮到了一個簡單的場景，用以展示醫療保健 API 市場的實際使用。為了支持醫療保健行業的廣泛需求，可以對這個參考實現進行改進，包括：
隨著醫療保健服務和技術的發展，醫療保健 API 市場將在數字醫療行業中發揮主導作用。
Nuwan Bandara 是一名解決方案架構師，在集成和消息傳遞軟件項目上與財富 1000 強全球企業緊密合作。他是WSO2的董事，并且領導著北美的方案解決工程師團隊。Nuwan 致力于醫療保健、政府和金融行業的項目，簡化系統集成。他是一名程序員、演講者和作家。
Chanaka Fernando 是 WSO2 的解決方案架構師。他與金融、教育、醫療保健和電信等各個領域的企業客戶密切合作。他在 WSO2 的整合平臺團隊中擔任技術主管和產品負責人，這是他最長的一段職業生涯。
Sachini Samson 是斯里蘭卡信息技術學院的三年級軟件工程專業學生，目前正在 WSO2 進行軟件工程實習。Samson 是本文提到的參考實現的核心開發人員。
查看英文原文：Transforming the Healthcare Industry Through API Marketplaces
本文轉自《API 市場帶來了醫療保健行業的巨大轉變》，譯者：楊雷