Remote control of radiotherapy medical devices

Abstract

Various examples of the present disclosure relate to remote control of a radiotherapy medical device (91) using an application executed by a server (95). The digital twinning of the radiotherapy medical device (91) may be maintained at an application executed by the server (95).

Description

Technical Field

[0001] Various examples disclosed herein relate to remote control of a radiotherapy medical device. A server may execute an application that enables display and adjustment of values ​​of device parameters of the radiotherapy medical device. Background Art

[0002] A radiation therapy medical device (RTMD) can deliver radiation to a treatment site in a patient. Such irradiation is configured according to the values ​​of a number of device parameters, defining, for example, the amount of radiation to be delivered, the treatment site, etc. A treatment plan specifying these values ​​is usually determined in a planning phase prior to the irradiation phase itself. During the irradiation phase, the values ​​of the device parameters are monitored.

[0003] Such tasks of generating and validating treatment plans, monitoring irradiation, etc. are conventionally performed by a user physically present at the RTMD through user interaction via a human machine interface (HMI) of the RTMD.

[0004] Techniques that enable remote control of RTMDs have been disclosed, see US2007 / 0041496A1. Such techniques face certain limitations and disadvantages. For example, distributed control by a user located at the RTMD and another user located remotely may not be possible, or such distributed control may cause conflicts. Certain functions in the control of the RTMD (e.g., monitoring of irradiation) may not be possible. Techniques disclosed in the prior art may compromise reliability. Summary of the invention

[0005] Therefore, there is a need for advanced techniques for remotely controlling RTMDs.There is a need for techniques that mitigate or overcome at least some of the limitations and disadvantages discussed above.

[0006] This need is met by the features of the independent claim. Features of the dependent claims define embodiments.

[0007] Various examples of the present disclosure generally relate to a computer-implemented method. The computer-implemented method includes establishing a data connection with a radiotherapy medical device at a server. The data connection is made via the Internet. The computer-implemented method further includes executing an application at the server for remotely configuring multiple device parameters of the radiotherapy medical device. The application provides a user interface for displaying and adjusting the values ​​of the multiple device parameters. The computer-implemented method further includes performing repeated two-way synchronization of the values ​​of the multiple device parameters when executing the application. The repeated two-way synchronization is performed between the application and the radiotherapy medical device via the data connection.

[0008] A computing device (e.g., a server that may be located at a server farm) includes at least one processor and a memory, the at least one processor being configured to load a program code from the memory and execute the program code. Wherein, the at least one processor is configured to establish a data connection with a radiotherapy medical device when executing the program code. The data connection is made via the Internet. The at least one processor is further configured to execute an application for remotely configuring multiple device parameters of the radiotherapy medical device at the server. The application provides a user interface for displaying and adjusting the values ​​of multiple device parameters. The at least one processor is further configured to implement repeated two-way synchronization of the values ​​of the multiple device parameters when executing the application. The repeated two-way synchronization is performed between the application and the radiotherapy medical device via a data connection.

[0009] A system is provided, comprising the computing device and the radiation therapy medical device.

[0010] A computer program or computer program product or computer readable storage medium, comprising program code. When the program code causes at least one processor executing the program code to establish a data connection with a radiotherapy medical device. The data connection is made via the Internet. The program code further causes the at least one processor to execute an application for remotely configuring multiple device parameters of the radiotherapy medical device at the server. The application provides a user interface for displaying and adjusting the values ​​of multiple device parameters. The program code further causes the at least one processor to perform repeated two-way synchronization of the values ​​of the multiple device parameters when executing the application. The repeated two-way synchronization is performed between the application and the radiotherapy medical device via the data connection.

[0011] It should be understood that the features mentioned above and the features still to be explained below can be used not only in the indicated respective combinations, but also in other combinations or alone, without departing from the scope of the present invention. For example, at least some steps of the computer-implemented method can be performed by a computing device (e.g., a server). In addition, a system including both a computing device or specifically a server and a radiotherapy medical device can perform a computer-implemented method as disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A system including a radiation therapy medical device and a server according to various examples is schematically illustrated.

[0013] Figure 2 A system including a radiation therapy medical device and a server according to various examples is schematically illustrated.

[0014] Figure 3Radiation therapy medical devices according to various examples are schematically illustrated.

[0015] Figure 4 Servers according to various examples are schematically illustrated.

[0016] Figure 5 is a flow chart of a method according to various examples.

[0017] Figure 6 is a flow chart of a method according to various examples. DETAILED DESCRIPTION

[0018] Some examples of the present disclosure generally provide multiple circuits or other electrical devices. All references to circuits and other electrical devices and the functions they each provide are not intended to be limited to only the contents illustrated and described herein. Although specific labels may be given to the various circuits or other electrical devices disclosed, such labels are not intended to limit the operating range of these circuits and other electrical devices. Such circuits and other electrical devices can be combined with each other and / or separated in any way based on the specific type of desired electrical implementation. It should be recognized that any circuit or other electrical device disclosed herein may include any number of microcontrollers, graphics processor units (GPUs), integrated circuits, memory devices (e.g., flash memory, random access memory (RAM), read-only memory (ROM), electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or other suitable variants thereof) and software, which work together to perform the operations disclosed herein. In addition, any one or more electrical devices may be configured to execute a program code embodied in a non-transient computer-readable medium that is programmed to perform any number of functions disclosed.

[0019] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be understood that the following description of the embodiments should not be construed as limiting. The scope of the present invention is not intended to be limited by the embodiments or drawings described below, which are considered to be illustrative only.

[0020] The accompanying drawings should be considered as schematic representations, and the elements shown in the accompanying drawings are not necessarily shown to scale. Instead, the various elements are represented so that their functions and general uses become apparent to those skilled in the art. Any connection or coupling between the functional blocks, devices, components or other physical or functional units shown in the accompanying drawings or described herein may also be implemented by indirect connection or coupling. Coupling between components may also be established by wireless connection. Functional blocks may be implemented with hardware, firmware, software or a combination thereof.

