Using Systems Thinking to Improve Safety in Radiation

Therapy

Prof. Nancy G. LevesonAeronautics and Astronautics

Engineering Systems

MIT

To understand and prevent accidents, must consider system as a whole

                                 And so these men of HindustanDisputed loud and long,Each in his own opinionExceeding stiff and strong,Though each was partly in the rightAnd all were in the wrong.

John Godfrey Saxe (1816-1887)

Facts about Accidents

• Almost never have single causes

– “Root cause seduction”

– Accidents are complex processes

• Usually involve flaws in

– Engineered equipment

– Operator behavior

– Management decision making

– Safety culture

– Regulatory oversight

Human Error as a Cause

• ALL accidents are caused by “human error” (except “acts of God,” like hurricanes)

• Almost always there is:

– Operator “error”

– Flawed management decision making

– Flaws in the physical design of equipment

– Safety culture problems

– Regulatory deficiencies

– Etc.

Do Operators Really Cause Most Accidents?

• When say human error, usually mean “operator error”

• Hindsight bias

• Operator error vs. design error

(Sidney Dekker, 2009)

Hindsight Bias

“should have, could have, would have”

Overcoming Hindsight Bias

• Assume nobody comes to work to do a bad job.– Assume were doing reasonable things given the complexities,

dilemmas, tradeoffs, and uncertainty surrounding them.

– Simply finding and highlighting people’s mistakes explains nothing.

– Saying what did not do or what should have done does not explain why they did what they did.

• Investigation reports should explain– Why it made sense for people to do what they did rather than

judging them for what they allegedly did wrong and

– What changes will reduce likelihood of happening again?

Fumbling for his recline button Ted unwittingly instigates a disaster

Operator Error: Traditional View

• Operator error is cause of most incidents and accidents

• So do something about operator involved (suspend, retrain, admonish)

• Or do something about operators in general

– Marginalize them by putting in more automation

– Rigidify their work by creating more rules and procedures

Operator Error: System View

• Operator error is a symptom, not a cause

• All behavior affected by context (system) in which occurs

• To do something about error, must look at system in which people work:

– Design of equipment and interface with equipment

– Usefulness of procedures

– Existence of goal conflicts and production pressures

– Etc.

Mental Models

Procedures

• Cannot guarantee safety

• Safety comes from people being skillful in judging when and how they apply.

• Old view: Safety improvements come from organizations telling people to follow procedures and enforcing this.

• New view: Safety improvements come from organizations monitoring and understanding the gap between procedures and practice.

An Engineering View of Safety: Overview

• Safety is a control problem

– Accidents occur when the system design does not enforce constraints on safe behavior

• Safety must be designed into a system

– Engineering relies on modeling and analysis to analyze system design

• Identify physical behavior that can lead to accidents

• Identify where human errors are prone to happen

• Design or redesign the system to prevent accidents

Safety as a Control Problem

• Goal: Design an effective control structure that eliminates or reduces adverse events.

• Controls may be:

– Physical design

– Processes

– Social (cultural, policy, individual self-interest)

[Need more than just checklists]

• Engineers use a proactive approach

– Predict and manage adverse effects

– Through modeling and analysis (identify scenarios that can lead to accidents)

STAMP

• A change in emphasis:

“prevent failures”

↓

“enforce safety constraints on system behavior”

• Losses (accidents) are the result of complex dynamic processes where the safety constraints are not enforced by the safety control structure

• Most major accidents arise from a slow migration of the entire system toward a state of high-risk

– Need to control and detect this migration

© Copyright Nancy Leveson, Aug. 2006

ExampleSafetyControlStructure

Accidents occur when model of process is inconsistent with real state of process and controller provides inadequate control actions

Controlled Process

Model ofProcess

ControlActions

Feedback

Controller

Every Controller Contains a Process Model

Feedback channels are critical -- Design -- Operation

A Systems Engineering Approach to Radiation Therapy Safety

