ISO 14971 Medical Device Risk Management FAQ

[MIREGMGR]

Note that this thread is focused on ISO 14971 as applied in an ISO 13485 context. There may be some differences in how it applies in a US FDA context.

US FDA "sort of" uses ISO 14971...they recognize it as a consensus standard, it's the only directly-risk-management-focused standard they recognize, and they say in guidances that they expect risk analyses and/or a risk-based approach.

However, my experience-based understanding is that FDA often does not follow the approach to risk management explained earlier in this thread in regard to certain aspects of contract manufacturing, specifically those involving validated processes including but not limited to sterilization, and contract manufacturing of certain device types where the product is critical to life and/or the contract manufacturer is regarded by FDA as having either special expertise or substantially greater knowledge than the responsible manufacturer.

In such circumstances, FDA may regard the contract manufacturer as co-responsible for the product or process. There have been multiple instances of this approach revealed in Warning Letters over the past several years.

For a contract manufacturer that may be subject to such an FDA interpretation, in my view the prudent managerial approach is to conduct and document a risk analysis covering the full scope of your activity and your knowledge of how that activity may affect users and patients. My view would be that if you don't know enough about the product's use to properly do such an analysis, you might want to learn more about the product use-risks before proceeding.

It's also noteworthy that, at least in my experience, US FDA ignores the risk-to-environment aspects of ISO 14971 except in regard to environmental hazards that themselves present an acute hazard to users and/or patients.

 

[Marcelo]

Note that this thread is focused on ISO 14971 as applied in an ISO 13485 context. There may be some differences in how it applies in a US FDA context.

In fact I was thinking of doing a thread related to the standard as a standard, and not directly related to any certification/regulatory use, because they really change for each certification/regulatory system. But doing this is difficult and in practice people here need help not only with the standard per se but also in using them in a certification/regulatory context.

So thanks for your input regarding the FDA, I will change it into a question and answer if that´s ok for you, and will also make it more clear on the beginning of the thread those distinctions.

Update: another problem here might be that the FDA, as you mentioned, "sort of" uses" 14971, so they use it the way they want. This is true for a lot of reg systems - they require some kind of risk analysis / risk management, and not directly ISO 14971.

 

[Marcelo]

Question 7 - Which functional group would be the best to take responsibility for each of the 20 tasks listed in Question 6, and which group(s) would be the supporting contributor(s)? A matrix?

Answer - the 20 points mentioned in Question 6 DEAD LINK REMOVED. are not tasks, but information required by ISO 14971. You will probably need a lot of additional "tasks" to get some of the information required.

Also, the "functional group" related to those information gathering really depends on the nature and use of the device.

As a generic answer, the following team of functions might be needed for a complex medical device (and even for less complex ones):

- A clinician/doctor which understands the disease/therapy/etc. which the medical device aims to cure/treat/etc.

- A system engineering which understand the system architecture

- Different types of engineers depending on the device nature: mechanical, electrical, hardware, software, quality

- Biomedical engineer to act as the bridge between the clinician and other engineers, interpreting inputs from both sides and "translating" them to the other

- Regulatory affairs staff to input and interpret regulatory requirements

- Risk managers to manage the risk manage process and team

Please note that this does not mean that a company has to have all these people/functions - it´s better to think that the knowledge provided by those functions is needed, instead of the functions per se.

Contributors - Treesei, Marcelo Antunes

 

[aeropel]

Hi Marcelo,

Thanks for the information summarized.
I am quoting:
"Question 1 - Does ISO 14971 applies to hazards/hazardous situations other than the ones affecting people/property/environment? For example, does it applies to faults or failure modes which does not result in harm to people/property/environment?

Answer - The simple answer is - no, those situations are not expected to be part of a risk management process per ISO 14971.

A better explanation follows:

Hazardous situations are circumstance in which people, property, or the environment are exposed to one or more hazard(s) (ISO 14971, 2.4).

They are related to the "outputs' of the device, meaning, the interaction between the device and people/property/environment."

Dilema:

An ECG recorder, Battery operated, not for emergency and non life saving device, no display, no printed output, no alarm function, no analysis function. Just for storing the ECG in memory for later sending it to a computer with software that can display it) - what are the hazards that the output of such a device can have with respect to patient, operator etc.?

 

[Marcelo]

Dilema:

An ECG recorder, Battery operated, not for emergency and non life saving device, no display, no printed output, no alarm function, no analysis function. Just for storing the ECG in memory for later sending it to a computer with software that can display it) - what are the hazards that the output of such a device can have with respect to patient, operator etc.?

Well I hope you are asking for a generic answer here

First - if this is really only for recording information, it problably does not
fit the definition of medical devices of ISO 14971.

But anyway:

Anything that uses batteries will have electrical hazards.

Anything electrical will have EMC hazards.

Any medical device (in fact any device) has usability hazards.

If it transmit information, it will surely have interoperability hazards.

If it connects to other devices it will have interconnection hazards.

Just to name a few that comes to mind.

 

[Peter Selvey]

Just an additional comment to Q3 ~ Q5 which are all on the same subject. Although the manufacturer is ultimately responsible, in many cases subcontractors do play the lead role in creating the risk management file (e.g. in the case of OEM).

