放療計劃系統及其任務執行方法與流程

本發明主要涉及醫療設備，尤其涉及一種放療計劃系統及其任務執行方法。

背景技術：

放射治療是利用現代高科技計算機控制先進的射線發生設備——醫用電子直線加速器，通過控制放射線的入射方向、放射區域對腫瘤進行不開刀、無痛苦、損傷小、體質消耗小的有效腫瘤治療方案。在進行放射治療之前，需在放療計劃系統(tps)上設計各個病人的放射治療計劃，在展示腫瘤接受放射致死照射劑量的同時，控制周圍重要組織和重要器官的受射線輻射劑量在正常組織和器官的耐受范圍以內。

放射治療計劃中，醫生需要給出處方和治療方案，物理師要根據醫生處方，勾畫器官和腫瘤位置，以及總的腫瘤體積(grosstumorvolume，gtv)、計劃治療體積(planningtargetvolume，ptv)和臨床目標體積(clinicaltargetvolume，ctv)等靶區；然后根據治療方案，創建射野(beam)和子野(beamsegment)，檢查劑量體積分布(dose-volumehistogram，dvh)，如果不滿足處方目標，進行優化計算直到滿足要求為止；然后批準計劃(approve)，保存整個計劃數據，用以治療。

現有的放療計劃系統(tps)的架構主要以單機系統和c/s(單一客戶端/單一服務器)架構為主，在硬件資源有限的情況下，系統性能受到以下幾個方面的挑戰。首先，當需要分割的器官眾多時，處理時間很長。其次，用于放療記錄計算的方法的計算量隨著精度提高而提高。再者，在放療云平臺上，放療計劃系統整體占用系統資源過多，影響放療云平臺整體運營的效率。

技術實現要素：

本發明要解決的技術問題是提供放療計劃系統及其任務執行方法，以便提高放療計劃系統的性能，提升放療云平臺整體運行的效率。

為解決上述技術問題，本發明提供了一種放療計劃的任務執行方法，由放療計劃系統執行，所述方法包括如下步驟：創建一個或多個容器；將各容器放置到容器池中；響應服務請求，分配所述容器中的一個或多個來執行所請求的服務，其中容器各容器用于執行各自的服務；匯總所述容器的結果，返回給所述服務的請求方。

可選地，上述方法還包括根據所請求的服務的數量，動態地補充所述容器池中的容器數量。

可選地，在匯總所述容器的結果，返回給所述服務的請求方后還包括回收容器到所述容器池中以及/或者銷毀容器。

可選地，上述方法是在所述放療計劃系統的容器管理器中執行，每個容器管理器與一個或多個應用模塊關聯，且具有獨立創建和管理與所述應用模塊任務有關的容器的權限。

可選地，每個應用模塊適于被獨立地啟動和關閉。

可選地，所述應用模塊為勾畫模塊、計劃模塊、評估模塊和驗證模塊中的一個。

可選地，與所述勾畫模塊有關的容器包括自動分割容器和感興趣區域容器。

可選地，與所述計劃模塊有關的容器包括計劃容器、劑量計算容器和優化容器。

可選地，與所述評估模塊有關的容器包括劑量計算容器和比較容器。

可選地，與所述驗證模塊有關的容器包括計劃容器和驗證容器。

本發明還提出一種放療計劃系統，包括：一個或多個應用模塊，接收服務請求；容器池，用于容納一個或多個容器；以及容器管理器，適于執行下述操作：創建一個或多個容器；將各容器放置到容器池中；響應服務請求，分配所述容器中的一個或多個來執行所請求的服務；匯總所述容器的結果，返回給所述應用模塊，其中各容器用于執行各自的服務容器。

可選地，所述容器管理器還根據所請求的服務的數量，動態地補充所述容器池中的容器數量。

可選地，所述容器管理器在匯總所述容器的結果，返回給所述服務的請求方后還包括回收容器到所述容器池中以及/或者銷毀容器。

可選地，每個容器管理器與一個或多個應用模塊關聯，且具有獨立創建和管理與所述應用模塊任務有關的容器的權限。每個應用模塊適于被獨立地啟動和關閉。

可選地，每個應用模塊適于被獨立地啟動和關閉。

可選地，所述模塊為勾畫模塊、計劃模塊、評估模塊和驗證模塊中的一個。

可選地，與所述勾畫模塊有關的容器包括自動分割容器和感興趣區域容器。

可選地，與所述計劃模塊有關的容器包括計劃容器、劑量計算容器和優化容器。

可選地，與所述評估模塊有關的容器包括劑量計算容器和比較容器。

