Medical Device Reporting (MDR)

This topic is part of the SG Systems Global post‑market surveillance, complaint handling & regulatory reporting glossary.

Updated December 2025 • 21 CFR Part 803 – Medical Device Reporting, MedWatch Form, QMS, CAPA, Deviation / NC, RCA, Data Integrity, DHR, FDA, Medical Device QMS

Medical Device Reporting (MDR) is the US system that forces manufacturers, importers and certain healthcare facilities to tell FDA when their device kills somebody, seriously injures them, or malfunctions in a way that could plausibly do so if it happens again. It sits in 21 CFR Part 803 and is one of the core post‑market obligations for anyone selling medical devices in the US.

Done well, MDR is an early‑warning radar: events flow in quickly, are investigated properly, and feed design changes, labeling updates, field actions and risk management. Done badly, it’s a chaotic mix of late reports, under‑reporting, vague narratives and missing follow‑up that eventually shows up in inspection findings, warning letters and “how did you miss this?” questions from FDA.

“If you only discover your device’s problems when FDA pulls your MAUDE history, you’re not using MDR as a safety system — you’re waiting for a public post‑mortem.”

1) What Medical Device Reporting (MDR) Actually Is

Medical Device Reporting is FDA’s mechanism for collecting post‑market safety data about devices already on the US market. Under 21 CFR 803, it obliges:

• Manufacturers to report device‑related deaths, serious injuries and certain malfunctions.
• Importers to report deaths and serious injuries to FDA and the manufacturer, and malfunctions to the manufacturer.
• Device user facilities (hospitals, nursing homes, certain outpatient facilities) to report deaths to FDA and the manufacturer, and serious injuries to the manufacturer (or FDA if the manufacturer is unknown).

MDR is not a “nice to have” or a marketing consideration. It’s a legal requirement tied to enforcement powers. Failing to report, reporting late, or filing low‑quality MDRs can and does show up in Form 483 observations, warning letters and, in ugly cases, consent decrees.

2) MDR vs “MDR” (the European Regulation)

There’s a dangerous naming collision in medical devices:

• In the US, MDR = Medical Device Reporting under 21 CFR 803.
• In the EU, MDR = Medical Device Regulation (Regulation (EU) 2017/745), the entire device framework.

They are not the same thing. US MDR is one specific post‑market reporting process inside the wider FDA regulatory system. EU MDR is the entire regulatory regime for CE‑marked devices. In practice, global manufacturers must run both: US MDR for FDA, EU vigilance and trend reporting for Europe, and often additional country‑specific schemes on top.

If your team uses “MDR” without context, you’re one misunderstanding away from people talking confidently about completely different obligations. Fix the language in your QMS and training so everyone knows which MDR is on the table.

3) Who Must Report and What They Owe

Under 21 CFR Part 803, the obligations split like this:

• Manufacturers
  • Report to FDA device‑related deaths, serious injuries and certain malfunctions.
  • Submit most MDRs within 30 calendar days of becoming aware of the reportable event.
  • Submit 5‑day MDRs for events requiring remedial action to prevent unreasonable risk of substantial harm to public health, or when FDA specifically requests 5‑day reporting for a pattern of events.
• Importers
  • Report deaths and serious injuries to both FDA and the manufacturer within 30 days.
  • Report malfunctions to the manufacturer within 30 days.
• Device user facilities
  • Report device‑related deaths to FDA and the manufacturer no later than 10 work days after becoming aware.
  • Report serious injuries to the manufacturer within 10 work days (or to FDA if the manufacturer is unknown).
  • Submit annual summaries of MDRs to FDA.

On top of mandatory reporters, FDA actively encourages voluntary reports from healthcare professionals, patients and consumers through the MedWatch program (Form 3500).

4) What Counts as an MDR‑Reportable Event

The MDR rule uses a deceptively simple test: you must report when information “reasonably suggests” that a device may have caused or contributed to a death or serious injury, or has malfunctioned in a way that would be likely to cause or contribute to a death or serious injury if it recurred.

That covers three main event types:

• Death – where a device failure, use error, or combination of factors may have contributed.
• Serious injury – life‑threatening events, permanent impairments, or events requiring medical/surgical intervention to prevent permanent harm.
• Malfunction – failures or incorrect performance that, if they happened again, could cause death or serious injury, even if this specific occurrence did not.

Key point: you’re not required to prove causality beyond doubt before reporting. MDR is deliberately biased toward “when in doubt, report and investigate,” not “wait until we’re absolutely sure.” Trying to argue “we’re unconvinced” as a reason for no MDR when your own complaint file hints otherwise is how you end up in FDA’s slides on bad case studies.

5) Timelines, Report Types and eMDR

MDR isn’t just “file something at some point.” FDA expects specific timelines and formats:

• 30‑day reports
  • Standard MDRs for deaths, serious injuries and reportable malfunctions (manufacturers and importers).
• 5‑day reports
  • For events requiring remedial action to prevent unreasonable risk of substantial harm to public health.
  • For patterns where FDA has formally requested 5‑day reporting.
• 10‑work‑day reports
  • User facility time limit to report deaths to FDA and manufacturers and serious injuries to manufacturers.
• Supplemental / follow‑up reports
  • When new, relevant information becomes available after an initial MDR; typically due within 30 days of obtaining the new information.

Manufacturers and importers must now submit MDRs electronically via FDA’s eMDR system using the electronic equivalent of Form 3500A. Paper MDRs are mostly a thing of the past except for granted exemptions. User facilities still have a bit more flexibility but are also moving towards electronic submission.

6) Forms, Databases and Visibility (MedWatch, MAUDE, etc.)

MDR lives alongside several visible FDA tools:

• Form FDA 3500A – mandatory reporting form for manufacturers, importers and user facilities; submitted electronically under eMDR.
• Form FDA 3500 – voluntary reporting form used in the MedWatch program.
• MAUDE database – FDA’s public Manufacturer and User Facility Device Experience database, where MDRs end up and where journalists, competitors, plaintiffs’ attorneys and regulators go hunting.

Internal teams sometimes forget that MDRs are effectively public. Sloppy narratives, inconsistent classifications and “we blame the user without evidence” language are not just a regulatory risk — they are searchable reputational risk.

7) MDR vs Complaints, NCs and CAPA

MDR sits on top of your core QMS processes, not next to them. A defensible design looks like this:

• Every field report (complaint, service ticket, adverse event) enters a controlled complaint / NC workflow.
• The complaint process evaluates:
  • Is this even a complaint under the regulations?
  • If yes, is it MDR‑reportable under 21 CFR 803?
  • Does it trigger CAPA, labeling change, design change, or field action?
• The MDR process then pulls from the complaint file: device details, event description, investigation results, and corrective actions.

FDA will absolutely compare your internal complaint universe to your MDR history. If you have dozens of internal complaints that look MDR‑like and only a handful of MDRs, you better have rock‑solid rationales for non‑reporting. “We didn’t think it crossed the line” without documented risk‑based rationale is not rock‑solid.

8) MDR Data Requirements and Recordkeeping

21 CFR 803 defines not just timelines but the content and records you must maintain. At a minimum, MDR files (and the underlying complaint files) must capture:

• Who you are – manufacturer/importer/facility details, contact person.
• Device identity – brand / trade name, model/catalog number, UDI, serial/lot/batch, 510(k)/PMA number where applicable.
• Patient and event details – what happened, clinical outcome, date, and whether death/serious injury occurred.
• Device evaluation – whether the device was returned, what testing/investigation you performed, and what you concluded.
• Corrective actions – whether you took remedial actions (field corrections, recalls, design changes, labeling changes).
• Follow‑up – any new information submitted via supplemental MDRs.

Under 21 CFR 803.18, manufacturers and importers must also maintain MDR event files — basically complaint files containing MDR‑relevant documentation and correspondence — for at least two years from the date of the event or for the expected life of the device, whichever is longer. Those files must be easily retrievable during inspections.

9) Risk Management, Field Actions and Design Changes

MDR is one of the main triggers for design and field‑safety decisions. A credible process ties MDR tightly to:

