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.

Fig.1 – Flow of Design Control

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.

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

Risk Analysis

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.

Design & Development Planning

FDA Design Controls require that the development process occur in a thoughtful, planned manner. “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)]

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 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 & Development Plans, FDA is forcing industry to do what it should be doing anyway. A comprehensive Design & Development Plan may include the following interdisciplinary areas:

  1. Prototype Development Plan
  2. Quality Plan
  3. Manufacturing Plan
  4. Risk Management Plan
  5. Regulatory Plan
  6. Verification and Validation Planning, including Clinical Studies where applicable
  7. Launch Plan

Realistic schedules need to allow for development as an iterative process, particularly when trial and error is required through prototyping to fine-tune 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 the possibility of a feedback loop in the development process.

Design Verification and Validation

Fig.2 – The Iterative Nature of Product Development and Design Reviews.

Design Verification refers to systematically testing to ensure that all the Design Inputs are met by the proposed design (see Fig. 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 customer.

Frequently, project files contain gaps, where not all Design Inputs were verified or customer use conditions validated. Another common problem is that verification and validation testing is not statistically adequate. Lastly, verification and validation test planning needs to ensure that the product remains functional and reliable after the intended shelf life.

Design Reviews

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:

  1. Design Inputs are comprehensive and measurable
  2. Verification and validation testing is thorough (all Design Inputs verified and all user needs validated) and statistically sufficient
  3. Risks have been identified and sufficiently mitigated
  4. Design Development Plans are updated, sufficient, and realistic
  5. Prior to manufacturing ramp-up (Design Transfer), specifications are finalized and manufacturing processes are properly validated.
  6. 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 do not lead to shortcuts 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 require certain development activities to be iterated (see Fig. 2).

The Importance of 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 lifecycles 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, a repository of design information is available and needs only to be reviewed or modified. Recreating such analysis and documentation to enable a minor product or process change can slow down a company’s change control process.

Additionally, having ready access to comprehensive hazards and risk analysis allows more efficient and credible determination of required 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 that there could be many other potentially harmful situations that also were not predicted. If the development and post-market surveillance processes are sound, product recalls or emergency field corrective actions may still be necessary, but the company will be less likely to face regulatory actions due to noncompliance concerns.


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 additional front-end documentation can avoid embarrassing and costly program delays, save time and money in the long run, and reduce the risk of harm to patients.

This article was written by Larry Servi, Director of Product and Process Development for Regulatory Compliance Associates, Inc. in Kenosha, WI. Contact Larry at This email address is being protected from spambots. You need JavaScript enabled to view it. or visit .