可選地，與所述驗證模塊有關的容器包括計劃容器和驗證容器。

本發明還提出一種放療計劃系統，包括存儲器、處理器及存儲在存儲器上并可在處理器上運行的計算機程序，所述處理器執行所述程序時實現如上所述的方法的步驟。

本發明還提出一種計算機可讀存儲介質，其上存儲有計算機程序，所述程序包括實現如上所述方法的代碼。

與現有技術相比，本申請由于容器的特性，各個容器可以并行地執行各項服務。這樣，對于一項任務來說，需要處理的時間為所有服務中處理時間最長的一個時間，而非該項任務執行時間的總和，因此本申請的方式大幅度提高了響應速度。

附圖說明

圖1是根據本發明一實施例的放療計劃系統的概略架構圖。

圖2是根據本發明一實施例的基于容器的任務執行方法流程圖。

圖3是根據本發明一實施例的器官自動分割部分的架構圖。

圖4是根據本發明一實施例的器官自動分割任務執行方法流程圖。

圖5是根據本發明一實施例的計劃部分的架構圖。

圖6是根據本發明一實施例的劑量計算任務執行方法流程圖。

圖7是根據本發明一實施例的創建射束過程中即時計算劑量的方法流程圖。

圖8根據本發明一實施例的放療計劃系統的完整架構圖。

具體實施方式

為了更清楚地說明本申請的實施例的技術方案，下面將對實施例描述中所需要使用的附圖作簡單的介紹。顯而易見地，下面描述中的附圖僅僅是本申請的一些示例或實施例，對于本領域的普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖將本申請應用于其他類似情景。除非從語言環境中顯而易見或另做說明，圖中相同標號代表相同結構或操作。

如本申請和權利要求書中所示，除非上下文明確提示例外情形，“一”、“一個”、“一種”和/或“該”等詞并非特指單數，也可包括復數。一般說來，術語“包括”與“包含”僅提示包括已明確標識的步驟和元素，而這些步驟和元素不構成一個排它性的羅列，方法或者設備也可能包含其他的步驟或元素。

雖然本申請對根據本申請的實施例的系統中的某些模塊做出了各種引用，然而，任何數量的不同模塊可以被使用并運行在處理器上。所述模塊僅是說明性的，并且所述系統和方法的不同方面可以使用不同模塊。

本申請中使用了流程圖用來說明根據本申請的實施例的系統所執行的操作。應當理解的是，前面或下面操作不一定按照順序來精確地執行。相反，可以按照倒序或同時處理各種步驟。同時，或將其他操作添加到這些過程中，或從這些過程移除某一步或數步操作。

在放療計劃系統中，影響性能的工作例如有：器官的自動分割、放療計劃的劑量計算以及放療計劃的優化。在優化過程中，需要多次進行劑量計算。器官的自動分割和/或劑量計算是影響放療計劃系統性能的主要方面。

目前放療劑量計算的方法主要包括但不限于：筆形束(pencilbeam)、卷積(coneconvolution)和蒙特卡羅(montecarlo)。以上所列方法，計算的精度依次提高，計算的復雜度和時間耗費也是依次提高。特別是蒙特卡羅算法計算量巨大，對于一個全弧(360度)的射野(beam)通常需要幾十分鐘。

此外，放療計劃系統包括的功能眾多，但是用戶每一次使用只用到其中部分功能，在多用戶的云平臺上，造成放療計劃系統占用系統資源過多和運行效率不高的問題。

本申請的實施例描述放療計劃系統(tps)及其任務的執行方法，能夠大幅度提高放療計劃系統的性能，能夠提升放療云平臺整體運行的效率。

本申請的實施例中，基于容器技術來執行放療計劃系統中的任務，尤其是器官自動分割和劑量計算任務。容器(container)是一種從一個計算環境移到另一個計算環境能夠方便獲取軟件可靠的運行時的解決方案。計算環境轉移包括從開發者的筆記本環境到測試環境，從暫存的環境到生產環境，以及從數據中心的物理環境到私有或者公有云中虛擬機器的環境。容器技術的好處是：提供一致的運行環境，提高運行效率，提升開發者的生產力和方便的版本控制。在本申請的上下文中，容器技術不限于docker，apachemesos，amazonawsecs和microsoftazureservicefabric等。提供服務(service)的容器有時被稱為服務容器(servicecontainer)，它是單獨可完成某種服務的單元。對請求服務的一方來說，其使用的是服務提供者(serviceprovider)提供的容器服務(containerservice)。

