国产三级黄色毛片,国产成人精品男人的天堂538 ,夜夜夜爽爽爽久久久

圖1：解決方案體系結(jié)構(gòu)

通過描述上面的解決方案，我們可以對醫(yī)療保健 IT 領(lǐng)域的利益相關(guān)者有所了解。工程師和業(yè)務(wù)領(lǐng)導(dǎo)者擁有數(shù)據(jù)訪問渠道標準化和治理的平臺；一些利益相關(guān)者會產(chǎn)生需要發(fā)布的數(shù)據(jù)，因此他們會聯(lián)系感興趣的相關(guān)方；有些利益相關(guān)者為最終用戶建立價值渠道。這些利益相關(guān)者聚合多個數(shù)據(jù)源并創(chuàng)建有價值的產(chǎn)品，然后由最終用戶消費這些數(shù)據(jù)并得出結(jié)論、做出決定。

API 市場的利益相關(guān)者

API 生產(chǎn)者群體 涵蓋了負責(zé)設(shè)計、開發(fā)、發(fā)布和測試醫(yī)療保健 API 的設(shè)計師、架構(gòu)師、醫(yī)療保健產(chǎn)品開發(fā)人員和 API 測試人員，這個小組負責(zé)定義 API 范圍（內(nèi)部、外部、限制和授權(quán)）。在大型醫(yī)療保健 API 數(shù)據(jù)交換中，生產(chǎn)者可以來自不同的醫(yī)療保健機構(gòu)。

平臺擁有者群體 保證了 API 市場的正常運作，他們維護組件，促進 API 使用者之間的協(xié)作，并向 API 生產(chǎn)者提供使用者的反饋。他們承擔了平臺宣傳、平臺支持和社區(qū)建設(shè)等任務(wù)。

API 使用者群體 來自應(yīng)用程序的開發(fā)社區(qū)。他們是愿意利用醫(yī)療數(shù)據(jù)并從中獲取價值的創(chuàng)新者。他們可以是人口健康驅(qū)動的倡議者、醫(yī)療保健初創(chuàng)企業(yè)、醫(yī)療保健機構(gòu)、醫(yī)院集團和政府，熱衷于改善多方面的醫(yī)療保健環(huán)境。

醫(yī)療保健 API 市場的組件

成功的醫(yī)療保健 API 市場應(yīng)該包含三個方面的東西：

API 管理
開發(fā)者門戶
活動

API 管理 是這個平臺的基本要素，解決了跨領(lǐng)域的架構(gòu)問題。它封裝了運行庫（網(wǎng)關(guān)）、安全層、治理層、分析層和許可管理層。

API 網(wǎng)關(guān)的運行庫充當了平臺的入口點，最終與實際數(shù)據(jù)后端的 EHR 系統(tǒng)連接。它與安全層無縫集成，提供基于令牌的安全性和基于策略的授權(quán)。

鑒于通過這些 API 公開的數(shù)據(jù)的敏感性，API 市場為 API 的開發(fā)、發(fā)布和全生命周期維護提供了強有力的治理是至關(guān)重要的。API 的暴露方式、人員驅(qū)動的治理模型、策略管理和依賴性分析都是通過 API 治理層來控制的。

開發(fā)人員發(fā)布 API 后，他們應(yīng)該能夠監(jiān)控、測量和管理已發(fā)布的 API，此功能由 API 的分析組件提供。除了基于批處理的分析之外，該層還可以為 API 調(diào)用失敗、響應(yīng)時間突然增加或 API 資源訪問模式變更等方案創(chuàng)建警報。

許可管理層實現(xiàn)工作流程，確保為數(shù)據(jù)共享、存儲和使用提供必要的許可。這是策略驅(qū)動的，有時依賴于基于機器的決策或人為參與。

開發(fā)者門戶 發(fā)布 API。它讓所有相關(guān)方都能夠發(fā)現(xiàn)可用的數(shù)據(jù)流并了解如何使用它們。開發(fā)者門戶解決了醫(yī)療平臺健康數(shù)據(jù)的可見性問題。所有專門的醫(yī)療保健系統(tǒng)都可以在由提供者機構(gòu)、醫(yī)院或公共醫(yī)療保健交易所維護的中央開發(fā)者門戶中檢索 API。

使用技術(shù)組件構(gòu)建一個出色的 API 市場只是整個過程的一部分，為了建立成功的醫(yī)療保健 API 市場，平臺所有者可以參與以下這些活動：

