ISO 14971 Medical Device Risk Management FAQ

S

sanok

Hi All,

When presenting the Risk Management Plan and Risk file to get audited by an agency,

1. Should risks be changed to 'closed status', only after leaving no residual risk or residual risk still be present?

2. Should all the risks be closed compulsorily or it can still have status of 'work in progress' or 'open' ?

Thanks for your replies and guidance in advance.
 

Ronen E

Problem Solver
Moderator
Hi All,

When presenting the Risk Management Plan and Risk file to get audited by an agency,

1. Should risks be changed to 'closed status', only after leaving no residual risk or residual risk still be present?

2. Should all the risks be closed compulsorily or it can still have status of 'work in progress' or 'open' ?

Thanks for your replies and guidance in advance.

Hello and welcome to the Cove :bigwave:

Generally speaking, the overall risk posed by the device should be at an "acceptable level" before placing the device on the market (and thereafter). It's possible to have individual risks at an "unacceptable level" and the overall risk "acceptable", considering the benefits of the device.

The meaning of "acceptable" varies according to the regulatory domain (the market where the device is placed) and the standard according to which you operate. For example, the MDD (as currently interpreted by NBs) & EN ISO 14971:2012 are stricter than ISO 14971:2007.

Cheers,
Ronen.
 

Peter Selvey

Leader
Super Moderator
I guess this question relates to giving the technical file to the NB while the design project is still in process, not yet actually released to market.

In theory this is OK. In Europe the most common approach (Annex II, Annex V) is not product approval, rather quality system approval. The NB should be able to see enough to have sufficient confidence in the quality system.

The NB may be reasonably interested in certain subjects (critical design aspects, protection features) and needs to see these complete in order to judge if the quality system meets the requirements.

Some NBs insist on a separate technical file review for each device, and make this appear as pre-market approval. Since this is not required by the regulations, it is really up to the NB to set the rules/requirements for this process, such as whether open items are allowed. And it may be possible to challenge this since it is outside of the regulation. The separate review itself is OK, but the law only applies when the product is placed on the market.

Having worked in this area for a long time, it is clear that when manufacturers have to deal with pre-market processes (e.g FDA, Health Canada), what they usually do is have special technical file for the regulators. This file is is fairly simple and shows everything is OK, even though in fact the designers are still ironing out the bugs, refining risk based decisions, tests are just on prototypes, software keeps crashing: in other words far from representative of the final medical device. This approach is needed because the pre-market approval process can often take months. If the design was really complete, the manufacturer would just have to sit idle while waiting for regulatory clearance. It shows how the Europeans were smarter by avoiding pre-market approval in most cases. Unfortunately some NBs don't understand this and try to act as de facto pre-market approvers.

Instead, the regulators should focus on sampling files from products that are already on the market, with appropriate penalties to act as an incentive for manufacturers to get thing right in the pre-market stage.
 
S

sanok

Thanks Ronen and Peter for your replies. That makes things clear a bit and by the way it is for the product which is already out in the market.

Whilst ISO 14971:2012 says about the requirements to fulfill it also gives the onus to the manufacturers to define the acceptable limits of risks and residual risks. So learnt that if they are falling within the defined limit and out side the preview of MDD/385 it is okay, just wanted to share.
 
L

LightAudit

Hello,
I am reading your comments and FAQ on ISO 14971:2012. Do you have more FAQ or links where I can find Q/A on this standards?

Thanks a lot! Great info on the posts:applause:
 

Marcelo

Inactive Registered Visitor
Hello,
I am reading your comments and FAQ on ISO 14971:2012. Do you have more FAQ or links where I can find Q/A on this standards?

Thanks a lot! Great info on the posts:applause:

Hello, thanks, Unfortunately, I do not know any other source for questions and answers.
 
N

newbean2

Hello,
I am new to the RA industry, been in a couple months from basic and clinical research (bio/oncology). My top management told me to redo our risk program (sure, no big deal) and make it conform to EN 14971:2012.

They have refused to define risk acceptability criteria and won't help me figure out what to say in the SOP. We make IVDs and they want to link the risks to false pos/neg results and specificity. They can't give me a touchstone document to look at and from reading 14971 it does not define what's acceptable. I am at a total loss.

