首 頁不同規模的醫療機構如何選擇合適的集成平臺中間件
隨著國家對于醫療機構互聯互通要求和醫療大數據應用的不斷深入，建設集成平臺來實現醫療系統的流程再造和數據治理已然成為很具實踐價值的方式。此時集成平臺中的核心中間件（如ESB、集成引擎等）就非常重要了，因此怎么樣選擇適合自身情況和應用場景的集成技術和架構是醫療機構需要仔細考慮的。
“知己”- 分析自身情況和需求
機構規模：
醫療機構有二級、三級、集團醫院、區域、醫共體/醫聯體等，不同規模的機構涉及到的系統廠商也不一樣，比如：三級醫院相對二級醫院可能會涉及到更多的供應商和業務復雜度，區域、醫共體考慮可能更多是跨機構協同等。
機構承載的業務：
平臺和數據集成中間件承載的業務涉及到很多方面，比如是核心業務還是非核心業務，是否有涉及到大數據方面的對接，是否需要對接Kafka、MQ、IOT等方面的應用，在國家互聯互通標準化這塊是否有需求，對實時性、并發性、可用性的要求如何，等等。這些均需要考慮集成平臺中間件（集成引擎）本身的功能和性能是否匹配和滿足。
集成平臺的定位：
平臺建設的定位對于選擇集成平臺中間件（集成引擎）也很重要，是僅解決評級所需的業務場景，還是希望搭載大部分或者全部經由集成平臺核心中間件實現數據交換和集成的“真”集成業務。
另外，醫院對集成平臺建設項目要需要有規劃設計，如考慮適應機構短期目標（3到5年）還是長期的成長發展訴求。選擇集成平臺中間件（集成引擎）的時候就要考慮如何匹配、解決這些問題，這也使醫院在評估集成平臺中間件（集成引擎）的可持續發展和升級路線上能有一個更明確的方向。
“知彼”- 了解集成平臺中間件（集成引擎）具備的功能特性和性能
場景覆蓋度：
不同機構和業務對于集成平臺中間件（集成引擎）的技術訴求也會不同，有時候我們需要從HIS發消息到LIS、PACS等實現順序傳輸和保證消息送達，也會有從多個數據中心通過報告索引快速檢索患者報告的場景，也可能有數據同步等訴求。因此選擇集成平臺中間件（集成引擎）時，需要考慮其數據交換技術是否能覆蓋足夠廣的業務場景，是用ESB、IE（集成引擎）還是用ETL、MQ等。
易用性：
全流程中文支持：產品不僅開發時就設計了全中文界面，還具有純中文幫助文檔、使用手冊、視頻教程和純中文的售后技術支持服務。
易使用 - 開箱即用的純Web的開發、監控界面，會讓開發運維人員更容易接入使用。
易開發 - 拖拽的圖形化配置開發能提高效率，簡單易用的在線實時開發讓使用者對集成平臺中間件（集成引擎）具有更強的自主可控性和對需求的敏捷響應。
易運維 - 快速安裝和多維度的監控界面能夠實時觀察運行狀態，對于每個數據流轉和消息內容可精確定位和追蹤。
架構完整度和前瞻性：
一個產品的架構完整才能滿足在不同機構場景的適應，同時也不用擔心當機構業務成長，產品架構升級時所帶來的風險。集成平臺建設不是一蹴而就，剛開始可能承載業務不多或者需求不高，采用冷、熱備部署架構即可實現。隨著業務增長和機構角色所承擔的能力增強，性能和容災需求就需要產品過渡到集群化架構甚至是云原生架構，這時候就要求選擇的集成平臺中間件（集成引擎）能夠滿足這些訴求。
穩定可靠性：
據統計，穩定可靠一向是集成平臺支撐機構各業務運行和數據流轉重要的訴求之一。集成平臺中間件（集成引擎）是否經受過各類項目歷練和場景考驗，并且有足夠的自修復（Robustness）機制和避險機制，也是醫療機構需要考慮的。不同機構和承載業務在容災方面也是有不同選擇的，如果對于非核心類實時度不高業務完全可以用冷備方式承載，涉及部分核心業務并且響應也要及時的時候，則可采用熱備方式。當數據交換的業務量和消息量達到一定規模時，比如大三甲或者集團化醫院時，則選用原生設計實現的集群方式或云原生分布式集群架構會更可靠。
兼容性：
協議和技術的兼容對接及可擴展會讓開發人員進一步加快項目推進和規范化建設。HL7 V2、V3、FHIR、DICOM等醫療協議，Kafka、ZooKeeper等分布式應用，Hadoop、MongoDB等大數據，ActiveMQ、RabbitMQ等消息隊列，XMPP、MQTT等物聯網協議，符合國家互聯互通的CDA、數據集等標準組件...這些在規劃平臺建設時需要結合業務場景切實考慮。另外一旦有遇到非常特殊的對接需求，集成平臺中間件（集成引擎）是否具備這種擴展能力和服務支持也是機構需要留意的。
高性能：
產品自身性能：通過產品功能設計更好地提升單機性能，如內置的內存數據庫、添加分布式緩存等設計，減少與外部I/O交互，提高數據獲取速度。
橫向擴展：集成平臺中間件（集成引擎）也需要具備橫向擴展能力，通過添加計算節點大幅提升性能以應對高并發環境下的海量數據處理需求。
開放性和成熟度：
集成平臺中間件（集成引擎）作為中間件不應是黑箱運行，需要保證數據的透明可追溯。其自身的API和對消息記錄存儲的訪問也要有高度開放性，能助力醫院的技術人員快速上手使用，自主進行二次開發（如快速響應全國健康碼），使醫院真正接管平臺，實現對集成平臺中間件（集成引擎）的自主可控。
同時選擇時需要考慮產品成熟度，建議選擇有大量成功落地應用案例或主流HIT廠商使用的集成平臺中間件 。
除了以上幾個基本要素外，本土化非常重要，主要分為：
本土標準的適應性：
面對國際上大量醫療數據交換協議，部分國外的特有標準和法案并不適合國內環境，需要更有針對性地選用在國內實用度高的協議標準和規范，如國家在互聯互通中提出的CDA標準、數據集標準、交互服務標準以及編碼集，國密算法SM3、SM4等，并在滿足這些本土化標準要求的前提下，對于這些標準提供更細致，易用性更高的配套功能（如自帶相關標準的數據映射），讓集成平臺中間件（集成引擎）的每一個功能都真正體現出其應用價值而非淪為“作秀”工具。
另外隨著國家對于國產化服務器和操作系統的推廣和普及，集成平臺中間件（集成引擎）應該要兼容適應這種趨勢，比如對于Arm、Mips等CPU架構的支持，麒麟和UOS等操作系統的支持。
對項目實施人員的本土化支持：
國內項目壓力大，進度緊張，項目人員工作強度大，集成平臺中間件（集成引擎）如果提供全程中文界面和學習技術材料，會大大降低項目人員的負擔，將更多精力放在實現業務本身上。
另外國內開發運維的水平高低不一，集成平臺中間件（集成引擎）更應該兼具國內用戶習慣和醫療場景復雜多變等特點，針對性的提供良好工具。比如內嵌簡單的測試工具，提供Dispatcher功能等。
滿足當下和未來的政策標準：
隨著2020年互聯互通標準的出臺，也逐步對微服務化架構、API 網關等提出了要求，集成平臺中間件（集成引擎）是否具備上述標準中所需架構和功能，產品的成長發展是否緊跟國家政策甚至為新政策預先打好基礎并做好準備，也需要機構更細致地考慮和關注。
