Regulatory Open Forum

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

Thank you both. These tips are helpful.

BR

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

I was about to reply but saw that Peter covered pretty much what I was going to say.... outputs of risk management are an input into Design Inputs (and Design Input Requirements if we want that distinction).

To pick up on one key point though, you do not need a design or design inputs to start the risk analysis. You can start with the high level intended purpose and go from there. The more information and detail that is known, the more specific the risk analysis can become. Without this mindset, you will always be locked into the sequential process of 'do design inputs' then 'do risk analysis' then 'go back and revisit design inputs'.

Thank you both. These tips are helpful.

BR

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

Thank you Ed. What about updates to the risk analysis made after all the design control documents are complete (for example, due to post-market information)? Do you then revisit the design inputs document and the traceability matrix and update them as well?

I was about to reply but saw that Peter covered pretty much what I was going to say.... outputs of risk management are an input into Design Inputs (and Design Input Requirements if we want that distinction).

To pick up on one key point though, you do not need a design or design inputs to start the risk analysis. You can start with the high level intended purpose and go from there. The more information and detail that is known, the more specific the risk analysis can become. Without this mindset, you will always be locked into the sequential process of 'do design inputs' then 'do risk analysis' then 'go back and revisit design inputs'.

Thank you both. These tips are helpful.

BR

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

Hi Noa,

not neccessarily. Only when those documents need to be updated (e.g. because a design input requirements is changed, or an additional risk control measure is identified and added as design input requirement and consequently needing verification and validation).

Your design change process should guide you through the design change, whatever the starting point of a design change is..

Thank you Ed. What about updates to the risk analysis made after all the design control documents are complete (for example, due to post-market information)? Do you then revisit the design inputs document and the traceability matrix and update them as well?

I was about to reply but saw that Peter covered pretty much what I was going to say.... outputs of risk management are an input into Design Inputs (and Design Input Requirements if we want that distinction).

To pick up on one key point though, you do not need a design or design inputs to start the risk analysis. You can start with the high level intended purpose and go from there. The more information and detail that is known, the more specific the risk analysis can become. Without this mindset, you will always be locked into the sequential process of 'do design inputs' then 'do risk analysis' then 'go back and revisit design inputs'.

Thank you both. These tips are helpful.

BR

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

I was about to reply but saw that Peter covered pretty much what I was going to say.... outputs of risk management are an input into Design Inputs (and Design Input Requirements if we want that distinction).

To pick up on one key point though, you do not need a design or design inputs to start the risk analysis. You can start with the high level intended purpose and go from there. The more information and detail that is known, the more specific the risk analysis can become. Without this mindset, you will always be locked into the sequential process of 'do design inputs' then 'do risk analysis' then 'go back and revisit design inputs'.

Thank you both. These tips are helpful.

BR

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

Unfortunately I have come on to this discussion late in the process.  There have been some excellent responses by Peter and Edward, but I saw one this that I may need to clarify.  

As an example I can point to the GHTF guidance on risk management which I will attach, which has an example of the traceability matrix in Annex C.  The various risk analyses described by Peter are in fact, all part of ONE risk analyses for the product.  

Certainly we do lots of different activities to create that input such as usability,  any software, cybersecurity, biocompatibility, electrical, environmental, the responses to ISO TR 24971:2020 Annex A Characteristics Related to Safety (required in ISO 14971 :2019 5.3) etc, all need to go into one traceability matrix which should start with the identified hazard, and progress through identification of the hazardous situation that exposes the hazard, the harms (multiple) that may occur as a result of he exposure, the probability of occurrence of harm and the severity of harm.  Next comes the risk rating, and then if risk controls are required, those are identified, and the verification of implementation (design verification) and the verification of effectiveness (design validation including usability validation for IFU risk controls) and finally the benefit-risk analysis if required.  This approach is based on the GHTF document.

A best practice is to identify the document that these items come from along with any item number or line item.  By following this process you are managing the history of the process for later actions, say if a complaint comes in about this issue.  I wrote about this in AAMI Horizons Spring 2015 Risk issue, if you can find it.  This approach has been used by some of my clients to satisfy NB and US FDA audits and inspections, with very good responses by the auditors/investigators on the demonstration of an effective risk management system.