[0021] Various techniques disclosed herein relate to radiation therapy, and more particularly to configuring radiation therapy.

[0022] Radiation therapy can be used to treat cancer. For example, photons, electrons, or heavy particles (e.g., protons or ions) can be used for radiation therapy. An applicator can be used to deliver radiation to the treatment site. Radiation can be generated using bremsstrahlung.

[0023] A radiotherapy episode comprises a planning phase and an irradiation phase and optionally further phases. The various phases may be offset in time, for example, performed on different days.

[0024] For example, and intraoperative radiation therapy events can be controlled. Here, the tumor is removed during surgery. That is, the radiation phase coincides with the surgery. After the surgery, the tissue surrounding the cavity caused by the tumor removal can be subjected to radiation, such as x-rays. The remaining tumor cells are thereby incapacitated.

[0025] Next, the various stages of a radiation therapy event are discussed. First, during a treatment planning stage, a treatment plan is determined. This includes adjusting the values ​​of multiple equipment parameters, for example, so as to thereby set the treatment site, set the radiation dose, set the radiation intensity, set the path of the radiation through the surrounding tissue, etc. Then, during a treatment stage (or irradiation stage), the predetermined treatment plan is executed. The values ​​of the equipment parameters are typically monitored to avoid deviations from any predetermined set points according to the treatment plan. Sometimes, there may be an intermediate pre-irradiation stage during which the treatment plan is approved for application. Sometimes, there may be a post-irradiation stage during which a radiation report is determined and optionally shared.

[0026] During the various stages of a radiation therapy event, typically multiple users will interact to set up a treatment plan, confirm a treatment plan, monitor radiation, and / or determine radiation reporting. For example, a radiologist, an oncologist, a technician operating an RTMD, etc. may take over certain tasks associated with the various stages of radiation therapy.

[0027] A number of control tasks occur during the various phases of a radiation therapy event.

[0028] According to various examples disclosed herein, remote control of a radiotherapy device may be achieved. That is, all or at least some of the tasks of controlling the RTMD may be performed at a location remote from the location of the RTMD itself. In addition, according to various examples disclosed herein, distributed / shared control is possible. For example, a first user may participate in the control of the RTMD at the location of the RTMD using the user interface of the RTMD; and another second user may participate in the control of the RTMD, for example, at a remote location, simultaneously and in collaboration with the first user. Collaborative control is possible where multiple users at different locations collaborate to control the RTMD.

[0029] According to various examples, this is achieved through a server-hosted control application that provides a user interface (UI) for displaying and adjusting the values ​​of multiple device parameters of the RTMD. The adjusted values ​​can then be provided to the RTMD.

[0030] The UI can be accessed by multiple clients. The UI can be implemented through a web page.

[0031] According to various examples, techniques are presented that enable the value of a device parameter to be adjusted simultaneously by multiple users who may be at a remote location and / or locally at the RTMD. Specifically, techniques are disclosed that avoid conflicts when adjusting the value of a device parameter when multiple users are involved in the control of the RTMD. For example, according to reference embodiments (e.g., those described in US2007 / 0041496 A1), if a first user (e.g., via remote control) adjusts the value of a given device parameter and a second user (who may be located at another location different from the first user, e.g., locally at the RTMD) adjusts the value of the same given device parameter at approximately the same time, incorrect settings or unintended configurations may result.

[0032] According to various examples, this disadvantage is mitigated by maintaining a digital twin of the RTMD at a server. The digital twin can store the latest values ​​of the device parameters of the RTMD and can be synchronized (e.g., substantially in real time) with a control module (typically an embedded software control module) at the RTMD, which is responsible for maintaining and applying the corresponding associated values ​​of multiple device parameters. Thus, in the event that the value of the device parameter is updated at the digital twin, this adjusted value of the device parameter is automatically and with low latency (e.g., substantially in real time) propagated to the control module at the RTMD. Similarly, any adjusted value of the device parameter generated by user interaction via the UI of the RTMD is automatically and with low latency propagated to the digital twin. The digital twin is thereby kept synchronized with the RTMD.

[0033] Additionally, in the event that the value of the same given device parameter is updated simultaneously at both the digital twin and the RTMD, conflict resolution may be performed that defines certain conflict resolution rules. The conflict resolution algorithm may reside at the RTMD, for example, at a corresponding control application at the RTMD.

[0034] According to various examples, in order to facilitate the digital twin at the server, a data connection can be established between the server and the RTMD. Specifically, the data connection can be via the Internet or a general wide area network. The data connection can be implemented, for example, at the application layer of the open system interface (OSI) protocol stack. The data connection can thus enable an application for remote configuration executed at the server to send or receive data to a corresponding application at the RTMD. The data connection can also be implemented at a lower layer of the OSI protocol stack. For example, the data connection can be implemented at layer 2 or layer 3. IP-in-IP tunnels are possible. Here, data packets exchanged along the data connection can be encrypted in layer 3 of the OSI protocol stack and then addressed to a destination defined according to an endpoint associated with the data connection.

[0035] Repeated bidirectional synchronization of the values ​​of the plurality of device parameters may then be performed between the application executing at the server and the RTMD via the data connection.

[0036] Figure 1 Schematically illustrated is a system 71 according to various examples. The system 71 comprises a RTMD 91. For example, the RTMD 91 may be located in a hospital 90, for example, defined by a local area network (LAN) connected to the Internet 81.

[0037] The system 71 also includes a server 95. The server 95 may be located in the cloud, ie, remote from the hospital 90 and the RTMD 91. The server 95 and the RTMD 91 may be connected via the Internet 81.

[0038] The server 95 executes an application 61 for remotely configuring multiple device parameters of the RTMD 91. The application 61 may provide a UI to the user, and the UI is used to display and implement adjustment of the values ​​of the multiple device parameters. The application 61 may implement a digital twin of the RTMD 91.