圖1是根據本發明一實施例的放療計劃系統的概略架構圖。參考圖1所示，一個放療計劃系統100在程序組成上可包括應用模塊101、容器管理器102和容器池103。放療計劃系統100向用戶呈現交互界面。應用模塊101面向用戶，通過交互界面接收用戶的指示以及向用戶呈現任務執行的結果。在一實施例中，應用模塊101接收用戶的服務請求。例如用戶需要執行諸如器官自動分割、劑量計算等任務，從而需要應用模塊101提供服務。容器管理器102適于執行和容器管理有關的操作，包括但不限于：創建一個或多個容器1031,1032,1033,1034；將各容器放置到容器池103中；響應服務請求，分配容器中的一個或多個來執行所請求的服務；匯總容器的結果，返回給應用模塊101。容器池103用于容納一個或多個容器。

用戶的一項任務可分解為一個或多個服務。容器每個容器可以執行一項服務。在此，各容器用于執行各自的服務。也就是說，對于一項具體服務(如器官分割)，容器管理器102會使用一個容器來執行。對于另一項具體服務(如劑量計算)，容器管理器102會使用另一個容器來執行。多個容器也可以共同執行一項服務。容器池中的容器用來執行一項具體服務前，可經歷稱為實例化(instantiated)的過程，形成實例化的容器或者容器實例。由于容器的特性，各個容器可以并行地執行各項服務。這樣，對于一項任務來說，需要處理的時間為所有服務中處理時間最長的一個時間，而非該項任務執行時間的總和，因此本實施例的方式大幅度提高了響應速度。

這種機制對于蒙特卡羅算法還有額外的好處。蒙特卡羅算法模擬大量粒子穿過治療機頭的輸運過程，獲得粒子在模體表面的相空間數據，直接利用相空間數據作為蒙特卡羅劑量算法的輸入。采樣越多，越近似最優解。蒙特卡羅算法的另一大特點是粒子相互獨立，非常有利于并行計算。這樣可以用大量的獨立的容器，來實現蒙特卡羅算法，變乘法為加法運算，通過硬件的物理空間來換取計算的時間，從而解決蒙特卡羅算法的性能瓶頸。

圖1所示的放療計劃系統可以在各種架構的計算機系統中實施。例如放療計劃系統可以在單機系統中實施，也可以在網絡系統中實施。放療計劃系統可通過在計算機系統中配置程序來實現。程序儲存在硬盤等儲存介質中，載入到內存等存儲器中，供處理器執行。在實施時，每一個容器可以是單獨的進程，也可以是單獨的線程。每個容器可以部署在物理機器上，也可以部署在虛擬機器上。

圖2是根據本發明一實施例的基于容器的任務執行方法流程圖。參考圖2所示，這一放療計劃的任務執行方法，由放療計劃系統執行，且包括如下步驟：

在步驟201，創建一個或多個容器。

在此，容器的數量可以是預設的，也可以根據用戶需求確定。

在步驟202，將各容器放置到容器池中。

容器池中的容器用于響應用戶的服務請求。容器池中預設容器數量，可以根據不同的應用場景和用戶習慣，配置到最佳。

在步驟203，響應服務請求，使用容器池中的一個或多個容器來執行所請求的服務。

在此，所請求的服務可以是一個，也可以是多個。每個服務可以由一個或多個容器來執行。

在步驟204，匯總容器的結果，返回給服務的請求方。

在此，一個或多個容器的結果會被匯總和返回。在客戶端/服務器架構的系統中，客戶端通常是服務的請求方，因此結果會被返回給客戶端。

可以理解，存在所請求的服務數量與容器數量不匹配的情形，因此本實施例還可包括根據所請求的服務的數量，動態地補充容器池中的容器數量。例如在步驟203中，如果容器池中可用的容器數n小于所請求的服務數r，那么需要回到步驟201，創建足夠的容器，以滿足需求，并在步驟202將新創建的容器加入容器池中。如果n大于或等于r，則容器池中的可用容器數足夠。無論如何，響應此次請求后，容器池中可用容器數減少了r個，因此最好同時在后臺再創建多個容器以使可用容器數達到預定數目，便于響應其他客戶端的請求。通常地，該預定數目即為n。

在步驟204之后，還可包括回收容器，將其放回到容器池中。例如在一種實施方式中，如果容器池中設定預留10個容器，客戶端占用了4個容器，那么其中可用的還有6個容器；當客戶端不用了，需要將占用的4個容器放回到容器池中，這是回收操作。回收到容器池中的容器會被去實例化(de-instantiated)。

