PT Software and its contribution to PT improvement and system upgrades
One of the pivotal roles of software is also enabling and supporting PT system upgrades. Since the introduction of particle therapy, PT systems have gone through many changes from one generation to the other. The software (SW) also influences the optimal design for upgrades. The latter and software have been entangled in the classical chicken or egg causality dilemma. Namely, up until now, operational PT machines rarely went through an upgrade stage, mainly due to the high cost of downtime — but this was also the result of the prevailing inefficient software design that disregarded modularity and subsystem separation.
The relationship between SW and system upgrading
Jay Flanz, who is also a technical director and has been involved practically in the whole lifecycle of PT machines, explains in greater detail the interaction between SW and system upgrades. He underlines that PT upgrades are an elaborate subject and that he probably devoted half of his professional life to the latter.
Jay thinks that the rapid pace of development in PT might be slowing down, as we’ve certainly evolved beyond the infancy stage of system capabilities. On the other hand, we now have about a hundred and ten particle therapy facilities worldwide, with most of them evolved into the scanning modality. Of course, the pace may pick up again with advancements such as flash and microbeams.
And although there’s always a reason to replace the LINAC, possibly every ten years, it is not clear whether the same holds for a particle therapy system. On the other hand, there will be improvements on the latter’s capabilities, like better real-time imaging, particle-based imaging and adaptive therapy.
The crux is that the mentioned improvements should be possible intrinsically, i.e. engineers should base them on existing systems. And the rub is that the latter is currently not likely because of the integration issues we’ve already mentioned in previous blogs — the way PT systems have been architected and specified. Jay believes that if the Beige Paper that he wrote on had been treated more seriously, things could have been different in the PT domain.
“The software has always been blamed for most difficulties regarding PT upgrades. Could this be because software engineers never stay at the same place for prolonged periods?”
Two examples of intrinsic improvements
We can look at the example of the patient positioner. It has six values that it has to exchange with the overall system continuously. Except for collision issues, that is all there is to it. Yet, in some systems, it is an act of heaven to replace a positioner quickly, although all you should have to do is pull it out, put in a new one and hook up those six wires — all in a weekend. But the systems today are not built to facilitate this.
Another example is scattering; it is so tightly woven into the software that it’s necessary to replace entire subsystems when upgrading it to scanning.
Jay remembers the time he developed the treatment point concept. With it, the idea of the room modality delivery would become generic, and upgrades would be more of a question of refurbishing the hardware and not so much the software. His concept was never really accepted.
The software has always been blamed for most difficulties regarding PT upgrades. Could one reason for this be that software engineers never stay at the same place for prolonged periods? And that there is never enough system knowledge shared by the current SW team when it’s time to perform the upgrade or a similar significant change? It wouldn’t be such an issue to upgrade with an adequately architected and modular system, which we will revisit when discussing outsourcing.
SW Systems are missing modularity
From the clinical user’s perspective, Zuofeng Li underlines that system software was often historically designed with no thought to future overhauling. Zuofeng mentions that he concurrently manages several treatment rooms and cannot upgrade just one room at a time. In his case, he must put the whole system into a testing mode to allow upgrading or changing something that impact the system — the rules are not separate enough to allow him to treat patients in other rooms while upgrading one room only.
But he wishes that the vendors would spend more time on software design to create modularity and arrange functionality in “several cubby holes” to protect the engineering team from significantly damaging the entire operation by one change. Of course, outright plug and play of subsystems would be even better.
Some vendors will refuse to provide subsystem upgrades unless the client revamps the whole system, which Zuofeng thinks is possibly the result of the initial software setup. Some upgrades are localised to just one room, as Jay’s example of upgrading the patient positioner illuminated. On the other hand, you often cannot independently install in-room Cone Beam CT (CBCT) in a room, which is unbelievable, he says.
On the other hand, particle therapy machines are systems with a 25 to 30-year lifetime expectancy, and it has become essential they are future-proof regarding upgrading.
And since safety is of utmost importance in PT, any stoppage of machine operation has a cascading impact on the clinical availability of services, which are off-line for an even longer extended period. For example, if the machine is down for three months, the patient pipeline will be unavailable effectively for one year because it takes time to ramp down on a patient and get the patient back.
PT Subsystems should be separate
Rock Mackie zooms out to the vista of radiotherapy systems in general. He underlines that you should never upgrade everything at once and that there have to be good divisions between subsystems. An excellent example in PT is the delivery of the beam out of the nozzle and beam steering. The latter should be fundamentally separable from the subsystem that positions the patient and verifies his position.
You can model just one subsystem and replace the patient with an orange crate and a phantom if it is. And then, you can move around and image the patient independently of whether you’re using a proton beam or a radiotherapy beam. And the beam should still be delivering precisely the same way as if there was a patient there. So there’s nice functional separability possible with this.
In this way, we can verify the patient position to check where the beam is. The older system can help confirm the newer system. Rock remembers when they introduced a beam-checking system with a detector for a megavoltage CT in photon therapy (tomotherapy), but it intercepted the beam. And that was extremely useful for verifying where the beam was. So they did not upgrade the control system of the accelerator and the verification system simultaneously. In one case, you want the verification system to be in a state where it can detect any small changes in the beam you’ve just implemented, underlines Rock. And, vice versa, you want any upgrade of the checking system to give you the same results if the beam is not changed.
So you can go about upgrading cleverly. Rock also believes you shouldn’t upgrade a treatment planning system and a radiotherapy system simultaneously. You should use one to verify the other.
It is optimal for the machine vendor that his software suppliers coordinate closely between themselves – or ideally, the vendor has one software supplier that understands the whole system. One such example, says Rock, is Leo Cancer Care which is partnering with Cosylab because of the latter’s broad knowledge of the proton radiation therapy fundamentals and the whole treatment workflow.
If you’d rather listen to the above, watch the video clip from the round table:
This is the fourth 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 3: “PT Software – Safety Systems”
- Part 5: Next time, we will look at PT and outsourcing software..
ABOUT THE PANELISTS
Subscribe to our newsletter
What kind of content are you interested in?