如今建設集成平臺逐漸成為醫院實現信息整合、數據共享乃至各異構系統信息的無縫銜接的主要方法之一，本文分享了筆者在長治醫學院附屬和平醫院近年來醫院集成平臺的建設歷程和體悟，供各位業內同仁參考。

平臺建設的歷程

　　長治醫學院附屬和平醫院成立于1946年7月1日，是一所具有悠久歷史和光榮革命傳統的紅色醫院，也是山西省1995年首批通過評審的綜合性三級甲等醫院。

　　1.2015年：伊始，初探

　　2015年以前，我院HIS系統(包括收費、住院登記、護理站、藥房、藥庫等)的開發和維護，很多系統接口以及數據上報等工作，都是由醫院自己負責。但是此類點對點的系統對接方式存在大量、重復的接口工作，而且是網狀交互，出現一個問題涉及到交互雙方，也難以追溯問題的源頭。同年，醫院的CIS升級，PACS系統上線，我院改變了傳統的點對點接口的方式，自行采用C#開發了一套簡單的接口集成平臺，新上線的業務接口采用星型方式、服務拆分、抽象接口的方式進行集成，并收到了良好成效。與此同時，我院在做預約掛號業務時接觸到了第三方廠商使用的開源ETL工具Kettle。同年，由于全國互聯互通的數據集成上報，發現上級要求提供從2003年到2010這些年的數據，無論哪個系統，一提數據就幾乎是死機狀態，因為每個數據都是幾十個G的業務量，而通過excel、access等進行少量數據復制、粘貼的方式，數據量大了根本不可行。于是我們決定開始通過Kettle進行數據的抽取與上報，收到了良好的效果，效率和開發的便捷性都得到了很大的提升。

　　2.2018年：雙平臺，規范化

　　隨著系統越來越多，接口集成越來越復雜，工作量也越來越大。同時各種評測要求以及業務擴展方面的需求也紛至沓來。2018年以后，我院開始用Kettle嘗試做業務集成，主要方式是將業務事件采用事件表的方式進行拆分規范化，然后對業務事件的處理抽象化為對一個個事件數據流的處理，并將接口方式統一化為簡單的表讀寫及存儲過程的調用，極大簡化和降低了接口對接工作及成本。但是此模式也存在很多弊端，如穩定性不夠，問題排查比較難，尤其在監控跟蹤這塊，日志追溯欠缺很多。于是在2019年我院引入了集成平臺，明確了業務集成(采用集成平臺核心引擎)和數據集成(采用Kettle工具)的雙平臺概念，即邏輯上兩套平臺，實際上是一套平臺。

　　3.2019年：全院，互聯互通

　　2019年，以全院HIS系統切換為契機，我們也開始將業務集成服務逐步遷移到集成平臺上。隨著對平臺的熟悉，逐漸發現這種架構和工具的優勢，不僅功能很友好，并且穩定性要比Kettle好多了。于是在2020年開始對醫院全部業務進行遷移，開啟了我院真正的ESB之旅，并且按照互聯互通標準進行標準化改造。

　　截至目前，集成平臺已經穩定運行了700多天，證明了平臺能在高強度、高負載、業務多、數據量大的系統處理需求下保證高可用。平臺接入了69個項目，534個終端，日消息量方面，接收量是26萬條，發送量是45萬條。歷史總接收量是8232萬，歷史發送消息總數1.3億條。

　　4.2022年—未來：深化，擴展

　　未來隨著醫聯體、醫共體建設的推進和業務、系統的不斷增加，對平臺的性能和穩定性等方面也將有更高要求，我院計劃：在功能方面對集成平臺進行更深入的挖掘(例如統一界面的多人協同開發、嘗試通過容器技術實現業務的微服務化);在架構方面根據集成平臺的核心中間件在產品設計時已經預設的升級路徑，在需要時平滑快速地將集成平臺升級為集群架構，甚至是性能更強的云原生平臺，為今后醫院業務的大規模擴展夯實基礎。

集成平臺建設中的體會和感悟

　　1.醫院層面

　　(1)放得下——分清角色

　　由于我院地處山西，相比沿?；虬l達城市信息化人才資源比較少，想實現完全自研開發人手不足，且成本較高。因此需要轉變觀念、分清角色，專業的事需要由專業的人來做。醫院則是做好監管工作，在日常運維中使用簡單、學習比較容易的集成平臺產品功能滿足業務場景需求，提升工作效率。

　　(2)拿得起——提高自主權

