Regulatory Open Forum

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Spyros,

I appreciate your comments. My position is based on a number of points. 

The risk management standard ISO 14971:2019 is a worldwide standard. The EN version is currently identical to the ISO edition.  EN ISO 14971:2019 has been identified publicly as "state of the art" by BSI, a leading Notified Body in the EU. CEN has withdrawn EN ISO 14971:2012.  Between the MDR and EN ISO 14971:2019, a number of problems with the CEN 2012 Edition have been addressed. There is no harmonization process for MDR for standards, so harmonization cannot be accomplished in the EU. 

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Spyros,

You said, "As informed by the European Commission, after many conversations, state-of-the-art standard, (until now, we do not know what will happen with MDR), means the harmonized standard".

Can you tell us where the European Commission informed us of this decision?

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Spyros,

You said, "As informed by the European Commission, after many conversations, state-of-the-art standard, (until now, we do not know what will happen with MDR), means the harmonized standard".

Can you tell us where the European Commission informed us of this decision?

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.

Spyros,

You said, "As informed by the European Commission, after many conversations, state-of-the-art standard, (until now, we do not know what will happen with MDR), means the harmonized standard".

Can you tell us where the European Commission informed us of this decision?

Medical Device Risk Management

A number of questions about risk management and ISO 14971 have popped up here.  I wish to form a response from an informed point of view from a long history on the subject.  You can read the attached Background file to understand my perspective on this important topic.  This is a lengthy document, and i have attempted to address many questions that have arisen here.

Introduction

Risk management does not need to be an overly complex process.  I find that companies with complex processes are trying to check the box, but do not have focus on improving product safety.  They often show their FMEA when asked to demonstrate compliance with regulations and standards. Usually, those companies are not promoting product safety, only checking the

box.

First of all, remember the audience for your risk management files.  It is not just the engineers or the auditors or the FDA inspectors or even the reviewers of product submissions.  It is not top management or the internal medical clinical team members, but includes the product liability lawyers, both the plaintiff and the defendant lawyers.  Your documents need to be written to pass scrutiny of all the audience reading the documents, and giving them a true and accurate picture of what you have done to create a safe and effective product.

Policy

As described in ISO 14971:2019 Clause 4.2 Management responsibilities, Top management shall define and document a policy for establishing criteria for risk acceptability.  This is the beginning of the risk management process, defining what is acceptable to management.  Some companies are willing to accept more risk than others.  Those that only manufacture Class I devices may not be willing to accept higher risk devices, while those that manufacture Class III devices are willing to accept higher risk.  Remember, the numbered sections or clauses of the standard are requirements.  All sections identified by alpha characters in the standard are guidance and not requirements.  And everyone responsible for implementation should read Annex A of the standard , the rationale or reason for each requirement.

Your policy should be appropriate to the device(s) you intend to cover by this policy.  It is important to understand that a risk matrix is not a risk policy! The scope section of the policy determines applicability of the policy.  You could have sections for Class I and different sections for Class III for example.  And there are a number of examples scattered through this annex. 

The Guidance-ISO TR 24971:2020

Here I should bring up the upcoming 100-page guidance document ISO TR 24971:2020, which give lots of information in Annex C in the policy, criteria, risk control and risk evaluation.  Unfortunately, a communications problem with ISO and CEN has delayed release of this document far beyond what we, in the technical committee, expected.  Currently you can obtain a  final draft copy from AAMI's publications group for purchase at: https://my.aami.org/store/SearchResults.aspx?searchterm=24971&searchoption=ALL

The final publication will be released to you at no charge if you purchase the draft.

Risk Levels and Charts

Risk Charts are the most often tool in medical device risk management to define risk acceptability. Levels of Severity can be best defined by using terminology found in vigilance systems such as FDA's Medical Device Reporting system.  Terms such as "death", "serious injury requiring medical intervention", and "injury not requiring medical intervention" or other such terms used by the personnel responsible for the reporting can be helpful in connecting risk management system and the complaint / recall investigation teams.  They are easy to define and document as well, and are most often included in complaint reports. 

