IHERO UseCase 2011 FFF

1. Proposed Workitem: Integrated Patient QA Checker (part of Patient Safety Use Case)

• Proposal Editor: Name: Mika Miettinen, mika.miettinen@varian.com, +1 650 799 7665
• Editor: Colin Field for Mika
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiation Oncology

2. The Problem

Some treatment delivery systems are capable of delivering so called “FFF” (Flattening Filter Free) beams. These beams differ from “standard flat”-beams so that beam profiles are not made “flat” using a flattening filter in the beam line. Thus FFF-beams are “pointed” (depending on the energy), and may enable significantly higher dose rates compared to the standard beams. Even if the nominal energy of the FFF beam is the same as the nominal energy of the standard beam from accelerator perspective, the FFF beam is little softer (when measured in water phantom) compared to the standard beam (with the same nominal energy) because of the missing flattering filter. As the beam characteristics of the FFF beams can be very different from standard beams, it is very important that these beams are recognized and handled properly by all systems contributing to the radiotherapy process. If plan is created using FFF beams, but treated as standard beam (or vice versa), the dose delivered to the patient may be significantly different.

The purpose of this Proposal is to request IHE-RO to add FFF-beams to “Advanced RT Objects Interoperability” Integration Profile, so that the vendors will be able to implement the FFF-beam interoperability consistently, and test the connectivity as part of IHE-RO connecthaton.

It is also important to acknowledge that the current “Advanced RT Objects Interoperability” integration profile addresses only the data content transfer between treatment planning systems and treatment management systems / information systems. IHE-RO does not currently have data content profiles to cover the data content transfer between treatment management system / information system and treatment delivery system. To ensure the interoperability of FFF-treatments, it is critical that IHE-RO will also look into developing these additional profiles. Author of this document is planning to submit a separate Proposal (per request from Planning Committee) to address this need.

4. Standards & Systems

As IHE-RO addresses interoperability, not functionality, the integration profile must be defined along these lines even if there is a temptation to define what kind of QA checks the “QA checkers” should perform. However it is clear that the community needs the “QA checkers” to perform e.g. data integrity checks, data sanity checks, clinical sanity checks, independent MU calculations, data verification, etc. As part of this integration profile, the technical committee must create a list of “checks” that the “QA checkers” can perform (define what, not how), and what are the expected inputs and outputs in the process.
DICOM RT standard (data objects and worklist) should be considered in implementation of the integration profile. One of the main objectives is to get the QA vendors to join the IHE-RO efforts, and get these QA tools to be part of clinical workflow.

5. Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>

<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>

<What are some of the risks or open issues to be addressed?>

<This is the brief proposal. Try to keep it to 1 or at most 2 pages>