Home Regulatory Quality Risk Management Ergonomics Mechatronics Safety Critical Systems e-Library Contact Samaras Blog
Copyright © 2012-20 Samaras & Associates, Inc., All Rights Reserved  

Risk Management

OUR SERVICES:  We can assist you with all aspects of the risk management process for your medical device or information system.  We use proprietary checklists, templates, and analytic tools combined with extensive knowledge of medicine, physiology, and engineering (HW, SW, HF&E and Quality).  We focus on comprehensive analysis that includes expected use, unexpected use, misuse, and abuse of your medical device or information system.  We can efficiently assist you to analyze comprehensively the HW, SW, HF&E, and system (”combined”) risks to the intended user(s) in the intended use environment(s).  Your risk analysis results in proposed risk mitigations.  Once your proposed risk mitigations have been implemented, we can assist you with the two specific types of verifications (please refer to V&V Process Chart) required by the ISO14971 international consensus standard.  OUR PRINCIPALS: One of our principals is a physiologist and licensed professional engineer with extensive HW, SW, HF&E, and Quality engineering experience.  The other is a clinician with real-world experience managing risks with medical devices & healthcare information systems. The regulation of the marketing of medical devices in the US is risk-based.  Risk analysis is a central element of Design Controls, required of all medical devices Class 2 or 3 and all medical devices automated with computer software (regardless of class).  ISO14971 is the international consensus standard for risk management of medical devices and is recognized by the FDA.  The flowchart on the right describes the risk management process. Risk management is not an activity that is done "after-the-fact"; it is an integral and iterative part of the medical device development process and must begin with Design Controls at the beginning of product development.  This is not just required by Federal regulations; it’s good business practice, whose purpose is to protect stakeholder value.  Anyone who tells you that you can get it all done either at the beginning or the end of product development is not doing you a favor - especially when you invariably find out that you have to make expensive design changes and suffer regulatory delays! Risk management is an iterative process; it consists of risk identification (is there a potential source of harm?), risk assessment (do I really care?), and risk mitigation (can I adequately reduce the targeted risk?).  If you have quantitative, historical, failure-rate data, use tools such as fault tree analysis (FTA), event tree analysis (ETA) and failure modes, effects and criticality analysis FMECA).  If you're only able to give it your best guess, use tools such as root cause analysis (RCA), failure modes effects analysis (FMEA), hazard & operability studies (HAZOPS), and hazard analysis and critical control points (HACCP) analysis. The quality of an objective risk analysis is dependent on the quality and quantity of the data. The quality of a subjective risk analysis is critically  dependent on the knowledge, experience, and expertise of the analyst. It is important to note that ISO14971 does NOT prescribe or permit only a bottom-up analysis (e.g., FMEA) or only a top-down analysis (e.g., RCA).  One or the other is inadequate, is merely an incomplete analysis, and is not compliant with the standard.  Both are required to achieve the greatest coverage, especially when you are doing a subjective, experiential analysis without historical, quantitative, failure-rate data. In addition, remember that design FMEA (dFMEA) is different from the manufacturing or process FMEA (pFMEA).   The dFMEA is for estimating Consumer Risk (after your product goes out the door), while the pFMEA is  used for estimating Producer Risk (before your product goes out the door).
Samaras Risk Management Process Flowchart Samaras Iterative Risk Management Diagram Samaras Risk Analysis Tools Matrix
You never use detectability in a dFMEA.  Detectability is a risk CONTROL measure, not a component of risk.  Using detectability in a dFMEA erroneously under- estimates the real risk to the end-user - the combination of probability of occurrence and severity of harm. Once your product is in the hands of end-users, manufacturers have no knowledge or control over what each individual end-user can or cannot detect.  Even if an end-user detects a hazardous product defect, manufacturers can have no knowledge or control over whether the user will remember how to properly respond to the risk.  And, even if the user recalls the correct response, manufacturers can have no knowledge or control over whether the user will have adequate time or inclination to do so.  It's critical that the correct risk analysis procedure be used for the correct application, especially when you're dealing with the safety of medical devices. INSTRUCTIONS for USE     You may also be interested in: QMED Focus on Fundamentals 3-day Webinar on  ”How to Manage Risk Throughout Medical Device Product Development Cycle and Beyond”.  To access the recorded audio and slide decks, register here.
Home Regulatory Quality Risk Management Human Factors Mechatronics Safety Critical Systems e-Library Contact Samaras Blog dFMEA Template Risk Management Risk Management