Integrating the OIS with the PT System: 5 Top Tips

At Cosylab we have worked on multiple Particle Therapy systems and projects. From this we have learnt 5 things that are crucial to shortening the time to integrate the Oncology Information System (OIS) and the Proton Therapy (PT) system.

Published in

Control Sheet

8 min readOct 26, 2018

Each year dramatic breakthroughs and improvements are being made in the field of medical technology, improving quality, efficacy, and safety of therapy and ultimately improving long-term patient outcome. Many of these technologies require good quality information for optimal operation. The information collection starts with the first presentation of patient, continues through diagnostics and treatment, and even later with follow-up consultations. Good quality information is also important in oncology, especially in the field of proton therapy (PT).

Proton Therapy System

The proton therapy system is a complex configuration of physical components that generates a particle beam of desired characteristics and delivers it in accordance with the treatment plan, safely and accurately to the patient.

When treatments are complete, the proton therapy system generates the treatment records that confirm exactly what has been delivered to the patient and what other information has been created during the treatment, e.g. images used to position the patient.

Management of Treatment Data

Figure 1: A high-level schematic of the information systems (treatment planning, oncology information, picture archiving and communication) that are responsible for generating and storing data needed to deliver proton treatment.

The information used during a PT session is contained in the treatment plan and the information generated during a PT session is stored in a treatment report.

Treatment plans are created in the treatment planning system and are sent to the picture archiving and communication system (PACS). The specific information necessary for a single treatment session is generated on the oncology information system (OIS) (Figure 2) and transferred to the proton therapy (PT) system. Any other information required to deliver the treatment, e.g. CT images of the treatment site, is also sent to the PACS. When the treatment is complete, the treatment reports are stored in the PACS and references are sent to the OIS.

The DICOM Standard

It is a medical-industry best-practice to use the Digital Imaging and Communications in Medicine (DICOM) [1] standard to encode, transfer, interpret and manage medical data. Initially focused on medical imaging, DICOM was later extended to include radiotherapy. The standard is widely adopted and it provides a framework for discussing the radiotherapy data requirements. So, all information stored the OIS and the PACS comply with the DICOM standard and also the DICOM communication protocols are used to transfer information between the different systems (Figure 2).

However, DICOM, as a standard, does not provide guidance for workflows. The Integrating the Healthcare Enterprise (IHE) initiative [2] is a standardization effort focused on improving interoperability between different vendors. The IHE provides multiple profiles that aim to satisfy specific healthcare needs and serve as an implementation guide for interoperability.

IHE contains a Radiation Oncology section (IHE-RO) that provides profiles for high-level workflow structuring applicable to proton therapy.

Integration is always Necessary

With the increasing availability of compact proton therapy machines, the choice is made easier for established hospitals to conveniently add proton therapy to their suite of cancer treatment modalities. Since the hospital has been delivering radiotherapy or other cancer treatments, there are usually existing information systems, e.g., an OIS or a PACS that they would prefer to integrate into the new proton therapy system (Figure 1).

However, because of the choice between so many specialized vendors for these systems, it is only possible to realize a working system through a systems integration project. Integration is also an important part of constructing a new PT center. In both these cases, a good understanding is needed about how data is generated, transferred and used in the proton therapy process.

The length of these integration projects can vary significantly, from several months to a few years. For investors, it is important that these projects have a predictable duration.

5 Things to Keep in Mind

Based on our experience from a variety of projects, we have gathered a few tips that are guaranteed to shorten the time to integrate the OIS and the proton therapy system:

Include Medical Staff
Embrace evolving standards
Accept that standards don’t guarantee interoperability
Use a central workflow manager
Anticipate invalid data

Tip 1: Include Medical Staff

Medical staff have experience with existing workflows in hospitals and so accommodate their experience and don’t “dictate”.

Hospitals have existing procedures they strictly adhere to. These will therefore greatly affect the workflow of a proton therapy system. It is therefore presumptuous of the manufacturers of the PT system to impose workflow restrictions and constraints upon the medical staff. It should always be the other way around.

