內容導讀
近年來，在電子病歷應用水平評級要求以及醫(yī)院在不同業(yè)務間實現(xiàn)協(xié)同等多種因素的推動下，集成平臺成為各大型醫(yī)院信息化建設中重點的項目。
“醫(yī)療信息系統(tǒng)集成”并不是一個全新的詞匯，早在十幾年前就已經(jīng)在醫(yī)院信息化的浪潮中初露端倪，也有一些敢于“吃螃蟹”的醫(yī)院開始嘗試建設自己的集成平臺。這些年，在國家衛(wèi)健委的互聯(lián)互通標準化測評推動下，集成平臺作為參評的“必要條件”進入眾多醫(yī)院信息化建設的優(yōu)先發(fā)展名單，經(jīng)過了行業(yè)化的不斷論證和實踐，取得了飛躍式的發(fā)展。
對于集成平臺，很多HIT行業(yè)領域的專家人士都有精辟獨到的見解。本系列文章會從我們公司集成平臺的建設、過程、經(jīng)驗、應用、成果等五個部分展開，向大家分享我院一路走來的集成平臺實踐經(jīng)驗，希望能夠為更多醫(yī)院信息化同仁提供借鑒和些許參考。
本文將圍繞醫(yī)院集成平臺的資源需求以及其對 IT 基礎架構的要求展開討論，并給出基于超融合架構的方案配置參考與傳統(tǒng)架構的對比分析。
圖：集成平臺總體架構圖
隨著醫(yī)院信息化建設的不斷完善，醫(yī)院逐步上線了 HIS、EMR、PACS、LIS 等多個業(yè)務系統(tǒng)。
由于這些業(yè)務系統(tǒng)由不同廠家開發(fā)，各個系統(tǒng)擁有不同的操作系統(tǒng)、數(shù)據(jù)庫，進而導致不同業(yè)務系統(tǒng)之間需求調用復雜、接口數(shù)量多且無統(tǒng)一標準、數(shù)據(jù)交互效率低下、維護困難等問題。
集成平臺的重要性在于，其不僅能夠在各個系統(tǒng)之間實現(xiàn)統(tǒng)一集成和交互，同時為數(shù)據(jù)集成提供了可能。
通過將各個系統(tǒng)產(chǎn)生的數(shù)據(jù)集中存儲并重新組織形成醫(yī)院的數(shù)據(jù)倉庫，集成平臺為下一步數(shù)據(jù)分析創(chuàng)造條件，即充分挖掘數(shù)據(jù)價值進而形成一系列數(shù)字化應用支撐智能化決策，幫助醫(yī)院實現(xiàn)真正數(shù)字化轉型?？梢哉f，集成平臺是醫(yī)院數(shù)字化轉型的重要基礎。
在部署集成平臺時，醫(yī)院需要清晰了解集成平臺的架構，從平臺的實際需求出發(fā)，并結合醫(yī)院資源池建設的整體規(guī)劃，為集成平臺選擇合適的基礎架構。
醫(yī)院集成平臺的實現(xiàn)方案有很多種，早期以接口調用集成方案為主，但這種方案集成效率較低，后期逐漸轉向企業(yè)服務總線（ESB）為主要框架。
可根據(jù)客戶的請求和事件提供路由，數(shù)據(jù)轉換、翻譯等服務。
具有快速、并行的消息處理能力。
無法保證消息或服務請求的順序，而醫(yī)院業(yè)務之間調用大多有嚴格處理順序要求。
不支持國際醫(yī)療標準，不利于醫(yī)療數(shù)據(jù)上報、醫(yī)療機構之間的數(shù)據(jù)交互。
ESB 引入消息隊列軟件處理服務請求順序的問題、改造 ESB 支持醫(yī)療標準協(xié)議等方案雖然在一定程度上實現(xiàn)了 ESB 的優(yōu)化，但存在方案極其復雜，開發(fā)難度過大，成本過高等問題，可見在集成平臺建設中，單憑 ESB 軟件是無法完全滿足業(yè)務的需求。
經(jīng)過多年的發(fā)展與試錯，醫(yī)院集成平臺逐步形成了以 ESB（企業(yè)服務總線）、IE（集成引擎）、ETL 工具三種技術組合而成的搭建方案。
如上圖所示，集成平臺的集成工作主要包括兩個部分：應用集成和數(shù)據(jù)集成。
應用集成主要實現(xiàn)各個業(yè)務系統(tǒng)之間的請求和調用，由 ESB 和 IE（集成引擎）兩部分組成；其中 ESB 負責同步數(shù)據(jù)處理操作，IE 集成引擎負責異步數(shù)據(jù)處理。
ESB 充分發(fā)揮并行處理優(yōu)勢，實時、高效地處理系統(tǒng)之間的請求。
IE 集成引擎支持以 HL7、CDA 等國際醫(yī)療標準協(xié)議交互，提供消息異步處理機制，解決重視次序的服務調用需求。
國內集成平臺常用的集成引擎方案如下表所示?？梢钥闯?，國內的集成平臺廠商大多采用國外成熟的 ESB 企業(yè)服務總線產(chǎn)品/集成引擎產(chǎn)品。
常見 ESB/集成引擎 產(chǎn)品的系統(tǒng)要求和數(shù)據(jù)庫支持情況如下：
數(shù)據(jù)集成主要任務是將醫(yī)院各個系統(tǒng)所產(chǎn)生的數(shù)據(jù)集中，清洗，并以新的組織結構進行存儲，形成醫(yī)院數(shù)據(jù)倉庫，以便后續(xù)對數(shù)據(jù)進行分析，挖掘和利用。
ETL 是 extract-transform-load 三個數(shù)據(jù)處理過程的縮寫：
數(shù)據(jù)抽取（Extract）：連接各個業(yè)務系統(tǒng)數(shù)據(jù)庫，抽取數(shù)據(jù)庫日志和事務數(shù)據(jù)。
數(shù)據(jù)轉換（Transform）：抽取數(shù)據(jù)后，對數(shù)據(jù)進行驗證、清洗、根據(jù)規(guī)則執(zhí)行轉換。
數(shù)據(jù)加載（Load）：將處理好的數(shù)據(jù)加載到目標數(shù)據(jù)庫。
理論上， ETL 工具可從生產(chǎn)業(yè)務系統(tǒng)的數(shù)據(jù)庫直接抽取數(shù)據(jù)并轉換數(shù)據(jù)，但這種方式會對生產(chǎn)數(shù)據(jù)庫帶來較大壓力，直接影響業(yè)務系統(tǒng)響應速度。為了解決這個問題， ETL 過程會先將數(shù)據(jù)完封不動地抽取到中間數(shù)據(jù)庫（臨時庫），數(shù)據(jù)轉換、數(shù)據(jù)加載都會發(fā)生在臨時庫中，以最大程度上降低對生產(chǎn)數(shù)據(jù)庫的影響。
量體裁衣，平臺運行環(huán)境和架構是什么？
集成平臺運行在vSphere虛擬化集群環(huán)境，虛擬化集群由6臺X86架構的華為RH5885服務器和一套CHANGHONG CNX400 2存儲組成。邏輯主機的配置為windows server 2008 R2 64位，64G內存，E7-4830四核四處理器，500G的磁盤空間。常態(tài)情況的CPU利用率為20%，內存平均利用率為70%左右。從硬件運行環(huán)境而言，集成平臺不需要非常高的硬件配置，其對內存消耗比較大，主要是緩存線程的使用。
圖：集成平臺服務器內存使用率
集成平臺的核心技術架構是ESB(Enterprise Service Bus的簡稱，中文翻譯為企業(yè)服務總線)。在這里，我們把企業(yè)服務總線在醫(yī)療衛(wèi)生行業(yè)內特定的實現(xiàn)稱之HSB(健康服務總線,Health Service Bus),這些特定的實現(xiàn)包括了醫(yī)療行業(yè)特殊的協(xié)議和標準，例如：信息交換標準HL7,醫(yī)學數(shù)字成像和通信標準DICOM等。
我司集成平臺采用基于電子病歷的醫(yī)院信息平臺進行各系統(tǒng)間的業(yè)務及數(shù)據(jù)集成，主要通過服務總線(DHC-ESB)完成系統(tǒng)間的業(yè)務協(xié)同，通過主數(shù)據(jù)管理（DHC-MDM）完成數(shù)據(jù)標準的管理，通過臨床數(shù)據(jù)中心（CDR）完成數(shù)據(jù)的整合。
圖：集成平臺總體架構圖
我院集成平臺的內部架構采用的是InterSystems Ensemble，HSB是其運行的邏輯架構，InterSystems Ensemble平臺的內部架構如圖所示：
圖：Ensemble平臺的內部架構
Ensemble的內部架構由三個主要的構件組成，分別是：BS、BP、BO。
業(yè)務服務（BusinessService）簡稱BS，是Ensemble中所有外部請求/外部數(shù)據(jù)的入口。Ensemble中內置了多種常用的導入型適配器供開發(fā)人員在BS中直接使用，其中包括并不限于SOAP、SQL、HTTP、File、FTP、HL7等。
業(yè)務流程（BusinessProcess）簡稱BP，是Ensemble中的業(yè)務處理模塊，在BP中可以實現(xiàn)數(shù)據(jù)轉換、數(shù)值對照以及根據(jù)規(guī)則引擎做出的消息分發(fā)等功能，BP是Ensemble的中樞，由各種不同類型BS進入的數(shù)據(jù)，經(jīng)過BP的處理，最終通過各種不同類型的BO流出Ensemble。
業(yè)務操作（BusinessOperation）簡稱BO，是Ensemble對外發(fā)送請求或數(shù)據(jù)的出口，Ensemble中內置了多種常用的導出型適配器（OutboundAdapter）供開發(fā)人員在BO中直接使用，其中包括并不限于SOAP、SQL、HTTP、File、FTP、HL7等。
通過打開Ensemble的消息路徑圖，我們可以監(jiān)測每一條消息的運行狀態(tài)和路徑，通過此圖，我們可以一目了然的看到消息是如何在平臺內部運行的。
圖：Ensemble的消息路徑圖
3.集成平臺能做什么？
集成平臺基于SOA（Service-Oriented Architecture，面向服務的架構），無侵入式設計，不改變現(xiàn)有信息系統(tǒng)的運行，由集成平臺完成各類業(yè)務數(shù)據(jù)的采集、轉發(fā)、解析、存儲和使用管理。集成平臺管理層提供業(yè)務日志、事件日志、業(yè)務規(guī)則日志、端到端的消息跟蹤業(yè)務監(jiān)控功能，實現(xiàn)在開發(fā)階段的有效調試以及運行期間的故障診斷分析，利用集成平臺的故障可追溯機制，管理員可快速定位導致異常的環(huán)節(jié)。
圖：標準字典維護模塊
圖：基于HL7的標準文檔CDA
圖：消息日志
通過集成平臺，其他業(yè)務系統(tǒng)可以很容易的對接到集成平臺的業(yè)務流程中來，通過集成平臺的數(shù)據(jù)集成和業(yè)務集成，各個系統(tǒng)繼承已有的數(shù)據(jù)和服務，降低了各個子系統(tǒng)之間的高耦合性。
4.集成平臺是如何實現(xiàn)業(yè)務互通的？
集成平臺通過Ensemble的“注冊－發(fā)布－訪問”機制對醫(yī)院信息平臺各種共享服務資源進行注冊與發(fā)布，從而實現(xiàn)服務資源共享及粗粒度應用服務之間的互操作。其核心是建立基于消息引擎的院內集成平臺服務總線(HSB)，通過基于SOAP（Simple Object Access Protocol，簡單對象訪問協(xié)議）的WebServices、HL7消息等將各系統(tǒng)與業(yè)務系統(tǒng)(HIS、EMR、PACS等)對接，并實現(xiàn)患者就醫(yī)流程的閉環(huán)處理。第三方系統(tǒng)通過集成平臺獲取所需信息并將回傳信息返回給集成平臺。
當某個業(yè)務需要某個應用程序將數(shù)據(jù)發(fā)送給另一個方應用時，由該程序向平臺發(fā)送一個消息，經(jīng)過平臺對消息進行接收和處理(BS中定義)，按照平臺預先設計好的消息流程(BP中定義)，調用目標系統(tǒng)的服務，通過此服務將消息內容寫入目標業(yè)務系統(tǒng)中。在此過程中，業(yè)務系統(tǒng)不需要考慮目標系統(tǒng)的數(shù)據(jù)結構是否與自己一致，也不需要鏈接對方的數(shù)據(jù)庫（比如采用視圖，存儲過程的方式調用目標系統(tǒng)）。只需要將消息發(fā)送給平臺，再由平臺完成后續(xù)的流程。平臺的BO能通過輸出適配器，API，或者其他方式來訪問Ensemble外部應用。
圖：集成平臺內部業(yè)務流程處理
5.集成平臺的主要作用
總體而言，集成平臺主要解決了以下幾個問題:
第一：兼容多個異構系統(tǒng)，并快速進行對接，使各個業(yè)務系統(tǒng)之間的數(shù)據(jù)可以交互。
第二：通過平臺交互，統(tǒng)一患者就診檔案。
第三：以集成平臺為基礎，可逐步建立區(qū)域級的信息平臺,從而使發(fā)展區(qū)域醫(yī)療，集團化醫(yī)院有了技術上的保證。
第四：同時，能夠采集海量的臨床數(shù)據(jù)，為醫(yī)院的教學科研工作奠定基礎。
Copyright ? 2022 上?？评讜狗沼邢薰?旗下「智慧醫(yī)療網(wǎng)」版權所有 ICP備案號：滬ICP備17004559號-5
