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