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]

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"] 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.

Automate Your Traceability

Using automated traceability solutions can make risk controls much more visible. With built-in linking between the different systems that manage requirements, hazards, test cases, and other development artifacts, these solutions let you trace artifacts from any point in the development process to any other point—forward or backward. Changing requirements and design tradeoffs during the project will require your team to reassess safety risks due to hazards. When new or modified functional requirements are added, the potential for additional hazards arises. Identifying changes to hazards based on changes to requirements means performing the same analysis all over again— unless hazards are linked to existing requirements, which makes it easier to determine which hazards are affected. Test planning and requirements verification are also part of reassessing risk. Ideally, test cases and test runs can be traced back to requirements, so that successful test case execution also ensures full requirements coverage. With traceability back to the safety analysis and risks, the team can demonstrate that their test suites directly verify their risk controls. By linking risk controls with the relevant requirements and downstream artifacts, such as test cases and defects, automated traceability helps ensure that identified risks are successfully mitigated in the resulting product.

Not Just “Nice to Have”

Medical device companies can no longer think of risk controls as something that’s “nice to have.” Risk management is critical to the quality and safety of the product, and to proving compliance to auditors. With the FDA and other regulators giving more attention to risk management, your risk controls need to be highly visible and fully traceable. For more information on increasing the visibility of risk, read our white paper, Exposing Risk throughout Your Development Lifecycle. We also have a collection of videos on managing risk.