Systems and methods for validating main radiation dose distribution curves, and storage media

Abstract

This invention provides a system and method for verifying a primary radiation dose distribution curve, and a storage medium. A system and method for verifying a primary dose distribution curve generated by a radiation machine using a cloud-based service are discussed. An exemplary system may include: a cloud providing the cloud-based service; and a user interface enabling multiple users to access the cloud-based service. A file service can extract image information and information about the radiation machine from a patient's DICOM file. A dose engine service can determine a secondary radiation dose distribution curve by applying a dose algorithm to the image information and the radiation machine information. The applied dose algorithm may differ from the dose algorithm used by the radiation machine to generate the primary dose distribution curve. A dose assessment service can use the secondary radiation dose distribution curve to verify the accuracy of the primary dose distribution curve based on the consistency indication between the primary and secondary dose distribution curves.

Description

Technical Field

[0001] This invention relates generally to dose management in radiotherapy treatment systems, and more specifically, to systems and methods for validating radiation dose distribution curves using cloud services. Background Technology

[0002] Radiation therapy (or "radiotherapy") can be used to treat cancer or other diseases in mammalian tissues (e.g., humans and animals). One such radiation therapy technique uses a linear accelerator (also known as a "linac") to irradiate the tumor with high-energy particles (e.g., electrons, protons, ions, high-energy photons, etc.). The arrangement and dosage of the radiation beam can be precisely controlled to ensure the tumor receives the prescribed radiation, and the beam is arranged to minimize damage to surrounding healthy tissues, often referred to as organs at risk (OARs). Similar to prescribing medication, a physician prescribes a predetermined dose of radiation for the tumor and surrounding organs. Typically, ionizing radiation, in the form of a collimated beam, is directed from an external radiation source towards the patient.

[0003] Specified or selectable beam energies can be used, for example, to deliver diagnostic or therapeutic energy levels. Modulation of the radiation beam can be provided by one or more attenuators or collimators, such as multi-leaf collimators (MLCs). The intensity and shape of the radiation beam can be adjusted by collimation to avoid damaging adjacent healthy tissue by aligning the projected beam with the contours of the target tissue (e.g., OAR).

[0004] Treatment planning is the process of determining specific radiotherapy parameters to achieve therapeutic goals within constraints. Examples of radiotherapy parameters include beam angle, dose intensity level, dose distribution, etc. The radiation dose can be calculated using software models. The result of the treatment planning process is a radiotherapy treatment plan, also referred to below as a treatment plan or simply a plan. Treatment plans can be developed prior to radiotherapy, for example using images from one or more medical imaging techniques, such as X-rays, computed tomography (CT), magnetic resonance imaging (MR), positron emission tomography (PET), single-photon emission computed tomography (SPECT), or ultrasound. Healthcare providers can use images of the patient's anatomy to identify the target tumor and the surrounding organ of origin (OAR), delineate the target tumor to receive the prescribed radiation dose, and similarly delineate nearby tissues, such as organs at risk of damage from radiotherapy. Delineation can be done manually or using automated tools that help identify or delineate the target tumor and OAR. The radiotherapy treatment plan can then be created using optimization techniques based on clinical and dosimetric goals and constraints, such as maximum, minimum, and partial radiation doses to portions of the tumor volume, and similar measures for critical organs.

[0005] In some cases, the radiation dose calculated by software models during treatment planning may differ from the actual dose measurement. This discrepancy can be attributed to various factors, including measurement uncertainty, dose calculation uncertainty, or dose delivery uncertainty. To prevent or reduce the difference between the calculated and measured doses, pretreatment dose validation (also known as subdose verification) has become an important quality assurance (QA) procedure and is routinely performed in clinical facilities. The dose validation process may include verifying a dose intensity map consistent with the radiation field using film. Proper dose validation helps prevent incorrect dose delivery to patients and ensures patient safety and treatment accuracy. Summary of the Invention

[0006] MR-linac is a radiotherapy system that combines linac radiotherapy with diagnostic-grade magnetic resonance imaging (MRI). MR-linac enables in-room MRI of anatomical structures and monitoring of physiological therapeutic adaptation and response, and has the potential to reduce treatment margins using real-time visualization and target tracking. It can precisely locate tumors and surrounding tissues, track their movement, and adjust treatment in real time in response to changes in tumor location, shape, biology, and spatial relationship with key organs during treatment.

[0007] Treatment planning can include using three-dimensional (3D) images of the patient to identify the target region (e.g., the tumor) and key organs near the tumor. Creating a treatment plan can be a time-consuming process, during which the planner attempts to adhere to various treatment goals or constraints (e.g., dose-volume histogram (DVH), overlap-volume histogram (OVH)) and consider their respective importance (e.g., weights) to produce a clinically acceptable treatment plan. This treatment plan consists of digital parameters that specify the direction, cross-sectional shape, and intensity of each radiation beam. Once the treatment plan is created, it can be executed by positioning the patient in the treatment machine and delivering prescribed radiation therapy guided by optimized planning parameters. In some examples, a radiotherapy treatment plan may include dose “gradations” to provide a sequence of radiation therapy over predetermined time periods (e.g., 30 to 45 fractions per day), where each treatment includes a designated fraction of the total prescribed dose. During treatment, the patient’s position and the position of the target tumor relative to the treatment machine (e.g., linac) are critical to ensure that the target tumor is radiated without radiating healthy tissue.

[0008] Treatment planning systems (TPS) can use beam models (e.g., software models) to determine dose measurements and other treatment parameters. A beam model may include parameters describing the distribution of radiation energy emitted from a radiation machine (e.g., a linac). Beam model parameter values ​​can vary between different radiation machines, even those of the same model from the same manufacturer, because at least one of these differences may exist between each radiation machine, such as the effects or energy delivered. Mechanical differences between radiation machines (e.g., mechanical dimensions or material properties) or differences in component values ​​(e.g., electronic circuitry component values) can also lead to differences in beam model parameter values ​​between different radiation machines.

[0009] To ensure patient safety and dosage accuracy, the radiation dose calculated by the TPS system can be validated before it is implemented in the treatment system and delivered to the patient. The radiation dose distribution curve can include a dose metric that defines the amount of radiation applied to the target area (e.g., a tumor), the manner of delivery of this radiation, and the dose distribution within the target area and the OAR. Examples of dose distribution curves can include: a percentage depth dose (PDD) distribution curve representing the relative dose as a function of depth, a percentage radial dose (PRD) distribution curve representing the relative dose as a function of radial distance, etc. Conventionally, human experts (e.g., radiation oncologists or medical physicists) manually validate that the calculated dose (e.g., the dose metric or dose distribution) meets predetermined dosimetry validation criteria. Dosimetry validation criteria can be based on the analysis of a limited number of points in a low-dose gradient region or the measurement of the distance between isodose lines in a high-dose gradient region. Human experts can compare the expected dose with film measurements by placing the films side-by-side to visualize their differences or by overlaying the isodose curves of these films onto the planning results to check for any discrepancies or validation consistency.

[0010] Manual dose validation, such as visual inspection and film comparison, can sometimes be inconsistent and lead to misinterpretations. Furthermore, while manual validation may be sufficient for dose planning in two-dimensional (2D) conventional radiotherapy or some simple three-dimensional (3D) conformal radiotherapy, the development of more advanced radiotherapy techniques (e.g., intensity-modulated radiotherapy (IMRT) or volume-modulated arc therapy (VMAT)) typically adds more complexity to dose calculations and requires more sophisticated dose metrics and distribution representations. For example, the integrity of the complexity of IMRT dose delivery techniques depends on the quantification of consistency between the planned and delivered IMRT dose distribution. Therefore, manual validation of doses generated by the TPS of advanced radiotherapy systems can be both time-consuming and laborious.

[0011] As an alternative to or supplement to manual dose verification, automated dose monitors can automatically calculate dose distribution profiles and compare them with those generated by the radiation therapy machine's TPS (Transient Spectrum Analyzer) for dose verification. However, current automated dose verification systems typically cannot verify dose distribution profiles generated by different TPS systems from different models or manufacturers of radiation therapy equipment. Furthermore, these automated dose verification systems are often not, or not optimized, for simultaneously handling a large number of dose verification requests from various hospitals or clinical facilities. The inventors have recognized that dose verification systems, apparatus, and methods have not yet met the need to accommodate a large number of dose distribution profiles generated by a wide variety of TPS systems. Such a universal dose verification system could be an integral part of an improved quality assurance (QA) system suitable for advanced radiation therapies such as IMRT or VMAT.

[0012] This invention discusses a cloud-based system, apparatus, and method for verifying a master dose distribution curve generated by a radiation machine (e.g., linac) for providing radiotherapy to an object. An exemplary system includes: a cloud providing a range of cloud-based services; and a user interface enabling multiple users to access one or more cloud-based services. The cloud services include a file service that can receive patient image information and information about the radiation machine that generated the patient images. Patient image information and radiation machine information can be extracted from DICOM files. A dose engine service can determine a secondary radiation dose distribution curve by applying a dose algorithm to the image and radiation machine information. The applied dose algorithm may differ from the dose algorithm used by the radiation machine to generate the master dose distribution curve. A dose assessment service can use the secondary radiation dose distribution curve to verify the accuracy of the master dose distribution curve based on an indication of consistency between the master and secondary dose distribution curves.

[0013] Example 1 is a system for verifying a primary radiation dose distribution curve generated by a radiation machine to provide radiation therapy to a subject. The system includes: a cloud computing device or network device configured to provide cloud-based services, the cloud-based services including: a file service for receiving image information (1) of the subject generated by the radiation machine and information (2) about the radiation machine; a dose engine service for using the received image information and radiation machine information to determine a secondary radiation dose distribution curve; a dose assessment service for using the secondary radiation dose distribution curve to verify the primary radiation dose distribution curve; and a user interface configured to: enable a client to access one or more of the cloud-based services via a communication network; and output the verification of the primary radiation dose distribution curve to a user or process.

[0014] In Example 2, the subject of Example 1 may optionally include a file service that can be configured to receive a DICOM file of an object and parse the received DICOM file to extract image information and radiology information from the received DICOM file.

[0015] In Example 3, the subject of Example 2 may optionally include a file service that can be configured to extract treatment plan information from a parsed DICOM file, which includes the main radiation dose distribution curve.

[0016] In Example 4, any one or more of the topics in Examples 2 to 3 may optionally include a DICOM file, which may be a compressed DICOM file or an encrypted DICOM file. The file service may be configured to decompress or decrypt the DICOM file and parse the decompressed or decrypted DICOM file.

[0017] In Example 5, any one or more of the subjects in Examples 2 to 4 may optionally include a cloud storage device that can be configured to store DICOM files of objects or image information and radiation machine information extracted from DICOM files.

[0018] In Example 6, any one or more of the topics in Examples 1 to 5 may optionally include radiation machine information received by the file service, which may include one or more radiation beam parameters or one or more bench parameters.

