Compliance & Regulation

Five Key Design Control Practices that Improve Compliance and Help Develop Better Products

By |

Design Control

Design Controls have been an FDA Quality System Regulation since 1997. Having worked on developing products in the regulated medical device industry for over 35 years, I have compiled a list of the five key takeaways for implementing design controls and achieving success in commercializing medical devices:

  1. Design Controls not only help achieve regulatory compliance, they help develop better products
  2. Design Inputs lay the foundation for product development, building a good foundation
  3. Don’t underestimate the power of Bidirectional Traceability
  4. Know the difference between Verification and Validation
  5. Risk Management is a vital part of Design Controls

#1 – Design Controls not only help achieve regulatory compliance, they help develop better products

Many companies think that design controls are a burden to development organizations imposed by the FDA, and it’s the price to pay for playing in the medical device field. However, what is often overlooked is that design controls only define the basic minimum requirements necessary to develop a product that can…

  • …meet the needs of the user.
  • …be designed to be safe and effective.
  • …be reliably manufactured.
  • …be verified and validated.
  • …maintained and updated throughout the product lifecycle.

These are all things that any development organization should do to successfully deliver products to market. I like to say that if you are doing the right things in product development, compliance comes for free!

#2 Design Inputs lay the foundation for product development, building a good foundation

The FDA defines design inputs as the physical and performance requirements of a device

that are used as a basis for device design. To generate adequate design inputs, the foundation upon which product development is built, the user needs must first be well understood. These needs, ideally written with the voice of the user, must then be translated into design requirements. In contrast to the user needs, these design requirements should be written using the voice of the engineer, and as such should be measurable and testable. Furthermore, design requirements should be traceable to a specific user need, risk control, or standard that necessitates the existence of said design requirement.

Research has shown that, on average, companies that are successful at developing products spend about 25% of the product development time on the generation of user needs and the subsequent design requirements. The return on this investment of time and resources reduces the need for rework and redesign, and ultimately leads to higher customer satisfaction. Failing to make the investment ensures that design inputs are complete and correct is analogous to building a house on quicksand, where the flaws in the foundation can cause issues throughout the construction and subsequent (likely short) lifetime of the house. Issues with requirements will impact development, verification, validation, and user acceptance of the product, so spending the time to get requirements right will be well worth the effort.

RELATED: Three Ways to Proactively (vs Reactively) Incorporate Design Controls in Medical Device Product Development

#3 Don’t underestimate the power of Bidirectional Traceability

In an audit, the trace matrix should be valued as a friend! Having and maintaining bi-directional traceability throughout the product lifecycle provides a number of benefits:

  • Effecting project tracking
  • Thorough change impact analysis
  • Ease of making future changes
  • Re-use of elements of the design
  • More effective issue resolution

To derive these benefits, the relationship between the following entities should be established:

  1. User Needs and Design Requirements
  2. User Needs and Validation
  3. Design Requirements and lower-level requirements
  4. Design Requirements and Verification
  5. Lower-level requirements and verification
  6. Lower-level requirements and Design Outputs
  7. Risk Controls and Design Requirements

In creating a trace matrix that has views to show all the bi-directional relationships of each of the elements described above can help answer most questions from an auditor.  With this level of traceability, I can trace from a user need all the way through implementation and test.

#4 Know the difference between Verification and Validation

The terms “Verification” and “Validation” often get combined and abbreviated to V&V; however, these activities are vastly different.

Verification is confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. It is design-centric and answers the question “Did I build the product right?” Verification also entails gathering objective evidence that the design behaves as intended through the use of observation (visual inspection), measurement (values and tolerances), testing (function) or analysis (reviews).

Validation is confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled. Unlike Verification, this is a user-centric term, and answers the questions “Did I build the right product?” and “For whom is this the right product?” Validation entails gathering objective evidence that the design satisfies the user needs through the use of Usability Studies/Human Factors Studies, Clinical Evaluation/Clinical Studies, Customer Surveys, and through Analysis of Verification Data.

Knowing the difference between Verification and Validation is of quintessential importance for ensuring customer satisfaction and regulatory acceptance of the product.

#5 Risk Management is a vital part of Design Controls

The elements of design controls are Planning, Design Inputs, Design Outputs, Design Reviews, Design Verification, Design Validation, Design Changes and the Design History File. So, what happened to Risk Management? Risk is mentioned in Design Control Regulation (QSR 820.30) all of one time, under Design Validation. The statement simply reads “Design validation shall include software validation and risk analysis, where appropriate.”

Fortunately, the FDA Design Control Guidance elaborates on requirements for risk management. The guidance includes this paragraph:

Risk management begins with the development of the design input requirements. As the design evolves, new risks may become evident. To systematically identify and, when necessary, reduce these risks, the risk management process is integrated into the design

process. In this way, unacceptable risks can be identified and managed earlier in the

design process when changes are easier to make and less costly.

The takeaway from this is that although risk management is just cursively mentioned in the QSR Design Control regulation, the intent of the regulation is that Risk Management be practiced starting from the point where design inputs are known and practiced throughout the product life cycle.  You cannot be compliant to the design control regulation without having an adequate risk management file.

Conclusion:

Design Control regulations have been around since 1997, but many manufacturers still have problems complying with design controls. Focusing on the best practices outlined above will derive the most benefit from implementing Design Controls, will lead to a more predictable development cycle, and ultimately result in higher-quality products that can be enhanced and maintained throughout their lifecycle.


Mercedes Massana
Latest posts by Mercedes Massana (see all)