基于API 的疾病預測系統數據導入研究

邵榮強，陳 燕，龔慶悅

（1.南京中醫藥大學人工智能與信息技術學院，江蘇南京 210023；2.宜興市第二人民醫院信息科，江蘇宜興 214221）

0 引言

自現代醫學誕生以來，由于醫學的發展極大地延長了人類的平均壽命，其研究一直吸引著大家的廣泛關注，研究者希望通過研究揭示人體的運行規律，對其發病趨勢進行預測。但是人體是一個十分復雜的系統，生理、心理和社會因素綜合交織在一起使對疾病的預測研究變得非常困難。

機器學習可以通過從歷史的行為和數據中分析、學習并找到更好的設計模式，可以解放很多復雜的工作。因此，機器學習已被廣泛運用于各生產和科研領域［1-2］。隨著大數據時代的到來，醫學領域中的海量數據引起了許多學者的關注。機器學習方法，如：神經網絡、支持向量機、決策樹等方法被廣泛應用于疾病預測領域［3-6］，它們處理復雜及其大量數據上表現出的優勢，解決了許多傳統方法的局限性［7-10］。隨著新的算法不斷出現及各類超參數、業務參數的不斷改進，疾病預測模型的準確率和召回率等指標也越來越高［11-13］。因此，相應的疾病預測模型也需要重新訓練，模型重建周期也變得越來越短，需要通過提高訓練效率以適應模型重建的快節奏。

1 相關工作

為提高疾病預測模型重建效率，近年來一些學者［14-18］針對算法和超參數選擇進行研究，但隨著研究的深入，訓練效率改進越來越逼近天花板；也有學者［19-20］通過研究機器學習的云服務提高訓練效率，但醫學數據傳到外部服務器則不可避免地面臨患者隱私泄露問題；還有學者［21］通過海杜普分布式文件系統（Hadoop Distributed File System HDFS）等提升硬件性能的方式提高機器學習效率，但這種方式受到了投入上的限制。

以上方法均未針對數據導入這一環節進行效率提升研究，而數據導入在模型訓練過程中不僅是不可避免的流程，而且過程復雜而繁瑣，極容易出錯。許多研究人員［22-24］采用手工方式導入數據，首先從數據庫查詢原始醫療數據，再通過數據庫管理軟件將數據導出為csv 和txt 文件，然后將文件拷貝或通過網絡傳輸到機器學習的服務器。本文采用了程序接口（Application Programming Inter?face，API）方式導入數據，優勢如下：

（1）API 方式導入數據不受記錄數的限制，效率更高。隨著醫療信息化的發展，醫療數據也越來越大，通過txt 或csv 文件導入醫療數據讓每次操作的數據量受到限制，當數據的記錄數超過1 048 576 時，這兩種文件類型都無法支持。如果數據集通過人工多次以文件為載體導入，則進一步降低了導出效率。API 方式導入數據不受記錄數限制，當收到數據請求，API 服務器可以根據數據量的大小自動分批封裝和傳送，整個過程無需人工介入，效率更高。

（2）API 導入方式采用輕量級的JSON 格式，出錯概率更低。數據集通過文件導入時，受到不同字符編碼方式、數據類型等環境因素的影響，導入過程時有失敗，同時操作人員對數據集采用人工方式進行文件的復制與傳輸也進一步加大了數據出錯概率。API 導入方式采用輕量級的JSON 格式，JSON 使用完全獨立于編程語言的文本格式存儲和表示數據，導入時出錯概率更低。

（3）API 導入方式降低了審計復雜性。直接通過數據庫查詢輸出為txt 或csv 文件，雖然可以通過數據庫日志對操作的動作和導出數據的范圍進行審計，但操作過程復雜。API 導入方式可以自動在其服務器中保存調用信息，如：調用數據的人員、時間和所調用數據的范圍等，結構化的調用信息更有利于調用的審計。

本研究的創新之處：使用API 的方式導入數據，而不是傳統的txt 或csv 等文件導入方式，以提高數據導入效率，突破文件格式對數據量的限制，避免因字符編碼方式或數據類型等因素引起的意外錯誤，降低審計復雜性并提高數據安全性。

2 API 數據導入設計

為提高數據獲取效率，本研究的臨床數據集不再以文件為載體進行導入導出，而是以API 接口的方式進行數據傳輸。試點醫院的臨床信息系統（Clinical Information Sys?tem，CIS）是通過C#開發的，而疾病預測服務器所用的語言是Python，因此它們之間的數據交互需要跨編程語言。而目前最常用的跨編程語言的遠程調用技術是WebSer?vice［25］。根據應用場景不同又可分為安全性要求較高的簡單對象訪問協議（Simple Object Access Protocol，SOAP）服務［26］和輕量級、易訪問、可擴展性為特征的表述性狀態轉移（Representational State Transfer，RESTful）服務［27］。