[0019] In Example 7, any one or more of the topics in Examples 1 to 6 may optionally include a dose engine service that can be configured to apply a sub-dose algorithm to one or more of the image information or radiation machine information to determine the sub-radiation dose, the sub-dose algorithm being different from the primary dose algorithm used by the radiation machine to calculate the primary radiation dose distribution curve.

[0020] In Example 8, the subject of Example 7 may optionally include a user interface that can be configured to: receive user input for a subdose algorithm; or receive user selection of a subdose algorithm from a plurality of candidate dose algorithms.

[0021] In Example 9, any one or more of the topics in Examples 1 to 8 may optionally include a dose assessment service that can be configured to: determine a consistency measure between the primary radiation dose distribution curve and the secondary radiation dose distribution curve, and verify the primary radiation dose distribution curve based on the determined consistency measure.

[0022] In Example 10, the subject of Example 9 may optionally include a dose consistency metric, which may include the relative difference between the primary radiation dose distribution curve and the secondary radiation dose distribution curve, and the dose assessment service may be configured to verify the primary radiation dose distribution curve in response to the dose consistency metric falling within a specified range.

[0023] In Example 11, any one or more of the subjects in Examples 1 to 10 may optionally include a cloud computing device or a networking device, which may include an access point configured to support simultaneous access to a cloud-based service by two or more clients.

[0024] In Example 12, the subject of Example 11 may optionally include a cloud-based service, which may further include an occupant management service configured to queue service requests from the two or more clients.

[0025] In Example 13, the subject matter of any one or more of Examples 1 to 12 may optionally include a cloud computing device or a network device that can be configured to generate a target radiotherapy plan using a beam model based on validation of the master dose distribution curve.

[0026] Example 14 is a method for verifying a primary radiation dose distribution curve generated by a radiation machine to deliver radiation therapy to a subject. The method includes the following steps performed via a cloud computing device or a networked device: receiving a DICOM file of the subject; parsing the received DICOM file and extracting image information and information about the radiation machine from the received DICOM file; using the image information and machine information to determine a secondary radiation dose distribution curve; and using the secondary radiation dose distribution curve to verify the primary radiation dose distribution curve.

[0027] In Example 15, the subject matter of Example 14 may optionally include determining a secondary radiation dose distribution curve, which may include applying a secondary dose algorithm to one or more of image information or radiation machine information, the secondary dose algorithm being different from the primary dose algorithm used by the radiation machine to calculate the primary radiation dose distribution curve.

[0028] In Example 16, the subject of Example 15 may optionally include receiving user input for a subdose algorithm; or receiving a user selection of a subdose algorithm from a plurality of candidate dose algorithms.

[0029] In Example 17, the subject matter of any one or more of Examples 14 to 16 may optionally include verifying a primary radiation dose distribution curve, which may include: determining a consistency measure between the primary radiation dose distribution curve and the secondary radiation dose distribution curve; and verifying the primary radiation dose distribution curve in response to the determined consistency measure satisfying certain conditions.

[0030] In Example 18, the subject of Example 17 may optionally include: queuing service requests from two or more clients simultaneously accessing a cloud-based service.

[0031] In Example 19, any one or more of the topics in Examples 14 to 18 may optionally include: generating a target radiotherapy plan using a beam model based on validation of the master dose distribution curve.

[0032] Example 20 is a non-transitory machine-readable storage medium comprising instructions that, when executed by one or more processors of a machine, cause the machine to perform the following operations: receiving a DICOM file of an object, the DICOM file being generated by a radiation machine for providing radiation therapy to the object; parsing the received DICOM file and extracting image information and information about the radiation machine from the received DICOM file; using the image information and machine information to determine a secondary radiation dose distribution curve; and using the secondary radiation dose distribution curve to verify a primary radiation dose distribution curve.

[0033] In Example 21, the subject matter of Example 20 may optionally include the operation of determining a secondary radiation dose distribution curve, the operation of which may include applying a secondary dose algorithm to one or more of image information or radiation machine information, the secondary dose algorithm being different from the primary dose algorithm used by the radiation machine to calculate the primary radiation dose distribution curve.

[0034] In Example 22, the subject of Example 21 may optionally include the following operations, which may include: receiving user input for a subdose algorithm; or receiving a user selection of a subdose algorithm from a plurality of candidate dose algorithms.

[0035] In Example 23, the subject matter of any one or more of Examples 20 to 22 may optionally include the operation of verifying a primary radiation dose distribution curve, the operation of which may include: determining a consistency measure between the primary radiation dose distribution curve and the secondary radiation dose distribution curve; and verifying the primary radiation dose distribution curve in response to the determined consistency measure satisfying certain conditions.

[0036] In Example 24, the subject of Example 23 may optionally include the following operation: queuing service requests from two or more clients simultaneously accessing a cloud-based service.

[0037] In Example 25, any one or more of the topics in Examples 23 to 24 may optionally include the operation of generating a radiotherapy plan using a beam model based on validation of the master dose distribution curve.

[0038] This paper discusses a cloud-based dose verification system, apparatus, and method that can improve automated quality assurance (QA) in advanced radiotherapy such as IMRT or VMAT. Compared to conventional manual or automated dose verification methods, the cloud-based dose verification discussed in this paper offers several advantages. First, this cloud-based dose verification is universal for verifying dose distribution profiles generated by multiple TPS systems of different models or from different manufacturers. Second, this cloud-based dose verification supports multi-user access to cloud-based services, allowing multiple users, for example, from different hospitals or clinical institutions, to subscribe to and simultaneously access various resources and cloud services, thereby reducing equipment costs and maintenance costs at each client. Third, cloud-based automated dose verification can significantly reduce the workload of human dose verifiers; improve the accuracy and efficiency of dose verification; and enhance data security and data management flexibility.

[0039] The foregoing is intended to provide an overview of the subject matter of this patent application. It is not intended to provide an exclusive or exhaustive explanation of the invention. This application includes detailed descriptions to provide further information regarding this patent application. Attached Figure Description

[0040] The accompanying drawings are not necessarily drawn to scale. Throughout the drawings, the same reference numerals describe substantially similar components. The same reference numerals with different letter suffixes indicate different instances of substantially similar components. The drawings illustrate, by way of example rather than limitation, the various embodiments discussed in this document.

[0041] Figure 1 An exemplary radiotherapy system is shown.

[0042] Figure 2A An exemplary radiotherapy system that can provide a treatment beam is shown.

[0043] Figure 2B An exemplary combined system including a computed tomography (CT) imaging system and a radiotherapy system is shown.

[0044] Figure 3A partial cross-sectional view of an exemplary combined system including a magnetic resonance (MR) imaging system and a radiotherapy system is shown.

[0045] Figure 4 An example of a dose distribution curve generated by a treatment planning system is shown.

[0046] Figure 5 This is a diagram illustrating an exemplary architecture of a cloud-based dose verification system.

[0047] Figure 6 This is a block diagram illustrating an exemplary cloud server configured to provide a suite of cloud-based services, including dose verification.

[0048] Figure 7 This is a flowchart illustrating an exemplary method for using cloud services to verify dose distribution curves generated by the TPS system of a radiotherapy system.

[0049] Figure 8 A block diagram of an example machine is shown in general, on which any or more of the techniques (e.g., methods) discussed herein can be executed. Detailed Implementation

[0050] In the following detailed description, reference is made to the accompanying drawings, which form a part of the detailed description, and the detailed description is illustrated by way of specific embodiments that allow the present disclosure to be practiced. These embodiments, also referred to herein as “examples,” are described in sufficient detail to enable those skilled in the art to practice the present disclosure, and it should be understood that embodiments may be combined or other embodiments may be utilized and structural, logical, and electrical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not limiting, and the scope of the present disclosure is defined by the appended aspects and their equivalents.

[0051] Figure 1 An exemplary radiotherapy system 100 for delivering radiotherapy to a patient is shown. The radiotherapy system 100 includes a data processing unit 112. The data processing unit 112 can be connected to a network 120. The network 120 can be connected to the Internet 122. The network 120 can connect the data processing unit 112 to one or more of the following: a database 124, a hospital database 126, an oncology information system (OIS) 128, a radiotherapy device 130, an image acquisition device 132, a display device 134, and a user interface 136. The data processing unit 112 can be configured to generate a radiotherapy treatment plan 142 to be used by the radiotherapy device 130.

[0052] Data processing apparatus 112 may include a memory device 116, a processor 114, and a communication interface 118. The memory device 116 may store computer-executable instructions, such as an operating system 143, a radiotherapy treatment plan 142 (e.g., the original treatment plan, an adjusted treatment plan, etc.), a software program 144, and any other computer-executable instructions to be executed by the processor 114. The memory device 116 may additionally store data, including medical images 146, patient data 145, and other data required to implement the radiotherapy treatment plan 142.

[0053] Software program 144 may include one or more software packages that, when executed by a machine such as data processor 114, can perform specific image processing and generate a radiotherapy treatment plan 142. In an example, software program 144 may convert a medical image of one format (e.g., MRI) to another format (e.g., CT) by generating synthetic images such as pseudo-CT images. For example, software program 144 may include an image processing program trained to predictive models for converting medical images from one modality of medical image 146 (e.g., MR image) to synthetic images of a different modality (e.g., pseudo-CT image); alternatively, the trained predictive model may convert CT images to MR images. In another example, software program 144 may register a patient image (e.g., CT image or MR image) with the patient's dose distribution (also represented as an image) such that the corresponding image voxels and dose voxels are appropriately correlated via a network. In yet another example, software program 144 may replace the functionality of the patient image, such as a signature distance function or a processed version of the image emphasizing some aspect of the image information. Such functionality could emphasize the edges or differences in voxel texture, or any other structural aspect useful for neural network learning. Software program 144 could replace functionality that emphasizes some aspects of dose distribution that provide dose information. Such functionality could emphasize steep gradients around the target, or any other structural aspect useful for neural network learning.

[0054] In the example, software program 144 can generate projection images for a set of two-dimensional (2D) and / or 3D CT or MR images depicting anatomical structures (e.g., one or more targets and one or more OARs), the projection images representing different views of the anatomical structures at a first gantry angle of the radiotherapy apparatus. For example, software program 144 can process the CT or MR image set and create a stack of projection images depicting different views of the anatomical structures depicted in the CT or MR images at various angles of the radiotherapy apparatus gantry. Specifically, one projection image may represent a view of the anatomical structure at 0 degrees of the gantry, a second projection image may represent a view of the anatomical structure at 45 degrees of the gantry, and a third projection image may represent a view of the anatomical structure at 90 degrees of the gantry. The degrees may be the position of the MLC relative to a specific axis of the anatomical structure depicted in the CT or MR images. For each of the different degrees measured, the axis may remain the same.

[0055] In the example, software program 144 can generate graphical aperture image representations of the MLC blade position at various gantry angles. These graphical aperture images are also referred to as aperture images. Specifically, software program 144 can receive a set of control points for controlling the radiotherapy apparatus to generate a radiotherapy beam. The control points can represent machine parameters such as beam intensity, gantry angle relative to the patient position, and the MLC blade position. Based on these control points, graphical images can be generated to graphically represent the beam shape and intensity output by the MLC at each specific gantry angle. Software program 144 can align each graphical image of the aperture at a specific gantry angle with a corresponding projected image at that generated angle. The images are aligned with the projections and scaled so that each pixel of the projected image is aligned with the corresponding pixel of the aperture image.

