醫院信息控制平臺的設計與開發

管 啟 康

(臺州市中心醫院(臺州學院附屬醫院)信息中心 浙江 臺州 318000)

0 引 言

隨著信息化時代的來臨，醫院管理大多采用HIS，它是醫院管理和醫療活動中進行信息管理和聯機操作的計算機應用系統[1-10]。HIS軟件開發商眾多，軟件種類繁多(如門診系統、住院系統、醫技系統、藥房系統、后勤物資管理系統等)，職能上各自專一且分工明確，每個部門的工作人員也只關心其職能相對應的軟件系統的使用，這在很大程度上將整個醫院的信息化辦公環境模塊化。

鑒于HIS軟件系統分工明確，功能專一，使得各個HIS軟件之間顯得相對獨立，沒有縝密的聯系和承接。譬如，門診醫生工作站只專注于醫生的就診，其不能執行其他醫院業務流程上的操作。病人一旦有其他就醫行為需求，就要到指定的相關科室或部門才能繼續操作。“看病就診一條龍”的服務只能讓病人從鏈路的開端順利地執行到結尾，并不能網狀式地開展業務。醫生接診患者并進行問診后，建議患者轉科掛號的場合，患者需重返鏈路開端，重新掛號，重新排隊等待就診，并不能在醫生診間內化解問題，為病人改號轉診。因此，當一個HIS軟件需要另一個HIS軟件來協作實施一些具體操作時，工作人員往往只能聯系對應科室的工作人員協助處理，導致醫院整體業務效率下降。

HIS軟件功能專一帶來的影響不僅體現在病人就醫方面，對醫護人員的日常工作業務也有負面影響。根據醫院的管理制度要求，醫生在給病人首次開具精神麻醉處方藥品的時候，需要向負責部門申請批準才能開方；住院醫生要實施高難度級別手術的場合，也需要病區責任醫師統一批準才能進行手術。這些“需要上級部門或者后續負責人員批準”的申請流程，會因為HIS軟件系統之間的低鏈接、低承接性質而產生斷層和滯后，提出申請或遞交流程后還需主動電話通知后續流程的負責人員，方能實現，導致有些緊急的手術和醫護行為會因為流程審批制度而被拖延，耽擱了病人的最佳治療時機。

1 中央控制平臺的設計與開發

控制平臺軟件系統是HIS軟件系統里的一個具體應用程序[11]，需要與其他各個HIS軟件系統進行交互通信，編程開發語言選用PowerBuilder 9.0(下文用PB簡稱)。PB的主要特點在于面向高效穩健的數據庫連接操作，非常符合醫院軟件系統開發的主流編程方向。目前多數HIS軟件系統也采用PB編程語言，在軟件系統架構上具有很好的連通性。

控制平臺的業務職能簡而言之就是通知告警的轉發和傳遞。其軟件層面上的做法是：每臺電腦上運行的控制平臺服務會獲取本機上運行的HIS軟件列表、中央控制端的服務情況以及消息隊列里的消息列表；HIS軟件系統不再單獨各自進行交互，而是全局統一向控制平臺推送與拉取消息通知(如圖1所示)，以達到平臺整合統一的通信方式。

(a) 控制平臺開發前HIS系統的通信方式

(b) 控制平臺開發后HIS系統的通信方式

分流機制和其他算法機制也要予以考慮。全院電腦在“聯絡網”上互相通信的過程中，難免會產生大量的網絡流量，造成網絡擁堵。良好的通信機制和報文組織方案是解決問題的一種途徑，在項目設計時應對這兩方面進行改進和優化。

1.1 功能需求

該醫院信息控制平臺的軟件系統分為客戶端程序與服務端程序。客戶端為終端電腦提供消息的生產轉發以及接收消費的功能，具備服務參數的配置界面，并起到具體的操作界面展示效果；服務端只需安裝并運行在控制平臺終端服務器上，連接消息隊列數據庫以及配置數據庫，接收全院各個終端的客戶端的通信連接、消息推送、消息拉取行為，并且提供配置界面以提供控制平臺管理員進行配置調整和數據監控分析。