• Identify system hazards

• Establish system safety requirements to reduce the occurrence and/or consequences of hazards

• Ensure they are enforced by or implemented in the safety control structure

• Do a hazard analysis

– Identify unsafe control actions

– Identify the causes of the unsafe control actions

• Eliminate or control hazards

• Establish risk management controls and procedures

Identify Accidents and Hazards

Accident:– Injury or death of patient related to treatment

– Injury or death of staff or visitor

– Equipment damaged

– Environmental damage?

HazardH1. Overdose

H2. Underdose

H3. Inadequate fractioning

H4. Non-patient exposure to radiation

H5. Equipment stress

Highest Level Safety Constraint (Requirement)

“Process of care” must not be compromised

– Patients, staff, and visitors must not be exposed to an unhealthy dose of radiation

– Equipment must not be stressed beyond documented design limits

RT Hazards and Safety Constraints

H1: Patient tissues receive more dose than clinically desirable

SC1: The system must be able to prevent delivery of higher than clinically desirable dose

H2: Patient tumor receives less dose than clinically desirable

SC2: The system must be able to deliver sufficient dose to treat the tumor.

H3: Patient treatment is improperly fractioned

SC3: Each fraction must not exceed more than TBD Gy and must not be delivered TBD’ hours after the previous one without treatment plan being reevaluated.

H4: Non-patient (esp. personnel) is unnecessarily exposed to radiation

SC4: The system must be able to prevent unnecessary exposure of personnel and non-patients to radiation

H5: Equipment is subject to unnecessary stress

SC5: The system must prevent excessive equipment exposure to radiation.

System Safety Requirements

• A complete, formally documented, effective, and safe clinical treatment plan must be created for each patient undergoing radiation treatment. A radiation oncologist must select and formally approve the plan ultimately selected for treatment.

– Changes to the treatment plan must be evaluated and approved by a radiation oncologist.

– Standard operating processes must be provided that have been evaluated for safety and effectiveness. If SOPs are tailored, they must be evaluated and approved by

– Immobilization treatment devices must provide accurate treatment delivery and must not restrict the treatment techniques.

– Radiation safety guidelines (ACR/ASTRO and NRC) must be followed when therapy uses unencapsulated radionuclides.

– Dosimetry treatment plan must administer intended dose of radiation to the target volume while minimizing radiation exposure to normal tissues.

– A pretreatment quality assurance program must be in place and followed for every patient. The QA program must provide for checking the accuracy of both the dose calculation and the data used for treatment.

System Safety Requirements

• Verification and documentation of accuracy of treatment delivery (conforms to original or latest clinical and dosimetric plans) must be provided (includes management of organ movement).

• Modification of initial treatment plan (to adjust for changes) must be approved by radiation oncologist.

• Equipment must be calibrated and maintained according to AAPM guidelines and applicable state and federal regulations concerning radiation treatment delivery technology.

– Procedures must be created and followed to ensure that any possible sign of impending machine malfunction is quickly recognized and diagnosed and any necessary corrective or reparative action is taken prior to use of the machine to deliver a clinical treatment to patient.

– All radioactive sources must be carefully controlled and monitored at least to the extent required by regulatory agencies.

• Radiation oncologist, along with other members of the team, must review and manage ongoing treatment to ensure that it is effective and safe.

System Safety Requirements

• Follow-up evaluation and care must be provided to manage acute and chronic morbidity resulting from treatment.

– A process must be established to monitor for unexpected morbidity, tumor relapse, [etc.], to identify any possible safety problems during treatment and to identify measures that might reduce the risk of toxicity for future patients. All suspicious findings must be thoroughly investigated and resolved.

• [Patients must receive an appropriate level of medical, emotional, and psychological care during and after treatment]

• Staff must be protected from accidental radiation exposure.

• Appropriate arrangements must be made for emergency patients.

• Procedures must be evaluated periodically to ensure they are being followed and, if not, then determine why. Use the information to improve the procedures.