However, I have found that companies often use the term "catastrophic" as the highest level of severity. That term originated with the chemical, aeronautical, and nuclear industry in which a single event results in multiple casualties, truly "catastrophic".  In the medical device industry, events usually result in single casualties and the use of the term "catastrophic" for the highest level of severity is not appropriate.  In product liability cases that go to trial, the term blown up to present to a jury on a large screen can be inflammatory and result in increased awards in cases.  It is not a good practice to use inflammatory  terms. 

In practice the levels of severity and probability should not be more than 5, and could be as few as 3.  Any more and you spend more time arguing in which box something should be placed than in resolving the issue with risk controls.  I have also seen teams placing an individual risk in a different box because of schedule or cost pressures on the team and on management because of bonus or other situations.  That is a dangerous practice and appeared to be the case in a recent aviation incident.   I have also witnessed this in the medical device industry. 

It is incorrect to identify a region in the Risk Management Chart as "ALARP" or As Low As Reasonably Practicable,  or any other such term.  In the end, there are two regions, Acceptable and Unacceptable, risk is one or the other.  It is possible to have a mid-region which identifies those risks that may be "Higher than Desirable" or  "Investigate for Further Risk Reduction".  Those mid-region risks are those that should be candidates, in the absence of unacceptable risks, for additional risk control activities for risk reduction to reduce the overall risk profile of the product.

Definitions

As identified in a number of places, there are new definitions in the standard such as benefit which although discussed by the regulators is undefined by them.  So, when you are doing benefit-risk analysis, you can find this definition and the extensive discussion in Clause 7.4 Benefit-risk analysis.  This activity has a definition relationship to the policy discussed above.

Another key term is state of the art as ISO 14971:2019 is the "state of the art" risk management standard and CEN has indicated that EN ISO 14971:2012 has been withdrawn in favor of the EN ISO 14971:2019 standard.  BSI has identified the 2019 edition is defined as "state of the art" standard in risk management for medical devices.

ISO 13485:2016 and Risk Management

It has been pointed out that ISO 13485:2016 does not call out ISO 14971 as a "Normative reference", and therefore it is not required.  However, after a long running heated discussion (since before 2003) between the two standards committees, the quality management standard only refers to ISO 14971 in its definitions pertaining to risk management and in a Note at the end of Clause 7.1 Planning for product realization where it says you can find more information in ISO 14971 (for risk management in product realization). 

The quality management technical committee wanted to expand risk to include regulatory risk, but not business risks, which are not part of the quality system.  Business risks are part of the financial processes and should be covered there, and ISO 31000 covers that area. The technical committee was walking a fine line here to get more than the risks to safety covered in ISO 14971, but not the financial risks covered in ISO 31000.  Regulatory risks fall in between the two standards, but are important to medical device quality management, so they took an approach that satisfies no one by not invoking ISO 31000 either. ISO 14971 clearly states in  Clause 1 Scope that it does not apply to business risks.

It is important that the medical device manufacturer not attempt to mix the two risks in a single system as the financial risks may overwhelm the safety risks in their importance and reduce the influence of safety in product risk management.  Again, product safety is a part of quality management, where business risk is a part of financial management.  It is the responsibility of top management to resolve issues between the two systems and if they are not brought to the top, then top management may never know there are conflicts between the two and never get the chance to step in a resolve them.

Other Standards

