↑↓ move↵ open[] previous / next lesson? all shortcuts
Appearance
Theme
Type size
Reading

Focus mode hides the sidebars. Press f to toggle it anywhere.

Keyboard shortcuts
/
Search
[ ]
Previous / next lesson
t
Jump to the table of contents
r
Review queue
f
Focus mode
?
This panel
Explainer14 min

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.

AssumesNeeds findingThe characterization reportSpineClinical / regulatory / human factors
On this page14 min
  1. The chain
  2. Traceability
  3. Your mock DHF

Every medical device company in the world runs the same process, because the FDA’s quality system regulation (and its international twin, ) requires it. 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 . 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

Figure 1. The V. Down the left, what you decided to build and why; up the right, the proof that you built it and that it does the job. Every step across is a document.

User needs. What the person needs, in their terms. From the and the interviews. “The user must be able to send a pre-set urgent message without caregiver help.”

Design inputs (). 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.

. Testing that the outputs meet the inputs: did you build what you specified? Your report from Phase 2 is a document. “Measured noise 1.1 µV RMS: requirement met.”

. Testing that the device meets the user needs in real or simulated use: did you specify the right thing? The person with sending the urgent message in their bedroom, timed, is . can pass while fails, when the 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.

Predict before you look

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?

, and before that, user needs and design inputs. The device does what it was specified to do ( passed). It does not meet the need ( failed), because the never included setup time. This is the most common way devices fail in the field and the reason is a separate step done with real users.

Traceability

The heart of the file is a matrix: each user need, the that address it, the design outputs that implement them, the tests that prove them, and the 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 ), design outputs (links to your schematics, code, and drawings), risk management (the from the next explainer), (your and bench tests, with pass/fail against each requirement), (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 requirement dates from 1996 and followed a decade of 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 database is the evidence.

Deep dive Software as a device 3 min

If your runs on a laptop, the software is the device or part of it, and IEC 62304 governs its lifecycle: , 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.

Recall
What is the difference between verification and validation?
Verification tests that the device meets its requirements (did you build what you specified). Validation tests that the device meets the user's needs in real use (did you specify the right thing).
Recall
What makes a statement a requirement rather than a wish?
It is testable: it names a measurable outcome and a condition, so that a specific verification test can pass or fail it.
Recall
What is a traceability matrix?
A table linking each user need to its requirements, design outputs, verification tests, and validation evidence, so any row can be followed end to end.
Explain it to your roommate

Explain what this page was about to your roommate in three sentences. No jargon they would not know.