醫用氣體實時監測平臺的設計與實現

張凡進 郭立君 張 榮 周豐平

1(寧波大學信息科學與工程學院 浙江 寧波 315211) 2(寧波視線軟件科技有限公司 浙江 寧波 315200)

0 引 言

醫用氣體是指醫療過程中使用的氣體，用于治療、麻醉患者或驅動醫療設備等，常用的醫用氣體有氧氣、氮氣、二氧化碳、壓縮空氣、真空吸引等。醫用氣體系統是指生產醫用氣體或抽排廢氣廢液的一整套裝置。醫用氣體系統建設關乎患者生命安危和醫療環境安全，作為生命支持系統，它是現代醫療體系的重要組成部分，具有廣泛的應用。相關規范[1]規定：醫用氣體系統宜設置集中監測與報警系統。由于該規范缺乏強制性條款，落實情況并不樂觀。醫院各站房和樓層的數據信息分散獨立，傳統人工巡檢抄表登記的監測方式仍在采用。傳統監測方式存在著諸多弊端[2-3]：值班員需24小時不間斷巡檢，人力成本高；巡檢周期長，難以保證監控的連續性，效率低下；安全隱患大，故障報警不能及時掌握和處理，嚴重時可能造成醫療事故；巡檢形成的數據文檔較多，數據零散，難以統一管理；歷史數據查詢困難，難以從中挖掘出有價值的信息。

為了解決傳統監測方式存在的問題，結合醫用氣體監測數據的實時性、海量性、并發性等特點，立足業務發展的需要，設計并開發了醫用氣體實時監測平臺。本文平臺實現了監測數據集中式地采集與云端存儲、遠程實時監控、報警聯動、歷史數據檢索及統計分析等功能。借助該平臺，醫院可以實時監測制氣設備的運行狀態和氣體的使用情況，保障醫療用氣的安全性和可靠性，降低維修成本，減少經濟損失。

現有一些監測平臺[4]的數據采集端針對組態軟件而設計，數據接入方式受限，嚴重影響了平臺的通用性和實用性。本文提出基于參數配置表的數據接入方式具有較強的開放性和靈活性，采集端依照約定的協議整合數據并上傳至數據接收端口，便可完成平臺的接入，監測設備的擴展便捷。針對醫院站點增加和設備增多導致的數據量增大和并發數據上傳等問題，提出一種基于緩沖隊列的并發數據處理機制，解除業務間不必要的耦合，提高了平臺數據處理的性能。平臺用戶采用分級機制，各級用戶根據需要使用設備運行數據，提高了數據利用率。現有基于WebSocket技術實時監測系統的研究工作[5-7]，缺乏對WebSocket在瀏覽器兼容性上的考慮，本平臺融合WebSocket和SockJS技術實現瀏覽器與服務端真正的全雙工實時通信，且增強了對瀏覽器的兼容性。

1 架構設計

為使平臺的處理邏輯更清晰，提高代碼的復用力度和平臺的可維護性，當需求發生變化時，方便業務的完善和擴展，設計如圖1所示的分層架構。平臺分為數據層、業務層、控制層、表現層和用戶層五層，各層各司其職，具有較強的內聚性，降低了層與層之間的耦合程度。最右側為各層相應的主要技術選型。

圖1 平臺開發架構圖

(1) 用戶層：從用戶視角對應的權限管理及功能視圖，用戶通過瀏覽器訪問表現層以獲取信息資源。

(2) 表現層：平臺具有較好的交互性，以合適的圖表形式呈現數據資源，實現平臺和用戶的交互。

(3) 控制層：該層負責業務流程及訪問權限的控制，將用戶的請求路由至業務層相應的處理模塊。

(4) 業務層：該層負責具體業務邏輯的實現，包括用戶管理、設備管理、監控報警、數據可視化等。

(5) 數據層：該層為業務層提供數據支撐，細分為數據訪問層和數據存儲層。訪問層定義了數據和文件的訪問接口；存儲層負責數據的持久化，包括數據庫和文件系統。

