Design controls are a set of practices and procedures that medical device manufacturers must follow to ensure a product is safe, effective, and meets its intended purpose before it reaches patients. Required by the FDA under federal regulation 21 CFR 820.30, design controls create a structured framework that guides a device from initial concept through production, with documented checkpoints at every stage. They apply to Class II and Class III medical devices, and to some Class I devices that require design controls specifically.
The system works by forcing manufacturers to define what a device needs to do, prove it meets those requirements through testing, and document everything along the way. If that sounds straightforward, the details matter: each stage feeds into the next, and skipping or poorly executing any step can result in FDA warning letters, product recalls, or harm to patients.
The Waterfall Model: How the Stages Connect
Design controls follow what’s commonly called a “waterfall” model, where each phase flows into the next in a logical sequence. The process begins with user needs: what problem does the device solve, and for whom? Those needs get translated into formal design inputs, which are the specific, measurable requirements the device must satisfy. Engineers then develop the device, producing design outputs like specifications, drawings, and prototypes. Those outputs are verified against the inputs (did you build it correctly?) and then validated against the original user needs (did you build the right thing?).
Throughout all of this, formal design reviews take place at planned intervals, and every decision, test result, and change gets recorded in a design history file. The entire system is designed to create a traceable chain from “what the patient needs” to “what got manufactured,” with evidence at every link.
Design Inputs and Outputs
Design inputs are the requirements your device must meet. These include functional performance targets, safety requirements, usability criteria, and any applicable regulatory standards. Good design inputs share a few critical qualities: they must be complete, unambiguous, able to be verified or validated, and not in conflict with each other. A vague input like “the device should be easy to use” fails this standard. A measurable one like “90% of trained users can complete the primary task within 60 seconds” passes it.
Inputs also need to account for risk management outputs. If your hazard analysis identifies a risk that a device could overheat during use, your design inputs should include a maximum surface temperature requirement that addresses it.
Design outputs are what the engineering team actually produces: detailed specifications, manufacturing drawings, software code, labeling, and packaging requirements. Outputs must directly meet the input requirements, provide enough information for purchasing and manufacturing, contain or reference acceptance criteria, and specify characteristics essential for safe use. Think of inputs as the promises and outputs as the proof that you can keep them.
Verification vs. Validation
These two terms get confused constantly, but they answer fundamentally different questions.
Design verification asks: “Did you design the device right?” It confirms that your design outputs actually meet the design inputs you specified. Verification typically involves bench testing, inspections, and analysis. If your input says the device must withstand 100 pounds of force, verification is the test that proves it does. You’re checking the device against its own specifications.
Design validation asks: “Did you design the right device?” It confirms the finished product meets the actual user needs and intended use you started with. Validation is broader and more demanding. It must use initial production units, not just prototypes. It must involve clinical evaluation, meaning end users should interact with the device under simulated or actual use conditions. It must address the device’s specific intended environment. And it can’t ignore packaging and labeling, which are part of what the user experiences.
Simulated validation sometimes includes mathematical modeling, but the core principle is real-world performance. A device that passes every bench test but confuses clinicians during actual use has failed validation.
Design Reviews
Design reviews are formal, documented examinations conducted at planned stages throughout development. They aren’t casual check-ins. Each review must evaluate whether the design requirements are adequate, whether the design can actually meet those requirements, and whether any problems have been identified that need resolution.
The FDA requires that review participants include representatives from all functions involved in the stage being reviewed, plus at least one person who has no direct responsibility for that stage. This independent perspective is meant to catch blind spots that the core team might miss. Any specialists needed for a particular review must also be included. Results, attendee names, dates, and identified issues all get documented in the design history file.
The Traceability Matrix
A requirements traceability matrix is the tool that ties the whole system together. It maps every user need to its corresponding design input, design output, verification test, and validation activity. Think of it as a living checklist that tracks each requirement from initial definition through final validation.
Traceability works in both directions. Forward traceability links a requirement to the tests that confirm it’s met. Backward traceability links a test result back to the requirement it serves. This bidirectional mapping prevents two common problems: requirements that never get tested, and “orphan” tests that don’t trace back to any requirement. For FDA submissions, a well-maintained traceability matrix is one of the clearest ways to demonstrate compliance.
The Design History File
The design history file, or DHF, is the complete record of your design control activities. It must include or reference every document needed to show that the device was developed according to its design plan and quality system requirements. A typical DHF contains:
- Design and development plan
- Product requirements document (design inputs)
- Detailed design specifications (design outputs)
- Hazard analysis and risk documents including design and use FMEAs
- Design input/output matrix
- Verification and validation protocols and reports
- Design review meeting minutes
- Records of design changes
- Design transfer plan
The DHF isn’t a filing cabinet you assemble at the end. It’s built throughout development as each activity is completed. FDA warning letters have specifically cited companies for failing to maintain DHFs that demonstrate compliance with their own design plans.
Design Transfer
Design transfer is the process of converting your finalized design into production specifications that a manufacturing team can reliably execute. It bridges the gap between “the design works in the lab” and “the design can be manufactured consistently at scale.”
Before transfer begins, design outputs must be documented and a formal design review completed. The design transfer plan itself outlines which product is being transferred, who owns each deliverable, and how changes will be managed. It covers a wide range of production-related items: bills of materials, work instructions, incoming inspection requirements, process validation protocols, labeling and packaging specifications, test equipment validation, training requirements, and any special considerations like biocompatibility or environmental controls.
The goal is to verify that design outputs are suitable for manufacturing before they become final production specifications. A device that performs perfectly as a hand-built prototype but can’t be reproduced on a production line hasn’t been successfully transferred.
Managing Design Changes
Design changes happen throughout development and after transfer to manufacturing. The regulation requires manufacturers to establish procedures for identifying, documenting, reviewing, and approving changes before they’re implemented. Each change must be verified or validated as appropriate, meaning you need to assess whether the change affects previously confirmed requirements.
A minor material substitution might only need verification testing. A change to the device’s user interface could require full revalidation with end users. The traceability matrix becomes essential here: it shows which requirements are affected by a given change and which verification or validation activities need to be repeated.
ISO 13485 and International Requirements
Design controls aren’t unique to the FDA. The international quality management standard ISO 13485:2016 contains closely parallel requirements under clause 7.3, covering design planning, inputs, outputs, reviews, verification, validation, and transfer. The FDA’s updated Quality Management System Regulation actually incorporates ISO 13485:2016 by reference, aligning U.S. requirements more closely with the international framework.
ISO 13485 adds some emphasis that’s worth noting. It explicitly requires documented risk management activities throughout design and development. It requires that verification confirm proper function when the device connects or interfaces with other devices or systems. And it mandates that validation be completed before the product is released, using representative production units and meeting applicable regulatory requirements for clinical evaluation. If you’re developing a device for global markets, meeting ISO 13485 design control requirements will cover most of what the FDA expects as well.