醫療審核與監管系統的大數據分析與設計

方智 電子科技大學成都學院 計算機系

1 系統需求與建模

在省、市、地區各級醫院運行的HIS 信息系統、電子病歷系統中，就診數據和檢查數據是海量的，數據的來源、結構、格式都不一致，醫療方面的大數據具有大量、高速、多樣、有價值的特點，采用大數據和分布式計算技術、數據倉庫技術相結合。系統需要從多個數據源中根據規則，提取數據，并轉換數據格式，以便進行查詢和分析，最后轉換的數據被加載到目標數據庫，組合到數據倉庫中，用于傳統存儲和分析所用。

醫療審核與智能監管系統的應用場景下，要求外掛于醫院的HIS（醫院信息管理系統），采集HIS 中的數據，進行分析運算，發現其中的違規情況。能提供給醫生事前審核和管理者事后審核，管理單位智能審核的核心功能，并能從海量數據中心分析出醫療診療趨勢，從而修正和改進現有的診療規則數據庫。

根據就診工作流所產生的一系列數據來看，醫療核心數據采集包括患者基本信息數據、醫生診斷數據、檢查項目數據、處方數據以及取藥記錄數據、項目執行情況數據等。要求智能監管系統不能干擾醫生診療行為，也不對原有信息系統進行過多的改造，便可完成對行為的監管以及對違規行為的事前提示。事前審核的處理時間不超過1秒。

傳統就診流程中，醫生在HIS 系統醫生工作站上開具檢查單或處方，系統直接對此信息進行保存。而采用智能監管流程系統后，在醫生從工作站提交檢查單或處方箋后，平臺從智能監管系統調取監管服務，對本次診療行為進行運算分析，如果發現違反監管規則，會將以消息形式，反饋違規原因及事項給現場醫生，醫生可根據提示進行本次診療內容修改，或保留原醫囑進入保存環節。完成對醫生診療記錄的事前審核。醫生可對已保存違規行為進行事后解釋和說明。同樣，護士、醫技在執行醫囑時，也會對護士及醫技的醫療行為進行監控和智能分析，對違規或有風險的操作予以提示。院方管理者和上級社保部門可查看全部的違規記錄和事后說明，醫生個人診療信用記錄，醫療行為趨勢分析，監管規則邏輯和閾值編輯。事后審核的處理時間不超過24 小時。

事前審核功能只能為單次診療行為的做出違規與否的判定。為管理者提供的違規情況智能監管，是對全部醫療數據進行分析、發現其中的違規情況。某個患者數據可能會在一次診療數據上沒有違規現象，但結合全部的多次診療數據就能發現可能存在的違規情況。因此在醫生工作站的事前審核提示環節是很難發現的。而對于管理者事后的違規情況監管來說，通過大數據分析的方法，這種問題就可以被發現。

違規數據分析則包括對醫院違規數據進行統計分析，并形成報表，從中提出數據，對醫生診療信用進行評價，也要包括對頻繁出現的共性違規數據進行預警和分析，比如飲片的過度用藥，為管理者提供決策，通過分析和論證，從而調整管理規則中的閾值。

根據醫療大數據的分析，平臺提供醫療機構一段時間以來的發展趨勢數據，比如醫療機構的每日就診人數，某種疾病在特定時期的發病高峰，治愈某種疾病的藥物用藥和用量的發展趨勢等等。

2 系統設計與技術

系統由五大子系統構成，分別是數據處理、事前違規、大數據分析審核、知識庫管理子系統。由基于云的自主開發ETL 工具完成對實時信息的提取、轉換和加載。系統采用分布式計算和數據存儲MongDB 服務器集群和Oracle 數據庫作為數據倉庫。系統提供事前提醒服務、web 應用服務、其他接口服務等。

在數據采集上由ETL 通過數據接口在醫院的信息系統數據庫中進行數據抽取，根據醫院的特定要求，設計了三種不同的采集接口方式。第一種是采用HIS 直接對ETL 工具開放查詢，這種做法不夠安全。但實現起來最簡單，效率最高。第二種是由中間庫連接醫院HIS 數據和ETL，在兩者之間建立一個用于數據交互的中間庫，HIS系統按照約定將數據寫入中間庫，ETL 工具讀取中間庫來進行抽取數據。這種方式相對安全，但降低效率，增加多次IO 讀寫。第三種是導出數據包方式來連接醫院信息系統數據庫和ETL。將HIS 系統數據按約定導出成數據文件，再導入中間庫，ETL 再進行提取。這種做法安全但效率有損。

數據運算任務經過拆分后，交給規則引擎來進行運算處理。規則引擎類設計了引擎編號、狀態為屬性，并編寫啟動服務()、啟動服務()、載入規則()、啟動運算()等方法。將監管規則直接讀入內存來提高服務性能。調度類設計了運行狀態屬性，并編寫采集數據()、保存數據()、接收數據()、分配任務 ()、保存任務結果()等方法。

大數據分析的結果信息類主要包括規則類、違規信息類、單據信息類、單據明細類、患者信息類。知識庫管理主要設計對基于中華藥典、國家中醫藥管理局數據等頒布的基礎數據庫、醫用材料數據庫、疾病診斷數據庫、醫療檢查服務項目數據庫、臨床知識庫等的導入、編輯、更新、梳理等。其中臨床知識庫是本系統的核心數據庫部分，根據臨床知識庫來對診療數據基于規則作出判斷，篩選偏離常規診療的項目，發現過度和缺失醫療行為。

在規則引擎分析之前，有規則編輯器來完成業務流的編輯，從而生成Fenix 和監管規則。例如在載入待審核數據后，順序做出是否兒童，是否新生兒，是否疾病與年齡吻合，是否治療方案與年齡吻合，是否藥物耗材與患者年齡吻合并做出對應的違規信息提示。

3 具體實現與問題

本系統采用分布式并行計算的方式進行任務分配和執行計算。可以在多臺服務器上部署規則引擎服務，也可以在一臺上部署多個引擎[2]服務，并采用多端口標識服務進程。在部署過程中，設計配置文件方式，當數據源更換時，僅需改變數據配置文件即可。配置文件以通用的XML 方式和Json 格式存儲，便于數據交互。審核結果數據的接口實現上，可以支持查詢某一條診療單據數據是否違反規則，支持查詢某條問題單據和違反規則的相關沖突記錄、支持某條問題明細和違反規則的相關沖突記錄，支持查詢某條問題明細違反所涉及的臨床知識信息。數據庫方面在審核結果表上包括單據ID、明細ID、規則編碼、審核時間、規則提示信息、記錄、組編碼、臨床信息提示、疾病臨床提示、原文提示編碼等字段。

4 系統測試

系統測試包括功能和性能測試。本系統測試主要是利用黑盒測試方法來進行系統測試，測試保證覆蓋全部在需求文檔中的全部功能點，并采用selenium 和python 技術方案進行自動化測試核心業務功能。系統性能測試則主要依賴自動化工具進行場景模擬和并發、壓力、負載、安全性方面的測試。測試結果符合預期。