本文研究中對數據庫的訪問需要有權限控制及審計，因此數據庫前置機則采用了SOAP WebService 架構。SOAP 是交換數據的一種協議規范，是一種基于可擴展標記語言（Extensible Markup Language，XML）的協議，它用于在Web 上交換固化和結構化信息［28］。從網絡和安全角度看，它有著隔離數據庫服務器的作用，同時可以在前置機上記錄詳細的訪問日志并用于審計。

布置在隔離區（Demilitarized Zone，DMZ）的微服務RESTful 服務器用于對外發布細顆粒度JSON 數據，需要達到輕便、簡單的效果，故此服務器采用了基于RESTful WebService 的微服務架構。RESTful 是一種網絡應用程序的設計風格和開發方式，可以使用XML 格式定義或JSON格式定義。RESTful 適用于業務數據交互接口的場景，實現第三方調用移動網絡資源的功能，動作類型為新增、變更、刪除所調用資源。如圖1 所示，由客戶端向疾病預測服務器發起疾病預測模型請求，數據申請路徑是：疾病預測服務器、RESTful API 服務器、SOAP API 前置機、訓練/預測Data 集，數據返回路徑則是從訓練/預測Data、SOAP API前置機、RESTful API 服務器、疾病預測服務器，后者完成訓練后保存疾病預測模型。

Fig.1 Disease prediction data flow Diagram圖1 疾病預測數據流圖

3 系統開發與實現

根據API 數據導入設計，疾病預測系統的API 數據導入涉及SOAP API 服務和RESTful API 服務實現。

3.1 SOAP API 服務實現

醫療數據涉及患者隱私，從安全角度而言，第三方應用不能直接對數據庫進行操作，而且調用數據的條件受到嚴格限制，同時調用的動作需要記錄在日志中，以備將來審計。因此，數據庫前置機采用了SOAP WebService 架構。

通過SOAP 這個嚴格定義的信息交換協議，在Web Service 中將遠程調用與返回封裝成機器可讀的格式化數據［29］。SOAP 數據使用XML 數據格式并定義了一整套適合醫學的標簽，以描述調用的出錯信息、返回值、參數和遠程過程等［30］，所有數據均需按照發布的參數要求進行調用，從而保障醫療數據調用的權限與數據范圍。考慮到數據安全性需求增長，本研究增加了對Web 服務描述語言（Web Service Description Language，WSDL）的支持。WSDL也遵循XML 格式，用來描述哪個服務器提供什么服務，如何找到它，以及該服務使用怎樣的接口規范［31］。因此，使用Web Service 的過程可轉換成獲得該服務的WSDL 描述，根據WSDL 構造一條格式化的SOAP 請求并發送給服務器，然后接收一條同樣SOAP 格式的應答，最后根據先前的WSDL 解碼數據。請求和應答使用HTTP 或HTTPS 協議傳輸，發送請求使用POST 方法［32］。

SOAP WebService 的整個實現流程如圖2 所示。①RESTful API 服務器需要調用一個數據服務，以通用描述發現和集成注冊服務器（Universal Description Discovery and Integration Registry，UDDI Registry）詢問哪個服務器可以提供該服務；②UDDI Registry 返回了一個消息，提示SOAP API 服務器能提供這樣的數據服務；③RESTful API服務器訪問SOAP API 服務器，詢問確切的調用方法；④SOAP API 服務器得到RESTful API 服務器提出的請求后，將一個WSDL 描述的XML 文檔返回給RESTful API 服務器，在文檔中記錄其能提供的各類方法接口；⑤RESTful API 服務器了解到這些后，將這些XML 的接口方法封裝成為HTTP 請求，發給SOAP API 服務器，這些封裝方式采用標準的SOAP 方式，實質是滿足HTTP/HTTPS 協議的一些SOAP 的報文消息［33］；⑥SOAP API 服務器回應的也是HTTP/HTTPS 協議的SOAP 包，這樣雙方的請求—響應完全暢通。

Fig.2 SOAP WebService圖2 SOAP WebService

3.2 RESTful API 服務實現

考慮到疾病預測系統將來可能推廣到各病種預測，為保障RESTful API 是一個通用的、可重用的架構模式，本文RESTful API 研究遵循模型—視圖—控制器模式（Model View Controller，MVC），如圖3 所示。它是用一種業務數據、邏輯、界面顯示分離的方法組織代碼，將疾病預測業務邏輯封裝到一個部件里，在改進和個性化定制界面及用戶交互的同時，業務邏輯不需要重新編寫［34］。它將軟件系統分為3 個基本部分［34］：