There must be an understanding of the existing workflows and workflow developers must work closely with staff when deciding on the final implementation.

The workflow can then be defined before the integration effort starts. How the workflow is defined depends on several constraints, where one of them is the capabilities of the systems that will be used to perform a specific part of the treatment, e.g. OIS, patient positioning system, imaging system, registration system, and treatment system.

Tip 2: Embrace evolving standards

Always work with the latest versions of the standard, which, in the case of such a comprehensive and compartmentalized standard as DICOM is not self-evident. In addition, take advantage of other initiatives e.g. the IHE-RO profiles, to assist with workflow standardization.

DICOM and the IHE-RO profiles are constantly evolving to include new requirements.

So, it is best to always try to use the latest version of the standard. This has implications in the cases when one (older) version of a standard does not include support for some feature.

This implies an ad hoc solution to address a need of the system. For example, there is no field in DICOM to store a location in the machine for patient-specific beam modulation devices. So, a custom field must be used, but this requires coordination between the TPS and OIS and the proton therapy system. However, a newer version of the standard might include a solution to this problem.

Tip 3: Accept that standards don’t guarantee interoperability

Always remember that while the DICOM standard and IHE-RO profiles give direction, their specific compliant implementations across products from different vendors can still be incompatible with each other.

The problem of integration and interoperability is well known in the medical systems community — that was one of the main drivers behind the creation of the DICOM standard. However, the DICOM standard is constantly evolving, and different vendors can be compliant with different versions of DICOM which might cause problems when these systems need to work together. Of immediate concern is the fact that DICOM has many similar fields and their use is open to interpretation. Hence data can be argued to fit in different places and thus it is possible that the PT system might not get the data that is is expecting.

The PACS also uses DICOM for communication, so the integration of the PACS with the PT system has similar challenges. For example, not all PACSs support the newer DICOM communication protocols for something as commonplace as retrieving an element from the PACS. So, it is possible that depending on your choice of proton therapy system, that you might not be able to integrate it with your existing PACS.

Furthermore, looking at the IHE-RO profiles, the OIS and proton therapy system can be designed to be compliant with the same profile, however, the compliance can be only claimed during integration testing called Connectathon.

Tip 4: Use a central workflow manager

Control in the context of proton therapy consists of a complex interplay of human actors with the software technology. Adding “glue-logic” to fix architectural misalignments that were missed between the OIS and the proton therapy system is an undesirable solution. A better approach is to use a central workflow manager, commonly known as treatment control system (TCS), which is the only system in contact with the OIS. This also reduces complexity by minimizing the number of necessary communication channels.

Figure 2: The central workflow manager, i.e. TCS, interacts with the OIS and PACS on one side and all subsystems of the PT system on the other.

The inclusion of a TCS (Figure 2) from early on simplifies the integration of the OIS and PACS into the PT system because there is one channel of communication into the PT system, which can be configured to handle all possibilities of input from the OIS and of instruction on the side of the PT system.

Specifically, this TCS is then responsible for the full coordination of the entire proton treatment process and its primary objective is to obtain all required information from an OIS and enable users to carry out the steps necessary to treat a patient.

Tip 5: Anticipate Invalid Data

Compliance with the DICOM standard does not ensure that all data required by the PT system is defined in the treatment plans, so verify all received data. In addition, if the actual OIS is not available, create a simulation and testing strategy early on in the project to help with identifying potential problems with data.

It is entirely possible for a treatment plan to comply with the DICOM standard, but also that it doesn’t contain all the information necessary to execute a proton treatment. Therefore, all received DICOM must be verified before it is used. If the data is not valid, it needs to be rejected and the right stakeholders notified.

This means that it is necessary to have “smart” data handlers that are content-aware, i.e. one cannot use generic parsing strategies. There are many interconnected parts of the treatment plans and all the data needs to be verified to ensure the relevant part of the PT system is going to receive exactly what it needs. This verification should also include checks for values that are outside of defined safety limits.

If the OIS is not actually available, then you need to create a simulation and testing mechanism for testing scenarios with invalid data.