Design history file requirements: what belongs in a medical device DHF
What a design history file must contain under 21 CFR 820.30 and ISO 13485, how the DHF relates to the DMR and DHR, and how to keep it audit-ready.
The design history file is the record that shows a device was developed according to an approved design plan. Auditors do not read it for elegance — they read it to confirm the plan existed, was followed, and produced traceable evidence.
What the regulation requires
21 CFR 820.30 requires manufacturers of Class II and Class III devices, and certain Class I devices, to establish design controls and maintain a DHF that demonstrates the design was developed in accordance with the approved design plan and the regulation. ISO 13485:2016 clause 7.3 sets equivalent expectations through the design and development file, and the EU MDR technical documentation in Annex II draws on the same records.
The FDA Quality Management System Regulation aligns 21 CFR 820 with ISO 13485, which reduces duplicate structures but does not reduce what has to be evidenced.
What belongs in the DHF
Design and development planning, including who is responsible for what. Design inputs — the requirements, traced to intended use and to risk management. Design outputs, expressed so they can be verified against inputs. Records of design reviews, with the independent reviewer identified. Verification records showing outputs meet inputs. Validation records, including software validation and usability, showing the device meets user needs and intended uses under actual or simulated conditions. Design transfer records. Design change records, each with its review, verification and where relevant re-validation. And the traceability that connects all of it.
Risk management under ISO 14971 runs alongside, referenced rather than duplicated.
DHF, DMR and DHR
The DHF records how the device was designed. The device master record is the recipe for building it. The device history record proves a specific batch or unit was built to that recipe. Confusing the three is one of the most common findings in a first audit.
Keeping it audit-ready
Build the DHF as development happens, not as a retrospective assembly exercise. Keep an index that maps each requirement of the regulation to the document that satisfies it. Make traceability a live artefact — requirement to risk to verification to validation — rather than a spreadsheet reconstructed the month before an audit. Control design changes with the same rigour as the original design; unmanaged post-launch change is where most DHFs come apart.
Where DevicePath fits
DevicePath sits earlier in the cycle: it tells you the likely FDA class, candidate product codes, the probable premarket pathway, real 510(k) predicate candidates with K-numbers, and high-level EU MDR and UKCA considerations. Knowing the class and pathway up front tells you which design control expectations apply before the file starts filling up. It is open source and built for start-ups, SaMD teams and small-to-mid-size manufacturers.