對于系統管理員，可以進行以下操作：對中央控制終端軟件系統的登錄登出操作；對用戶進行管理，新建用戶，分配權限，建立并設置分組；對終端電腦進行管理，新建終端對象，設置片區和分組，配置通信連接端口和具體信息，對其流量和在線狀態進行監控；對消息列表進行管理，查看隊列情況并對其進行增刪改操作，設置消息的轉發規則和去向，并對消息的具體生成情況進行探究和質量分析改進。

對于客戶端控制平臺軟件程序，可以進行以下操作：配置消息的接受發送參數，包括通信端口和鏈路通道、重連時長、消息的主動被動推送模式；配置與HIS系統的聯通模式和具體參數；查看消息接受發送的日志，檢查軟件系統的運行情況。

1.2 核心流程

軟件系統的核心軟件功能主要集中在消息傳遞轉發上。消息傳遞包括消息的產生、消息的傳輸導向設置、網絡消息傳播、客戶端上的消息接收以及分發并展示在指定應用程序上這五個步驟。其中傳輸導向設置是控制平臺管理員的設置任務，通過對各項消息報文的分類歸并，從全局上設置好哪些消息需要轉發給哪些客戶端電腦，消息是即時發送還是需要短期甚至中長期保留備案的，消息的發送是否要求再度反饋的，各臺終端電腦的接收端口開放情況等。一旦設置完畢，產生的消息即可從中央控制臺獲取整條轉發鏈路的基本信息，然后將消息投遞至終端消息通道或是同網段內的廣播信道，最后將消息投遞至目標終端。系統的核心流程圖如圖2所示。

圖2 控制平臺核心業務流程

1.3 消息轉發接收機制

控制平臺的應用軟件產品可以分為客戶端程序(Client，下文稱之為終端控制臺或終端)與服務端程序(Server，下文稱之為中央控制臺)。終端控制臺安裝運行在全院各臺電腦上，而中央控制臺則部署在專設的一臺平臺服務器上。終端需要聯通中央控制臺進行整體資源部署和鏈路分配(如圖3中301部分)，獲取并投遞通信消息資源；中央控制臺從醫院整體層面觀察檢測各終端的運行狀況和健康程度，接收消息的生成，并將消息存放在頂層消息隊列，或是投遞到對應的目標終端電腦上；終端還能向服務端請求任務委托權限，向其內部網段的其他終端廣播轉發簡單消息內容(如圖3中的302部分)，并在所處網段內形成消息隊列閉環。

圖3 控制平臺的服務端與客戶端的通信模式

1.4 消息傳遞機制

各HIS系統與控制平臺之間的消息傳遞機制(又可稱為消息監聽機制)可分為主動、被動兩種，如圖4所示。其概念是控制平臺如何去跟HIS軟件系統進行交互以及消息轉發。主動、被動都是從控制平臺角度出發來定義的。主動監聽即為平臺定時的會去詢問HIS軟件系統，主動投遞消息或是提取挖掘其潛在狀況；被動的消息接收則是平臺被動的接收來自HIS軟件系統的告警消息，然后進行解析和轉發投遞。

圖4 控制平臺與HIS系統的監聽機制

1.5 網絡通信機理

從整個通知分發的鏈路情況來看，一共有四種消息流通方向，如圖5所示。一種是從HIS軟件系統到終端控制臺的鏈路，稱之為消息產生(Message Produce)、告警預警，如圖5中501部分；反向的，從終端控制臺返回到目標HIS軟件系統的鏈路，稱之為消息消費(Message Consume)、消息處理、消息響應，如圖5中502部分；終端與中央控制臺之間的鏈路，稱之為消息的上行下行(upload download)、消息發布(publish)、通知訂閱，如圖5中503部分；同網段的幾個終端之間的消息相互傳遞，稱之為消息級聯廣播(broadcast)，如圖5中504部分。四種鏈路通信情況的編程開發手段不同，針對的問題不同，所以要采取不同設計模式和編程手段來實現。