另外，如果此前創建了多于預定數目n的容器，在步驟204之后還可以銷毀多于n個的容器，將容器數量減少到預定的n個。例如在另一種實施方式中，如果容器池中預定預留10個容器，來了3個客戶端，各申請4個容器，這樣一共創建了12個容器；當所有客戶端都不用了，則將其中10個容器放回到容器池中，這是回收操作，另外多出來的2個容器需要被銷毀，這是銷毀操作。

圖2所示的流程可以在圖1所示放療計劃系統100的容器管理器102中執行。每個容器管理器可以與一個或多個應用模塊關聯，且具有獨立創建和管理與該應用模塊任務有關的容器的權限。也就是說，此容器管理器可以在不依賴放療計劃系統100的其他組成部分，例如其他應用模塊和其他容器管理器的情況下，獨立地創建和管理與關聯的應用模塊任務有關的容器。

較佳地，每個容器管理器與一個應用模塊關聯，用于創建和管理與該應用模塊任務有關的容器。在這一實例中，每個應用模塊適于被獨立地啟動和關閉。舉例來說，目前的放療計劃系統通常包括多個功能模塊：勾畫模塊、計劃模塊、評估模塊和驗證模塊。可以在放療計劃系統配置4個容器管理器，其中第1個容器管理器與例如勾畫模塊關聯，第2個容器管理器與例如計劃模塊關聯，第3個容器管理器與例如評估模塊關聯，第4個容器管理器與例如驗證模塊關聯。每個容器管理器均有獨立地創建和管理與關聯的應用模塊任務有關的容器的權限。

上述各個應用模塊的相互獨立以及對容器創建和管理權限的相互獨立有明顯的優勢。對于用戶來說，每一次使用并非所有放療計劃的功能，比如負責勾畫工作的物理師通常更多的使用勾畫模塊，而不需要其他模塊；同理，評估模塊和驗證模塊的功能相對比較對立。本實施例的放療計劃系統能夠根據用戶的當前實際使用需要，最小化的加載相關的應用模塊，從而減少對資源的占用，提高單個系統效率，最大程度地提升云平臺整體運行的效率。

下面例舉在一些應用模塊上執行任務的示例。

圖3是根據本發明一實施例的器官自動分割部分的架構圖。參考圖3所示，放療計劃系統的器官自動分割部分包括勾畫模塊301、容器管理器302、自動分割容器池303和感興趣區域(regionofinterest,roi)容器池304。自動分割容器池303包含自動分割容器，能執行器官分割任務。roi容器池304則包含感興趣區域容器，包括所有roi相關的功能。器官自動分割部分中各部分的功能可參考圖1所示的概略架構，在此不再展開。

圖4是根據本發明一實施例的器官自動分割任務執行方法流程圖。參考圖4所示，此方法包括如下步驟：

在步驟401，應用模塊請求分割多個器官；

在步驟402，容器管理器指定對應的多個容器，并將需要的數據輸入傳遞給每個容器；

在步驟403，每個容器負責一個器官的分割任務；

在步驟404，所有容器結束，匯總結果，返回給容器管理器，進一步返回給應用模塊，或者直接返回給容器管理器。

圖5是根據本發明一實施例的計劃部分的架構圖。參考圖5所示，放療計劃系統的計劃部分包括計劃模塊501、容器管理器502、計劃容器池503、劑量計算容器池504和優化容器池505。計劃容器池503包含計劃容器，進行計劃的創建、修改以及刪除。劑量計算容器池504包含劑量計算容器，負責劑量計算的功能。計劃部分中各部分的功能可參考圖1所示的概略架構，在此不再展開。

圖6是根據本發明一實施例的劑量計算任務執行方法流程圖。參考參考圖6所示，此方法包括如下步驟：

在步驟601，應用模塊請求計算多個射野(beam)的計算；

在步驟602，容器管理器指定對應的多個容器，并將需要的數據輸入傳遞給每個容器；

在步驟603，每個容器負責一個射野的劑量計算任務；

在步驟604，所有容器結束，匯總結果，返回給容器管理器，進一步返回給應用模塊，或者直接返回給應用模塊。

圖7是根據本發明一實施例的創建射束過程中即時計算劑量的方法流程圖。即時劑量計算，是在用戶創建射野的同時，系統后臺立即計算該射野的劑量，這樣在用戶點擊劑量計算按鈕的時候，只需要合成所有射野的劑量，能夠最大程度提高系統性能。參考圖7所示，此方法包括以下步驟：

在步驟701，用戶創建新的射野；

在步驟702，獲取一個劑量計算容器；

在步驟703，計算基于此射野的劑量分布；

在步驟704，判斷用戶是否點擊劑量計算按鈕；如果沒有點擊，重復701-703；

