Advanced Radiotherapy Objects Interoperability

Advanced Radiation Therapy Interoperability (ARTI) beam type specific requirements for information exchange

Summary

This integration profile involves the exchange of RT Plan information between treatment planning systems and between treatment planning systems and treatment management systems. The emphasis for this profile is on reducing ambiguity involved in re-planning and incorporation of the planning information in to the treatment management system in anticipation of transfer to a treatment delivery system. The profile identifies 14 treatment-specific beam types and delineates the attribute requirements for each type. It also describes four sets of additional (optional) attributes that may be included with the different beam types to provide consistent support for compensators, bolus, blocks, and secondary physical (hard) wedges.

Benefits

Defines beam specific attribute requirements to promote interoperable exchange of RT Plan information between planning systems and/or treatment management systems
By using different beam types, allows treatment planning systems to identify capabilities in an industry-wide format
Provides attribute requirements for common optional treatment devices for consistent information exchange

Details

This integration profile involves the exchange of RT Plan information between treatment planning systems and between treatment planning systems and treatment management systems. The emphasis for this profile is on reducing ambiguity involved in re-planning and incorporation of the planning information in to the treatment management system in anticipation of transfer to a treatment delivery system. The transactions revolve around content rather than workflow.

This profile addresses a broad variety of “Beam Techniques” that exist in Radiation Therapy. Rather than define actors that have broad involvement in many optional transactions, a large number of actors were defined which each have specific mandatory/required transactions and a small number of optional transactions related to beam modifiers. The actors are either producers or consumers of a DICOM RT Plan. It is expected that the actual products commonly referred to as Treatment Planning Systems will implement one or more of the “producer” actors, and that the choice of which actors are implemented (for which adherence is claimed) will depend on the intended functionality (which is not defined by IHE-RO). A Treatment Planning System that is intended to be able to perform re-planning based on the output of another Treatment Planning System would be expected to adhere to one or more of the “consumer” actors.

It is expected that the actual products variously referred to as Oncology Information Systems, Oncology Information Management, or Electronic Medical Record for Oncology will implement the Treatment Management System (TMS) actor. While the profile does not dictate the functionality of the TMS, the TMS is responsible for providing an adequate view of the information provided to it (as a Beam Consumer) such that, in normal operating practice, the appropriate user can ensure that the planning information has been properly consumed, associated with the correct patient, etc. No transactions have been defined between the TMS actor in this profile and the TMS actor in other profiles, and any necessary interface is considered private (in the same way that an Image Manager and an Image Archive are related in the Radiology Domain Scheduled Workflow profile). In practice, it is expected that once a TMS has consumed the information provided to it by a Beam Producer, the system incorporating the TMS actor will then be able to act as the TMS in delivery-oriented profiles and provide that information to a Treatment Delivery System actor in that profile. It is not expected that a TMS actor for this profile from one vendor will interoperate with a TMS actor for other delivery profiles from another vendor. As indicated in the table identifying actors and transactions, the TMS actor can support retrieval of any of the beam types (all transactions are optional). The TMS shall indicate in its Integration Statement the scope of its capabilities (i.e. which beam types it supports). It is expected that a TMS will support most, if not all, beam types. However, there may be beam types for which full testing is not possible due to limitations on the number of producers of a specific beam type, hence the optional transaction list.

It should also be noted that the Appendix in this Supplement’s Volume 2 specifies content that is mandatory across all transactions. Finally, there are individual attributes within a RT Plan that are not specified in this profile, but have significant safety implications if ignored. As much as possible, these attributes have been identified in the transactions and it is indicated that a ‘retrieval’ actor shall handle RT Plans that may include these attributes in a safe manner. This behavior can include rejection of the RT Plan or appropriate warmings (with user acknowledgement) as possible courses of action in such circumstances.