Does anybody use Detection in medical device Design FMEA?

[indubioush]

Hi All. Do any of you use detection in your FMEA RPN calcuations? When I am in control of the risk management methods and documentation, I do not use detection. However, now I am in a situation where I am only a reviewer of the SOP, not the writer. I'm going to have to make a case for not using detection in the DFMEA. I know that some companies still use it is the PFMEA through. If it is used, how are the RPNs from the PFMEA reconciled with the RPNs from the DFMEA? Also, please know that I am aware that FMEA is not used for compliance to ISO 14971, no need to have that discussion here.
Thanks for your input.

 

[Watchcat]

Why do you not use detection?

 

[John Broomfield]

Detectability exposes hidden failure modes before the effect of the failure modes occur.

Best not to ignore them just because we cannot detect them.

RPN helps us to manage our resources as we take preventive action to get the risks as low as possible. For medical device design this will require several FMEA>preventive action cycles (updating the FMEA each time) instead of just addressing the failure modes with the highest RPN.

Edited to show that the RPN need not stop FMEA from getting the risks as low as possible.

 

[Tidge]

Why do you not use detection?

One of the reasons why organizations move away from using Detection (specifically in Design FMEA) is that the organization cannot come to consensus on what it means to assign a Detection rating for certain failure modes prior to the implementation of an identified risk control.

