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

醫(yī)院集成平臺(tái)的不同建設(shè)階段

　　階段一：滿足院內(nèi)的數(shù)據(jù)集成/業(yè)務(wù)集成等基本需求

　　該階段的大多數(shù)醫(yī)院以院內(nèi)需求或是互聯(lián)互通測(cè)評(píng)作為契機(jī)，初步接觸并開(kāi)始使用集成平臺(tái)。在建設(shè)集成平臺(tái)時(shí),也以滿足院內(nèi)的數(shù)據(jù)集成/業(yè)務(wù)集成需求，升級(jí)點(diǎn)對(duì)點(diǎn)的系統(tǒng)架構(gòu)為主，并結(jié)合互聯(lián)互通測(cè)評(píng)要求，搭建起一個(gè)基本的集成框架。

　　以門(mén)診預(yù)約掛號(hào)業(yè)務(wù)場(chǎng)景的集成為例，其中包括了掛號(hào)、退號(hào)、信息注冊(cè)、信息查詢、注銷(xiāo)等功能。信息查詢要求響應(yīng)速度快，有同步處理要求，響應(yīng)時(shí)間不能超過(guò)3秒。對(duì)于查詢的內(nèi)容能夠根據(jù)業(yè)務(wù)變更靈活調(diào)整;而預(yù)約掛號(hào)業(yè)務(wù)對(duì)于響應(yīng)要求不高，但是需要保證消息的傳輸以及傳輸時(shí)的順序，因此在應(yīng)用端的預(yù)約和取消預(yù)約通過(guò)異步進(jìn)行處理，結(jié)果信息的接收可通過(guò)發(fā)短信或刷新實(shí)現(xiàn)查詢。

　　因此在這個(gè)場(chǎng)景中，查詢類業(yè)務(wù)適合通過(guò)ESB實(shí)現(xiàn)，而預(yù)約掛號(hào)類業(yè)務(wù)適合通過(guò)集成引擎實(shí)現(xiàn)。在處理一個(gè)外部入口的所有請(qǐng)求時(shí)，需要根據(jù)具體業(yè)務(wù)中數(shù)據(jù)的傳輸模式要求不斷進(jìn)行調(diào)整，滿足集成的基本需求。

　　階段二：針對(duì)集成需求實(shí)現(xiàn)便捷的自主開(kāi)發(fā)，拓展集成平臺(tái)功能邊界

　　該階段醫(yī)院對(duì)集成平臺(tái)的使用已經(jīng)有了一定的了解，在使用集成平臺(tái)的過(guò)程中也有了自己的體會(huì)和想法。醫(yī)院會(huì)慢慢將主要系統(tǒng)遷移至集成平臺(tái)上，業(yè)務(wù)系統(tǒng)與集成平臺(tái)數(shù)據(jù)交互也越發(fā)緊密，消息吞吐量在百萬(wàn)量級(jí)，集成平臺(tái)逐漸從“潤(rùn)滑劑”變?yōu)樾畔①Y源整合的“主動(dòng)脈”。

　　這個(gè)階段醫(yī)院也需要通過(guò)集成平臺(tái)自主實(shí)現(xiàn)一些需求的開(kāi)發(fā)和部署。如果醫(yī)院難以掌控集成平臺(tái)，則不得不通過(guò)廠商添加功能或易用性模塊這種“打補(bǔ)丁”的方式才能解決需求。

　　以 “健康碼”的開(kāi)發(fā)為例，疫情之初各地醫(yī)院都需要快速響應(yīng)全國(guó)“健康碼”的推廣，在Odin引擎的助力下，傳統(tǒng)接口模式下需要2-3天的開(kāi)發(fā)工作，某集團(tuán)化三甲醫(yī)院信息部門(mén)一位熟練的技術(shù)人員1小時(shí)內(nèi)就自主完成了全部服務(wù)部署。

　　同時(shí)，由于醫(yī)院逐漸意識(shí)到了一體化對(duì)于醫(yī)院信息化建設(shè)的重要性，各系統(tǒng)之間的邊界也將越來(lái)越模糊，集成平臺(tái)將不僅僅作為滿足醫(yī)院集成需求的工具，也會(huì)根據(jù)醫(yī)院需求拓展出更多的功能。

　　以API的管理為例，API網(wǎng)關(guān)服務(wù)應(yīng)用，具有鑒權(quán)管理、流量控制、黑白名單、訪問(wèn)控制等API管理功能，能提升接口管理方面的用戶體驗(yàn)，但也常常需要對(duì)集成平臺(tái)進(jìn)行二次開(kāi)發(fā)才能實(shí)現(xiàn)該功能。

　　階段三：支撐瞬時(shí)超高并發(fā)環(huán)境下的大規(guī)模集成建設(shè)