• All emergency equipment and safety devices must be operational at all times during hazardous operations.

System Safety Requirements

• Management of change procedures must include hazard analysis for any planned change to individual treatment plans and to the facility itself including any safety-critical equipment.

• Procedures must be in place to identify and remediate any unplanned changes over time to behavior within the system or within its environment that can affect system hazards.

• Reporting systems must be created that follow Just Culture principles.

– Leadership must make all staff feel comfortable (and rewarded) for raising safety concerns without fear of reprimand or reprisal.

– All members of the team must be empowered to be active participants in improving the safety of clinical processes.

– Trends and migration toward states of higher risk must be identified and effective procedures created to disseminate this information to all staff and to provide corrective measures.

System Safety Requirements

• Procedures must be in place to identify and investigate thoroughly all serious or potentially serious incidents. Recommendations must be implemented to eliminate or mitigate all identified factors contributing to the adverse events. Follow-up must be provided to ensure that recommendations have been implemented and are effective. Lessons learned must be documented and disseminated.

• A process must be established to evaluate the safety (identify hazards) associated with any equipment purchased from vendors or created in the hospital. Thoroughness and quality of the vendor’s hazard analysis and design for safety must be a major criterion in selecting a vendor. A two-way communication channel must be established to provide on-going communication about errors, incidents, and potential hazards.

System Safety Requirements

• The hospital must establish the safety of integrated systems purchased from multiple vendors and the introduction of new equipment into the total clinical environment. Sophisticated hazard analysis methods must be used to identify potential safety concerns about individual equipment or the integrated equipment and operational environment.

– Hazard logs must be created and maintained and used in the investigation of adverse events and in periodic performance audits to ensure that hazards are being adequately controlled and that the staff is sufficiently educated about the hazards involved in their job. Leading indicators of increasing risk must be identified and monitored.

– All staff must be educated on the hazards of their job responsibilities and the equipment they operate

– Hazard analysis must include the analysis of human–automation interaction. Design methods must be used to minimize any potential human errors and HMI hazards, including investigating and reducing the frequency of spurious alarms and providing error messages and indications of safe operating limits for any potentially hazardous operation.

System Safety Requirements

• Safety-related decisions must be independent from cost and efficiency concerns. Conflicts must be identified and transparent resolution procedures created and followed to resolve any conflicts.

• The hospital must have a documented safety policy and a documented safety management plan. This policy and management plan must be periodically reviewed and updated and communicated to staff. Conformance with the safety policy and safety management plan must be monitored.

• The hospital must create and maintain a comprehensive safety information system.

• Robust feedback channels must be provided to enhance risk awareness to those with responsibilities related to the safety of the patients and safety.

Trace System Safety Requirementsto Safety Control Structure

• All personnel must have and maintain a minimum level of knowledge and training.

[pointers to Board Certification Process, Education process including continuing education, responsible official for training at UCSD, each staff component]

[includes initial orientation, education, credentialing, continuing education, and periodic evaluation]

• Completion of any component of care must be appropriately documented in the patient record

• Patients must be evaluated to determine if treatment is recommended

– Patient evaluation must be conducted by a qualified physician in consultation with other team members.

High-Level Control Structurefor Gantry 2

Treatment Delivery

Patient

Treatment Definition

Therapeutic Requirements

1. Treatment Specifications (fraction definition,

target positioning information, steering file)

2. Capability Upgrade Requests

Patient PreparationBeam Creation and Delivery

QA resultsPatient physionomy

change

Patient well-beingPatient physiognomy changes

(delayed) Patient health outcome

Treatment Delivery – D0

Patient

Treatment Definition – D1

Steering file with treatment specification(fraction definition,

patient positioning information, beam properties)

Patient PositionBeam Creation and Delivery

QA resultsPatient physiognomy changes

(delayed)Cure evaluation

Prognosis

Medical Doctor

Medical Physicist

