小規模非公有制醫院門診信息系統的應用研究

焦瑋, 楊雪寒, 孟潔, 張倩

(河北醫科大學第三醫院, 河北 石家莊 050051)

0 引言

大型公立醫院門診信息系統大多都是以小型機作為系統平臺，采用集中方式進行部署。由于小規模非公有制醫院的信息化應用水平有限，采用此類方式建設和部署門診信息系統將會導致系統建設費用高、系統可運維性不高以及系統可拓展性差等問題，為此本研究采用具有良好可擴展性的分布式系統架構以替代集中式的系統架構建設和部署門診信息系統[1-3]。本文以河北醫科大學附屬醫院門診信息系統為例，闡述了以分布式體系架構對現有醫院信息系統進行部署的應用實踐。所研究的醫院信息包括十個子系統，每個子系統之間都存在復雜的邏輯關聯以解決門診、取藥、住院等繁雜的業務需求。目的是使用分布式體系架構完成對現有醫院信息系統的重構，使其具有滿足業務需求的高度可靠性和必要的運行效率。主要研究的是系統中系統消息路由、業務狀態以及應用程序數據之間的交互，而不是描述系統的詳細實現。通過具體的應用實踐對該分布式體系架構的有效性進行必要驗證。

1 研究背景和目標

河北醫科大學附屬醫院的醫院門診信息系統具有10多個子系統，如圖1所示。

圖1 門診信息系統架構

這些子系統之間存在很多數據交互。當患者在門診掛號時，門診子系統可以按掛號訂單處理該患者。然后將掛號訂單轉發到相關子系統以進行進一步的工作。例如，針對患者掛號訂單的放射檢查指令將通過門診信息系統的放射子系統轉發至放射科信息系統(RIS)。當患者在放射科完成X射線檢查后，RIS中將生成一個第三方系統的記錄返回給門診信息系統的放射子系統。許多患者掛號訂單需要在子系統和外部第三方系統之間進行狀態變更和數據交互，因此門診信息系統需要靈活的體系結構來解決內部的不同子系統和第三方系統之間頻繁的數據交互需求。

一般從三個維度對醫院門診信息系統的性能進行評價：高可用性、高可拓展性和高性能。本研究使用冗余服務器、負載均衡器和應用程序集群來實現這三個性能指標。在傳統的集中式系統架構中，門診信息系統由幾個異構操作系統和數據庫組成，如OS/390、HP-UX和Windows 2000服務器等操作系統，以及DB2、Sybase和Microsoft SQLServer等數據庫[4-5]。在如此復雜的運行環境中顯然無法保證系統高度可靠性、數據一致性和良好的系統可擴展性。為此本研究將基于統一的Windows 2003和Oracle RAC對門診信息系統進行重構，以確保新的門診信息系統的高度可用性以及不同數據庫中數據的一致性。

2 系統架構

本研究選擇SOA作為門診信息系統運行的系統環境。使用基于Web的用戶界面構建系統面向終端用戶的系統操作交互頁面。Web用戶界面服務器(WebUI)是為用戶瀏覽器生成系統交網頁的服務器。本研究使用Microsoft StateServer[6]來存儲來自WebUI的網頁會話。身份驗證Web服務器(Auth-WS)通過標準SOAP協議[7]為終端用戶提供身份驗證和授權，并且啟用單點登錄(SSO)[8]為門診信息系統提高足夠的安全保障。

HL7消息[9]服務器(HL7 Server)也是基于SOAP協議的Web服務。HL7 Server是通過SOAP協議上的HL7消息構建的。門診信息系統的后端HIS數據庫(HIS DB)通過運行Oracle RAC環境以實現高可用性。為了實現數據一致性，門診信息系統設置了數據交換(DataExchang)服務器。該服務器僅接收從HL7 Server發送的消息。當DataExchang服務器接收消息時，它將執行數據同步作業，例如將患者實驗室訂單發送到HIS數據庫或將新的掛號注冊患者數據發送到存儲服務器(DB Server)上。此數據交換處理可以確保其他系統中的所有數據都是最新的。門診信息系統的基本運行邏輯，如圖2所示。

