基于Web 的醫學圖像處理系統的設計

許自強，王麗嘉

（上海理工大學健康科學與工程學院，上海 200093）

醫學成像技術已經成為越來越重要的診斷手段。隨著數據量的爆炸式增長，人們對醫學圖像處理技術有了更高的要求。以醫學圖像分割為例，它是計算機輔助診斷的關鍵步驟，也是整個處理任務耗時較多的一步，現有的分割模型精度并不能滿足所有的應用場景[1]。如何讓這些不夠精確但能夠起到一定輔助作用的模型盡快投入使用呢？在醫學圖像領域，已經出現了一些符合醫學數字成像和傳輸協議（Digital Imaging and Communications in Medicine，DICOM）標準的優秀開源軟件，如Sébastien Jodogne等開發的圖像歸檔與傳輸系統[2-3]（Picture Archiving and Communication System，PACS）Orthanc[4]，Open Health Imaging Foundation（OHIF）開發的OHIF Viewer[5]等，這些都為解決該問題提供了技術支持。文中提出一種對非全自動化流程可特別支持的，基于Web 的醫學圖像處理系統。

1 總體設計

1.1 功能設計

醫學圖像處理系統的主要數據對象是DICOM文件，系統除了提供圖像歸檔、圖像查看、數據在線訪問這些基礎功能之外，還應提供一種表示圖像處理任務的方法，以便在各子系統之間傳遞處理任務的信息。考慮到一個完整的圖像處理任務可能涉及到人工介入，例如對圖像分割質量進行人工確認和對手術方案進行規劃，系統還需要提供相應的應用編程接口（Application Programming Interface，API）。通常開發這樣的系統至少需要配備軟件工程師和算法工程師這兩類崗位的人員，軟件工程師擅長軟件開發，熟悉整個系統的運行機制，能夠快速定位系統故障；算法工程師專注于圖像處理模塊，通常對該模塊以外的部分不如軟件工程師熟悉。為了設計出易于開發、擴展和維護的系統，需要充分考慮各崗位人員的技術特點。基于上述分析，該系統的功能結構圖如圖1 所示。

圖1 系統功能結構圖

各模塊具體功能如下：

1）基礎功能模塊，該模塊提供用戶登錄驗證、用戶基本信息管理、用戶角色管理和數據分組管理等基礎功能。

2）圖像歸檔模塊，該模塊提供DICOM 文件的存儲、檢索和在線訪問功能，為了易與Web 系統和一些現成的工具包集成，該模塊需要支持DICOM 標準定義的DICOM Standard for Web-based medical imaging（DICOMWeb）[6-7]接口。

3）圖像處理模塊，該模塊提供醫學圖像處理功能，由于算法的實現往往依賴復雜的軟件環境，且不同算法可能依賴不同版本的軟件，大部分軟件不支持同時安裝多個版本，所以該模塊需要支持不同類別的算法使用獨立的運行環境。

4）人機交互模塊，該模塊提供易于用戶使用的可視化操作界面，方便用戶進行如用戶登錄、圖像查看、圖像分割和處理任務提交等操作。

5）任務管理模塊：一個處理任務至少包含一個步驟，文中也將處理任務的步驟稱為“計算作業”。該模塊用于創建、查詢和控制用戶提交的處理任務和維護計算作業的執行情況。

6）作業調度模塊：該模塊用于異步和同步執行計算作業；支持按照各個節點的負載情況和作業優先級分配作業；支持啟動、查詢、中斷和結束計算作業的運行；支持對計算節點的管理。考慮到高并發情況，還應支持對計算節點進行橫向擴展。

7）文件管理模塊：該模塊提供文件的在線存取和管理的功能，通常醫學圖像處理的結果以文件的形式進行表示，對外暴露的結果文件使用該模塊進行管理。

1.2 對人工介入操作的特別說明

在實際的醫學圖像處理任務中，總是會涉及到人工介入的操作。文中以肝臟手術規劃中的圖像分割任務為例，肝臟手術規劃需要精確分割大部分腹部臟器和肝內管道系統。特別地對于肝內管道系統這類小目標來說，目前開發的全自動分割模型精度常常無法滿足實際要求。但是這些分割任務完全依靠人工操作，又非常繁瑣和耗時。在這樣的背景下，文中將這樣的圖像分割任務分解為“自動分割”和“手動分割”兩部分，“自動分割”表示使用計算機程序對圖像進行初步分割，“手動分割”表示人工對自動分割的結果進行二次確認，如果分割結果有錯誤或者缺少，則人工手動對其進行修正，分割流程如圖2 所示。對于任何需要人工介入的操作，都可以使用類似的流程。

