Is the RPN (risk priority number) in the PFMEA really a RPN without the detectability

Hi all. I am working in a company in the medical field. The company is located on two continents. The one I am working for is the contract manufacturer, the other is the distributor. Some time ago our colleagues from abroad were audited. No critical remarks were found during the audit but the auditing team stated that we (both companies) are not assessing the risk correctly due to the fact that we haven't updated a particular document in a while. They also suggested that the Detectability value in the PFMEA should be removed. I think this was not something that should have been changed at all. Anyhow... Due to the fact that we are two companies with unique quality management systems they decided to change the numbering convention for the RPN without informing us. That triggered a number of actions and now we have to change our numbering convention. Which as you know will take some time. So my questions are: Can a RPN be a RPN without the detectability value when we are addressing the PFMEA? The other company is still treating the new risk value as a RPN. Shouldn't be a critical number now without the detectability value? And also should the detectability value be even removed from the PFMEA in the first place when there are already established controls in place that are justifying the control of the risk? Should we update an already established PFMEA and treat it as if it is a new one? Because removing the detectability means exactly that. Can the auditing company be wrong? I am a bit confused and if someone can explain this to me that will be great. Thanks.

John C. Abnet

Re: Is the RPN (risk priority number) in the PFMEA really a RPN without the detectabi

Good day @wardar90.
My first concern is that the "auditing team...suggested..."
I am inferring from your message that the "auditing team" is a 3rd party auditor. If that is the case, they are not to be consultants, but simply auditors.

Also, as you have eluded to, the RPN value is indeed, by definition, a calculation obtained by multiplying SEVERITY * OCCURRENCE * DETECTION. Even though the RPN value itself is dependent on numerous considerations (and likewise a "value" COULD be obtained by leaving out the "detection" value) and not necessarily the best tool for purposes of prioritization, it is nonetheless the method used by a PFMEA.

My last comment is actually a question. If your organization has utilized the PFMEA including the "detectability" value to identify and trigger the establishment of "DETECTION" controls, then it sounds as if the PFMEA, designed as intended which includes "DETECTION", is providing a benefit to your organization. My question, therefore, is -
why would your organization undue something that is established and providing benefit?

Summary: Do what is best for your organization (while meeting the requirements of the governing standards.

Hope this helps.
Be well.


Forum Moderator
Staff member
Re: Is the RPN (risk priority number) in the PFMEA really a RPN without the detectabi

To add on to John Abnet's excellent post, I personally think the detection parameter in a pFMEA is QUITE useful. It clearly, to me, helps characterize the likelihood of a failure escaping.

(I don't use detection for product-related FMEAs since if we can detect it, we should design to manage it.)


Quite Involved in Discussions
Re: Is the RPN (risk priority number) in the PFMEA really a RPN without the detectabi

Since 9001, doesn't require a method, you may apply a correction to your method, to say that is not fmea, and leave it as it is.
Say that you evaluate risk by multiplying severity x occurrence and you get the risk value and is that easy.
Remember, risk method is not required.
Instead you "patch" all your analysis, modify your method.
It's simpler.
Hope this helps

Marcelo Antunes

Addicted to standards
Staff member
Re: Is the RPN (risk priority number) in the PFMEA really a RPN without the detectabi

Question - why did you put this discussion in the ISO 14971 forum?

Your concerns have nothing to do with ISO 14971, and if you talking about ISO 14971, you may have a lot more problems.