• Risk management (QRM) – MDR events feed back into your hazard analyses and risk files; new failure modes or higher‑than‑expected rates of known hazards must be reflected in risk assessments and controls.
• Field safety actions – serious MDR patterns often drive corrections and removals under 21 CFR 806, recalls, or customer notifications.
• Design and labeling changes – recurring MDR failure modes may demand design modifications, manufacturing changes or upgraded warnings/IFU.
• Premarket impact – in some cases, significant design changes driven by MDR may require new or updated submissions (e.g. additional FDA clearances or approvals).

What regulators hate seeing is MDRs treated as isolated paperwork: serious signals in MAUDE, but a risk file and design history that look untouched for years. If MDR is not visibly feeding risk and design, your “risk‑based” story falls apart fast.

10) Data Integrity and MDR – No Fantasy Narratives

MDR is only as good as the data behind it. That pulls data integrity squarely into the discussion:

• Attributable – complaint triage, MDR assessments and submissions must be traceable to named individuals; shared logins and unsigned assessments are red flags.
• Contemporaneous – dates of awareness, investigation and submission matter; backdating complaints to hit MDR deadlines is both obvious and unacceptable.
• Complete – MDR narratives should reflect the actual state of knowledge, including known device issues and relevant prior events, not a carefully edited highlight reel.
• Original – avoid uncontrolled spreadsheets, offline notes and “shadow logs” that never make it into the official QMS.
• Accurate – classifications (death vs serious injury vs no injury), device IDs and timelines must match what’s in your DHR and complaint system.

FDA has seen every shortcut: missing complaints, “lost” emails, copied‑and‑pasted narratives, and optimistic under‑classification. It’s safer (and frankly easier) to build MDR into disciplined, electronic workflows than to clean up after creative record‑keeping.

11) Common MDR Failure Modes and Inspection Themes

When FDA publishes warning letters, the same MDR problems come up repeatedly:

• Failure to report – clear reportable events in complaint files that never generated MDRs.
• Late reporting – awareness dates manipulated or ignored to avoid 30‑day and 5‑day breaches.
• Weak investigations – MDRs filed with “no root cause identified” while internal emails admit recurring design or process issues.
• Poor linkage to CAPA – serious MDR patterns with no corresponding systemic actions.
• Inconsistent data – MDR narratives that conflict with complaint data, DHRs or field‑corrective‑action records.

Inspectors will usually sample complaints and trace them forward into MDRs, CAPAs and design risk files. If that trace looks random, your MDR process is on borrowed time.

12) Implementation Roadmap – Making MDR Defensible

For a manufacturer trying to get MDR under control, a pragmatic roadmap looks like this:

• 1) Map your actual flows. How do complaints, service calls, emails and distributor reports really enter your system today? Where are the unofficial side channels?
• 2) Standardise intake and triage. Force everything through a single complaint / event intake process with defined questions, including “MDR‑reportable? yes/no and why.”
• 3) Hard‑link MDR decisions to complaints. Build your process so MDR assessments are made inside the complaint record, not on a separate spreadsheet that can go missing.
• 4) Codify the “reasonably suggests” test. Use clear criteria, examples and risk‑based guidance for when to report; remove as much subjectivity as possible.
• 5) Industrialise timelines. Use electronic workflows, dashboards and alerts to track 5‑day/30‑day/10‑day clocks; don’t rely on someone’s Outlook reminders.
• 6) Connect MDR to CAPA and change control. Ensure serious or recurring MDR‑related issues automatically trigger systemic reviews, not just case‑by‑case firefighting.
• 7) Train with real cases. Use past borderline events and inspection findings as training examples; “soft” MDR decisions should be stress‑tested, not quietly filed.

The goal is simple: when FDA asks, “Show us how you decided what to report, how fast, and what you did with the information,” you can demonstrate a clear, electronic trail rather than pulling together an explanation on the spot.

13) What This Means for V5

On the V5 platform, Medical Device Reporting (MDR) is not a bolt‑on spreadsheet — it’s an integrated part of how complaints, events, batches, devices and regulatory submissions hang together across V5 QMS, V5 MES, V5 WMS and V5 Connect API.

