Radiation Therapy Interoperability: An Engineering Problem
Radiation Therapy Interoperability: An Engineering Problem
3. September 2026
min read
Radiation therapy
Let us say we have installed radiotherapy (RT) systems from various vendors, and on paper, the workflow holds. The simulation imaging system provides patient images to the treatment planning system, which produces the treatment plan and passes it to the oncology information system. The OIS then makes the approved treatment data available to the treatment delivery system, and the linac executes the prescribed treatment while reporting the treatment record back to the OIS. They all work because their interfaces are technically correct. Yet in production, someone is still manually checking every handoff.
This is the operational reality for most multi-vendor radiation therapy stacks, and it is where the gap between “connected” and “interoperable” systems quietly does its damage. Clinical staff deal with this discrepancy by re-entering data, verifying transfers and chasing plans that failed silently somewhere between two systems that both claim conformance to the same standard.
Commercial reality also plays out here as platform vendors have to be reliable connectors across mixed ecosystems rather than bottlenecks within them, and this commitment succeeds or fails at the interface layer where engineering discipline meets clinical operations.
In other words, workflow interoperability is not something that ships and then just works forever; it is a sustained engineering discipline. When things go wrong, it usually fails for reasons that have very little to do with the DICOM standards themselves.
What workflow interoperability actually means in an RT stack
As stated, a process moves patient data sequentially through several interfaces: from imaging to treatment planning, from treatment planning to the OIS, from the OIS to the control system, and ultimately to the delivery hardware. Each of the lines above represents another interoperability agreement (protocol, error surface, validation requirements) that can pass conformance testing yet still cause your processes to fail in ways that only become apparent after it’s been put into clinical use.
DICOM only defines how the data is formatted and does not address what happens if the previous step provides a plan with a structural representation that the next step wasn’t anticipating, or if safety interlocks identify parameters as invalid even though they were valid last quarter. It is only after a team has shipped production code on both sides of an interface and has experienced the issues firsthand that they learn the potential failure points.
The deeper issue is that exchanging data is only one part of interoperability. Moving DICOM objects between systems is necessary but not enough, because true interoperability includes orders, status, context, configuration, intent, results, exception handling, and workflow states. The goal is not just to move bytes from one system to another but to preserve clinical meaning across independent systems designed by teams that never interacted and with vendor release cycles that never synchronised.
This is where “interoperability theatre” begins.
A system might claim interoperability because it supports common standards. However, in practice, it might still require manual steps, custom scripts, proprietary gateways, or vendor-specific constraints actually to work in a clinical environment. Standards themselves do not automatically mean interoperability. What really matters is whether clinical workflow works safely, reliably and efficiently day after day and release after release when using systems from different vendors.
Subscribe to our newsletter.
Radiation therapy engineering insights, straight from our project teams.
Why interoperability is never finished
Every validated interface is an assumption of how two systems will behave. When any system in the chain changes, that assumption must be retested. According to IEC 62304 Class C, testing interfaces after they have been validated is not overhead – it is baseline, and the more systems there are in the stack, the more complex this problem gets.
Configuration and version management are where the pressure really builds up. While all the other timelines run independently, such as protocol versions, machine capabilities, imaging protocols, treatment techniques and software releases, a vendor update at any point in the chain can invalidate an interface that was working perfectly well a week before.
Therefore, teams must verify compatibility continually, rather than only once when they first install the product. In addition, in mixed-version environments, where various departments within the same institution may use different versions, an originally two-party interface evolves into a matrix of version-compatibility issues that no single group can own.
There is no way to shortcut any of this under Class C. Every interface in a safety-critical pathway must be specified, implemented, tested, and traced, so that when an assumption breaks, revalidation is not optional. The engineering cost of maintaining these interfaces varies with others’ release schedules, making planning for them very difficult.
Adding new modalities such as proton therapy or theranostic imaging makes matters harder instead of easier. These technologies bring their own communication protocols, real-time control architectures, and safety interlock requirements, which, in effect, means the V&V cycle starts from the beginning.
Conventional software development or outsourcing companies cannot efficiently navigate these issues because they have not shipped software on both sides of these interfaces before, and each new modality becomes its own interoperability project rather than an extension of existing ones.
What it takes to make multi-vendor RT integration work
Coordination between parties is the most challenging aspect of integrating applications and is often grossly under-estimated. On paper, a typical radiation therapy integration project consists of three parties: the hospital, the platform vendor and the developer building the connecting layer. However, in reality, none of these three possesses a full understanding of the entire picture.
The hospital knows what the clinician will actually do with results from the external application.
On the other hand, the vendor knows what its system produces and expects, and the developer knows what the interface documentation states. Therefore, for a working solution to exist, there must be a person who can sit with all three parties simultaneously and translate among them.
A multi-vendor RT integration example
Treatment console integration
Let’s use a specific example to illustrate the point above. On one project, a treatment console needed to be integrated with an external system before the external interface even existed – namely, the client was still defining the DICOM data structure.
Therefore, our developers were required to collaborate with both the external supplier and the hospital to agree on assumptions, emulate enough of the missing system to allow development to continue, and develop for a moving target.
What was agreed in advance still needed adjustment once the real systems were finally connected, because in complex setups, delivered interfaces, timing, data, and behaviour are rarely exactly as expected. Ultimate integration brought new findings that had to be resolved collectively by everyone involved, or the workflow would not hold.
This is what real interoperability engineering looks like. It does not live in an interface specification but in the ability to coordinate between people who understand their own side of the issue and to continue translating until all parties involved have developed a common understanding of what needs to happen
There is another layer beneath the coordination problem, however, and it is where interfaces most often fail quietly. Semantic interoperability is the hard part because the same term or object can carry different meanings across systems. Patient position, coordinate systems, image references, treatment intent, dose objects, structures, and machine parameters must be unambiguous at every boundary they cross.
Data exchange without a shared understanding of meaning is inefficient; clinically, it can be unsafe. Domain knowledge is therefore very important at the integration interface, and relying solely on conformity to standards is not enough. Someone needs to understand the data clinically, rather than just its structural appearance, and that person needs to be involved from the start of integration design, rather than after something has already broken down.
The engineering problem worth solving – continuously
Workflow interoperability fails not because standards are wrong; it fails because no one has a full view across organisations that need to work together. Interfaces alone don’t clarify operational boundaries, and what holds integration together in production is a combination of domain understanding, coordination among all parties involved, and engineering discipline applied to every version of every interface until the system remains in clinical service. This is the engineering problem worth solving, and it doesn’t go away once the system goes live.
Do you have a specific interoperability challenge?
Contact Rok Štefanič directly: rok.stefanic@cosylab.com
Learn more about our RT services at https://cosylab.com/solutions/radiation-therapy/.
Cosylab has shipped software on both sides of the interfaces that carry radiation therapy workflows for more than 15 years. Real interoperability engineering is what we do, like on the following project:
"Throughout our collaboration, we worked with Cosylab as one team toward one common result. We particularly value the strong commitment of their engineers, the quality of the code and architecture, and the overall technical competence demonstrated during the project."
Marina Izzo
Chief Executive Officer & Director, EbaMed
Subscribe to our newsletter for radiation therapy engineering insights
Radiation therapy engineering insights, straight from our project teams.