Product Risk Assessment Basics: Continually Collect Data, Update Documentation Often

Q: I’ve been assigned to do a product risk assessment on a new device we’re developing. My background is not in risk management, so any advice you can offer would be very much appreciated.

I’m especially concerned about how often we should update our product risk assessment and its documentation, both during the design process and once the product is on the market.

A: First of all, you need to understand that FDA’s primary focus is and always will be the risk to the patient or product user.

So start your risk assessment focusing on the product’s potential risks to the end-user. Then work back to assess risks to the product introduced by your design and manufacturing processes.

Also, look at the risks associated with your overall Quality System (things like procurement, change control, and maintenance to name just a few). As much as you can, trace all these risks back to the ultimate user of your product.

The more data you collect, the better. Risk management is an iterative process. Especially for a new product, have your testing and operational data flow back to you continually, and use the information to update your design and your original risk documents.

Over time, you’ll understand more about frequency of occurrence and severity, and you’ll understand more about the product’s failure modes.

With a multi-disciplinary team, you’ll have different skill sets and a variety of knowledge points to draw from.

I strongly recommend a team approach to risk assessment. With a multi-disciplinary team, you’ll have different skill sets and a variety of knowledge points to draw from — allowing you to share ideas and perspectives and, in the long run, better match your product risk assessment to reality.

Obviously, your risk management process has to be documented, and it has to be verified to be shown to be effective.

Change is one of the biggest reasons to have good, updated risk documentation. When you make a change to the product or the process, you’ll want to go back to those original risk documents and ask yourself, does this change introduce a new failure mode or hazard? Does it add a new mitigation? Does it change, modify or remove an existing mitigation?

In my opinion, you should review your risk documents with every design change and with the receipt of any new data — then update as needed.

I’ve had people ask if they can just update their risk documents every six months or so, instead of doing it with every change. My answer is that every time you make a change, you need to have the most current data at your fingertips to assess that change.

It doesn’t do anybody any good to work with old risk assessments. You need the most current thinking — what the latest data is telling you about risk — to make informed decisions.

In the end, your risk assessment is an exercise in probability. It’s not exact. But to make it as useful as possible, you should plan to continually collect data, carefully review and learn from that data, and then diligently update your risk decisions and documentation as needed.

Answered by Denise Dion, Vice President of Regulatory and Quality Services for EduQuest, who served 18 years at the U.S. FDA as an expert field investigator and who was co-editor of FDA’s Investigations Operations Manual, which is updated annually as a resource for FDA’s own investigators. Denise is the lead instructor for EduQuest’s training class on Design Control for Medical Devices: Meeting FDA’s 21 CFR 820.30 Rules for Quality Design and Manufacturing.


2 comments for “Product Risk Assessment Basics: Continually Collect Data, Update Documentation Often

  1. Nigel Miller
    August 16, 2017 at 3:56 am

    Writing a RA can be daunting, but is made easier by building it piecemeal using a range of techniques. FMEAs (Use, Design, and Process), FTA, etc., should all be used to focus on different types of ‘what can go wrong’ questions, making sure that the right blend of skills are available in different teams addressing each exercise. It’s very tempting to have the same team of internal ‘experts’ involved in these exercises, but that’s how things get missed. There needs to be team continuity, but with different functional representatives leading different activities; the output from each then serves as an input to the overall RA. Another really important input is Human Factors (Usability) work, especially as part of the UFMEA. It is vital that the user workflow is properly understood (techniques such as Hierarchical Task Analysis are useful here), combined with Perception-Cognition-Action analysis that addresses what users sense and think and that lead to how devices are actually used. These data feed back into the DFMEA and the iterative design process generally, helping to ‘design out’ potential failure modes and, therefore, risks. This also emphasises the importance of keeping the whole suite of risk management processes live and in line with the product development as it proceeds. It’s ALL part of Design Control. The trick is to look outside the ‘Risk Assessment’ per se and utilise the range of other techniques that are inputs to it, build it in parts, keep it live – and, above all, keep in mind that it helps us develop truly user-centred designs that are safe and effective.

  2. Nigel Miller
    September 13, 2017 at 4:36 am

    I’d like to emphasise again the importance of Human Factors (Usability) work as integral to preparing the RA. It’s important to remember that whilst the commonly used FMEA tools as an input to the RA allow us to think about failure modes, we are also required to consider risks during normal use not associated with ‘failure’. FMEAs are not Risk Assessments, only an input to RAs. The overall risk profile can only be gained by considering both fault conditions and normal use; normal use is the combined set of circumstances of correct use and use error. Human Factors work allows us to explore the aspects of the design that promote correct use, and understand the causes of use errors (whilst users interact with each and every aspect of the user interface associated with normal use).
    Risk Analysis without HF work only ever allows us to document the risks we predict, but doing HF work allows us to find and remediate those associated with use error that we didn’t predict. This gives us a much more balanced understanding of risk because it collects both the anticipated AND the unanticipated risks. This is important – it is this deeper understanding of risk that should feed into our Risk-Benefit Analysis (RBA) as residual risk. RBAs feed into decisions about the state of completeness of a new product development and whether it is ready for launch. If we base our RBA only on anticipated risk (which is all we can ever do in the absence of HF work) than we are not considering the full picture and will never know the true residual risk. As it says in IEC62366 Part 2 (the guidance document for the normative standard that is Part1), “The susequent overall evaluation of resdidual risk, which is required according to IEC62366-1:2015, 5.9 and ISO14971:2007, is only possible when considering the entire set of risks associated with the medical device. These include risks caused by medical device failures as well as those caused by use error.”

Leave a Reply

Your email address will not be published. Required fields are marked *