研討會——研討會為 API 消費者提供了一個教育平臺，可以解決一些入門問題。主題應(yīng)包括：如何在醫(yī)療監(jiān)管范圍內(nèi)使用數(shù)據(jù)？采用哪些安全協(xié)議和策略？許可管理如何運作？
激勵性黑客攻擊——建立市場的主要目標之一是實現(xiàn)醫(yī)療保健領(lǐng)域的創(chuàng)新，激勵性黑客攻擊被認為是朝這個方向移動的一個推動因素。平臺所有者可以托管黑客攻擊，并根據(jù)健康數(shù)據(jù)產(chǎn)生新的想法。
布道——內(nèi)部和外部的布道使平臺更受歡迎。
排行榜和分析儀表板——展示創(chuàng)新項目、啟動產(chǎn)品并提供 API 使用模式的可視化。

醫(yī)療保健 API

市場中的 API 可以根據(jù)其消費模式進行產(chǎn)品分類。在醫(yī)療保健領(lǐng)域，常見的模式包括患者注冊、調(diào)度、財務(wù)和計費、保險、臨床、輔助、公共健康和物聯(lián)網(wǎng)。

注冊 API

注冊 API 用來管理與 EMR 系統(tǒng)相關(guān)的注冊功能。通過這些注冊 API，開發(fā)人員可以開發(fā)與不同 EMR 系統(tǒng)進行集成的接口，用來管理患者特定的數(shù)據(jù)交換。身份驗證和授權(quán)是這些 API 的關(guān)鍵需求，因為它們提供了與消費者數(shù)據(jù)相關(guān)的所有后續(xù)活動的入口。API 市場中的 API 管理層可以為這些 API 活動提供關(guān)鍵的安全構(gòu)造。

調(diào)度 API

調(diào)度 API 的功能包括：安排預(yù)約、發(fā)送預(yù)約提醒、檢查預(yù)約時間段以及更新、取消或重新安排預(yù)約。調(diào)度是醫(yī)療保健市場中常用的功能之一，它與各種系統(tǒng)（包括賬單、消息和通知）集成在一起。API 網(wǎng)關(guān)運行庫以及集成層可以在這些系統(tǒng)之間提供所需的橋梁，從而為患者提供輕松的調(diào)度體驗。

財務(wù) API

財務(wù) API 用來管理護理提供者機構(gòu)和各當事方之間的資金交易。這些財務(wù) API 可以進一步細分，例如可以分為計費 API、索賠 API 等。醫(yī)療保險在醫(yī)療保健行業(yè)的財務(wù)部門發(fā)揮著重要作用。索賠管理系統(tǒng)有助于檢查索賠狀態(tài)、取消或調(diào)整以及自動付款過賬，它公開的 API 使支付方能夠連接到合作伙伴系統(tǒng)。安全性是這些 API 的關(guān)鍵需求之一，特別是強身份驗證和授權(quán)。為了支持其中的一些需求，需要有一個能夠與外部身份提供者（IDP）交互的 API 管理平臺。

臨床 API

臨床 API 將基于不同的標準（如 HL7v2、HL7v3 和 FHIR）通過 EHR/EMR 系統(tǒng)來管理臨床數(shù)據(jù)交換。成熟的 API 平臺具有數(shù)據(jù)格式轉(zhuǎn)換功能，因此它可以連接到多個系統(tǒng)，并根據(jù)使用者的要求提供數(shù)據(jù)傳送。這些系統(tǒng)包括一些特殊的數(shù)據(jù)流，如患者用藥數(shù)據(jù)、治療計劃、免疫詳細信息和家庭病史，醫(yī)生利用這些數(shù)據(jù)來決定病人的健康狀況。患者可以借助 API 驅(qū)動的以患者為中心的應(yīng)用程序來查看他們的藥物、診斷和病史。這樣可以鼓勵患者更多地參與個人健康診斷，也符合公共醫(yī)療政策，例如“有意義使用”政策。

輔助 API

輔助 API 用來管理與核心臨床功能（如藥房、實驗室、放射科等）相分離的系統(tǒng)的信息。這里有一些示例，包括與外部藥房就用藥處方和續(xù)藥請求進行通信、用不同的信息系統(tǒng)交換實驗室結(jié)果的數(shù)據(jù)，以及用外部營養(yǎng)系統(tǒng)來管理膳食訂單。通過安全通道（B2B）與外部系統(tǒng)連接是這些 API 的關(guān)鍵需求，支持各種安全協(xié)議（如 OAuth2、SAML、OIDC）的 API 管理系統(tǒng)將有助于與這些第三方系統(tǒng)安全連接。

