HE與醫院信息系統集成技術研究
何雨生1 王力華1 王秀民1 孟兆斌2 靳罡2 王永輝3
1北京大學人民醫院醫學信息中心
2美國GE公司醫療部
3北京眾邦惠智公司
摘要：本文介紹了國際上醫療信息集成標準的進展，重點介紹了IHE有關集成的基本體系結構和互操作性問題，同時介紹了系統集成技術的進展和面向服務的體系結構，討論了其在醫學中的應用。在此基礎上，討論了北京大學人民醫院集成系統體系結構的設計方案。
關鍵字：醫院信息系統 系統集成 標準化 面向服務的體系結構 區域衛生信息系統
1. 簡介
隨著國內醫院建設的信息系統規模不斷發展，信息系統集成的需求越來越強烈。醫院信息系統集成的需求主要來自于以下幾個方面：
醫院不同子系統的集成需求。國內大型醫院信息化的需求十分復雜，單一HIS提供商無法滿足。隨著軟件專業化分工的發展，PACS/RIS、檢驗、財務、人事等系統得到獨立發展的機會；電子病歷的專業化發展對集成需求更為強烈和復雜。
醫療集團之間信息系統的集成需求。集團中不同醫院的信息系統可以是同構或異構的系統。只要不是使用同一個服務器和數據庫，就存在集成問題。即使使用同一數據庫，也有不同醫院病人的標志問題。
區域/國家衛生信息網中信息共享的需求。這種共享包括不同醫療機構之間信息共享，還有不同醫療機構與管理部門的信息共享。近年來發達國家投入巨資研究的國家衛生信息網，其核心內容就是電子病歷的互操作性，本質上就是集成問題。
由于近年信息化的集成需求，通用集成技術研究取得了長足的進展，其典型的三大技術是“企業應用集成（Enterprise Application Integration，EAI）技術”、“企業信息集成(Enterprise Information Integration, EII)技術”和“擷取、轉換和載入(Extract, Transform and Load, ETL)技術”[1]。隨著面向服務架構（Service Oriented Architecture，SOA）技術的發展，人們開始從軟件的體系結構上考慮系統的集成問題，甚至有人提出SOA將是集成的終結[2]，意思是人們從此將不用考慮集成的問題，軟件天生就是可分布的，可任意組合的。這種想法過于天真，但SOA代表了軟件的發展方向，HL7版本3已經使用了面向服務的思想分解醫院需求。當然，HL7版本3距離任意分步和任意組合功能的目標還差得很遠，也可能永遠達不到這個目標。
2. IHE集成與互操作性內容簡介
2.1. IHE簡介
IHE（Integrating the Healthcare Enterprise）是北美放射醫學協會(RSNA)和美國醫療衛生信息與管理系統協會(HIMSS)于1998年成立的組織[3]，其目標是促進醫療信息系統的集成, 為不同子系統之間的互連提供集成方案。IHE并不是定義新的集成標準,而是基于現有成熟的標準（例如DICOM、HL7和其他一些系統集成的行業標準）制定的一套集成方案。IHE定位在制定一套規范的流程，并通過DICOM、HL7等消息系統實現這種流程，以實現不同系統的集成。IHE集成規范目前的版本包括如下內容：
IHE技術框架－集成規范 版本6.0 2005.5發布
IHE技術框架－事務處理 版本6.0 2005.5發布
IHE技術框架－國家擴展 版本6.0 2005.5發布
IT基礎技術框架－集成規范 版本2.0 2005.8發布
IT基礎技術框架－事務 版本2.0 2005.8發布
實驗室技術框架－集成規范 版本1.1 2004.7發布
實驗室技術框架－事務 版本1.2 2005.2發布
心血管科技術框架－集成規范 版本2.0 2005.6發布（試用版）
心血管科技術框架－事務 版本2.0 2005.6發布（試用版）
IHE 患者診療協作 2005.10發布（試用版）
IHE技術框架和體系結構將醫療系統集成的公共部分抽象出來，用UML描述，例如一些標準流程和一些標準處理過程，其余規范則是針對具體應用領域制定的流程規范。在此我們重點討論集成的基本體系結構和互操作性問題。
2.2. MPI和PIX[4]
MPI（Master Patient Indexes）是醫院信息系統中病人基本信息的主索引，是唯一完整的病人標識，通常它只能由一個應用系統輸入，并對其它應用系統進行分發，以保證整個系統中病人基本信息的一致性。
國內一直沒有重視病人主索引的技術研究，目前還有很多HIS系統在病人主索引的設計中存在嚴重的問題，即使用病人門診和住院號作為病人的主索引，這種設計將帶來“災難性”的后果。因為病人門診和住院號一人多號問題普遍存在，為了病人信息的完整性和一致性，醫院需要將多號合并。如果HIS使用病人門診和住院號作為主索引，在合號過程中，HIS系統需要將變更號碼的所有記錄修改為新號，這將涉及多個表的多個記錄，很難修改完整，一旦出錯，有可能會導致收錯費或發錯藥的嚴重后果。另外，HIS數據量巨大，醫院不可能永遠將其保存在當前運行的數據庫中，需要將其遷移到過期數據備份服務器上，或者備份到磁帶上，理論上講，這些數據的主索引更本不可能再修改，因而必將破壞數據的一致性。過期數據的檢索和統計將受到影響。我們建議，醫院采購HIS時要將這個問題列為考核系統的重要指標，因為這是系統設計的重大問題，不可能通過維護修改解決。可喜的是，2006年全國醫院網絡大會收到了多篇討論MPI的文章，希望引起與會者的重視和討論[5][6][7][8]。
隨著醫療集團和區域衛生信息系統的發展，病人標識和病人主索引也引起了IHE的重視。2003年，IHE提出了PIX（Patient Identifier Cross－referencing Integration Profile）集成規范，其目的在于從多個產生病人標識符的應用中，實現病人標識的交叉引用。
以前，MPI沒有實現規范，實現起來比較混亂。PIX集成規范定義了實現MPI的一套流程規范，使用HL7標準實現。不同的應用系統遵循該規范，使用HL7消息，可以比較容易的加入到現有應用系統的MPI中。
在一個醫療集團中，不同醫院分別使用相同或不相同的HIS，使病人主索引的問題更為復雜。在一個醫院中，我們需要解決不同部門應用系統的病人標識問題，如放射、病理、B超檢查編號等。在醫療集團中，出現了同類系統不同病人標識問題。當然，我們仍然可以按照不同類型應用系統的處理方法，但這些數據沒有辦法匯總統計分析。當然，若要徹底解決問題，還要通過門診和住院系統的主索引結構實現。
2.3. XDS
2003年以后，IHE重點討論了互操作性(Interoperability)問題，提出了“跨機構文檔共享規范(Cross-Enterprise Document Sharing, XDS)”，以解決區域性的醫療信息共享問題。XDS主要為醫療機構之間的文檔共享的管理提供一個規范,這些醫療企業可以包括私人診所和門診部甚至是一個住院病人的緊急看護科室。圖1顯示醫生在聯網環境下遠程讀取病人資料，臨床信息系統通過訪問索引系統實現查找并讀取不同地點的病人文檔的過程。圖2介紹了XDS使用的其它標準，XDS自己沒有定義任何標準，只是一個臨床流程規范建議。因為流程具有很強的地域性，非常容易受人為因素影響，不可能強制統一。圖3介紹了在區域范圍內臨床文檔共享，文檔注冊、病人ID與病人主索引之間的關系。
目前各國都在積極建設自己的國家、區域衛生信息系統，這種系統的基礎模型就是XDS，因此應該引起各級衛生信息化規劃者的足夠重視。我們不能重走醫保系統建設的老路，在沒有研究、規劃、設計好的前提下匆忙建設，造成大量人力物力的浪費。一個大型醫院和醫療集團的需求模型與其相同，只是稍微簡單一些。
圖1. 區域衛生信息系統中基于XDS 的電子病歷交換
圖2. XDS使用的標準
圖3. 基于XDS規范的臨床文檔訪問流程
3. 系統集成技術進展
3.1. EAI基本概念
在集成方法學方面，近年來人們進行了大量的研究，企業應用集成(Enterprise Application Integration，EAI)[9]討論了集成的不同模型。其中，集成消息模型就是HL7、DICOM實現的基礎[圖4]。
圖4. 集成的消息模型
企業應用集成EAI（Enterprise Application Integration）被定義為：將進程、軟件、標準和硬件聯合起來，在兩個或更多的企業系統之間實現無縫集成，使它們就像一個整體一樣。實際就是研究異構系統互連的方法學。
從集成的內容上看，隨著集成的發展及人們對集成的不同需求，可以從幾個不同的層次去實現。分別是數據（Date）層，應用（Application）層及表示（Presentation）層，根據其實施機制分為四種集成模型，圖5介紹了不同的應用集成方法。其中數據集成主要是在不同的系統間傳遞數據，目前HL7的應用，主要還是用于數據集成。應用接口集成和方法集成是在不同的系統之間實現功能集成，傳統的功能集成很多通過遠程調用實現，Web Service在功能集成方面代表了最重要的發展方向。界面集成主要討論不同應用系統之間用戶界面的集成方法。HL7標準組織專門制定了界面集成的標準－CCOW，希望通過該標準讓不同的應用系統共同配合工作，自動同步顯示需要的數據。但CCOW在實際使用中還是碰到了很多問題，使用十分復雜，在實際中很少有醫院使用。
圖5. 應用集成的不同層次
從應用集成的系統集成結構來劃分，可以分為三種結構，分別是點對點的結構[圖6]、消息代理結構[圖7]和過程代理結構[圖8]。
圖6. 點對點結構 圖7. 消息代理結構 圖8. 過程代理結構圖
點對點方式是傳統的系統互連方式。實際上，HL7是基于點對點方式制定的互連標準。消息代理方式使用集成代理中間件實現。基于HL7的點對點集成方法只能夠解決互連標準化問題，不能夠簡化接口數量[圖9]。理論上講，如果需要互聯的子系統有N個，則完全互連的接口數量為(N-1)*N。如果使用集成代理中間件，則接口數量可以減少為N*2個[圖10]。集成代理中間件可以分成消息代理和過程代理兩種模式。消息代理模式通過消息傳遞機制實現系統互連，過程代理模式能夠支持系統的過程集成，可以通過過程代理中間件配置流程。當然，這種流程控制能力受限于應用邏輯和集成應用系統的設計，并不能達到任意配置的愿望。
圖9. 點對點互連模型 圖10. 集成代理中間件集成模型
3.2. EAI工具
我們以微軟公司的BizTalk Server為例介紹EAI工具。BizTalk Server 包括接收和發送適配器、接收和發送管道、編排組件、BizTalk Server 消息框和業務規則引擎[圖11]。在集成平臺中商務流程處于核心地位。在商務過程中需要進行信息交換，交換會在流程服務、MessageBox、連接應用的適配器之間進行。MessageBox是消息出版與訂閱的核心。BizTalk Server通過Adapter（適配器）與發送/接收管道以某種通訊協議發生實際的交互。通過BizTalk Server的消息機制，可以實現數據、過程集成，也支持Web Service的服務集成。
當然，類似的工具產品很多，如IBM的WebSpere、Web Logic、SeeBeyond等公司，都有類似的集成工具。
圖11. BizTalk Server工作原理圖
3.3. ETL和EII技術簡介
ETL技術主要面向數據倉庫的需求，將數據從多種數據源抽取、轉換和裝載到另一個數據庫中，包括數據集市和數據倉庫。但是，這種數據轉換整理的過程耗費大量的人力物力，否則很難適應復雜的數據分析需求。
|
|
資源大小：876.04 KB 
