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.
------------------------------
Kevin Randall, ASQ CQA, RAC (Europe, Canada, U.S.)
Principal Consultant
Ridgway, CO
United States
© Copyright 2021 by ComplianceAcuity, Inc. All rights reserved.
------------------------------
Original Message:
Sent: 18-Jul-2021 09:37
From: Mor Sharon
Subject: Risks in software developing as medical device
Hi
What could be the existing / potential risks in the development process in medical software, which are medical devices.
The developers I spoke to argued that there are no risks and the main risks are in information security like software hacking. And in fact, there are no risks associated with the development process. In the risk analysis process, they suggested listing risks associated with the software users.
I would appreciate yours expertise, ideas and opinion on that issue
Mor
------------------------------
Mor Sharon
Regulatory Affair Specialist
OROT
Israel
------------------------------