Q: I have a question about documenting risk analysis, especially software hazard (risk), to satisfy FDA’s requirements for hazard analysis under the Quality System Regulation (QSR) – particularly 21 CFR Part 820.30(g). At the same time, we want to meet the ISO 14971:2007 requirements for documenting risk analysis.
While the QSR requires documenting risk analysis based on the level of concern, ISO 14971 and IES 62304 require additional information beyond what’s required by the FDA. In addition, they use terms such as Hazardous Situation, Residual Severity, and others not found in the FDA rule and related guidance. Please advise how we can develop a hazard analysis template for medical device software that will meet both the U.S. and international standards.
A: When FDA offers guidance on anything, it tends to be very minimalistic. As a result, it may appear FDA requires less than what’s requested by other standards, but that’s not necessarily the case.
In a nutshell, FDA expects you to follow good risk analysis and management processes that minimize the risks. To achieve that result, FDA wants to allow you to use whatever type of risk analysis method that works best for your products and processes, so the Agency purposely limits the terms it uses.
[pullquote align=”right” cite=”” link=”” color=”” class=”” size=””]On closer look, FDA and ISO terms are more equivalent than you may first think.[/pullquote]
In contrast, ISO 14971:2007 tends to use terms and concepts found in Failure Mode and Effects Analysis (FMEA) more than other methods of risk analysis. But on closer look, the FDA and ISO terms are more equivalent than you may first think.
For example, FDA’s “Cause of the Hazard” = “Hazardous Event” = the “Hazardous Situation” used by ISO 14971. Yes, the term “situation” is broader than “event”. Think of it this way: the hazardous situation or cause of the hazard is a thunderstorm, but the hazardous event is the lightning strike. To determine the severity of the hazard, you need to identify the harm that goes with the hazard since severity is linked to the harm and not the hazard itself. In this case, lightning is a hazard, but there are multiple harms associated with it. The worst case is death. You could say that the severity of the hazard is death.
– “Residual Severity” — used by ISO 14971 — is calculated only in FMEA, but the concept of ensuring you have reduced the risks enough is also very important to FDA. FDA says you have to verify the method of control actually works; that verification could be done by calculating the residual risk, including severity.
– ISO’s “Mitigations of Residual Risks (when applicable)” = FDA’s Method of Control (e.g., alarm). Mitigations of residual risks comes about when, after the first mitigations of control are in place, there may be residual risks that still need to be mitigated or controlled. FDA says you must verify the controls work.
– Regarding ISO’s “Additional Hazards created from implemented controls” — FDA expects this too. But FDA rolls its expectation into your verification that the controls work and are sufficient.
So what should be in your template for documenting risk analysis? FDA has given you the minimum it expects, but if you’re also working in other countries, you need to use methodology that is complete and satisfies all the regulatory authorities.
For software, you need to understand how the software can fail and what controls need to be in place. Risk analysis and risk management have numerous methods you can use. While FMEA/FMECA is one method that works well during design, there are other methods that are less quantitative and can identify the hazards, harms, and causes so you can then identify the controls or mitigations. Many of these methods do not have a way to calculate the residual severity and residual probability of occurrence.
Don’t forget that ISO’s residual frequency applies to software, too. With systemic problems, this can be calculated. It’s only with what appears to be random events that you cannot calculate frequency of occurrence.
But if we truly understand the software and where it’s failing, we find it generally fails systematically, not randomly. It only appears to be random because our documentation does not allow the trouble-shooting needed to determine the systemic cause. Software will fail the same way — every time — given the same inputs or conditions.
Answered by Janis Olson, Vice President of Regulatory & Quality Services at EduQuest (22 years as an expert FDA investigator and as the FDA regional director of information management resources). Jan also is the lead instructor and developer of EduQuest’s Quality Risk Management for FDA/ISO/ICH Compliance training class.