[0056] In the example, software program 144 may include treatment planning software for generating or estimating a graphical aperture image representation of the MLC blade position at a given gantry angle for a projected image of an anatomical structure representing a view of the anatomical structure from a given gantry angle. Software program 144 may also include a beam model that can simulate radiation exiting the radiation machine and being applied to the patient. Software program 144 can calculate machine parameters or control points for a given type of machine to output a beam from the MLC that achieves the same or similar estimated graphical aperture image representation of the MLC blade position. That is, the treatment planning software can output an image representing an estimated beam shape and intensity for a given gantry angle and a given projected image of the gantry at that angle, and this function can calculate control points for a given radiotherapy apparatus to achieve that beam shape and intensity.

[0057] In addition to the memory 116 storing the software program 144, the software program 144 may be additionally or alternatively stored on a removable computer medium, such as a hard disk drive, computer disk, CD-ROM, DVD, HD, Blu-ray DVD, USB flash drive, SD card, memory stick, or any other suitable medium; and the software program 144 may be executed by the data processor 114 when it is downloaded to the data processing device 112.

[0058] Data processor 114 may be communicatively coupled to memory 116, and processor 114 may be configured to execute computer-executable instructions stored in memory 116. Processor 114 may send medical images 146 to or receive medical images 146 from memory 116. For example, processor 114 may receive medical images 146 from image acquisition device 132 via communication interface 118 and network 120 to store the medical images 146 in memory 116. Processor 114 may also send the medical images 146 stored in memory 116 via communication interface 118 to network 120 to store the medical images 146 in database 124 or hospital database 126.

[0059] Data processor 114 can use software program 144 (e.g., treatment planning software) along with medical images 146 and patient data 145 to create a radiotherapy treatment plan 142. Medical images 146 may include information such as imaging data associated with patient anatomical regions, organs, or the amount of segmented data of interest. Patient data 145 may include information such as: (1) functional organ modeling data (e.g., sequential vs. parallel organs, appropriate dose response models, etc.); (2) radiation dose data (e.g., DVH information); or (3) other clinical information about the patient and treatment (e.g., other surgeries, chemotherapy, previous radiotherapy, etc.).

[0060] In some examples, processor 114 may utilize software program 144 to generate intermediate data, such as updated parameters to be used by a machine learning model, such as a neural network model; or to generate intermediate 2D or 3D images, which may then be stored in memory 116. Processor 114 may then transmit an executable radiotherapy treatment plan 142 to radiotherapy apparatus 130 via communication interface 118 to network 120, wherein the radiotherapy plan will be used to treat a patient with radiation. Additionally, processor 114 may execute software program 144 to perform functions such as image transformation, image segmentation, deep learning, neural networks, and artificial intelligence. For example, processor 114 may execute software program 144 to train medical images or delineate the contours of medical images; such software program 144, when executed, may train boundary detectors or utilize shape dictionaries.

[0061] Processor 114 may be a processing device, including one or more general-purpose processing devices such as a microprocessor, central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), etc. More specifically, processor 114 may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. Processor 114 may also be implemented by one or more special-purpose processing devices such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), system-on-a-chip (SoCs), etc. As those skilled in the art will understand, in some embodiments, processor 114 may be a special-purpose processor rather than a general-purpose processor. Processor 114 may include one or more known processing devices, such as those from Intel... TM Manufactured Pentium TM Core TM Xeon TM or This series of microprocessors comes from AMD. TM Turion manufactured TM Athlon TM Sempron TM Opteron TM FX TM Phenom TM The processor 114 may be any of the following series of microprocessors, or any processor from various processors manufactured by Sun Microsystems. The processor 114 may also include a graphics processing unit, such as those from Nvidia. TM Manufactured Series, by Intel TM GMA and Iris manufactured TM series or by AMD TM Radeon manufactured TM The series of GPUs. Processor 114 may also include accelerated processing units, such as those from Intel. TM Xeon Phi manufactured TM This is a series. The disclosed embodiments are not limited to any type of processor otherwise configured to meet the computational needs of identifying, analyzing, maintaining, generating and / or providing large amounts of data or manipulating such data to perform the methods disclosed herein. Additionally, the term "processor" can include more than one processor (e.g., a multi-core design or multiple processors, all having multi-core designs). Processor 114 can execute sequences of computer program instructions stored in memory 116 to perform various operations, processes, and methods, which will be described in more detail below.

[0062] The memory device 116 may store medical images 146. In some embodiments, the medical images 146 may include one or more MRI images (e.g., 2D MRI, 3D MRI, 2D flow cytometry MRI, four-dimensional (4D) MRI, 4D volumetric MRI, 4D imaging MRI, etc.), functional MRI images (e.g., fMRI, DCE-MRI, diffusion MRI), CT images (e.g., 2D CT, cone-beam CT, 3D CT, 4D CT), ultrasound images (e.g., 2D ultrasound, 3D ultrasound, 4D ultrasound), one or more projection images representing views of anatomical structures depicted in MRI, synthetic CT (pseudo-CT) and / or CT images at different angles of the gantry relative to the patient axis, PET images, X-ray images, fluoroscopic images, radiotherapy field images, SPECT images, computer-generated synthetic images (e.g., pseudo-CT images), aperture images, graphic aperture image representations of MLC blade positions at different gantry angles, etc. Furthermore, the medical images 146 may also include medical image data, such as training images and ground truth images, contour images, and dose images. In this embodiment, medical images 146 can be received from image acquisition device 132. Therefore, image acquisition device 132 may include an MRI imaging device, a CT imaging device, a PET imaging device, an ultrasound imaging device, a fluoroscopy device, a SPECT imaging device, an integrated linac and MRI imaging device, or other medical imaging devices for acquiring medical images of a patient. Data processing device 112 can receive and store medical images 146 using any data type or format type to perform operations conforming to the disclosed embodiments.

[0063] Memory device 116 may be a non-transitory computer-readable medium, such as read-only memory (ROM), phase-change random access memory (PRAM), static random access memory (SRAM), flash memory, random access memory (RAM), dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), electrically erasable programmable read-only memory (EEPROM), static memory (e.g., flash memory, flash disk, static random access memory) and other types of random access memory, cache memory, registers, CD-ROM, DVD or other optical storage devices, magnetic tape cassette, other magnetic storage devices, or any other non-transitory medium that can be used to store information including images, data, or computer-executable instructions (e.g., stored in any format) that can be accessed by processor 114 or any other type of computer device. Computer program instructions may be accessed by processor 114, read from ROM or any other suitable memory location, and loaded into RAM for execution by processor 114. For example, memory 116 may store one or more software applications. The software applications stored in memory 116 may include, for example, an operating system 143 for a public computer system and for a software-controlled device. Furthermore, memory 116 may store the entire software application or only a portion of a software application that can be executed by processor 114. For example, memory device 116 may store one or more radiotherapy treatment plans 142.

[0064] Data processing device 112 can communicate with network 120 via communication interface 118, which is communicatively coupled to processor 114 and memory 116. Communication interface 118 provides communication connectivity between data processing device 112 and components of radiotherapy system 100 (e.g., allowing data exchange with external devices). For example, in some embodiments, communication interface 118 may have a suitable interface circuitry to connect to user interface 136, which may be a hardware keyboard, keypad, or touchscreen through which a user can input information into radiotherapy system 100.

[0065] Communication interface 118 may include, for example, network adapters, cable connectors, serial connectors, USB connectors, parallel connectors, high-speed data transmission adapters (e.g., fiber optic, USB 3.0, Thunderbolt, etc.), wireless network adapters (e.g., WiFi adapters), telecommunications adapters (e.g., 3G, 4G / LTE, etc.), etc. Communication interface 118 may include one or more digital and / or analog communication devices that allow data processing device 112 to communicate with other machines and devices, such as remotely located components, via network 120.

[0066] Network 120 can provide the functionality of a local area network (LAN), wireless network, cloud computing environment (e.g., Software as a Service, Platform as a Service, Infrastructure as a Service, etc.), client-server, wide area network (WAN), etc. For example, network 120 can be a LAN or WAN, and it may include other systems S1 (138), S2 (140), and S3 (141). Systems S1, S2, and S3 may be the same as data processing device 112 or may be different systems. In some embodiments, one or more systems in network 120 may form a distributed computing / simulation environment that collaboratively performs the embodiments described herein. In some embodiments, one or more systems S1, S2, and S3 may include a CT scanner that acquires CT images (e.g., medical image 146). Additionally, network 120 may be connected to the Internet 122 to communicate with servers and clients residing remotely on the Internet.

[0067] Therefore, network 120 allows data processing device 112 to transmit data with multiple different other systems and devices such as OIS 128, radiotherapy device 130, and image acquisition device 132. Furthermore, data generated by OIS 128 and / or image acquisition device 132 can be stored in memory 116, database 124, and / or hospital database 126. Data can be transmitted / received via communication interface 118 through network 120 as needed for access by processor 114.

[0068] Data processing device 112 can communicate with database 124 via network 120 to send / receive various types of data stored on database 124. For example, database 124 may store machine data associated with radiotherapy device 130, image acquisition device 132, or other machines related to radiotherapy. Machine data information may include control points such as beam size, arc placement, beam on and off duration, machine parameters, segmentation, MLC configuration, gantry speed, MRI pulse sequence, etc. Database 124 may be a storage device and may be equipped with appropriate database management software programs. Those skilled in the art will understand that database 124 may include multiple devices located in a centralized or distributed manner.

[0069] In some embodiments, database 124 may include processor-readable storage media (not shown). While the processor-readable storage media in an embodiment may be a single medium, the term "processor-readable storage media" should be considered to include a single or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more sets of computer-executable instructions or data. The term "processor-readable storage media" should also be considered to include any medium capable of storing or encoding instruction sets that are executed by a processor and cause the processor to perform any or more methods of the present disclosure. Therefore, the term "processor-readable storage media" should be considered to include, but is not limited to, solid-state memory, optical media, and magnetic media. For example, a processor-readable storage media may be one or more volatile, non-transitory, or non-volatile tangible computer-readable media.

[0070] Data processor 114 can communicate with database 124 to read images into memory 116 or store images from memory 116 into database 124. For example, database 124 can be configured to store multiple images received from image acquisition device 132 (e.g., 3D MRI, 4D MRI, 2D MRI slice images, CT images, 2D fluorescence fluoroscopy images, X-ray images, raw data from MR or CT scans, Medical Digital Imaging and Communication (DICOM) data, projection images, graphic aperture images, etc.). Database 124 can store data to be used by data processor 114 when executing software program 144 or when creating radiotherapy treatment plan 142. Database 124 can store data generated by trained machine learning patterns such as neural networks, including network parameters constituting the model learned by the network and the resulting prediction data. The data processing device 112 can receive image data, such as medical images 146 (e.g., 2D MRI slice images, CT images, 2D fluorescence fluoroscopy images, X-ray images, 3D MR images, 4D MR images, projection images, graphic aperture images, etc.) from the database 124, the radiotherapy device 130 (e.g., MR-Linac), and / or the image acquisition device 132 to generate a treatment plan 142.