Treatment Planning Software

Steering File Generator

Imaging Facility

(CT/MRI)

Propose treatment plan

Define tumor volumeSpecify treatment dosesApprove treatment plan

Mapbody

Combine CT and MRI imagesCalculate dose distribution

Define field direction

Define fields (direction, energy, intensity)

Patient well beingPatient physiognomy changes

Capability upgrade requests

Tumor Board

Request therapy slot for patientApprove patient

Zooming into Treatment Definition

PROSCANDesign Team

Operations Management

Treatment Delivery – D1

Patient

Treatment Definition – D0

Patient PositionBeam Creation and Delivery

QA results

Maintenance Operators Medical Team

PROSCAN facility (physical actuators and sensors, automated controllers)

Software revisionsHardware modifications

Problem reportsIncidents

Change requestsPerformance audits

Work ordersResources

Procedures Problem reportsChange requests

Problem reportsChange requests

Hardware replacements

Revised operating procedures

Start treatmentInterrupt treatment

Procedures Problem reportsChange requests

Test results

QA resultsSensor info

Patient positionInterrupt treatment

Room clear

(delayed)Cure evaluation

Prognosis

Patient well beingPatient physiognomy

changes

Panic button

Treatment specifications (fraction definition, patient positioning information, beam characteristics)

Capability upgrade requests

PositionMovement

Patient position

Zooming into Treatment Delivery

Operation Management

Medical Team

Patient & Fixationdevices selection

Patient list,Procedures

Patient position on

Table

Medical Team+ Patient

CT imaging

Positioning Offsets

Patient Positionon Table

GPPS

Gantry + Table in Room referential

Gantry + TableMotors

Encoders,Potentiometers

TCS

Beam in Gantry

referential

Sweeper magnets

Strip chambers

Local Operator

Beam & Patient alignment

Treatment Definition – D0

Patient list,Procedures

Steering file

Treatment Report

Loop1

Loop2

Loop4

Choice of Steering fileManual Corrections

Steering File Application ProgressSystem Status

SetpointBeam location

at detectorGantry + Table

Position

Encoders,Potentiometers

Status

Gantry + TablePosition

Steering FileApplication Progress

TreatmentReport

TreatmentReport

TreatmentReport

Patient list,Procedures

Loop3

Process Attributes

Treatment Delivery – D2

Beam and Patient Alignment Control

Process model

Process variable

Possible values

Comment

Personnel close not close

"close" is to be understood as "potentially leading to detrimental radiation exposure"."personnel" is to be understood as "non-patient" (can include visitors, family members...)"close" = close to beamline or inside the treatment room"not close" = not close to beamline and outside of the treatment room

Patient readiness (esp. position)

no patientreadynot ready

“Ready”: patient is in treatment room, at treatment point, in the correct position and ready for dose delivery"Not ready": patient is in treatment room, but not ready for dose delivery (e.g. incorrect position)

Treatment plan ID

rightwrongnone

"Right"/"Wrong" refer to whether the correct treatment plan has been selected and loaded for the patient awaiting treatment. "None": no treatment plan has been loaded

Equipment readiness

readynot ready

"Ready"/"Not ready": with respect to treatment start

Mastership status

masternot master

"Not master": other areas have the power to control beamline elements

Facility mode therapynon therapy

"Therapy": facility is configured for patient treatment application. All the patient safety and machine interlocks are enabled and remote operator control is disabled."Non-therapy": facility is configured to allow more flexibility for experimental purposes. Some patient safety and machine protection interlocks are disabled by default. The interlocks can be remotely disabled/enabled by an operator.

Treatment status

no treatmentin progressinterrupted

"Interrupted": treatment was previously in progress, but was stopped before completion and is expected to resume for the dose delivery to be complete

• System hazards: …

• Controller: Area Operator

• Control actions:

– Load steering file

– Start treatment

• STPA Step 1: identify unsafe control actions

