訂閱式診療消息提醒與處理系統(tǒng)設(shè)計與實現(xiàn)

□ 陳培俊 CHEN Pei-jun 林傳洲 LIN Chuan-zhou 林清芯 LIN Qing-xin

在醫(yī)院信息化的助推下，醫(yī)院建立了大量的信息系統(tǒng)，收集重要的醫(yī)療信息。由于信息孤島的存在或者缺乏有效的重要信息的提取手段，很多重要的診療信息不能及時通知相關(guān)的醫(yī)務(wù)人員。在當(dāng)前復(fù)雜的醫(yī)療環(huán)境下有效的溝通是保障醫(yī)院安全的基礎(chǔ)，醫(yī)務(wù)人員之間的溝通不良是醫(yī)療差錯與意外的主要原因[1]。因此加強(qiáng)醫(yī)務(wù)人員之間的有效溝通，保證信息對稱已經(jīng)成為各醫(yī)療機(jī)構(gòu)關(guān)注的焦點。

為增強(qiáng)醫(yī)務(wù)人員之間的溝通及提高其溝通質(zhì)量和效率，國內(nèi)外醫(yī)院和醫(yī)療研究機(jī)構(gòu)做了很多嘗試[2-3]，如即時通訊工具，像微信、釘釘。即時通訊工具具備較高的靈活性，但是要求雙方同步進(jìn)行溝通，而且通訊工具獨立于臨床信息系統(tǒng)，存在信息提取困難，抄送易出錯，處理困難及信息泄露等問題。

現(xiàn)有信息系統(tǒng)需要醫(yī)務(wù)人員甄選重要的診療信息，有時還需到其他的信息系統(tǒng)做處理，操作復(fù)雜，容易遺漏重要的診療信息，造成診療差錯或意外。

針對以上問題，我院設(shè)計并開發(fā)了訂閱式治療消息提醒及處理系統(tǒng)。該系統(tǒng)具有異步、松耦合、多點通訊等特點。包括消息產(chǎn)生模塊，消息傳輸模塊，消息展現(xiàn)及處理模塊，系統(tǒng)管理模塊。用戶根據(jù)需求訂閱消息，消息產(chǎn)生模塊根據(jù)用戶訂閱的消息類型檢索相關(guān)診療信息，產(chǎn)生消息，由消息傳輸模塊及時傳輸?shù)娇蛻舳苏宫F(xiàn)，用戶接收并處理消息。通過該系統(tǒng)及時推送用戶訂閱的消息，過濾冗余信息，滿足醫(yī)務(wù)人員個性化需求，減少無關(guān)信息打擾，提高工作效率，及時實施下一個診療計劃，保障醫(yī)療安全，提高醫(yī)療質(zhì)量。

系統(tǒng)設(shè)計及實現(xiàn)

訂閱式治療消息提醒及處理系統(tǒng)由Server 端、客戶端、消息傳輸模塊、WEB SERVICE 組成(圖1)。系統(tǒng)的各種診療消息通過消息的形式由服務(wù)端推送到消息傳輸服務(wù)器，再由消息服務(wù)器推送到客戶端，客戶端接收消息并展現(xiàn)。C/S 結(jié)構(gòu)交互性強(qiáng)，響應(yīng)速度快，同時要求客戶端不能通過正常手段關(guān)閉以實時接收診療消息，所以采用C/S 模式構(gòu)建系統(tǒng)。

圖1 系統(tǒng)結(jié)構(gòu)圖

1.消息傳輸模塊。TCP 是一種面向連接的、可靠的傳輸層通信協(xié)議。消息傳輸模塊與服務(wù)端，客戶端均采用TCP協(xié)議建立SOCKET 連接，保證消息實時、可靠傳輸。系統(tǒng)設(shè)計并實現(xiàn)了一個高性能的消息傳輸模塊，支持5 萬個客戶端同時在線(圖2)。

圖2 消息傳輸模塊

2.服務(wù)端。服務(wù)端負(fù)責(zé)客戶端管理及診療消息的數(shù)據(jù)檢索與處理。

2.1 客戶端管理功能包括客戶端的版本升級、消息展現(xiàn)模塊版本更新、消息同步等?？蛻舳嗽O(shè)計成不能通過正常手段關(guān)閉，客戶端接收到版本更新消息時，強(qiáng)制退出升級。消息展現(xiàn)模塊基于WEB 技術(shù)實現(xiàn)，客戶端接收到展現(xiàn)模塊更新的消息后，使WEB 瀏覽器控件重新加載頁面實現(xiàn)版本更新。WEB 瀏覽器重新加載導(dǎo)致消息展現(xiàn)頁面初始化，之前接收的消息信息丟失。因此在WEB 展現(xiàn)模塊版本更新后，需重新推送客戶端已接收未處理的消息使客戶端正確展現(xiàn)消息。