圖5 消息在整個控制平臺里的流通方向

1.6 消息隊列管理邏輯

消息隊列[12-16]是一個消息產生后，在醫院內整個生命周期的活動時限里的管理機理。消息會根據其功能需求，劃分為通知和資訊兩種，如圖6所示。通知在一次完整的消息產生-轉發-消費行為之后即可消亡，其在消息隊列里留存的時間大約在幾分鐘、數小時甚至幾天內，超過一定的時間后就失去了其及時性和有效性，然后會被中央控制臺清理消除；而資訊則不是一條單鏈路，其有效性也可以長達三五年之久，這些消息則會在消息隊列中長期停留，在需要的時候為用戶提供信息的下載查閱。

(a) 通知式消息

(b) 資訊式消息

1.7 設計分析

(1) 控制平臺業務職能范疇的劃分。為了使平臺運行順暢，需對各HIS軟件系統功能進行分析，且需要跨模塊解決的申請和操作，才允許接入平臺，并提出解決方案。因此，需要各職能科室的方案制定者進行嚴謹的討論和商定，定位控制平臺的業務范圍。

(2) 控制平臺底層通信手段的制定。一個是通信在應用層上的機制，即采用軟件工程上的各種手段進行通信；另一個是通信中報文字段的設計定義，即通信中要表達的內容和方式。因現場轉發的消息性質和內容繁多，鏈路也較復雜，所以需要確立一種通用的標準模式，來轉發并解析消息通知。

(3) 各個HIS軟件系統通信和接口的調整。各HIS軟件要想接入控制平臺，需要在兩端都進行適當的調整改造，以達到與平臺聯通的目的。這項工作難度大，需要與各HIS軟件開發商協商，制定整體的調整修改方案。

2 技術路線

2.1 技術路線圖

整體項目分為三個階段，如圖7所示。

圖7 控制平臺設計開發的技術路線

(1) 技術論證。首先要對醫院信息控制平臺的可用性進行判定。以一條基礎的消息推送鏈路的聯通為核心目標，搭建控制平臺終端服務器，配置相配套的應用數據庫和消息隊列數據庫，設置終端電腦的配置參數，設計、開發、調試并安裝運行控制平臺的服務端程序；設計開發客戶端程序，并安裝運行于院內兩臺客戶端終端電腦上，配置與HIS軟件系統的聯通參數以及同中央控制端的聯通參數；對特定的HIS軟件系統進行改造擴展，使其能生產消息將其推送，并且能被動接收控制終端服務推送的消息報文并且將其展示。在固定好各項參數和測試規模環境后，調試程序，使得其中一臺終端電腦上的HIS軟件系統產生的一條消息能被另一臺電腦所接收展示，即可證明該醫院信息控制平臺的通信鏈路的可行性，并移步至下一階段。

(2) 模塊接入。以論證階段的軟件系統和網絡部署為參考基礎，在此基礎上進一步對業務功能進行明確細化。對控制平臺服務端程序進行模塊化分析和設計，整理出可視化操作監控和配置界面，提供管理員登錄登出功能，單例、批量的終端配置監控功能，日志檢索功能。對客戶端程序也進行模塊化分析擴展，實現消息的主動推動和被動拉取功能，同中央控制臺和本機HIS軟件系統建立通信連接機制。對消息的報文解析和封裝組成進行規范化的協議制定，提出共用的報文模板和擴展內容填寫規范。對中央消息隊列進行優化，對消息訂閱、轉發模式進行細化，研究客戶終端對同一網段的廣播模式的集成聯通討論。在設計開發的過程中，對實驗結果進行記錄分析，并不斷提出改進方案和思路，反復對整體鏈路方案進行優化改善，提高消息轉發的效率和可靠性，最終形成可以發布的成品版本。

