根據斯坦福醫學2017年健康趨勢報告在過去的十年中，醫療健康行業捕獲的數據量大幅增長。這是由於例如政府採取了電子病歷（EMR）平臺、設備（X射線，MRI，CT等）對醫療記錄進行數字化，以及無處不在的個人健康/健身監視器（智能穿戴設備如Apple Watch等）。
接下來我們將討論如何使用API市場（包括其後面的一系列解決方案）作爲解決此問題的方法。通過API市場，管理者可以安全地開放或者部分開放這些數據（用戶的隱私數據和受到法律保護的信息不在描述範圍當中），使醫療行業的患者或醫療機構和公民都可以訪問這些數據，從而提高醫療健康行業的效率並實現人口健康技術的創新。
不是沒數據，而是數據太多
現今世界各地的許多醫療及健康機構都在記錄和總結醫療數據，並根據這些數據對患者下一步的醫療方案做出決策。這些數據通常保存在一個或多個EMR系統中。在絕大部分的情況下，很少能看到這類醫療數據可以作爲經濟數據來進行使用，有一部分原因是基於醫療道德及國家法律法規所限定，另一方面原因則是醫療機構基於經濟方面拒絕數據共享。
無法按完整原始數據進行共享的原因，主要來是國家政策和公共道德（如個人隱私）的結果。由於隱私原因，大多數國家/地區都有保護個人健康記錄的政策指令（如HIPAA）。因此，來自EMR的患者原始醫療數據不能也應該被公開。在多種因素的共同作用下，醫療數據在行業內變成一個個黑盒子，沒人能獲取到更多的信息，進而使得醫療技術發展受到了限制。
另一個被忽視的機會是醫療健康行業的科技發展潛力。在今天，中國國內的醫療技術或者醫療服務公司的數量，與國外相比較差距是非常大的，因爲行業整體進入的壁壘很高，而更重要的是，醫療數據（即使已經經過脫敏，不包含患者個人社會信息）訪問的障礙太大。如果健康醫療數據能夠以更加智能、可靠、安全的形式進行經濟化應用，那將爲整個醫療行業帶來一次重大的的創新浪潮，並使整個行業的所有從業者以及因此誕生的產品的使用者受益。
將API市場作爲解決方案
在當今世界，數據平臺已經成爲了衆多不同商業體系的運轉中心，而API作爲平臺的數據連接器起到了關鍵的作用。各行各業都開始積極採用API優先的系統開發方法，我們在醫療健康領域也能很明顯的看到這一點。一個健全的API市場可以解決醫療健康數據的商用問題，它將與數據使用者進行API社交，讓他們從數據當中獲取更多的信息，以便進行產品和技術的創新。API市場鼓勵醫療機構或者醫藥企業思考如何更好的使用和保管他們合法的研究數據，並通過高可用性的API計劃提供醫療數據，並進而產生效益。
從實際出發，醫療健康行業的API市場主要擔負的，是將醫療數據使用者和產生者建立起聯繫，而相應解決方案的最終願景，則是建立一個以API市場爲基礎，以醫療健康數據合法交易爲導向的經濟體。在這個經濟體當中，應該有一個全面的API管理平臺，它爲API市場概念提供了動力，而該平臺使數據供應商能夠設計，發佈和管理API，同時實施安全管理，數據應用治理和收集分析工作。
圖1：解決方案架構
通過該解決方案，我們可以瞭解醫療健康IT領域的整體需求（對於其他行業也有很大一部分數據或者API是有共通的用處）。當所有產品的開發者和管理者都在使用基於API管理解決方案時，數據供應商會將所獲得的合法的數據發佈在API市場上，有需要的企業則同時會在市場上聯繫他們感興趣的API供應商；API市場爲供應方和消費方搭建了一個開放而安全的價值交換渠道，使得數據消費方可以根據所獲得的數據產生更有價值或者有潛在價值的產品。
API市場該如何模塊分工
圖2：API市場角色及數據流向分析
API 生產者：指的是API的設計師、架構師、開發人員、測試人員、發佈人員。負責定義每一個API的應用範圍（內部使用，外部使用，使用限制和使用權利）。在大型醫療項目的API生產中，生產者可以來自不同的醫療組織機構或者是企業。
平臺擁有者：指的是API市場的維護及搭建人員。他們負責API市場模塊的維護，並促進API使用者之間的協作，並需要及時向API提供商報告消費者反饋。他們負責了整個API市場的平臺宣傳、支持和社區建設等任務。
API使用者/消費者：指的主要是應用程序開發，是願意利用醫療數據並從中獲取價值的創新者；同時，這指代的可能是健康發展項目、醫療健康創業公司、跨國衛生組織、醫院團體或者政府，他們熱衷於提高醫療健康水平，爲行業提供更好的醫療解決方案。
醫療健康API市場的組成
API的管理是平臺的基礎，它包含了API的網關、安全、管理、設計發佈以及分析部分。
API網關是整個平臺的入口，最終與實際數據後端EHR系統相連接。它與API安全模塊是密不可分的，另外它還將基於安全策略和令牌的信息爲整個API管理平臺提供支持服務。
鑑於API數據的敏感性，在開發、發佈、維護等每一個階段都需要進行強有力的管理——通過API管理系統和平臺管理者的維護，能夠很好的強化和控制API的使用，併爲管理者提供了良好的管理策略和使用模式。
開發人員在發佈API後，需要能夠持續監控、測試和管理已發佈的API，而API管理解決方案除了提供這些功能以外，還應該能夠針對API調用失敗，響應時間突然增加或API資源訪問模式等異常變化，提供建議解決方案併發出報警提醒。
圖3：Healthcare API市場的組件
實現技術的產品
在提出的解決方案中，我們將系統集成和API管理視爲兩個不同的必備組件，需要深思的是集成組件應該可以通過不同協議與各種醫療健康系統做到集成。在此之後，它還需要對數據進行轉換和規範化，進而提供一個統一的接口以供使用。在底層之上的集成層，應該根據管理者在API管理系統上設置的策略，對所有數據進行脫敏和匿名處理。當然，我們可以找到非常多不同的技術棧和框架達成此目的，比方說Apache Camel，Apache Synapse，Apache ServiceMix，Spring集成和Ballerina等等。
API管理模塊的組成主要有高性能的網關用於身份驗證的密鑰服務器，用於限制和分析的事件處理器，和用於API列表的開發人員門戶以及用於職稱管理的工作流引擎。一些流行的開源產品封裝了這些功能，包括GoKu API Gateway、Kong API Gateway和Tyk API Gateway。
一個可參考的實施方案
下圖是對我們所描述的框架進行了整合，並標出了可以使用這些技術選項的地方。這個圖偏向於開源平臺和其他框架，這爲後期平臺的發展和功能的定製提供了極大的靈活性。
圖4：具有技術選擇的實現架構
在此實現中，API管理系統提供了API全生命週期管理的功能，包括API使用、管理、商業化，數據安全和路由API管理，而API請求則將通過API網關發送到管理平臺。
參考圖的方案同時兼考慮了API的生命週期 - 一旦新API發佈，那麼就必須棄用先前版本，並且將通知到所有API訂閱者。API解決方案應當可以通過內部設置處理此問題，因此在API生命週期的每個階段都應可以與該階段對應的操作相關聯，如圖5所示。
圖5：示例API生命週期視圖
API的安全性是整個API管理體系首要考慮的因素。雖然身份驗證和授權是通過密鑰或令牌完成的，但是更高級的權利應當是通過OAuth令牌的對應信息進行授權應用的。該信息可以是高級用戶組的確認驗證，也可以是關於數據使用者的屬性判斷，也可以是例如使用者的設備或者地理位置等。
圖6：爲API操作應用授權OAuth範圍的示例
API管理平臺應當可以控制通過何種方式向第三方公開數據，例如允許無限制訪問或受限制策略限制。而於此同時，API管理平臺也應該能對請求數量和速率進行相應的規則限制。
圖7：如何將限制策略應用於API訂閱的示例視圖
API管理平臺應當可以控制通過何種方式向第三方公開數據，例如允許無限制訪問或受限制策略限制。而於此同時，API管理平臺也應該能對請求數量和速率進行相應的規則限制。
圖8：具有Patient / Provider FHIR API的開發人員門戶的示例視圖
API管理系統的分析功能提供了最常見的API使用數據視圖，爲不同的使用者提供了有足夠客觀性的數據。而對於平臺維護者來說，這可以爲相關技術設備升級規劃的決策提供更多的資料和信息。這樣的好處是，API消費者可以進一步瞭解健康數據的可用性和重要性，而API提供商則可以提供和數據採集有關的更多數據。
圖9：醫療保健 API分析視圖示例
在國內的API接口管理工具中，能完整實現API管理全流程並且體驗較好的平臺和工具就是 EOLINKER了，包括接口文檔編輯、API測試、自動化測試和API監控和API網關等功能，能體驗到完整的API研發方案。而國外的諸如POSTMAN、Swagger功能也很強大，但是前者注重測試，後者注重接口管理，可能並不全面，而且全英的語言對國人也不是很友好。因此有需求或者感興趣可以各自了解下 EOLINKER、POSTMAN、Swagger。有需求或者感興趣的可以到官網瞭解下 EOLINKER。
未來的改進
我們在上面的討論中模擬了一個簡單的場景，以展示醫療健康API市場的實際用途。不單單是醫療健康類API，所有API都可以從基於API管理解決方案的基礎上，提供更多的價值。數據從來都不應該是封閉的，只有充分的利用數據本身的價值，讓其在更多的機構、創業者手中得到靈活運用，才能創造出更大的價值。一方面可以讓數據提供方獲得更多的服務，另一方面則可以促進服務創新發展。
值得關注的其中一點是，在有效的利用API進行服務創新和價值創新的同時，我們要對API的安全性投入更多的關注，而隨着社會的進步發展，API經濟將逐步被人們所重視，API的管理和使用將會在各行各業的發展中發揮更大的作用。
參考資料：Sachini Samson，Transforming the Healthcare Industry through API Marketplaces，https://dzone.com/articles/api-life-cycle-basics-api-management