This post is the second of several addressing common aspects of software in proton therapy systems.
Towards a Common Architecture
At the highest level, elements of any modern Proton Therapy (PT) system can be organized along some standard lines. These systems will all produce protons and direct them to a clinical treatment area, they will all need some method to physically support the patient, to verify tumor position, to monitor patient motion and so forth.
Developing a standard structure will help us understand how to best manage the engineering of software systems, especially the development and integration of software from vendors. It will also help us create the Design History File (DHF), Device Master Records (DMRs) and the various Bills of Material (BOMs).
Identifying these standard components is great, but what is the next step in defining an architecture? Somehow these pieces need to work together to provide a seamless, integrated system that presents itself as a simple clinical treatment device.
Several major component types are recommended here as being standard within most modern proton therapy systems. Interfaces, specifically the communication between these components is an important aspect of the architecture, which will be addressed in the next post in this series.
Accelerator and Beam Transport Systems
There are three general systems commonly used for producing and transporting protons. These include a source to generate and accelerate protons, another to transport them to a clinical area and a third to control and monitor them in real time. The beam will travel through an evacuated beam pipe, perhaps through short segments of air, to arrive at the clinical systems in a specific treatment area.
The accelerator systems are not responsible for delivering protons directly to the patient, only to a specialized clinical system that will do so.
1. Proton Production
There are several technologies in use today for producing protons but the most common are the cyclotron and the synchrotron.
A Cyclotron will produce a continuous beam of protons with a single, maximum energy. It requires separate beam adjustment components to reduce the energy to the prescribed setting for a given treatment. A cyclotron will only adjust the beam current and typically produces stable beam. Most modern medical cyclotrons used for proton treatment are superconducting to provide energetic protons in a relatively small space.
A Synchrotron accelerates protons to the prescribed energy for treatment, but requires incoming protons of a minimum input energy. A Radio Frequency Quadrupole, or RFQ can provide incoming protons when used with another small accelerator structure such as a drift tube linac (DTL). Using a specific RF frequency, the synchrotron then produces a pulsed beam as opposed to the continuous beam coming from a cyclotron.
Other technologies are being used, tested or researched for proton therapy such as the Linear Accelerator (Linac), Dielectric Wall Accelerator (DWA), or a combination of technologies such as the Synchrocyclotron, the Fixed-field Alternating Gradient (FFAG) accelerator and laser-driven accelerators. For a more complete overview of these technologies for Proton Therapy, check out Nuclear Instruments and Methods in Physics Research Section A, Volume 809, 11 February 2016, by Hywel Owen, Antony Lomax and Simon Jolly.
2. Beam Transport
A Beam Transport system contains electromagnetic elements to direct the positively charged protons to their intended target in a specific treatment area. The protons are typically moving with such momentum that their natural tendency to repel one another as particles is diminished. But they are attracted to the negatively charged magnetic fields along the beam path so two important affects, among others, occur; first, they can be focused back into a coherent beam to compensate for their natural divergence, and second they can be deflected as a beam to a different path. Both of these actions allow us to direct the beam where it needs to go.
Most of these elements are adjusted to match the incoming proton’s energy. Other technologies are used to support the system including water cooling for larger magnets and power supplies, vacuum systems, timing systems and beam diagnostics.
3. Accelerator Control
An integrated control system manages the adjustments needed to support the system throughout its lifetime, including those for installation, daily system startup, quality assurance procedures and regular treatment operations. Most systems will have elements from several suppliers, each with potentially different platforms and software APIs, so platform-independent communication software is important.
The Experimental Physics and Industrial Control System (EPICS) is a good choice, and recent updates to OPC Unified Architecture (OPC UA) make it a viable solution as well. Programmable Logic Controllers are standard solutions for vacuum, water and many other controls problems but specialized solutions are required for higher-level functions like beam diagnostics and run-time physics modeling for dynamic beam tuning. EPICS and OPC UA can work well together to provide a complete solution.
Clinical Systems
For any patient, the treatment process starts before coming to the treatment room. An extensive planning procedure takes place and one result of the process is a detailed treatment plan. The plan is forwarded to the Proton Therapy system before the patient is scheduled to arrive and contains all the information needed by the system to deliver protons to the tumor site.
When protons having the prescribed attributes arrive at the clinical area, the clinical systems will have already confirmed the patient’s identity, immobilized the patient to minimize motion during the application of the proton beam, taken images of the patient to ensure consistency with the prescribed position and adjusted the incident angle of the beam relative to the tumor site.
The clinical systems represent the essence of the proton therapy system as a medical device.
4. Treatment Planning
Treatment planning software (TPS) plays a critical role in delivering effective treatment, but is surprisingly not usually part of a proton therapy product. The software is typically marketed separately, giving oncologists a choice in how to plan and prescribe treatment.
The TPS calculates detailed treatment system parameters for all aspects of treatment preparation and delivery. Before the treatment is scheduled, the patient will discuss treatment options with their oncologist and if proton therapy is indicated, a planning session is arranged. Images are acquired, typically CT images reconstructed to provide a detailed view of the tumor site(s), and the TPS uses those images to develop a precise treatment prescription.
As shown above, the treatment decision process has several steps before planning is even considered. Note that certain cases might include chemotherapy and radiation therapy as part of a complete treatment.
The plan it creates indicates the precise locations and required dose to be delivered, along with details of patient positioning, the incoming proton beam angle and so forth. Modern pencil beam scanning systems are supported with precise parameters for every spot being irradiated in every treatment session. Visual displays help the oncologist with their planning process, along with a complete representation of each step of the treatment.
When the time comes for treatment to be administered, the TPS provides guidance to the proton therapy system for every step of treatment delivery, but does not communicate directly with the delivery system. Instead, the prescribed plan is forwarded to an Oncology Information System in it’s entirety, which will drive the treatment workflow.
5. Oncology Information
An Oncology Information System (OIS), like the Treatment Planning software is typically marketed and sold separately from the Proton Therapy system. It can exist as part of a more comprehensive Healthcare Information System, or as a larger suite of radiotherapy solutions. Keeping the software separate from the treatment delivery system can also provide a sense of balance, meaning the clinical team doesn’t feel that they are completely dependent upon the expertise of a single vendor. The choice of planning and management software is important to the oncologist and their team because most of their time is spent on planning, not on the treatment delivery itself.
The OIS holds the repository of detailed prescribed treatment plans from the Treatment Planning Software. After each treatment session, the actual delivered treatment results are recorded as well. This Record and Verify function is crucial to the overall treatment process and upcoming plans for sessions with that patient can be updated based on these results.
The OIS can also be referred to as an Oncology Management System (OMS) depending on the functionality it provides. Some vendors will drive the details of treatment delivery directly from this software, while other solutions send the plans to the proton therapy system for plan management, expecting the results to be returned upon completion.
Because the OIS and TPS come from other vendors, perhaps competitors, a standard software interface is used, based on DICOM-RT. A good overview can be found in the DICOM-RT and its Utilization in Radiation Therapy by Maria Y. Y. Law and Brent Liu, in the RSNA RadioGraphics Journal, Volume 29, Number 3. Although speaking to radiotherapy in general, it provides a good overview of the process and interactions.
6. Treatment Control
The Treatment Control System (TCS) coordinates the activities of the other clinical systems to manage the overall treatment plan. It will do so either actively or passively depending upon the Oncology Information software with which it interacts. To be specific, each session’s clinical workflow might be directed entirely by the OIS, or the OIS might simply send the detailed treatment plan to the proton therapy system for execution.
In either case, the TCS will direct each clinical action after receiving communication from the OIS. Having a TCS presents a single interface with which the OIS must communicate. Communication with the PT system’s components are encapsulated and private within the medical device so the vendor will not be dependent upon the OIS software to be updated when internal devices become obsolete or improvements are made internally.
7. Delivery Nozzle
The Delivery Nozzle is the heart of any modern proton therapy system. It takes the incoming proton beam and delivers it to the tumor’s location according to the details found within each prescription plan.
Modern PT systems often use a Pencil Beam Scanning system (PBS) implemented by the nozzle, although systems exist with scattering or double scattering nozzles. A pencil beam solution provides dose delivery to an array of spots at precise locations. Multiple sets of spots can be delivered to a common area and across varying depths within the region. This Intensity Modulated Proton Therapy (IMPT) solution provides greater precision and much less damage to surrounding structures in the body.
An important aspect of the nozzle’s function is safety. Although a separate Safety System exists in most proton therapy devices, the nozzle is considered an overall key safety element. It monitors the characteristics of incoming protons in real time and confirms the location of each delivered dose. Irregularities result in direct, immediate suspension of beam delivery.
8. Nozzle Positioning
The incoming angle of the proton beam is prescribed in the plan for each dose delivery session, called a field. The angle is adjusted by physically moving the delivery nozzle, which represents an engineering challenge because of the typical weight and shape of the nozzle itself, and the precision with which it must be positioned.
The patient’s entire treatment session for a given day might include several fields with differing beam angles. Depending on the nature of the tumor site(s), the treatment plan will prescribe beam delivery at almost any angle to the patient in a supine (face-up) position on a table, or while seated in a chair.
Certain types of treatment have the incoming beam for all prescribed fields to be at a simple angle such as at right angles to the patient, depending on the geometry of the patient’s positioning device. The PT system can be much simpler by not allowing arbitrary positioning of the delivery nozzle. A Fixed Beam treatment room provides a single incident beam angle, but allows the patient to be positioned (see below) to accommodate prescribed shallow angles. It also provides the customer with significant cost savings.
However, arbitrary incident beam angles are required for many treatment regimens, and the common solution is a large cylindrical structure that supports precise positioning of the delivery nozzle relative to the patient.
The Gantry as it is often called, requires precise motion control, counterweights, locking brakes and more to prevent free rotation. It must have precise repeatability as well. Gantry solutions are often cylindrical with a solid frame, perhaps an open frame with rigid cross-members to support the weight, or even some kind of cantilever design without full rotation ability. In any case, the gantry must support the weight of the nozzle, the equipment that transports the beam up to the nozzle and in some cases the supporting equipment such as power supplies, cooling water equipment and more.
Additional mechanical challenges come into play with the details of motion. The beam pipe delivering the protons in a partial vacuum must be able to rotate or move with the gantry. Electrical cables, cooling water hoses or pipes must be movable as well, with take-up reels or movable guidance sleeves.
9. Patient Positioning
A patient can expect to be in a treatment area for a half-hour or more, even though actual treatment time might be only a few minutes or less. Preparation includes time to immobilize the patient to ensure minimal motion during treatment, and other steps such as imaging the tumor and comparing it to those images acquired during the planning sessions.
The patient is typically placed on a table, often referred to as a couch, usually in a supine (face-up) position. Many tables can move through three axes and along three planes of motion to position the patient, specifically the tumor site, at a well-defined location to meet the incoming proton beam. Most modern table-like devices are driven by robotic arms and support simultaneous access to several degrees of freedom. They also provide features like patient weight deflection, automatic loading positions for gurney or wheelchair support and more.
Another method for patient positioning uses a chair for immobilization and support, but is not driven by the same robotic motion as a table. Chairs are used for ocular treatment or treatment of tumors in the upper body. An important distinction is that the planning process must including images acquired from the patient being in the same position as the expected treatment, so something like a vertical CT device is used. The chair can typically rotate about the horizontal axis and is movable to provide a slight forward or backward tilt of the patient.
The robotic aspect of chair’s motion can provide six degrees of freedom using a Stewart Platform, sometimes referred to as a hexapod. Full motion is typically not required for ocular-only treatments, but other equipment and software is required for optical tracking.
Treatment rooms that contain a chair will rely on patient positioning to adjust the angle of the incoming proton beam and do not require a gantry. The nozzle is typically directing the proton beam horizontally towards the chair.
Rooms with a table can have a movable nozzle system with a gantry system or a fixed-angle nozzle as the chair-based room will have, except the nozzle will be mounted such that the proton beam will be delivered vertically towards the movable table.
Systems that support a treatment table and movable gantry-based nozzle will sometimes have a single motion control system and software. This depends upon development details, specifically from the providers of those systems. A table manufacturer and gantry manufacturer might have such completely different software interfaces that a single motion control solution might not make sense. A central motion control system is a great choice if the the gantry and table are manufactured by the same organization.
10. Position Verification
Confirmation that the proton beam is going to the right place is a critical part of a safe treatment. Images are acquired of the intended target area during treatment preparation, either with a pair of x-ray imagers at right angles to one another, or with imagers rotating about the patient.
In either case, the images are compared to digitally reconstructed radiographs from the treatment planning session to determine how to align the proton beam with the tumor site. After position offsets are calculated, the table will be moved by a small amount to ensure its on target. If the offset is considered too great, the oncologist must determine how to deal with the discrepancy.
By having the x-ray imagers rotate around the patient, or the patient rotate in front of the imagers in the case of a chair-based configuration, cone beam computed tomography (CBCT) provides the clinicians with 3D volumetric imaging, allowing more precise proton beam alignment. Some vendors provide a separate CT system in the treatment room for volumetric imaging, but the patient would ideally be immobilized on the same table (couch) for both imaging and proton beam delivery to minimize differences between the imaging and treatment steps.
The images acquired during preparation, and the images available from the planning sessions are available for display before treatment begins. Quantitative data, physical dimensions and offsets are available to the clinician, and treatment can proceed when the patient position is adjusted if necessary and the image differences are confirmed.
In the time between the treatment planning imaging and these recent preparatory images being acquired, the patient may have lost weight, the tumor(s) might have changed size and other factors might have introduced more differences than expected. The clinician is ultimately responsible to ensure the accuracy of the beam placement, but the system software is expected to do as much as possible to support their efforts.
11. Motion Detection
Once positioned relative to isocenter and immobilized, the patient might still be monitored for any kind of motion, depending upon the details of treatment, the location of the tumor and the extent of immobilization. If significant motion occurs, proton beam delivery might be suspended or even terminated if the motion is extreme.
One common form of motion detection is respiratory tracking, which is important for lung or similar treatment. Detection can occur with simple cameras monitoring the patient’s inhale and exhale cycles and suspending beam delivery at specific times.
More elaborate forms include sets of cameras positioned to provide multiple views of the target volume area and suspending treatment when movement occurs.
A specialized form of motion detection could be used for motion tracking, which is being developed for certain specific types of treatments. Using more elaborate technologies, the intent is to keep the target volume in the path of the proton beam during treatment delivery. The beam can be adjusted in real-time to follow the detected motion of the tumor. An interesting paper presented at the 2018 IEEE International Workshop on Intelligent Robots and Systems describes some ongoing work. Check out Real-Time Tumor Tracking for Pencil Beam Scanning Proton Therapy by Sai Vemprala et. al.
Safety and Support Systems
A proton therapy system needs more than accelerator equipment and clinical components. There are supporting systems upon which those elements depend, enabling them to provide an integrated product.
12. Safety
Support for providing a safe product is engrained in the design and development of every major system. So what is the purpose of a separate Safety system?
It’s in the action to take when a problem occurs.
A Failure Modes and Effects Analysis (FMEA) for any significant system will provide insight into many different kinds of failures and the hazards that can result from them. It helps us find problems with specific components or assemblies. But hazards coming from integrated system use in a clinical context are usually identified by a larger set of tools and procedures, as those identified in the IEC 14971 standard for medical device risk management. It helps identify hazards at all phases of the product’s life cycle.
Many of the risks identified in a complex medical device like a proton therapy system can be addressed by individual components. But on a system-wide scale, certain hazards can result in risks that can only be addressed by system-wide actions. A Safety System could deal with those actions such as
-
- disabling the delivery of the proton beam
- disabling the delivery of x-ray beam used for position verification
- disabling the distribution of power to equipment being used or serviced
- ensuring that accurate measures of dose delivery are being made
- ensuring that dose delivery measurements are forwarded and recorded
Other hazards are understood to exist at a system-wide level, but the actions shown here, of disabling physical equipment needs to be done in real-time and require a robust, dedicated and standalone system without dependencies on other system elements outside of its control.
The Safety System should be a such a standalone system, capable of disabling delivery of any radiation or electrical current, based on simple logical inputs. In practical terms, the system might include more elaborate inputs with analogue or linear circuitry, but the philosophy is the same; to disable the source of the hazard to minimize the risk to people or equipment.
The intent is to have inputs coming from many sources as active but basic logic. For instance, a signal should come to the safety system if a door to the treatment room is suddenly opened during proton beam delivery. The logical signal must be held in an active state when the input is valid so that a cut wire indicates a fault, just as an open door would. If an electrical low state was to indicate proper operation, the system couldn’t detect wiring failures.
Other intelligent decisions could be made as well, such as a delivery nozzle setting a signal low if the incoming proton beam current is not within the prescribed range. That signal would be provided as an input to a Safety system, but would only be considered relevant if that treatment room is the one currently providing treatment in a multi-room facility.
A modern safety-rated Programmable Logic Controller (PLC) system is typically adequate for this purpose. More elaborate software-based systems could arguably introduce more risk to the process.
13. Data Management
In a general sense, any proton therapy system will make use of configuration data which will not often change, but also acquired data which will be constantly analyzed and growing in size.
A data management system needs to manage that data, to provide and control access to it. Several types of data, both dynamic and rather static in nature, would be supported:
-
- Hardware calibration data for possibly hundreds of devices, which allows conversion from hardware-dependent readings in many cases, to common engineering units expected by service people, and in some cases customer experts.
- Software configuration data that describe site-wide customer preferences and site-specific information about room location, personnel accounts, role information and passwords, the language of interaction and more. This data changes infrequently and does not contain patient data.
- Archived, recorded data from system devices, gathered at various rates to provide up-to-date information about system health, including trend analysis data. This data contains no patient related information.
- Logged messages describing major actions taken by each of the working systems as they operate. This can include detailed problem analysis messages, enabled by field service personnel to troubleshoot intermittent or expected issues. These messages make no reference to patient information.
- Audit data recorded for each delivered treatment to identify every system action that was taken, who initiated the action and any unexpected results. Patient information is not recorded, although a reference code may be included to provide access to patient data for authorized clinical users for HIPAA compliance.
- Fault log of unexpected actions seen by the Safety system and the actions taken in response. No patient related data is stored.
Each of these types of data elements have their own expected lifetime and a data management system would supply consistent graphical tools to access and manage the data. Conceptually the data management components provide a central repository with access to all data, but ideally it will exist as distinct entities in a networked environment. Most clinical customers expect data to be maintained onsite, but that can change as trust grows with technology.
Some data would benefit from a true database such as a relational database management system, while other data could reside in flat files of some kind.
A common API would be used to access all data in a consistent way. Most other software components would make use of that API to access data, so the underlying storage media and location could be adjusted or replaced with minimal impact to the overall system.
14. Service Management
Field Service and Support engineers need a way to install, configure, calibrate, diagnose and manage all elements within the system. A Service Management feature provides integrated graphical tools for those tasks, even if the bulk of the system might not exist, such is the case during installation and commissioning.
Integrated user interaction software is important here, and must be available on a few different platforms. Larger systems might have a dedicated accelerator control room for example, while smaller single or double-room systems will only have treatment control rooms. In either case, Field Service personnel need to access their tools and have a similar experience everywhere. This could be on an authorized laptop or mobile device, perhaps on a clinical treatment room screen if it’s not being used, or on a dedicated workstation in an accelerator control room.
Certain customers will allow remote access to service engineers over a secure channel, perhaps with onsite personnel to authorize and enable it.
But local or remote, these users need access to all of the types of data mentioned under the Data Management elements above. Access is HIPAA compliant and in some cases live-time, meaning that data and messages will appear on their screen as soon as the system produces them.
15. Network Management
A distributed system relies on a robust and fault-tolerant network. The components of the system will communicate using specific protocols but will also be isolated in well-defined subnets in certain cases.
For example, a site with multiple treatment rooms would ideally have each of those rooms exist on a separate subnet with controlled access. This reduces the risk of having beam requested from one room being delivered to another. It helps address the issue of a motion control request in one room causing inadvertent motion in another.
But the network provides more isolation and control as well. The Delivery Nozzle system could contain many magnets, some vacuum equipment and other networked devices similar to the main beam transport system. But an isolated subnet would ensure that magnet settings and other adjustments would only come from within the Delivery Nozzle system itself.
Certain elements would need access to multiple subnets, and a set of well-integrated management tools would provide an overall picture of the entire working system. A well-structured network is important to diagnosing and isolating problems and would include intelligent network switches, firewalls and more.
Conclusions
The architecture of a proton therapy system could be started by organizing some or all of the components suggested above, but would ultimately be tied to the system requirements specific to your product and the goals of your organization.
The intent is that these elements exist in a distributed environment as distinct entities working to provide a larger integrated system. While there are advantages (and some disadvantages) to a distributed system, the organization of these pieces in a larger system might be driven by other factors. Schedule will play a role for instance, as certain accelerator elements would have a longer lead time for delivery and integration, and could therefore be labeled as distinct assemblies or subsystems in the architecture to support better planning.
The assigned owner of each component could also contribute to the structure of the architecture. It’s unlikely that any PT system manufacturer will design and build every piece in the system, so acting as OEM, the company could structure the architecture depending on who builds what. A system having several treatment rooms with gantries will probably structure the overall architecture, the BOMs and documentation to include the gantry as a distinct subsystem because an external vendor is providing the engineering.
Creating a sound architectural structure and proceeding with good engineering of those components is great. But without proper requirements upon which to base them, without an understanding of their interface definitions and much more architectural and design work, these efforts could result in a set of well-engineered components that might not work well together. The final result might not to treat cancer as expected or address the intended use of the product.
In terms of integrated deployment, there are other elements of infrastructure that aren’t mentioned here but could provide benefits of scale. Common equipment racks, cables and even smaller items like switches or lights would present a consistent product face while helping to reduce costs.
The next post in this series will deal with interface definitions and communication technologies focusing on software. You might be interested in reading some thoughts on requirements management; check out Getting the Right Requirements Right.
