FDA’s Design Controls regulation can be an open book but sometimes hard to read. Interpretations of the various regulatory requirements contained within 21 CFR 820.30 can vary both between and within life science organizations. The challenge becomes interpreting the requirements and implementing them into your development processes in such a way that does not negatively impact product quality or your larger quality system.
We’ve heard a lot about the open-ended nature of Design Controls regulation, and we can relate; many requirements of 21 CFR 820.30 can be difficult to approach as a result. The issues span across the board, but there are six common misunderstandings we think are worth addressing when it comes to interpreting FDA’s Design Controls.
1. Your design history file isn’t your full device record
In compiling your design history file (DHF) for regulatory submission, it’s a common mistake to treat it as a repository for all your product files. In reality, FDA makes a distinction between your product’s master record and its DHF. According to 21 CFR 820.30(j), the DHF contains or references only those records necessary to demonstrate that the product design was made according to the:
- Approved design plan
- Requirements of 21 CFR 820.30
2. Design Controls do include risk analysis
Although FDA does not require specific risk management activities, some organizations incorrectly believe risk analysis is not an explicit requirement for life science product development. However, in the requirements for design validation, FDA states that “design validation shall include software validation and risk analysis, where appropriate.” It falls under the umbrella of validation and must therefore be treated accordingly.
3. Design & development plans can be flexible
Playing on the conservative side when it comes to building and managing design & development plans for your life science product is not an unreasonable approach. However, fear of rejection or other issues that could delay regulatory submission can cause teams to become too rigidly stuck to those plans. FDA’s Design Controls regulation allows for flexibility in these plans, however, and that should be leveraged when appropriate.
4. The Design Controls process isn’t linear
Design & development plans are the first steps to the larger progression of the Design Controls process, but by no means does everything else happen in a linear fashion. Risk analysis done during design validation, for example, could force new rounds of design input development or trigger design reviews. Likewise, a design change can cause a shift in design transfer procedures and vice versa. All of the interplay between each part of the design controls process does not happen in sequential order.
5. You should be working through Design Controls more than once
Aside from design controls not happening sequentially, they don’t happen just once, either. Throughout the product development process, your teams need to come back into your design control stages to build on existing data, add new pieces of information, test new components/systems/subsystems, and so on. Doing your best to control the amount of time invested into different quality processes is necessary for ensuring time to market, but a single round of design controls can be more harmful than beneficial over time.
6. Design Controls are not just a compliance activity
Putting a checkmark in your files that says your Design Controls activities are complete and aligned to regulatory expectations might be good enough for some organizations. However, doing so misses a big point: working through the design control process is not just about compliance. In actuality, design control is necessary to ensuring product quality. It may only be one part of your quality management efforts, but it’s essential to assuring regulators of your product’s safety and effectiveness.
