IHERO UseCase Improved Workflow A: Difference between revisions

Latest revision as of 08:33, 30 November 2007

1. Proposed Workitem: Registration Data Transfer

Proposal Editor: Virgil Willcut
Editor: Virgil Willcut, Mika Miettinen
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: Radiation Oncology

2. The Problem

There is currently no consistent network transfer of patient registration information and/or applicable localization data (e.g. cone beam CT images) between the localization systems and either a) the record and verify system (R&V) or b) the treatment planning system (TPS). There is also no record of the imaging in relation to the treatment (pre-tx, pre-shift, post-shift). This means the accuracy and full record of each day’s imaging, localization, and delivery is not being recorded in an automated fashion into the R&V system, and that delivery evaluation and subsequent decision making concerning the need for an adapted or new plan is very manual and, therefore, labour intensive, which limits its availability for routine clinical use.

3. Key Use Case

Physician A prescribes daily localization via pre-treatment CT done in treatment room (CT or CBCT) for the first five fractions of a patient’s treatment. The patient is subsequently imaged, registered, and shifted prior to each treatment for the first five fractions. The physician would like to import these pre-treatment images( to treatment planning system), along with the shift information which is necessary to locate isocenter, and contour on each image set for a patient specific PTV and organ at risk (OAR) evaluation and assessment of the need for re-planning.

Envisioned process: Once the patient treatment has concluded, the images, registration information, and status of the image information (pre- or post-shift/treatment) is sent to the R&V so that a record is established. These images, along with any applicable registration information are then exportable from the imaging workstation or the R&V system to the TPS. In an ideal world, the imaging system and registration information would automatically export to the TPS if the user desires and the TPS would associate the images with the correct baseline plan, locate the isocenter, deform the original structures to the new dataset, re-compute dose, compute user defined metrics, compare these to user established limits and inform the user when tolerances were exceeded.

4. Standards & Systems

DICOM RT

5. Discussion

The planning committee acknowledges that some (or all) aspects of the described use case(s) is covered by 2008 “Treatment Delivery Workflow” profile. However the team decided to submit the use cases, because the use cases are not very clearly described in the profile document, which is under public commenting at the moment. The planning committee asks the technical committee to analyze that the use case(s) described in this document are covered by 2008 profiles, would like to link these “real-life” use case descriptions to 2008 profile document.

@@ Line 1: / Line 1: @@
 __NOTOC__
-==1. Proposed Workitem: ''Improved Workflow B''==
+==1. Proposed Workitem: ''Registration Data Transfer''==
 * Proposal Editor: ''Virgil Willcut''
@@ Line 11: / Line 11: @@
 ==2. The Problem==
-There is currently no consistent transfer of patient anatomy data or aperture data from the TPS to the localization system or from the Record and Verify system (R&V) to the localization system. This creates problems for establishing the correct patient position, and gating envelope in case of gated treatment.
+There is currently no consistent  network transfer of patient registration information and/or applicable localization data (e.g. cone beam CT images) between the localization systems and either a) the record and verify system (R&V) or b) the treatment planning system (TPS).  There is also no record of the imaging in relation to the treatment (pre-tx, pre-shift, post-shift).  This means the accuracy and full record of each day’s imaging, localization, and delivery is not being recorded in an automated fashion into the R&V system, and that delivery evaluation and subsequent decision making concerning the need for an adapted or new plan is very manual and, therefore, labour intensive, which limits its availability for routine clinical use.
+==3. Key Use Case==
-==3. Key Use Case==
+Physician A prescribes daily localization via pre-treatment CT done in treatment room (CT or CBCT) for the first five fractions of a patient’s treatment.  The patient is subsequently imaged, registered, and shifted prior to each treatment for the first five fractions. The physician would like to import these pre-treatment images( to treatment planning system), along with the shift information which is necessary to locate isocenter, and contour on each image set for a patient specific PTV and organ at risk (OAR) evaluation and assessment of the need for re-planning.<br>
-: Physician A prescribes daily image guided patient setup using CT/CBCT imaging device in the treatment room. He has outlined the anatomy details, which are needed to position patient correctly at the time of the treatment. Therapist acquires CT/CBCT images, and uses the anatomy information (defined by physician) to position patient correctly before treatment.>
+Envisioned process: Once the patient treatment has concluded, the images, registration information, and status of the image information (pre- or post-shift/treatment) is sent to the R&V so that a record is established.  These images, along with any applicable registration information are then exportable from the imaging workstation or the R&V system to the TPS.  In an ideal world, the imaging system and registration information would automatically export to the TPS if the user desires and the TPS would associate the images with the correct baseline plan, locate the isocenter, deform the original structures to the new dataset, re-compute dose, compute user defined metrics, compare these to user established limits and inform the user when tolerances were exceeded.
-: Physician A prescribes daily image guided patient setup using radiographic imaging device in the treatment room. He has outlined the anatomy details, which are needed to position patient correctly at the time of the treatment. Therapist acquires radiographic images, and uses the anatomy information (defined by physician) to position patient correctly before treatment.>
-: Physician A prescribes daily gated therapy with localization and the gating envelope to be established while viewing (under flouro using the treatment room imaging system) the relationship between implanted fiducials and an ITV established for these implanted fiducials.  To accomplish this, 4-D CTs are taken and the physician decides to treat over certain phases.  Individual contours are made of the CTV and fiducials on each phase selected for treatment.  An ITV is created for the fiducials and the target and an additional margin is added to the target ITV to establish a PTV.  Because the anatomical information is not transferred to the localization system (in this case the fluoro system), there is no way to view under flouro an anatomy outline of the fiducial ITV. >
-:  Same scenario as Number 3, except Physician A wants to localize and establish the gating envelope by viewing the tumor under flouro with respect to the treatment aperture for that gantry position.  Because the portal information is not transferred to the localization system (in this case the flouro system), there is no way to view, under flouro, the position of the tumor with respect to the treatment portal.
 ==4. Standards & Systems==
@@ Line 27: / Line 25: @@
 ==5. Discussion==
-The planning committee acknowledges that DICOM standard provides tools to transfer the anatomy information (both 2D and 3D). However the vendors have not implemented the support consistently, and thus the interoperability is poor. These use cases are challenging, because the data needs to flow though several systems before it is used by localization system.
+The planning committee acknowledges that some (or all) aspects of the described use case(s) is covered by 2008 “Treatment Delivery Workflow” profile. However the team decided to submit the use cases, because the use cases are not very clearly described in the profile document, which is under public commenting at the moment. The planning committee asks the technical committee to analyze that the use case(s) described in this document are covered by 2008 profiles, would like to link these “real-life” use case descriptions to 2008 profile document.