2 功能設計

通過對業務需求的分析，抽離出一個個功能模塊，各自負責特定任務。模塊間相互獨立，耦合度較低，便于程序的維護和功能的擴展，提高開發效率。如圖2所示，平臺劃分為用戶管理、設備管理、數據采集、監控報警、設備后維護五大功能模塊。

圖2 平臺功能模塊結構圖

2.1 用戶分級管理

平臺涉及管理員、安裝公司和醫院三種角色，并基于角色進行權限的劃分，賦予不同角色以不同的操作權限，實現了數據的隔離訪問與高效利用。管理員是邏輯上主機設備和平臺用戶的管理者，安裝公司給醫院安裝氣體設備并負責維護，醫院則是氣體設備的使用者。三者通過主機設備進行關聯，如圖3所示。

圖3 用戶-設備關系圖

管理員具有最高權限，負責安裝公司的合法性審核，進行主機設備的創建、配置、分配和綁定，可以查看監測數據；安裝公司將分配到的主機綁定至醫院，有權更改主機的配置，并基于歷史數據分析進行設備的后維護；醫院權限最低，只能查看監測數據。安裝公司在注冊時提交營業憑證，待管理員審核通過后，才能獲得相應權限。管理員與安裝公司之間、安裝公司和醫院之間、管理員與醫院之間皆為一對多的關系。

2.2 設備管理

設備管理模塊作為平臺的核心模塊之一，包括設備參數信息的配置、設備的分配、綁定和認證。設備參數配置完成后，可導出參數配置表，配置表為數據采集端整合數據提供依據。通過設備管理，明確管理員、安裝公司、醫院對設備的職責，保證設備安全。安裝公司從數據中挖掘規律，從而制定高效的設備維護計劃和升級方案，向用戶提供更優質的服務。醫院全面掌握氣體生產和運行情況、保障醫療安全，提高了設備運行數據的利用率。

如圖3所示，管理員將創建好的主機設備分配給安裝公司，安裝公司將設備綁定至具體醫院。安裝公司可以分配得到多個主機設備，但一家醫院只能有一個主機設備，且一個主機設備只能綁定至一家醫院。主機設備綁定成功后產生唯一識別碼，數據上傳時須攜帶此碼，作為設備合法性認證的依據。該模塊還提供了開關報警短信通知的功能，在此功能開啟的情況下，當設備發生報警時，會立即將報警內容以短信形式發送到醫院負責人手機上。

2.3 數據接入

部署于醫院的數據采集端依照參數配置表，采用約定的JSON格式，并攜帶設備的唯一識別碼，將數據上傳至平臺的數據接入模塊。如圖4所示為數據接入流程圖。

圖4 數據接入處理示意圖

該模塊負責對數據的完整性和合法性進行校驗。所謂完整性是指上傳的監測參數是否和參數配置表一致，合法性指取值合法性和設備識別碼是否正確。若通過校驗，則進行數據的解析存儲等其他處理并返回“數據上傳成功”的消息，否則返回數據錯誤原因。

2.4 監控報警

監控報警模塊提供了數據實時監測、異常情況平臺報警和短信報警、數據推送及數據可視化。交互性良好的可視化設計便于用戶掌握監測數據的變化趨勢，用戶可根據需要切換數據的展示方式。

圖5為監控報警流程示意圖。該模塊接收到通過完整性和合法性檢驗的數據后，解析數據包中的標志位以確定該數據是否為報警數據，如果是，再判斷該主機設備的報警短信通知業務是否開啟，若開啟，則將報警短信發送給醫院負責人，提示其及時采取應對措施，排查報警設備。無論是否為報警數據，都會進行數據的存儲，同時將數據推送到客戶端瀏覽器，實現數據的實時更新和可視化。

圖5 監控報警流程示意圖

2.5 設備后維護