（1）模型（Model）。負責存儲醫院信息系統的醫療數據、封裝應用程序狀態和應用程序功能、響應狀態查詢和通知視圖改變。

（2）視圖（View）。將醫療信息輸出給用戶，用于模型解釋、模型請求更新、給控制器發送用戶輸入，以及允許控制器選擇視圖。在研究中輸出為JSON 格式的數據，經解析和格式化后可以視圖形式呈現。

（3）控制器（Controller）。處理用戶輸入信息，負責定義應用程序行為、用戶動作映射或模型更新和選擇響應的視圖。從url 讀取相關參數，控制用戶輸入，并向模型發送數據，是RESTful API 中處理用戶交互的部分。

Fig.3 MVC architecture of RESTful API圖3 RESTful API 的MVC 體系結構

MVC 在具體開發時的應用如下：

（1）本研究項目對應一個application 文件夾，RESTful API 對應application 下的一個api 目錄，其包含MVC 架構，API 有多個controller 和model，controller 保存疾病預測業務的邏輯，將疾病預測數據保存在model 中。

（2）為做好版本控制，在controller 中建v1 目錄，用于控制疾病預測系統的各版本，在v1 下創建UserPermission.php 控制器，負責管理與用戶交互控制。

（3）在model 下創建DataService.php，與醫療數據增刪改查相關操作均通過model 完成。

（4）控制層和model 層建好后，就可以建立路由規則。在目錄route 下進行配置，配置的url 及相關參數即是客戶端調用數據的規范。

疾病預測服務器在調用醫療數據時，通過url 進行訪問，route 解析配置中的參數，產生input events 事件，通過View 調用相應controller 中的方法，后者使用對應model 中的統一數據調用函數訪問SOAP 的服務，獲取數據后將XML 格式轉換成JSON 格式并返回給url 調用方。

4 系統測試與結果分析

本文通過多個不同記錄數的數據集測試API 接口從數據庫向疾病預測服務器導入數據的速度。SOAP API 服務器和RESTful API 服務器的硬件配置均為16 核的雙處理器和16G 內存的虛擬機。測試用的數據集均是16 個字段，一個循環共做100 個數據集導入測試。第一個數據集有1 000 條記錄，第二個數據集有2 000 條記錄，以1 000條遞增，循環100 次，最后一次導入數據集為100 000 條記錄。根據數據集的記錄數與耗時畫成散點圖，如圖4 所示，耗時從1.214 0s 到40.431 5s 不等。在導出并導入第42 個數據集時，服務器自動啟動CPU 四核運行，CPU 會將處理任務分成4 份分別交給4 個核心處理，處理速度也大幅提高；在導出并導入第62 個數據集時，服務器自動啟動CPU 十六核運行，處理速度是最初的近16 倍；為保證實驗的可重復性，循環測試實驗共做了10 次，繪制的圖形大體一致。可以看出，通過API 導入醫療數據，在10 萬條數據以內，隨著數據量的增大，所耗時間并不是線性增長，系統會根據任務量自動分配硬件資源以保障導入速率。取每次循環中最后一個數據集（100 000 條記錄的數據集）的導入時間，10 次平均耗時6.705s。對比文件導入方式，數據庫僅將100 000 條記錄的數據集導出到csv 文件，10 次測試平均用時358.213s。經計算，前者速度是后者的53 倍以上。10 次實驗通過API 接口共導入1 000 個數據集，無一出錯，也體現了API 導入數據的穩定性。通過API 調用1 000 個數據集的動作與調用數據的范圍均可自動記錄于數據庫中。

Fig.4 Time consuming scatter diagram of API importing dataset圖4 API 導入數據集耗時散點圖

5 結語

隨著信息技術在醫療領域的廣泛應用，醫療數據的質與量將不斷提升，疾病預測模型也需要用更多、更新、質量更高的數據進行不斷優化。為簡化醫療數據導入步驟并提高導入效率，本文使用API 的方式導入數據，而不是傳統的txt 或csv 等文件導入方式。研究結果表明，基于SOAP 和RESTful API 微服務的數據導入方式，提高了數據導入速度，避免了因字符編碼方式引起的意外錯誤，降低了審計的復雜度，并提高了數據安全性。

同時，本文還存在一些不足：整個研究尚未經過上百萬條數據的考驗，隨著數據量的進一步增大，通過API 接口方式導入數據的優勢是進一步擴大還是減小，有待驗證；隨著應用的推廣，業務的多并發也是一項新的挑戰。本研究實施周期偏短，希望通過系統的持續性改進，以促進機器學習在疾病預測中發揮更大作用。