In these situations, the best way to think about it is that regardless of the practical structure, there should only be one risk management file for every medical device. It cannot be that the labelling manufacturer has one file while the design company has another, production company has another and software designers another, all relating to the same medical device. It is possible however, that the labelling manufacturer designates that the design company has practical responsibility for the file, becoming the single "owner" to use Marcelo's phrase.

There is a second point here which relates to phrase "ISO 14971 is only worried about hazardous situations, so it´s only worried about the failures modes which are part of a sequence of events which results in a hazardous situation".

This is not correct: the term "hazardous situation" is based on the definition of "hazard" which includes the term "potential". This subject is a big issue (what hazardous situations to include in the risk management file) and there is evidence that ISO 14971 definition is flawed, but at least in a guide on ISO 14971 it should be accurate according to those definitions.

There are many situations where a failure mode (or sequence of events) is self contained, but only as the result of deliberate design decisions. Technically, these are part of ISO 14971. The flawed part is that there are virtually an infinite number of these decisions if the whole life cycle is considered.

In practice (i.e. outside of ISO 14971), the point of differentiation seems to be based on whether the risk control is standard practice, or otherwise obviously safe to a reasonably qualified expert, as opposed to special risk controls where analysis is necessary to understand the situation and how the risk control is effective. This in turn can be derived from a resource model: if we attempted to document all standard practice the risk management process would become overbearing, even though there is a small possibility that standard practice is not enough. On the other hand, analyzing special situations has a high potential to reduce risk with only relatively small amount of resources being used.

 

[Marcelo]

Thanks for the comments Peter.

There is a second point here which relates to phrase "ISO 14971 is only worried about hazardous situations, so it´s only worried about the failures modes which are part of a sequence of events which results in a hazardous situation".

This is not correct: the term "hazardous situation" is based on the definition of "hazard" which includes the term "potential". This subject is a big issue (what hazardous situations to include in the risk management file) and there is evidence that ISO 14971 definition is flawed, but at least in a guide on ISO 14971 it should be accurate according to those definitions.

I the xample I was trying to focus on the need of exposure, but you are right, the phrase lack a "potential"

"ISO 14971 is only worried about hazardous situations, so it´s only worried about the failures modes which are part of a sequence of events which has a potential to result in a hazardous situation".

There are many situations where a failure mode (or sequence of events) is self contained, but only as the result of deliberate design decisions. Technically, these are part of ISO 14971. The flawed part is that there are virtually an infinite number of these decisions if the whole life cycle is considered.

In practice (i.e. outside of ISO 14971), the point of differentiation seems to be based on whether the risk control is standard practice, or otherwise obviously safe to a reasonably qualified expert, as opposed to special risk controls where analysis is necessary to understand the situation and how the risk control is effective. This in turn can be derived from a resource model: if we attempted to document all standard practice the risk management process would become overbearing, even though there is a small possibility that standard practice is not enough. On the other hand, analyzing special situations has a high potential to reduce risk with only relatively small amount of resources being used.

Agree with you that this is a problem of ISO 14971 - it's not clear when you can or cannot consider an already decided risk control measure. One issue is that in principle ISO 14971 was created to be used from scratch, when you have nothing - no info, no risk control measures - related to the device, so you really cannot take for granted any "standard practice". For example, even for risk control measures derived from standards you need a consideration in ISO 14971 - this is not very clear right now but will be in ISO TR 24971 and Amendment 1 of IEC 60601-1.

 

[Liz.e]

Hi,

I am trying to rewrite our risk management procedure to incorporate the 2012 changes to ISO14971. The old procedure allowed for 'no action' on a risk assessment score of 4 or below, with 5-9 falling into the ALARP region with 10 being unacceptable.

I know I need to include what we will do with a score of 4 or below now, but I cannot find anything in ISO14971 that tells me the action we shoudl take/document on an 'acceptable risk'. Can you help me?

Thanks

 

[Ronen E]

Hi,

I am trying to rewrite our risk management procedure to incorporate the 2012 changes to ISO14971. The old procedure allowed for 'no action' on a risk assessment score of 4 or below, with 5-9 falling into the ALARP region with 10 being unacceptable.

I know I need to include what we will do with a score of 4 or below now, but I cannot find anything in ISO14971 that tells me the action we shoudl take/document on an 'acceptable risk'. Can you help me?

Thanks

Hello and welcome to the Cove

The 2012 changes don't relate to ISO 14971; only to EN ISO 14971.

Strictly speaking, in this context there is no more such thing as "an acceptable risk". All risks must be brought down "As Far As Possible". If there is anything that can be done to lower the risk further, it must be done.

Outraged? You are not alone.

3. Risk reduction "as far as possible" versus "as low as reasonably practicable":
a) Annex D.8 to ISO 14971, referred to in 3.4, contains the concept of reducing risks "as low as reasonably practicable" (ALARP concept). The ALARP concept contains an element of economic consideration.
b) However, the first indent of Section 2 of Annex I to Directive 93/42/EEC and various particular Essential Requirements require risks to be reduced "as far as possible" without there being room for economic considerations.
c) Accordingly, manufacturers and Notified Bodies may not apply the ALARP concept with regard to economic considerations.

 

[sagai]

I would suggest to look into the importance of the overall (and also the individual) risk benefit analysis to cut off this gordian knot.
Cheers!