This is the third article in the blog series “Developing great software for particle therapy systems”. One of the characteristics of Particle Therapy (PT) machines is that they are particularly complex, and their integration is often quite underrated by novice engineers entering the PT field. The goal of the software is to connect all the subsystems and machine parts in a functioning whole that will treat patients effectively, safely and quickly. Today we look at one of the most important roles of software – securing the overall safety of a PT system.
PT Software – Safety Systems
Evolving Role of Software
Common sense states that the importance of software (SW) cannot be understated in the safety-critical aspects of a PT machine. Jay Flanz steps in and shares his opinion on the matter.
Jay sees the critical role of software in PT as an evolving theme in his life over the last few decades. But he believes we should start our considerations from the observation that, fundamentally, a non-working machine is not a safe machine, as the patient is not getting any treatment.
In the early days of the development of particle-therapy machines, the role of software in safety was not central, as the domain demanded tertiary or even higher redundancy. Using “wires and AND gates” was deemed more reliable, with control logic being “more tractable”. At that time in the PT industry, it was never acceptable to use software to mitigate severe hazards or highly probable faults.
To play the devil’s advocate, why was this so? Isn’t it true that software runs the way it is written, including all of the implied timing issues and integration issues that might be built into it? If there are reliability problems with software, it is not a generic trait of its technology, but it means either that the SW wasn’t written well or that there are variables in how it runs which aren’t explicitly embedded.
Accelerator Engineers are often not the best SW Designers
Due to a combination of some confusion and lack of understanding, software in PT evolved into something that was never fully embraced by control systems engineers for managing and supervising safety in PT machines.
The quality of the software is a function of how good the SW architects are and how well they’ve incorporated what’s essential in the design of their system. Historically, people who were good at devising accelerator control systems often did not excel in planning sophisticated software. Good accelerator engineers always knew how to set magnets and turn on the beam, but they didn’t necessarily know how to understand all the embedded implications of the software control system.
When particle-beam scanning came about, control software became even more critical, especially pertaining to safety measures and procedures. When you needed to perform an analysis or enable handling of statistics, noise and glitches without unsafely stopping, you couldn’t just have the option of a binary stop.
“Software for safety could be used similarly to the anti-missile system Iron Dome”
With the latter, you would never finish the treatment — it could be part of a two out of three logic, or it could have been employed to decide that something is safe, even if you thought it wasn’t, or vice versa. Jay points out this as an excellent example of how error handling in PT has been a much-ignored topic through the years.
Jay feels that it’s never really been done well by most people building PT control systems to his knowledge. On the other hand, it should be performed by developers that know and understand software architecture, design and development. Jay adds that he has concluded that software for safety could be even more effective if used similarly to the anti-missile defence system Iron Dome, a skeleton framework on the outside that independently watches what’s going on.
Software and Medical Standards
Uros Mitrovic agrees with Jay that software plays a progressively more vital part in PT safety systems subunits. So going from the “traditional” way of guaranteeing safety in PT, many control measures have been implemented in software as time goes by. For instance, with the recent introduction of artificial intelligence (AI) such as image registration algorithms for IGRT (Image-Guided RadioTherapy), controls engineers can enact risk-control measures purely in software.
To rely on software to irradiate patients safely and effectively, you need to have reliable and well-written software. And to create the latter, you have to follow a heap of medical standards meticulously. So software development for a particle therapy system is complex because it demands excellent software design capabilities combined with a deep understanding of the PT domain.
And all the relations between the multitude of devices, subunits and processes have to be strictly defined. Risk management plays a central role in the system as a whole and needs to be thoroughly and well tested, from the unit to the system level. That means that you must have unit tests, code reviews, static analyses, unit integration tests, system integration tests, workflow testing, end-to-end testing, and, finally, V&V (Verification and Validation). All of the latter can prove your software is safe and efficient to be used in the proximity of patients and personnel.
If you’d rather listen to the above, watch the video clip from the round table:
Read the rest of the series …
This is the third article in a series of blogs dealing with the challenges of developing good software for particle therapy systems and is based on the PTCOG 59 round table “SOFTware: the HARD part of proton therapy“.
- Part 1: “PT Software – The importance of subsystems integration for machine performance“
- Part 2: “PT Software – Why do Radiation Therapy and Particle Therapy machines differ so much in the control-room design“
- Part 4: Next time, we will look at PT system upgrades and the contribution of software to PT improvement.
ABOUT THE PANELISTS
Jay Flanz, PhD, served as Assoc. Prof. at the Harvard Medical School and Technical Director at the Francis H. Burr Proton Therapy Center of the Massachusetts General Hospital before retiring in 2020. Before that, he was Principal Research Scientist at MIT. At the former, he contributed to the design and optimisation of the proton therapy (PT) equipment and its adaptation to clinical uses. A central focus for Dr Flanz is upgrading the beam delivery modality for optimal patient treatments. He is the President of the Particle Therapy CoOperative Group (PTCOG) international organisation.
Zuofeng Li, PhD, is the chief physicist of the Meizhong Jiahe Medical Group (Concord Medical Holdings) and Guangzhou Concord Cancer Center. He is also a Fellow of the American Association of Physicists in Medicine, a Prof. at the University of Florida College of Medicine and was a Member of the steering committee of PTCOG. Dr Li has more than ten years of experience, specialising in radiation physics, brachytherapy, image-based brachytherapy, combined IMRT and brachytherapy delivery.
Thomas Rockwell (“Rock”) Mackie, PhD is Emeritus Prof. in Medical Physics, Human Oncology, and Engineering Physics at the University of Wisconsin-Madison and the Director of Medical Devices Focus Area at the Morgridge Institute for Research. He is a medical physicist that also developed a safer type of radiotherapy called tomotherapy, which produces less radiation without lowered effectiveness and is the marriage of a linac and a CT scanner. Dr Mackie is also focused on the development of a compact proton therapy machine.
Uros Mitrovic, PhD, is a technical expert with more than ten years of experience in several medical fields, including radiotherapy and medical imaging. He holds a PhD in medical image processing and is the author or co-author of several papers in prestigious journals, conference proceedings and US patents. At Cosylab, Uros is the Medical Product Portfolio Manager of OncologyOne product suite.
Others Also Read
A Novel Approach to Triggering and Beam Synchronous Data Acquisition
SwissFEL, the new Free-Electron Laser facility is a 740 m long accelerator with the goal of providing pulses of light between 6 and 30 fs long at a wa...