A manufacturer does not keep one file about a device. It keeps several, written for different purposes, by different departments, over many years. Most of what an investigation needs is in them.
This guide explains the three core files, the records that surround them, and the questions each one answers. It then sets out how to write a request that covers the whole record, including similar devices, and what to look for when the production arrives. A one-page request schedule is on page 12.
Who this guide is for
- Legal counsel preparing a document request or reviewing a production.
- Engineering experts who must tell counsel what to ask for, and in what form.
- Risk managers and clinical engineering teams who request records from a supplier after an incident.
This guide is general technical information. It is not legal advice. Rules of discovery, privilege, and protective orders differ by court; the record names below are the names the regulation and ISO 13485 use, which is what a request should cite.
01Three files, three questions
Under FDA's quality system rules, a manufacturer must keep records that show how a device was designed, how it is meant to be made, and how each unit was in fact made. For decades these had three names.
Design history file. How the device was designed: plans, inputs, outputs, reviews, verification, validation, transfer, and every design change. It answers: what did the manufacturer intend, test, and know when the design was finished?
Device master record. The recipe: drawings, specifications, software, process instructions, acceptance criteria, labeling, and packaging. It answers: what should a correct unit be?
Device history record. The production record of one unit or lot: dates, quantities, acceptance results, labeling used, and the identifier. It answers: was this unit built and released as the recipe required?
Since February 2, 2026, FDA's Quality Management System Regulation (21 CFR Part 820) incorporates ISO 13485:2016 and uses its names. The design history file is now the design and development file (ISO 13485, 7.3.10). The device master record and the device history record are kept as the medical device file (4.2.3) and the production records it points to. The content did not go away; the labels changed. Records made before that date carry the old names.
Cite both sets of names in a request. A manufacturer that reads "design history file" narrowly for a device designed in 2027 may answer that no such file exists.
One device, four groups of records. Each row is a separate request item; each has an owner inside the company and a retention rule. The right column gives the place in the regulation or standard to cite.
02Writing the request
A request succeeds or fails on four points: the device is named exactly, the records are named as the manufacturer names them, the period is long enough, and similar devices are included. Each is a step below.
Name the device exactly
Give every name the device has carried: brand, model, catalog and part numbers, the product code, and the device identifier from the UDI. Add the software and firmware version that the unit ran, and every version released before and after it.
A model name on the label is not enough. Manufacturers keep records by part number and by software release, and a request that names only the brand can be answered with the records of a different revision.
Ask for the file, not for documents from it
Ask for each file as maintained, with its index, its revision history, and the documents the index lists. A file has a structure; a stack of documents chosen by the producing party does not. The index shows what exists, including what was not produced.
Cite the regulation and the ISO 13485 clause for each file (see the figure on page 5), with both the former and the current name.
Set the period wide
The record starts before the design did, with the project plan and the market need, and it continues after the event. Ask from the start of design to the date of the document production. Changes made after the event are often the clearest statement of what the manufacturer thought the problem was: a software release, a revised warning, a new acceptance test, a supplier change.
For complaints, MDRs, and CAPA, ask for the whole life of the model and its predecessors, not only the years around the event.
Include similar devices
Ask for the same records for the devices that share the design, the parts, or the problem: - the predicate device named in the 510(k), and the device's own successors; - models built on the same platform or with the same subsystem; - devices that use the same component from the same supplier; - other products under the same FDA product code, where the failure mode is the same. A manufacturer that saw the failure in a sister model knew about it, even when the file of the device in question is silent.
A request that lists documents by type ("all test reports") invites a production of what the manufacturer chooses to call a test report. A request that names the file and asks for its index invites the whole file.
03The request list
The items below are grouped as the figure on page 5 groups them. For each file, request the index, the revision history, and the documents listed, for the device and for the similar devices identified in step 04.
Design and development file
Design plan; user needs and inputs; outputs; review minutes; verification and validation protocols, reports and deviations; transfer records; every design change with its evaluation.
Risk management file
Plan; hazard analyses and FMEAs; risk estimates and acceptability criteria; risk controls and their verification; residual-risk evaluation; post-production reviews of field data.
Usability engineering file
Use specification; use-related risk analysis; formative study reports; summative study protocol and report; the use errors recorded in testing.
Software file
Requirements; architecture; V&V reports; release history with versions and dates; the known-anomalies list for each release; problem reports and their resolution.
Medical device file
Specifications, drawings, bills of materials, process and inspection instructions, acceptance criteria, labeling specifications, at the revision in force when the unit was made.
Production record for the unit
By serial or lot: build dates, components and lots used, acceptance results, nonconformance reports, rework, labeling applied, release signature.
Supplier records
Supplier qualification and agreements for the components involved; supplier change notices; incoming inspection results; supplier corrective action requests.
Premarket submission
The 510(k) or PMA as submitted, FDA's questions and the answers, the predicate comparison, and the test reports summarized in the submission.
Labeling and instructions
Every revision of the labeling and the instructions for use, with the change record and the reason for each change.
Complaint files
Every complaint for the same failure mode, with the record 21 CFR 820.35(a) requires: the nature of the complaint, the investigation, the reportability decision, the corrective action.
MDR submissions
Each report to FDA, including supplemental reports, and the internal decision record on whether to report.
CAPA records
Each CAPA opened for the failure mode or the component: trend data, root-cause analysis, actions, effectiveness check, closure.
Corrections and removals
Field actions, recall records and health hazard evaluations, customer notices, and the reports, or the decision not to report, under 21 CFR 806.
Servicing records
For the unit: each service event, work done, parts replaced, test data. For the model: service bulletins and field-repair instructions.
04Reading what comes back
The first review of a production is a review of its shape, not its content. Six questions tell you whether the record is complete.
Is the index there?
A file without its index cannot be checked for gaps. Ask for it by name.
Do the revisions line up?
Documents that postdate the unit, or a revision history with holes, point to records not produced.
Were there deviations?
Verification and validation rarely pass on the first run. A record with no deviations or retests is usually incomplete.
Was the risk file updated?
ISO 14971 requires field information to flow back into the file. A risk file dated before the first complaints was not maintained, or its later revisions were held back.
How did the CAPAs close?
A CAPA closed as "no root cause identified" or "no trend" is a decision. Ask for the data behind it.
Are the similar devices there?
Silence on the predicate and the sister models means the request was read narrowly. Say so, with the step 04 list.
| Item | Record | Cite | Period |
|---|---|---|---|
D1 | Design and development file (DHF) | ISO 13485 7.3; former 820.30 | All |
D2 | Risk management file, all revisions | ISO 14971; ISO 13485 7.1 | All |
D3 | Usability engineering file | IEC 62366-1 | All |
D4 | Software file, releases, known anomalies | IEC 62304; ISO 13485 7.3 | All |
P1 | Medical device file (DMR) | ISO 13485 4.2.3; former 820.181 | Model |
P2 | Production record, this unit (DHR) | ISO 13485 7.5, 8.2.6; former 820.184 | Unit |
P3 | Supplier records, components involved | ISO 13485 7.4 | All |
M1 | Premarket submission, FDA letters | 21 CFR 807 subpart E; 814 | All |
M2 | Labeling and IFU, all revisions | 21 CFR 801; 820.45, former 820.120 | Model |
F1 | Complaint files, same failure mode | 21 CFR 820.35(a), former 820.198; ISO 13485 8.2.2 | Model |
F2 | MDR submissions, reporting decisions | 21 CFR 803 | Model |
F3 | CAPA records, failure mode, component | ISO 13485 8.5.2, 8.5.3 | Model |
F4 | Corrections, removals, field notices | 21 CFR 806; part 7 | Model |
F5 | Servicing records, unit and model | 21 CFR 820.35(b), former 820.200 | Unit |
§Sources and further reading
- eCFR — 21 CFR Part 820, Quality Management System Regulation (820.35, complaint and servicing records)ecfr.gov
- eCFR — 21 CFR Part 803, Medical Device Reporting; Part 806, Reports of Corrections and Removalsecfr.gov
- ISO 13485:2016 — Medical devices, quality management systems (4.2.3 medical device file; 7.3.10 design and development files; 8.2.2 complaint handling; 8.5 improvement)iso.org
- ISO 14971:2019 — Application of risk management to medical devicesiso.org
- IEC 62366-1 — Application of usability engineering to medical devices; IEC 62304 — Medical device software, software life cycle processesiec.ch
A–ZTerms used in this guide
- Design history file (DHF)
- The records of the design of a device, from plan to transfer. Under ISO 13485, the design and development file (clause 7.3.10).
- Device master record (DMR)
- The specifications, procedures, and labeling needed to build a device. Under ISO 13485, the medical device file (clause 4.2.3).
- Device history record (DHR)
- The production record of one unit or lot: components, operations, tests, acceptance, labeling, release.
- Complaint file
- The record of each complaint: the allegation, the investigation, the reportability decision, and the reply.
- CAPA
- Corrective and preventive action: the record of a problem, its investigation, its root cause, the action taken, and the check that it worked.
- Production
- In discovery, the set of documents a party produces in response to a request, each with an identifying number. Distinct from manufacturing production, the record group P in this guide.
- Sister model
- A device of the same platform, design, or component set sold under another name or in another market.
- QMSR
- Quality Management System Regulation, 21 CFR Part 820 as amended in 2024 and in force from February 2026, which incorporates ISO 13485:2016.