• V5 Solution Overview
  • Provides a single data model where complaints, DHRs, batches, lots, equipment and customers are first‑class objects, not disconnected tables.
  • Makes MDR decisions traceable across the same backbone that already stores manufacturing, quality and warehouse events.
• V5 QMS – Quality Management System
  • Runs structured complaint handling, NC, deviation and CAPA workflows that include explicit MDR assessments and outcomes.
  • Captures MDR decision logic (“reportable / not reportable / why”) inside the complaint record with required fields and e‑signatures.
  • Links MDR‑relevant events directly to associated CAPAs, risk files and change controls so systemic fixes are visible, not scattered.
• V5 MES – Manufacturing Execution System
  • Provides the detailed DHR and electronic batch records behind MDR cases: exact device IDs, lots, parameters, equipment, operators and in‑process checks.
  • Allows investigations to pull execution history, alarms, IPC data and deviations straight into the MDR case file without manual re‑typing.
  • Supports hard‑gating of production and release when specific MDR‑driven CAPAs or changes are required before continued manufacturing.
• V5 WMS – Warehouse Management System
  • Provides full lot / UDI / shipment genealogy to answer “where else did this device or lot go?” during MDR‑driven investigations.
  • Supports targeted quarantines and holds on affected inventory when MDR cases escalate to field actions or recalls.
• V5 Connect API
  • Integrates with ERP, CRM, LIMS and regulatory gateways so complaint and MDR data can move through validated, auditable channels.
  • Supports automated population of eMDR payloads from V5 QMS data, reducing manual copy‑paste and transcription risk.
  • Allows customer portals and service systems to feed complaints into V5 in a controlled way instead of proliferating side databases.

Net result: on V5, MDR is the visible tip of a connected system. When an MDR case appears, you can drill down to the exact device history and up to the CAPAs, risk evaluations and field actions it triggered — all on one platform, with one audit trail.

FAQ

Q1. Is every complaint automatically an MDR?
No. Every MDR starts as a complaint or similar event, but not every complaint is MDR‑reportable. Many complaints involve minor issues, cosmetic defects or non‑serious events. The key test is whether the information reasonably suggests a device may have caused or contributed to a death or serious injury, or has malfunctioned in a way that could cause such harm if it recurs.

Q2. Do we need “proof” before submitting an MDR?
No. MDR uses a “reasonably suggests” threshold, not courtroom‑level proof. You must report even if investigation is ongoing, then submit supplemental MDRs as you learn more. Waiting for absolute certainty is a classic way to blow the 5‑day and 30‑day clocks.

Q3. How does MDR relate to CAPA and field actions?
MDR is one of the main signal sources for systemic issues. Serious or recurring MDRs should feed CAPA, risk re‑assessment and, where appropriate, field corrections or recalls. If your MDR log shows the same failure mode repeatedly with no CAPA or design change, expect hard questions from FDA.

Q4. What’s the difference between mandatory MDR and voluntary MedWatch reports?
Mandatory MDRs are legally required submissions from manufacturers, importers and user facilities using Form 3500A via eMDR. Voluntary MedWatch reports (Form 3500) come from healthcare professionals, patients and consumers. Both feed FDA’s safety surveillance, but only mandatory reporters are on the hook for specific timelines and recordkeeping obligations.

Q5. Can we combine MDR obligations with EU vigilance and other global reporting?
You can design one global safety and complaint process that feeds multiple regulators, but the underlying rules differ (US MDR vs EU vigilance vs other national schemes). The trick is to centralise intake, triage and investigation, then map each case to the specific reporting criteria and timelines for the jurisdictions where the device is on the market.

Related Reading
• US Device Regulations: 21 CFR Part 803 – MDR | 21 CFR 820 / QMSR | 21 CFR 806 – Corrections & Removals
• Quality & Post‑Market: Quality Management System (QMS) | Deviation / Nonconformance | CAPA | Root‑Cause Analysis | Data Integrity
• Records & Traceability: Device History Record (DHR) | Traceability | Record Retention & Archival
• V5 Platform: V5 Solution Overview | V5 QMS | V5 MES | V5 WMS | V5 Connect API