ISO 13485:2016 · Clause 4.2.3
A worked procedure for establishing and maintaining an ISO 13485 medical device file, with the device family grouping decided, the file index built, and the legacy DMR, DHF and DHR terminology mapped across to what the regulation requires now.
On February 2, 2026 the terms Device Master Record, Device History Record and Design History File stopped appearing in 21 CFR Part 820. The requirements did not go away — they now flow from ISO 13485:2016, incorporated into Part 820 by reference. Most of what lived in the device master record now lives in the ISO 13485 medical device file at Clause 4.2.3, and the design history file corresponds to the design and development file at Clause 7.3.10.
The trap is that the medical device file is broader than the container it replaced. A device master record described how to build the device. Clause 4.2.3 asks for files containing or referencing the documents generated to demonstrate conformity to the standard and compliance with applicable regulatory requirements. Renaming a folder does not discharge it.
What the crosswalk usually finds. A legacy device master record covers Clause 4.2.3 b), c) and d) well, because those were its whole purpose — product specifications, manufacturing and packaging, and measuring and monitoring.
The gaps cluster at a), e) and f): the general description and intended use written as a regulatory statement rather than a marketing one, instructions for use held as a controlled document rather than as artwork owned by marketing, and installation and servicing where the determination was never recorded because the old regulation did not force it. The other consistent gap is the defined lifetime of the device, which the legacy structure had no place for.
Clause 4.2.3 requires one or more files for each medical device type or medical device family. How you group your devices decides how many files exist and what each one claims to describe.
Group too finely and you maintain forty files that differ in three fields each, which guarantees they will diverge. Group too coarsely and one file describes devices it does not accurately describe — worse, because it reads as complete right up until an auditor reads it against the product. That determination is almost never written down, and when it is not, the next person re-makes it differently.
Six questions, and one that decides the rest: can one set of specifications and procedures describe every member of the family accurately, without a qualifying sentence that applies to some members and not others?
Every over-grouped file announces itself the same way: a sentence beginning "except for the model." Each one is a device that should have had its own file, and a place where a reader can take the wrong specification and be right to have trusted the document. Count the qualifiers.
37 pages, editable Word, in three parts: instructions you delete, the procedure you keep, and a toolkit you work through and then delete.
Four other compilations sit next to this one, and confusion between them causes more badly built files than any other single reason. The template draws each boundary explicitly.
| That file | How it differs |
|---|---|
| Design and development file, Clause 7.3.10 | Records how the design was arrived at. The device file describes what the device is and how it is made now. Both are required, and excluding design controls does not remove the device file. |
| Risk management file, ISO 14971 | Referenced by the device file, not absorbed into it. Keeping it separate lets it be maintained on its own cycle as post-production information arrives. |
| Production or batch records, Clause 7.5.1 | Per batch or unit, evidencing execution. The device file is per type or family and describes intent. Do not fold production records into it. |
| EU technical documentation, Annexes II and III | Overlapping content, different structure and addressee. A notified body will not accept one in place of the other. |
Regulatory affairs and quality managers at device manufacturers and contract manufacturers, and consultants converting legacy FDA documentation. Especially relevant if your documentation predates February 2, 2026.
Also available as a bundle
Bundled with either manual, saving $49: with the ISO 13485 Quality Manual at $249, or with the Combined ISO 9001 + ISO 13485 Quality Manual at $349.
Not automatically. The medical device file is broader than the device master record it replaces. A DMR described what was needed to manufacture the device. Clause 4.2.3 asks for files containing or referencing the documents generated to demonstrate conformity to the standard and compliance with applicable regulatory requirements — a wider brief. A mature DMR covers a good deal of it, which is exactly what makes renaming tempting. The gaps are usually the general description and intended use, instructions for use as a controlled document, the recorded determination on installation and servicing, unique device identification, and the defined device lifetime.
The term no longer appears in 21 CFR Part 820. The requirement is now the design and development file at ISO 13485 Clause 7.3.10, incorporated into Part 820 by reference. In practice most organizations continue to call it a DHF internally, which is fine — what matters is that the content meets Clause 7.3.10 and that it exists as a file distinct from the medical device file. Both are required, and a single combined compilation satisfies neither cleanly.
One or more per device type or family, and the grouping is your determination to make and record. The template supplies six tests — shared intended use, design platform, classification and submission, manufacturing process, risk profile, and whether a change to one member requires assessment of the others — plus a decisive test: can one set of specifications describe every member without a qualifying sentence? If the file would need qualifiers, they are separate types and take separate files.
Record the determination in the row rather than deleting the row. Clause 4.2.3 e) and f) qualify installation requirements and servicing procedures with "as appropriate," which asks the organization to determine whether they apply. A determination that leaves no trace is indistinguishable from an oversight. A file with a row reading "not applicable — device is supplied ready for use and no installation activity is specified" answered the question. A file missing the row may never have been asked it.
Either is permitted by Clause 4.2.3. The template uses referencing as the default, because a contained file goes stale the moment a referenced specification is revised, and a superseded copy inside a file is more dangerous than a broken reference because it looks authoritative. Containing is the better answer where the file must travel intact — supplied to a contract manufacturer, a distributor in another jurisdiction, or an organization that does not control the underlying documents.
In the medical device file, and it matters well beyond that file. Clause 4.2.5 anchors record retention to the lifetime of the device as defined by the organization, with a floor of two years from device release. If the lifetime is never defined, the retention requirement has no floor and every retention period in the quality system rests on nothing. Define it per device in the file, then reference it from the records procedure rather than the other way around.
Management Systems International is a veteran-owned, female-owned ISO consulting firm founded in 1998. Over 28 years we have supported 80+ certifications, attended 200+ audits, and trained 600+ professionals across quality, environmental, health and safety, and healthcare management systems.
These templates were written by the consultants who sit in the audits. The defects they are built to prevent are the ones we watch organizations answer for.
QMS Interviews course — preparing your people for the questions an auditor actually asks.