[0071] In one embodiment, the radiotherapy system 100 may include an image acquisition device 132 capable of acquiring medical images of the patient (e.g., MR images, 3D MRI, 2D flow cytometry MRI, 4D volumetric MRI, CT images, cone-beam CT, PET images, functional MR images (e.g., fMRI, DCE-MRI, and diffusion MRI), X-ray images, fluoroscopy images, ultrasound images, radiotherapy field images, SPECT images, etc.). The image acquisition device 132 may be, for example, an MRI imaging device, a CT imaging device, a PET imaging device, an ultrasound device, a fluoroscopy device, a SPECT imaging device, or any other suitable medical imaging device for acquiring one or more medical images of the patient. Images acquired by the image acquisition device 132 may be stored in a database 124 as imaging data and / or test data. By way of example, images acquired by the image acquisition device 132 may also be stored in a memory 116 as medical images 146 by a data processing device 112.

[0072] In one implementation, for example, the image acquisition device 132 may be integrated with the radiotherapy device 130 as a single device. For example, the MR imaging device may be combined with a linear accelerator to form a system known as an "MR-Linac". Such an MR-Linac can be used, for example, to determine the location of a target organ or target tumor within a patient, so as to accurately direct radiotherapy to the predetermined target according to the radiotherapy treatment plan 142.

[0073] Image acquisition device 132 can be configured to acquire one or more images of a patient's anatomy targeting a region of interest (e.g., a target organ, a target tumor, or both). Each image—typically a 2D image or slice—can include one or more parameters (e.g., 2D slice thickness, orientation, and location). In one embodiment, image acquisition device 132 can acquire 2D slices of any orientation. For example, the orientation of a 2D slice can include sagittal orientation, coronal orientation, or axial orientation. Processor 114 can adjust one or more parameters, such as the thickness and / or orientation of the 2D slice, to include the target organ and / or target tumor. In one embodiment, 2D slices can be determined based on information such as 3D MRI volume. For example, in the case of using radiotherapy device 130, such 2D slices can be acquired by image acquisition device 132 "in real time" while the patient is receiving radiotherapy, where "in real time" means acquiring data in at least milliseconds or less.

[0074] The data processing device 112 can generate and store radiotherapy treatment plans 142 for one or more patients. The radiotherapy treatment plan 142 can provide information about the specific radiation dose to be administered to each patient. The radiotherapy treatment plan 142 may also include other radiotherapy information, such as control points, including beam angle, gantry angle, beam intensity, dose histogram-volume information, the number of radiation beams used during treatment, and the dose per beam.

[0075] Data processor 114 can be used with software program 144 such as treatment planning software (e.g., manufactured by Elekta GmbH, Sweden). To generate a radiotherapy treatment plan 142, the data processor 114 can communicate with an image acquisition device 132 (e.g., a CT device, MRI device, PET device, X-ray device, ultrasound device, etc.) to access images of the patient and delineate targets such as tumors. In some embodiments, it may be necessary to delineate one or more OARs, such as the tumor periphery or healthy tissue adjacent to the tumor. Therefore, segmentation of the OAR can be performed when the OAR is close to the target tumor. Additionally, if the target tumor is close to the OAR (e.g., the prostate is close to the bladder and rectum), by segmenting the OAR relative to the tumor, the radiotherapy system 100 can study not only the dose distribution in the target but also the dose distribution in the OAR.

[0076] To depict a target organ or tumor relative to the OAR, medical images of a patient undergoing radiotherapy, such as MR images, CT images, PET images, fMR images, X-ray images, ultrasound images, radiotherapy field images, SPECT images, etc., can be non-invasively acquired using image acquisition device 132 to reveal the internal structure of the body part. Based on information from the medical images, the 3D structure of the relevant anatomical part can be obtained. Furthermore, during treatment planning, many parameters can be considered to achieve a balance between effective treatment of the target tumor (e.g., ensuring the target tumor receives a sufficient radiation dose for effective treatment) and low exposure of the OAR (e.g., ensuring the OAR receives the lowest possible radiation dose). Other parameters that can be considered include the location of the target organ and tumor, the location of the OAR, and the movement of the target relative to the OAR. For example, the 3D structure can be obtained by outlining the target or the OAR within each 2D layer or slice of the MRI or CT image and combining the outlines of each 2D layer or slice. This can be done manually (e.g., by a physician, dosimeter, or healthcare professional using a program such as that manufactured by Elekta GmbH, Sweden). The contour can be generated automatically (e.g., using a program such as ABASTM, an Atlas-based automated segmentation software manufactured by Elekta AG, Sweden). In some implementations, the 3D structure of the target tumor or OAR can be automatically generated using treatment planning software.

[0077] After the target tumor and one or more OARs have been located and mapped, a dosimeter, physician, or healthcare professional can determine the radiation dose to be applied to the target tumor and any maximum dose that can be received by OARs located near the tumor (e.g., left and right parotid glands, optic nerve, eye, lens, inner ear, spinal cord, brainstem, etc.). After the radiation dose has been determined for each anatomical structure (e.g., target tumor, OAR), a process known as inverse planning can be performed to determine one or more treatment planning parameters that will achieve the desired radiation dose distribution. Examples of treatment planning parameters include volume mapping parameters (e.g., those defining the target volume, contour-sensitive structures, etc.), the edges around the target tumor and OARs, beam angle selection, collimator settings, and beam-on time. During the reverse planning process, the physician can define dose constraint parameters that set limits on how much radiation an OAR can receive (e.g., limiting the full dose to the tumor target and zero dose to any OAR; limiting 95% of the dose to the target tumor; limiting the spinal cord, brainstem, and optic nerve structures to ≤45 Gy, ≤55 Gy, and <54 Gy, respectively). The results of the reverse planning can form a radiotherapy treatment plan 142 that can be stored in memory 116 or database 124. Some of these treatment parameters can be related. For example, adjusting one parameter (e.g., weighting for different targets, such as increasing the dose to the target tumor) in an attempt to change the treatment plan may affect at least one other parameter, which in turn may lead to the development of different treatment plans. Therefore, data processing device 112 can generate a customized radiotherapy treatment plan 142 with these parameters so that radiotherapy device 130 can deliver radiotherapy treatment to the patient.

[0078] Additionally, the radiotherapy system 100 may include a display device 134 and a user interface 136. The display device 134 may include one or more displays showing medical images, interface information, treatment planning parameters (e.g., projected images, graphic aperture images, contours, dose, beam angle, etc.), treatment plans, targets, target location and / or target tracking, or any related information to the user. The user interface 136 may be a keyboard, keypad, touchscreen, or any type of device from which the user can input information into the radiotherapy system 100. Alternatively, the display device 134 and user interface 136 may be integrated into a device such as a tablet computer (e.g., an Apple tablet). Lenovo Samsung Devices such as (etc.).

[0079] Furthermore, any and all components of the radiotherapy system 100 can be implemented as virtual machines (e.g., VMware, Hyper-V, etc.). For example, a virtual machine can be software acting as hardware. Therefore, a virtual machine can include at least one or more virtual processors, one or more virtual memories, and one or more virtual communication interfaces that together act as hardware. For example, the data processing device 112, OIS 128, and image acquisition device 132 can be implemented as virtual machines. Given the availability of processing power, memory, and computing power, the entire radiotherapy system 100 can be implemented as a virtual machine.

[0080] Figure 2A An exemplary radiotherapy apparatus 202 is shown, which may include a radiation source (e.g., an X-ray source or linac), a bed 216, an imaging detector 214, and a radiotherapy output 204. The radiotherapy apparatus 202 may be configured to emit a radiation beam 208 to provide treatment to a patient. The radiotherapy output 204 may include one or more attenuators or collimators, such as MLCs. A patient may be positioned in area 212 and supported by the bed 216 to receive a radiation dose according to a radiotherapy treatment plan. The radiotherapy output 204 may be mounted or attached to a frame 206 or other mechanical support. When the bed 216 is inserted into the treatment area, one or more chassis motors (not shown) may rotate the frame 206 and the radiotherapy output 204 about the bed 216. In one embodiment, the frame 206 may rotate continuously about the bed 216 when the bed 216 is inserted into the treatment area. In another embodiment, the frame 206 may rotate to a predetermined position when the bed 216 is inserted into the treatment area. For example, the gantry 206 can be configured to rotate the treatment output 204 about an axis (“A”). Both the bed 216 and the radiotherapy output 204 can be moved independently to other locations around the patient, for example, capable of moving in a lateral direction (“T”), capable of moving in a side direction (“L”), or capable of rotating about one or more other axes, such as about a transverse axis (denoted as “R”). A controller communicatively connected to one or more actuators (not shown) can control the movement or rotation of the bed 216 to properly position the patient inside or outside the radiation beam 208 according to the radiotherapy treatment plan. The ability of both the bed 216 and the gantry 206 to move independently of each other in multiple degrees of freedom allows the patient to be positioned such that the radiation beam 208 can target the tumor. The MLC can be integrated with the gantry 206 to deliver a radiation beam 208 of a specific shape.

[0081] Figure 2AThe coordinate system shown (including axes A, T, and L) may have an origin located at isocenter 210. The isocenter can be defined as the location where the central axis of the radiation beam 208 intersects the origin of the coordinate axes to deliver the prescribed radiation dose to or within the patient. Alternatively, isocenter 210 may be defined as the location where the central axis of the radiation beam 208 intersects the patient for various rotational positions of the radiotherapy output 204 positioned by the gantry 206 about axis A. As discussed herein, while any other axis or combination of axes may be referenced and used to determine the gantry angle, the gantry angle corresponds to the position of the gantry 206 relative to axis A.

[0082] The gantry 206 may have an attached imaging detector 214, which is preferably opposite to the radiotherapy output 204. In one embodiment, the imaging detector 214 may be located within the field of the treatment beam 208. The imaging detector 214 may remain aligned with the treatment beam 208. The imaging detector 214 may rotate about a rotation axis as the gantry 206 rotates. In one embodiment, the imaging detector 214 may be a flat panel detector (e.g., a direct detector or a scintillator detector). In this way, the imaging detector 214 may be used to monitor the treatment beam 208, or it may be used to image the patient's anatomy, such as field imaging. The control circuitry of the radiotherapy apparatus 202 may be integrated within or remote from system 100.

[0083] In the illustrative embodiment, one or more of the bed 216, treatment output 204, or gantry 206 can be automatically positioned, and the treatment output 204 can establish a treatment beam 208 according to a specified dose for a particular treatment delivery instance. The treatment delivery sequence can be specified according to a radiotherapy treatment plan (e.g., using one or more different orientations or positions of the gantry 206, bed 216, or treatment output 204). Treatment deliveries can occur sequentially, but can also cross over at desired treatment sites on or within the patient (e.g., at isocenter 210). This allows a prescribed dose of radiotherapy to be delivered to the treatment site while minimizing or avoiding damage to tissues near the treatment site.