[0039] Although in Figure 1 In the case of , server 95 is connected to only a single RTMD 91, but as a general rule, server 95 can be connected to multiple RTMDs. Server 95 can host multiple instances of application 61, one for each RTMD. Thus, multiple digital twins of multiple RTMDs can be implemented at server 95. For example, each instance of application 61 can be instantiated on a virtual machine set up by server 95. Alternatively, each instance of application 61 can also be instantiated in a corresponding container instantiated at a single virtual machine at server 95.

[0040] like Figure 1As shown, multiple user clients 98, 99 can access an application 61 executed at a server 95. For example, the application 61 can implement hosting of a web page that can be accessed by the clients 98, 99 through a browser executed at the clients 98, 99. The clients 98, 99 can also implement an application that serves as an interface to the corresponding data provided by the application 61.

[0041] The server 95 may access a database / data repository 96. Various data may be stored in the data repository 96. For example, patient information of patients to be treated by the RTMD 91 may be stored in the data repository 96. Alternatively or additionally, user information of users participating in the control of the RTMD 91 may be stored in the repository, for example, contact information of various parties associated with the radiation therapy event.

[0042] The UI of the application 61 may be accessed via the client 98, 99. For example, the UI may provide a web page via which the current values ​​of the device parameters may be displayed, the web page also providing the possibility to adjust the value of one or more of such device parameters. The web page may be hosted by the application 61 executed at the server 95 and may be loaded by the client 98, 99.

[0043] For example, another application 62 may be executed at the RTMD 91. Such an application 62 may also provide a UI for displaying and adjusting the values ​​of a plurality of device parameters, for example using a human machine interface (HMI) provided locally at the RTMD 91. The application 62 may also interface with an embedded software control module ( Figure 1 1). The embedded software control module can control the radiation applicator of RTMD 91. Application 62 can set the value of the device parameter for control at the radiation applicator in the corresponding memory access of embedded software control module 161. This corresponds to the hierarchy in control. At the application level, application 62 adjusts the value of the device parameter; then, the recommended value is propagated to the hardware-adjacent embedded software control module 161.

[0044] The application 62 may also implement a conflict resolution function. For example, if the application 61 through the server 95 requests to update the value of a given device parameter through a corresponding adjustment input, and at the same time or substantially at the same time, the same given device parameter is updated to another value through the HMI provided at the RTMD 91, the conflict resolution function of the application 62 may determine how to resolve the conflict based on one or more criteria. Such criteria may include, but are not limited to: user permissions of different users associated with the adjustment of the value of a given direct device parameter; priorities associated with local adjustments versus remote adjustments; timestamps associated with corresponding user requests for adjusting the value of a given device parameter; and the like. For example, the user permissions may be predetermined and may assign a higher priority to a user adjusting the value of a given device parameter remotely than to a user adjusting the value of a given device parameter locally. In this case, adjustments made by the user through the server 95 may take precedence over adjustments made locally by the user via the HMI of the RTMD 91. For example, based on a corresponding predetermined priority associated with local adjustments relative to remote adjustments, local adjustments may always take precedence over remote adjustments of the value of a device parameter. In yet another example, even small differences in timing associated with the corresponding adjustments may be considered; for example, the most recent adjustment may take precedence over any previous adjustments. When the conflict is resolved, the corresponding adjusted value may be propagated to the embedded software control module 161. When the conflict is resolved, a corresponding warning message may be output, for example, via the HMI of the RTMD 91 and / or via a UI provided by the application 61 at the server 95.

[0045] Figure 1 Also shown is a data connection 189 between the server 95 and the RTMD 91. The data connection 189 is made via the Internet 81. The data connection 189 can be used to transfer data between the RTMD 91 and the server 95. For example, repeated two-way synchronization of values ​​of multiple device parameters of the RTMD 91 can be implemented between the application 61 and the RTMD 91 via the data connection 89. The applications 61, 62 can communicate with each other, for example, to implement repeated two-way synchronization of these values.

[0046] Figure 2 In another embodiment, system 71 is shown. Figure 2The case where the RTMD 91 includes a gateway module 92 is shown. The gateway module 92 can implement connection functions. For example, data traffic from and to the Internet 81 can be routed via the gateway module 92. The gateway module 92 can implement encryption functions. The gateway module 92 can serve as an endpoint for a data connection 89. For example, establishing a data connection 89 at a server 95 can include transmitting a connection establishment request message to the gateway module 92. The establishment request message can be associated with access credentials for the cloud server 95. Therefore, the establishment of the data connection 89 can be limited to a trusted corresponding server 95 at the RTMD 91.

[0047] exist Figure 2 In the case of the present invention, the gateway module 92 is shown as a part of the RTMD 91. In some examples, the gateway module 92 can also be arranged separately from the RTMD 91 in the local area network of the hospital 90. The RTMD 91 and the gateway module 92 can then communicate via the LAN of the hospital 90.

[0048] Figure 3 RTMD 91 is schematically illustrated. RTMD 91 includes processing circuitry 151 including processor 153, non-volatile memory 154, communication interface 152, and human machine interface 155. For example, HMI 155 may include a monitor, keyboard, mouse, etc. Voice control is possible. Processing circuitry 151 implements application-level functionality for controlling RTMD 91.

[0049] The processor 153 may execute the application 62. The application 62 may have multiple tasks, such as displaying and adjusting device parameter values ​​of the RTMD 91, performing integrity checks on device parameter values, participating in repeated bidirectional synchronization of multiple device parameter values ​​with the application 61 executing at the server 95, interfacing with the embedded software control module 161, conflict resolution, etc.

[0050] The processor 153 can also execute the implementation of the gateway module 92 (see Figure 2 ) application, thereby transmitting data via the communication interface 152. The gateway module 92 can also be implemented by the application 62. The gateway module 92 can also be arranged separately from the RTMD 91.

[0051] The processor 153 may also communicate with an embedded software control module 161. For example, the embedded software control module 161 may be implemented on a microcontroller, a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). The embedded software control module 161 may control the radiation applicator 162 via corresponding control commands, typically voltage and current output via a digital-to-analog converter of the corresponding underlying hardware. The embedded software control module 161 implements hardware adjacent functions.

