放疗计划系统及其任务执行方法与流程

本发明主要涉及医疗设备，尤其涉及一种放疗计划系统及其任务执行方法。

背景技术：

放射治疗是利用现代高科技计算机控制先进的射线发生设备——医用电子直线加速器，通过控制放射线的入射方向、放射区域对肿瘤进行不开刀、无痛苦、损伤小、体质消耗小的有效肿瘤治疗方案。在进行放射治疗之前，需在放疗计划系统(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。可以根据需求，动态创建、回收和/或销毁一个或多个容器。

从另一角度看，本申请提出一种放疗计划系统，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。处理器执行所述程序时实现本申请的方法的步骤。

从另一角度看，本申请提出一种计算机可读存储介质，其上存储有计算机程序，该程序包括实现本申请的方法的代码。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述发明披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

虽然本发明已参照当前的具体实施例来描述，但是本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本发明，在没有脱离本发明精神的情况下还可作出各种等效的变化或替换，因此，只要在本发明的实质精神范围内对上述实施例的变化、变型都将落在本申请的权利要求书的范围内。