Why Design Control Makes 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 FDA approval 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 design control is complex in the extent of interactions among components and the number of areas where a seemingly small problem 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 design control medical device scenarios frequently involving such large investments in time and resources, product development teams can be under intense pressure. 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.
21 CFR 820
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 design control regulations 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.
Design Control Process
Early phase development that includes exploratory R&D, development of concept models and early feasibility testing is not governed by Design Controls. The design control process begins 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 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 control requires 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.
Design Control Plan
Early during development, risk analysis that identifies and evaluates the potential failure should be conducted as part of a successful design control plan. 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.
Design Control Requirements
The identification of risks early on allows the project team to adjust the design control requirements or process, or through other means mitigate the likelihood of occurrence 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?”
Standard Operating Procedures (SOP)
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))
FDA Waterfall Model
Many organizations have added commentary on the FDA’s Waterfall Model. At RCA® Inc., we believe Design Verification refers to systematically testing to ensure that design control 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. A common design control process 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
- Design control process 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 product design control 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 File (DHF)
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 product lifecycle. 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.
Design Control Documents
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.
Regulatory Compliance Associates® (RCA) provides worldwide services to the following industries for resolution of compliance and regulatory challenges:
We understand the complexities of running a life science business and possess areas of expertise that include every facet of R&D, operations, regulatory affairs, quality, and manufacturing. We are used to working on the front lines and thriving in the scrutiny of FDA-and globally-regulated companies.
As your partners, we can negotiate the potential minefield of regulatory compliance and regulatory due diligence with insight, hindsight, and the clear advantage of our unique expertise and experience.
- Founded in 2000
- Headquartered in Wisconsin (USA)
- Expertise backed by over 500 industry subject matter experts
- Acquired by Sotera Health in 2021
To begin the RCA® scoping process today, please enter your information in the blue form below and click the submit button at the bottom of the webpage.