No abstract

No abstract

ObjectivesStereotactic body radiation therapy (SBRT) can improve therapeutic ratios and patient convenience, but delivering higher doses per fraction increases the potential for patient harm. Incident learning systems (ILSs) are being increasingly adopted in radiation oncology to analyze reported events. This study used an ILS coupled with a Human Factor Analysis and Classification System (HFACS) and barriers management to investigate the origin and detection of SBRT events and to elucidate how safeguards can fail allowing errors to propagate through the treatment process.MethodsReported SBRT events were reviewed using an in-house ILS at 4 institutions over 2014–2019. Each institution used a customized care path describing their SBRT processes, including designated safeguards to prevent error propagation. Incidents were assigned a severity score based on the American Association of Physicists in Medicine Task Group Report 275. An HFACS system analyzed failing safeguards.ResultsOne hundred sixty events were analyzed with 106 near misses (66.2%) and 54 incidents (33.8%). Fifty incidents were designated as low severity, with 4 considered medium severity. Incidents most often originated in the treatment planning stage (38.1%) and were caught during the pretreatment review and verification stage (37.5%) and treatment delivery stage (31.2%). An HFACS revealed that safeguard failures were attributed to human error (95.2%), routine violation (4.2%), and exceptional violation (0.5%) and driven by personnel factors 32.1% of the time, and operator condition also 32.1% of the time.ConclusionsImproving communication and documentation, reducing time pressures, distractions, and high workload should guide proposed improvements to safeguards in radiation oncology.

Due to a gap in published guidance, we describe our robust cycle of in-house clinical software development and implementation, which has been used for years to facilitate the safe treatment of all patients in our clinics. Methods and Materials: Our software development and implementation cycle requires clarity in communication, clearly defined roles, thorough commissioning, and regular feedback. Cycle phases include design requirements and use cases, development, physics evaluation testing, clinical evaluation testing, and full clinical release. Software requirements, release notes, test suites, and a commissioning report are created and independently reviewed before clinical use. Software deemed to be high-risk, such as those that are writable to a database, incorporate the use of a formal, team-based hazard analysis. Incident learning is used to both guide initial development and improvements as well as to monitor the safe use of the software. Results: Our standard process builds in transparency and establishes high expectations in the development and use of custom software to support patient care. Since moving to a commercial planning system platform in 2013, we have applied our team-based software release process to 16 programs related to scripting in the treatment planning system for the clinic. Conclusions: The principles and methodology described here can be implemented in a range of practice settings regardless of whether or not dedicated resources are available for software development. In addition to teamwork with defined roles, documentation, and use of incident learning, we strongly recommend having a written policy on the process, using phased testing, and incorporating independent oversight and approval before use for patient care. This rigorous process ensures continuous monitoring for and mitigatation of any high risk hazards.