Medical Device Complaint Handling and MDR Reporting: A Developer's Guide to 21 CFR 803 and ISO 13485 8.2.2

Picture a support ticket on a Friday afternoon: "Unit shut off halfway through a treatment. Patient fine, restarted it." The agent tags it hardware, the queue sorts it under low priority, and nobody outside support reads it. Five weeks later a quality engineer finds three more tickets like it, decides the shutdowns are a reportable malfunction, and checks the date on the first one. The 30-day deadline passed a week ago.

Medical device complaint handling is the process that stops that week from happening. Under FDA's Quality Management System Regulation (QMSR), a manufacturer must receive, review and evaluate every complaint under ISO 13485:2016 clause 8.2.2, keep the records 21 CFR 820.35 lists, and decide for each one whether it is a Medical Device Report (MDR) under 21 CFR Part 803. If your team builds the CRM, ticketing integration or quality system that holds those complaints, the deadline lives in your code.

What do the complaint handling rules require?

Five rules shape a device complaint system in the US:

Rule	What it requires	What you build
ISO 13485 8.2.2	Documented complaint handling: receive, record, evaluate, investigate, decide on reporting	A single intake for every channel, with a status workflow
21 CFR 820.35(a)	Record content for complaints that are investigated or reportable	Required fields: device name, date received, UDI, complainant contact, nature of complaint, corrective action, reply
21 CFR 803.17	Written MDR procedures, including a system to decide if an event is reportable	A reportability decision step on every complaint, with reason and reviewer
21 CFR 803.50	Report deaths, serious injuries and qualifying malfunctions within 30 calendar days	Deadline tracking from the awareness date
21 CFR 803.53	5-work-day report when an event needs remedial action to prevent unreasonable risk of substantial harm, or when FDA asks	A second, shorter clock and an escalation path

Section 820.35(a) also lets you skip a new investigation when you already investigated a similar complaint, as long as you record the justification. Give that its own field.

When does the MDR clock start?

The clock starts when your company becomes aware of the event, not when quality reads the ticket. For a manufacturer, Part 803 treats the company as aware when any employee gets information that reasonably suggests a reportable event. A support agent, a field service engineer or a sales rep reading a customer email all start the clock.

That one definition drives the architecture:

• Stamp aware_at at intake, on the first channel that received the information, and never let a later edit change it.
• Route every new complaint to a reportability decision within days, not weeks.
• Show the deadline on the ticket from the first minute.

from dataclasses import dataclass, field
from datetime import date, datetime, timedelta

def add_work_days(start: date, n: int) -> date:
    d = start
    while n:
        d += timedelta(days=1)
        if d.weekday() < 5:  # Mon-Fri; plug in your holiday calendar here
            n -= 1
    return d

def mdr_due(aware: date, five_day: bool = False) -> date:
    """21 CFR 803.50: 30 calendar days. 803.53: 5 work days."""
    return add_work_days(aware, 5) if five_day else aware + timedelta(days=30)

@dataclass
class Complaint:
    id: str
    device_name: str
    udi: str | None
    received_at: datetime           # 820.35(a)(2)
    aware_at: datetime              # set once at intake, never edited
    complainant: dict               # name, address, phone (820.35(a)(4))
    details: str                    # nature and details (820.35(a)(5))
    reportable: bool | None = None  # 803.17 decision
    decision_reason: str = ""
    decided_by: str = ""
    linked_capa: str | None = None
    history: list = field(default_factory=list)  # append-only audit trail

c = Complaint("CS-4471", "TheraPulse 2", "(01)00812345678901", datetime(2026, 11, 6, 15, 10),
              datetime(2026, 11, 6, 15, 10), {"name": "Clinic A"}, "Unit shut off mid-treatment")
assert mdr_due(c.aware_at.date()) == date(2026, 12, 6)
assert mdr_due(c.aware_at.date(), five_day=True) == date(2026, 11, 13)

Treat a "not reportable" decision as data too. An investigator reading your complaint file wants to see who decided, when, and why, for the complaints you did not report as much as for the ones you did.

Which 483s cite complaint handling and MDR reporting?

Investigators cite all three parts of the process, before QMSR and since, and each kind of failure maps to a software decision. Every example below links to the public observation list in the Atlas Form 483 directory.