平臺提供了歷史數據和報警記錄檢索、數據統計分析等功能，根據用戶設定的時間段，以圖表形式展現數據的變化情況。平臺可為用戶統計出某時間段內設備上傳的數據量、報警發生率等信息，并導出統計報表。此模塊可輔助設備維護人員做出更為合理的決策，制定更高效的設備檢修和維護方案，提高設備管理效率和服務質量。例如，對于報警發生率高的設備或區域，應提高檢修頻率，反之，可以適當降低檢修頻率。

3 關鍵技術

3.1 針對高并發情況的數據處理與訪問機制

3.1.1 并發數據處理機制

在數據接入模塊中，單條數據的處理要經過數據校驗(記為B1)和數據推送及存儲(記為B2)兩個階段。圖6(a)為常規的處理方式，在同一線程中依次進行B1和B2處理，B2處理結束后給予采集端響應，然后再處理下一條數據。當出現數據并發上傳時，數據處理速度可能會滯后于數據接收速度，從而可能造成數據的阻塞或丟失，嚴重時可能導致平臺停止響應。

(a) 常規方式 (b) 異步方式圖6 業務數據處理方式

上述處理方式中，B1和B2兩個子業務由于發生嚴重耦合，導致處理性能的下降。為此，設計了并發處理機制，如圖6(b)所示。主線程僅負責業務B1的處理，將校驗成功的數據放入緩存隊列，然后給予采集端響應，同時激活B2業務處理器，并為之開辟新線程。新線程不斷地從緩存隊列中獲取數據進行處理，同時主線程可繼續下一條數據的接收與處理。當隊列中無數據可處理時，B2處理器所在線程進入休眠狀態，以減少對服務器CPU資源的占用。這種處理機制實現了子業務間的解耦，方便與源數據處理相關業務的擴展，緩解了主線程的壓力，大大提升了服務端的響應速度和應對高并發數據的處理能力。

3.1.2 高訪問處理機制

監測數據最終持久化于關系型數據庫中，處理資源請求的過程即是對數據庫進行I/O操作的過程。當有并發訪問時，頻繁的I/O操作會使得關系型數據庫的性能瓶頸凸顯，導致數據庫系統性能下降。為此，考慮將數據緩存于內存，以應對并發訪問。如圖7所示，服務端接收到來自客戶端的資源請求，首先查找緩存中是否存在目標資源，若存在，直接獲取并返回；否則，前往關系型數據庫查找，將查找結果返回客戶端并更新緩存，以便下次訪問。

圖7 基于緩存的資源訪問設計

基于緩存的資源訪問緩解了關系型數據庫的讀壓力。由于緩存數據庫占據內存，當緩存了大量歷史數據，系統整體吞吐量將降低，內存空間也會受到壓縮，造成內存空間不足，導致整體性能下降[15]。平臺采用最近最少使用LRU(Least Recently Used)策略淘汰“過期”資源數據，以防止內存空間不足產生的影響。

在諸多緩存數據庫中，Redis能夠支持K/V、List隊列等多種數據結構，支持數據持久化。服務器斷電和重啟不會造成數據丟失。本文平臺選用Redis作為緩存數據庫。

3.2 基于參數配置表的數據接入方案

為方便監測數據接入平臺，本文提出基于參數配置表的數據接入方案。方案約定數據采集端需將監測數據以JSON數據包形式通過HTTP上傳至平臺數據接收端口。表1為方案中所設計的數據包協議，協議規定了包中應有的元素及其取值類型。

表1 監測數據JSON數據包協議

Excel參數配置表包含兩張sheet：其一描述了主機設備的唯一識別碼、數據上傳的接口地址及方式；其二明確了各設備站和區域配置的參數信息及其代號。假設某主機只啟用了二氧化碳生產設備并只監測瓶組1壓力、瓶組1低壓報警限值及出口壓力3項參數，且添加了一個編號為BF101的區域并監測該區域氧氣的使用狀態，導出的配置表如圖8所示。

(a) 主機身份及接口說明