A classic RPN ('Risk' Priority Number) FMEA calculation where RPN = D (detection rating or "detectability") x O (occurrence rating) x S (severity rating) I'm familiar with organizations that have no problem coming up with pre- and post-control assessments of S and O, but are flummoxed by D. One element of the problem people have with D for a failure mode is that engineers tend to be very binary about whether the failure mode is valid or not. If the design team doesn't consider it to be a potential failure mode they simply ignore it (and it doesn't get into the RM file); if they think its a possibility they will add it but then they are only comfortable making a post-control assessment of the detectability of the failure mode. If they don't have a pre-control guesstimate then they are at a loss of what it means to have improved D.

Personally: I prefer to keep D as a rating in all FMEA. Detection is distinct from Occurrence and I see value in having it as a rating as seeking improvement in D can drive design and manufacturing choices. (*1)

Within Design FMEA, my personal advice to less mature design teams for assigning D ratings prior to the identification of risk controls is rather simple and is based on design methodology rather than design choices. For example: An ad-hoc (or reactionary) approach to design that emphasizes testing (for the effectiveness of risk controls) only will merit a poor D rating (prior to implementing risk controls). If the specific design choice is pulled from a library of 'time-honored' (i.e. well understood) solutions specifically relevant to the identified failure a (at least) slightly more improved D rating. For certain Medical Electrical devices particular 60601-2-xx standards explicitly require certain detectability-driven design choices because of known failure modes. Once a design requirement has become the established state of the art, for particular and specific failure modes those design choices could merit extremely good D ratings. This approach isn't perfect, but it allows for some consistency from design teams that have a wide spectrum of risk analysis experience.

(*1) A possible example of a design choice to improve a D rating: If a medical device has the potential to 'wear out' in away that may not be obvious to a patient or user, something could be implemented to indicate that it is 'wearing'. Presumably the S and O ratings are not changed, but the priority of this failure mode (within the greater context of the risk profile for the finished device) is presumably reduced. This solution is different than 'just use materials that don't wear out', as that would be an attempt to address the O rating.

 

[indubioush]

Why do you not use detection?

Because risk is the combination of the probability of occurrence of harm and the severity of that harm. Notice how detection is not mentioned.

The argument against detection is that what you are really doing with detection is reducing the occurrence. Why should detection be a full third of your risk calculation when clearly, severity and occurrence are the two main factors? Tidge, thank you for explaining the value in D. I do see what you mean, but I'm curious how you calculate risk. Do you have a separate hazard analysis that calculates risk based on ISO 14971?

I'm curious whether the new ISO 24971 guidance discusses this. Has anyone seen a draft of this?

 

[Tidge]

Tidge, thank you for explaining the value in D. I do see what you mean, but I'm curious how you calculate risk. Do you have a separate hazard analysis that calculates risk based on ISO 14971?

We have a separate Hazard Analysis (required per product RM Plan) that is supported by (design, manufacturing process, and use) FMEA. The HA is where we formally analyze risks, but through some traceability the FMEA are (generally) where the best details of individual risk controls (identified in the HA) are found. We have other documents, but I think the picture gets some focus with just these details. Because we leverage FMEA, every FMEA line ends up tracing to (often multiple) HA line(s).

This becomes a bit of a balancing act because (as we know) the FMEA is really just a tool for prioritizing design/process/use elements so in this system there is an assessment that the reduction of RPN numbers in an FMEA (via implemented controls) has an effect on the post-control risk ratings in the HA. If I were trying to design a RM methodology from scratch, I wouldn't immediately jump to using FMEA in the specific way I just described for a variety of reasons I won't list here, except to write this:

FMEA (especially process FMEA) are very good at identifying potential contributors to risk. The FMEA are also very good at identifying controls for those potential risk contributors. This doesn't mean that a general FMEA process is going to specifically speak to risks identified through a general analysis of specific risks at an HA level. This is a contributing factor why design teams often stumble over the inclusion of detection in design FMEA: dFMEA almost universally describe the device as designed, with (hopefully adequate) design choices made to specifically reduce previously identified risks.

 

[Watchcat]

First, I am aware that there are those who have strong preferences for some risk-related tools over others. I am not expert in any such tools, so this is a choice I leave the engineers. I think FMEA has its limitations, but I like it because I'm used to it, and I can get what I need from it. Second, I do not think anyone should be assessing clinical harms except clinicians, nor do I think anything about clinical harms should be described with numbers. With this in mind...

If by "Detection" you mean the likelihood that a clinical harm will be detected, then, if you are going to insist on trying to describe clinical harms with numbers, Detection is critically important, as it can have a strong impact on Severity. As an example, a cancer that is easily detected may be easily cured before it does severe harm. A cancer that is not easily detected may not be diagnosed until it is too late to treat.

If this isn't what you mean by "Detection," never mind then.

 

[Tidge]

A common guidance on Detection (as a rating) within an FMEA to support medical devices is this: "Detection is the ability to detect the failure mode before the effect of the failure mode occurs." It's not easy to find a specific guidance document for medical devices that explicitly says this (presumably because of the long history of FMEA outside of medical devices, but also the reluctance to prescribe specific approaches) but this aligns with the informative text of 60812:2018 and is an extension of the term "fault detection = event by which the presence of a fault becomes apparent" found in the electropedia.org.

Outside of medical devices, the term is more-or-less used consistently in the context of FMEA but with the sort of variety you would expect from different industries. For example the International Marine Contractors Association guidance definition reads "Detection is an assessment of the likelihood that the mechanisms provided to prevent the Cause of the Failure Mode from occurring will detect the Cause of the Failure Mode or the Failure Mode itself." An older guidance (SAE J1739:2000) from the US automotive industry defines detection as the ability to "detect the cause/mechanism or failure mode, either by analytical or physical methods, before the item is released to production."

I believe that there are plenty of reasons to disfavor the use of design FMEA as a primary tool in medical device risk management, with the key disadvantage being their history: FMEA have been around long enough that some folks may accept FMEA without recognizing the inherent limitations... and it just takes a couple of misstatements or misunderstandings (*1) (*2) to expose potential issues with a medical device manufacturer's risk management process. Even writing this, I fully believe that FMEA are a solid tool that have a place withing medical device risk management.

(*1) As an example of a classic FMEA methodology that will run afoul of current (European) thinking is: Classically the RPN value was established as a prioritization method to set thresholds for where "actions" (i.e. risk controls) are required. The current thinking around medical devices is to make risks as low as possible, which can be addressed within FMEA but only by sacrificing the prioritization.

(*2) Another issue with FMEA methodology is the use of the term RPN = Risk Prioritization Number. 'Risk' has a well defined concept that doesn't play nicely with the old school FMEA methods, and as mentioned in (*1) the current thinking is that all risks have to be reduced, no matter the 'priority'. Does anybody have a good suggestion as a replacement term for RPN?

 

[Watchcat]

In that case, it sounds redundant with occurrence, assuming that, if you detect it before the failure mode occurs, you prevent it from occurring?

I will also add that I find myself talking at cross-purposes with many people when I talk about risk. I have concluded that there is (or is often) a total disconnect between premarket risk assessment of the kind that determines a device's regulatory classification, and the process of risk management postmarket. I cannot speak to the usefulness of the FMEA for the latter.

For premarket risk assessment, I'm still fine with engineers using whatever works for them, But maybe what happens in design engineering should stay in design engineering.

 

[Watchcat]

Does anybody have a good suggestion as a replacement term for RPN?

My suggestion would be to start by determining what people think that number actually tells them.

FWIW, I'm fine with "prioritization." I'm not fine with the notion that all risks should be reduced, because I think prioritization is the whole point of risk management. If a risk management effort doesn't support prioritization, then it's largely useless, IMO. It's obviously a number, so that leaves the R. I suspect this is wherein the problem lies, but only those who rely on the FMEA for risk-something can explain what kind of risk it represents to them, how it does that, what value this might have, and for what.