The time and investment needed to bring an idea for a new medical product successfully to commercial realization can be daunting. In developing new drugs, the costs and timing required to conduct multiple stages of clinical studies, even under the best of circumstances, can be a “non-starter” if the projected long-term revenue and profit potential are not sufficient to justify the cost and risk associated with development. Similarly, the development of software-driven instrumentation products is complex in the extent of interactions among components and the number of areas where a seemingly small problem with one mechanical component, or a mistake in one line of software coding, can lead to catastrophic product system failure. Even the development of “simple” single-use medical devices can involve years of development and millions of dollars in capital investment.It’s no wonder that with product development scenarios frequently involving such large investments in time and resources, product development teams can be under intense pressure to avoid manifestations of Murphy’s Law: “If anything can go wrong, it will.” What is not always fully appreciated is that regulations put in place by the United States Food & Drug Administration (FDA) with regard to medical product development are helpful to ensure consistency and thoroughness in the development process. In 1990, the Safe Medical Device Act (SMDA, Public Law No. 101-629) was approved as an amendment to the federal Food, Drug, and Cosmetic Act. The SMDA included a set of regulations called Design Controls to better regulate the design process for Medical Devices (21CFR, Part 820.30). These regulations are legally applicable only to certain classes of medical device and diagnostic products, yet the principles behind Design Controls are logical and can be applied to any type of medical product development.
Early phase development that includes exploratory R&D, development of concept models, and early feasibility testing is not governed by Design Controls. Design Controls begin after an initial product concept has been determined and Design Inputs are formally documented, prior to formal Design Verification and Validation testing.
Frequently, the requirements of the customer are not well understood. It is not enough to say the product being designed must be able to jump — there must be an understanding of how high the product must be able to jump from the customer perspective (known as the “Voice of the Customer”). Then, the engineer or scientist must translate that voice of the customer into specifications with quantifiable design boundaries that enable measurement of development progress, and ultimately be able to assess the degree to which the product will consistently meet the requirement. In the example above, one might determine the initial design input to be: “Under x and y conditions, the product must be able to jump vertically 2.3±0.2 meters with at least 95% confidence.”
Design Controls require that a set of Design Inputs be established early in the product development process. Design Inputs are a set of technical specifications with quantifiable design boundaries that represent a translation of the customer requirements into measurable engineering terms. As a design evolves and test methods and acceptance criteria are better determined, the Design Inputs document is supposed to be updated and treated as a formal revision-controlled document. Frequently, Design Inputs are incomplete, unclear, or not measurable. Without adequate Design Inputs, the risk of completing qualification all the way through clinical studies only to find problems during expensive clinical studies is increased. The product might even work sufficiently to get approved, only to find “surprises” following commercialization.
During the early stages of development, risk analysis that identifies and evaluates the risk associated with various potential product failure modes should be conducted. Failure Mode Effects Analyses can help determine potential sources of failure and potential patient hazards due to Customer Use/Misuse (UFMEA), Design (DFMEA) or Process (PFMEA). For complex product systems, Fault Tree Analysis can be an effective alternative for risk analysis.
Risk analyses are done prior to final qualification testing since verification and validation testing frequently are part of risk mitigation. Design For Six Sigma (DFSS) is frequently applied to critical design elements to ensure a statistically adequate safety margin in reliably meeting requirements.
Comprehensive risk analysis can be effective in avoiding those dreaded manifestations of Murphy’s Law. Early identification of potential risks allows the project team an opportunity to adjust the design or process, or to mitigate the likelihood of occurrence or potential severity of the hazard. This reduces the possibility of a last-minute major program setback.
Unfortunately, risk analyses are not always comprehensive and risks are not always fully mitigated. This can ultimately lead to recalls of commercialized products, or expensive product re-engineering programs. Management may then ask, “How could this happen?” or “Why did we not anticipate this failure in advance?” Risk analysis done merely as a paperwork exercise to meet a company SOP may not capture the real issues — known as “Garbage In, Garbage Out.” Risk analysis needs to tap appropriate expertise regarding medical use, product design, and manufacturing. Even with the most rigorous of efforts to develop risk analysis, there are legitimate unknowns regarding frequency of occurrence of certain failures when estimated early during product development. This is why risk analysis documents must be updated periodically as frequency of occurrence or severity of the hazard become better understood or new failure modes are discovered.
Risk Management is central to implementation of and compliance with Design Controls. Expectations and best practices in the utilization of Risk Management have evolved significantly over the past 10 years. Since many medical products were developed prior to adoption of expanded risk management methodologies, supporting technical files sometimes lack comprehensive risk analysis. Hence, many companies have remediation programs in place to address the need for supporting risk analysis.