圖2 有人工介入的圖像分割流程

1.3 架構設計

根據功能設計的邏輯結構，將系統劃分為前端App、API 網關、Web 后端、PACS、算法后端和調度中心共計六個子系統，系統架構圖如圖3 所示。

圖3 系統架構圖

對各子系統的說明如下：

1）前端App：實現系統的人機交互模塊，是基于該系統對外開放的API 開發的一組應用。

2）API 網關：是前端和后端通信的橋梁，用于統一管理對外暴露的API。

3）Web 后端：實現系統的基礎功能模塊、任務管理模塊和文件管理模塊。

4）PACS：實現系統的圖像歸檔模塊。

5）算法后端：實現系統的圖像處理模塊。

6）調度中心：實現系統的作業調度模塊。

2 子系統的實現

2.1 前端App

這里的前端是廣義上的前端，它們通過使用超文本傳輸協議(Hyper Text Transfer Protocol，HTTP)的API 經過網關與后端通信，既包含了基于瀏覽器開發的Web App，又包含了原生App和命令行App。該系統目前設計開發兩個Web App 和一個命令行App，為了保持界面邏輯的清晰，用兩個Web App 分別承擔DICOM 圖像相關交互和一些其他的圖形化交互，它們的代號分別為DICOM Viewer和DICOM Explorer。其中DICOM Viewer 使用TypeScript 語言基于OHIF Viewer 開發，是專門用于處理DICOM 文件的應用，支持DICOMWeb 接口，用于實現DICOM 圖像的查看和手動分割功能；DICOM Explorer 使用TypeScript 語言基于Vue3 和Element-Plus[8]開發，實現用戶管理、數據集管理、DICOM 文件上傳、處理任務提交和數據預覽等常規的交互操作。命令行App 的代號為DICOM Uploader，使 用Python 語言開 發，用于解 決DICOM Explorer 上傳大批量數據時容易出現的性能問題和實現一些在Web 瀏覽器中難以實現的功能。

2.2 API 網關

該系統后端有多個子系統，互相通信均使用HTTP 協議，系統將會定義大量HTTP API，一部分API 如作業調度接口，出于安全和性能方面的考慮，應僅供后端內部使用，不對外部開放。除此之外系統還需要路由配置、登錄狀態檢查等功能，該系統使用API 網關來實現。常用的方案有使用NGINX、OpenResty、Kong 和Apache APISIX[9]作為網關，通過性能、易用性、插件支持情況和功能等方面的比較，最終選用APISIX。APISIX 是云原生架構的開源API網關，相較于傳統的API 網關，它提供了動態路由、插件熱加載等諸多能力，可以為海量API 和微服務提供安全可靠的動態、高性能、可擴展的管理平臺。

2.3 Web后端

該子系統基于Kotlin[11]語言和Spring Boot框架[11-12]開發，實現基礎功能模塊、任務管理模塊和文件管理模塊這三個模塊功能。基礎功能模塊實現了用戶管理和認證功能，并引入數據集概念，將DICOM 圖像分配到不同的數據集下，即實現了數據分組管理的功能。文件管理模塊實現為所有管理的文件夾和文件分配唯一id的功能，并提供增刪改查操作的API。

2.3.1 處理任務類型的表示

系統要能夠集成多種類型的處理任務，需要對處理任務的類型進行表示，因此設計了名為PipelineDescriptor 的數據結構，其具體結構如圖4 所示。該數據結構的屬性及其說明如表1 所示，序號為1-7、8-13、14-17 的分別 是PipelineDescriptor、StageDescriptor、ParameterDescriptor 結構的說明。

表1 PipelineDescriptor屬性

圖4 表示處理任務類型的數據結構

該系統集成“肝內血管分割”和“肺結節良惡性分析”這兩種類型的處理任務作為示例。現給出“肺結節良惡性分析”類型的JSON 格式表示，如下所示：

除了高精度圖像分割之外，目前進行如手術規劃之類的復雜操作也難以實現完全自動化，均可以通過類似的方式來定義流程。

2.3.2 計算作業所需圖像序列的指定

