隨著醫院信息化建設不斷深入，功能和需求越來越多，醫院對集成平臺的要求也越來越高，為了滿足要求不得不采用“打補丁”的方式添加功能，改造接口等。但是如果能更好地理解集成平臺建設的不同階段，提前做好準備，采用合適產品，則能很大程度上避免陷入“打補丁”的困局。

醫院集成平臺的不同建設階段

　　階段一：滿足院內的數據集成/業務集成等基本需求

　　該階段的大多數醫院以院內需求或是互聯互通測評作為契機，初步接觸并開始使用集成平臺。在建設集成平臺時,也以滿足院內的數據集成/業務集成需求，升級點對點的系統架構為主，并結合互聯互通測評要求，搭建起一個基本的集成框架。

　　以門診預約掛號業務場景的集成為例，其中包括了掛號、退號、信息注冊、信息查詢、注銷等功能。信息查詢要求響應速度快，有同步處理要求，響應時間不能超過3秒。對于查詢的內容能夠根據業務變更靈活調整;而預約掛號業務對于響應要求不高，但是需要保證消息的傳輸以及傳輸時的順序，因此在應用端的預約和取消預約通過異步進行處理，結果信息的接收可通過發短信或刷新實現查詢。

　　因此在這個場景中，查詢類業務適合通過ESB實現，而預約掛號類業務適合通過集成引擎實現。在處理一個外部入口的所有請求時，需要根據具體業務中數據的傳輸模式要求不斷進行調整，滿足集成的基本需求。

　　階段二：針對集成需求實現便捷的自主開發，拓展集成平臺功能邊界

　　該階段醫院對集成平臺的使用已經有了一定的了解，在使用集成平臺的過程中也有了自己的體會和想法。醫院會慢慢將主要系統遷移至集成平臺上，業務系統與集成平臺數據交互也越發緊密，消息吞吐量在百萬量級，集成平臺逐漸從“潤滑劑”變為信息資源整合的“主動脈”。

　　這個階段醫院也需要通過集成平臺自主實現一些需求的開發和部署。如果醫院難以掌控集成平臺，則不得不通過廠商添加功能或易用性模塊這種“打補丁”的方式才能解決需求。

　　以 “健康碼”的開發為例，疫情之初各地醫院都需要快速響應全國“健康碼”的推廣，在Odin引擎的助力下，傳統接口模式下需要2-3天的開發工作，某集團化三甲醫院信息部門一位熟練的技術人員1小時內就自主完成了全部服務部署。

　　同時，由于醫院逐漸意識到了一體化對于醫院信息化建設的重要性，各系統之間的邊界也將越來越模糊，集成平臺將不僅僅作為滿足醫院集成需求的工具，也會根據醫院需求拓展出更多的功能。

　　以API的管理為例，API網關服務應用，具有鑒權管理、流量控制、黑白名單、訪問控制等API管理功能，能提升接口管理方面的用戶體驗，但也常常需要對集成平臺進行二次開發才能實現該功能。

　　階段三：支撐瞬時超高并發環境下的大規模集成建設

　　5G的到來和醫聯體/醫共體的建設加速了醫療信息互聯互通的進程，更高速率、更低延時和更多設備的接入，以及部分系統和外網的直連意味著數據處理量存在瞬時激增的可能，這對于平臺在短時間內的擴展能力提出了極高的要求，傳統的集成引擎所具備的性能和穩定性由于難以支撐此類瞬時超高并發的環境而導致卡頓甚至宕機，則會導致“打補丁”現象不斷發生。

Odin明確的產品升級路線圖，解決醫院集成平臺不同階段的“打補丁”難題

　　Odin針對醫院不同的集成階段，提供了從AlwaysOn企業版到集群版再到Odin NeXT云原生平臺的三個產品解決方案，這條非常明確的升級路線圖可以有效保護醫院的基礎投資，避免醫院在集成平臺建設中由于平臺性能、穩定性、功能不如預期而陷入“打補丁”或推翻重來的困局。

　　1.Odin引擎AlwaysOn企業版

　　Odin引擎 AlwaysOn 企業版除了解決了國內用戶對于聯互通測評支持、產品容災性、易用性等多個常見問題，滿足院內的數據集成/業務集成等基本需求外，還額外具有強大的高可用功能和易用性，其中包括：

　　產品內置的主備容災環境，無需依托任何外部高可用技術，服務無感知切換(亞秒級別切換時間);

　　拖拽式、圖形化的操作界面，做到了所見既所得，大大減少了操作人員的工作量;

　　統一界面的多人協同開發，統一配置管理，統一監控管理，統一數據管理，醫院在進行自主開發、日常運維時更加便捷易用。

　　2.Odin引擎集群版

　　Odin引擎集群版原生實現一體化集群架構(Controller+Worker)，并非單機系統部署在多臺虛擬機上形成的“集群”(其核心仍是單機架構)。除支持業務集成和數據集成外，作為平臺的核心中間件，Odin引擎集群版能助力醫院集成平臺實現“五個一體化”—— 數據集成技術一體化、界面一體化、組件一體化、功能一體化、管理一體化。

　　數據集成交換技術一體化：融合集成引擎、IE、ESB、MQ等多種技術;

　　界面一體化：統一的開發、測試、管理、運維和監控界面;

　　組件一體化：控制組件、運行組件、API網關、用戶鑒權等融為一體;

　　功能一體化：DevOps、態勢感知、服務熔斷、事件驅動等功能;

　　管理一體化：容器微服務、單點登錄、流量控制、黑白名單、訪問控制。

　　Odin引擎集群版還引入OpenApi、RAM等能力組件，具有統一運維監控、智能化部署、定向隔離負載計算、態勢感知、熔斷保護、跟蹤埋點、DevOps發布機制等功能特點，為大型醫療衛生機構提供“功能完備、持續穩定、高能可靠”的大規模數據交換和業務集成能力。

　　3.Odin NeXT云原生平臺

　　Odin NeXT云原生平臺在具備集群版功能特點的基礎上融入高并發、高可用的云原生技術架構，前瞻性地實現單場景微服務和基于Kubernetes的容器動態化分布式PaaS部署等特性，實現了最佳的系統高性能、高可用、高穩定;具有高資源利用率，動態彈性擴展，隨業務負載波動的資源適配和場景項目間隔離等特性，為超大規模云應用，實現APIs快速開發和接口化服務提供準開發平臺和純Web一體化運維工具。

結語

　　醫院集成平臺建設要有切實可行的發展路徑，作為集成平臺的核心中間件，產品本身也要有著明確成熟的升級路線圖為醫院集成平臺的建設規劃提供支撐，才能讓醫院用的更加放心，走出頻繁“打補丁”的困局。

　　(本文由ODIN公司供稿)