公共健康 API

公共健康 API 可以用于指導(dǎo)通過交換公眾、聯(lián)邦或?qū)I(yè)注冊機構(gòu)可報告臨床數(shù)據(jù)來跟蹤公共健康。這些 API 能夠提供公共衛(wèi)生監(jiān)督所需的數(shù)據(jù)。公共健康 API 向政府和其他研究機構(gòu)提供存儲在電子病歷（EMR）中的臨床健康數(shù)據(jù)，并從這些機構(gòu)獲取數(shù)據(jù)，以豐富本地的臨床記錄。這兩項事務(wù)都是在給定的標準下進行的，以確保健康數(shù)據(jù)的隱私。當提供此類數(shù)據(jù)流時，API 運行庫可以對記錄進行清洗和去識別化，以確保這些數(shù)據(jù)是匿名的，這是一個成熟 API 運行庫必備的實用功能之一。

物聯(lián)網(wǎng)/活動跟蹤 API

近年來，可穿戴健康/活動監(jiān)測設(shè)備呈指數(shù)增長。這些數(shù)據(jù)流開啟了個人健康監(jiān)控的新維度，通過可消費的平臺公開這些流，可以加速以患者為中心的健康應(yīng)用程序的創(chuàng)新。

技術(shù)選擇

在所提議的解決方案中，我們將系統(tǒng)集成和 API 管理視為兩個不同的組件，需要經(jīng)過深思熟慮的分析。集成組件應(yīng)該通過不同的協(xié)議和消息格式與不同的醫(yī)療保健系統(tǒng)集成。然后，它需要通過統(tǒng)一的接口來轉(zhuǎn)換和規(guī)范化數(shù)據(jù)。集成層應(yīng)根據(jù)某些策略在必要時清理和匿名化數(shù)據(jù)，有多個技術(shù)棧和框架可用于執(zhí)行這個任務(wù)，比如一些領(lǐng)先的開源產(chǎn)品，如Apache Camel、Apache Synapse、Apache ServiceMix、Spring Integration和Ballerina。

API 管理組件由一組功能組成，包括高性能網(wǎng)關(guān)、用于身份驗證的密鑰服務(wù)器、用于限制和分析的事件處理器、用于顯示 API 列表的開發(fā)者門戶，以及用于許可管理的工作流引擎。一些流行的開源產(chǎn)品封裝了這些功能，包括WSO2 API Manager，Kong API Gateway和Tyk API Gateway。

參考實施

出于概念驗證的目的，參考實現(xiàn)顯示了每種技術(shù)可以被用在什么地方。它偏向于開源平臺和框架，因為它們?yōu)椴粩喟l(fā)展的平臺提供了很大的靈活性。

在這個實現(xiàn)中，API 管理器支持完整的 API 生命周期管理功能，包括 API 實現(xiàn)、管理、貨幣化、安全和路由 API 流量。這樣一來，來自公開 API 的請求可以通過 API 網(wǎng)關(guān)路由到集成組件。

參考實現(xiàn)考慮到了 API 的生命周期——一旦發(fā)布 API，就必須棄用以前的版本，并且必須通知訂戶。API 管理解決方案通過生命周期執(zhí)行器來處理這個問題，因此每個 API 生命周期階段都可以與要采取的操作相關(guān)聯(lián)，如圖 5 所示。

API 安全也是主要的考慮因素，雖然身份驗證和授權(quán)是通過令牌完成的，但細粒度的授權(quán)是通過 OAuth 令牌作用域來實現(xiàn)的。作用域可以通過用戶組進行驗證，也可以通過健康數(shù)據(jù)消費者的一組屬性進行驗證，例如設(shè)備、位置等。

圖 6：為 API 操作應(yīng)用授權(quán) OAuth 作用域的示例

API 平臺可以控制如何向第三方公開數(shù)據(jù)，允許無限或受限訪問策略。API 管理平臺的限制引擎定義了與被允許的請求數(shù)和數(shù)據(jù)使用率相關(guān)的規(guī)則，并強制執(zhí)行。