(b) 設備站/區域參數明細圖8 某主機參數配置表

根據配置表信息和數據包協議，組織JSON數據如下，最后調用數據上傳接口將數據包發送至平臺，實現數據接入。

{

"no":" 37d8a***f0c5",

"send_time":"2018-09-01 00:00:00",

"type":"0",

"equire_list":[{

"equire_no":"CO2",

"cs_list":[{

"cs_no":"CO201",

"cs_value":"20.15"

},{

"cs_no":"CO202",

"cs_value":"18.00"

},{

"cs_no":"CO207",

"cs_value":"20.00"

}

]

},{

"equire_no":"BF101",

"cs_list":[{

"cs_no":"FO201",

"cs_value":"0.59"

},{

"cs_no":"FO202",

"cs_value":"0.35"

},{

"cs_no":"FO203",

"cs_value":"0.70"

}

]

}

]

}

該方案對數據采集端的形式未加約束，只要可以按照數據協議整合數據并進行HTTP數據傳輸的均可作為采集端，極大地提高了采集端的靈活性和平臺的開放性。

3.3 基于WebSocket和SockJS的實時通信

通信實時性是醫用氣體實時監測平臺的重要指標。服務端接收到監測數據后，應即刻將數據推送到客戶端，以實現客戶端瀏覽器數據的實時刷新，從而使得用戶能夠在第一時間掌握設備的運行狀態。

傳統實現Web實時交互的功能常采用輪詢技術和Comet技術[5-6]，Comet技術分為長輪詢和流技術。輪詢要求客戶端定時向服務端發送請求，以頻繁請求的方式保持數據的同步，但并非每次請求都能返回有效數據，由此造成帶寬資源的浪費。長輪詢與輪詢的區別在于，當服務端數據沒有更新時，請求會被掛起以保持連接，直至有數據更新或連接超時，這種方式降低了無效的網絡傳輸和請求，但請求的掛起會導致資源的浪費，且當數據更新比較頻繁時，較輪詢在性能上沒有本質的提高。流技術是客戶端向服務端發起一個長連接請求，服務端為之做出響應并不斷更新連接狀態以保持連接，服務端通過此連接將數據主動推送給客戶端。相較于輪詢和長輪詢，流技術減小了服務器處理請求的壓力，但在數據并發程度高時易造成網絡阻塞。

傳統的Web實時技術是基于HTTP協議的請求響應模式。圖9為傳統Web實時技術客戶端/服務器通信交互圖，通信只能由客戶端發起，并沒有實現真正意義的實時通信，只是借助Ajax異步請求來模擬實時交互效果。

圖9 傳統Web實時技術客戶端/服務端交互圖

醫用氣體實時監測的參數多，數據量大，數據上傳頻率高(秒級)，服務端的數據更新快，數據需要被頻繁地推送至客戶端以實現數據的實時展示。綜合以上分析，傳統的Web實時技術在醫用氣體實時監測平臺中并不合適。

WebSocket作為HTML5的新特性[8]，實現了客戶端瀏覽器和服務器之間的全雙工通信，是真正意義的實時通信。圖10為WebSocket客戶端/服務器交互圖，瀏覽器使用JavaScript向服務端發送建立WebSocket連接的HTTP請求，建立連接后，客戶端與服務器均能主動地向對方發送消息。

圖10 WebSocket客戶端/服務端交互圖

WebSocket在本質上是基于TCP的協議，相較于基于HTTP協議的輪詢和Comet技術，數據傳輸更為穩定高效，數據傳輸量更小[9]，從而減輕了服務器負載，節省網絡帶寬資源，提高了監測平臺的實時性、穩定性和可靠性。

當前大多數瀏覽器均支持WebSocket，少部分(如IE10以下版本的瀏覽器)并沒有提供支持。對于這類瀏覽器，平臺采用SockJS作為備選方案。SockJS是對WebSocket的模擬，旨在為瀏覽器和服務器之間創建一個低延遲、全雙工、跨域通信的通道，且提供了JavaScript API，增強了瀏覽器的兼容性。在醫用氣體實時監測平臺中，對支持WebSocket的瀏覽器優先使用WebSocket，其次考慮SockJS。客戶端關鍵代碼如下:

if ("WebSocket" in window) {

websocket=new WebSocket("ws://{socketPath}/ws");

} else if ("MozWebSocket" in window) {

websocket=new MozWebSocket("ws://{socketPath}/ws");

} else {

websocket=new SockJS("http://{socketPath}/sockjs/ws");

}

//連接錯誤的回調函數

websocket.onerror=function(event) { //TODO }

//連接成功的回調函數

websocket.onopen=function() { //TODO }

//接收到服務端數據的回調處理函數

websocket.onmessage=function(event) {

//解析event.data，實現數據的更新

}

//連接關閉的回調函數

websocket.onclose=function() { //TODO }

3.4 基于REST的Web服務接口

表述性狀態轉移REST(Representational State Transfer)是Roy Fielding在其博士論文[10]中提出的一種軟件架構風格，為構建可擴展、可移植和松耦合的Web程序提供了一個架構上的準則[11-14]。REST將Web中的所有事物抽象成資源，使用統一資源標識符URI(Uniform Resource Identifier)對每個資源進行標識，通過復用HTTP協議的動詞，對資源進行操作，這種基于資源的設計改變了傳統的基于服務的設計思想。

為資源設計簡潔明了、結構良好的URI是構建REST服務的關鍵。本文平臺主要使用了POST、GET、DELETE、PUT、PATCH五類動詞，分別用于新建資源、獲取資源、刪除資源、修改資源整體、修改資源局部信息。表2為本文平臺設計的RESTful API(符合REST的接口)示例。

表2 URI應用示例

RESTful API中的URI只使用名詞，用于標識資源，用HTTP動詞標識具體的行為，可讀性高。接口的響應采用JSON對資源進行描述，實現了資源描述和視圖的解耦。REST便于設計和對外提供可被第三方調用的Open API。

3.5 其他技術

(1) 輕量級的數據交換格式 考慮到采集端數據上傳頻率高、服務端與客戶端數據通信頻繁等特點，平臺選用輕量級的JSON作為數據交換格式。相較于XML，JSON數據有效減少了數據格式中的冗余標記，體積小，傳輸速度快，帶寬占比小。JSON數據可被直接解碼為JavaScript對象，解析便捷，與Ajax完美搭配，實現客戶端瀏覽器信息數據的異步讀取和局部刷新。

(2) 基于ECharts的數據可視化 監測數據可視化是醫用氣體實時監測平臺的一大重要內容。數據可視化旨在為用戶提供直觀的圖形圖表，便于觀察數據的變化趨勢。本文平臺基于ECharts實現監測數據可視化。ECharts是一款開源的、基于JavaScript實現的數據可視化圖表庫，其底層依賴于輕量級的Canvas類庫ZRender，提供了直觀、可交互、可個性化定制的數據化圖表，瀏覽器兼容性好，在PC和移動設備上運行流暢。

4 實 現

4.1 物理結構

本文平臺采用如圖11所示的物理結構。數據采集端部署于醫院，負責數據的采集。組態軟件或其他數據匯集器整合制氣設備的運行參數和各區域氣體的使用狀態數據，通過調用相應的API將數據上傳至服務平臺。服務平臺提供了友好的RESTful API，方便設備接入和客戶端訪問。相較于C/S開發模式部署復雜、維護困難、擴展性差等弊端，平臺選用更為靈活的B/S模式，用戶借助可聯網終端(如手機、電腦、平板)通過Web即可訪問平臺，隨時隨地掌握設備的運行狀態和氣體的使用情況。

圖11 平臺物理結構圖

4.2 安裝公司管理

如圖12所示為管理員進行安裝公司管理。管理員可查看安裝公司上傳的營業憑證及其詳細信息，對其進行合法性審核。審核狀態分為“未經審核”、“審核通過”和“審核不通過”，管理員可分類查看各審核狀態下的用戶列表，默認顯示全部安裝公司。

圖12 安裝公司管理

4.3 設備管理

圖13為主機設備列表頁，不同顏色標注主機的分配情況。點擊“添加主機”，并輸入主機編號以創建主機。主機編號不能與已有主機編號相同，否則將創建失敗。

圖13 主機列表

點擊已創建的主機，進入主機詳情頁，可進行設備站(指各類氣體的生產設備)的啟用、停用，參數的配置，區域的增刪、配置以及報警短信通知的開關等。圖14為液氧源監測參數配置過程。

圖14 主機參數配置

主機各設備站和區域參數配置完成后，將主機分配給通過審核的安裝公司，圖15為主機分配過程。接下來，將主機綁定至安裝公司旗下的醫院。

圖15 主機設備分配

圖16為綁定過程，已綁定到主機的醫院不會再顯示于列表中。主機分配工作由管理員進行，主機配置與綁定工作可由管理員或安裝公司進行。

圖16 主機設備綁定

主機被綁定后，產生唯一識別碼，作為數據上傳的憑證，如圖17所示。主機配置完成，可點擊“導出參數表”按鈕以導出Excel參數配置表。

圖17 主機唯一識別碼

4.4 實時數據展示

當瀏覽器接收到服務端推送的數據，實時更新圖表數據和時間。圖18為某主機氮氣生產設備運行狀態實時展示界面，該設備同時監測了瓶組1和瓶組2壓力狀態，圖表以不同顏色標識，將鼠標放在時間點會顯示相應時刻各瓶組的壓力值。

圖18 實時數據顯示界面

4.5 歷史數據檢索與統計分析

圖19為某區域某時間段氧氣壓力歷史數據查詢結果。平臺默認以折線圖展現最近的150條數據，用戶可拖動圖表下方滾動條以展示更多數據，圖表右上角的工具按鈕可用于實現數據呈現方式的切換等。

圖19 區域氧氣歷史數據查詢結果

如圖20為數據統計結果。用戶可查看截至當前時刻，平臺共接收到的數據總量、正常數據、異常報警數據數量及其所占比例。

圖20 區域氧氣報警數據統計結果

5 測試與對比

為驗證本文平臺具有高響應率和高性能的特點，將本文的并發處理機制與傳統的同步方法進行對比，并進行了4組測試，分析在處理800、1 500、2 500、3 600 Byte左右大小JSON數據包的時間消耗情況。數據采集頻率設為1秒，每次測試連續發送200次數據，取平均值作為耗時結果，結果如圖21所示。結果表明，本文方法能明顯降低平臺的響應時間，進而可以處理更多的數據包，提高了平臺的處理性能。

圖21 耗時對比圖

從功能點角度，將本文平臺與現有同類平臺進行對比，如表3所示。

表3 功能點對比

6 結 語

本文設計和實現的醫用氣體實時監測平臺有效克服了傳統監測方式巡檢周期長、安全隱患大、工作效率低、數據利用率低等弊端，實現了數據接入、遠程實時監測、報警聯動、歷史數據檢索及統計分析等功能。并發處理機制的設計縮短了平臺服務的響應時間，提高了平臺應對并發海量數據的處理性能。緩存技術的引入降低了數據庫負載，提高了平臺的訪問效率。在數據接入方面，提出基于配置表的數據接入方案，提高了平臺的開放性、通用性和實用性。融合WebSocket和SockJS技術實現B/S的全雙工實時通信，克服了傳統Web實時技術的弊端，解決了WebSocket瀏覽器兼容性問題。平臺選用JSON作為數據交換格式，節省帶寬資源，提高了數據傳輸和解析效率。該平臺的應用可以降低醫療用氣的風險，節省維護成本，提高工作效率。目前，平臺已投入試運行階段，且運行狀況良好。