醫學圖像的采集通常是多模態的，即每個檢查（Study）下會采集多個序列（Series）的圖像，以“肝內血管分割”類型的處理任務為例，需要對肝靜脈、門靜脈和肝動脈進行精確的分割，肝靜脈通常在靜脈期或者延遲期有清晰成像，肝動脈通常在動脈期有清晰成像，所以要完成各類血管的分割，需要在多個序列圖像上分別運行相應的分割模型。DICOM標準沒有規定如何表示此類期相信息，各影像機構通常利用DICOM 文件的SeriesDescription 標簽來記錄，由于各機構都使用自己約定的表述方式或者在掃描時由技師隨意指定，這種寬松的做法導致在開發圖像序列選擇程序時可能出現找不到所需序列圖像的情況。所以在表示計算作業類型的數據結構StageDescriptor 中，設計了parameters 屬性，用于表示該類計算作業需要的參數，用戶可以通過這個參數來手動指定所需圖像序列。

2.3.3 處理任務與計算作業的存儲

在數據庫中創建一張名為task 的數據表，用于存儲處理任務和計算作業的執行狀況，數據表的關鍵字段及其說明如表2 所示。

表2 task數據表的關鍵字段及說明

該子系統為所有處理任務及其計算作業都創建一條數據庫記錄，且非自動計算作業的狀態變化必須通過顯式調用API 來進行，以此表示用戶手動結束非自動計算作業。

2.4 PACS

PACS 子系統直接選用現成軟件，為了便于后期對該子系統進行替換，PACS 子系統與其他子系統通過DICOMWeb接口通信。經比較，開源版本的Orthanc是一個合適的選擇，使用PostgreSQL 替換Orthanc 默認的數據庫，Orthanc 的性能達到較優的狀態[4]。

為了和其他軟硬件保持兼容性，該系統充分利用DICOM 標 準，使用Modality 為SEG 的DICOM 文件存儲分割結果。并做如下約定，為每種分割類型指定一個id，每個分割實例使用一個DICOM 序列存儲，且該序列下僅包含一個實例文件（Instance），并用SeriesDescription 標簽記錄分割類型id，使用ContentCreateDate 標簽和ContentCreateTime 標簽記錄該分割結果的創建時間。將這個文件導入Orthanc 后，可通過DICOMWeb 接口查詢使用。為了以示區分，模型預測的分割類型id 以model_為前綴，目前規定的分割類型id 及其說明如表3 所示。

2.5 算法后端

算法后端子系統專注于數據處理工作，且圖像處理程序多用Python 和C/C++開發。由于Python 相對于C/C++，可以很容易地集成其他編程語言的代碼，也有成熟易用的異步框架，所以算法后端選擇了Python 語言和Celery 框架[13-14]作為主要技術，并以RabbitMQ 作為broker 和backend。算法后端集成的處理作業均以函數的形式對外開放，一個函數即實現一個計算作業。根據不同依賴環境的計算作業必須在不同的組別、同一任務的計算作業必須在同一組別的原則對其分組。如將“肝內血管分割”的兩個計算作業編入liver-worker 組，將“肺結節的良惡性分析”的計算作業編入lung-worker 組。上述的liver-worker 和lung-worker 將作 為Celery 框架的兩類worker 實例運行，按照配置的優先級，在獨立的軟件環境中對計算作業進行處理。

2.6 調度中心

使用Celery 的Flower[15]插件對Celery 進行擴展，Flower 是一個基于Web 的監控和管理Celery 集群的開源工具，適合作為該系統的調度中心。Flower 支持HTTP 協議的API，可以方便地與Web 后端子系統進行集成。

3 測試與API文檔管理

該系統通過HTTP API 與外界通信，應當進行全面的測試以保證功能的完整性和系統的安全性，并為每個對外開放的API 編寫易理解的文檔，該系統選用Apifox 作為API 文檔管理工具和API 測試工具。

4 持續集成與部署方案

該系統所有的代碼均使用Git 進行版本管理，為了加快開發效率和方便測試，使用Jenkins 進行持續集成，每當有代碼提交Jenkins 將自動將其構建為Docker 鏡像[16]。由于各組件均構建為Docker 鏡像，該系統既可以使用Docker Compose 部署到單機，又可使用Kubernetes 部署到計算機集群，部署工作非常方便。

5 結束語

系統通過將處理任務分解為計算作業的方式，對各種自動化程度的圖像處理任務都進行了支持，這可以加速科研成果到產業的轉化，具備高度的靈活性和通用性。在實際應用中發現，系統仍有不足之處，即使對Orthanc 的配置進行了優化，部分DICOMWeb 接口還是存在性能問題，這個問題可以嘗試使用多個Orthanc 實例負載均衡，或者使用高性能的商用PACS 軟件來改善。