[0084] Figure 2B An exemplary radiotherapy system 202 combining a radiation system (e.g., a linac) and a CT imaging system is shown. The radiotherapy device 202 may include an MLC (not shown). The CT imaging system may include, for example, an imaging X-ray source 218 providing X-ray energy in the kiloelectron volt (keV) energy range. The imaging X-ray source 218 may provide a fan-shaped and / or cone-shaped beam 208 directed at an imaging detector 222, such as a flat panel detector. The radiotherapy device 202 may be similar to the one described above. Figure 2A The described system includes, for example, a radiotherapy output 204, a gantry 206, a bed 216, and another imaging detector 214 (e.g., a flat panel detector). An X-ray source 218 can provide a relatively low-energy X-ray diagnostic beam for imaging.

[0085] like Figure 2B As shown, the radiotherapy output 204 and the X-ray source 218 can be mounted on the same rotating stage 206, rotated 90 degrees apart from each other. In some examples, two or more X-ray sources can be mounted along the periphery of the stage 206, such that each X-ray source has its own detector arrangement to provide diagnostic imaging from multiple angles simultaneously. Similarly, multiple radiotherapy outputs 204 can be provided.

[0086] Figure 3 An exemplary radiotherapy system 300 combining a radiation system (e.g., a linac) and a nuclear MR imaging system is shown. This radiotherapy system 300 is also referred to as an MR linac system. System 300 may include a bed 216, an image acquisition device 320, and a radiation delivery device 330. System 300 delivers radiation therapy to a patient according to a radiotherapy treatment plan (e.g., a treatment plan 142 created and stored in memory 116). In some embodiments, the image acquisition device 320 may correspond to... Figure 1 The image acquisition device 132 is capable of acquiring an image of a first modality (e.g., an MR image) or a target image of a second modality (e.g., a CT image).

[0087] Bed 216 can support the patient during treatment. In some implementations, bed 216 can move along a horizontal translation axis (labeled "I"), allowing bed 216 to move the patient lying on it into and / or out of system 300. Bed 216 can also rotate about a vertical rotation axis transverse to the center of the translation axis. To allow such movement or rotation, bed 216 may have motors (not shown) that enable the bed to move in various directions and rotate along various axes. A controller (not shown) can control these movements or rotations to properly position the patient according to the treatment plan.

[0088] In some embodiments, the image acquisition device 320 may include an MR imaging machine that can acquire 2D or 3D MR images of a patient before, during, and / or after a treatment phase. The image acquisition device 320 may include a magnet 321 for generating a main magnetic field for magnetic resonance imaging. The magnetic field lines generated by the operation of the magnet 321 may extend substantially parallel to the central translation axis "I". The magnet 321 may include one or more coils whose axes extend parallel to the translation axis "I". In some embodiments, one or more coils of the magnet 321 may be spaced apart such that there are no coils in the central window 323 of the magnet 321. In other embodiments, the coils in the magnet 321 may be thin enough or have a reduced density such that the coils are substantially transmissive to radiation of wavelengths generated by the radiotherapy device 330. In some embodiments, the image acquisition device 320 may also include one or more shielding coils that can generate approximately equal amplitude and opposite polarity magnetic fields outside the magnet 321 to eliminate or reduce any magnetic field outside the magnet 321. As described below, the radiation source 331 of the radiotherapy device 330 can be positioned in a region where the magnetic field is at least eliminated to the first order or reduced.

[0089] The image acquisition device 320 may further include two gradient coils 325 and 326, which can generate a gradient magnetic field superimposed on the main magnetic field. The coils 325 and 326 can generate gradients in the resulting magnetic field, which allow for spatial encoding of protons to determine their positions. The gradient coils 325 and 326 can be positioned about a common central axis with respect to the magnet 321 and can be displaced along this central axis. This displacement can create a gap or window between the coils 325 and 326. In embodiments where the magnet 321 includes a central window 323 between the coils, the two windows can be aligned with each other.

[0090] In some embodiments, the image acquisition device 320 may be an imaging device other than MRI, such as X-ray, CT, CBCT, spiral CT, PET, SPECT, optical computed tomography, fluorescence imaging, ultrasound imaging, radiotherapy field imaging devices, etc. As will be appreciated by those skilled in the art, the above description of the image acquisition device 320 relates to certain embodiments and is not intended to be limiting.

[0091] The radiotherapy apparatus 330 may include a radiation source 331 (e.g., an X-ray source or linac) and a collimator, such as an MLC 332. This collimator is a beam limiting device that helps shape the radiation beam exiting the machine and can limit the maximum field size of the beam. The MLC 332 can be used to shape, guide, or modulate the intensity of a radiotherapy beam directed to a designated target site within the patient's body. The MLC 332 may include a metal collimator plate (also referred to as an MLC blade) that slides into position to form the desired field shape. The radiotherapy apparatus 330 may be mounted on a chassis 335. When the bed 216 is inserted into the treatment area, one or more chassis motors (not shown) can rotate the chassis 335 around the bed 216. In one embodiment, the chassis 335 may rotate continuously around the bed 216 when the bed 216 is inserted into the treatment area. The chassis 335 may also have an attached radiation detector (not shown), which is preferably located opposite the radiation source 331 and the rotation axis of the chassis 335 is positioned between the radiation source 331 and the detector. Furthermore, the device 330 may include a control circuitry (not shown) for controlling one or more of, for example, the bed 216, the image acquisition device 320, and the radiotherapy device 330. The control circuitry of the radiotherapy device 330 may be integrated within or located away from the system 300.

[0092] During radiotherapy treatment, the patient can be positioned on bed 216. System 300 can then move bed 216 to the treatment area defined by magnet 321, coils 325 and 326, and chassis 335. The control circuitry system can then control radiation source 331, MLC 332, and chassis motor to deliver radiation to the patient through a window between coils 325 and 326 according to the radiotherapy plan.

[0093] Figures 2A to 2B and Figure 3 The radiotherapy output configurations shown, such as those where the radiotherapy output can rotate about a central axis (e.g., axis "A"), are for illustrative purposes and not for limitation. Other radiotherapy output configurations may be used. For example, the radiotherapy output may be mounted to a manipulator or robotic arm with multiple degrees of freedom. In yet another embodiment, the treatment output may be fixed (e.g., located in an area laterally separated from the patient), and a patient-supporting platform may be used to align the radiotherapy isocenter with a designated target site within the patient.

[0094] Figure 4An example of a dose distribution curve is shown. The dose distribution curve represents the spatial distribution of radiation dose generated by an algorithm, such as a distribution generated by radiotherapy planning software in software program 144. Examples of dose distribution curves may include a percentage depth dose (PDD) distribution curve representing the variation of relative dose with depth or a percentage radial dose (PRD) distribution curve representing the variation of relative dose with radial distance. Measurement can be performed by applying radiation from the radiation machine to a medium simulating human tissue (e.g., a phantom). Figure 4 The PDD shown is an example. In one example, the phantom may include water. The amount of radioactivity deposited (as a function of depth in the medium) can be measured and recorded, for example, using sensors mounted in the medium to provide... Figure 4 The PDD curve is shown. In some examples, in addition to the PDD or PRD distribution curve, the dose distribution curve may include beam model parameter values. Examples of beam model parameters may include the size and location of one or more photon sources within the radiation machine, the maximum energy of the photon spectrum emitted from the radiation machine, a number of factors describing the shape of the photon spectrum emitted from the radiation machine, the size and location of one or more electron sources within the radiation machine, the average energy of the electron spectrum emitted from the radiation machine, or one or more numbers describing how the radiation (e.g., electrons or photons) emitted by the radiation machine varies off-axis, etc.

[0095] Figure 5 This is a diagram illustrating an exemplary architecture of a cloud-based dose verification system 500. System 500 can be configured to determine a sub-dose distribution profile and use it to verify a master dose distribution profile generated by a TPS (Transmission Positioning System) of a radiotherapy system such as system 202 or system 300. The sub-dose distribution profile can be determined independently of the TPS used to determine the master dose distribution profile. System 500 may include multiple access points for multiple clients 510, one or more gateways 520, and a cloud-based computing device or networking device 530 (also referred to as a cloud server or simply the "cloud") configured to provide a range of cloud-based services including dose assessment and verification.

[0096] One or more clients 510 (or “occupiers”) are devices that may be located in different hospitals or clinical facilities. Examples of clients 510 may include computers, tablets, or mobile devices (e.g., mobile phones). Clients may subscribe to one or more cloud services provided by cloud 530 and securely connect to cloud 530 via an internet connection (e.g., Ethernet or a wireless connection such as WiFi or a cellular network). Image information obtained from patient 501, such as image information generated by a radiotherapy system (e.g., an MR linac) in a hospital or clinical facility, may be input to client 510. Patient image data may include digital images of the radiotherapy target of the object, which may include computed tomography (CT) images, synthetic CT images, or magnetic resonance (MR) images, etc. Machine information, such as one or more machine parameters (also referred to as “control points”) of the radiotherapy machine that generated the patient image information, may also be provided to client 510. Examples of machine parameters may include the linac gantry angle, the shape of the beam aperture through which the therapeutic radiation beam is projected onto the target, and the intensity of the beam or one or more parameters associated with the delivery of electron or particle therapy, etc.

[0097] In one example, patient image information and machine information can be formatted into a patient file according to specific standards such as the Medical Digital Imaging and Communication (DICOM) standard. Such a patient file is referred to as a DICOM file in this document. A DICOM file stores metadata including patient image information and machine parameters. Patient image information may include image type, image pixel data, image location, image orientation, image plane pixel spacing, pixel aspect ratio, pixel position, and photometric interpretation. In one example, a DICOM file may store a set of images taken at different gantry angles, allowing radiation beams to be delivered to the target tumor and OAR from different directions. Machine parameters include parameters characterizing the configuration and operating status of the radiation machine (i.e., “control points”) and the treatment plan using the machine, such as beam number, beam name, beam description, beam type, beam intensity, beam limiting device type, gantry angle, gantry rotation direction, blade / jaw position, aperture weight or intensity, beam angle selection, collimator setting, or beam on-time, etc. DICOM files may additionally include structural information, such as the patient's anatomical structures of interest, volumetric delineation parameters defining the target volume, contour-sensitive structures, or the edges surrounding the target tumor and the oAR. Treatment planning information stored in the DICOM file may also include dose information, which may include master dose distribution curves (e.g., one or more dose measures or dose statistics).