I have written something generic like "risks are mitigated to the lowest possible level and residual shall only be accepted after risk-benefit analysis of each individual risk and all risks taken together and balanced against the device as a whole." They are not happy with this, they say too vague. I don't know what to do. Am I seeing this wrong? Please help me! Thank you.
 

Peter Selvey

Leader
Super Moderator
You have fallen onto the big hole in the whole model of safety based on "acceptable risk": we can't measure risk. Hence it's impossible to build a system that involves making decisions by comparing the estimated risk against an pre-established criteria.

Once you realise this, the whole thing should get easier, because you stop wasting time trying to make sense of it all: just relax, it doesn't make sense.

If you look in Annex D of ISO 14971 the do, in fact, suggest some criteria, for example if you combine the tables in D.3.4.2 and criteria in Figure D5. So, you could think about adopting that at least as a starting point.

Personally, I think these are very relaxed criteria since it is based on "per use" and the are more appropriate for a "per year". If think about cumulative effect, say a patient in hospital that has patient monitor, IV pump, ventilator, hospital bed, various sets and accessories, and each manufacturer is using a criteria in D5 for each line in the risk table, you will quickly realise that the criteria is way too high for a "per use" basis. But the fact that no one has picked up on this is really just illustrates even more that we can't measure risk, otherwise the error would have been detected and corrected a long time ago.
 
N

newbean2

You have fallen onto the big hole in the whole model of safety based on "acceptable risk": we can't measure risk. Hence it's impossible to build a system that involves making decisions by comparing the estimated risk against an pre-established criteria.

Once you realise this, the whole thing should get easier, because you stop wasting time trying to make sense of it all: just relax, it doesn't make sense.

If you look in Annex D of ISO 14971 the do, in fact, suggest some criteria, for example if you combine the tables in D.3.4.2 and criteria in Figure D5. So, you could think about adopting that at least as a starting point.

Personally, I think these are very relaxed criteria since it is based on "per use" and the are more appropriate for a "per year". If think about cumulative effect, say a patient in hospital that has patient monitor, IV pump, ventilator, hospital bed, various sets and accessories, and each manufacturer is using a criteria in D5 for each line in the risk table, you will quickly realise that the criteria is way too high for a "per use" basis. But the fact that no one has picked up on this is really just illustrates even more that we can't measure risk, otherwise the error would have been detected and corrected a long time ago.


Thanks for the reply. I should have mentioned that my initial draft did not have an acceptability policy, but top management said it was needed for conformance with standard and that auditors look for it. After that I spent a lot of time chasing one down and chasing my tail. In the end, I didn't write one for the second draft but stuck with vague and general statements but managers were still unhappy and suggested I had done a poor job. Maybe I am out of my depth, but I can't tell because I'm too new. The general process we use to id harms/hazards and rank probability and severity boggles my mind as it is so subjective. Thank you for the insight
 

ratamatafon

Registered
Question 6 - What is required to be in a ISO 14971 risk management file (RMF)?

Answer - A comprehensive list is given below. It´s based on what is directly required by the standard. Please note that the RMF is per device.

…..

7 - Data used and the sources (e.g. accident history, experience gained from risk reduction applied to similar medical devices, etc.)
…..

Welcome everyone,

I had an internal discussion with my colleagues in R&D department during internal audit about this topic. They claimed that providing the source of the risk in their Risk Management File is not required. They claimed that PMS process and production is providing the input to the Product Risk Assessment. Additionally they said that new PRA is a copy of the previous PRA and "cleaning up" is a part of development process, however they wanted to defend it on records level by comparison of old and new PRA. They also claimed that Annex E is only informative therefore not mandatory.

My point was that I couldn't see in their first version of approved Risk Management file any evidence that they identified and analysed any known hazards associated with the device. There was not such column like "Source".

Can you please elaborate? Will you really expect column "source" in Risk Management file to show the clear evidence that experience with the same and similar types of device was taken into account?

I would really appreciate your opinion.
 
Top Bottom