Challenges In Design Development—Why Design Controls Make Sense
The author describes challenges in a Design and Development Plan and how those problems can be minimized through design control compliance with FDA requirements
The time and investment needed to bring an idea for a new medical product all the way 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 is 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 an aid to help ensure consistency and thoroughness of 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.
Pre – Design Controls
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.
Product Requirements / Design Inputs
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 enables assessment of the degree to which the product will consistently meet requirements.
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 percent confidence.
Design Controls require that a set of Design Inputs be established early during product development. Design Inputs are a set of technical specifications 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 intended 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 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.
Early during 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 is part of plans for risk mitigation. Design For Six Sigma (DFSS) is frequently applied to critical design elements to ensure statistically adequate safety margin in reliably meeting requirements. Comprehensive risk analysis can be effective in avoiding those dreaded manifestations of Murphy’s Law.
Identification of potential risks early on allows the project team an opportunity to adjust the design or process, or through other means 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 are intended to be updated periodically as frequency of occurrence or severity of the hazards become better understood or new failure modes are discovered.
Risk Management is central to implementation and compliance with Design Controls. Expectations and best practices in the utilization of Risk Management have evolved significantly over the past ten 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.
Unfortunately, risk analyses are not always comprehensive and risks are not always fully mitigated.
Design and Development Planning
FDA Design Controls require that the development process occur in thoughtful, planned manner.
Poor project planning can result in a process that is ad hoc and lacking in confidence as to when milestones may be achieved. Good planning that results in realistic schedules can reduce schedule pressure on the project team, and thus mitigate a historical contributing factor to design defects that can cause patient injury.
By mandating the creation and maintenance of Design and Development Plans, FDA is forcing industry to do what it should be doing anyway. A comprehensive Design and Development Plan may include the following interdisciplinary areas:
- Prototype Development Plan
- Quality Plan
- Manufacturing Plan
- Risk Management Plan
- Regulatory Plan
- Verification and Validation Planning, including Clinical Studies where applicable
- Launch Plan
Realistic schedules need to allow for development being an iterative process, particularly when trial and error is required through prototyping to finetune critical tolerances, or in the case of software development where time to eliminate bugs in the system is normally needed. Additionally, the common use of Stage Gates and Design Reviews during development implies by their nature the possibility of a feedback loop in the development process.
“Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation.” (21 CFR820.30(b))
Design Verification and Validation
Design Verification refers to systematically testing to ensure that all the Design Inputs are met by the proposed design (See Figure 1). Verification testing needs to be sufficient to address any required mitigations identified by Risk Analysis. Correspondingly, Design Validation through clinical studies or simulated product use testing is performed to check that the user needs have been met. Design Validation is critical because Design Inputs are not always complete or accurately translated from the voice of the customer.
Design and Development Plan validation often includes project files with gaps, where not all Design Inputs were verified or use conditions validated. Another common problem is verification and validation testing is not statistically adequate. Lastly, verification and validation test planning needs should ensure the product remains functional and reliable after the intended shelf life.
Design Reviews are essential checkpoints conducted periodically to ensure that design process deliverables are being sufficiently performed. Design review meetings are intended to ensure the following:
- Design Inputs are comprehensive and measurable
- Verification and Validation Testing is thorough (all Design Inputs Verified and all User Needs Validated) and statistically sufficient
- Risks have been identified and sufficiently mitigated
- Design Development Plans are updated, sufficient and realistic
- Prior to manufacturing ramp-up (Design Transfer), specifications are finalized and manufacturing processes are properly validated.
- Regulatory clearances are received prior to clinical or commercial human use.
Design reviews provide objective independent review and management oversight that ensures that day-to-day pressures to deliver the product design quickly have not led to short cuts that could jeopardize product quality. Formal Design Reviews must be documented and identified issues must be tracked and resolved. Informal Design Reviews include activities such as review and approval of test reports or approval of engineering drawings. Informal reviews do not require independent reviews, issues tracking, etc. as required for Formal Design Reviews. Design & Development Plans should recognize that Design Reviews may lead to certain development activities needing to be iterated (See Figure 2).
Design review meetings are intended to ensure risks have been identified and sufficiently mitigated.
Design History Files
Maintaining a record of the design process is required as part of Design Controls, but it is also good business practice. Product life cycles do not end with initial launch of the product. Product or process changes typically are required at different points over the lifetime of the product. Many changes require a new look at risk analyses to identify new risks or changes in frequency of occurrence. Additionally, new tests or portions of previous verification or validation testing may need to be repeated.
Accordingly, key revision-controlled documents such as Design Inputs, Risk Analyses, and Design Outputs are updated as necessary over the lifetime of the product. The ready availability of these core documents as part of a Design History File (DHF) means that when product changes are needed, there is a repository of design information available that needs only review or modification. Re-creating such analysis and documentation to enable a minor product or process change can slow down a company’s design and development plan.
Additionally, having access to comprehensive hazards and risk analysis will allow for credible determination of actions when investigating product issues encountered by customers. If an FDA investigator responding to reports of patient harm associated with a product discovers that there is not even a process in place by which the risk of harm could have been anticipated, red flags arise. An investigator knows there could be many other potentially harmful situations that also have not be predicted. If the development and post-market surveillance processes are sound, product recalls or emergency field corrective actions may still be necessary. However, this situation would have fewer regulatory consequences due to non-compliance.
In summary, design development requires significant analysis and documentation to ensure that requirements are understood, risks are addressed and that ultimately the product launched will be safe and effective. The small investment in front end documentation can avoid embarrassing and costly program delays, save time and money, and reduce the risk to patients.
The ready availability of a Design History File means that when
product changes are needed, there is a repository of design
information available that needs only review or modification.