[0098] Client 510 can establish communication with cloud 530 and, after authentication, upload the patient DICOM file to the cloud, for example, for storage and maintenance on a cloud storage device. To save communication bandwidth and improve communication and storage efficiency, the DICOM file can be compressed before transmission and storage. Compression can be lossy or lossless. Examples of compression algorithms can include predictive coding, arithmetic coding, Huffman coding, adaptive Lempel-Ziv-Welch algorithm, chained coding, transform coding, fractal compression, etc. For confidentiality and compliance requirements, data encryption can be performed on the patient DICOM file before data transmission and storage. Additionally or alternatively, client device 510 can use a subscribed DICOM service provided by cloud 530 to extract one or more of image information, machine information, or treatment plan information from the DICOM file. See below for examples. Figure 6 Examples of cloud storage devices and cloud-based services such as DICOM services are discussed.

[0099] Communication between client 510 and cloud 530 can follow Transmission Control Protocol / Internet Protocol (TCP / IP), Wi-Fi Protected Access Security Protocol, 3G or 4G cellular network protocols, Long Term Evolution (LTE), or other wireless network protocols. Other network topologies and arrangements can be used, as those skilled in the art will understand. Figure 5 In the example shown, client 510 can communicate with cloud 530 via gateway 520. Gateway 520 may include multiple devices forming an asset group, such as multiple routers. Gateway 520 may support one or more communication protocols to control and monitor data flow between client 510 and cloud 530, such as Internet Protocol via Ethernet or wireless networks (e.g., WiFi or cellular networks). In some examples, gateway 520 may include a computer or computer program configured to perform specific tasks such as data aggregation, identification, security, data buffering, alerting, gateway analysis, monitoring service connections, etc. In one example, when multiple clients access cloud services simultaneously, gateway 520 can monitor and control traffic between client 510 and cloud 530.

[0100] The Cloud 530 may include servers or web servers configured to perform the following functions: store and manage data uploaded by one or more clients (e.g., patient DICOM files or parsed DICOM data); run applications such as subdose checks and dose validation against master dose distribution curves generated by different TPS systems; or deliver content (e.g., validated dose distribution curves) to one or more ordering clients. Access policies or whitelists can be used to update the Cloud 530. In some examples, the Cloud 530 may be a local cloud. The Cloud 530 may have a scalable infrastructure supporting services such as the storage and processing of imaging data (e.g., DICOM files). See below for examples. Figure 6 This section discusses examples of Cloud 530 and the various services hosted on Cloud 530.

[0101] System users (e.g., radiation oncologists, medical physicists, or healthcare professionals) can use client 510 to access cloud 130. Client 510 may be equipped with a web browser for accessing the web server via Hypertext Transfer Protocol (HTTP) or an encrypted communication protocol (e.g., Hypertext Transfer Protocol for Secure Communication (HTTPS)). In one example, after necessary user authentication (e.g., account ID, password, bearer token, etc.), the user can query cloud 130 (or a portion thereof, such as a patient database or service) for information such as subdose distribution curves, dose verification results, etc. Client 510 may include applications, software programs, or visualization tools that present subdose checks and dose verification results to the user, for example, by displaying them on a screen of the user interface. This information may be presented in the form of tables, charts, graphs, or interactive dashboards and may include both text and graphical content. Hard copies of such information may be printed. The information presented to the user may also include machine information and patient image information extracted from patient DICOM files.

[0102] Client 510 can generate alert notifications to warn user 501 about unverified dose distribution curves, such as inconsistencies between the primary dose distribution curve generated by the radiotherapy system's TPS and the secondary dose distribution curves independently calculated by the dose engine application in cloud 530. Alert notifications can be sent via email, text, or "instant" messages (e.g., Short Message Service (SMS), web page updates, telephone or pager calls, etc.). In some examples, alert notifications are triggered only when specific alert conditions are met. Upon receiving an alert notification, the user can view the alert, interpret the results (e.g., secondary dose distribution curves), and take actions such as performing further dose testing (automatic or manual dose checks) or adjusting the dose engine application in cloud 530.

[0103] Parts of the dose verification system 500 can be implemented using hardware, software, firmware, or a combination thereof. In one example, at least a portion of the dose verification system 500 can be implemented using dedicated circuitry that can be constructed or configured to perform one or more specific functions, or using general-purpose circuitry that can be programmed or otherwise configured to perform one or more specific functions. Such general-purpose circuitry may include a microprocessor or a portion thereof, a microcontroller or a portion thereof, or programmable logic circuitry, memory circuitry, network interfaces, and various components for interconnecting these components. For example, among others, a "comparator" may include an electronic circuit comparator that can be constructed to perform a specific function of comparing two signals, or a comparator that can be implemented as part of a general-purpose circuitry driven by code instructing a portion of the general-purpose circuitry to perform a comparison between two signals.

[0104] Figure 6 This is a block diagram illustrating an exemplary cloud server 600 configured to provide data storage and a range of cloud-based services, including dose verification. The cloud server 600 can be physical or virtual infrastructure. Figure 5 An implementation of at least a portion of the cloud 530 shown may include a file service 610, a dose engine service 620, and a dose assessment service 630. The file service 610 manages patient files received from one or more clients 510. Each patient file may contain patient image information and information about the radiation machine. In one example, the patient file includes a patient DICOM file. (Refer to the above...) Figure 5 The file service 610 discussed may include a DICOM service 612, which is configured to use a parser application to parse DICOM files and extract various types of information from them, including one or more of patient image information, machine information, dosage information, structural information, and treatment plan information. The file service 610 may include a data storage device 614 for storing patient DICOM files or parsed DICOM information received from multiple users 510.

[0105] In some examples, the DICOM file received from client 510 and stored in data storage device 614 is a compressed and / or encrypted DICOM file. The DICOM service may include applications for decompressing and / or decrypting the stored DICOM file before parsing and extracting information from it.

[0106] File service 610 may include an occupant management service 616 configured to manage service requests from multiple clients 510. Occupant management service 616 may dynamically allocate physical and virtual resources to handle service requests from one or more clients. In one example, occupant management service 616 may queue clients and their service requests based on computing and storage resources at cloud server 600, the amount of data processed per client request, the type of service requested, and quality of service (QoS) requirements imposed by each client. Dynamic allocation of physical or virtual resources may include distributed computing across multiple networked computing devices that collaboratively perform a specific computational task, such as performing DICOM file parsing, subdose checking, or dose verification for DICOM files provided by clients. Additionally or alternatively, dynamic allocation of system resources may include (e.g., in a cloud server) parallel computing across multiple processors that simultaneously perform multiple tasks for different clients, such as DICOM file parsing, subdose checking, or dose verification services associated with DICOM files uploaded by different clients. Dynamic allocation of physical or virtual resources, including distributed computing and / or parallel computing, can help improve the efficiency of multi-occupancy management and the quality of service to meet the needs of different clients.

[0107] The dosing engine service 620 may include a subdose checker 622, which is configured to generate a subdose distribution curve using parsed DICOM information (e.g., one or more of patient image information, machine parameters, or treatment plan parameters). In one example, patient images uploaded to and stored in a cloud storage device include grayscale CT or MR images. The dosing engine service 620 can retrieve grayscale images, and the image data calibrator 626 can calibrate the grayscale images by converting pixel data to mass density data. For example, the image data calibrator 626 can use a pre-generated lookup table or formula to convert CT numbers (which represent the X-ray absorption coefficients of image pixels, expressed in Hornsfield units) in CT images into relative electron density (ED) data or mass density (MD) data. The subdose checker 622 can then use the converted ED or MD data of the patient images to generate a subdose distribution curve.

[0108] The auxiliary dose checker 622 can use dose algorithm 624 to calculate sub-dose distribution curves. In one example, the cloud server 600 can provide an integration interface that allows users to upload one or more different dose algorithms, and the sub-dose checker 622 can use the corresponding dose algorithm to calculate one or more sub-dose distribution curves.

[0109] In one example, the dosage algorithm 624 could be derived from a radiotherapy system, such as... The commercial algorithms used by Elekta Inc. The implementation of such commercial algorithms in the dosing engine service 620 may differ from their corresponding commercial algorithm implementations. In some examples, the dosing algorithm 624 may differ from the commercial algorithm used by a radiotherapy system.

[0110] The dose algorithm 624 (hereinafter referred to as the "sub-dose algorithm") may differ from the algorithm used by the radiation machine to calculate the main dose distribution curve (hereinafter referred to as the "main dose algorithm"). The resulting sub-dose distribution curve may differ from the main dose distribution curve and can therefore be used to verify the accuracy of the main dose distribution curve. In one example, the sub-dose algorithm may be a more complex algorithm than the main dose algorithm. In another example, the main dose algorithm and the sub-dose algorithm are different implementations of the same dose calculation method, for example, implementations done by different manufacturers or suppliers. As an example and not a limitation, the main dose algorithm is a pencil beam algorithm implemented in the TPS of the radiotherapy system, and the user can choose the Monte Carlo algorithm from the implemented algorithms, or upload and integrate the Monte Carlo algorithm into the cloud. The Monte Carlo algorithm can more accurately simulate particle motion and can be used as a sub-dose algorithm for dose verification. Alternatively, the sub-dose algorithm may be an implementation of a pencil beam algorithm different from the implementation in the TPS of the radiotherapy system.

[0111] In one example, information about the identified primary dose algorithm can be presented to the user, for instance, via the user interface of client device 510. The user is prompted to upload a secondary dose algorithm, which may be different from the primary dose algorithm or may be a different implementation of the primary dose algorithm. In some examples, dose algorithm 624 may include implementations of multiple candidate dose algorithms. The user can select a secondary dose algorithm from the multiple candidate dose algorithms via the user interface. If no candidate algorithm is selected, the user can upload a secondary dose algorithm and integrate it into dose algorithm 624.

[0112] The dose assessment service 630 can compare, for example, a secondary dose distribution curve generated by the dose engine service 620 with a primary dose distribution curve. The dose assessment service 630 can generate a consistency metric 632 between the primary and secondary dose distribution curves. In one example, the dose consistency metric 632 can include the relative difference between a primary dose metric extracted from a patient DICOM file and a secondary dose metric generated by the secondary dose checker 622. The primary and secondary dose metrics can be of the same type. Examples of dose metrics can include one or more of the following: maximum dose, minimum dose, dose range, coverage area (e.g., the contour of coverage), 3D dose distribution, dose volume histogram (DVH), or overlap volume histogram (OVH). If the dose consistency metric 632 meets certain conditions, such as falling below a threshold or falling within a specified range, the assessment service 630 can determine that the primary dose distribution curve is validated. The validated dose distribution curve can be used, for example, to generate a treatment plan using a bundle model stored in a cloud server 600. In one example, the cloud server 600 can provide an integrated interface that allows users to upload beam models and apply the beam models to validated dose distribution curves to generate treatment plans.

[0113] Dose validation results, optionally such as subdose check results of subdose distribution curves, treatment plans generated based on validated dose distribution curves, and other calculation results generated by the cloud service, can be obtained from an authenticated client 510. Figure 5 The communication links shown are used for access and are presented to the user, for example, displayed on the screen of the user interface.