圖2 門診信息系統的序列圖

由圖2可知，門診信息系統所涉及的服務器包括WebUI、Auth-WS、StateServer、HL7Server、DataExchange和HIS DB。這些服務器為虛擬服務器，且構成了ServerFarms集群網絡[10-11]。除HIS DB之外，所有虛擬服務器均具有映射的四層交換機定義的虛擬IP。該集群網絡中部署了四臺物理服務器，并被配置為以負載平衡模式或故障轉移模式運行，以確保系統可用性。為了擴展系統并提高性能，為目標IP地址(如SOAP接口調用、HL7消息接口和DataExchang協議)提供了一個虛擬IP，該虛擬IP也在第4層交換機中定義。每個服務器組在醫院內網和ServerFarms集群網絡中都有對應的虛擬IP。由于Web服務器或HIS核心服務器以負載平衡模式運行，因此HIS可以將任何已配置的服務器動態添加到ServerFarms集群網絡中以處理用戶請求[12-13]。如果Web服務器的負擔不大，還可以直接從四層交換機配置中刪除一些Web服務器。因此，門診信息系統的維護變得更加容易和有效。硬件架構，如圖3所示。

圖3 門診信息系統硬件架構

3 應用結果

河北醫科大學附屬醫院在開展本系統的應用實踐。該醫院的門診總數約為180個，但同時開設的門診科室總數約為150個。大約有40個掛號和收費柜臺。同時，病歷部門運行著約60個工作站，藥房運行著20個工作站，實驗室注冊站點運行著10個工作站。其他科室和部門中也同時存在運行著少量工作站。因此，該醫院全天總共約有500個工作站同時訪問門診信息系統。

經統計，醫院一天大約需要為9 000名門診病人提供服務。這意味著本研究所架構的門診信息系統應持續、可靠地為500個工作站連接提供服務并處理其訪問請求。為此本研究從以下幾個方面來評估系統的性能。

3.1 四層交換機TCP連接數

本研究使用多路網絡通信量繪圖儀來監視四層交換機的運行狀態。對四層交換機進行一個星期的性能監視，所得出的各個虛擬服務器的最大會話數，如表1所示。

表1 最大會話數和平均會話數

表1中 “30分鐘最大會話數”表示單個虛擬服務器在采樣時間中所處理的TCP會話總數?！?0分鐘平均會話數”表示連續五分鐘的六次會話的平均值。

可以得出在一周中四層交換機總會話次數的峰值為1 253。

3.2 WebUI統計

WebUI直接處理用戶瀏覽器請求，然后根據需要處理身份驗證調用，HL7 Server 提供SOAP調用和數據交換調用的功能。對于WebUI頁面的每個處理時間代表門診信息系統的響應時間。

本研究通過分析Internet信息服務(IIS)的日志文件以獲得Web服務器每天的總請求數和一天中每小時的平均響應時間的統計結果。門診信息系統由10個子系統組成，所有子系統都部署在20臺WebUI服務器中。每個WebUI服務器為10個子系統提供用戶界面和交互服務。這10個子系統是門診管理子系統、門診子系統、檢測子系統、病理子系統、傳染病報告子系統、病歷管理子系統、門診調度管理子系統、放射科子系統、門診計費子系統和藥房管理子系統。每個子系統都有不同的用戶請求和數據交換操作。下面就門診管理子系統、診所子系統、門診計費子系統和總體統計結果進行具體闡述。

1)當日總請求數和平均響應時間的統計。以門診管理子系統為例，該子系統處理患者掛號、掛號查詢、掛號更新、查詢患者數據、患者數據更新和其他一些用于掛號和維護患者數據的輔助功能。對門診管理子系統的Web請求的統計數據，如表2所示。