(3) 模塊擴展研討。在上一階段完畢后，即可討論考慮產品的模塊通用化以及行業內的橫向對外功能的拓展能力。同各臨床科室部門溝通，了解各個使用者對產品的需求和性能要求，再對本次的醫院信息控制平臺提出改進方案。對接口進行封裝和可配置項的改造，對數據庫的鏈接模塊進行模塊提煉和可配調整，對網絡的適應性也加入配置考慮，以應對該套軟件系統程序移植部署到其他醫療衛生單位后，無需大量的程序開發調整，只從配置上著手就能快速部署并投入使用的動態可配置的軟件使用模式。從應用軟件系統的行業規范標準出發，對整體系統的運行情況增加日志記錄模塊，對網絡實時流量進行可視化監控和預防預警功能，對網絡上傳輸的信息進行加密認證以確保信息安全，對控制平臺服務器進行集群改造考慮。

2.2 主要技術指標

(1) 提升響應速度。通過控制平臺的接入，HIS軟件系統發生異常或者通知報警的場合，通過網絡鏈路在0.1秒內就能通知到負責人員，比起電話溝通(大概5～10 s)的效率要高出許多。而且通過優化網絡通信協議，現場情況能全面地整理呈現在使用者面前，比起人員口頭交流，效率更是有所提升。全院過半的電腦同時發生狀況報警時，中央控制臺的消息隊列處理能力控制在0.1秒以內。

(2) 減少維護成本。通過程序的級聯通信，可以減少現場人員的維持維護成本、設備的維修成本、人員流動上的時間消耗，在人力物力時間上提高效率。

(3) 提高問題處理效率。通過控制平臺對信息的發掘和匯報，給出合理建議和操作指導，現場問題的解決率會得到提升，病人滿意度也會提升，從而為醫院創造經濟效益。

3 控制平臺的作用

(1) 現場狀況能及時得到發現和反饋。以當前的HIS軟件系統架構，單一的HIS應用程序所發生的狀況或問題沒有途徑能反映到其他HIS系統上。而控制平臺的主要職能之一就是能將問題信息及時準確地傳遞散布出去，很好地解決這一缺陷。

(2) 跨系統、跨部門、全方位的數據展示。通過搭建各個HIS軟件系統間的通信網絡，可以對患者的門診、住院、檢查行為進行全方位的信息展現和醫護保障，對患者的潛在風險狀況進行及時提醒，在患者各個診間的移動過程中提供信息上的無縫連接，為醫護人員提供患者更完整的信息材料，從而更好地為患者提供醫療服務。

(3) 為大數據處理和智能化解決方案提供服務。通過收集并積累消息的發源和分類，以及智能庫的錄入和更新，控制平臺能更好地了解工作人員的實際需求，響應現場工作人員的操作需要，在其他人員響應之前給出合理建議和操作指導，從而給醫生和醫護人員帶來便利。

總之，控制平臺搭建的這張全院“聯絡網”，可以提高病人的就診效率，使醫院各部門科室的聯絡溝通更高效，醫院的業務流程更順暢。此外，控制平臺還有極好的系統拓展能力，通過加載智能化的決策響應機制，提供通用接口以擴展更多的硬件設備，以及對控制平臺模塊化的產品封裝，使得控制平臺在今后的拓展應用方面更加廣泛。

4 結 語

該醫院信息控制平臺是全新開發和實施的軟件，聯接了醫院信息系統中的各HIS軟件，能快速反饋現場出現的問題，全方位展示患者的就診信息，方便患者就醫和醫生診療，提高了醫院的管理水平。控制平臺軟件系統模塊通用性強，具有可擴展的接口設計，獨特的編程語言，系統穩定性高，能推廣到不同的醫療單位或其他多系統軟件的單位。