NL2011393C2 - Radiation therapy treatment planning system. - Google Patents
Radiation therapy treatment planning system. Download PDFInfo
- Publication number
- NL2011393C2 NL2011393C2 NL2011393A NL2011393A NL2011393C2 NL 2011393 C2 NL2011393 C2 NL 2011393C2 NL 2011393 A NL2011393 A NL 2011393A NL 2011393 A NL2011393 A NL 2011393A NL 2011393 C2 NL2011393 C2 NL 2011393C2
- Authority
- NL
- Netherlands
- Prior art keywords
- script
- execution
- scms
- server
- program
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
Landscapes
- Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Biomedical Technology (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Radiation-Therapy Devices (AREA)
Description
Radiation therapy treatment planning system Field of the invention
The invention relates to radiation therapy planning, and, in particular, though not exclusively, to methods and systems for radiation therapy treatment planning, a radiation therapy treatment planning system, a database server for use with such radiation therapy planning system and a computer program product for using such method.
Background of the invention
In a radiation therapy system a radiation source is applied at angular positions around the subject in order to produce a targeted total radiation dosage spatial distribution that is concentrated on a region to be treated (the so-called target volume), while keeping the exposure of certain radiation-sensitive areas below a safety threshold. Angular coverage can be achieved by using a plurality of radiation sources distributed within the subject (brachy therapy), or by moving a single radiation source such as a linear accelerator (linac) around the subject (tele therapy).
The radiation therapy system may be controlled on the basis of a radiotherapy treatment plan that is specific for a certain patient. The treatment plan controls the linac of the radiation therapy system such that a region to be treated is exposed to radiation according to a predetermined spatial radiation distribution. A so-call treatment planning system (TPS) enables medical personnel to generate a treatment plan on the basis of image information of the region to be treated. Typically, the image information may be obtained from CT,
Pet/CT and/or MRI scans. A treatment planning process therefore typically starts with importing scans of the patients whereafter the TPS presents medical personnel with tools for identifying regions of interests (regions that are targeted for radiation treatment), regions of risk (regions that should not be exposed to radiation) and points of interest (e.g. points that are important for positioning a patient within the coordinate system of the linac). Further, the TPS may comprise tools that are configured to allow medical personnel to define bundle configurations of the linac and assign dosage parameters to certain parts of the target volume. Thereafter, the TPS may calculate the total radiation dosage spatial distribution within the target volume on the basis of the entered settings. The TPS may use an (iterative) optimization algorithm or a simulation program in order to further improve the radiation therapy plan such that the radiation beam concentrates the radiation in the target volume while minimizing exposure of sensitive organs or regions, taking into account known information about radiation attenuation or absorption characteristics of the various tissues. A TPS is usually implemented as a software program that is executed on a computer or a dedicated processor. A known TPS is the Pinnacle(TM) radiation therapy planning system of Philips. Pinnacle may be controlled using a very basic native scripting language referred to as Pinnacle script or "hotscript". A Pinnacle script defines a sequence of line commands that may be executed from a script menu. The menu may allow a number of different scripts (e.g. initialize, create ROI, setup beams, set objectives) to be executed in an predetermined order in order to control a logical workflow within the TPS or to allow use of custom functionality. When executing these scripts, Pinnacle items defined or modified in a first script X may be used as input in a later second script Y. In this way, for different treatment protocols and/or treatment planning techniques an appropriate script menu may be programmed or new functionalities may be added to the Pinnacle TPS.
The Pinnacle script language has however some important limitations. For example, the implementation of regular "for" or "while" loops is limited. Further, it only provides a limited possibility for executing IF ... THEN ... statements and the number of available numerical and string operations is very limited. For example, it is possible to add something to a string variable but not to remove something from a string variable. A technique to overcome at least part of these limitations is described in the article by Yang et. al. "Automated radiotherapy treatment plan integrity verification", Medical Physics 39(3), March 2012, pp. 1542-1551. The authors propose a dynamic script generation method, which makes use of the possibility within the Pinnacle scripting language to execute an external shell script in another script language such as Python that is supported by the computer/server on which the TPS is executed.
For example, it allows the execution of a Python script that allows information to be analysed and/or modified and the output of the script can be a text file with the syntax of a Pinnacle script. Although this dynamic script generation method greatly increases the possibilities for adding functionality to the Pinnacle TPS, it increases the problem of managing the large number of different interacting script files, e.g. in certain cases more than 30 interacting Pinnacle and Python scripts are needed in order to create functionality that in a normal programming environment could be dealt with in one single code file.
One problem relates to the fact that the text-file structure of scripts does not allow explicit ways to manage different versions. Distinction between a current version and older versions needs to be managed manually using e.g. a particular folder structure. These limitations make the system vulnerable for mistakes. In the article of Kantor et al, "Relational Database of treatment planning system information", Journal of Radiation Oncology Informatics, 2013, a database system for a TPS system is described. This system allows storage of treatments plans for facilitating retrospective review of data in a treatment plan. It does not deal with managing scripts that are used during the execution of a TPS.
In addition, understanding of the operating system (e.g. Solaris) is necessary to avoid simple mistakes with large consequences such as accidental deletion of script files without even noticing. Therefore, in such file-based scripting environment even the simplest adjustment to a clinical script is only suitable for persons that have technical programming background. Further extension of functionality (e.g. database connection) would require upgrading or extending Python (or PERL) with third-party (open source) modules. However, this is not recommended since modifications by the user to a medical device should be avoided.
Hence, from the above it follows there is a need in the art for improved methods and systems for radiation therapy treatment planning that extend the functionality of a TPS without changing the TPS.
Summary of the invention
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non- exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java(TM), Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor, in particular a microprocessor or central processing unit (CPU), of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer, other programmable data processing apparatus, or other devices create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It is an objective of the invention to a computer-implemented method for forming at least part of a radiation treatment plan for use in a radiation therapy system, wherein said radiation therapy system may comprise a treatment planning system (TPS) server connected to at least one script content management system (SCMS) server. In an embodiment, said method may comprise: a first script execution module in said TPS executing a first (static) process script in a first (native) scripting language of said radiation treatment system, the execution of said first process script initiating a dynamic script generation module to send one or more messages to said SCMS server, wherein said one or more messages comprise one or more instructions for said SCMS server for retrieving at least part of a program script in a second scripting language; said dynamic script generation module in said TPS executing at least part of said program script for forming one or more target scripts in said first scripting language, and, executing at least one of said one or more target scripts in order to establish at least part of said treatment plan. A simple static script may be used to execute a program script by the dynamic script generating module in order to dynamically generate a target script in a simple, native scripting language wherein the target script may be formed on the basis of variables and/or scripts that are stored on a separate script content management system (SCMS) server. Subsequent execution of the target script will generate part of a treatment plan for a radiation treatment system.
When compared with prior art systems, the invention provides a true programming environment on a legacy TPS system that has limited scripting functionality (such as Pinnacle). Instead of executing simple scripts in the scripting language of limited functionality, a script in a second language (e.g. Python or Perl) may be executed which - when executed on by the TPS - generates one or more target scripts for execution of a selected planning function using variable and/or scripts that are stored on an external SCMS server. Hence, no complex script handling and version management by the TPS system is required.
The invention allows a user to instruct the TPS on the basis of standard open-source scripting language such as Python or Perl and allows a TPS to deliver results that are directly usable for further use within an executed Python script. Hence, the invention replaces the limited (hot)script user interface of a legacy TPS with a more elaborated user interface that is based on standard open-source scripting language with extended functionality such as database handling modules etc.
Further, the TPS may instruct remote execution of scripts that are stored at the SCMS server. Moreover, the information that is stored on the SCMS server may be managed separately. The above-described extended functionality may be achieved without modifying the legacy script execution modules of the TPS.
In an embodiment, the TPS server may be a legacy TPS server. In an embodiment, said planning process may further comprise: during the execution of said first process script starting the execution of a second process script in a second (conventional) scripting language by a second script execution module, said second process script triggering said dynamic script generation module to set up a (TCP/IP-based) communication channel between said dynamic script generation module and a SCMS execution module in said SCMS server.
In an embodiment executing at least part of said program script may comprise: said dynamic script generation module sending one or more messages to the SCMS execution module in the SCMS server, said one or more messages comprising on or more instructions to a SCMS execution module, said instructions including the retrieval one or more parameters and/or scripts in said first and/or second scripting language; and, said dynamic script generation module using at least part of said retrieved one or more parameters and/or scripts in said first and/or second scripting language in the formation of said least one target script.
In an embodiment executing at least part of said program script may comprise: said dynamic script generation module sending one or more messages to the SCMS execution module in the SCMS server, said one or more messages comprising one or more instruction to execute one or more scripts in said second scripting language by a SCMS execution module in said SCMS server; said dynamic script generation module using at least part of the results of the one or more executed scripts in the formation of said least one target script.
In an embodiment, executing said first target script may include: proving said first script execution module with said first target script; instructing said dynamic script generation module to suspend execution of said program script; said first script execution module executing said first target script.
In an embodiment, executing said first target script may include: storing said first target script on a storage medium of said treatment planning system, preferably in patient and plan-specific (sub)folder; and/or, storing at least part of the result of the execution of said first target script on a storage medium of said treatment planning system, preferably in patient and plan-specific (sub)folder.
Hence, the method allows the dynamic generation of a native target script that may be executed in order to generate part of a treatment plan. At least part of the information that is needed for forming the target script is retrieved from an external SCMS server.
In a further aspect, the invention may relate to a radiation therapy planning (TPS) server for use with a script content management system (SCMS) server that is configured to execute messages that are sent by said TPS sever in messages to said SCMS server. The TPS server may be configured for establishing at least part of a treatment plan for a radiation treatment system and said TPS server may comprise a computer readable storage medium having computer readable program code embodied therewith, and a (micro) processor coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code, the (micro) processor is configured to perform first executable operations associated with a first script execution module and second executable operations associated with a dynamic script generating module.
In an embodiment, said first executable operations may comprise: executing a first process script in a first (native) scripting language of said radiation treatment system, and, executing a target script in order to establish at least part of said treatment plan.
In an embodiment, said second executable operations may comprise: sending, in response to the execution of said first process script by said first script execution module, one or more messages to said SCMS server, wherein said one or more messages comprise one or more instructions for said database server for retrieving at least part of a program script in a second scripting language; and, executing at least part of said program script for forming a target script in said first scripting language.
In an embodiment, said second executable operations may further comprise: said dynamic script generation module sending one or more messages to the SCMS execution module in the SCMS server, said one or more messages comprising on or more instructions to a SCMS execution module, said instructions including the retrieval one or more parameters and/or scripts in said first and/or second scripting language; and, said dynamic script generation module using at least part of said retrieved one or more parameters and/or scripts in said first and/or second scripting language in the formation of said least one target script.
In another embodiment, said second executable operations may further comprise: said dynamic script generation module executing a second part of said program script on the basis of at least part of the result of the execution of said first target script for forming at least a second target script in said first scripting language.
In a further aspect, the invention may relate to a script content management system (SCMS) server for use with a radiation therapy planning system (TPS) server as described above, wherein the SCMS server may comprise: a computer readable storage medium comprising one or more treatment variables and/or one or more program scripts in said second scripting language for use in the formation of part of a treatment plan by said a radiation therapy planning system; said SCMS server comprising a computer readable storage medium having computer readable program code embodied therewith, and a (micro) processor coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code, the (micro)processor is configured to perform first executable operations associated with a SCMS main module and second executable operations associated with a SCMS execution module, said first executable operations comprising: setting up a communication channel, preferably an TCP/IP-based communication channel, with a dynamic script generating module in said radiation therapy planning system; said second executable operations comprising: receiving one or more messages over said communication channel and for executing one or more instructions in said messages from said dynamic script generating module, said instructions including: retrieving at least part of a program script and/or treatment variable from said storage medium and sending said program script for execution to said radiation therapy planning system; or; executing at least part of a program script on the basis of one or more variables and transcending the result of said executed program script to said radiation therapy planning system.
The invention thus includes a script content management system (SCMS) for a Treatment Planning System (TPS) wherein the SCMS is configured to extend a TPS comprising a native TPS scripting language with the functionality of a programming language. In particular, a TPS comprising the SCMS allows an unmodified Pinnacle TPS to seamlessly run Python code directly from an external database. The ability to use scripts and script menus that dynamically depend on treatment protocols, the web/database design, and the reduced script complexity offer great potential regarding script management and treatment plan management.
The SCMS may be implemented using e.g. a Python/PHP/MySQL platform that runs on a dedicated server. To establish connection between the SCMS and the TPS (Pinnacle) a custom Python-to-Python communication protocol may be used.
The TPS was not modified except for the use of static process script files in the designated scripting folder. Additional Python modules were installed on the SCMS server only. A set of custom functions add advanced features like in-script SCMS/TPS communication and external database access. The SCMS database is configure to host both scripts (Python code) and variables: the properties of ROIs, POIs, Beams, IMRT Objectives, DVH/Dose Parameters, etc. Customizable script menu templates may combine relevant scripts and variables based on treatment protocols. An administrative web interface manages both the database content and the script-assembly process; no programming skills are required. Finally, the SCMS uses sets of sandboxed live/test environments featured with automated version control and access control.
The invention may also relate to a program product, a computer program product comprising software code portions configured for, when run in the memory of a computer, executing the method steps as described above. The invention will be further illustrated with reference to the attached drawings, which schematically will show embodiments according to the invention. It will be understood that the invention is not in any way restricted to these specific embodiments.
Brief description of the drawings
Fig. 1A depicts a radiation therapy system according to an embodiment of the invention.
Fig. IB depicts a schematic of data processing system for use in a radiation therapy system.
Fig. 2 depicts a flow diagram of the execution of at least part of a planning process on a radiation therapy treatment planning system (TPS) according to an embodiment of the invention.
Fig. 3 depicts a flow diagram of the execution of at least part of a planning process on a TPS according to another embodiment of the invention.
Fig. 4 depicts a flow diagram of the execution of at least part of a planning process on TPS according to a further embodiment of the invention.
Fig. 5 depicts a flow diagram of the execution of at least part of a planning process on a TPS according to a yet another embodiment of the invention.
Detailed description
Fig. 1 depicts a radiation therapy system according to an embodiment of the invention. The system may comprise a treatment planning system (TPS) 102 that is coupled to one or more imaging (scanning) systems and a server system 112 that is connected to one or more databases 114 which hereafter may be referred to as the SCMS server and the SCMS databases respectively. Known imaging systems may include a CT scanner 108 and/or one or more other scanning systems 110 such as MR, PET/CT, and CBCT. The TPS may be configured to generate a treatment plan for a particular patient that can be used to control a radiation source such as a linear accelerator (linac) 106 around the subject. The treatment plan may be recorded and verified by a record and verify system 104 during and after it is executed. The TPS may be implemented as a computer system comprising hardware and/or software modules that can be executed and that are configured to build a treatment plan for a patient on the basis of information from the scanning systems, input from an authorized user, and other medical information.
The computer of the TPS may be configured to execute one or more applications 116 that may control the work flow process for building the treatment plan, which may include one or more graphical user interfaces that allow execution of functions from one or more menus, including a script menu 118 and a menu 120 that allows the execution of planning functions, wherein the execution of one or more planning function may establish at least part of a radiation treatment plan. The TPS may be controlled using a native, dedicated scripting language such as the Pinnacle scripting language. Here, a scripting language or script language may be regarded as a programming language that supports the writing of scripts, relatively small programs written for a special runtime environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator.
Scripts may be stored in a memory or on storage medium of the TPS and executed by a first script execution module 122 that may comprise a first interpreter for interpreting the native script language. The native scripts may be stored in a dedicated memory of the TPS. For example, in the Pinnacle TPS scripts are stored in a special Pinnacle Scripting folder. Here, the native script language can only provide very basic functionality. By executing scripts (part of) a radiation plan may be determined. The radiation plan may be used by the radiation therapy system in order to determine the setting of the radiation source 106 of the radiation therapy system may be controlled by the radiation treatment plan that is formed by executing scripts (target scripts) in the native TPS scripting language. The TPS may be further configured to execute other scripting languages using a second script execution module 124. The second script execution module may comprise an interpreter for executing a second conventional script language, e.g. Python or Perl. A radiation therapy system including the TPS and the radiation source are expensive medical devices so that it is used for a relatively long time before it is replaced. Therefore, the script execution modules are legacy modules that only support relatively old versions of the script language. A simple update of the script execution modules, e.g. an update of the Python interpreter and/or (part of) the operating system of the TPS is not possible due to security issues and/or regulations. Therefore, the functionality that is offered by the scripting modules is limited and e.g. often does not provide database functionality.
In order to broach this problem, the functionality of the TPS may be extended without modifying the originally installed script execution modules. To that end, the first script execution module may be configured to execute a first static process script in the first (native) script language for starting a process for the formation and execution of one or more target scripts in the first script language, wherein execution of the target scripts results in the generation of part of a radiation treatment plan.
During the execution of the first process script, the execution of a second static process script by the second script execution module may be triggered. The execution of the second script may be controller by a script controller manager 125. During the execution of the second script, a dynamic script generation module 126 may be triggered to set-up and maintain a communication channel 127 between the TPS server and the SCMS server 112. Further, the dynamic script generation module may be trigged to use the communication channel to instruct a SCMS server main module 130, in particular a SCMS execution module 128 that is executed by a third script execution module 129 in the SCMS server.
Here, the third script execution module may support execution of scripts of the same or other available script languages as the second script execution module (e.g. Python or Perl). Furthermore, the third script execution module may be extended with one or more modules, e.g. known open source modules such as an PYODBC-module, that allow execution of database handling commands, e.g. SQL commands, in order to access data in the one or more databases 114 that are hosted on the SCMS server or a further external third-party database 144.
In order to establish a communication channel, the dynamic script generation module 126 may create a network socket, that is configured to establish a connection with the SCMS execution module, using e.g. a dedicated Python socket.
When a script is executed on the TPS that triggers the execution of a script by the second script execution module, the dynamic script generation module may be started to send one or more connection requests to a predetermined port of the SCMS server. On the SCMS server, the SCMS execution module is waiting from incoming connection requests from the dynamic script generation module of the TPS. In particular, the second script execution module may assign a local free TCP/IP port to the dynamic script generation module. Further, the TCP/IP port of the SCMS execution module of the SCMS server may be fixed. The dynamic script generation module may communicate with the third script execution module on the basis of a TCP/IP protocol. In particular, a TCP/IP (protocol) which is encapsulated in a standard Ethernet protocol.
During execution of a script by the second script execution module, the dynamic script generation module may send one or more messages to the SCMS execution module wherein the messages may comprise one or more instructions for the SCMS execution module. Instructions that may be executed by the SCMS execution module may include: SQL DatasourceName [SQL statement]
This instruction instructs the SCMS execution module in the SCMS server to execute an SQL database command, e.g. to fetch one or more variables from a particular database. EXE Scriptnumber [one or more variables]
This instruction instructs the SCMS execution module in the database server to remotely execute a script in a second script language that is stored in the database. The script may be executed on the basis of one or more variables that are sent by the dynamic script generation module in the message to the SCMS execution module. When an instruction in a message is executed, the result (e.g. one or more variables and/or scripts retrieved from the database or the result of the execution of a script by the third script execution module) may be returned to the dynamic script generation module, which may use the returned data in the process of the formation of a target script.
Hence, when a script associated with a menu button (a planning function) is executed on the TPS, the dynamic script generation module may send one or more messages comprising one or more instructions to the SCMS execution module in the SCMS server .
In the database various data may be stored, including scripting code 138 of scripts in the first and/or second scripting language and can be executed by the script execution modules in the TPS or the SCMS server. Further, the database may comprise treatment plan variables and settings 132, medical treatment protocols 134, menu-items 136 and treatment plan information 142. The database may be accessed by a web interface 140 to manage the database information separately from the TPS.
Hence, from the above it follows that the dynamic script generation module may add database functionality to a legacy TPS without changing the script execution modules. It enables a TPS that has no in-script database functionality to seamlessly run scripts (e.g. Python code) directly from an external database. The ability to use scripts and script menus that dynamically depend on treatment protocols, the web/database design, and the reduced script complexity offer great potential regarding script management and treatment plan management. The processes that are executed on the TPS and the database server in order to achieve these effects and advantages are described hereunder in more detail.
One or more embodiments disclosed within this specification a secure computing system using a client-server type of architecture. In accordance with the one or more embodiments disclosed herein, secure computing system may be operated as a Web Service being available to service requests issued through a client-server type of architecture. FIG. IB depicts a block diagram illustrating an exemplary data processing system that may be used in a secure computing system as described with reference to Fig. 1A. Data processing system 150 may include at least one (mirco) processor 152 coupled to memory elements 154 through a system bus 156. As such, the data processing system may store program code within memory elements 154. Further, processor 152 may execute the program code accessed from memory elements 154 via system bus 156. In one aspect, data processing system 150 may be implemented as a computer that is suitable for storing and/or executing program code. It should be appreciated, however, that system 150 may be implemented in the form of any system including a processor and memory that is capable of performing the functions described within this specification.
Memory elements 154 may include one or more physical memory devices such as, for example, local memory 158 and one or more bulk storage devices 160. Local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive or other persistent data storage device. The processing system 250 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from bulk storage device 160 during execution.
Input/output (I/O) devices depicted as input device 162 and output device 164 optionally can be coupled to the data processing system. Examples of input device may include, but are not limited to, for example, a keyboard, a pointing device such as a mouse, or the like. Examples of output device may include, but are not limited to, for example, a monitor or display, speakers, or the like. Input device and/or output device may be coupled to data processing system either directly or through intervening I/O controllers. A network adapter 166 may also be coupled to data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and/or remote storage devices through intervening private or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and/or networks to said data and a data transmitter for transmitting data to said systems, devices and/or networks. Modems, cable modems, and Ethernet cards are examples of different types of network adapter that may be used with data processing system 150.
As pictured in FIG. IB, memory elements 154 may store an application 168. It should be appreciated that data processing system 150 may further execute an operating system (not shown) that can facilitate execution of the application. Application, being implemented in the form of executable program code, can be executed by data processing system 150, e.g., by processor 152. Responsive to executing application, data processing system may be configured to perform one or more operations to be described herein in further detail.
In an aspect, data processing system 150 may represent a server. For example, data processing system 150 may represent server in which case application 168, when executed, may configure data processing system 150 to perform server operations. In another aspect, data processing system 150 may represent TPS server or a SCMS server including modules, e.g. script execution modules, that may be executed as a software application on the server.
Fig. 2 depicts a flow diagram of the execution of part of a computer-implemented planning process according to an embodiment of the invention. The planning process may be executed on a TPS server 205 as described with reference to Fig. 1A and IB. The TPS server 205 may display one or more planning functions to a user via a GUI. A menu 203 may comprise one or more buttons that each may be associated with a planning function. When selecting a button, a planning process for a particular patient may be started wherein this planning process includes the formation and subsequently execution of one or more target scripts.
During the process, planning parameters may be used, including: a user identification number UserlD, a script identifier Script_ID, a process identifier Local LS port, a patient treatment plan identifier, etc. The planning process shown in Fig. 2 may be executed using the first and second script execution modules 213,215 of the TPS server and the third script execution module of the SCMS server.
In a first step (step 202) a user may execute a TPS function for forming part of a radiation treatment plan of a particular patient by selecting a particular button in the menu. Upon activation of the button, the first script execution module may execute a first (static) process script "Tvrs. script" in the Pinnacle scripting folder on the basis of parameters that are associated with the selected function (step 204). As will be explained hereunder in more detail, the execution of the first process script may result in an executable target script that provides - when executed - the functionality associated with the selected menu button.
The target script may be stored as a dynamic text file "Zombie. Script" 226 in a patient and plan-specific subfolder within the Pinnacle Scripting folder structure: /usr/local/adacnew/PinnacleSiteData/Scripts/
Umbrella/Institution_xxx/Mount_0/Patient_xxxx/Plan_yy/. The target script is "dynamic" in the sense that the content of the file changes during the execution of a planning processes, wherein the content of the process scrip file does not change.
During the execution of the first process script Tvrs.script, a second (static) process script in another (conventional) scripting language of the second script execution module (in this example a static Python script "Tvrs.py"), may be executed (step 206). The second process script may be executed using a native TPS command in the first process script such as the Pinnacle SpawnCommand().
The associated second script Tvrs.py may be implemented as an execution initiator that may start and stop the script execution manager LS.py for a particular patient.
If the execution initiator is running, the TPS will wait with the execution of the first process script, until the execution initiator is stopped. The script execution manager LS.py may manage the process for forming and executing the target script that belongs to the selected planning function. The process may be executed on the basis of one or more threads. A main thread may be implemented as a dynamic script generating module for forming and executing one or more target scripts on the basis of variables and/or scripts that can be accessed via the SCMS server. The second script execution module may be a legacy module that does not support database functionality. Hence, in order to provide the dynamic script generation module with database and script management capabilities, the dynamic script generation module may create a socket that is configured to connect to the socket of the SCMS execution module (LS'.py), that is executed in the third script execution module as described in detail with reference to Fig. 1.
The execution initiator may check whether a script execution manager LS.py for the currently selected planning function and selected patient is already running. If this is not the case, the execution initiator may start a script execution manager for this patient (step 208). The script execution manager may subsequently start the dynamic script generation module as a main thread of the selected planning function (step 210).
As shown in Fig. 2, the dynamic script generating module may start the execution of a script in the second scripting language (e.g. a Python code). The script may include an initialization step (get Umbrella class) in which information is retrieved from the SCMS server. Here, the Umbrella class may include a list of functions that may be executed and/or retrieved from the SCMS server by the dynamic script executing module. Thereafter, a further script of the second scripting language (e.g. a Python script) that is associated with the selected planning function (i.e. a function script) may be retrieved from the SCMS server (step 212) .
The execution of the script may include the retrieval of one or more scripts and/or treatment parameters from the SCMS server 207 or a further third-party database server 209.
As described with reference to Fig. 1, the dynamic scriptgenerating module may easily retrieve the database information by sending one or more messages over the TCP/IP connection to the SCMS server, wherein the messages may comprise instructions in the second scripting language for the SCMS execution module.
When the SCMS main module (LS'.py) of the SCMS execution module receives a connection request from the dynamic script generation module of the TPS, the SCMS main module may start the SCMS execution module as a new thread (step 214) for the retrieval of treatment parameters and/or scripts from the one or more databases or execution of remote snippets, i.e. the execution of a script in the second scripting language that is stored in the database of the SCMS server and that is executed by the third script execution module on the SCMS server.
The SCMS execution module may parse the messages that it receives and execute the instructions in the messages (step 216). These instructions may include the execution of one or more SQL commands for retrieving certain information (native TPS scripts and/or treatment parameters such as POIs, ROIs, etc.) from one of the databases 230i-4. Alternatively, the instruction may include the execution of a particular script (snippet) by the SCMS execution module wherein script is stored in one of the databases of the SCMS server. These database parameters or snippets may be selected from the database using the planning parameters of the planning function that was selected by the user. The result of the executed instructions are subsequently sent to the dynamic script executing module.
When the dynamic script-generating module receives the requested data via the communication channel, it may form the dynamic target script, which is subsequently written as a text file "Zombie. Script" in a patient and plan-specific subfolder (step 218). Thereafter, a message may be sent to the execution initiator (step 222) in order to inform the execution initiator that the main thread for the selected planning function has been terminated. In response, the execution initiator may stop so that TPS continues the execution of the first process script Tvrs.script (step 224). When the control is back with the execution of the first process script, the dynamically generated target script will automatically executed using e.g. the Pinnacle command Script.ExecuteNow (step 226). The execution of this target script will result in execution of the selected planning function, which may be configured to generate part of the treatment plan. In this particular embodiment, the target script is configured to give control back to the TPS system, e.g. the menu, once the execution of the target script is finished (step 228).
If a user selects a further planning function from the menu, the system will repeat the same planning process using the same static scripts, i.e. Tvrs.script, Tvrs.py, LS.py in order to generate a new dynamic target script that is written as a text file Zombie. Script in the patient and plan-specific subfolder. Hence, a simple set of static scripts may be used to execute a function script by the dynamic script generating module in order to form and execute a dynamically generated target script. When compared with prior art systems, the invention provides a true programming environment on a legacy TPS system. Instead of executing simple scripts in a scripting language of limited functionality (such as Pinnacle), a script in a second language (e.g. Python or Perl) may be executed which - when executed on by the TPS -generates one or more target scripts for execution of a selected planning function using variable and/or scripts that are stored on an external SCMS server. Hence, no complex script handling and version management by the TPS system is required. Further, the TPS may instruct remote execution of scripts that are stored at the SCMS server. Moreover, the information that is stored on the SCMS server may be managed separately. The above-described extended functionality may be achieved without modifying the legacy script execution modules of the TPS.
Fig. 3-5 depict flow diagrams of the execution of at least part of a planning program on a radiation therapy treatment planning system (TPS) according to an embodiment of the invention. In this particular embodiment, the functionality of the TPS may be extended by allowing a user to execute a relative complex planning program in a scripting language for the creation of a new user treatment plan that includes the execution of multiple planning functions. The planning program may involve the automatic execution of a logical sequence of (smaller) planning functions, wherein each of the planning functions is associated with the formation and execution of one or more target scripts that may be generated on the basis of scripts and/or parameters that are stored in the one or more databases of the SCMS server and on the basis of the results of an earlier executed target script. As will be described hereunder in more detail, the logical sequence of planning functions may be executed on the basis of information in the database using a (multi-thread) process wherein the output of a first executed target script of a first planning function may be used as (part of) the input for the execution of a second target script of a second planning function.
In order to allow the direct use of the result of the execution of a (Pinnacle) target script in Python code a class of Python functions may be defined. For example, functions Umbrella .pinnCommand() may include a pinCommand. add () function for compiling statements in Pinnacle script syntax to a sequence which may be stored in a PinnDump textfile. The function pinnCommand.exe() may result in the execution of a compiled Pinnacle statement (i.e. the target script) and may return as an Python object so that the result may be used directly in the Python code itself: pinncmd.add ('Store .FloatAt.MYVAR=<Pinnacle script>;')
This function adds Pinnacle variable MYVAR to a certain Pinnacle script (a target script) and stores the result in a PinnDmp file. Thereafter, the Python code may instruct the TPS to execute the target script using the Python statement: RES = pinncmd.exe()
The first script (Pinnacle) execution module will read the PinnDmp file and will find that MYVAR is needed. Thereafter, the result of the executed script may be used in the Python code as RES.MYVAR. Hence, the pinnCommand.exe() is a very powerful function which returns a Python object with Pinnacle variables that are added to the Pinnacle "store" (i.e. a Pinnacle object for defining and/or storing Pinnacle string and float variables). The pinnCommand.exe() function may be used in the program script in order to allow the use of results of an executed (Pinnacle) target script in the (Python) program script. This way powerful application can be build wherein during the execution of a program script results that are executed in Pinnacle may be used in advanced Python scripts that include e.g. optimization algorithms.
The process in Fig. 3 may start with the execution of the planning program by a user using the GUI of the TPS (step 302). Similar to the process described in Fig. 2, a first static process script (Tvrs. Script) in a first native TPS scripting language (e.g. Pinnacle) may be executed on the basis of a set of planning parameters of the planning program (step 304). During the execution of the first process script may in turn execute second‘static process script (Tvrs.py), the process initiator (step 306), that triggers the script execution manager (step 308) for managing the start and termination of one or more threads that are executed by the second script execution module during the execution of the planning program. If the execution initiator detects that the execution manager of the selected planning program has not been stated yet, it may start the execution manager (step 308) which may - in turn - start the dynamic script generating module (step 308) (the main thread) for executing the planning program.
Thereafter the dynamic script generation module may set-up a communication channel with SCMS main module associated with the SCMS execution module (step 310) and one or more messages comprising instructions for the SCMS execution module may be sent to the SCMS execution module in order to retrieve at least part of a program script that represents the planning program (step 312). The planning program script may include the execution of a plurality of planning functions, wherein each of these functions may involve a process of forming a target script and executing the target script by the first script execution module.
The thus retrieved program script is executed by the dynamic script generation module using the pinnCommand.exe () function (step 313). During the execution of the program script, the dynamic script generation module may form a first target script on the basis of parameters and/or scripts that are stored in the SCMS server (step 314). The thus formed first target script may be stored as a text file "Zombie. script" in a patient and plan-specific subfolder (step 316) .
Thereafter, the dynamic script generation module may notify the execution initiator (step 318) that the main thread for the selected planning function is temporarily suspended. Thereafter the process initiator is stopped so that the control is transferred back to the first script execution module that executes the first process script (step 322). In response, the first target script is automatically executed and the execution of the first process script is terminated.
During the execution of the first target script part of the treatment plan may be generated. The output of the executed first target script may be saved in a text file PinnDmp#.txt (step 324) wherein #=1,2,3.... This file may be referred to as target script output file. Further, the target script may be configured to start the execution of the first process script for a second time (step 326) once the execution of the first target script is finished.
The process is further continued in Fig. 4 showing a next, second process cycle in the execution of the program script wherein a second target script is formed and executed.
The second process cycle may start with the first script execution module executing the first process script for a second time (step 402). During the execution of the first process script, the execution of the second process script representing the execution initiator may be started (step 404), which triggers the execution manager to check whether a script execution module (a main thread) of the associated with the executed planning program exists. When determining a main thread of the planning program, the execution manager may start a secondary thread of the planning program (step 406), wherein the secondary thread may notify the main thread that execution of the program script may be continued. When resuming execution of the program script, at least part of the information in the target script output file may be used as input information for the formation of the (next) second target script (step 412).
Further, during the formation of the second target script, the dynamic script generation module may instruct the SCMS server to retrieve parameters and/or scripts; and/or, to (remotely) execute snippets (scripts) that are stored in a database of the SCMS server (step 414) in a similar way as described with reference to Fig. 1-3.
Thereafter, the second target script may be written in a text file "Zombie. script" that is stored in a patient and plan-specific subfolder (step 416). Further, the execution manager may notify the execution initiator via the secondary thread that the execution of the planning program is suspended. Thereafter, the execution initiator is stopped and control is given back to first script execution module that executes the first process script (step 420) and the second dynamically generated target script may be executed by the first script execution module. The result (output) of the executed target script may be stored in a target script output file (step 424). The second target script may be configured to start the execution of the first process script for a third time (step 426) once the execution of the second target script is finished.
This process may be repeated until the whole planning program in the dynamic script generating module is executed. Fig. 5 depicts the last cycle of the execution of the program script, comprising the same steps that are described in detail with reference to Fig. 4. In this case however, when the final target script is formed, the script is configured such that when it is executed control is given back to the TPS when the execution of the final target script is finished.
An example of part of a (Python) planning program script is provided hereunder, which checks whether certain ROIs are already available in Pinnacle for a certain treatment plan. This program script may be stored in database of the SCMS server and retrieved and executed by dynamic script generation module. u=Umbrella () pinncmd = u.pinnCommand() MYROIS = u.getScriptInput (6) PRESENTROIS = u.getListNames('ROI') # getListNames(itemtype) is a user-defined function that uses pinnCommand.exe() to get a list of current present item-types. In this case 'ROI'. #Check if MYROIS are already present in Pinnacle PRESENTLIST = [] if len(MYROIS)>0: for roi in MYROIS: if str(roi. name) in PRESENTROIS: PRESENTLIST. append (roi. name) cont = 1 if len(PRESENTLIST)>0: pinncmd. add ('Store .FloatAt. Continue = 0;') pinncmd. add ('AskYesNoDefault = 0;') pinncmd. add('AskYesNoPrompt = "Some ROIs are already present: do you want to continue? ";') pinncmd. add ('Store .FloatAt. Continue = AskYesNo;') cont__tmp = pinncmd. exe () #Step 1 cont = int(cont__tmp. Continue) pinncmd. reset () myStr = '' if cont==l and len(MYROIS)>0: for roi in MYROIS: if roi.name not in PRESENTROIS: pinncmd. add ('CreateNewROI = 1;') pinncmd. add ('RoiList. Last. Name = +str(roi. name) pinncmd. add ('RoiList. Current = +str(roi. name) if roi. color != 'None': pinncmd. add ('RoiList. Current. Color = "'+str(roi. color) myStr = myStr + '* '+ str(roi. name) + ' 0' pinncmd. add ('WarningMessage = "Your ROIs 0 @' + myStr + '00 are ready!";') pinncmd.exe() #Step 2 else : pass
The example shows that the pinncmd.add function is used to compile pieces of Pinnacle script into a target script which is subsequently executed using the pinncmd.exe() function. In this example, a first part of the Python program script (step #1) may compile a first Pinnacle target script. When executing the target script of step #1, the result of the executed target script may be stored in a PinnDmp file in the patient and plan specific folder. Thereafter, the result of the executed first target script, in this example, the variable "cont_temp" may be directly used in the execution of the second part (step #1) of the Python program script, which will generate a second Pinnacle target script for execution using the pinncmd.exe() function.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. For example, in an embodiment, the first and second scripting language may relate to different scripting languages, i.e. a native (proprietary) scripting languages of the TPS such as Pinnacle and a conventional (open-source) scripting language such as Python or Perl. In another embodiment, the first and second scripting language may relate to different versions of the same scripting language, e.g. a first (older) legacy version and a current version that offers more functionality than the legacy version. In yet another embodiment, the first and second scripting language may be identical, e.g. a legacy version of a scripting language (e.g. a older Python version with limited database capabilities). The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Claims (14)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2011393A NL2011393C2 (en) | 2013-09-05 | 2013-09-05 | Radiation therapy treatment planning system. |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2011393A NL2011393C2 (en) | 2013-09-05 | 2013-09-05 | Radiation therapy treatment planning system. |
| NL2011393 | 2013-09-05 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| NL2011393C2 true NL2011393C2 (en) | 2015-03-09 |
Family
ID=49817197
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| NL2011393A NL2011393C2 (en) | 2013-09-05 | 2013-09-05 | Radiation therapy treatment planning system. |
Country Status (1)
| Country | Link |
|---|---|
| NL (1) | NL2011393C2 (en) |
-
2013
- 2013-09-05 NL NL2011393A patent/NL2011393C2/en not_active IP Right Cessation
Non-Patent Citations (2)
| Title |
|---|
| ME KANTOR ET AL: "Relational Database of Treatment Planning System Information", 1 January 2013 (2013-01-01), XP055121918, Retrieved from the Internet <URL:http://jroi.org/index.php/jroi/article/viewFile/15/17> [retrieved on 20140605], DOI: 10.5166/jroi-5-1-15 * |
| YANG DESHAN ET AL: "Automated radiotherapy treatment plan integrity verification", MEDICAL PHYSICS, AIP, MELVILLE, NY, US, vol. 39, no. 3, 1 March 2012 (2012-03-01), pages 1542 - 1551, XP012160906, ISSN: 0094-2405, [retrieved on 20120228], DOI: 10.1118/1.3683646 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11775339B2 (en) | Robotic process automation using virtual machine and programming language interpreter | |
| US11921497B2 (en) | Zero footprint robotic process automation system | |
| US10972367B2 (en) | Provisioning framework for binding related cloud services | |
| US11599348B2 (en) | Container image building using shared resources | |
| US10620933B2 (en) | Techniques for efficient application configuration patching | |
| US9588752B2 (en) | Performing unattended software installation | |
| US20180316551A1 (en) | Portable instance provisioning framework for cloud services | |
| US11316683B2 (en) | Systems and methods for providing IoT security service using hardware security module | |
| US11301224B1 (en) | Robotic process automation system with a command action logic independent execution environment | |
| JP7453426B2 (en) | Network management systems, methods, devices and electronic equipment | |
| WO2020223365A1 (en) | Zero footprint robotic process automation system | |
| US8856740B2 (en) | Implementing multiple versions of a plug-in concurrently | |
| US11640304B2 (en) | System and method for the administration of imaging devices | |
| NL2011393C2 (en) | Radiation therapy treatment planning system. | |
| US20170192874A1 (en) | Targeted multi-tiered software stack serviceability | |
| US20170315785A1 (en) | Concurrent authoring session management for declarative document | |
| US8769075B2 (en) | Use of a systems management tool to manage an integrated solution appliance | |
| KR20170054269A (en) | Enterprise protocol management | |
| US20230198991A1 (en) | File-based configuration of access management | |
| US10146804B2 (en) | Computer implemented systems and methods to augment data from data sources by simultaneously adding enhancements generated by different technologies | |
| US11941024B1 (en) | Orchestration service for database replication | |
| US12008342B2 (en) | Package conversions for procedural language extensions | |
| CN112148416B (en) | Information interaction method, device, equipment and storage medium | |
| WO2022146469A1 (en) | Cross-platform implementation of cloud-based applications utilizing noodl programming | |
| CN115016811A (en) | Configuration file modification method, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MM | Lapsed because of non-payment of the annual fee |
Effective date: 20161001 |