Every medical device starts as a set of needs. Design controls turn those needs into a device, and leave a record that shows how it was done.
This guide explains the waterfall model of design controls, the records it produces, and how to trace a requirement from a user need to the test that proved it. It closes with what to look for when a design record is reviewed in litigation or in an audit.
Who this guide is for
- Legal counsel who review design records in discovery.
- Manufacturers — engineering and quality teams preparing for an audit.
- Hospitals — clinical engineering teams who evaluate design evidence.
This guide is general technical information. It is not legal or regulatory advice. Confirm which version of the regulation and which standard editions apply to the device and the dates in question.
01Why the design record matters
FDA requires manufacturers of Class II and Class III devices, and of some Class I devices, to control their design process. The idea is simple: plan the design, define what the device must do, show that the design does it, and show that the finished device meets the needs of its users.
The result is a design record that can be read years later. In an investigation, it is often the best evidence of what the manufacturer intended, what it tested, and what it knew.
On February 2, 2026, FDA's Quality Management System Regulation (QMSR) took effect in 21 CFR Part 820. It incorporates ISO 13485:2016 by reference. The design and development requirements are now mainly in clause 7.3 of that standard.
Design work done before that date was subject to the former Quality System Regulation, including its design control section, 21 CFR 820.30. Read each record against the requirements that applied when it was made.
The waterfall is a teaching model, not a required process. FDA's 1997 design control guidance uses it to show how the elements relate. Real projects iterate; the record should still show each element.
Application of design controls to the waterfall design process, after FDA's Design Control Guidance for Medical Device Manufacturers (1997).
02From user needs to a finished device
User needs
What the device must do for the people who use it, in their words and in their environment: the intended use, the users, the use environment, and the clinical need.
Design input
The physical and performance requirements of the device, written so that each one can be verified. Inputs include requirements from standards, regulations, and the risk analysis. The process must resolve incomplete, ambiguous, or conflicting requirements.
Design output
The drawings, specifications, software, labeling, and acceptance criteria that define the device. Outputs essential for the proper function of the device are identified, and each output can be checked against an input.
Design review
Formal, documented reviews at planned stages. Under the former rule, each review included at least one person without direct responsibility for the stage under review.
Verification
Objective evidence that the design output meets the design input: tests, inspections, and analyses, each traced to the requirement it covers.
Validation
Objective evidence that the device meets user needs and intended uses. Validation is done on initial production units, lots, or their equivalents, under actual or simulated use conditions, and includes software validation and risk analysis where appropriate.
Transfer and change
The design is transferred into production specifications. Later changes are identified, documented, verified or validated as appropriate, reviewed, and approved before they are put into effect.
Software and usability have their own process standards, IEC 62304 and IEC 62366-1, which FDA recognizes as consensus standards. Their plans, requirements, and test records belong in the same design file.
03Three records, three questions
Three records describe a device from design to delivery. Each answers a different question, and an investigation often needs all three.
| Record | Question | Typical contents |
|---|---|---|
| DHF Design history file | How was the device designed? | Plans, inputs, outputs, reviews, verification, validation, risk file, design changes |
| DMR Device master record | How is the device made? | Specifications, drawings, production and test procedures, labeling, acceptance criteria |
| DHR Device history record | How was this unit or lot made? | Dates, quantities, acceptance records, labels, and the device identifier for each unit or lot |
The QMSR does not keep the DHF, DMR, and DHR as defined terms. ISO 13485 requires equivalent content: the design and development file (clause 7.3.10), the medical device file (4.2.3), and a record for each device or batch (7.5.1, 8.2.6).
Many companies still use the familiar names, and records made before February 2026 carry them. Ask for the content, whatever the record is called.
04Traceability
Traceability links each user need to the design inputs that address it, each input to the outputs that implement it, and each output to the verification and validation that proved it.
Risk controls belong in the same chain. Under ISO 14971, each risk control becomes a requirement, and its implementation and effectiveness must be verified. A trace matrix makes the chain visible:
| Need | Input | Output | Test |
|---|---|---|---|
UN-04 | DI-17 | DO-32 | VER-09 |
| Alert the user when flow stops | Occlusion alarm within a defined time | Pressure-sensing firmware module | Bench occlusion test report |
05What to look for in litigation or audits
Inputs that cannot be verified
Words such as “robust” or “user-friendly” with no measurable criterion.
Gaps in the trace
Needs or risk controls with no test, or tests with no requirement.
Verification that does not match
Test conditions, samples, or software versions that differ from the released design.
Validation on the wrong units
Prototypes instead of production-equivalent units, or use conditions that leave out the real environment.
Changes without re-verification
Design changes after release with no record of impact assessment, testing, or approval.
Field data not fed back
Complaints and reports that describe a failure mode the risk file does not address.
Records that do not fit the timeline
Dates, signatures, and versions that do not agree with each other.
Each flag is a question for the record, not a conclusion. The answer is in the documents the trace should lead to, and in the test reports behind them.
✓Records to request
- Design and development plans
- User needs and design input requirements
- Design outputs: specifications, drawings, software, labeling
- Design review records, with attendees
- Verification protocols and reports
- Validation protocols and reports, including software and usability
- Risk management file and trace matrix
- Design change and design transfer records
- DMR or medical device file; DHR for the unit or lot
- Complaint, CAPA, and MDR files for the failure mode
§Sources and further reading
A–ZTerms used in this guide
- Design controls
- The required way of developing a device: planning, inputs, outputs, review, verification, validation, transfer, and change control, with records of each.
- Design input
- The requirements a device must meet, derived from user needs and intended use, written so that they can be verified.
- Design output
- The specifications, drawings, software, and labeling that define the device, each traceable to an input.
- Verification
- Objective evidence that the design output meets the design input: the device was built as specified.
- Validation
- Objective evidence that the device meets user needs and intended uses under actual or simulated use conditions.
- Design history file (DHF)
- The compilation of records that describes the design history of a finished device. Under ISO 13485, the design and development file.
- Traceability
- The documented links from each user need to its inputs, outputs, verification, and validation, and to the risk controls it carries.
- Design transfer
- The step at which the design is translated into production specifications, and the records that show it was done correctly.