在步驟705，如果用戶點擊了劑量計算的按鈕，匯總所有射野的劑量計算的結果，返回給應用模塊。

圖8根據本發明一實施例的放療計劃系統的完整架構圖。參考圖8所示，一個典型的放療計劃系統800包括多個應用模塊，如勾畫模塊801、計劃模塊802、評估模塊803和驗證模塊804。勾畫模塊801，屬于比容器池更高(更面向用戶或者客戶端)層次的模塊，能夠獨立完成勾畫的任務。計劃模塊802，屬于比容器池更高層次的模塊，為放療計劃系統800的核心模塊，能夠創建完整的治療計劃，包括正向計劃和逆向計劃。評估模塊803，屬于比容器池更高層次的模塊，能夠完成多個計劃的評估和比較任務。驗證模塊804，屬于比容器池更高層次的模塊，能夠完成計劃驗證的任務。在勾畫模塊801、計劃模塊802、評估模塊803和驗證模塊804中均可各自與容器管理器交互，如圖1所示，在此不再圖示。器官自動分割容器池811，能夠提供器官分割任務。roi容器池812，包括所有roi相關的功能。計劃容器池813，包括計劃的創建、修改以及刪除的容器。劑量計算容器池814，負責劑量計算的功能。優化容器池815，負責劑量優化相關的任務。計劃比較容器池816，負責多個計劃評估和比較的任務。驗證容器池817，提供計劃驗證的功能。

各應用模塊，如勾畫模塊801、計劃模塊802、評估模塊803和驗證模塊804可以調用與其功能有關的容器池。例如勾畫模塊801可以調用自動分割容器池811和roi容器池812；計劃模塊802可以調用包括計劃容器池813、劑量計算容器池814和優化容器池815。評估模塊803可以調用劑量計算容器池814和計劃比較容器池816。驗證模塊804可以調用計劃容器池813、劑量計算容器池814和驗證容器池817。

每個容器池都包含一個或多個容器，例如圖中的容器821,822,825和826。可以根據需求，動態創建、回收和/或銷毀一個或多個容器。

從另一角度看，本申請提出一種放療計劃系統，包括存儲器、處理器及存儲在存儲器上并可在處理器上運行的計算機程序。處理器執行所述程序時實現本申請的方法的步驟。

從另一角度看，本申請提出一種計算機可讀存儲介質，其上存儲有計算機程序，該程序包括實現本申請的方法的代碼。

上文已對基本概念做了描述，顯然，對于本領域技術人員來說，上述發明披露僅僅作為示例，而并不構成對本申請的限定。雖然此處并沒有明確說明，本領域技術人員可能會對本申請進行各種修改、改進和修正。該類修改、改進和修正在本申請中被建議，所以該類修改、改進、修正仍屬于本申請示范實施例的精神和范圍。

同時，本申請使用了特定詞語來描述本申請的實施例。如“一個實施例”、“一實施例”、和/或“一些實施例”意指與本申請至少一個實施例相關的某一特征、結構或特點。因此，應強調并注意的是，本說明書中在不同位置兩次或多次提及的“一實施例”或“一個實施例”或“一替代性實施例”并不一定是指同一實施例。此外，本申請的一個或多個實施例中的某些特征、結構或特點可以進行適當的組合。

此外，本領域技術人員可以理解，本申請的各方面可以通過若干具有可專利性的種類或情況進行說明和描述，包括任何新的和有用的工序、機器、產品或物質的組合，或對他們的任何新的和有用的改進。相應地，本申請的各個方面可以完全由硬件執行、可以完全由軟件(包括固件、常駐軟件、微碼等)執行、也可以由硬件和軟件組合執行。以上硬件或軟件均可被稱為“數據塊”、“模塊”、“引擎”、“單元”、“組件”或“系統”。此外，本申請的各方面可能表現為位于一個或多個計算機可讀介質中的計算機產品，該產品包括計算機可讀程序編碼。

同理，應當注意的是，為了簡化本申請披露的表述，從而幫助對一個或多個發明實施例的理解，前文對本申請實施例的描述中，有時會將多種特征歸并至一個實施例、附圖或對其的描述中。但是，這種披露方法并不意味著本申請對象所需要的特征比權利要求中提及的特征多。實際上，實施例的特征要少于上述披露的單個實施例的全部特征。

雖然本發明已參照當前的具體實施例來描述，但是本技術領域中的普通技術人員應當認識到，以上的實施例僅是用來說明本發明，在沒有脫離本發明精神的情況下還可作出各種等效的變化或替換，因此，只要在本發明的實質精神范圍內對上述實施例的變化、變型都將落在本申請的權利要求書的范圍內。