July 19, 2021

Risks from an Inadequate Development Process for Software

The most fundamental reason for medical device design and development controls (e.g., ISO 13485 clause 7.3; the U.S. FDA’s 21 CFR 820.30, etc.) is to control risks that come from an inadequate development process.  That fact is unequivocally true and stands in stark contrast to the erroneous notion that there are no risks from the software development process.  For example, in a 6-year study, FDA found that approximately 44 percent of medical device quality problems leading to recalls were attributed to design errors that FDA says may have been prevented by adequate design controls.  And regarding design and development of software, FDA did a subsequent study for fiscal year (FY) 1983 through FY 1991 and found that a whopping 90 percent of all software-related device failures were from failure to have a proper software development process.

When approaching risk management regarding the software development process itself (as distinguished from risk management of the software medical device), the general paradigm needs to start from a process-focused approach rather than a device-focused starting point.

There are multiple ways to do process-focused risk analysis.  Now, we all know how important it is to realize that FMEA, on its own, is not sufficient to meet ISO 14971’s risk management and analysis requirements.  But for temporary discussion purposes, I’m going to dare say something slightly to the contrary in order to help drive home the process-focused concept mentioned above.  Specifically, to really grasp the distinction of the process-focused concept, think in terms of p(process) FMEA vs. d(design) FMEA.  Okay, there I said it.  Now quickly, while my colleagues (and me too of course) are catching their breath and settling down about the mention of FMEA in the context of risk management, I’ll reiterate the disclaimer that we need to be sure and remember FMEA’s intrinsic limitations and intent.

So, if you’re familiar with doing risk analysis for a process (instead of a device), then those principles are the ones that should be applied in order to do risk management of the software development process itself.  What can be confusing is that the ultimate purpose of medical device risk management is to control the risks to patients and users.  Consequently, it may well be (as the U.S. FDA has indicated), that an inadequate development process can indeed be ultimately correlated to patient and user harms.  But there may also be process-centric hazards and harms (derived e.g., via FMEA) that are focused on the process itself.  When that is the case, then bridge the ISO 14971 risk management gap by being sure to, where appropriate, ultimately extrapolate (by representation as resulting hazardous situations and sequences of events) into the patient or user harms.

Check out AAMI TIR 36 (Annex B ‘Severity’ explanation under ‘Risk management terminology as it applies to quality and production systems) and ISO 80002-2 (Annex B section B.4) for interesting interpretations of how process risk analysis can differ from product risk analysis. In addition, IEC 60812 also contains some good basic process FMEA insights which can reasonably be adapted for software development process risk analysis.

(Note that it’s only by mere coincidence that AAMI TIR 36 and ISO 80002-2 which I cited happen to involve a software-related context; please note that they aren’t intended to address medical device software validation, nor device software development.  Instead, I recommended these resources simply because they coincidentally happen to provide some good illustrations about doing process-focused risk analysis as distinguished from device-focused disk analysis.)