STPA looks at how a device is controlled, and how unsafe interactions can arise with the patient, other equipment, the staff, and the clinical setting.
A bedside blood analyzer reported a patient’s electrolyte level as dangerously low. The real level was normal. If staff gave electrolytes through an IV to raise the level, the patient could suffer arrhythmia, seizure, or death. Reports like this led to a global recall.
The sensor had not failed. It detects electrolyte ions in the blood sample, but a deposit of foreign material on its surface kept the ions from reaching it. The designers knew a sensor’s readings could drift in exactly this way, so they built in a calibration run after each sample to check the sensor. But they also designed the analyzer to send each result before the calibration run, so staff get it quickly. Each calibration run takes as long as the blood test, and the analyzer repeats a failed run before giving up. By the time the analyzer added a warning to the result it had originally reported, staff at the bedside may already have acted on that result.
The device’s FMECA, accepted by regulators, looked for parts that could fail, such as a degrading sensor membrane. It had no place for a working sensor covered by a deposit, or for the conflict of reporting fast versus finishing the calibration run first. An MIT analysis built on STAMP, the model behind STPA and CAST, found both. In six of the analyzer’s roughly 20 control loops it found 175 hazards, versus 70 in the FMECA, and it produced the requirement the design lacked: hold each result until the calibration run is done.
Read the MIT thesisSystem-Theoretic Process Analysis (STPA) is a hazard analysis method developed at MIT. It finds unsafe interactions among a device, its software, the people using it, and the clinical setting, including interactions where every component works as designed.
At Massachusetts General Hospital, STPA of the Varian Ethos found 496 unsafe control actions, most from how staff and software interact rather than from equipment failure. On one IMRT process, it found hazards an earlier HFMEA study had missed.
Identifies potential for user errors, specific device behaviors that can cause or prevent user errors, solutions to prevent harm despite user errors, and ways to design interfaces or workflows that minimize confusion and improve safety.
Reveals unsafe control actions in embedded or closed-loop control systems where timing, environmental factors, available feedback, and the way decisions are made matter.
Identifies risks arising from inadequate coordination and misinterpretations among networked devices or hospital systems.
Extends beyond design to evaluate how the user context, clinical environment, maintenance, configuration changes, and updates can introduce new risks.
STPA identifies hazards and the scenarios that lead to them, for your hazard identification. The safety requirements it derives become risk control measures.
Unsafe control actions by software controllers show how software can contribute to a hazardous situation, which shapes software safety requirements.
STPA treats the user as a controller, so it finds use errors along with the device behavior and feedback that lead to them, for your hazard-related use scenarios.
Each requirement traces back through a scenario and an unsafe control action to a hazard, the traceability a submission needs.
SAE J3187, the published STPA recommended practice, applies to any industry, and a medical-device supplement, J3187-5, is in development. An STPA of cross-vendor interoperability fed Annex J of ANSI/AAMI/UL 2800-1.
Regulators and manufacturers are recognizing that system-level safety requires more than failure analysis. The U.S. FDA, medical device companies, hospital systems, and other industry leaders are increasingly applying STPA.
Medical device leaders that have used STPA to set the gold standard for system safety and device reliability include:
Each one links to its source.
See who uses STPASTPA provides a structured, engineering-driven way to uncover hazards early, define explicit safety constraints, and design more resilient medical devices that take into account the full operational context.
By moving beyond failure-based thinking, STPA helps teams address the safety challenges of modern healthcare technology systematically, with a better understanding of how their devices fit into the wider clinical setting.