I was about to reply but saw that Peter covered pretty much what I was going to say.... outputs of risk management are an input into Design Inputs (and Design Input Requirements if we want that distinction).

To pick up on one key point though, you do not need a design or design inputs to start the risk analysis. You can start with the high level intended purpose and go from there. The more information and detail that is known, the more specific the risk analysis can become. Without this mindset, you will always be locked into the sequential process of 'do design inputs' then 'do risk analysis' then 'go back and revisit design inputs'.

Thank you both. These tips are helpful.

BR

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!

I should have attached the risk traceability matrix I discussed.  Here it is along with other items to show visually the inputs to Risk Analysis.

Unfortunately I have come on to this discussion late in the process.  There have been some excellent responses by Peter and Edward, but I saw one this that I may need to clarify.  

As an example I can point to the GHTF guidance on risk management which I will attach, which has an example of the traceability matrix in Annex C.  The various risk analyses described by Peter are in fact, all part of ONE risk analyses for the product.  

Certainly we do lots of different activities to create that input such as usability,  any software, cybersecurity, biocompatibility, electrical, environmental, the responses to ISO TR 24971:2020 Annex A Characteristics Related to Safety (required in ISO 14971 :2019 5.3) etc, all need to go into one traceability matrix which should start with the identified hazard, and progress through identification of the hazardous situation that exposes the hazard, the harms (multiple) that may occur as a result of he exposure, the probability of occurrence of harm and the severity of harm.  Next comes the risk rating, and then if risk controls are required, those are identified, and the verification of implementation (design verification) and the verification of effectiveness (design validation including usability validation for IFU risk controls) and finally the benefit-risk analysis if required.  This approach is based on the GHTF document.

A best practice is to identify the document that these items come from along with any item number or line item.  By following this process you are managing the history of the process for later actions, say if a complaint comes in about this issue.  I wrote about this in AAMI Horizons Spring 2015 Risk issue, if you can find it.  This approach has been used by some of my clients to satisfy NB and US FDA audits and inspections, with very good responses by the auditors/investigators on the demonstration of an effective risk management system.

I was about to reply but saw that Peter covered pretty much what I was going to say.... outputs of risk management are an input into Design Inputs (and Design Input Requirements if we want that distinction).

To pick up on one key point though, you do not need a design or design inputs to start the risk analysis. You can start with the high level intended purpose and go from there. The more information and detail that is known, the more specific the risk analysis can become. Without this mindset, you will always be locked into the sequential process of 'do design inputs' then 'do risk analysis' then 'go back and revisit design inputs'.

Thank you both. These tips are helpful.

BR

Hi Noah,

Kimberly already gave good advice on the continuous update of risk management throughout the design and development cycle.

I would like to add that in ISO 13485, Clause 7.3. is stated that, amongst others, applicable output of risk management is input for design. Of course not all risks and control measures are known at the beginning of a design project, Kimberley described how that could work.

I advise my clients to identify risk control measures as design input requirements. All design input requirements are to be verified and/or validated, therefor risk control measures are 'automatically' verified and/or validated (requirement of ISO 14971). You can do the same with usability risk management control measures and security risk control measures. This approach also ensures that risk control measures are verifiable to start with.

We utilize a software called JAMA. https://www.jamasoftware.com/ 

I am not affiliated with JAMA. It's just a nice program. You can set directional relationships and check any missing relationships pretty easily. You'd of course need to validate the software for your use. 

Regarding risks, we had design reviews in the beginning that fed back into design inputs. As a part of risk management throughout the product lifecycle, we manage that on a quarterly basis at recurrent product surveillance review meetings.

Hello dear community,

I am looking for a smart and efficient way to maintain traceability between the risk analysis and the design control parameters throughout the lifecycle of the product.

I'll be happy to hear about any processes you have in place for updating this traceability whenever a new risk is added/modified in the risk analysis. 

Also in this regard, how do you ensure you have a design input for every risk? Design starts with design inputs, and only then a risk analysis takes place. How do you feed back any new risks as design inputs and at what stage?

Glad to hear any insights you may have on this topic.

Thanks in advance!