How to Read a Complaint File

A complaint file looks like paperwork until you need it to hold up under an inspector’s question, or your own memory, six months after the fact. It has to do two things at once: capture what a customer actually said, close to their own words, and show the reasoning that got you from that complaint to a decision about whether it was reportable.

In brief

A complaint is any written, electronic, or oral communication alleging a deficiency in a device already in distribution — not only the ones that arrive on a formal intake form.
Every complaint needs a documented evaluation of whether it’s MDR-reportable, even the ones you conclude aren’t — the reasoning is what an inspector actually reads.
A single complaint rarely tells you much on its own. What the file is really for is letting the same failure mode get counted the same way twice, so trending catches it the third time.
The file that still reads clearly six months later separates what the customer reported from what your investigation found — collapsing the two into one paragraph is the most common way a complaint file stops being trustworthy.

What has to be in the file

A usable complaint record starts with the intake: device identification and lot or serial number where available, the date of the event, and the complaint as the customer described it, kept close to their actual words rather than pre-translated into your team’s internal vocabulary. From there the file needs a documented decision on whether the complaint was investigated and, if not, a documented reason why not — “no investigation needed” is itself a finding that has to be justified, not a default. The investigation, when one happens, needs its own record of what was examined and what was concluded. None of this is optional paperwork sitting beside the real work; a regulator reading the file back is reconstructing your judgment from exactly these entries, not from what you remember having decided.

How the reportability decision actually gets made

The reportability call — whether the complaint meets the threshold for a Medical Device Report — turns on whether the device caused or contributed to a death or serious injury, or would be likely to if the malfunction recurred; the specifics of that test are covered in how to read a medical device report. What matters for the complaint file itself is that the reasoning behind a “not reportable” determination has to be written with the same care as a “reportable” one. In practice it’s the “not reportable” calls that draw the closest scrutiny in an audit, precisely because there’s no external report to check the reasoning against — the file is the only record that the judgment happened at all. And a complaint that closes as an isolated event needs to be checked against the trend before it closes, since the connection to the risk management file’s post-market data loop is exactly what turns three unremarkable complaints into a signal worth a CAPA.

Where this goes wrong

Recording only what supports the conclusion already reached

An investigation summary that quietly drops the parts of the customer’s original account that don’t fit the chosen determination reads as thin the moment anyone compares it back to the original complaint text.

Treating a “not reportable” decision as needing no documentation

These are usually the ones that draw the closest look in an audit, precisely because there’s no external filing to check the reasoning against.

Losing the connection to trending

Closing complaints one at a time without checking them against the pattern is how the same failure mode gets rediscovered from scratch three separate times instead of triggering a CAPA on the second.

None of this is unique to complaint handling — it’s the same discipline of documented reasoning that runs through a risk management file or a CAPA record. What makes complaint files distinct is that the record starts with someone else’s words, not your own, and the whole file has to stay honest to that origin while still doing the analytical work a regulator expects to see.

Sources & further reading

21 CFR § 820.198 — Complaint Files ecfr.gov
21 CFR Part 803 — Medical Device Reporting ecfr.gov
Regulatory Academy — How to Read a Medical Device Report regulatoryacademy.com
Regulatory Academy — How to Read a Risk Management File regulatoryacademy.com

This essay is provided for general educational purposes and reflects the regulatory landscape as of its publication date. It is not legal, regulatory, or career advice.