The records and controls behind a medical device
Design controls are a documented, traceable process that connects what the device is supposed to do, to how it was designed, to the evidence that it works. In the US they are required under 21 CFR 820.30 for most Class II and Class III devices, and the equivalent expectations under ISO 13485 apply in most other markets.
The chain of traceability
Design controls connect the requirements, design work, reviews, testing, and final evidence. Each part is documented.
User needs
What the device has to accomplish for the patient or clinician.
Design inputs
Those needs translated into specific, testable requirements.
Design outputs
The specifications, drawings, and code that satisfy the inputs.
Verification
Proves the outputs meet the inputs — that the device was built right.
Validation
Proves the device meets the user needs — that the right device was built.
A traceability matrix ties each requirement to the output that implements it and the test that proves it. Design reviews happen at defined stages, design transfer moves the design into manufacturing, and design changes after that go through the same controlled process. The design history file holds all of it, and it is what an auditor asks to see.
DFMEA
Design failure mode and effects analysis asks, for every component and function, what happens if it fails. Each failure mode is rated for severity, occurrence, and detection. The combination prioritizes which risks need design mitigation, and the mitigations feed back into the design inputs and the verification plan.
DFMEA is most useful when it is done early enough to influence the design. Done later, it mainly documents decisions that have already been made. The difference shows up in how many hazards are engineered out versus how many are left for a warning label.
How bad the consequence is.
How likely it is.
How likely the failure is to be caught before it causes harm.
Risk management as the frame
ISO 14971 is the standard for medical device risk management, and DFMEA is one tool inside it. The overall risk management file ties together hazard analysis, risk evaluation against defined acceptability criteria, mitigation, and residual risk — and it stays live through the device's life, updated as post market data comes in.
Scaling rigor to risk
The process should match the device and its risk. A Class I device with an established design history does not need the same depth as a Class III device that is first of its kind. The phase guided approach sets the checkpoints, and the risk level, prior product history, and novelty of the design set how much evidence each checkpoint demands.
SequoiaAT applies design controls, DFMEA, and validation frameworks across hardware, firmware, and cloud on medical device programs, scaled to the device class and the novelty of the design, following a phase guided flow from concept through post market support.