醫療信息集成交換是解決醫療信息互操作性與信息孤島的有效方法,是醫療信息共享的基礎。本文以醫療文本與醫學影像信息為集成對象,以DICOM和HL7消息、數據集為集成交換單元,以高效的DICOM、HL7消息構建與解析方法為基礎,設計并實現了一種通用的醫療信息集成交換服務中間件。實驗表明,原型系統能夠實現數據庫、DICOM、HL7消息之間的集成與交換,為解決醫療信息孤島提供了可行方案,為建立統一的醫療信息集成與共享平臺打下了良好的基礎,并在云南省社會發展科技計劃項目"開放式醫療信息集成系統開發與示范"中得到了應用。
引用本文： 黃冕, 劉利軍, 熊馨, 范洪博, 賈連印, 湯守國. 基于HL7與DICOM的醫療信息集成交換服務中間件. 生物醫學工程學雜志, 2015, 32(4): 815-820. doi: 復制
版權信息： ?四川大學華西醫院華西期刊社《生物醫學工程學雜志》版權所有，未經授權不得轉載、改編
引言
隨著醫療信息化建設的深入變革與飛速發展，衛生行政管理部門和醫療機構在管理模式、信息需求、臨床應用、教學及科研等方面提出了更高要求。任何一個軟件提供商都不可能為一個醫院提供滿足需求的全線產品。不同產品結構不同，實現方式各異，軟硬件環境差異也很大，這些產品大都成了一個個“信息孤島”，難以實現醫療信息的實時交換，導致整體業務不能協調一致。因此，標準化的醫療信息集成交換已成為21世紀醫療服務發展的必然趨勢。2009年4月，中共中央國務院頒布了《關于深化醫藥衛生體制改革的意見》，將信息化作為“四梁八柱”中的一大支柱，明確提出了“建立實用共享的醫藥衛生信息系統 ”的要求[1]。
HL7 (Health Level Seven)標準致力于將醫療信息傳輸的某些關鍵數據集合的格式和協議標準化，將HL7標準發展成為國際間通用的醫療信息交換標準。基于HL7的醫療信息交換中間層軟件的研究與開發變得非常重要。DICOM (Digital Imaging and Communications in Medicine)標準定義了醫學圖像在存儲和通信過程中的各種實體和關系，所有DICOM設備都可以按照DICOM標準進行互相連接和操作。國內外學者對基于HL7與DICOM的信息集成交換進行了一系列研究。Tran等[2]開發了基于HL7的醫療設備通信中間件，實現了醫療設備之間的信息交換；Blazona等[3]通過HL7和DICOM標準來完成放射科系統與醫療保健系統的集成。De Meo等[4]在多Agent系統中通過HL7標準來支持對e-Health的個性化訪問。Alam等[5]設計并實現了基于HL7 V3版本的服務軟件系統；Yang等[6]設計并實現了一個基于HL7與DICOM標準的網關系統；張蘭華等[7]基于HL7標準，在醫院內部及醫院之間實現醫療平臺的數據交換與共享。喬聰聰等[8]以HL7 CDA (Clinical Document Architecture)文檔為基礎，設計了基于衛生部數據集標準的CDA模板，采用Web Service方式實現了異構信息系統之間的信息共享和業務聯動。沈劍峰等[9]通過HL7 CDA技術初步實現了電子病歷的信息共享；李昂等[10]基于HL7標準實現了HIS (Hospital Information System)與PACS (Picture Archiving and Communication Systems)、RIS (Radiation Information System)的集成。陳靜等[11]基于HL7醫療信息交換標準和Web Service技術，解決了醫院信息共享問題；吳壽剛等[12]介紹了HL7標準及其在國內外的應用現狀，從HL7版本選擇和基于HL7集成方式選擇兩個方面指出了HL7在國內的發展趨勢；鄭建立等[13]基于HL7標準為醫療儀器提供了統一的HI 7標準接口，解決了醫療儀器與信息系統的集成；董方杰等[14]參考IHE (Integrating the Heahhcare Enterprise)技術框架，立足于HL7標準，闡述了醫療信息院內交互與區域共享的整體架構，實現了區域醫療信息的集成。上述研究成果推進了HL7與DICOM的研究與應用，但大多是針對特定系統，解決特定問題，其性能與通用性有待進一步提高。
本文針對當前醫院，特別是區、縣及落后地區的醫院，尚無條件實現標準化的醫療信息系統或者需要升級改造非標準化醫療信息系統這一實際情況，以醫療系統、醫學影像系統及影像設備中的文本信息和影像信息為集成交換對象，以DICOM、HL7以及國家衛生部數字醫療相關標準為出發點，以DICOM消息和HL7消息為數據集成和交換基本單元，以高效的DICOM、HL7消息構建與解析方法為基礎，以面向服務的體系結構作為基礎構架，以中間件技術為實現手段，設計并實現一種通用的醫療信息集成交換服務中間件，通過語義映射，不僅支持HL7與DICOM標準，同時可解決非標準化醫療系統之間，標準化醫療系統與非標準化醫療系統之間的信息集成與交換問題。
1 方法
1.1 總體技術原理
醫療信息的集成與交換主要包含醫療文本與醫學影像的集成與交換，并且兩者必須進行正確有效的融合。集成交換的總體技術原理如圖 1所示。
圖1
總體技術原理
Figure1.
Overall technical principle of the middleware
1.2 核心處理組件
1.2.1 語義映射與轉換規則
語義映射與轉換規則是不同數據格式得以轉換的基礎，用于建立源系統與目標系統的語義關系，源系統與HL7、DICOM消息之間的語義關系以及目標系統與HL7、DICOM消息之間的語義關系及轉換規則，分別完成源系統與目標系統數據的直接轉換、源系統(目標系統)與HL7消息之間的轉換、源系統(目標系統)與DICOM消息之間的轉換。HL7消息與關系數據庫之間的語義映射如圖 2所示，其它數據源與目標的語義映射與此類似。
圖2
HL7消息與數據庫之間的語義映射
Figure2.
Semantic mapping between HL7 message and relational database
1.2.2 DICOM消息的構建與解析
(1)DICOM消息的構建
完成從源系統到DICOM 3.0消息的轉換和封裝，形成標準的DICOM 3.0消息，將DICOM 3.0消息傳輸到目標系統(如醫學影像系統)，在進入目標系統之前解析DCIOM 3.0消息，根據語義映射與轉換規則生成符合目標系統要求的數據結構(若目標系統支持DICOM 3.0標準則可直接入庫)，最后存入目標庫，從而完成醫學影像的集成交換。DICOM 3.0消息的構建過程如圖 3所示。
圖3
DICOM消息構建流程
Figure3.
Workflow of DICOM message construction
DICOM消息轉換過程分為三種情況：①DICOM 3.0消息之間的交換：直接讀取或接收DICOM 3.0消息并進行轉發；②不同DICOM版本消息向DICOM 3.0消息的轉換：取得DICOM版本信息，獲取相應DICOM模板，根據模板與DCIOM 3.0標準的映射關系轉換成DICOM 3.0消息；③非標準DICOM數據(關系數據庫)向DICOM 3.0消息轉換：取得轉換數據，根據語義映射與轉換規則建立數據與DICOM 3.0消息的轉換通道，轉換成DICOM 3.0消息。
(2)DICOM消息的解析
DICOM消息的解析與構建過程正好相反，是將DICOM 3.0消息轉換成第三方系統能夠識別的數據格式的過程。DICOM消息解析過程也分三種情況：①DICOM 3.0消息之間的轉換：直接讀取或接收DICOM 3.0消息并根據路由信息發送至目標系統；②DICOM 3.0消息向非標準DICOM 3.0(DICOM的歷史版本)：取得DICOM版本信息，獲取相應的DICOM模板，根據DICOM 3.0消息與模板的映射關系轉換成符合相應版本的數據格式，最后根據路由信息發送給目標系統；③DICOM 3.0消息向非標準DICOM格式的轉換：取得轉換數據，根據語義映射與轉換規則建立標準DICOM消息與業務數據的轉換通道，將DICOM數據轉換成符合業務系統的數據格式。
1.2.3 HL7消息的構建與解析
(1)HL7消息的構建
實現從源(不支持HL7消息)到HL7消息的轉換和封裝(若源支持HL7消息的產生，則系統直接接收即可)，形成標準HL7消息，將HL7消息傳輸到目標系統，若目標系統支持HL7協議，則無需進行解析與轉換，否則在存入目標系統之前要對HL7進行解析，根據語義映射與轉換規則生成符合目標系統的數據結構。HL7消息構建完成HL7 3.x消息之間的交換、非標準HL7 3.x消息(HL7歷史版本)向HL7 3.x消息的轉換以及非標準HL7數據(關系數據庫)向HL7消息的轉換。HL7 3.x消息構建過程如圖 4所示。
圖4
HL7消息構建流程
Figure4.
Workflow of HL7 message construction
HL7消息構建過程分為三種情況：①HL7 3.x消息之間的交換：直接讀取或接收HL7 消息并根據路由信息發送給目標系統；②不同HL7版本消息向HL7 3.x版本轉換：取得HL7版本信息，獲取相應的HL7模板，根據模板與HL7 3.x標準的映射關系轉換成符合HL7 3.x標準的數據格式；③非標準HL7數據(關系數據庫)向HL7 3.x消息轉換：取得轉換數據，根據語義映射與轉換規則建立數據與HL7 3.x消息的轉換通道，轉換成HL7 3.x消息。
(2)HL7消息解析
HL7消息解析與構建過程正好相反，是將HL7消息進行解析并轉換成第三方系統能夠識別的數據格式的過程，以便集成、交換與存儲醫學臨床文本數據。與HL7消息構建類似，HL7消息解析過程分三種情況：①HL7 3.x消息之間轉換：直接接收HL7 3.x消息并存入目標系統；②HL7 3.x消息向非標準HL7 3.x(HL7歷史版本)轉換：取得HL7版本信息，獲取相應的HL7模板，根據HL7模板的映射關系轉換成符合相應版本的數據格式，最后發送給目標系統；③HL7消息向非標準HL7消息(關系數據庫)轉換：取得轉換數據，根據HL7消息映射以及語義、語法規則建立標準HL7消息與數據轉換通道，將HL7消息轉換成符合業務系統的數據格式。
針對HL7消息的構建與解析性能，文獻[15]提出了一種優化消息構建和消息存儲的模型以提高性能。文獻[16]提出了一種動態構建與解析HL7消息的方法，以減小內存對象創建來提高性能。本文結合文獻[15]與[16]中提出的方法與模型，對HL7消息進行構建和解析以達到提高性能的目的。
1.3 原型系統實現
系統核心功能包含：參數配置、集成交換通道及集成交換引擎。參數配置：以數據字典的方式配置系統所需各類信息，包含消息模板、數據源類型、源處理協議、數據庫類型、數據源等配置。集成交換通道：建立源系統與目標系統的集成交換通道，以語義映射與轉換規則完成源與目標的轉換，是中間件實現信息集成交換的基礎。集成交換引擎：根據建立的交換通道，完成信息源監控、讀取、轉換與輸出，是中間件實現信息集成交換的關鍵組件。
原型系統以J2EE為開發與運行環境，采用面向對象和插件的方式進行設計與實現，以Web的方式進行展示，以Tomcat6.0為Web服務器，以MySQL5.0來存儲參數信息。運行時，首先對參數進行預加載，形成內存數據庫，以Key-Value的方式為通道配置與集成交換引擎提供服務。
2 原型系統驗證
為了驗證原型系統的可用性，構建了完整的測試環境，由于測試比較復雜，我們開發了一些測試小程序，也借助了第三方開源軟件，測試環境由源PC機、中間件服務器和目標服務器組成，它們之間由一臺千兆交換機進行連接，實驗環境如表 1所示，測試項目如表 2所示，性能對比如表 3所示。
表1
實驗環境配置
Table1.
Configuration of the experimental environmentc
其中，HL7發送程序用于產生HL7 2.x或HL7 3.x消息，由于HL7消息類型眾多，我們選取一些常用的HL7消息進行測試；DICOM發送程序用于產生DICOM 2.x或DICOM 3.0消息，Mayam是一款基于Java的免費DICOM處理軟件，用于產生CT、US、MR、PET等DICOM 3.0消息。DCM4CHEE是一款基于Java的開源PACS系統，可以接收和管理DICOM 3.0消息。HL7接收程序用于模擬HL7服務器或支持HL7協議的醫療系統，DICOM接收程序用于模擬DICOM服務器或支持DICOM協議的PACS系統或醫學影像集成平臺。
測試過程中，首先對每一種類型的源與目標進行了測試，然后進行各類源與目標的混合測試。結果表明，原型系統能夠完成如表 2所示的測試項目，集成與交換性能與Mirth Connect[17](著名的醫療信息集成交換中間件)進行了對比，如表 3所示，除DICOM與RDB的集成與交換性能略低于Mirth Connect外，其他項目與Mirth Connect持平或明顯優于Mirth Connect。
表2
實驗測試項目
Table2.
Experimental testing items
表3
實驗性能測試(平均時間/ms)
Table3.
Performance testing (average time/ms)
該中間件已在云南省社會發展科技計劃項目“開放式醫療信息集成系統開發與示范”中得到了應用，并部署在應用示范單位昆明市中醫院及其有業務往來的區縣級醫院，實現了PACS、HIS、LIS (Laboratory Information Management System)、RIS與EMR (Electronic Medical Record)五個系統的集成與交換。
3 討論與結論
原型系統實現了關系數據庫、HL7消息、DICOM消息之間的集成與交換，統一了醫療環境中三種主要數據的存儲與交換方式，為解決醫療信息孤島問題提供了可行的解決方案，為建立統一的醫學信息集成與共享平臺打下了良好的基礎。在系統實現過程中，采用面向對象和插件的方式完成，增強了系統的可擴展性，可以容易地通過配置和添加核心處理引擎實現新的處理協議，如輸出XML格式等。在性能方面，參考了文獻[15]與[16]中提出的方法與模型對HL7消息進行構建和解析。下一步，我們將建立大規模集成交換環境，對原型系統的性能進行測試、評價與優化，進一步簡化語義映射與轉換規則配置，提高系統的可用性，并在此基礎上，引入IHE集成規范，建立標準化的區域醫療信息集成交換服務平臺。
引言
隨著醫療信息化建設的深入變革與飛速發展，衛生行政管理部門和醫療機構在管理模式、信息需求、臨床應用、教學及科研等方面提出了更高要求。任何一個軟件提供商都不可能為一個醫院提供滿足需求的全線產品。不同產品結構不同，實現方式各異，軟硬件環境差異也很大，這些產品大都成了一個個“信息孤島”，難以實現醫療信息的實時交換，導致整體業務不能協調一致。因此，標準化的醫療信息集成交換已成為21世紀醫療服務發展的必然趨勢。2009年4月，中共中央國務院頒布了《關于深化醫藥衛生體制改革的意見》，將信息化作為“四梁八柱”中的一大支柱，明確提出了“建立實用共享的醫藥衛生信息系統 ”的要求[1]。
HL7 (Health Level Seven)標準致力于將醫療信息傳輸的某些關鍵數據集合的格式和協議標準化，將HL7標準發展成為國際間通用的醫療信息交換標準。基于HL7的醫療信息交換中間層軟件的研究與開發變得非常重要。DICOM (Digital Imaging and Communications in Medicine)標準定義了醫學圖像在存儲和通信過程中的各種實體和關系，所有DICOM設備都可以按照DICOM標準進行互相連接和操作。國內外學者對基于HL7與DICOM的信息集成交換進行了一系列研究。Tran等[2]開發了基于HL7的醫療設備通信中間件，實現了醫療設備之間的信息交換；Blazona等[3]通過HL7和DICOM標準來完成放射科系統與醫療保健系統的集成。De Meo等[4]在多Agent系統中通過HL7標準來支持對e-Health的個性化訪問。Alam等[5]設計并實現了基于HL7 V3版本的服務軟件系統；Yang等[6]設計并實現了一個基于HL7與DICOM標準的網關系統；張蘭華等[7]基于HL7標準，在醫院內部及醫院之間實現醫療平臺的數據交換與共享。喬聰聰等[8]以HL7 CDA (Clinical Document Architecture)文檔為基礎，設計了基于衛生部數據集標準的CDA模板，采用Web Service方式實現了異構信息系統之間的信息共享和業務聯動。沈劍峰等[9]通過HL7 CDA技術初步實現了電子病歷的信息共享；李昂等[10]基于HL7標準實現了HIS (Hospital Information System)與PACS (Picture Archiving and Communication Systems)、RIS (Radiation Information System)的集成。陳靜等[11]基于HL7醫療信息交換標準和Web Service技術，解決了醫院信息共享問題；吳壽剛等[12]介紹了HL7標準及其在國內外的應用現狀，從HL7版本選擇和基于HL7集成方式選擇兩個方面指出了HL7在國內的發展趨勢；鄭建立等[13]基于HL7標準為醫療儀器提供了統一的HI 7標準接口，解決了醫療儀器與信息系統的集成；董方杰等[14]參考IHE (Integrating the Heahhcare Enterprise)技術框架，立足于HL7標準，闡述了醫療信息院內交互與區域共享的整體架構，實現了區域醫療信息的集成。上述研究成果推進了HL7與DICOM的研究與應用，但大多是針對特定系統，解決特定問題，其性能與通用性有待進一步提高。
本文針對當前醫院，特別是區、縣及落后地區的醫院，尚無條件實現標準化的醫療信息系統或者需要升級改造非標準化醫療信息系統這一實際情況，以醫療系統、醫學影像系統及影像設備中的文本信息和影像信息為集成交換對象，以DICOM、HL7以及國家衛生部數字醫療相關標準為出發點，以DICOM消息和HL7消息為數據集成和交換基本單元，以高效的DICOM、HL7消息構建與解析方法為基礎，以面向服務的體系結構作為基礎構架，以中間件技術為實現手段，設計并實現一種通用的醫療信息集成交換服務中間件，通過語義映射，不僅支持HL7與DICOM標準，同時可解決非標準化醫療系統之間，標準化醫療系統與非標準化醫療系統之間的信息集成與交換問題。
1 方法
1.1 總體技術原理
醫療信息的集成與交換主要包含醫療文本與醫學影像的集成與交換，并且兩者必須進行正確有效的融合。集成交換的總體技術原理如圖 1所示。
圖1
總體技術原理
Figure1.
Overall technical principle of the middleware
1.2 核心處理組件
1.2.1 語義映射與轉換規則
語義映射與轉換規則是不同數據格式得以轉換的基礎，用于建立源系統與目標系統的語義關系，源系統與HL7、DICOM消息之間的語義關系以及目標系統與HL7、DICOM消息之間的語義關系及轉換規則，分別完成源系統與目標系統數據的直接轉換、源系統(目標系統)與HL7消息之間的轉換、源系統(目標系統)與DICOM消息之間的轉換。HL7消息與關系數據庫之間的語義映射如圖 2所示，其它數據源與目標的語義映射與此類似。
圖2
HL7消息與數據庫之間的語義映射
Figure2.
Semantic mapping between HL7 message and relational database
1.2.2 DICOM消息的構建與解析
(1)DICOM消息的構建
完成從源系統到DICOM 3.0消息的轉換和封裝，形成標準的DICOM 3.0消息，將DICOM 3.0消息傳輸到目標系統(如醫學影像系統)，在進入目標系統之前解析DCIOM 3.0消息，根據語義映射與轉換規則生成符合目標系統要求的數據結構(若目標系統支持DICOM 3.0標準則可直接入庫)，最后存入目標庫，從而完成醫學影像的集成交換。DICOM 3.0消息的構建過程如圖 3所示。
圖3
DICOM消息構建流程
Figure3.
Workflow of DICOM message construction
DICOM消息轉換過程分為三種情況：①DICOM 3.0消息之間的交換：直接讀取或接收DICOM 3.0消息并進行轉發；②不同DICOM版本消息向DICOM 3.0消息的轉換：取得DICOM版本信息，獲取相應DICOM模板，根據模板與DCIOM 3.0標準的映射關系轉換成DICOM 3.0消息；③非標準DICOM數據(關系數據庫)向DICOM 3.0消息轉換：取得轉換數據，根據語義映射與轉換規則建立數據與DICOM 3.0消息的轉換通道，轉換成DICOM 3.0消息。
(2)DICOM消息的解析
DICOM消息的解析與構建過程正好相反，是將DICOM 3.0消息轉換成第三方系統能夠識別的數據格式的過程。DICOM消息解析過程也分三種情況：①DICOM 3.0消息之間的轉換：直接讀取或接收DICOM 3.0消息并根據路由信息發送至目標系統；②DICOM 3.0消息向非標準DICOM 3.0(DICOM的歷史版本)：取得DICOM版本信息，獲取相應的DICOM模板，根據DICOM 3.0消息與模板的映射關系轉換成符合相應版本的數據格式，最后根據路由信息發送給目標系統；③DICOM 3.0消息向非標準DICOM格式的轉換：取得轉換數據，根據語義映射與轉換規則建立標準DICOM消息與業務數據的轉換通道，將DICOM數據轉換成符合業務系統的數據格式。
1.2.3 HL7消息的構建與解析
(1)HL7消息的構建
實現從源(不支持HL7消息)到HL7消息的轉換和封裝(若源支持HL7消息的產生，則系統直接接收即可)，形成標準HL7消息，將HL7消息傳輸到目標系統，若目標系統支持HL7協議，則無需進行解析與轉換，否則在存入目標系統之前要對HL7進行解析，根據語義映射與轉換規則生成符合目標系統的數據結構。HL7消息構建完成HL7 3.x消息之間的交換、非標準HL7 3.x消息(HL7歷史版本)向HL7 3.x消息的轉換以及非標準HL7數據(關系數據庫)向HL7消息的轉換。HL7 3.x消息構建過程如圖 4所示。
圖4
HL7消息構建流程
Figure4.
Workflow of HL7 message construction
HL7消息構建過程分為三種情況：①HL7 3.x消息之間的交換：直接讀取或接收HL7 消息并根據路由信息發送給目標系統；②不同HL7版本消息向HL7 3.x版本轉換：取得HL7版本信息，獲取相應的HL7模板，根據模板與HL7 3.x標準的映射關系轉換成符合HL7 3.x標準的數據格式；③非標準HL7數據(關系數據庫)向HL7 3.x消息轉換：取得轉換數據，根據語義映射與轉換規則建立數據與HL7 3.x消息的轉換通道，轉換成HL7 3.x消息。
(2)HL7消息解析
HL7消息解析與構建過程正好相反，是將HL7消息進行解析并轉換成第三方系統能夠識別的數據格式的過程，以便集成、交換與存儲醫學臨床文本數據。與HL7消息構建類似，HL7消息解析過程分三種情況：①HL7 3.x消息之間轉換：直接接收HL7 3.x消息并存入目標系統；②HL7 3.x消息向非標準HL7 3.x(HL7歷史版本)轉換：取得HL7版本信息，獲取相應的HL7模板，根據HL7模板的映射關系轉換成符合相應版本的數據格式，最后發送給目標系統；③HL7消息向非標準HL7消息(關系數據庫)轉換：取得轉換數據，根據HL7消息映射以及語義、語法規則建立標準HL7消息與數據轉換通道，將HL7消息轉換成符合業務系統的數據格式。
針對HL7消息的構建與解析性能，文獻[15]提出了一種優化消息構建和消息存儲的模型以提高性能。文獻[16]提出了一種動態構建與解析HL7消息的方法，以減小內存對象創建來提高性能。本文結合文獻[15]與[16]中提出的方法與模型，對HL7消息進行構建和解析以達到提高性能的目的。
1.3 原型系統實現
系統核心功能包含：參數配置、集成交換通道及集成交換引擎。參數配置：以數據字典的方式配置系統所需各類信息，包含消息模板、數據源類型、源處理協議、數據庫類型、數據源等配置。集成交換通道：建立源系統與目標系統的集成交換通道，以語義映射與轉換規則完成源與目標的轉換，是中間件實現信息集成交換的基礎。集成交換引擎：根據建立的交換通道，完成信息源監控、讀取、轉換與輸出，是中間件實現信息集成交換的關鍵組件。
原型系統以J2EE為開發與運行環境，采用面向對象和插件的方式進行設計與實現，以Web的方式進行展示，以Tomcat6.0為Web服務器，以MySQL5.0來存儲參數信息。運行時，首先對參數進行預加載，形成內存數據庫，以Key-Value的方式為通道配置與集成交換引擎提供服務。
2 原型系統驗證
為了驗證原型系統的可用性，構建了完整的測試環境，由于測試比較復雜，我們開發了一些測試小程序，也借助了第三方開源軟件，測試環境由源PC機、中間件服務器和目標服務器組成，它們之間由一臺千兆交換機進行連接，實驗環境如表 1所示，測試項目如表 2所示，性能對比如表 3所示。
表1
實驗環境配置
Table1.
Configuration of the experimental environmentc
其中，HL7發送程序用于產生HL7 2.x或HL7 3.x消息，由于HL7消息類型眾多，我們選取一些常用的HL7消息進行測試；DICOM發送程序用于產生DICOM 2.x或DICOM 3.0消息，Mayam是一款基于Java的免費DICOM處理軟件，用于產生CT、US、MR、PET等DICOM 3.0消息。DCM4CHEE是一款基于Java的開源PACS系統，可以接收和管理DICOM 3.0消息。HL7接收程序用于模擬HL7服務器或支持HL7協議的醫療系統，DICOM接收程序用于模擬DICOM服務器或支持DICOM協議的PACS系統或醫學影像集成平臺。
測試過程中，首先對每一種類型的源與目標進行了測試，然后進行各類源與目標的混合測試。結果表明，原型系統能夠完成如表 2所示的測試項目，集成與交換性能與Mirth Connect[17](著名的醫療信息集成交換中間件)進行了對比，如表 3所示，除DICOM與RDB的集成與交換性能略低于Mirth Connect外，其他項目與Mirth Connect持平或明顯優于Mirth Connect。
表2
實驗測試項目
Table2.
Experimental testing items
表3
實驗性能測試(平均時間/ms)
Table3.
Performance testing (average time/ms)
該中間件已在云南省社會發展科技計劃項目“開放式醫療信息集成系統開發與示范”中得到了應用，并部署在應用示范單位昆明市中醫院及其有業務往來的區縣級醫院，實現了PACS、HIS、LIS (Laboratory Information Management System)、RIS與EMR (Electronic Medical Record)五個系統的集成與交換。
3 討論與結論
原型系統實現了關系數據庫、HL7消息、DICOM消息之間的集成與交換，統一了醫療環境中三種主要數據的存儲與交換方式，為解決醫療信息孤島問題提供了可行的解決方案，為建立統一的醫學信息集成與共享平臺打下了良好的基礎。在系統實現過程中，采用面向對象和插件的方式完成，增強了系統的可擴展性，可以容易地通過配置和添加核心處理引擎實現新的處理協議，如輸出XML格式等。在性能方面，參考了文獻[15]與[16]中提出的方法與模型對HL7消息進行構建和解析。下一步，我們將建立大規模集成交換環境，對原型系統的性能進行測試、評價與優化，進一步簡化語義映射與轉換規則配置，提高系統的可用性，并在此基礎上，引入IHE集成規范，建立標準化的區域醫療信息集成交換服務平臺。
