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.

« Start Prev 1 2 3 Next End»

The U.S. Government does not endorse any commercial product, process, or activity identified on this web site.