Conclusions: One-year outcome for 3 dimensional topographic applicator brachytherapy seems very promising, with very high local control and cosmesis.
Poster Viewing Abstracts S619
Volume 87 Number 2S Supplement 2013 14.5, range 4-30). 106/107 (99.1%) completed treatment. The local control is 102/107 - 95.3%. Acute toxicity was (RTOG) Grade 1 - 58/107 (54.2%); Grade 2 - 49/107 (45.8%). All toxicity resolved by the 2 month follow-up. Cosmesis was excellent - 94/107 (87.9%); good - 12/107 (11.2%); fair 1/ 107 (0.9%) Conclusions: One-year outcome for 3 dimensional topographic applicator brachytherapy seems very promising, with very high local control and cosmesis. The ability for treatment on curved surfaces and the relative ease for customization suggest that 3-TAB could be a strong option for nonmelanoma skin cancer treatment on difficult areas such as the face. Further study with longer follow-up is warranted. Author Disclosure: S. Mutyala: None. N. Thawani: None. S. Vyas: None. G. Palaniswaamy: None. J. Smith: None. C.B. Ord: None. N. Deb: None. D. Rangaraj: None.
3088 Development of a Protocol-Driven Script Content Management System for a Commercial Radiation Therapy Treatment Planning System R.W.J. Janssen and K.H. van der Boom; Department of Radiotherapy, Isala, Zwolle, Netherlands Purpose/Objective(s): Patient safety and process efficiency both benefit from automating and standardizing radiation therapy treatment planning tasks. This is facilitated by e.g., the use of scripts. However, as the number and the complexity of interacting scripts grow, script management becomes a serious challenge. This work describes the development of a protocol-driven Script Content Management System (SCMS) for a commercial Treatment Planning System (TPS) that in addition extends the native TPS scripting language with the functionality of a programming language. Materials/Methods: The SCMS was built with Python/PHP/MySQL and runs on a dedicated server. To establish connection between the SCMS and the TPS a custom Python-to-Python communication protocol was developed. The TPS was not modified except for the use of custom script files in the designated scripting folder. Additional Python modules were installed on the SCMS server only. A set of custom functions add advanced features like in-script SCMS/TPS communication and external database access. The SCMS database was designed to host both scripts (Python code) and variables: the properties of ROIs, POIs, Beams, IMRT Objectives, DVH/Dose Parameters, etc. Customizable script menu templates combine relevant scripts and variables based on treatment protocols. An administrative web interface manages both the database content and the script-assembly process; no programming skills are required. Finally, the SCMS uses sets of sandboxed live/test environments featured with automated version control and access control. Results: The SCMS was clinically implemented in 2012; initially for QA purposes only. This includes a script to check plan integrity and extract parameters from the TPS to perform an independent MU check and a transfer integrity check. The SCMS reduced a complex web of over 30 interacting scripts to a single database entry of code. In addition, scripts intended for e.g., standardized ROI initialization were tested. A dynamically generated script menu allowed the TPS user to execute the same script with different variables based on the protocol selected. Another script was able to retrieve and use patient specific information from the R&V-EMR system. Conclusions: A protocol-driven SCMS was developed that enables an unmodified TPS to seamlessly run Python code directly from a database. The ability to use scripts and script menus that dynamically depend on treatment protocols, the web/database design, and the reduced script complexity offer great potential regarding script management and treatment plan management. Current development focuses on further clinical implementation, protocol-based storage and automated analysis of treatment plan parameters, decision making support, and TPS/R&V-EMR workflow optimization. Author Disclosure: R.W.J. Janssen: None. K.H. van der Boom: None.
3089 A Software Architecture and Application for Reporting on and Analyzing Radiation Plans for Concordance With Ideal Dose Constraints as a Quality Assurance Parameter F.S. Vali,1 C. Gordon,2 J. Gesner,2 P. Crossan,1 and J. Kang1; 1Affiliated Oncologists, South Chicago Suburbs, IL, 2Advocate Christ Medical Center, Oaklawn, IL Purpose/Objective(s): Approving a radiation dosimetry plan can be a time-intensive iterative process that is essential for maximizing a treatment’s therapeutic ratio. We aim to design a software framework (i.e., architecture) and implement an application that verifies that treatment plans meet established dose volume constraints. In doing so, we hope to improve upon an inadequate solution provided within our Treatment Planning System (Planning Objectives) and enhance quality assurance within our department. Materials/Methods: We used JSON (JavaScript Object Notation) and Javascript for data exchange and knowledge representation. Using D (a C++ derivative that supports advanced compile-time metaprogramming) a highly performant parser was written to process the large data within a Dose Volume Histogram (DVH) and convert it to JSON. Javascript, ExtJS and Microsoft HTML Application framework were used to create the Graphical User Interface (GUI). Results: The designed Architecture consists of five components: 1) DVH Converter: converts a DVH’s native representation (text, dicom etc.) into a JSON schema, 2) Constraint Factory: stores the knowledge of various user defined dose constraints using Javascript; if queried with a DVH structure, returns the corresponding constraint object, 3) Constraint Verifier: checks if the DVH data meets constraints while creating feedback in JSON format, 4) Feedback Responder: uses the feedback from the Constraint Verifier to produce an appropriate alert or report, 5) Program Controller: coordinates invocation of and data exchange within the various components, and responds to user interaction. We prototyped an application using our Architecture and tested it against de-identified patient data. Our prototype can rapidly (< 1 min) summarize large DVHs (e.g., Head and Neck) into a readable report – as a dynamic HTML web application – that clearly highlights constraint violations. While the Program Controller is flexible enough to deduce appropriate defaults (i.e., constraint guidelines based on the diagnosis; prescription dose from the structure name: PTV 70), users can select specific constraint guidelines (RTOG, NCCN, QUANTEC etc.) and/or doses to apply to all or specific structures at the time of report review. Conclusions: We have designed an initial software architecture and prototyped an application within our clinic to expedite plan review and quality assurance (during chart rounds). Our solution is capable of handling different DVH formats, applying different constraint guidelines and responding to constraint violations in versatile ways; thus, overcoming the many inflexibilities of Eclipse’s Planning Objectives. Author Disclosure: F.S. Vali: None. C. Gordon: None. J. Gesner: None. P. Crossan: None. J. Kang: None.
3090 Prospective Randomized Double-Blind Study of Atlas-Based Autosegmentation Assisted Radiation Treatment Planning in Headand-Neck Cancer G.V. Walker, M. Awan, R. Tao, E.J. Koay, G.B. Gunn, A.S. Garden, J. Phan, W.H. Morrison, D.I. Rosenthal, and C.D. Fuller; University of Texas MD Anderson Cancer Center, Houston, TX Purpose/Objective(s): We assessed potential time reduction and acceptability of an atlas-based autosegmentation (AS) algorithm compared to manual segmentation (MS) of organs-at-risk (OARs) region of interest (ROI) for radiation therapy (RT) planning. Materials/Methods: Patients being simulated for definitive RT/chemoRT for non-cutaneous head and neck malignancies were included. Following CT acquisition, DICOM files were processed using the Smart Probabilistic