[0114] In various examples, cloud server 600 may include multiple networked computing devices that work collaboratively to fulfill client requests for various cloud services, such as parsing DICOM files, generating subdose distribution curves, or generating dose validation results. In one example, a network of multiple computers may process DICOM files via parallel computing and simultaneously validate doses for multiple patients, or analyze patient DICOM files and extract images corresponding to different bench angles and simultaneously validate doses based on multiple images.

[0115] Figure 7 This is a flowchart illustrating an exemplary method 700 for validating a dose distribution curve using cloud services such as those provided by cloud 530 or cloud server 600. The dose distribution curve to be validated—also referred to as the “master dose distribution curve”—can be generated by a TPS system of a radiotherapy system such as system 202 or system 300. In one example, method 700 can be implemented and executed in a dose validation system 500.

[0116] Method 700 begins at 710, where one or more patient files can be uploaded to a cloud-based computing or networked device, such as cloud 530 or 600, each containing image information and machine information generated by a radiation machine. In one example, the patient file may include a DICOM file obtained from the patient by a radiation machine in a hospital or clinical facility. Each DICOM file stores metadata, including patient image information and machine parameters. The patient image information may include digital images of the object's radiation therapy target, such as computed tomography (CT) images, synthetic CT images, or magnetic resonance (MR) images. The machine information includes information about the structure, configuration, and operating status of the radiation machine, such as one or more machine parameters (also referred to as "control points") of the radiation machine that generated the patient image information. The DICOM file may additionally include treatment planning information, such as a master dose distribution curve generated by a TPS (e.g., one or more dose metrics or dose statistics). In some examples, the DICOM file may store multiple images of the patient generated at different gantry angles, along with machine parameters, treatment planning parameters, and master dose metrics and statistics.

[0117] DICOM files can be uploaded to the cloud via client devices such as client 510. Clients can securely connect to the cloud via an internet connection (e.g., Ethernet, or a wireless connection such as WiFi or cellular network) and subscribe to one or more cloud services. At 720, after necessary user authentication, the client can request a cloud service (e.g., file service 610 provided by cloud server 600) to parse the patient file to extract image information, machine information, and treatment plan information. In one example, multiple images corresponding to different gantry angles can be extracted from the DICOM file. When multiple clients simultaneously request cloud services, clients and their service requests can be scheduled, for example, based on computing and storage resources, the amount of data requested by each client, the type of service requested, and the Quality of Service (QoS) requirements imposed by each client. In one example, client management can include dynamically allocating physical and virtual resources to each requesting client, or using distributed or parallel computing to improve the efficiency and QoS of multi-occupancy management to meet the needs of different clients.

[0118] At point 730, one or more of the following can be used to determine the subdose distribution curve: for example, patient image information obtained from a parsed DICOM file, machine parameters, or treatment plan parameters. A dosing algorithm (also known as a subdose algorithm) can be applied to the patient and machine information to calculate the subdose distribution curve. The subdose algorithm, which can be uploaded to the cloud by the user via an integration interface, can be a commercial dosing algorithm. Alternatively, the subdose algorithm can differ from a commercial dosing algorithm.

[0119] The secondary dose algorithm can differ from the dose algorithm (also known as the primary dose algorithm) used by the radiation machine to calculate the primary dose distribution curve. In one example, the primary dose algorithm and the secondary dose algorithm are different implementations of the same dose calculation method. In one example, a user can upload the secondary dose algorithm to the cloud. In another example, a user can select a secondary dose algorithm from multiple candidate dose algorithms implemented in the cloud via a user interface. If no candidate algorithm is selected, the user can upload the secondary dose algorithm. Examples of dose distribution curves can include a percentage depth dose (PDD) distribution representing the change of relative dose with depth, or a percentage radial dose (PRD) distribution representing the change of relative dose with radial distance, beam model parameter values, dose volume histograms, overlap volume histograms, or three-dimensional dose distributions, etc.

[0120] At 740, the secondary dose distribution curve determined at 730 is compared with the primary dose distribution curve generated by the radiation machine's TPS, and a consistency metric between the primary and secondary dose distribution curves can be generated, for example, using dose assessment service 630. In one example, the dose consistency metric may include the relative difference between the primary dose metric (obtained from the primary dose distribution curve) and the secondary dose metric (obtained from the secondary dose distribution curve). The primary and secondary dose metrics can be of the same type. If the dose consistency metric meets specific conditions, such as decreasing below a threshold or falling within a specified range, the assessment service can determine that the primary dose distribution curve is validated.

[0121] At point 750, a dose verification indicator can be generated. The dose verification results, optionally such as sub-dose check results of the sub-dose distribution curve and other calculation results generated by the cloud service, can be accessed by an authenticated client and presented to the user, for example, displayed on the user interface screen. If the difference between the primary dose metric and the sub-dose metric exceeds a threshold, an alert notification can be generated, for example, on the client side to warn the user of an unverified dose distribution curve. The user can then take actions such as performing further dose testing (automatic or manual dose checks) or adjusting the dose engine service in the cloud. The verified dose distribution curve, along with other information, can be presented to the user. In some examples, the verified dose distribution curve can be used, for example, to generate a treatment plan using a bundle model.

[0122] Figure 8A block diagram illustrating an embodiment of machine 800 on which one or more of the methods discussed herein may be implemented. In one or more embodiments, one or more of the data processing apparatus 112 may be implemented by machine 800. In alternative embodiments, machine 800 may operate as a standalone device or may be connected (e.g., networked) to other machines. In one or more embodiments, data processing apparatus 112 may include one or more of the items of machine 800. In a networked deployment, machine 800 may operate as a server or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, network device, network router, switch, or bridge, or any machine capable of executing instructions (sequentially or otherwise) specifying actions to be taken by the machine. Furthermore, although only a single machine is shown, the term "machine" should also be understood to include any set of machines that individually or collectively execute a set (or more sets) of instructions to perform any or more of the methods discussed herein.

[0123] Example machine 800 includes a processing circuitry system 802 (e.g., a central processing unit (CPU), graphics processing unit (GPU), application-specific integrated circuit, circuitry system (e.g., one or more transistors, resistors, capacitors, inductors, diodes, logic gates, multiplexers, buffers, modulators, demodulators, radios (e.g., radio transmitters or receivers)), a sensor 821 (e.g., a transducer that converts one form of energy (e.g., light, heat, electricity, mechanical, or other energy) into another form of energy) or combinations thereof), a main memory 804, and a static memory 806, which communicate with each other via a bus 808. Machine 800 (e.g., a computer system) may also include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The machine 800 also includes an alphanumeric input device 812 (e.g., a keyboard), a user interface (UI) navigation device 814 (e.g., a mouse), a disk drive or mass storage unit 816, a signal generation device 818 (e.g., a speaker), and a network interface device 820.

[0124] Disk drive unit 816 includes a machine-readable medium 822 on which one or more sets of instructions and data structures (e.g., software) 824 are stored, which embody or be utilized by any one or more of the methods or functions described herein. During execution of the instructions 824 by machine 800, the instructions 824 may also reside wholly or at least partially in main memory 804 and / or in processor 802, which also constitute the machine-readable medium.

[0125] As shown, machine 800 includes an output controller 828. The output controller 828 manages the data flow to / from machine 800. The output controller 828 is sometimes referred to as a device controller, and the software that interacts directly with the output controller 828 is referred to as a device driver.

[0126] Although in one embodiment the machine-readable medium 822 is shown as a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more instructions or data structures. The term "machine-readable medium" should also be considered to include any tangible medium capable of storing, encoding, or carrying instructions or data structures that are executed by a machine and cause the machine to perform any one or more of the methods of the present invention, and that these data structures are utilized by or associated with such instructions. Therefore, the term "machine-readable medium" should be considered to include, but is not limited to, solid-state memory, as well as optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, which by way of example includes: semiconductor memory devices, such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0127] Instructions 824 can also be sent or received via communication network 826 using a transmission medium. Instructions 824 can be sent using network interface device 820 and any of many well-known transmission protocols, such as HTTP. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet, mobile phone networks, common-use telephone (POTS) networks, and wireless data networks (such as WiFi and WiMax networks). The term “transmission medium” should be considered to include any intangible medium capable of storing, encoding, or carrying instructions executed by a machine and comprising digital or analog communication signals, or other intangible media facilitating communication of such software.

[0128] As used in this article, “coupled in communication between” means that entities on either side of the coupling must communicate through an item between them, and that these entities cannot communicate with each other without communicating through that item.

[0129] Additional notes

[0130] The above detailed description includes reference to the accompanying drawings, which form part of the detailed description. The drawings illustrate specific embodiments by way of illustration rather than limitation, in which the present disclosure may be practiced. These embodiments are also referred to herein as “examples.” These examples may include elements other than those shown or described. However, the inventors also contemplate providing examples that only include those elements shown or described. Furthermore, the inventors contemplate examples of any combination or substitution of those elements (or one or more aspects thereof) with respect to a particular example (or one or more aspects thereof) or to other examples (or one or more aspects thereof) shown or described herein.

[0131] All publications, patents, and patent documents referenced in this document are incorporated herein by reference in their entirety as if they were individually incorporated by reference. In the event of any inconsistency between the usage in this document and those incorporated by reference, the usage in one or more incorporated references shall be considered supplementary to the usage in this document; in the event of any inconsistency, the usage in this document shall prevail.

[0132] In this document, when describing various aspects of this disclosure or elements in its embodiments, the terms “a,” “an,” “the,” and “the” are used, as is common in patent literature, to include one or more elements, independent of any other instance or usage of “at least one” or “one or more.” In this document, the term “or” is used to indicate non-exclusivity, or such that, unless otherwise stated, “A or B” includes “A but not B,” “B but not A,” and “A and B.”

[0133] In the appended claims, the terms “including” and “in which” are used as common English equivalents to the corresponding terms “comprising” and “wherein”. Furthermore, in the appended claims, the terms “comprising,” “including,” and “having” are intended to be open-ended, meaning that there may be other elements besides those listed, such that anything following such terms in the claims (e.g., “comprising,” “including,” “having”) is still considered to be within the scope of the claims. Additionally, in the appended claims, the terms “first,” “second,” and “third,” etc., are used merely as designations and are not intended to impose numerical requirements on their objects.

[0134] Embodiments of this disclosure can be implemented using computer-executable instructions. Computer-executable instructions (e.g., software code) can be organized into one or more computer-executable components or modules. Various aspects of this disclosure can be implemented using any number of such components or modules and any organization of such components or modules. For example, various aspects of this disclosure are not limited to the specific computer-executable instructions or specific components or modules shown in the accompanying drawings and described herein. Other embodiments of this disclosure may include different computer-executable instructions or components having more or fewer functions than those shown and described herein.

[0135] The method examples (e.g., operations and functions) described herein may be implemented at least in part by a machine or computer (e.g., implemented as software code or instructions). Some examples may include a computer-readable or machine-readable medium encoded with instructions operable to configure electronic devices to perform the methods described in the examples above. Implementations of such methods may include software code such as microcode, assembly language code, high-level language code, etc. (e.g., “source code”). Such software code may include computer-readable instructions (e.g., “object” or “executable code”) for performing various methods. Software code may form part of a computer program product. Software implementations of the embodiments described herein may be provided via an article of art on which code or instructions are stored, or via a method of operating a communication interface to transmit data via a communication interface (e.g., wirelessly, via the Internet, via satellite communication, etc.).

