由繁多的醫療業務系統搭建而成的醫院信息化架構,正在遭遇"信息孤島"問題,醫院內部各個業務系統相互異構,難成一體。如何實現患者有效醫療信息在醫院內部的無障礙交互且進一步完成患者縱向診療信息的區域內互通共享,已成為醫療信息化建設過程中亟待解決的問題。本文參考IHE技術框架,立足于HL7標準,闡述了醫療信息院內交互與區域共享的整體架構,詳細說明了離散的患者醫療信息從分布于不同醫院的各個業務系統到通過信息交換平臺進行院內交互再到集中存儲于區域臨床數據庫(CDR)并得以通過Portal技術完整展示和共享的全過程。
引用本文： 董方杰, 蒲立新, 曲建明, 胡建平. 醫療信息院內交互與區域共享的架構及其技術研究. 生物醫學工程學雜志, 2014, 31(4): 788-792. doi: 10.7507/1001-5515.20140147 復制
引言
2000 年衛生部根據新醫改要求，制訂了衛生信息化“十二五”規劃，提出了“十二五”期間衛生信息化建設“3521工程”的總體框架，旨在促進區域衛生信息化水平的發展。區域衛生信息平臺涵蓋了衛生服務領域中眾多核心信息，能夠有效地降低單個患者醫療信息的搜集成本、增強信息完整性，同時促進同級醫療服務機構之間的信息共享、技術交流以及上級醫療服務機構對下級醫療服務機構的技術指導[1]，是整個醫療信息化建設進程中不可或缺的一環，對實現全民醫療信息化具有重要意義。
然而，因為醫院內部的信息化架構大多是由繁多的醫療業務系統在不同時期“拼湊”而成，僅單個醫院內部，就已面臨著“信息孤島”問題，各個業務系統相互異構，難成一體，要想進一步真正實現患者診療信息在區域內的互通共享，絕非易事[2]。
只有依據國家標準，通過特定、統一的規則進行抽取、整合的患者診療數據，才可能服務于臨床應用、管理決策和公眾信息等多個方面，達到減少醫療事故、加快對不利醫療保健事件的響應、提高醫院業務運作效率[3]等目的；進而在區域內進行醫療信息的集成，使患者有效診療信息真正貫通于整個區域范圍，更加及時和完整地展示有效診療信息，為醫生提供更加廣闊的視角，提高既往病史信息的可及性，為醫療管控和決策部門提供關鍵醫療信息的監控途徑和詳盡的醫療統計信息[4]。本文正是立足于區域范圍內的患者有效診療信息，著眼于信息的集成、整合及展示，提出了一種實時性強、數據標準可靠且能夠滿足各種展示需求的區域醫療信息集成平臺架構，并詳述其各部分組件及實現方式。
1 院內信息交換平臺架構及關鍵組件
醫療機構是患者診療信息的產生源和收集地，患者在醫療機構中的每次就診過程，都會產生大量的診療信息，并由機構內部各個專業系統所記錄和存儲。但是，各個業務系統大多孤立開發，內部信息處理手段的差異性較大，數據表現和存儲方式不統一，所以在醫院內部部署院內信息交換引擎，用以支持院內各個業務系統的信息共享和業務交互，并配合區域信息處理引擎對醫療信息的收集。
院內信息交換引擎基于ETL技術實現，ETL的工作過程如圖 1所示。
圖1
ETL原理過程
Figure1.
ETL fundamentals and process
ETL包括數據抽取、轉換和裝載等過程，其中數據抽取負責從各個業務系統、外部數據接口和脫機存儲介質中采集關心的數據，也就是將數據源提取到數據緩存區；數據轉換功能主要包括對緩存區數據的轉化、數據的重新格式化和計算、關鍵數據的重新構建和數據總結、數據定位等；數據裝載功能主要是按照給定的數據模型將裝換后的數據加載到目標位置[5-6]。
院內信息交換引擎正是應用ETL的上述功能，使用開源ETL工具Kettle[7]，通過Tcp Socket、DB Tables等多種形式與醫院內部各個業務系統進行互連，并在既定的觸發事件發生時，將需要院內交換的、支持醫院業務進行所需的實時數據從不同的系統中主動提取或被動接收，若消息發送業務系統支持HL7消息的構建和發送，則只需對接收到的消息進行格式驗證和必要的業務流程控制，若消息為其它格式，則遵照相應的HL7消息格式規范，對數據進行清洗、轉換后，形成語義統一、語法一致的HL7消息，為縱向的區域信息集成、共享打下堅實基礎，邁出患者信息區域標準化的第一步。
在院內信息交換引擎上轉換而來的HL7消息，可以直接推送給下游的消息接收業務系統，以實現患者就診過程中必要的異構系統間的業務交互，但因為國內能夠支持HL7消息格式解析的業務系統并不常見，所以引擎在面對無力自身解析數據的下游業務系統時，又增加了一部分工作：解析HL7消息，并按照接收方業務系統的要求進行數據格式轉換向其推送。
院內信息交換平臺還承擔著另一項重要的任務即將特定的一條或幾條HL7消息轉換為相應的CDA文檔，并通過消息發送層向上層的區域集成平臺推送，院內信息交換引擎具體實現架構如圖 2所示。
圖2
院內信息交換引擎整體架構
Figure2.
The overall architecture of hospital information exchange engine
2 區域信息共享架構及關鍵組件
孤懸于醫院內部各個異構業務系統中的患者診療信息，經過院內信息交換引擎的抽取和打包，形成用于封裝患者醫學診療記錄的CDA文檔[8]，進而推送到區域信息處理引擎，通過將CDA文檔所承載的臨床信息存儲到臨床數據庫(cinical data repository,CDR)中并利用Portal技術進行展示，最終使零散的、非標準的患者診療信息以患者為索引標準化的整合在一起，并服務于臨床醫生、管理機構和公眾。具體的實現架構如圖 3所示。
圖3
區域信息集成平臺整體架構
Figure3.
The overall architecture of regional information integration platform
2.1 信息處理引擎
區域信息交換引擎負責對接收到的CDA文檔，對其依照CDA Schema進行格式驗證，將通過驗證的標準CDA文檔按塊解析，并將其構建為若干條標準的HL7 ER7格式消息并再次進行消息格式的驗證。它還負責與CDR交互，將構建好的一個患者索引下的若干條HL7 ER7消息交付給CDR。
2.2 臨床數據庫
CDR是一個實時數據庫，它能夠從不同臨床數據源收集臨床數據，并為單個患者提供一個唯一的統一、縱向的展示視圖[9-10]。CDR搭配區域信息處理引擎，將其提供的HL7 ER7格式的消息按消息格式自動解析、存儲。解析后的結構化數據以患者為中心存儲，各種離散的結構數據，例如化驗結果、用藥、疾病列表、過敏或過往病史等，在CDR中均以此中心展開存儲，生成一個患者的綜合記錄，使患者的完整醫療信息得以快速提取、展示[11]。
2.3 展示門戶
展示門戶是基于Portal技術實現的，Portal技術的工作原理如圖 4所示。
圖4
Portal工作原理
Figure4.
Portal fundamentals
客戶端瀏覽器通過由Portal執行的請求/應答機制與Portlet進行交互。Portlet是基于WEB的java組件，由Portlet容器管理，能夠處理請求，產生動態內容。通常，用戶與由Portlet產生的內容進行交互，Portal接收到Portlet窗口的動作，隨后將Portlet產生的內容送至用戶操作的Portlet窗口。對不同的用戶，一個Portlet產生的內容可能會大不一樣，這與用戶對Portlet的設置有關[12]。
正是得益于Portal技術強大的交互性和可配置性，展示門戶可以實現根據臨床應用、管理決策、公眾信息等多種應用類型，完成患者完整診療信息的不同視角展示，也可以方便的根據不同用戶的偏好，配置不同布局的展示界面。
3 整體數據流分析
患者的診療數據，從離散的存儲在各個業務系統到轉換成一條條HL7消息用來支持系統間的業務交互，再到一條或多條HL7消息集成為一個完整的CDA文檔，接著CDA文檔中承載的患者醫療信息并存儲在區域CDR中，最后通過Portal以各種形式展示出來，這個數據轉換流程本身就集中體現了整個共享過程的技術精髓，整個流程如圖 5所示。
圖5
數據轉換流程
Figure5.
The data conversion process
整個數據轉換流程描述如下：
(1) 從業務數據到HL7 ER7消息
當設定的觸發事件發生時，院內信息交換引擎即刻按既定的數據規則從業務系統抽取患者診療數據，不論業務系統提供的是何種類型的數據、數據本身遵從何種標準，引擎都能將所得數據清洗、轉換為標準的HL7 ER7格式。
(2) 從HL7 ER7消息到CDA文檔
對于患者的一次診療行為，勢必需要多條HL7 ER7消息才能完全描述，而患者醫療信息向區域集成平臺推送時，多條消息分別傳輸會導致多次連接和無法保證信息完整性等問題，因此在院內，交換引擎將數據轉換為HL7 ER7格式后，會以患者為線索，將患者的多條消息打包成一個完整的CDA文檔[13]。
(3) CDA文檔的推送
院內信息交換引擎將在CDA文檔生成后，通過Web Services將其推送到區域信息處理引擎。
(4) CDA文檔解析為HL7 ER7消息
包含患者一次診療過程完整有效信息的CDA文檔，將被區域信息處理引擎解析為多條HL7 ER7消息，并由引擎傳遞到CDR中。
(5) 患者信息的結構化存儲和展示
HL7 ER7消息將被解析、存儲在CDR中，而CDR對臨床信息強大的組織和處理功能，將有效的提供患者結構化醫療數據的關聯性，更好的通過Portal技術對縱向、完整的醫療信息進行不同視角的展示。
4 結語
區域醫療信息集成平臺，將患者的診療信息、衛生經濟信息與醫院管理信息等進行最有效地收集、儲存、傳輸與整合,實現各類業務流程的最優化和信息利用最大化[14]，支撐了區域性醫療衛生信息服務，是集業務、管理、協調為一體的綜合醫療信息服務平臺的體系架構。通過建立信息集成平臺，實現了患者不同時間、不同醫院產生的醫療信息的統一展示，加強了醫療資源整合，整體提高了區域性醫療服務、醫療救治、疾病預防、衛生監督執法管理水平和應對突發公共衛生事件的能力[15]。
引言
2000 年衛生部根據新醫改要求，制訂了衛生信息化“十二五”規劃，提出了“十二五”期間衛生信息化建設“3521工程”的總體框架，旨在促進區域衛生信息化水平的發展。區域衛生信息平臺涵蓋了衛生服務領域中眾多核心信息，能夠有效地降低單個患者醫療信息的搜集成本、增強信息完整性，同時促進同級醫療服務機構之間的信息共享、技術交流以及上級醫療服務機構對下級醫療服務機構的技術指導[1]，是整個醫療信息化建設進程中不可或缺的一環，對實現全民醫療信息化具有重要意義。
然而，因為醫院內部的信息化架構大多是由繁多的醫療業務系統在不同時期“拼湊”而成，僅單個醫院內部，就已面臨著“信息孤島”問題，各個業務系統相互異構，難成一體，要想進一步真正實現患者診療信息在區域內的互通共享，絕非易事[2]。
只有依據國家標準，通過特定、統一的規則進行抽取、整合的患者診療數據，才可能服務于臨床應用、管理決策和公眾信息等多個方面，達到減少醫療事故、加快對不利醫療保健事件的響應、提高醫院業務運作效率[3]等目的；進而在區域內進行醫療信息的集成，使患者有效診療信息真正貫通于整個區域范圍，更加及時和完整地展示有效診療信息，為醫生提供更加廣闊的視角，提高既往病史信息的可及性，為醫療管控和決策部門提供關鍵醫療信息的監控途徑和詳盡的醫療統計信息[4]。本文正是立足于區域范圍內的患者有效診療信息，著眼于信息的集成、整合及展示，提出了一種實時性強、數據標準可靠且能夠滿足各種展示需求的區域醫療信息集成平臺架構，并詳述其各部分組件及實現方式。
1 院內信息交換平臺架構及關鍵組件
醫療機構是患者診療信息的產生源和收集地，患者在醫療機構中的每次就診過程，都會產生大量的診療信息，并由機構內部各個專業系統所記錄和存儲。但是，各個業務系統大多孤立開發，內部信息處理手段的差異性較大，數據表現和存儲方式不統一，所以在醫院內部部署院內信息交換引擎，用以支持院內各個業務系統的信息共享和業務交互，并配合區域信息處理引擎對醫療信息的收集。
院內信息交換引擎基于ETL技術實現，ETL的工作過程如圖 1所示。
圖1
ETL原理過程
Figure1.
ETL fundamentals and process
ETL包括數據抽取、轉換和裝載等過程，其中數據抽取負責從各個業務系統、外部數據接口和脫機存儲介質中采集關心的數據，也就是將數據源提取到數據緩存區；數據轉換功能主要包括對緩存區數據的轉化、數據的重新格式化和計算、關鍵數據的重新構建和數據總結、數據定位等；數據裝載功能主要是按照給定的數據模型將裝換后的數據加載到目標位置[5-6]。
院內信息交換引擎正是應用ETL的上述功能，使用開源ETL工具Kettle[7]，通過Tcp Socket、DB Tables等多種形式與醫院內部各個業務系統進行互連，并在既定的觸發事件發生時，將需要院內交換的、支持醫院業務進行所需的實時數據從不同的系統中主動提取或被動接收，若消息發送業務系統支持HL7消息的構建和發送，則只需對接收到的消息進行格式驗證和必要的業務流程控制，若消息為其它格式，則遵照相應的HL7消息格式規范，對數據進行清洗、轉換后，形成語義統一、語法一致的HL7消息，為縱向的區域信息集成、共享打下堅實基礎，邁出患者信息區域標準化的第一步。
在院內信息交換引擎上轉換而來的HL7消息，可以直接推送給下游的消息接收業務系統，以實現患者就診過程中必要的異構系統間的業務交互，但因為國內能夠支持HL7消息格式解析的業務系統并不常見，所以引擎在面對無力自身解析數據的下游業務系統時，又增加了一部分工作：解析HL7消息，并按照接收方業務系統的要求進行數據格式轉換向其推送。
院內信息交換平臺還承擔著另一項重要的任務即將特定的一條或幾條HL7消息轉換為相應的CDA文檔，并通過消息發送層向上層的區域集成平臺推送，院內信息交換引擎具體實現架構如圖 2所示。
圖2
院內信息交換引擎整體架構
Figure2.
The overall architecture of hospital information exchange engine
2 區域信息共享架構及關鍵組件
孤懸于醫院內部各個異構業務系統中的患者診療信息，經過院內信息交換引擎的抽取和打包，形成用于封裝患者醫學診療記錄的CDA文檔[8]，進而推送到區域信息處理引擎，通過將CDA文檔所承載的臨床信息存儲到臨床數據庫(cinical data repository,CDR)中并利用Portal技術進行展示，最終使零散的、非標準的患者診療信息以患者為索引標準化的整合在一起，并服務于臨床醫生、管理機構和公眾。具體的實現架構如圖 3所示。
圖3
區域信息集成平臺整體架構
Figure3.
The overall architecture of regional information integration platform
2.1 信息處理引擎
區域信息交換引擎負責對接收到的CDA文檔，對其依照CDA Schema進行格式驗證，將通過驗證的標準CDA文檔按塊解析，并將其構建為若干條標準的HL7 ER7格式消息并再次進行消息格式的驗證。它還負責與CDR交互，將構建好的一個患者索引下的若干條HL7 ER7消息交付給CDR。
2.2 臨床數據庫
CDR是一個實時數據庫，它能夠從不同臨床數據源收集臨床數據，并為單個患者提供一個唯一的統一、縱向的展示視圖[9-10]。CDR搭配區域信息處理引擎，將其提供的HL7 ER7格式的消息按消息格式自動解析、存儲。解析后的結構化數據以患者為中心存儲，各種離散的結構數據，例如化驗結果、用藥、疾病列表、過敏或過往病史等，在CDR中均以此中心展開存儲，生成一個患者的綜合記錄，使患者的完整醫療信息得以快速提取、展示[11]。
2.3 展示門戶
展示門戶是基于Portal技術實現的，Portal技術的工作原理如圖 4所示。
圖4
Portal工作原理
Figure4.
Portal fundamentals
客戶端瀏覽器通過由Portal執行的請求/應答機制與Portlet進行交互。Portlet是基于WEB的java組件，由Portlet容器管理，能夠處理請求，產生動態內容。通常，用戶與由Portlet產生的內容進行交互，Portal接收到Portlet窗口的動作，隨后將Portlet產生的內容送至用戶操作的Portlet窗口。對不同的用戶，一個Portlet產生的內容可能會大不一樣，這與用戶對Portlet的設置有關[12]。
正是得益于Portal技術強大的交互性和可配置性，展示門戶可以實現根據臨床應用、管理決策、公眾信息等多種應用類型，完成患者完整診療信息的不同視角展示，也可以方便的根據不同用戶的偏好，配置不同布局的展示界面。
3 整體數據流分析
患者的診療數據，從離散的存儲在各個業務系統到轉換成一條條HL7消息用來支持系統間的業務交互，再到一條或多條HL7消息集成為一個完整的CDA文檔，接著CDA文檔中承載的患者醫療信息并存儲在區域CDR中，最后通過Portal以各種形式展示出來，這個數據轉換流程本身就集中體現了整個共享過程的技術精髓，整個流程如圖 5所示。
圖5
數據轉換流程
Figure5.
The data conversion process
整個數據轉換流程描述如下：
(1) 從業務數據到HL7 ER7消息
當設定的觸發事件發生時，院內信息交換引擎即刻按既定的數據規則從業務系統抽取患者診療數據，不論業務系統提供的是何種類型的數據、數據本身遵從何種標準，引擎都能將所得數據清洗、轉換為標準的HL7 ER7格式。
(2) 從HL7 ER7消息到CDA文檔
對于患者的一次診療行為，勢必需要多條HL7 ER7消息才能完全描述，而患者醫療信息向區域集成平臺推送時，多條消息分別傳輸會導致多次連接和無法保證信息完整性等問題，因此在院內，交換引擎將數據轉換為HL7 ER7格式后，會以患者為線索，將患者的多條消息打包成一個完整的CDA文檔[13]。
(3) CDA文檔的推送
院內信息交換引擎將在CDA文檔生成后，通過Web Services將其推送到區域信息處理引擎。
(4) CDA文檔解析為HL7 ER7消息
包含患者一次診療過程完整有效信息的CDA文檔，將被區域信息處理引擎解析為多條HL7 ER7消息，并由引擎傳遞到CDR中。
(5) 患者信息的結構化存儲和展示
HL7 ER7消息將被解析、存儲在CDR中，而CDR對臨床信息強大的組織和處理功能，將有效的提供患者結構化醫療數據的關聯性，更好的通過Portal技術對縱向、完整的醫療信息進行不同視角的展示。
4 結語
區域醫療信息集成平臺，將患者的診療信息、衛生經濟信息與醫院管理信息等進行最有效地收集、儲存、傳輸與整合,實現各類業務流程的最優化和信息利用最大化[14]，支撐了區域性醫療衛生信息服務，是集業務、管理、協調為一體的綜合醫療信息服務平臺的體系架構。通過建立信息集成平臺，實現了患者不同時間、不同醫院產生的醫療信息的統一展示，加強了醫療資源整合，整體提高了區域性醫療服務、醫療救治、疾病預防、衛生監督執法管理水平和應對突發公共衛生事件的能力[15]。