API 管理組件的開發(fā)者門戶提供了一個中央樞紐，可以在這里發(fā)現(xiàn)、試用和訂閱所有 API。開發(fā)者門戶提供了一個創(chuàng)新平臺，記錄了每個 API 可以使用的內(nèi)容以及如何使用這些數(shù)據(jù)。開發(fā)者門戶對本文中描述的 API 進行分類，允許相關(guān)方訂閱這些 API 并將其集成到應(yīng)用程序中。

API 管理分析提供了訪問最頻繁的 API 及其使用方式的視圖，為多個受眾提供了有用的見解。對于平臺維護人員來說，他們可以知道有關(guān)技術(shù)能力規(guī)劃的決策。API 用戶可以了解健康數(shù)據(jù)的可用性，API 提供商可以了解在哪里可以得到更多關(guān)于數(shù)據(jù)采集的信息。

一旦 API 調(diào)用將請求委托給解決方案的集成層，ApacheSynapse、Camel、Spring Integration 或 Ballerina 等框架就可以執(zhí)行集成功能。一旦集成框架接收到請求，它將檢查本地注冊表條目，以確定醫(yī)院屬于哪個 EHR 系統(tǒng)。這些值可以存儲為文本字符串、XML 或 URL。這也可以通過在文件或數(shù)據(jù)庫中查找來實現(xiàn)。

通過本地條目檢查之后，將使用消息過濾器來執(zhí)行驗證，檢查醫(yī)院名稱是否保存在本地注冊表條目中。如果未找到醫(yī)院，則會將故障信息作為錯誤消息發(fā)送回 API，表示該醫(yī)院不可用。

<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進行醫(yī)院名稱驗證

集成框架使用一個或多個連接器訪問來自不同 EHR 平臺的數(shù)據(jù)，從而允許用戶與第三方健康供應(yīng)商（如 Epic、Cerner 等）進行交互。基于 EHR 系統(tǒng)，集成器將確定請求被路由到何處，并調(diào)用 Cerner 連接器或 Epic 連接器來獲取來自各自 EHR 系統(tǒng)的數(shù)據(jù)。

以下的 Synapse 配置（XML）用于初始化 Epic 和 Cerner 連接器并獲取診斷報告數(shù)據(jù)。

<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路由到相應(yīng)的EHR系統(tǒng)

基于 EHR 系統(tǒng)檢索到的響應(yīng)通過 API 網(wǎng)關(guān)發(fā)送到 API。

未來的改進

我們在前一節(jié)中討論的參考實現(xiàn)考慮到了一個簡單的場景，用以展示醫(yī)療保健 API 市場的實際使用。為了支持醫(yī)療保健行業(yè)的廣泛需求，可以對這個參考實現(xiàn)進行改進，包括：

與個人數(shù)字健康設(shè)備集成；
與第三方醫(yī)療保健服務(wù)提供商集成；
構(gòu)建以患者為中心的移動應(yīng)用程序；
與醫(yī)療保健研究機構(gòu)集成，提供有價值的數(shù)據(jù)。

隨著醫(yī)療保健服務(wù)和技術(shù)的發(fā)展，醫(yī)療保健 API 市場將在數(shù)字醫(yī)療行業(yè)中發(fā)揮主導(dǎo)作用。

作者簡介

Nuwan Bandara 是一名解決方案架構(gòu)師，在集成和消息傳遞軟件項目上與財富 1000 強全球企業(yè)緊密合作。他是WSO2的董事，并且領(lǐng)導(dǎo)著北美的方案解決工程師團隊。Nuwan 致力于醫(yī)療保健、政府和金融行業(yè)的項目，簡化系統(tǒng)集成。他是一名程序員、演講者和作家。

Chanaka Fernando 是 WSO2 的解決方案架構(gòu)師。他與金融、教育、醫(yī)療保健和電信等各個領(lǐng)域的企業(yè)客戶密切合作。他在 WSO2 的整合平臺團隊中擔任技術(shù)主管和產(chǎn)品負責(zé)人，這是他最長的一段職業(yè)生涯。

Sachini Samson 是斯里蘭卡信息技術(shù)學(xué)院的三年級軟件工程專業(yè)學(xué)生，目前正在 WSO2 進行軟件工程實習(xí)。Samson 是本文提到的參考實現(xiàn)的核心開發(fā)人員。

查看英文原文：Transforming the Healthcare Industry Through API Marketplaces

本文轉(zhuǎn)自《API 市場帶來了醫(yī)療保健行業(yè)的巨大轉(zhuǎn)變》，譯者：楊雷