　　5G的到來(lái)和醫(yī)聯(lián)體/醫(yī)共體的建設(shè)加速了醫(yī)療信息互聯(lián)互通的進(jìn)程，更高速率、更低延時(shí)和更多設(shè)備的接入，以及部分系統(tǒng)和外網(wǎng)的直連意味著數(shù)據(jù)處理量存在瞬時(shí)激增的可能，這對(duì)于平臺(tái)在短時(shí)間內(nèi)的擴(kuò)展能力提出了極高的要求，傳統(tǒng)的集成引擎所具備的性能和穩(wěn)定性由于難以支撐此類瞬時(shí)超高并發(fā)的環(huán)境而導(dǎo)致卡頓甚至宕機(jī)，則會(huì)導(dǎo)致“打補(bǔ)丁”現(xiàn)象不斷發(fā)生。

Odin明確的產(chǎn)品升級(jí)路線圖，解決醫(yī)院集成平臺(tái)不同階段的“打補(bǔ)丁”難題

　　Odin針對(duì)醫(yī)院不同的集成階段，提供了從AlwaysOn企業(yè)版到集群版再到Odin NeXT云原生平臺(tái)的三個(gè)產(chǎn)品解決方案，這條非常明確的升級(jí)路線圖可以有效保護(hù)醫(yī)院的基礎(chǔ)投資，避免醫(yī)院在集成平臺(tái)建設(shè)中由于平臺(tái)性能、穩(wěn)定性、功能不如預(yù)期而陷入“打補(bǔ)丁”或推翻重來(lái)的困局。

　　1.Odin引擎AlwaysOn企業(yè)版

　　Odin引擎 AlwaysOn 企業(yè)版除了解決了國(guó)內(nèi)用戶對(duì)于聯(lián)互通測(cè)評(píng)支持、產(chǎn)品容災(zāi)性、易用性等多個(gè)常見(jiàn)問(wèn)題，滿足院內(nèi)的數(shù)據(jù)集成/業(yè)務(wù)集成等基本需求外，還額外具有強(qiáng)大的高可用功能和易用性，其中包括：

　　產(chǎn)品內(nèi)置的主備容災(zāi)環(huán)境，無(wú)需依托任何外部高可用技術(shù)，服務(wù)無(wú)感知切換(亞秒級(jí)別切換時(shí)間);

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

　　統(tǒng)一界面的多人協(xié)同開(kāi)發(fā)，統(tǒng)一配置管理，統(tǒng)一監(jiān)控管理，統(tǒng)一數(shù)據(jù)管理，醫(yī)院在進(jìn)行自主開(kāi)發(fā)、日常運(yùn)維時(shí)更加便捷易用。

　　2.Odin引擎集群版

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

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

　　界面一體化：統(tǒng)一的開(kāi)發(fā)、測(cè)試、管理、運(yùn)維和監(jiān)控界面;

　　組件一體化：控制組件、運(yùn)行組件、API網(wǎng)關(guān)、用戶鑒權(quán)等融為一體;

　　功能一體化：DevOps、態(tài)勢(shì)感知、服務(wù)熔斷、事件驅(qū)動(dòng)等功能;

　　管理一體化：容器微服務(wù)、單點(diǎn)登錄、流量控制、黑白名單、訪問(wèn)控制。

　　Odin引擎集群版還引入OpenApi、RAM等能力組件，具有統(tǒng)一運(yùn)維監(jiān)控、智能化部署、定向隔離負(fù)載計(jì)算、態(tài)勢(shì)感知、熔斷保護(hù)、跟蹤埋點(diǎn)、DevOps發(fā)布機(jī)制等功能特點(diǎn)，為大型醫(yī)療衛(wèi)生機(jī)構(gòu)提供“功能完備、持續(xù)穩(wěn)定、高能可靠”的大規(guī)模數(shù)據(jù)交換和業(yè)務(wù)集成能力。

　　3.Odin NeXT云原生平臺(tái)

　　Odin NeXT云原生平臺(tái)在具備集群版功能特點(diǎn)的基礎(chǔ)上融入高并發(fā)、高可用的云原生技術(shù)架構(gòu)，前瞻性地實(shí)現(xiàn)單場(chǎng)景微服務(wù)和基于Kubernetes的容器動(dòng)態(tài)化分布式PaaS部署等特性，實(shí)現(xiàn)了最佳的系統(tǒng)高性能、高可用、高穩(wěn)定;具有高資源利用率，動(dòng)態(tài)彈性擴(kuò)展，隨業(yè)務(wù)負(fù)載波動(dòng)的資源適配和場(chǎng)景項(xiàng)目間隔離等特性，為超大規(guī)模云應(yīng)用，實(shí)現(xiàn)APIs快速開(kāi)發(fā)和接口化服務(wù)提供準(zhǔn)開(kāi)發(fā)平臺(tái)和純Web一體化運(yùn)維工具。

結(jié)語(yǔ)

　　醫(yī)院集成平臺(tái)建設(shè)要有切實(shí)可行的發(fā)展路徑，作為集成平臺(tái)的核心中間件，產(chǎn)品本身也要有著明確成熟的升級(jí)路線圖為醫(yī)院集成平臺(tái)的建設(shè)規(guī)劃提供支撐，才能讓醫(yī)院用的更加放心，走出頻繁“打補(bǔ)丁”的困局。

　　(本文由ODIN公司供稿)