Implementing Design Controls – 10 Steps
The article explains ten steps of implementing design controls, including design plans, design inputs, design review, verification protocols, and risk management.
FDA Guidance for Implementing Design Controls
The diagram above is called the “Application of Design Controls to Waterfall Design Process.” The FDA introduced this diagram in 1997 in the design controls guidance document. However, the original source of the diagram was Health Canada.
This diagram is one of the first slides I use for every design control course that I teach because the diagram visually displays the design controls process. The design controls process, defined by Health Canada and the US FDA, is equivalent to the design and development section found in ISO 13485 and ISO 9001 (i.e., – Clause 7.3). Seven sub-clauses comprise the requirements of these ISO Standards:
- 7.3.1 – Design Planning
- 7.3.2 – Design Inputs
- 7.3.3 – Design Outputs
- 7.3.4 – Design Reviews
- 7.3.5 – Design Verification
- 7.3.6 – Design Validation
- 7.3.7 – Design Changes
In addition to the seven sub-clauses found in these ISO Standards, the FDA Quality System Regulation (QSR) also includes additional requirements in the following sub-sections of 21 CFR 820.30: a) general, h) design transfer, and J) Design History File (DHF).
Implementing Design Controls: A Complex Process
Even though the requirement for Design Controls has been in place for 16 years, there are still far too many design teams that struggle with understanding these requirements. Medical device regulations are complex, but design controls are the most complex process in any quality system. The reason for this is that each of the seven sub-clauses represents a mini-process that is equivalent in complexity to CAPA root cause analysis. Many companies choose to create separate work instructions for each sub-clause.
Medical Device Academy’s training philosophy is to distill processes down to discrete steps that can be absorbed and implemented quickly. We use independent forms to support each step, and develop training courses with practical examples, instead of writing a detailed procedure(s). The approach we teach removes complexity from your design control procedure. Instead, we rely upon the structure of step-by-step forms completed at each stage of the design process.
10 Ways for Implementing Design Controls
1. Design plans are just a plan. You can and should change that plan. This is stated in both Clause 7.3.1 of the ISO Standards, and Section 21 CFR 820.30b of the FDA QSR. You can make your plan as detailed as you need to, but I recommend starting simple and adding detail. Your first version of a design plan should include the following tasks:
- Identification of the regulatory pathway-based upon the device risk classification and applicable harmonized standards.
- Development of a risk management plan
- Approval of your design plan (1st design review)
- Initial hazard identification
- Documentation and approval of design inputs (2nd design review)
- Risk control option analysis
- Reiterative development of the product design
- Risk analysis
- Documentation and approval of design outputs (3rd design review)
- Design verification and validation and risk control verification
- Clinical evaluation and risk/benefit analysis
- Development of post-market surveillance plan with a post-market risk management plan
- Development of a draft Device Master Record(DMR) /TF Index
- Commercial release (4th and final design review)
- Regulatory approval and closure of the Design History File (DHF
- Review lessons learned and initiate actions to improve the design process
2. Design inputs need to be requirements verified through the use of a verification protocol. If you identify external standards for each design input, you will have an easier time completing the verification activities, because verification tests will be easier to identify. Medical Device Academy has written more on this topic in a previous blog posting.
3. Design outputs are drawings and specifications. Ensure you keep them updated and control the changes. When you finally approve the design, this is the “design freeze.”
4. Design reviews should have defined deliverables. I recommend designing a form for documenting the design review, which identifies the deliverables for each design review. The form should also define the minimum required attendees by function. Other design review attendees should be identified as optional—rather than required reviewers and approvers. If your design review process requires too many people, this will have a long-term impact upon review and approval of design changes.
5. Design verification protocols should be standardized instead of being project-specific. Information regarding traceability to lots of calibrated equipment ID and test methods should be included as a variable that is entered manually into a blank space when the protocol is executed. The philosophy behind this approach is to create a protocol once and repeat it forever. This results in a verification process that is consistent and predictable, but it also eliminates the need for review and approval of the protocol for each new project.
6. Design validation should be more than bench testing. Ensure that animal models, simulated anatomical models, finite element analysis, and human clinical studies are considered.
7. Design transfer is not a single event in time. Transfer begins with the release of your first drawing or specification to purchasing and ends with the commercial release of the product.
8. Do not keep the DHF open after commercial release. All changes after that point should be under production controls, and changes should be documented in the (DMR)/Technical File (TF).
9. Your DMR Index should perform a dual function of also meeting technical documentation requirements for other counties, such as Canada and Europe.
10. Audit your design control process to identify opportunities for improvement and preventive actions. Audits should include a review of the design process metrics, and you may consider establishing quality objectives for the improvement of the design process. This last step, and the standardization of design verification protocols in step five (5), are discussed in further detail in another blog by Medical Device Academy.
More Information Regarding Implementing Design Controls
If you are interested in design control training, Rob Packard will be teaching a Design Controls Training Webinar on November 2, 2018.
Posted in: Design Control
Leave a Comment (6) ↓
Rob – While I agree that a disciplined method for defining designs, evaluating hazards, and documenting outputs is absolutely necessary, I’m seriously worried that a rehash of the classical, linear, “waterfall” approach to design is a recipe for continued decline of the medical device industry in the U.S. – and lets all too many flaws hide until far too late in the design process.
We need a new approach that allows for learning, for refinement, and for explicit iteration with regular customer/stakeholder feedback.
A couple of key points you either miss entirely or don’t bring out:
– The 1997 FDA Design Controls Guidance presents the waterfall diagram that you show, but then explicitly goes on to recommend CONCURRENT ENGINEERING as a means of developing designs and solving the inevitable unforeseen design / hazard issues
– You recommend using standardized, fixed design verification protocols, but this is patently impossible for software. Every software design has its own set of required functions, its own set of hazard mitigations – and needs its own customized design verification
– Where I agree with your comment that design reviews need to have clear goals, I totally disagree with the standard approach of making these heavy, fixed, bureaucratic events. An Agile team which conducts and documents regular, frequent demonstrations in the course of development (without requiring all the same participants every time!!) can more than adequately review their design well before final release, and be ready for a final, all-stakeholders review that holds virtually no surprises.
Thanks for this description. Better understanding and adherence to medical device design controls is absolutely necessary. Let’s just not make the process so rigid that teams can’t respond to new information as development proceeds.
Brian Shoemaker
Mr. Shoemaker and I will choose to disagree on this. I have seen software validation protocols that were repeated due to a failure–such as hardware or a new version of the product that did not affect the validation protocol. However, making minor modifications to the previous protocol version is quite common for software.
For sterilization validation, knot tensile strength for sutures, and pull-out force for orthopedic screws–I recommend using standardized verification protocols and process validation protocols to streamline design V&V. This is part of the reason why larger companies have so many procedures. They write procedures to define the process for verification and validation and use standardized templates to make sure it is done right. This is how they leverage economies of scale.