2.2 數(shù)據(jù)檢索及處理。服務(wù)端根據(jù)消息種類，檢索HIS、LIS、PACS 等業(yè)務(wù)系統(tǒng)，產(chǎn)生客戶端訂閱的診療消息數(shù)據(jù)并存儲到數(shù)據(jù)庫。通過消息傳輸模塊推送到客戶端。診療消息產(chǎn)生與消息傳輸采用獨立的線程完成。消息存儲到數(shù)據(jù)庫有利于消息的跟蹤、處理控制及消息能可靠的推送給醫(yī)務(wù)人員。

2.3 消息產(chǎn)生及推送機(jī)制。服務(wù)端檢索出符合條件的診療消息后，根據(jù)客戶端的訂閱消息種類，插入到消息表。該消息表存有這條消息要發(fā)送到哪個客戶端，消息的狀態(tài)等。服務(wù)端在確認(rèn)客戶端當(dāng)前在線時，推送消息到客戶端，客戶端接收到消息后，更新該表的消息狀態(tài)。這樣就能準(zhǔn)確可靠地讓醫(yī)務(wù)人員接收到消息，從而執(zhí)行下一步的診療計劃。

3.客戶端?？蛻舳擞上⒔邮漳K、消息展現(xiàn)模塊及系統(tǒng)配置功能組成。

3.1 客戶端配置。首次啟動客戶端時需用戶配置科室信息，以便于有些消息推送到科室所有客戶端?？蛻舳嗽诮邮盏较r，需調(diào)WEB SERVICE 接口更新消息狀態(tài)，服務(wù)端如果認(rèn)為客戶端還未接收到消息，在下個周期繼續(xù)推送該消息，直到客戶端接收到消息為止。此外客戶端需發(fā)送心跳消息以告訴服務(wù)端是否在線，服務(wù)端僅在客戶端在線時推送消息，以減少不必要的性能消耗?？蛻舳丝梢杂嗛喿约焊信d趣的消息(圖3)，以減少無關(guān)消息打擾。

圖3 消息訂閱

3.2 消息接收模塊。消息分系統(tǒng)消息及診療消息兩類。系統(tǒng)消息包括客戶端版本更新、消息展現(xiàn)模塊版本更新、心跳消息等。接收到消息后需調(diào)用web service 更新消息狀態(tài)。心跳消息能告知服務(wù)端客戶端的在線狀態(tài)，使消息能可靠地被接收，同時減少不必要的性能消耗。診療消息有需處理消息、需確認(rèn)消息、接收類消息。需處理、需確認(rèn)消息均需用戶處理確認(rèn)后消失，接收類消息用戶只需查看就消失。

3.3 客戶端采用內(nèi)嵌谷歌瀏覽器的方式，高效美觀的展現(xiàn)及處理消息，避免了C/S 結(jié)構(gòu)構(gòu)建界面復(fù)雜的問題。客戶端接收到診療消息后，調(diào)網(wǎng)頁的接收消息接口提醒用戶收到新消息?？蛻舳瞬粌H提醒新消息，展現(xiàn)消息內(nèi)容(圖4)，還可以處理消息(圖5)。避免了醫(yī)務(wù)人員再到相應(yīng)的業(yè)務(wù)系統(tǒng)做業(yè)務(wù)處理，提高了工作效率，也減少了信息錄入錯誤導(dǎo)致的差錯。

圖4 消息明細(xì)

圖5 消息處理

展望

訂閱式診療消息提醒及處理系統(tǒng)準(zhǔn)確及時地給醫(yī)務(wù)人員推送業(yè)務(wù)相關(guān)的提醒消息，避免無關(guān)消息打擾，讓其更及時地實施診療行為。同時系統(tǒng)具備業(yè)務(wù)處理的功能，醫(yī)務(wù)人員不用再到相應(yīng)的業(yè)務(wù)系統(tǒng)進(jìn)行處理，提高了工作效率，減少了差錯。該系統(tǒng)的應(yīng)用，能實現(xiàn)醫(yī)務(wù)人員更高效地協(xié)同工作，是保證醫(yī)療安全和提高醫(yī)療質(zhì)量的有效手段，在我院的實際臨床應(yīng)用中取得了良好的應(yīng)用效果。接下去會根據(jù)醫(yī)療業(yè)務(wù)需求，推送更多診療消息以滿足醫(yī)務(wù)人員需求。