• STPA Step 2: identify unsafe scenarios that lead to the unsafe control actions

Operator

Therapy Delivery System

1.2 Load steering file1.3 Start treatment

Beam characteristicsTreatment progress

Beamline controllers

Irradiation at patient

Labelcontroller controlled process

Previous progress informationDaily plan and updates

Patient

ConfigurationBeam characteristics

Actuator settingsTreatment progress

Nurse

Previous progress informationDaily plan and updates

Beamline actuators

Beamline sensors

Status Status

Well-being

Example: Operator Starting Treatment

• Treatment is started while personnel are in room (↑H-R4)

• Treatment is started while patient is not ready to receive treatment (↑H-R1, H-R2

Note: This includes “wrong patient position”, “patient feeling unwell”, etc.

• Treatment is started when there is no patient at the treatment point (↑H-R2, H-R3)

• Treatment is started with the wrong treatment plan (↑H-R1,H-R2)

• Treatment is started without a treatment plan having been loaded (↑H-R1,H-R2)

Example Unsafe Control Actions (1)

• Treatment is started while the beamline is not ready to receive the beam (↑H-R1, H-R5)

• Treatment is started while not having mastership (↑H-R1, H-R2, H-R4)

• Treatment is started while facility is in non-treatment mode (e.g. experiment or trouble shooting mode) (↑H-R1, H-R2)

• Treatment start command is issued after treatment has already started (↑H-R1, H-R2)

• Treatment start command is issued after treatment has been interrupted and without the interruption having adequately been recorded or accounted for (↑H-R1, H-R2)

• Treatment does not start while everything else is otherwise ready (↑H-R1, H-R2)

Example Unsafe Control Actions (2)

Hazard Causal Scenarios (Causes of Unsafe Control Actions)

1. (missing input) – no treatment file available and TDS loads previously used one

2. (wrong input) – error in treatment planning and treatment file is incorrect

3. (wrong input) – operator loads file from previous fraction

4. (distorted transmission) – changes to daily plan not correctly communicated/understood by operator

5. (actuator failure) – GUI fails to transmit the new steering file and TDS uses previously loaded one

6. ….

also: inadequate feedback (sensor failure, wrong sensor calibration, …), external perturbations etc.

UCA4: Treatment is started with wrong treatment plan

Causal Scenarios

• Scenario 1 - Operator was expecting patient to have been positioned, but table positioning was delayed compared to plan (e.g. because of delays in patient preparation or patient transfer to treatment area; because of unexpected delays in beam availability or technical issues being processed by other personnel without proper communication with the operator).

• Controls:

– Provide operator with direct visual feedback to the gantry coupling point, and require check that patient has been positioned before starting treatment (M1).

– Provide a physical interlock that prevents beam-on unless table positioned according to plan

Example Causal Scenarios (2)

• Scenario 2 - operator is asked to turn the beam on outside of a treatment sequence (e.g. because the design team wants to troubleshoot a problem) but inadvertently starts treatment and does not realize that the facility proceeds with reading the treatment plan.

• Controls:

– Reduce the likelihood that non-treatment activities have access to treatment related input by creating a non-treatment mode to be used for QA and experiments, during which facility does not read treatment plans that may have been previously been loaded (M2);

– Make procedures (including button design if pushing a button is what starts treatment) to start treatment sufficiently different from non-treatment beam on procedures that the confusion is unlikely.

Organizational Aspects of Risk

• Example so far focuses on physical level

• Also requirements and control responsibilities at management level to satisfy system safety requirements

• Can identify unsafe control actions and causal scenarios at higher levels of the control structure (perform a risk analysis) and build in controls to prevent them

• Behavior and control structures change over time

– Prevent migration to higher levels of risk

– Detect when occurs

© Copyright Nancy Leveson, Aug. 2006

Additional information in:

Nancy Leveson, Engineering a Safer World:

(Systems Thinking Applied to Safety) MIT Press, January 2012