Everything You Need to Know About Design Controls for Medical Devices
Navigating the medical device regulatory environment can seem daunting at times, and it's easy to get lost in the technical jargon of the standards. Taking a step back to understand how a requirement can be beneficial to your bottom line is a helpful approach to managing regulatory overwhelm.
Listen to the audio version of this article read by a real person here (Sound on!):
For those that are new to the regulatory landscape, Design Controls is one of the more difficult set of procedures to comprehend. It is a big system with lots of requirements. This is your complete guide to understanding just what Design Controls really means for your medical device product development.
Table of Contents
- What are Design Controls?
- What is the Purpose of Design Controls?
- Design Controls and Your Quality Management System
- Key Elements of Design Controls
- Succeeding with Design Controls
What are Design Controls?
Design Controls are practices required by the FDA to facilitate a structured design and development process for medical devices. There are multiple checkpoints in place to ensure the device is safe and effective when brought to market. If you are a medical device manufacturer, compliance with Design Controls is required.
- Deliver quality products
- Ensure user safety
- Maintain regulatory compliance
- Keep costs down
- Accelerate time to market
What is the Purpose of Design Controls?
Design Controls are required to improve product quality and help companies avoid manufacturing defects that can lead to recalls or other significant issues. Complying with the requirements fully can prevent recalls and other regulatory enforcement actions. FDA warning letters and recalls are outcomes medical device or software as a medical device (SaMD) companies want to avoid, underscoring the need for a strong Design Controls system.
Design Controls provide a structure for ensuring that device design and development is completed in a highly controlled manner. This means that each design step is planned before being executed and that the execution is verified.
Design Controls also ensure that a cross-functional approach is taken to the design process so that additional viewpoints are considered and potential roadblocks are realized early.
Ultimately, organizations use these controls to ensure their design processes deliver products to market that are safe and effective.
How do Design Controls Factor into a Quality Management System?
Design Controls is one process that should be integrated into the quality management system (QMS). Your QMS should also have procedures in place to manage documents, records, and suppliers, so Design Controls link those pieces together with additional development specific processes.
The design and development process, which Design Controls regulates, extends beyond creating and testing a device. Creating documents, ensuring that suppliers are adequately qualified for their role in the manufacturing process, and maintaining records are just a few of the QMS procedures that directly feed into design controls. Once the initial design has been completed and brought to market, the QMS will continue to be necessary for ongoing compliance. Regulators require ongoing monitoring and quality system reporting related to the device including complaint handling, nonconformance monitoring, and Risk Management.
Even when the Design Controls process has been completed, the work is far from done and you will need to rely on your existing QMS for ongoing control of your device.
Key elements of Design Controls
Now that we understand how Design Controls fits into the big picture we can dive into the process itself.
The following elements are a generalized approach of blended FDA/ISO requirements, mostly using FDA terminology. Each element of Design Controls is carefully considered by an auditor, and those specific considerations are listed at the conclusion of each of the following Design Controls elements.
1. Establish QMS Procedures
Starting with effective, well-thought out QMS procedures will make for a smoother implementation.
When an organization develops a device before establishing the QMS and Design Controls process, some common issues that may arise are:
- Missed compliance steps in device development
- Ineffective procedures (written out of context)
- Disorganization and more resources used in retrospective "clean-up"
- Messy audits (for all the above reasons)
- Delays getting product to market
- Design changes to device that does not meet all requirements
Writing procedures is only half of the work—the procedures must also be implemented. You can have volumes of procedures to show to an auditor, but if you can’t show that they’ve been implemented you're not in compliance.
Auditors look for: Are the activities performed by the organization regarding Design Controls consistent with the procedures developed (i.e. are they implemented)?
2. Document Design and Development Planning
Once you have your QMS and Design Control procedures in place, you need to develop your Design Plan. Typically organizations create Development Plans with "Phases" or "Stages" that align roughly with these milestones, which we'll explore in more detail. Those phases or stages are:
- User Needs / Design Input / Initial Risk Assessment
- Design Output / Device Risk Assessment
- Design Manufacturing Process / Supplier Qualification / Process Risk
- Design Verification and Design Validation / Design & Process Risk
- Design Transfer for Manufacturing
Auditor looks for: Are planning documents established? Are team members defined? Are plans effective and being followed?
3. Apply Risk Management
Risk Management is complex on its own, however, Risk Management is a critical part of all areas of design and development, and will be summarized here.
Risk Management is most commonly applied per the ISO 14971 standard, recognized by both FDA and EU. It is applied early to the development process, as risks and harms are to be considered as an outcome and a driver for User Needs and Design Inputs. Risk is subsequently re-evaluated as the design takes shape and new considerations likely arise. Risk will be continually reviewed throughout the product life cycle.
Auditor looks for: Is Risk Management applied to the design and development process throughout? Are risks mitigated through the design process?
4. Perform Design Reviews
Design Reviews are checkpoints throughout the design process that can prevent wasted time and money on a device that won’t work or meet requirements. Completing thorough, cross-functional reviews at each phase and taking necessary corrective actions can prevent issues down the road when it comes time for Design Verification and Design Validation (VnV).
Regulations don't mandate the specific project milestones at which Design Review is to occur, so this is up to the organization to define in their SOPs. The following is an example of what's common in industry:
- Phase 1 Close-out: User Needs/Design Input Review
- Phase 2 Close-out: Design Output Review
- Phase 3 Close-out: Design Verification and Validation Results Review
- Phase 4 Close-out: Design Transfer/Release Final Review
Primary expectation in Design Review:
- Record attendees of the review, their roles, and approval of the review
- Record the stage/phase being reviewed
- Record meeting minutes with any action items
- Ability to connect the review to the respective device's Design History File (DHF)
Auditors look for: Does each Design Review include an independent reviewer not directly involved with the design and development project? Are action items being addressed that are noted during phase reviews? Are phases being used to gate the design from proceeding?
5. Establish User Needs and Design Inputs
Before device development begins, the purpose of the device must be defined to ensure it achieves the intended purpose, per the user and the organization.
User Needs and Design Inputs are very similar. Notice the distinction in the example for a syringe device:
- User Need example: The syringe must fit in an emergency medical services go-bag
- Typically driven by use case marketing feedback from potential users
- Finished device will be Validated later in the process to ensure the user is satisfied with the size of the syringe
- Design Input example: The syringe shall be no more than 5" in length and 1" in diameter
- Typically translated from User Needs to something more tangible for the engineering team to work with
- Finished Device will be Verified later in the process to ensure the syringe length/diameter meets the Design Input
Auditor looks for: Are User Needs and Inputs concise and unambiguous? Do they conflict with one another?
6. Establish Design Outputs
Design Outputs represent the characteristics of the device that make the Design Inputs and User Needs a reality.
Continuing with the example of the syringe device:
- User Need example: The syringe must fit in an emergency medical services go-bag
- Design Input example: The syringe shall be no more than 5" in length and 1" in diameter
- Design Output example: McKesson Brand #16-S1C, 1cc, 4.1" x 0.375" dia. syringe (device drawing)
- The Design Output can be viewed as the answer to the Design Input
- Verification ensures the Design Output meets the Design Input
Auditors look for: Are Outputs linked to respective Inputs and Verification activities in the Design History File? Are the linked drawings and specification files current and controlled documents?
7. Perform Design Verification and Design Validation (VnV)
VnV are testing activities required for ensuring the device meets the pre-defined specifications and intended purpose.
Verification vs. Validation are commonly mixed up:
- Design Verification: Did you design the device right?
- Evaluating if Design Inputs are achieved - are specifications met?
- Design Validation: Did you design the right device?
- Evaluating if User Needs are met
The critical factors of Verification and Validation are:
- Planning: VnV is complex, and requires qualified individuals performing well-defined tests.
- Samples: VnV must be performed on finished device "equivalents" and the organization must provide rationale for the sample size tested.
- Many organizations cut corners here and end up having to perform multiple iterations of VnV
- Sample sizes must be supported with a rationale statement based on statistical sampling plans
- Software device sample size of 1 is commonly acceptable with proper rationale
Making changes to the device after VnV is costly since it may require going back and completing VnV activities again. Making sure prior phase reviews have been completed can help prevent sending a device out for VnV that is destined to fail.
Auditors look for: Are VnV performed on finished device equivalents? Are sample sizes used based on Statistical Techniques? Have all User Needs and Inputs been tested? If you have a contract manufacturer, do you have proof they have validated their manufacturing process? Are all VnV activities documented in the DHF?
8. Document Design Transfer
Design transfer is the process of making all the final arrangements for transferring the device to commercial production. Once Design Transfer is completed you should be able to “turn the key” to start manufacturing your product.
Through Design Transfer you will be able to:
- Connect design documentation to manufacturing documentation
- Verify the Design History File (DHF) is complete and contains all required items
- Document that records of the transfer to manufacturing are maintained
- Ensure that training is completed for manufacturing personnel
- Ensure that regulatory approvals are received before releasing product to the market
Auditors look for: Have all final actions required to send the device to market been taken?
9. Completing Design Changes and the Design History File (DHF)
The FDA's rule on DHF states: "Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part."
End-users employ various methods of documenting a DHF. Since the regulations include "reference" to the records that make up the file, users will often create a DHF Index that acts as a Table of Contents for DHF records.
So, what is a DHF vs. a DHF Index? They're two varying methods representing the same end-goal. Using a DHF Index to guide the reader through the records that make up the DHF is, without question, a far more effective way to present this complex compilation of records.
- Compilation of all design activities related to the development of the device
- Commonly recorded as an index/list of activities with easy access to reference documentation listed
- A Design Control Matrix contains a majority of the records found in the Design History File
- May occur at any time pre/post-release and must be done in accordance with established procedure(s)
- Must follow formal development lifecycle as already prescribed by FDA/ISO (i.e. input, output, VnV, DHF, etc.)
- Require proof of risk assessments related to change - update to risk management file if necessary
Note that Device Master Records (DMR) are commonly mixed up with DHF. The DMR is a "recipe" for the device including drawings, specifications, and work instructions, whereas the DHF represents the activities supporting its development. To make matters more confusing there is also the Device History Record (DHR) which is maintained to house all of the records specific to each batch/lot of devices.
Auditors look for: Does the DHF contain all design activities, or a link to all design activities performed related to a project? Activities include: Design Reviews, Inputs, Outputs, Verification and Validation Reports, Risk Reviews, etc.
Tips for succeeding with Design Controls
1. Don't Wait to Start Design Controls
The first question many companies have is: when do Design Controls begin? Regulation doesn’t explicitly name when Design Controls are required to start. However, the FDA provides the following direction:
- Where research ends and design begins
- After Feasibility/“Proof of Concept”
- When you plan to bring your device to market
- Prior to start of any Investigation Device Exemption (21 CFR 812)
- Premarket Mechanism of change/revision
Some may argue that starting Design Controls early will subject their product to greater regulatory burden and cost, but that’s not the case. The reality is that for many companies, starting Design Controls sooner rather than later can actually save money and time down the road.
Design Controls are not vastly more burdensome than following sound engineering practices. A process with well-defined stakeholders, responsibilities and goals is a far better experience for teams than a disjointed approach, regardless of the stage of the product.
Understanding Design Controls means embracing the discipline needed to successfully develop a compliant medical device or SaMD solution. Beginning Design Controls early should be driven by the company’s goals to develop a safe and successful product rather than regulatory pressure. The mindset you exhibit toward implementing Design Controls is just as important as following the regulatory guidance. Building a culture of quality into the company from the outset of the design process will help ensure that quality mindset is maintained throughout the device lifecycle.
2. Get Away from Paper as Soon as Possible
If you haven’t already done so, migrate from a paper-based system to a cloud-based quality management system. These are now the industry standard, as they equip medical device companies to easily comply with ISO and FDA regulations. A paper-based system is cumbersome and makes it difficult to quickly log information in your DHF or communicate changes across teams. It can also leave more room for error, whereas in a cloud-based system, you can track changes, monitor who accessed a document, and more.
3. Adopt a Unified Approach
Often, it can feel like quality and product development are on opposing sides—creating a sense of friction between the two teams. Adopt a unified approach so that quality isn’t seen as a blocker but as a critical function that bolsters the product development team’s goals. Make sure the teams work together and not in silos using different software and project tracking tools.
4. Get Help If You Need It
When you first start implementing Design Controls, there are a lot of complex issues that you’ll need to tackle. If you’re unsure when or how to start, then it may benefit you to ask an expert for help. Starting with a strong Design Controls procedure and system can save headaches down the road. Services like Qualio Plus feature a team of experts that can advise you on Design Controls and the entire FDA approval process.
Accelerate Product Development with Design Controls software
Design Controls can be complicated—let Qualio simplify it with software designed specifically for the medical device industry. Our industry experts created a platform that can help your medical device company navigate requirements, and we’ll also provide you with direct access to those experts who can give you valuable guidance. Contact us today to set up a demo of our design controls software.