[0052] To this end, the embedded software control module 161 may execute control software, for example, based on program code stored in the internal memory 169 of the embedded software control module 161. The control software may also access the values ​​of device parameters stored in the memory 169. For example, a treatment plan generated based on user interaction via the HMI 155 and then stored in the memory 154 may be propagated down to the embedded software control module 161 at some point, and the corresponding values ​​may be updated in the memory 169. A hardware-adjacent integrity check may be performed at this point on the values ​​proposed by the treatment plan against the hard-coded threshold settings stored in the memory 169.

[0053] Figure 4 The server 95 is schematically shown. The server 95 includes a processor 183, a non-volatile memory 184, and a communication interface 182. The processor 183 can load and execute program code from the memory 184. When executing the program code, the processor 183 can execute the application 61, thereby providing a UI for displaying and adjusting the values ​​of multiple device parameters of the RTMD 91. The UI can be accessed by the client 98, 99 via the communication interface 182, for example. The processor 183 can also access the data repository 96. Alternatively or additionally, a local data repository can be stored in the memory 184. The application 61 can be executed by a virtual machine or container set at the server 95. Multiple instances of the application 61 can be executed; the multiple instances are associated with different RTMDs.

[0054] Figure 5 is a flow chart illustrating various aspects of a radiation therapy event. A radiation therapy event may be performed by RTMD 91. A radiation therapy event includes Figure 5 Multiple stages are shown. Radiation therapy does not have to include all of these boxes. Sometimes, for example, the pre-radiation stage at box 3010 can be optional; sometimes, the post-irradiation stage at box 3020 can be optional.

[0055] Initially, a planning phase is performed at box 3005. During the planning phase, a radiation therapy plan is set for a radiation therapy event. This means that certain values ​​of equipment parameters are adjusted according to patient-specific characteristics.

[0056] For example, a patient profile may be loaded, for example, from the data repository 96, at the beginning of the planning phase at block 3005. The patient profile may specify, for example, patient demographics, such as age, gender, etc. The patient profile may include a patient unique identifier. The patient profile may specify a treatment site. The patient profile may specify a history of previous radiation treatments performed for the patient.

[0057] Based on the patient profile, one or more users may then adjust the values ​​of a plurality of device parameters associated with the treatment plan. Examples would include the accelerating voltage of the x-ray radiation, the duration of the radiation, the shape of the applicator (defining the spatial shape of the radiation), etc. The treatment plan may include such a set of device parameter values. Since the setting of the treatment plan during the planning phase at block 3005 may occur a considerable time prior to the actual radiation, the set of values ​​of the device parameters included in the treatment plan is typically not directly propagated to hardware adjacent control modules (such as in conjunction with Figure 3 Embedded software control module 161 discussed above). Typically, this occurs prior to radiation, for example, in the pre-irradiation phase at box 3010 explained next.

[0058] The pre-irradiation phase begins at box 3010. Here, the patient may be placed in the application position next to the RTMD. The predetermined treatment plan obtained from the planning phase at box 3005 may be cross-checked and confirmed by medical personnel.

[0059] The values ​​of the device parameters indicated by the treatment plan may be propagated to the control software executed by the embedded software control module 161. The corresponding internal memory 169 may be updated. This may be triggered by approval confirmation of the treatment plan by one or more users.

[0060] The approval may be provided directly at the RTMD, for example, via the user interface of the RTMD. The approval may also be provided remotely (ie, via the server 95).

[0061] Once the radiation plan has been licensed / approved, the method can start and perform the irradiation at box 3015. When performing the irradiation during the irradiation phase at box 3015, the latest values ​​of the equipment parameters can be monitored to ensure compliance with the treatment plan. Thus, any deviation can be detected immediately and the radiation can then be suspended.

[0062] Next, during the post-irradiation phase at block 3020, the radiation therapy may be summarized in a medical report. For example, the total dose applied, post-treatment observations, etc. may be summarized in the medical report. The medical report may be published to a corresponding repository.

[0063] According to the techniques disclosed herein, remote control of the RTMD is possible in any of blocks 3005, 3010, 3015, and 3020. This means that certain actions associated with a stage can be performed by a user located away from the RTMD. Sometimes remote control can be enabled only in one or some of these stages; sometimes, all blocks can be remotely controlled. The application 61 at the server 95 can be combined with the application 61 to enable remote control of the RTMD. Figure 5 One or more of the disclosed stages may be performed.

[0064] Figure 6 is a flow chart of a method according to various examples. Figure 6 The method is used to remotely control an RTMD, such as RTMD 91 discussed above. Figure 6 Some blocks of the method may be executed by the server, and Figure 6 Some blocks of the method may be executed locally at the processor or other processing hardware of the RTMD. Figure 1 and Figure 2 Various aspects of distributed processing are discussed.

[0065] The order or sequence of the blocks may vary depending on the implementation. Not all blocks need to be performed in all cases; various blocks may be optional.

[0066] At block 5005, access management may optionally be performed. In some cases, access management at block 5005 may be performed only after the data connection is established at block 5010, or may be performed while the data connection is established at block 5010. Thus, block 5010 may sometimes be performed before block 5005 is performed.

[0067] Access management can be performed at the server level and / or at the user / client level. Both scenarios are explained below.

[0068] For example, a connection establishment request message may be transmitted from the cloud server 95 to the RTMD 91. The connection establishment request message may trigger the establishment of the data connection 89. The connection establishment request message may be associated with access credentials of the cloud server 95. These access credentials may then be checked at the RTMD, for example by forming a lookup in a corresponding database / repository. Thus, only authorized servers are allowed to establish the data connection 89.

