IHERO UseCase 2011 FFF: Difference between revisions

Latest revision as of 09:12, 20 March 2011

1. Proposed Workitem: Flattening Filter Free

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.

3. The Use Case

Successful Use Case:

A treatment plan using FFF beams (or mixed FFF and standard beams) is created using treatment planning system. Treatment planning system uses the data definitions required by IHE-RO Advanced RT Objects Integration profile to differentiate the FFF beams and standard beams.
Clinicians Approve the plan
Treatment planning system exports the plan to Treatment Management System (TMS) (or Archive).
TMS imports the plan from Treatment Planning System (or Archive). TMS uses the data definitions required by IHE-RO Advanced RT Objects Integration profile to differentiate the FFF beams and standard beams.
Clinicians approve the plan for treatment
Treatment Delivery System (TDS) imports the plan for treatment. TDS uses the data definitions required by IHE-RO Advanced RT Objects Integration profile to identify and differentiate between the FFF beams and standard beams, and modes up the correct settings to deliver the dose.

Technical committee shall consider how the applications in the process chain shall react to FFF-data, if they are not capable of handling these types of treatments.
Some unsuccessful (potentially hazardous) scenarios:

User configures an “FFF unaware” treatment planning system to use FFF beam depth dose curves, profiles and output factors, but treatment planning system is not capable of marking the beam as FFF when plans are exported to TMS. Thus there is a possibility that FFF beam would be treated using standard (flat) beam, and this could lead to misadministration of the dose.
Treatment plan with FFF beams is imported to TMS that is not FFF-aware. Even if TPS had marked FFF beams in its data export, TMS drops the definitions, and imports the FFF beams as standard (flat) beams. This could lead to misadministration of the dose, if this plan was later treated.
Treatment machine receives an FFF beam, but is not aware of the FFF definitions, and treats the beam as standard (flat) beam. This could lead to misadministration of the dose.

4. Standards & Systems

DICOM RT WG-7 has created a mechanism that can be used to identify the FFF beams, and this proposal suggests that the DICOM RT definitions should be used to differentiate the FFF-beams from standard (flat) beams (see table 1). The problem with the current DICOM RT standard is that the “Primary Fluence Mode Sequence” is “Optional”, and thus it would be legal for e.g. receiving end to ignore it. Technical committee needs to define the integration profile in a way that each actor in the chain of radiotherapy process is aware of the different beam types, and is able to react to the data safely (e.g. prevent the “unsuccessful scenarios” listed above). One suggestion is to make the “Primary Fluence Mode Sequence” mandatory in IHE-RO Advanced RT Object Integration Profile for the actors creating and consuming dosimetric plans, but technical committee needs to make the final decision how to implement the DICOM RT standard to ensure the maximum inoperability.

Item

Tag

Description

>Primary Fluence Mode Sequence

(3002,0050)

3*

Sequence defining whether the primary fluence of the treatment beam uses a nonstandard fluence-shaping. Only a single item shall be permitted in this sequence.

>>Fluence Mode

(3002,0051)

1

Describes whether the fluence shaping is the standard mode for the beam or an alternate.

Enumerated Values:
STANDARD = Uses standard fluence shaping
NON_STANDARD = Uses a non-standard fluence-shaping mode

>>Fluence Mode ID

(3002,0052)

1C

Identifier for the specific fluence-shaping mode.

Required if Fluence Mode (3002,0051) has value NON_STANDARD.

Defined Terms: FFF ** [New terms]

Currently DICOM RT Standard defines “Primary Fluence Mode Sequence” as Optional (3)*, but this must be reconsidered in the IHE-RO integration profile. **) New, similar techniques can be described using the same mechanism.
It is also suggested that the nominal energy of the FFF and standard (flat) beam shall be defined to be the same if the same energy is used to drive the electrons to the target, and only difference in the beam generation is that the standard (flat) beam has a flattening filter in the beam, and FFF beam doesn’t, and some steering parameters may be different. This definition might be beyond IHE-RO’s scope, but MITA group thought that this is worth of documenting in the proposal.
Another guidance for the technical committee: FFF is the representative example in this proposal. However, in general this applies to all filters, which the machine can put into the beam line dynamically, and are different from the standard filters in the past. Thus the identifier could be something else than FFF. If possible the implementation should be generalized to ensure interoperability of the future techniques without compromising the safety.

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?>

@@ Line 2: / Line 2: @@
-==1. Proposed Workitem: Integrated Patient QA Checker (part of Patient Safety Use Case)==
+==1. Proposed Workitem: Flattening Filter Free==
 * Proposal Editor: Name: Mika Miettinen, mika.miettinen@varian.com, +1 650 799 7665
@@ Line 13: / Line 13: @@
 ==2. The Problem==