Late or missing reports.

• Biofilm, Vista, California, May 2026: 1 observation, a death or serious injury report under 803.50(a)(1).
• Biowave, Westport, Connecticut, May 2026: 6 observations, opening with malfunction reports under 803.50(a)(2).
• Abbott Diabetes Care, Alameda, California, October 2025: 2 observations, one of them a malfunction report under 803.50(a)(2).

No system to decide reportability.

• Aus Systems, Allenby Gardens, Australia, June 2026: 2 observations, including no written MDR procedures (803.17).
• Magnatone Hearing Aid, Casselberry, Florida, July 2025: 14 observations, including no system for determining MDR events (803.17(a)(2)) and complaint procedures (820.198(a)).

Complaint records that don't hold up.

• Lambda, Brendola, Italy, May 2026: 1 observation, complaint handling procedures lacking required elements (8.2.2).
• Light Age, Somerset, New Jersey, May 2026: 18 observations, including complaint handling records not maintained (8.2.2).
• Philips North America, Bothell, Washington, November 2025: 1 observation, complaint procedures under 820.198(a).
• Boston Scientific, Saint Paul, April 2025: 9 observations, including MDR evaluation codes (803.52(f)(6)) and complaint procedures.

A single-observation 483 can carry this finding. Biofilm, Lambda and Philips each received one observation, and it was the complaint or MDR process.

Why does feedback now connect to risk management?

ISO 13485 clause 8.2.1 asks you to use feedback, complaints included, as an input to risk management. Fresenius Medical Care Renal Therapies Group in Waltham received an observation in June 2026 for feedback not used as input into risk management, and LeMaitre Vascular in North Brunswick got the same one that month.

In code, that means a complaint record needs a path out of the support system: a link to the hazard it relates to in the risk file, and a link to the CAPA it triggered. If your complaint data lives in a ticketing tool and your risk file lives in a spreadsheet, build the export. The guide to corrective and preventive action covers what the CAPA side expects to receive.

A complaint handling checklist for engineering teams

1. One intake for every channel: support, email, phone, field service, sales, social. Each creates the same record.
2. aware_at set at intake and locked.
3. A reportability decision with reason, reviewer and date on every complaint.
4. A 30-day and a 5-work-day clock, visible on the record, with alerts before the deadline.
5. All 820.35(a) fields required before a complaint can close.
6. Links to the investigation, the CAPA and the risk file entry.
7. An append-only audit trail on every field. Our post on 21 CFR Part 11 audit trail requirements covers the design, and the audit trail tests used in computerized system validation list what a reviewer will try.
8. Validation scaled to risk. The deadline logic and the reportability step are high process risk; the dashboard colours are not. See computer software assurance for developers.

FDA's wider expectations for device makers sit in FDA's guidelines for medical device manufacturers.

FAQ

What counts as a complaint for a medical device?
A complaint is any written, electronic or oral communication that alleges a deficiency in a device's identity, quality, durability, reliability, usability, safety or performance after release. A support ticket, a sales email or a phone call can each be a complaint.

What are the MDR reporting deadlines?
Under 21 CFR 803.50, a manufacturer must report a death, serious injury or reportable malfunction within 30 calendar days of becoming aware of it. Under 803.53, a 5-day report is due within 5 work days when the event needs remedial action to prevent an unreasonable risk of substantial harm, or when FDA requests one in writing.

When does a manufacturer become aware of an MDR event?
Part 803 treats a manufacturer as aware when any employee acquires information that reasonably suggests a reportable event occurred. The clock does not wait for the quality team to review the complaint.

What must a complaint record contain under QMSR?
For complaints that are investigated or reportable, 21 CFR 820.35(a) requires the device name, the date received, any UDI or UPC, the complainant's name, address and phone number, the nature and details of the complaint, any correction or corrective action, and any reply to the complainant.

Does complaint handling software need validation?
Yes. Software that a manufacturer uses for complaint handling and MDR decisions is quality system software, and ISO 13485 clause 4.1.6 requires validation for its intended use. FDA's computer software assurance guidance lets you scale that testing to risk.

---

I work on Atlas Compliance, which tracks FDA inspections and Form 483 observations for pharma and medical device quality teams. The FDA inspection directory is free to browse.