November 4, 2015
Improving the Visibility of Risk Controls
Since 2011, we’ve asked respondents to the State of Medical Device Development Survey, “What are the top three pieces of information you wish you had better visibility into during the design control phase?”
Respondents have consistently identified risk controls as one of the top three, often putting it at the very top of the list. It would seem that poor visibility into risk is a persistent problem in the industry, so how can companies improve the visibility of risk controls?
[caption id="attachment_17863" align="aligncenter" width="650"]
Source: 2015 State of Medical Device Development Report (click to enlarge)[/caption]
Source: 2015 State of Medical Device Development Report (click to enlarge)[/caption]
Gaining visibility into a document or spreadsheet is challenging, to say the least. Assuming the “latest copy” is easily accessible (and how often is that true?), actually understanding what’s in the document requires digging into the contents to find the relevant information.
To improve risk visibility, you need to link individual risk control artifacts to the relevant requirements and downstream artifacts. It is much easier to trace an individual risk artifact, review progress, and investigate related tasks and work items when development artifacts are linked.
However, manually linking risk controls to product requirements and downstream artifacts is a detailed, tedious, and error-prone process. It’s also a maintenance nightmare, because requirements and corresponding risks change in response to market needs and design tradeoffs over the course of the project. Coming up with unique identifiers for requirements is also a hassle, and another way errors can slip in.
Automated solutions can eliminate the tedium and decrease the chances for error, with the bonuses of providing an audit trail and building the traceability matrix for you.
Email sign up
Not “Just a Compliance Check Box”
Historically, many medical device companies have viewed risk controls as something they had to do to appease auditors, and nothing more. As one participant at a recent AAMI/FDA Summit put it, “We’re doing risk management to check a box, file it away, and never look at it.” Now, however, companies are starting to realize that risk management needs to begin early in the research phase and continue across the entire development and testing process. Not only is it better from a compliance standpoint, but it also results in defects being found much earlier, when they can be fixed for far less expense than if they’re found late in the process. A $500,000 fix found at the end of the development process may only cost a few thousand dollars to fix if caught earlier. The first step to gaining more visibility into risk, then, is to recognize that risk controls are a “must have” component of the development process, and not just a “nice to have” feature completed simply to fill in a check box.FDA Guidance
The FDA has recently started paying closer attention to risk controls. While this may be a fairly new practice, what’s not new are the FDA’s guidelines on risk controls; some of them date back to 1997. Here’s a good explanation and example from the FDA’s Design Control Guidance For Medical Device Manufacturers (we italicized key points):RISK MANAGEMENT AND DESIGN CONTROLS. Risk management is the systematic application of management policies, procedures, and practices to the tasks of identifying, analyzing, controlling, and monitoring risk. It is intended to be a framework within which experience, insight, and judgment are applied to successfully manage risk. It is included in this guidance because of its effect on the design process. Risk management begins with the development of the design input requirements. As the design evolves, new risks may become evident. To systematically identify and, when necessary, reduce these risks, the risk management process is integrated into the design process. In this way, unacceptable risks can be identified and managed earlier in the design process when changes are easier to make and less costly. An example of this is an exposure control system for a general purpose x-ray system. The control function was allocated to software. Late in the development process, risk analysis of the system uncovered several failure modes that could result in overexposure to the patient. Because the problem was not identified until the design was near completion, an expensive, independent, back-up timer had to be added to monitor exposure times.The FDA also offers explicit recommendations for premarket approval that state that companies should “provide traceability to link together design, implementation, testing, and risk management.” They also recommend including a traceability matrix to help guide the auditor. The FDA’s recommendations for software validation call for “an integration of software life cycle management and risk management activities,” and there’s even a Design Controls Decision Flowchart from the FDA, which includes the following recommendation (again, we italicized key points):
While the requirement for the conduct of risk analysis appears in Section 820.30(g) Design Validation, a firm should not wait until they are performing design validation to begin risk analysis. Risk analysis should be addressed in the design plan and risk should be considered throughout the design process. Risk analysis must be completed in de-sign validation.These are all good guidelines for controlling risk, and becoming familiar with them is another good step in raising the visibility of your risk controls.
Move Away from Documents
The next step is to move away from document-centric processes. This is another part of the development process we’ve been tracking in the State of Medical Device Development Survey, and while the industry as a whole is moving away from documents, it is doing so at a glacial pace. [caption id="attachment_17870" align="aligncenter" width="650"]