When a device fails in the field, someone tells the manufacturer. What happens next is written down three times, in three systems, by three groups of people.
This guide follows one report through the complaint file, the MDR to FDA, and the corrective and preventive action system. It explains what the regulation requires at each step, how to read the records that result, and the patterns that show a report was received but not acted on.
Who this guide is for
- Legal counsel reading a production of complaint files, MDRs, and CAPA records.
- Manufacturers — quality and regulatory teams who run these systems or prepare them for inspection.
- Hospitals — risk managers who report events and want to know what the report sets in motion.
This guide is general technical information. It is not legal or regulatory advice. Reporting periods and record contents are quoted from 21 CFR Parts 803 and 820 and ISO 13485:2016 as in force in October 2026.
01One report, three records
A complaint is any communication that alleges a deficiency in a device that has been released: in its identity, quality, durability, reliability, usability, safety, or performance. A phone call to a sales representative is a complaint. So is a service ticket, a returned unit, a social-media post that reaches the company, and an adverse-event report filed by a hospital.
The regulation does not care which door the report came through. It requires that every one is received, recorded, evaluated, and, where needed, investigated, and that the records show it. Three records result.
The complaint file. The manufacturer's own record of the report and its investigation. 21 CFR 820.35(a) lists what it must contain.
The medical device report. What the manufacturer told FDA, on the clock Part 803 sets, when the event involved a death, a serious injury, or a malfunction that could cause one.
Corrective and preventive action. What the manufacturer did about the cause, once the complaints, taken together, showed there was one.
The three records are kept by different people and rarely cross-reference each other well. Matching them is the first task, and the complaint number is the key.
Eight steps, each with a record. A production that stops at step 05 for every complaint, with no step 06 and no CAPA, is itself a finding.
02Reading complaint files
A complaint file is read for three things: whether the report was treated as a complaint, whether it was investigated, and what the investigation concluded. The columns of the complaint database tell most of it.
Check the door it came through
Service tickets, returned-goods records, and sales notes are complaints when they allege a deficiency, whatever the system calls them. Ask for the procedure that defines a complaint and the records of reports that were evaluated and found not to be complaints. A manufacturer that logs failures as "service" and never as "complaints" has a complaint rate of zero and a service record full of failures.
Read the investigation, not the status
"Investigation complete" is a status. The record behind it says what was done. Three findings are common and deserve a second look: "device not returned, unable to evaluate", which ends the investigation without a test; "no malfunction found", which describes a bench result, not the event; and "user error", which is a conclusion that needs the usability file to support it (guide 12).
03Reading MDRs
An MDR is what the manufacturer told FDA, on a form with fixed fields and a free-text narrative. The same report is in MAUDE (guide 02), but the manufacturer's copy carries what the public one does not: the internal complaint number, the reportability decision, and the dates behind the clock.
Match the MDR to the complaint
Every MDR starts as a complaint. Find the complaint record, compare the two narratives, and compare the dates: the date received, the date the manufacturer decided the event was reportable, and the date it reported. The gaps between them are the first thing a reviewer reads.
Read the narrative as a choice
The narrative is written by the manufacturer, after an evaluation, with the regulation's definitions in mind. "The device was found to function within specification" says the bench test passed; it does not say the event did not happen. "The cause could not be determined" says what was not found. Read each sentence for what it establishes and what it leaves open, and read the supplemental reports: the first report is often filed before the investigation, and the supplement is where the conclusion lives.
Awareness starts the thirty-day clock, and the regulation defines it as the day any employee becomes aware of information that reasonably suggests a reportable event. The date the quality department opened the file is not the date of awareness if a field engineer heard about the event a month before.
04Reading CAPAs
A CAPA is the manufacturer's written answer to a problem it has recognised. ISO 13485 requires a sequence: review the nonconformity, find the cause, decide on action, implement it, verify it caused no new problem, and review whether it worked. A CAPA record is read against that sequence.
What opened it, and when
The trigger: a complaint trend, an audit, an MDR, a field report. Compare the opening date with the first complaint of the same kind. The gap is the time the problem was visible before it was recognised.
The root cause
A root cause explains why the failure happened, not what failed. "Component failure" and "operator error" are descriptions; "the seal softens above the storage temperature on the label" is a cause. "No root cause identified" is a decision to stop looking; ask what data it rested on.
The action
Does the action address the cause? Retraining answers a knowledge gap, not a design. A label change is the lowest control in ISO 14971’s order (guide 04). A design change is the strongest, and the one that opens the design file.
Verification and effectiveness
Verification shows the action broke nothing else. The effectiveness check shows the problem stopped: complaint rates after the action, against before. A CAPA closed before the effectiveness period ended was closed on hope.
Where it went
A design cause should lead to a design change, a risk-file revision, and possibly a correction or removal (guide 14). If none of these records exist, the CAPA ended in the CAPA system.
05Finding the trend
Single complaints rarely decide anything. The pattern across complaints does. The manufacturer is required to analyse its complaints together (ISO 13485, 8.4), and the reviewer does the same with the production.
One table
Every complaint, one row: date received, model, serial or lot, software version, failure mode as reported, failure mode as coded, investigation result, MDR number, CAPA number.
Your own failure-mode criteria
Write the criteria for "same failure mode" before coding, and code from the narrative, not from the manufacturer's code. Codes change, and the same event is coded differently by different reviewers.
Rates, not counts
A count means little without the number of units in the field. Ask for shipment data by model and period, and express the trend as complaints per thousand device-years, or the nearest measure the data supports.
Compare with the thresholds
The manufacturer's trending procedure sets the level at which a trend opens a CAPA. Compare the rate you find with that threshold, and the threshold with the risk file's probability estimate for the same hazard.
Look across models
Sister models, predecessors, and devices with the same component (guide 05, step 04). A failure mode that appears in three models is a platform problem.
A trend analysis is reproducible or it is an opinion. Keep the criteria, the coding, and the shipment data with the table, so another reviewer reaches the same numbers.
06Where the trail thins
These are the gaps most often found between a report and an action. Each is a question for the record, and a well-run system has an answer.
Reports that were not complaints
Service and return records that allege a failure but never reached the complaint system.
Investigations that ended at the door
“Device not returned” as the end of the inquiry, with no request for the device, the data, or the facility's records.
Late awareness
MDR clocks started from the quality file, not from the first employee who knew.
Trends under the threshold
A threshold set so high that the trend never opens a CAPA, or complaint categories split so that no one category crosses it.
CAPAs without a cause
“No root cause identified”, “isolated event”, or “use error” without the investigation to support it.
Actions without effect
Retraining, a memo, or a label change where the cause was in the design, followed by the same complaints.
Nothing goes back
No risk-file revision, no design change, no field action, after a CAPA that found a cause.
The CAPA record is the manufacturer's own account of what it knew, when it decided to act, and what it did. It is usually the most direct evidence in the file.
✓Field records at a glance
- Complaint-handling procedure and the definition of a complaint obtained
- Reports evaluated as "not a complaint" requested
- Complaint files matched to MDRs and CAPAs by complaint number
- For each MDR: date received, awareness date, reportability decision, report date
- Supplemental MDRs read; conclusions taken from the last report, not the first
- Investigation records read behind every "complete" status
- Trend table built with your own failure-mode criteria
- Shipment data obtained; rates computed, not counts
- Trending thresholds compared with the rates found and with the risk file
- Each CAPA read against the ISO 13485 sequence: cause, action, verification, effectiveness
- CAPA outcomes traced to the risk file, the design file, or a field action
- Dates placed on the timeline (guide 15)
§Sources and further reading
A–ZTerms used in this guide
- Complaint
- Any written, electronic, or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, usability, safety, or performance of a device after it is released for distribution.
- MDR
- Medical device report under 21 CFR Part 803: a manufacturer's report to FDA of a death, a serious injury, or a malfunction that would be likely to cause or contribute to one, due within 30 calendar days of awareness, or five work days where remedial action is needed.
- Awareness
- The point at which any employee of the manufacturer learns of an event that may be reportable; for the five-work-day report, an employee with management or regulatory duties. The clock starts here, not at the quality department.
- Malfunction
- The failure of a device to meet its performance specifications or otherwise perform as intended.
- CAPA
- Corrective and preventive action: the process that investigates a problem, finds its cause, acts on it, and verifies that the action worked.
- Root cause
- The underlying reason a problem occurred, as distinct from the symptom reported or the component that failed.
- Trend
- A pattern in complaints or service data over time that may indicate a problem not visible in any single report.
- Reportability decision
- The manufacturer's recorded decision whether a complaint meets the criteria for an MDR, with its reasoning. Required for every complaint, whether or not a report is filed.