Design controls and the design history file
What the FDA requires of every device developer: user needs, requirements, design, verification, validation, and the record of all of it. Write a mock design history file for your project and you will sound like a third-year employee.
You are skimming: the title, the first figure, and the short version. Switch to Read in the header for the full page, or Deep to open every deep dive.
Every medical device company in the world runs the same process, because the FDA’s quality system regulation (and its international twin, ISO 13485ISO 13485The quality management standard for medical device companies; the reason everything is written down. Glossary entry) requires it. Design controlsDesign controlsFDA's required process for developing a medical device: user needs, requirements, design, verification, validation, and the records of all of it. Glossary entry is that process: a chain from what the user needs to what the device must do to what was built to the proof that it works, with every link written down. The written record is the design history fileDesign history file (DHF)The complete record of how a device was designed, showing every requirement traced to a test; writing a mock one teaches more than any lecture. Glossary entry. Almost no undergraduate has produced one. Produce a mock one for your Phase 5 project and you will have done the thing every device engineer does every day.
The chain
User needs. What the person needs, in their terms. From the need statement and the interviews. “The user must be able to send a pre-set urgent message without caregiver help.”
Design inputs (requirements). Testable statements of what the device must do to meet the needs. “The urgent-message selection shall complete within 10 seconds of the user’s initiating gesture in 95 percent of attempts.” “Input-referred noise shall be below 2 µV RMS from 0.5 to 40 Hz.” Each requirement traces back to a need and forward to a test. If you cannot write the test, it is not a requirement yet.
Design outputs. The device itself, described: schematics, code, drawings, the bill of materials, labelling, the user guide. What you built.
Verification. Testing that the outputs meet the inputs: did you build what you specified? Your characterization report from Phase 2 is a verification document. “Measured noise 1.1 µV RMS: requirement met.”
Validation. Testing that the device meets the user needs in real or simulated use: did you specify the right thing? The person with ALS sending the urgent message in their bedroom, timed, is validation. Verification can pass while validation fails, when the requirements were wrong.
Design review. Formal points where people who did not build it look at everything above and sign.
Design transfer. Moving from prototype to production, with the documents that let someone else make it.
Design changes. Every change after the first review, with why, and what re-testing it triggered.
Your amplifier passes every requirement in the spec. The user cannot use the device because the electrodes take twenty minutes to apply and their caregiver has ten. Which step failed?
Validation, and before that, user needs and design inputs. The device does what it was specified to do (verification passed). It does not meet the need (validation failed), because the requirements never included setup time. This is the most common way devices fail in the field and the reason validation is a separate step done with real users.
Traceability
The heart of the file is a matrix: each user need, the requirements that address it, the design outputs that implement them, the verification tests that prove them, and the validation evidence. A reviewer, or the FDA, picks any row and follows it end to end. Build the matrix as a spreadsheet from day one; retrofitting it is the misery every startup goes through.
Your mock DHF
For the Phase 5 project, one document with these sections: user needs (from your interviews), design inputs (ten to twenty testable requirements), design outputs (links to your schematics, code, and drawings), risk management (the FMEA from the next explainer), verification (your characterization and bench tests, with pass/fail against each requirement), validation (your sessions with the person, with measurements), a design review record (a friend and a mentor read it and signed), and a change log. Twenty pages. It is the most impressive thing a student can bring to a device-company interview, because it shows you know what the job is.
Deep dive Why the regulation exists 2 min
The design controls requirement dates from 1996 and followed a decade of recalls traced to design rather than manufacturing: infusion pumps with confusing interfaces, radiation therapy machines with software errors, the Therac-25 deaths. The regulation’s premise is that a device designed without a documented, reviewed process will fail in ways nobody anticipated, and that the fix is process, not genius. It is a good premise, and the recall database is the evidence.
Deep dive Software as a device 3 min
If your decoder runs on a laptop, the software is the device or part of it, and IEC 62304 governs its lifecycle: requirements, architecture, unit and integration testing, version control, and a record of every known bug and whether it was fixed. Machine-learning models add the question of how a model that was trained on data is verified; the FDA’s guidance on this is evolving and worth reading once. A Git repository with tests and tagged releases is most of the way to compliance for a student project.
Explain what this page was about to your roommate in three sentences. No jargon they would not know.