[0069] It is not necessary in all cases to check the access credentials of the server 95 at the RTMD 91. For example, in some cases, the access credentials of the server 95 may be checked at another server ( Figure 1 or Figure 2 The access credentials of server 95 are checked at (not shown).

[0070] In some cases, one or more user identities of users who are authorized to access the application 61 may be provided from the RTMD to the server 95. The server 95 may then check the access rights of users accessing the user interface provided by the application 61 based on such one or more identities. When connecting to the server 95 using a client 98, 99, the user may be required to enter their credentials (e.g., password, 2-factor authentication, certificate-based authentication, to name just a few examples) into the UI. Thus, only authorized users are allowed to participate in the remote control of the RTMD 91. It may also be possible to allow only certain clients (i.e., at the hardware level) to access the UI provided by the application 61 executed by the server 95.

[0071] Also in this case, one or more user identities of users and / or clients authorized to access application 61 may not be provided to server 95 from RTMD 91, but rather from another server acting as a central authority. Such user identities may also be stored in data repository 96.

[0072] At block 5010, a data connection 89 is established. This may include, for example, establishing a VPN tunnel. Alternatively or additionally, this may include establishing an application layer communication protocol between an application 61 executing at a server 95 and an application 62 executing at a RTMD 91. Alternatively or additionally, this may include setting up encryption along the data tunnel.

[0073] Both the server 95 and the RTMD 91 participate in establishing the data connection 89 .

[0074] The establishment of the data connection 89 facilitates low latency communications between the server 95 and the RTMD 91. In addition, status pings may be repeatedly transmitted along the data connection 89; thereby ensuring that the digital twin implemented at the server 95 remains up to date with respect to the RTMD 91. The integrity of the data connection 89 may be monitored to avoid any loss of synchronization between the digital twin at the server 95 and the RTMD 91 due to the data connection 89 being disabled or failing in functionality.

[0075] Next, at block 5015 , an application may be executed to adjust the values ​​of one or more device parameters of the RTMD 91 .

[0076] Sometimes, the application may be executed first at block 5015; and only at block 5010 may the data connection be established. Thus, block 5015 may sometimes be executed before block 5010 is executed.

[0077] Some example device parameters that may be remotely configured using application 61 are disclosed below in Table 1.

[0078]

[0079]

[0080]

[0081] Table 1: Examples of device parameters that can be remotely configured via the techniques disclosed herein.

[0082] In some cases, the UI provided by the application executed at block 5015 may depend on the stage of the radiation therapy event. In other words, as the radiation event progresses, for example, according to Figure 5 When the treatment progress indicator is in the stage, the UI can be reconfigured according to the value of the treatment progress indicator, as explained in Table 1. Depending on the stage, different functions can be provided. For example, it is conceivable that in the planning stage (see Figure 5 : Box 3005), various values ​​of device parameters can be adjusted; on the other hand, during the pre-irradiation stage (see Figure 5 : box 3010), such adjustment of the values ​​may no longer be possible. During the pre-irradiation phase, only a certain predetermined treatment plan including a corresponding set of values ​​for the device parameters may be permitted for application; or return to the planning phase. During the irradiation phase, an up-to-date display of the device parameter values ​​currently applied by the RTMD 91 may be provided; manual adjustment may not be possible. On the other hand, the irradiation may be completely aborted via the UI. Specific phases of the radiotherapy event may be synchronized between the server 95 and the RTMD 91 by repeatedly transmitting corresponding values ​​of the progress indication (see Table 1) over the data connection 89.

[0083] At block 5020, optionally, the adjusted value may be monitored for compliance with one or more threshold settings. For example, one or more threshold comparisons may be performed, such as to compare the acceleration voltage to a corresponding threshold and / or to compare the acceleration current to one or more corresponding threshold settings, etc. Such monitoring of value compliance may be performed at the server 95 via the application 61 and / or at the RTMD 91 via the application 62.

[0084] The one or more threshold settings may be parameters that are themselves adjusted at block 5015 via the application 61 (see Table 1: "Threshold Settings"). Enhanced configuration is possible by adjusting the threshold settings via remote control using a UI provided by the application 61. At the same time, because hardware-adjacent integrity checks on the values ​​may be implemented later, e.g., with the aid of the embedded software control module 161, the safety of the radiation is not compromised.

[0085] At block 5025, repeated bidirectional synchronization of values ​​of a plurality of device parameters is performed. The synchronization is performed between the application 61 executing at the server 95 and the RTMD 91. The synchronization is performed via the data connection 89 established at block 5010. For example, the application 61 may communicate with the application 62.

[0086] Repeated two-way synchronization may be based on push notifications transmitted via the data connection 89 .

[0087] In a first example, once an adjustment of the value of a given device parameter is detected at application 61, application 61 can provide such a push notification to application 62. Likewise, once an adjustment of the value of a given device parameter is detected at application 62, application 62 can provide such a push notification to application 61. That is, both uplink and downlink push notifications are possible. Thus, on-demand, repeated, bidirectional synchronization of the values ​​of medical device parameters is facilitated.

[0088] In a second example, changes in the values ​​of multiple device parameters in the control software executed by the embedded software control module 161 may be monitored at the RTMD 91. Then, in response to detecting a change in a given value of any of the multiple device parameters, a push notification of the change may be provided to the server 95, and more specifically, to the application 61 executed by the server 95. This ensures that the digital twin at the server 95 includes the latest values ​​related to the hardware-adjacent controls.

[0089] Any adjustment of a device parameter value input via the HMI 155 at the RTMD 91 may trigger such a push notification to the server 95 .

[0090] As part of block 5025, conflict resolution may also be performed. For example, a first change to a given value of a given device parameter may be triggered at server 95 via application 61; and a second change to the same given value of a given device parameter may be triggered at RTMD 91 via application 62. In this case, conflict resolution may be performed for both changes. One or more conflict resolution rules may be applied, such as, for example, user permissions associated with different users associated with the first change and the second change; predetermined priorities with respect to local adjustments to the values ​​of multiple device parameters versus remote adjustments to the values ​​of multiple device parameters; or timestamps associated with the changes.

[0091] Conflict resolution is not required in all cases. For example, a check-in / check-out procedure may be used by different users, operating on different client devices or locally at the RTMD, who may check in to a corresponding change mode before changing any device parameter value. Such a check-in is enabled only if no other user is simultaneously checked in. In this case, it is ensured that only one user can change the value of a device parameter at a time. The corresponding check-in / check-out parameters may also be synchronized between the RTMD 90 and the server 95 (i.e., the corresponding application).

[0092] At block 5030, a downlink notification of a change in a given value of a given device parameter may be obtained from the server 95. The downlink notification may initially be obtained at the application 62. The expected change in the value of the given device parameter may then be handled in different ways depending on the implementation.

[0093] In some cases, new values ​​for given device parameters may be written into the treatment plan by the application 62. For example, the treatment plan may be stored in the memory 154. The treatment plan may be stored for later use, such as during the pre-irradiation phase 3010 or even the irradiation phase 3015.

[0094] In some cases, the new value of a given device parameter may also be propagated directly to lower layers of the control stack of RTMD 91. For example, a new value of a given device parameter may be provided to embedded software control module 161, such as by application 62, in response to being notified of a change in a given value for use in an application program executed by embedded software control module 161 (see Figure 3 ) in the control software executed by the embedded software control module 161. In any case, once the value is adjusted at the embedded software control module 161, the embedded software control module 161 can implement a further check on the integrity of the corresponding given value (box 3031). For example, the embedded software control module 161 can monitor that the given value complies with one or more hard-coded threshold settings in the memory of the embedded software control module 161. This can involve a hardware-adjacent integrity check of the adjusted values ​​of the device parameters. For example, the radiation applicator 162 can read these values ​​maintained by the control software executed by the embedded software control module 161. This hardware-adjacent integrity check can supplement the application-level integrity check of the values ​​of the device parameters performed at box 5020. The level of safety can be improved; operational errors can be avoided.

[0095] In the case where the values ​​of items maintained by the control software are not updated immediately at block 5030 (but the treatment plan is stored at a high level for later use), the values ​​maintained by the control software may be updated later based on the treatment plan, such as in the pre-irradiation phase (see Figure 5 : Box 3010). That is, box 5031 can be performed after box 5035 or even after box 5045.

[0096] The various aspects disclosed in conjunction with blocks 5005 to 5030 relate to the planning stage (see Figure 5 : Frame 3005). Then, the method starts from frame 5035.

[0097] At block 5035, a check is made to see whether the pre-irradiation phase has started (see Figure 5 : Box 3010). The pre-irradiation stage is generally optional.

[0098] For example, in some cases, the pre-irradiation phase may be triggered only by a user operating the RTMD 91, such as by a corresponding control command input via the HMI 155 (i.e., remote control is not possible). This may ensure that the patient is properly positioned so that the change can be initiated. This increases safety.

[0099] The pre-irradiation phase can be indicated by a corresponding treatment progress indication, see Table 1. By means of the treatment progress indication, the server 95 can be informed that the pre-irradiation phase has been initiated (e.g., by a local user). The UI provided by the server 95 can then be reconfigured to, for example, show different buttons and / or HMI elements. This is because different control tests are usually required during the pre-irradiation phase and during the planning phase. For example, during the pre-irradiation phase, the treatment plan may need to be reviewed and possibly approved; while during the planning phase, the treatment plan may need to be set up, for example, from a template or from scratch.

[0100] In some cases, approval of treatment may be required within a certain predetermined duration. In other words, when the pre-irradiation phase is triggered at block 5035, a timer may be initialized, and it may be monitored whether the timer expires before all parties agree. This ensures that a "four-eyes" approval plan is implemented in the event that multiple parties collaborate simultaneously to approve a treatment plan. Standardized times for parties located in different time zones may be considered.

[0101] For example, at box 5040, in response to the value of the treatment progress indicator being equal to the pre-irradiation stage, the server 95 can perform a lookup in the data repository 96 for contact information of multiple parties associated with the radiation treatment event. For example, the contact information can be determined based on another device parameter (i.e., an approval scheme) (see Table 1). The approval scheme can determine a set of predetermined users who need to approve the treatment plan before proceeding to the irradiation stage. The users can be defined by their role (e.g., "radiation oncologist") or by their unique identity (e.g., "Dr. John Doe"). The approval scheme can be a fixed setting or can be predetermined during the planning stage as a device parameter synchronized between the RTMD 91 and the server 95.

[0102] A conference call can then be established based on the contact details. Such contact details can, for example, include routing addresses of conference call applications executed on the mobile devices of the multiple parties. That is, the called group can be automatically triggered. This automatic triggering of the conference call has the benefit of automatically involving all necessary parties required to approve the treatment plan (e.g., radiologists and oncologists, as well as equipment technicians). By automatically connecting these users, the time required for radiation can be reduced. It can be ensured that the correct users are involved; for example, different patients or radiation treatment events can be associated with different users.

[0103] At the check in block 5045, the consent of all such parties involved in the conference call may be required to proceed to the irradiation phase (see Figure 5 :Frame 3015).

[0104] There are a variety of options for individually approving the treatment plan. For example, approval may be entered via a UI implemented by application 61 and / or an HMI of RTMD 91. Alternatively or additionally, approval may be entered via a user interface element provided by a teleconferencing application executing on the mobile devices of the multiple parties. For example, the teleconferencing application may communicate with application 61 executing at server 95 to signal approval. For example, the teleconferencing application may query the approval of the users participating in the teleconference using a corresponding button interface element.

[0105] Approval may require entering user credentials and / or providing a signature (eg, a digital signature).

[0106] Such techniques facilitate implementation of a "four eyes" approval protocol for the irradiation phase. The "four eyes" approval protocol can be ensured even in situations where, for example, a radiation oncologist is not physically present at the site of the RTMD 81.

[0107] At block 5050, irradiation of the patient is performed. This may include sending a corresponding trigger command from the software 62 executed by the processor 153 to the embedded software control module 161. The trigger command may only be sent if all parties associated with the corresponding treatment event have previously approved the corresponding treatment plan, for example, by means of a corresponding conference call at block 5040.

[0108] The embedded software control module 161 then controls the radiation applicator 162 based on the values ​​of the device parameters stored in the local memory 169 (the values ​​of these parameters were previously set based on the UI provided by the application 61 and the UI provided by the application 62; see also box 5031).

[0109] The embedded software control module 161 may repeatedly and continuously report the values ​​of device parameters applied by the radiation applicator 162. For example, control values ​​and / or measured / observed values ​​may be reported to the application 62, for example.

[0110] Such values ​​can then be provided to the server 95, for example, to the application 61. This can help to monitor the radiation phase remotely. For example, these values ​​can be output via a UI provided by the application 61. Specifically, when the irradiation phase is performed at box 5045, the UI provided by the application 61 can be reconfigured. A UI can be provided to enable the latest values ​​of the device parameters to be monitored during irradiation. For example, the UI can depict the current value of a given device parameter (e.g., an acceleration voltage); and the set point value of the given device parameter can be further depicted in an associated manner according to the treatment plan. Thereby, any deviations can be immediately discovered. The UI can also display user interface elements that can abort irradiation.

[0111] In this state of continuous irradiation, low latency monitoring of the values ​​of equipment parameters may be desired. Where monitoring is performed remotely, techniques for detecting interrupted data connections 89 may be employed to avoid loss of real-time monitoring capability.

[0112] For example, it is possible to switch from packet-based communication (which can be used to transmit updated values ​​of device parameters during the pre-irradiation phase and / or the planning phase, see block 5025) to stream-based communication. Here, data resources are pre-allocated for multiple data frames of the corresponding data stream. However, this switch from packet-based communication to stream-based communication is optional.

[0113] A data stream comprising a sequence of data frames may be provided to the server 95, and each data frame may include the latest values ​​of one or more operating parameters of the radiating RTMD during the irradiation phase.

[0114] In this regard, the integrity of the data stream during the irradiation phase may be monitored at the server 95. Each data frame may be associated with an expected transmission timing. The server may immediately detect lost data frames by comparing whether a sequence of corresponding data frames are correctly received for a given transmission timing. Furthermore, out-of-order arrival of data frames may be an indication of a loss of integrity in the data stream.

[0115] In response to detecting that the integrity of the data stream is impaired, an abort command may be transmitted to the RTMD to abort the irradiation phase. Thus, in the event that the data connection provides only impaired quality, automatic abort of the irradiation may be facilitated (even though in fact the values ​​of the device parameters used or observed during the irradiation are in accordance with the treatment plan - however real-time monitoring at the server 95 is not possible). For example, the data stream may be implemented over the data connection, and the abort command may be transmitted using an alternative data connection. An alternative communication channel may be used, for example, via another access technology or using an alternative route via the Internet. Thus, even in the event of an impaired data connection, the abort command may be successfully delivered to the RTMD 91.

[0116] Alternatively or additionally using such an abort command, a positive and / or negative acknowledgement protocol may also be implemented. Here, the server may positively acknowledge each data frame or each set of data frames. This positive acknowledgement may also be transmitted via the data connection. Acknowledgements of the data frames may be monitored at the RTMD 91, for example by the application 62 or by the gateway module 92. Based on said monitoring, the irradiation phase may be selectively aborted. For example, in the event of a negative acknowledgement, the irradiation phase may be aborted. Alternatively or additionally, the irradiation phase may be aborted if a corresponding positive acknowledgement of a data frame is not received within a certain tolerance time span when transmitting a given data frame.

[0117] At block 5065, it is then checked whether the irradiation phase has been completed and whether the post-irradiation phase has begun (see Figure 5 : Block 3020). In the event that the irradiation phase has been completed (e.g., by completing all tasks included in the treatment plan or in response to an abort), the method begins at block 5070.

[0118] At block 5070, reporting on the irradiation event may be implemented. Such reporting may include drafting a medical report. The medical report may include details of the irradiation event. For example, the delivered dose, details of the treatment site, or any follow-up diagnosis may be included in the medical report. In some cases, the medical report may be drafted at least in part automatically, for example, based on treatment parameters derived from monitoring of the irradiation, for example, as described in conjunction with blocks 5050, 5055, and 5060.

[0119] The medical report can be drawn up on the server, for example by means of the application 61 .

[0120] The values ​​of the device parameters observed during the irradiation that has been performed may be included in the treatment report.

[0121] Treatment reports and / or medical reports may be provided to a data repository, such as data repository 96 .

[0122] A digital signature for treatment reports and / or medical reports may be provided, for example, based on the access credentials of a user involved in approving treatment plans and / or monitoring irradiation (see Box 5045, Box 5055, Box 5060).

[0123] In short, Figure 6 In the present invention, various aspects of RTMD control in conjunction with radiation therapy events have been presented. Variations in the order of the blocks are possible. Furthermore, it is not necessary to perform the Figure 6 For example, in Figure 6 , the data connection is shown to be established at box 5010 during the planning phase 3005. However, in some cases, the data connection can be established during each of the execution phases of the radiation event and released at the end of each phase. For example, the data connection can be established at the beginning of the planning phase and then released at the end of the planning phase. The data connection can then be (re)established at the beginning of the pre-irradiation phase at a later time (e.g., the next day or the next week).

[0124] Although the invention has been shown and described with respect to certain preferred embodiments, equivalents and modifications will occur to others skilled in the art upon the reading and understanding of the specification. The present invention includes all such equivalents and modifications, and is limited only by the scope of the appended claims.

Claims

1. A computer-implemented method comprising: - at the server (95), establishing a data connection (89) to the radiotherapy medical device (91) via the Internet, - executing, at the server (95), an application (61) for remotely configuring a plurality of device parameters of the radiotherapy medical device (91), wherein the application (61) provides a user interface for displaying and adjusting the values ​​of the plurality of device parameters, and - when the application (61) is executed, a repeated bidirectional synchronization of the values ​​of the plurality of device parameters is carried out between the application (61) and the radiotherapy medical device (91) via the data connection (89).

2. The computer-implemented method of claim 1, in, The plurality of device parameters include one or more threshold settings for values ​​of one or more additional device parameters of the plurality of device parameters, Wherein, the method further comprises: - Monitoring (5020) compliance of the values ​​of the one or more further device parameters adjusted via the user interface with the values ​​of the one or more threshold settings.

3. A computer-implemented method as claimed in claim 1 or claim 2, in, The implementation of the repeated bidirectional synchronization includes: at the radiotherapy medical device (91): obtaining a notification of a change in a given value of a given device parameter among the plurality of device parameters from the server (95); Wherein, the method further comprises: - at the radiotherapy medical device (91): based on the notification of the change of the given values, providing a request to an embedded software control module (161) for reconfiguring the given values ​​in control software executed by the embedded software control module, and - the embedded software control module (161) monitors the given value for compliance with one or more hard-coded threshold settings associated with the given value.

4. A computer-implemented method as claimed in any one of the preceding claims, in, The implementation of the repeated bidirectional synchronization includes: at the radiotherapy medical device (91): obtaining a notification of a change in a given value of a given device parameter among the plurality of device parameters from the server (95); Wherein, the method further comprises: - obtaining, at the radiotherapy medical device and from a human-machine interface, a request for a further change of the given value of the given device parameter, - performing a conflict resolution with respect to the change and the further change of the given value of the given device parameter based on at least one criterion, Wherein, the at least one criterion is optionally selected from the group comprising: user rights associated with different users associated with the change and the further change; a predetermined priority associated with local adjustment of the values ​​of the multiple device parameters and remote adjustment of the values ​​of the multiple device parameters; or a timestamp associated with the change and the further change.

5. A computer-implemented method as claimed in any one of the preceding claims, in, The implementation of the repeated bidirectional synchronization includes, at the radiotherapy medical device (91): monitoring changes in the values ​​of multiple device parameters in the control software executed by the embedded software control module (161) of the radiotherapy medical device (91), and in response to detecting a change in a given value of a given device parameter among the multiple device parameters, providing a push notification of the change in the given value to the server (95).

6. A computer-implemented method as claimed in any one of the preceding claims, in, The plurality of device parameters include a procedure identifier identifying a radiation therapy event at the radiation therapy medical device (91), The plurality of equipment parameters further include a progress indicator, which is associated with the process identifier and indicates a current stage (3005, 3010, 3015, 3020) of the corresponding radiotherapy event, and a value of the progress indicator changes at least between a planning stage, a pre-irradiation stage, and an irradiation stage. The functionality provided by the user interface is reconfigured according to the value of the progress indicator.

7. The computer-implemented method of claim 6, further comprising: - In response to the value of the progress indicator corresponding to the pre-irradiation stage: looking up contact information of multiple parties associated with the radiotherapy event in a data repository (96), and establishing a telephone conference based on the contact information.

8. The computer-implemented method of claim 7, in, The contact details include routing addresses for teleconferencing applications executed on the mobile devices of the parties.

9. A computer-implemented method as claimed in claim 7 or claim 8, in, The plurality of parties are predetermined according to an approval scheme defined by the plurality of device parameters.

10. A computer-implemented method as claimed in any one of the preceding claims, in, The establishing of the data connection (89) includes: the server (95) transmitting a connection establishment request message to the radiotherapy medical device (91) or another server, wherein the connection establishment request message is associated with the access credentials of the server (95).

11. The computer-implemented method of any preceding claim, further comprising: - obtaining from the radiotherapy medical device (91) or from a data repository (96) or from another server a plurality of user identities of users who are authorized to access the application (61), and - Checking access rights of a user attempting to access the user interface based on the multiple user identities.

12. The computer-implemented method of any preceding claim, further comprising: - at the server (95): receiving from the radiotherapy medical device (91) a data stream comprising a sequence of data frames, each data frame comprising updated values ​​of one or more operating parameters of the radiotherapy medical device (91) during an irradiation phase (3015) of a radiotherapy event at the radiotherapy medical device (91), Therein, the user interface is provided for monitoring the irradiation phase based on the values ​​of the one or more operating parameters (3015).

13. The computer-implemented method of claim 12, further comprising: - at the server (95): monitoring the integrity of the data stream during the irradiation phase and, in response to detecting that the integrity is compromised, transmitting an abort command to the radiotherapy medical device (91) to abort the irradiation phase.

14. The computer-implemented method of claim 13, in, The data flow is implemented on the data connection (89), The abort command is transmitted using an alternative data connection.

15. The computer-implemented method of any preceding claim, further comprising: - at the radiotherapy medical device (91): transmitting to the server (95) a data stream comprising a sequence of data frames, each data frame comprising updated values ​​of one or more operating parameters of the radiotherapy medical device (91) during an irradiation phase of a radiotherapy event at the radiotherapy medical device (91), - monitoring the acknowledgement of the data frames in the sequence of data frames, and - selectively aborting the irradiation phase based on said monitoring.

16. A computer-implemented method as claimed in any one of the preceding claims, in, The application (61) is executed during at least one of a planning phase (3005), a pre-irradiation phase (3010), or an irradiation phase (3015) of a radiotherapy event at the radiotherapy medical device (91).

17. A server comprising at least one processor and a memory, wherein: The at least one processor is configured to load a program code from the memory and execute the program code, wherein the at least one processor is configured to: - establishing a data connection (89) to a radiotherapy medical device (91) via the Internet, - executing an application (61) for remotely configuring a plurality of device parameters of the radiotherapy medical device (91), wherein the application (61) provides a user interface for displaying and adjusting the values ​​of the plurality of device parameters, and - when the application (61) is executed, a repeated bidirectional synchronization of the values ​​of the plurality of device parameters is carried out between the application (61) and the radiotherapy medical device (91) via the data connection (89).

18. A system comprising the server according to claim 17 and the radiotherapy medical device.

Images