Thanks! You've successfully subscribed to the BONEZONE®/OMTEC® Monthly eNewsletter!

Please take a moment to tell us more about yourself and help us keep unwanted emails out of your inbox.

Choose one or more mailing lists:
BONEZONE/OMTEC Monthly eNewsletter
OMTEC Conference Updates
Advertising/Sponsorship Opportunities
Exhibiting Opportunities
* Indicates a required field.

25 Considerations for Companies Seeking Clarity in Design Controls

Since early 1984, FDA has identified lack of design controls as one of the major causes of device recalls. The intrinsic quality of devices, including their safety and effectiveness, is established during the design phase.

FDA believes that unless appropriate design controls are observed during pre-production stages of development, a finished device may be neither safe nor effective for its intended use. This has been true for almost 35 years now. With that being said, some device companies, by their admittance, still struggle with this process and seek clarity.

Forget the convoluted regulatory language for the moment and consider the basic facts.The following is a short list of considerations I have compiled over the years and share with you as key reminders while you’re working through your design controls:

  1. Implementing design controls as a separate entity within the Quality Management System (QMS) is counterproductive and not the way the architecture of 21 CFR, Part 820 was intended.

  2. Research is not development. Concept and feasibility is not included in design, per se. Research, though valuable, is not part of a documented design controls process.

  3. User needs are not design inputs. Design inputs are measurable.User needs are confirmed during design validation. Design inputs are confirmed during design verification.

  4. After design inputs are approved, they are used to verify design outputs, i.e. design verification.

  5. Risk analysis is considered a design input, not something that you do later during the process build. The extent of testing conducted should be governed by the risk(s).

  6. Design control does not end with the transfer of a design to production. It is part of the product life-cycle to the end of the device’s life (in the field).

  7. The Design History File (DHF) is the basis for the Device Master Record (DMR). The DHF and the DMR can be updated as the device’s life span continues. 

  8. Essential outputs must be recognized as early as possible to start thinking about developing a verification plan.

  9. Design controls do not just address the device (the product). They do address the process build as correlated.

  10. Not having a cross-functional design team causes problems later on in the process.  

  11. Change can bring a company to its knees (when you’re not prepared for it). Therefore, all changes must be considered.

  12. Design validation using production units or their equivalents follows successful design verification.

  13. Design transfer can happen incrementally over a period of time, i.e. not necessarily all at once.

  14. Waiting too long to audit the DHF can be an Achilles heel—“Where did we put all of the documentation?”

  15. All devices, including Class I, exempt from design controls must be properly transferred to production in order to comply with 21 CFR, Part 820.181.

  16. The design control requirements are intended for legacy products that have realized design changes since 1997.

  17. Manufacturers and specifications’ developers should put together a process flow of design as part of planning.

  18. The design plan is regularly reviewed and appropriately updated throughout the design process.

  19. Interfaces between organizational groups providing input to the design should be defined and documented.

  20. Design inputs should be appropriate so that the device will perform to meet its intended use and the needs of the user.

  21. Labeling developed for a device during the design process should be tested for usability.

  22. Procedures should include a mechanism for addressing incomplete, ambiguous or conflicting requirements.

  23. Prototypes can be made and used for clinical or other studies, but the last and final design validation cannot be done using prototypes.

  24. Software must be validated when it is a part of the finished device.

  25. Design validation follows successful design verification.


John Gagliardi has had success over the past 45+ years in the medical device and pharmaceutical industries because of his practical approach to process-orientation and business. He has been actively involved in research and development, quality assurance, training, operations, process architecture, FDA inspections and regulatory affairs. Mr. Gagliardi specializes in building systems in a compliant and business-ready manner. Mr. Gagliardi can be reached by 
email.

MidWest Process Innovation, LLC

4 COMMENTS

Security code
Refresh