-Current patient QA solutions are not integrated well to the clinical workflow to enable efficient, fast and as automated daily patient QA as possible. The lack of integration causes a lot of manual work for clinicians, and thus does not encourage the adoption of these tools to be part of everyday operations and patient treatments in the clinic.
+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. <br>
+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. <br>
-==3. Key Use Case==
+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.
-Success Use Cases
+==3. The Use Case==
+Successful Use Case:
+# A treatment plan using FFF beams (or mixed FFF and standard beams) is created using treatment planning system. Treatment planning system uses the data definitions required by IHE-RO Advanced RT Objects Integration profile to differentiate the FFF beams and standard beams.
+# Clinicians Approve the plan
+# Treatment planning system exports the plan to Treatment Management System (TMS) (or Archive).
+# TMS imports the plan from Treatment Planning System (or Archive). TMS uses the data definitions required by IHE-RO Advanced RT Objects Integration profile to differentiate the FFF beams and standard beams.
+# Clinicians approve the plan for treatment
+# Treatment Delivery System (TDS) imports the plan for treatment. TDS uses the data definitions required by IHE-RO Advanced RT Objects Integration profile to identify and differentiate between the FFF beams and standard beams, and modes up the correct settings to deliver the dose.
+<br>
+Technical committee shall consider how the applications in the process chain shall react to FFF-data, if they are not capable of handling these types of treatments.
+<br>
+Some unsuccessful (potentially hazardous) scenarios:
+# User configures an “FFF unaware” treatment planning system to use FFF beam depth dose curves, profiles and output factors, but treatment planning system is not capable of marking the beam as FFF when plans are exported to TMS. Thus there is a possibility that FFF beam would be treated using standard (flat) beam, and this could lead to misadministration of the dose.
+# Treatment plan with FFF beams is imported to TMS that is not FFF-aware. Even if TPS had marked FFF beams in its data export, TMS drops the definitions, and imports the FFF beams as standard (flat) beams. This could lead to misadministration of the dose, if this plan was later treated.
+# Treatment machine receives an FFF beam, but is not aware of the FFF definitions, and treats the beam as standard (flat) beam. This could lead to misadministration of the dose.
-Use Case 1
+==4. Standards & Systems==
-# Treatment plan has been created and is sent to Treatment Management System (TMS)
+DICOM RT WG-7 has created a mechanism that can be used to identify the FFF beams, and this proposal suggests that the DICOM RT definitions should be used to differentiate the FFF-beams from standard (flat) beams (see table 1). The problem with the current DICOM RT standard is that the “Primary Fluence Mode Sequence” is “Optional”, and thus it would be legal for e.g. receiving end to ignore it. Technical committee needs to define the integration profile in a way that each actor in the chain of radiotherapy process is aware of the different beam types, and is able to react to the data safely (e.g. prevent the “unsuccessful scenarios” listed above).  One suggestion is to make the  “Primary Fluence Mode Sequence” mandatory in IHE-RO Advanced RT Object Integration Profile for the actors creating and consuming dosimetric plans, but technical committee needs to make the final decision how to implement the DICOM RT standard to ensure the maximum inoperability.
-# Treatment is prepared by dosimetrist in TMS
-# Dosimetrist saves the final plan, and sends it to approval
-# TMS system request a “QA check” from “QA checker” (QA application)
-# “QA checker” performs the “QA Check”, and returns the results to TMS
-# If “QA Checker” result is “Ok to proceed”
-#*Plan in TMS is ready to be approved by physicist and physician
-#*Physicist and physician approve the plan for treatment
-# If “QA Checker” result is “Not Ok to proceed”
-#*TMS informs the dosimetrist about the failure of the check
-Use Case 2
-# Therapist opens the worklist on the Treatment Delivery System (TDS) and selects the patient plan to be treated.
-# TDS retrieves the patient plan from TMS
-# TDS system request a “QA check” for the plan from “QA checker” (QA application)
-# “QA checker” performs the “QA Check”, and returns the results to TDS
-# If “QA Checker” result is “Ok to proceed”
-#*TDS allows therapist to start treatment (after other verification steps are completed)
-# If “QA Checker” result is “Not Ok to proceed”
-#*TDS informs the therapist about the failure of the check and requires QA personnel to resolve the situation.
 <br>
+{| style="width:100%" border="1" cellpadding="3"
+! Item
+! Tag
+!
+! Description
+|-
+| >Primary Fluence Mode Sequence
+| (3002,0050)
+| 3*
+|Sequence defining whether the primary fluence of the treatment beam uses a nonstandard fluence-shaping. Only a single item shall be permitted in this sequence.
+|-
+| >>Fluence Mode
+| (3002,0051)
+| 1
+| Describes whether the fluence shaping is the standard mode for the beam or an alternate.
+Enumerated Values: <br>
+STANDARD = Uses standard fluence shaping <br>
+NON_STANDARD = Uses a non-standard fluence-shaping mode
+|-
+| >>Fluence Mode ID
+| (3002,0052)
+| 1C
+|  Identifier for the specific fluence-shaping mode.
+Required if Fluence Mode (3002,0051) has value NON_STANDARD.
+Defined Terms:
+FFF ** [New terms]
+|}
-These are just example use cases, and any actor in the radiotherapy or radiosurgery process shall be able to call a “QA check” at any point of time of the process, and this way the clinic is able to define “QA check timeouts” in their process.
-==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.
 <br>
-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.
+Currently DICOM RT Standard defines “Primary Fluence Mode Sequence” as Optional (3)*, but this must be reconsidered in the IHE-RO integration profile. **) New, similar techniques can be described using the same mechanism.
+<br>
+It is also suggested that the nominal energy of the FFF and standard (flat) beam shall be defined to be the same if the same energy is used to drive the electrons to the target, and only difference in the beam  generation is that the standard (flat) beam has a flattening filter in the beam, and FFF beam doesn’t, and some steering parameters may be different. This definition might be beyond IHE-RO’s scope, but MITA group thought that this is worth of documenting in the proposal.
+<br>
+Another guidance for the technical committee: FFF is the representative example in this proposal. However, in general this applies to all filters, which the machine can put into the beam line dynamically, and are different from the standard filters in the past. Thus the identifier could be something else than FFF. If possible the implementation should be generalized to ensure interoperability of the future techniques without compromising the safety.
 ==5. Discussion==
@@ Line 56: / Line 84: @@
 :''<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>''