表2 門診管理子系統的請求IP總數

由表2可知，全天一共有172個客戶端訪問門診管理子系統，該子系統全天約有2.4萬個網頁請求。

門診子系統一天內有將近28萬個頁面請求。 在門診HIS中，它占所有請求的69%。門診子系統也是使用最多的子系統。每天大約有600個用戶客戶端訪問診所子系統。這意味著一天中將近70%的HIS用戶使用門診子系統。

對于一天中的平均響應時間，如表3所示。

表3 WebUI的響應時間

由表3可知，診所子系統的平均響應時間為0.562 s，標準偏差為1.145 s，最大響應時間為154 s(154 s的響應時間也是所有子系統中最大的時間成本)。在長頁面執行中應該存在一些編程或數據訪問問題。頁面響應時間長，可以幫助發現門診信息系統中潛在的編程問題。所有子系統請求的平均響應時間為0.566 s，標準偏差為1.250 s。

2)全天中每小時的統計信息。為了評估請求和響應時間，本研究統計了當天的每小時總請求數和平均響應時間，如圖4所示。

圖4 門診子系統的平均響應時間

在診所子系統中，從07:00到20:00的平均響應時間不到1 s，如圖5所示。

圖5 診所子系統的總訪問請求數

早晨的高峰請求是10:00到11:00，大約有40 000個請求。從14:00到15:00是下午的高峰請求，大約有37 000個請求，如圖6、圖7所示。

圖6 門診管理子系統的平均響應時間

圖7 門診管理子系統的總訪問請求數

顯示了門診管理子系統的總請求數和平均響應時間。門診計費子系統的總請求數和平均響應時間，如圖8、圖9所示。

圖8 門診計費子系統的平均響應時間

圖9 門診計費子系統的總訪問請求數

這兩個子系統在07:00至20:00的平均響應時間約為1 s，而在07:00之前和20:00之后的平均響應時間有所不同。

4 結果討論

本研究所重構的門診信息系統中運行著20臺WebUI服務器和20臺HL7消息服務器。在應用實踐中對四層交換機和WebUI的響應時間和會話數量進行統計和匯總，以驗證系統的性能。其中WebUI響應時間包括服務器場中的后端操作，例如身份驗證、基于SOAP協議的HL7消息接口調用和數據交換操作。

每小時響應時間和會話數統計結果表明，門診信息系統的響應時間在07:00和20:00之間比較穩定，在負載較重的門診子系統和計費子系統中也是如此。在上午10:00和下午15:00的高峰時段，整個門診信息系統能夠保持穩定運行，響應時間約為1 s。這意味著所架構的門診信息系統具有較好負載響應性能。

響應時間在上午07:00之前和下午20:00之后出現變化的原因是，當子系統當前沒有加載至內存中時， WebUI應用程序需要時間來緩存數據庫中的一些常用數據。從上午00:00到上午07:00的門診管理響應時間在0.6～1.23 s之間有很大差異，這是因為一些患者在午夜從醫院急診信息系統中進行門診掛號操作，這導致響應時間較長。此外，門診信息系統會在連續20分鐘內沒有訪問請求的時候基于IIS對子系統進行內存回收，子系統的回收和啟動會產生響應時間變長。

5 總結

本文通過分布式體系架構對基于小型機集中部署的門診信息系統進行了重構。在分布式體系架構中，門診信息系統可以實現數據高效交換和保持多個系統之間的數據一致性。該體系架構使用四層交換機作為服務器集群的負載平衡器，為門診信息系統提供了高可用性和可拓展性。在該體系架構中，可以將已配置的服務器動態添加到ServerFarms中，為門診信息系統提供良好的可拓展性能。本文通過應用實踐獲得了包含四層交換機和WebUI的會話數和響應實踐的統計數據。 統計結果表明，基于SOA和分布式體系架構的門診信息系統能夠在負載較重的實際環境提供較好系統響應性能。