This post is the first of several addressing common aspects of software in proton therapy systems. This will include suggested system structure, recommended technologies, internal communication strategies, tools and more.
Part 1: A Reason for Generic Structure
Proton Therapy systems share a common set of high-level requirements and usually a common feature set. Although very general, these features form the basis of a generic software architecture that we can use to suggest standard vendor interfaces, common communication tools and more.
Proton Therapy system vendors often have conflicting development strategies. In a small and competitive market they need to differentiate themselves technically but also need to be an effective OEM for a technically diverse product.
Whether components are developed in-house or by a supplier, there are common elements expected to be present in any modern system. Innovation can add to this pool, but more commonly will add to the feature set of those expected components. Software is an essential part of the system and an architecture that provides an extensible framework will enable and encourage that innovation.
Deployment
Until recently, most proton therapy systems have been built using a single accelerator with beam transport systems to provide protons to multiple treatment rooms, typically between three and six. Recently, single room systems have been considered more cost-effective and some vendors have considered marketing multiple single room systems instead of the single multi-room system.
A Strategy for Isolating Risks
A Proton Therapy System is software-centric, as are most modern systems of size or complexity. As such, its development follows guidelines set forth in standards such as IEC 14971, IEC 62304, IEC 60601-1-64 and others.
To address the risks associated with such a device, companies have adopted a strategy to separate proton production and transport from the clinical treatment process. The intent is to isolate the clinical equipment as a true medical device and use protons as a commodity, conceptually similar to electricity being delivered through a common wall outlet. This strategy allows engineers to follow a more rigorous development process for the Class C clinical software in the medical device itself, and use a standard development process for accelerator software.
Hazards that exist in the accelerator systems can be addressed directly by local components such that the associated risks during clinical operations are negligible. Protons must be delivered with specific energy, beam current and possibly a standard beam spot size to the clinical equipment. Variation in the quality of delivered beam can be dealt with in real-time by clinical equipment interacting with a dedicated safety system.
Organizing the Internal Systems
We can imagine distinct groups of components to support this strategy.
-
- Accelerator and beam transport components dealing with proton production.
- Clinical equipment dealing with treatment management and treatment delivery.
- Safety and Support elements support the components from Accelerator and Clinical groups.
The Safety and Support elements provide a common base to support Accelerator and Clinical components.
The next post in this series will describe the types of components suggested for each of these categories.