If you are creating  an electro-medical device, then you have to follow the IEC 60601-1 family of standards.  IEC 60601-1 does require the use of ISO 14971, as do a number of other standards including IEC 62366-1:2015, the Usability Engineering standard (referred to in FDA parlance as human factors" though there is some difference to the practitioners of this science).  Even ISO 14155 on clinical trials calls ISO 14971 out as a Normative Reference. Though it is not called out by ISO 13485:2016, you can't escape that easily, ISO 14971:2019 is the "state of the art" medical device risk management standard.

Risk Management Plan

ISO 14971 in Figure 1 has emphasized the importance of planning.  Formerly, the diagram did not include planning as a part of the risk management process.  Now the technical committee has emphasized that planning is an important activity in risk management.  An often-used quote is "failing to plan is planning to fail".  The Risk Management Plan must cover all phases of the product lifecycle, and must be updated when changes occur.  So and auditor finding the only plan document in the Risk Management File that is identified as "original" might have questions as to the state of the risk management process and the accuracy of the plan document.

Risk Management File

One often overlooked requirement in Clause 4.5 Risk management file, is the very first paragraph, second sentence in this requirement, risk traceability.  It has been a requirement since the first edition was released in 2000, yet is usually not  well, if at all, implemented.  The requirement even had an example in the GHTF SG3/N15:2005 Implementation of risk management principles and activities within a Quality Management System, in Annex C of that document.  The example was a good start but could be improved, and I co-authored an article about it in AAMI's Horizons publication in Spring 2015, entitled Documenting Risk Management through the Risk Traceability Summary.  The article illustrates an Excel spreadsheet implementation of the RTS, the most important part is, in my thoughts, the identification of the various document numbers and line item numbers of all the documents used in the risk management activities for a particular product.  It serves as a knowledge management tool connecting all the dots and preserving the knowledge of everyone associated with the risk management of the product over its life.  ISO TR 24971:2020 has a discussion of the requirement in a paragraph in Clause 4.5 Risk management file. 

The RTS has been successfully presented to auditors and investigators as evidence of risk management processes implemented for a particular product.  In fact, comments have been very positive about the system implemented. 

Clause 4 General requirements for risk management system of the risk management standard also introduced, in the 2019 edition, the concept of a risk management system.   The system consists of  clauses 4.1-4.5 or all of the parts of Clause 4 in the requirements of the standard from Management responsibilities through the Risk management file.

Risk Analysis

If we look at Clause 5 Risk Analysis,  we will find an extensive discussion over two pages in ISO 14971, and 9 pages in ISO TR 24971:2020.  A key statement in Clause 5.4 Identification of hazards and hazardous situations is in the first paragraph,

" The manufacturer shall identify and document known and foreseeable hazards associated with the medical device based on the intended use, reasonably foreseeable misuse and the characteristics related to safety in both normal and fault conditions."

The key here is "known and foreseeable hazards"…"in both normal and fault conditions". 

Note it does not say "single fault hazards", and it does say "both normal and fault conditions".  FMEA fails to meet both of these requirements.  It is a single fault tool, not identifying hazardous situations caused by multiple faults occurring.  It only identifies hazards caused by faults, and not hazards caused by normal conditions, when everything is working right. Normal condition most often is covered by the IEC 62366-1 Usability Engineering standard.  One other problem is compliance with ISO 13485:2016 Clause 7.3.3c) Design and development inputs.  The requirement here is that design inputs "shall include applicable outputs of risk management;".  Now we know that the device design must be at a stage where at least some of the design outputs must be at least drafted before we can do an FMEA.  This requires design inputs to be at some stage of completion.  But if the outputs of risk management must occur to get design inputs, we are in a quandary.  Using FMEA as your only risk management activity means you are not in compliance with ISO 13485:2016.

ISO TR 24971:2020 has an extremely valuable Annex E Role of international standards in risk management, which tells the manufacturer how to use safety standards in risk management.  Here we can use the hazards already identified in an international product safety or process safety standard and the risk controls identified in the standard without any further risk analysis if you follow the guidance in Annex E.  You can do that as design inputs, thus following the ISO 13485 requirement for outputs from risk management as design inputs.  This may greatly reduce the work load on the team performing the risk analysis.  Since standards are generally acknowledged to be "state of the art" you can have some assurance that you are using current practice in your product.  You still need to check to see that the standard is still current, however. 

Other Annexes

The IVD annex, Annex H,  has been updated and extensively revised by ISO TC 212, the IVD standards committee.  This section may have some good background for other device manufacturers as well.  It is recommended reading for all.  

New topics include Annex F Guidance on risks related to [cyber]security, and Annex G Components and devices designed without using ISO 14971.  Annex G provides guidance on remediation of Risk Management Files, and has some useful guidance that may be helpful in upgrading to the new ISO 14971:2019 from earlier editions.