[0136] Furthermore, software code can be tangibly stored on one or more volatile or non-volatile computer-readable storage media during execution or at other times. These computer-readable storage media can include any means of storing information in a form accessible by a machine (e.g., a computing device, electronic system, etc.), such as, but not limited to, floppy disks, hard disks, removable disks, any form of disk storage media, CD-ROMs, magneto-optical disks, removable optical disks (e.g., compressed optical disks and digital video disks), flash memory devices, magnetic tape cassettes, memory cards or memory sticks (e.g., secure digital cards), RAM (e.g., CMOS RAM), recordable / non-recordable media (e.g., read-only memory (ROM)), EPROMs, EEPROMs, or any type of media suitable for storing electronic instructions. Such computer-readable storage media are coupled to a computer system bus so that they can be accessed by the processor and other parts of the OIS.

[0137] In one implementation, the computer-readable storage medium may have encoded a data structure for treatment planning, wherein the treatment plan may be adaptive. The data structure for the computer-readable storage medium may be at least one of the following: Medical Digital Imaging and Communication (DICOM) format, extended DICOM format, XML format, etc. DICOM is an international communication standard that defines a format for transmitting medical image-related data between various types of medical devices. DICOMRT refers to a radiotherapy-specific communication standard.

[0138] In various embodiments of this disclosure, the methods for creating components or modules can be implemented in software, hardware, or a combination thereof. For example, the methods provided by the various embodiments of this disclosure can be implemented in software using standard programming languages ​​such as, for example, C, C++, Java, Python, and combinations thereof. As used herein, the terms “software” and “firmware” are interchangeable and include any computer program stored in memory for execution by a computer.

[0139] A communication interface includes any mechanism that interfaces with any of hardwired media, wireless media, optical media, etc., to communicate with another device, such as a memory bus interface, processor bus interface, Internet connection, disk controller, etc. A communication interface can be configured by providing configuration parameters and / or sending signals to prepare it to provide data signals describing the software content. A communication interface can be accessed by one or more commands or signals sent to it.

[0140] This disclosure also relates to systems for performing the operations described herein. Such systems may be specifically constructed for a desired purpose or may include general-purpose computers that are selectively activated or reconfigured by computer programs stored in a computer. Unless otherwise stated, the order in which operations are run or performed in the embodiments of this disclosure shown and described herein is not mandatory. That is, operations may be performed in any order unless otherwise stated, and embodiments of this disclosure may include additional or fewer operations compared to those disclosed herein. For example, it is contemplated that running or performing a particular operation before, simultaneously with, or after another operation falls within the scope of various aspects of this disclosure.

[0141] In view of the foregoing, it will be seen that several objectives of this disclosure have been achieved and other advantageous results have been obtained. Various aspects of this disclosure have been described in detail, and it will be apparent that modifications and variations are possible without departing from the scope of the various aspects of this disclosure as defined in the appended claims. Since various changes can be made to the above-described constructions, products, and methods without departing from the scope of the various aspects of this disclosure, it is intended that all content contained in the foregoing description and shown in the accompanying drawings be interpreted as illustrative and not restrictive.

[0142] The above description is intended to be illustrative and not restrictive. For example, the examples above (or one or more aspects thereof) may be used in combination with each other. Furthermore, many modifications may be made to adapt a particular situation or material to the teachings of this disclosure without departing from the scope of this disclosure. While the dimensions and types of materials and coatings described herein are intended to define the parameters of this disclosure, they are by no means limiting but rather exemplary embodiments. Many other embodiments will become apparent to those skilled in the art upon review of the above description. Therefore, the scope of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

[0143] Furthermore, in the above-described embodiments, various features may be combined to simplify this disclosure. This should not be construed as an intention that an unintended disclosed feature is necessary for any of the claims. Rather, the subject matter of the invention may lie in fewer than all features of the particular disclosed embodiment. Therefore, the appended claims are thus incorporated into the embodiments, wherein each claim is considered an independent embodiment. The scope of this disclosure should be determined with reference to the appended claims and the full scope of their equivalents. Furthermore, the limitations of the appended claims are not written in the form of means plus function, and are not intended to be interpreted based on paragraph 6 of 35 U.S.SC §112, unless such a claim expressly uses the phrase “means for…” followed by a functional statement without further structural details.

[0144] An abstract is provided to comply with 37 C. FR § 1.72(b) to allow the reader to quickly determine the substance of the technical disclosure. It should be understood at the time of submission that it will not be used to interpret or limit the scope or meaning of the claims.

Claims

1. A system for validating a primary radiation dose distribution curve, the primary radiation dose distribution curve being generated by a radiation machine to deliver radiation therapy to a subject, the system comprising: The radiation machine is configured to generate the main radiation dose distribution curve using a main dose algorithm; A cloud computing device is configured to provide cloud-based services, the cloud-based services including: The file service receives image information of the object generated by the radiation machine, information about the radiation machine, and the main radiation dose distribution curve. The dose engine service determines a secondary radiation dose distribution curve independent of the primary radiation dose distribution curve by applying a secondary dose algorithm, different from the primary dose algorithm, to the received image information and the radiation machine information; and A dose assessment service uses the secondary radiation dose distribution curve to verify the primary radiation dose distribution curve, including generating a dose consistency metric between the primary and secondary radiation dose distribution curves; determining that the primary radiation dose distribution curve is verified when the dose consistency metric meets verification conditions including a decrease below a threshold or within a specified range; and generating an alarm indication of an unverified dose distribution curve when the verification conditions are not met. The user interface is configured to enable clients to access one or more of the cloud-based services via a communication network and to output verification of the main radiation dose distribution curve to the user or a process executed by the cloud computing device.

2. The system according to claim 1, wherein, The file service is configured to receive the object's DICOM file and parse the received DICOM file to extract the image information and the radiation machine information from the received DICOM file.

3. The system according to claim 2, wherein, The file service is configured to extract treatment plan information from a parsed DICOM file, the treatment plan information including the main radiation dose distribution curve.

4. The system according to claim 2 or 3, wherein, The DICOM file is a compressed DICOM file or an encrypted DICOM file, and the file service is configured to: decompress or decrypt the DICOM file, and parse the decompressed or decrypted DICOM file.

5. The system according to claim 2 or 3 further includes a cloud storage device configured to store the DICOM file of the object or the image information and the radiation machine information extracted from the DICOM file.

6. The system according to any one of claims 1 to 3, wherein, The radiation machine information received by the file service includes one or more radiation beam parameters or one or more gantry parameters.

7. The system according to claim 1, wherein, The user interface is configured to: receive user input for the subdose algorithm; or receive user selection of the subdose algorithm from a plurality of candidate dose algorithms.

8. The system according to claim 1, wherein, The secondary dose algorithm is a Monte Carlo-based dose algorithm, and the primary dose algorithm is a deterministic dose calculation model that differs from the Monte Carlo-based dose algorithm.

9. The system according to any one of claims 1 to 3 and 7 to 8, wherein, The cloud computing device includes an access point configured to support simultaneous access to the cloud-based service by two or more clients.

10. The system according to claim 9, wherein, The cloud-based service also includes an occupant management service configured to queue service requests from the two or more clients.

11. The system according to any one of claims 1 to 3, 7 to 8 and 10, wherein, The cloud computing device is configured to generate a radiotherapy plan for the subject using a beam model based on the validation of the main radiation dose distribution curve.

12. A method for validating a master radiation dose distribution curve, the master radiation dose distribution curve being generated by a radiation machine to deliver radiation therapy to a subject, the radiation machine being configured to generate the master radiation dose distribution curve using a master dose algorithm, the method comprising: Via cloud computing devices: Receive the DICOM file of the object; The received DICOM file is parsed, and image information, information about the radiation machine, and the main radiation dose distribution curve are extracted from the received DICOM file. By applying a secondary dose algorithm, different from the primary dose algorithm, to the image information and the machine information, a secondary radiation dose distribution curve independent of the primary radiation dose distribution curve is determined; as well as Using the secondary radiation dose distribution curve to verify the primary radiation dose distribution curve includes generating a dose consistency metric between the primary radiation dose distribution curve and the secondary radiation dose distribution curve; determining that the primary radiation dose distribution curve is verified when the dose consistency metric meets verification conditions including a decrease below a threshold or within a specified range; and generating an alarm indication of an unverified dose distribution curve when the verification conditions are not met.

13. The method of claim 12, comprising: Receive user input for the subdose algorithm; Alternatively, it may receive a user selection of the sub-dose algorithm from a plurality of candidate dose algorithms.

14. The method according to claim 12, wherein, The secondary dose algorithm is a Monte Carlo-based dose algorithm, and the primary dose algorithm is a deterministic dose calculation model that differs from the Monte Carlo-based dose algorithm.

15. The method of claim 14, comprising: Service requests from two or more clients simultaneously accessing a cloud-based service are queued.

16. The method according to any one of claims 12 to 15, comprising: A radiotherapy plan for the subject is generated using a beam model based on the validation of the main radiation dose distribution curve.

17. A non-transitory machine-readable storage medium comprising instructions that, when executed by one or more processors of a machine, cause the machine to perform the following operations: Receive the DICOM file of the object, which is generated by the radiation machine for use in providing radiation therapy to the object; The received DICOM file is parsed, and image information, information about the radiation machine, and the main radiation dose distribution curve are extracted from the received DICOM file. A secondary radiation dose distribution curve, independent of the primary radiation dose distribution curve, is determined by applying a secondary dose algorithm, different from the primary dose algorithm used by the radiation machine to generate the primary radiation dose distribution curve, to the image information and the machine information. as well as Using the secondary radiation dose distribution curve to verify the primary radiation dose distribution curve includes generating a dose consistency metric between the primary radiation dose distribution curve and the secondary radiation dose distribution curve; determining that the primary radiation dose distribution curve is verified when the dose consistency metric meets verification conditions including a decrease below a threshold or within a specified range; and generating an alarm indication of an unverified dose distribution curve when the verification conditions are not met.

18. The non-transitory machine-readable storage medium according to claim 17, wherein, The operation includes: receiving user input for the subdose algorithm; or receiving user selection of the subdose algorithm from a plurality of candidate dose algorithms.

19. The non-transitory machine-readable storage medium according to claim 17, wherein, The secondary dose algorithm is a Monte Carlo-based dose algorithm, and the primary dose algorithm is a deterministic dose calculation model that differs from the Monte Carlo-based dose algorithm.

20. The non-transitory machine-readable storage medium according to claim 19, wherein, The operation includes queuing service requests from two or more clients that are simultaneously accessing the cloud-based service.

21. The non-transitory machine-readable storage medium according to claim 19 or 20, wherein, The operation includes generating a radiotherapy plan using a beam model based on the validation of the main radiation dose distribution curve.

Images