　　集成平臺不能為了評級過級而建，而是為了醫院的業務集成標準化規范化建真正集成“平臺”，借助該平臺來促進醫院的信息化建設。專業的事應該由專業的人來做，該放手的放手，該抓住的也要抓住，對于醫院的業務來說，整個“醫療業務流程設計規劃”這個專業的事情就要由醫院信息部門(專業的人)來做，醫院信息部門要有主導和掌控能力。集成平臺僅僅只是“工具”，醫院要了解這個工具適合做什么，了解到、了解透，平臺工具用在何處，怎樣使用，怎樣發揮工具的最大效率這是醫院的信息化部門所深思熟慮的，這樣在信息化建設過程中才能避免無論大小事都要找廠商、被廠商牽著鼻子走，真正建好符合地域背景、醫院背景的“集成平臺”。

　　(3)兩手抓——理論實踐相結合

　　醫院需要有自己思想、熟悉工具，將理論和實踐聯系起來，比如：日常運維中曾經遇到體檢系統影像結果回傳不了，以前每次定位問題查詢要花10多分鐘，借助集成平臺核心引擎內置的功能自主開發做個小工具解決，不僅開發過程(開發測試1個小時)很快很方便，效果也非常好，做出來后提供查詢服務讓用戶自己查?？梢娂梢娈a品提供的不僅是基本的集成平臺能力，還是一個強有力的工具，還有著更多能力及應用場景待醫院日常發掘。

　　(4)多思考——先思而后行

　　無論大小項目，前期一定要先規劃好設計好再開始動手，掌握好經典的二八原則，前期考慮的越完善，后期節約的時間越多。

　　(5)慎選型——選對合適的工具很重要

　　工欲善其事必先利其器，用合適的工具在信息化建設過程中可以起到事半功倍的效果。在醫院平臺建設過程中，我們將集成分離成業務集成和數據集成兩部分，針對業務集成重點考慮的是集成的及時準確可追溯，針對數據集成重點考慮的則是數據的量級及傳輸效率，針對不同的兩個應用場景，我們分別用了集成平臺核心引擎(業務)和Kettle(數據)兩種不同的集成工具和方式，并收到了良好的成效，將來也計劃讓平臺的核心引擎承擔更多集成業務。

　　(5)勿拖延——核心遺留問題“今日事今日畢”

　　項目初期時需要盡可能減少核心遺留問題，而非拖到日后再進行優化，因為一旦上線再改造成本很高，帶來的業務中斷風險也大，“日后優化”就會慢慢變成“不優化”。因此核心問題盡量在事前進行解決，做到“今日事今日畢”。

　　2.產品層面

　　(1)簡單易用的工具

　　集成產品作為工具應該能非常簡單的上手使用，例如我院的集成平臺能支持各種終端或者路由，有很多封裝好的工具，可以很方便地去做這種數據庫終端、WEB服務終端、HTTP終端等，還能通過傻瓜式的界面拖拽方式實現開發和運維，快速便捷，不僅能幫助醫院解決人手問題，還提升了開發效率、縮短開發周期等。還是專業的事情交給專業的工具去做，在對第三方的接口開發適配效率成本等方面，集成引擎給我們帶來了質的飛躍。

　　(2)完備的基礎功能

　　集成平臺的基礎功能也必不可少，例如在標準對接上，符合HL7、互聯互通等標準格式，相當于通過核心引擎在集成平臺上把這些標準一層一層加上了，對于其他第三方的系統是完全不知情且無感知的，但最終在集成平臺上的標準就越來越先進、越來越標準化了。用戶使用的過程中越簡單有效，其背后的設計及技術支撐越復雜。

　　(3)前瞻的集成架構

　　好的軟件公司能夠有一定前瞻性，不僅能讓醫院在當下用好平臺，更應該有前瞻性，能讓醫院在未來也能用好平臺，例如集成消息引擎，解決消息的重復消費;實現對最新國際數據互操作標準FHIR的支持等;架構上也要有非常明確的升級路線圖，可以保護基礎投資，不用通過打補丁的方式進行平臺性能和穩定性等方面的升級。實現醫院信息化集成的可持續的快速發展，為醫院信息化建設提供有力的支持，提升信息部門的公信力。

結語

　　想要真正建設好集成平臺，離不開醫院和平臺產品兩方面的共同努力。醫院不僅需要了解平臺“品性”，更需要在建設過程中不盲目跟風，清楚自身業務訴求，并且有自己的想法和思路。產品方面也盡可能簡單易用，在保證集成平臺基本功能的基礎上，最好有一定的前瞻性，為醫院今后的發展打好“地基”。

　　作者簡介

　　黃明清，軟件設計師，管理科學與工程碩士，長治醫學院附屬和平醫院醫學信息中心副主任