21 CFR Part 803

This glossary term is part of the SG Systems Global regulatory & operations guide library.

Updated December 2025 • 21 CFR Part 803, Medical Device Reporting (MDR), mandatory adverse event reporting, reportability assessment, 30-day reports, 5-day reports, supplemental reports, user facility reporting, importer reporting, eMDR, Form 3500A data integrity, MDR event files & retention, complaint-to-MDR linkage • Medical Devices (USA)

21 CFR Part 803 is the U.S. FDA’s Medical Device Reporting (MDR) regulation: the mandatory framework that requires device manufacturers, importers, and device user facilities to report certain device-related adverse events and product problems to FDA (and, in some cases, to each other) within defined timelines. In plain language, Part 803 is the rule that turns adverse-event awareness into a regulated clock, a documented decision, and a traceable submission—backed by procedures, event files, and retention requirements.

Most teams treat MDR as “a form” and then act surprised when they get burned. Part 803 is not a form. It is an operational system requirement: you must detect potential reportable events quickly, evaluate reportability consistently, lock the “become aware” date, gather what FDA considers “reasonably known” information, submit on time, and preserve an inspection-ready evidence trail. If any of those steps are informal, MDR becomes a recurring failure mode: late reports, under-reporting of malfunctions, shaky causality logic, missing device identifiers, sloppy narratives, and weak linkage between complaints, investigations, CAPA, and manufacturing truth.

In a modern execution-and-quality stack, MDR readiness is not isolated inside Quality. MDR depends on cross-functional evidence: complaint intake, service records, UDI/serial/lot traceability, nonconformance and rework history, and the ability to scope affected product quickly when an event suggests systemic risk. That’s why Part 803 connects naturally to execution integrity concepts like Manufacturing Execution Integrity, evidence depth and traceability terms like Work Order Execution Traceability, and governance controls like Segregation of Duties in MES. If the “truth” of how a unit was built is ambiguous, your MDR investigation and narrative will be ambiguous too—and ambiguity is not a compliance strategy.

“MDR isn’t paperwork. It’s a clock—and your system either starts it on time or it doesn’t.”

1) What Part 803 is really doing (and what it is not)

Part 803 is FDA’s mechanism for turning postmarket signals into structured, time-bound regulatory intelligence. FDA does not need perfect causality to require reporting; it needs sufficient information that “reasonably suggests” a device may have caused or contributed to a death or serious injury, or (for manufacturers and importers) that a malfunction would be likely to cause or contribute to a death or serious injury if it recurred. The regulation is intentionally built for imperfect real-world information: you report when the threshold is met, then you investigate, follow up, and supplement as necessary.

Part 803 is not a substitute for good engineering, and it is not a catch-all “adverse event process” for every product problem. It is a mandatory reporting pathway with explicit timelines, recipients, and recordkeeping expectations. A company can have excellent product safety culture and still fail MDR if it cannot prove timeliness, consistency of reportability determinations, and completeness of required data fields. Conversely, a company can submit MDRs on time and still have serious product quality issues; MDR compliance does not equal product quality, but weak MDR compliance reliably indicates weak governance.

Operationally, Part 803 behaves like a controlled decision engine: incoming event → triage → reportability decision → regulated submission path → preservation of evidence and rationale. The work is repetitive, high-consequence, and easy to get subtly wrong, which is why MDR should be treated like an engineered workflow with audits, metrics, and segregation of duties rather than a heroic manual effort.

2) Why MDR fails in real companies

MDR failures rarely happen because people refuse to comply. They happen because the system makes compliance ambiguous, slow, or politically expensive. In most organizations, the first failure mode is timing: the “become aware” date is not captured when awareness actually occurs, or it is captured inconsistently across functions, or it is treated as negotiable. The second failure mode is classification: the organization under-reports malfunctions by silently redefining “likely to cause or contribute” as “already caused harm,” which is not the MDR standard. The third failure mode is evidence: device identifiers, lot/serial/UDI, service history, and manufacturing genealogy are scattered, so investigations and narratives become shallow.

There is also a cultural trap: teams fear “over-reporting” because they assume MDR volume is itself a risk. The real risk is inconsistent decision logic and late reporting. FDA can tolerate high reporting volume when it is consistent and well-supported. FDA does not tolerate stories that change, missing rationales, and clocks that start late. A mature MDR program is not about minimizing reports; it is about making the reportability decision defensible and repeatable.

3) What “MDR reportable event” means in practice

In practice, “reportable” is a threshold test applied to imperfect data. The test is not “prove the device caused the outcome.” The test is whether the information you have reasonably suggests the device caused or contributed, or whether a malfunction would likely cause or contribute to serious harm if it recurred. That wording is why MDR is a system problem: your organization must define what “reasonably suggests” means, who is qualified to make medical judgment when required, what evidence is required to support a “not reportable” decision, and how you prevent hindsight bias from rewriting decisions after additional facts appear.

For manufacturers and importers, malfunctions are the most commonly mishandled category. Teams often treat malfunctions as “service issues” unless someone was harmed. That logic is backwards under Part 803. A malfunction can be reportable because its recurrence could plausibly cause death or serious injury—even if the specific incident did not. That’s exactly the point: FDA uses malfunction reporting to see emerging risk patterns before they become injury clusters.

Reportability is also influenced by the device’s intended use and the patient population. The same failure mode can have different severity implications depending on the device. Your MDR system should therefore incorporate device family context (risk class, intended use, known hazards) into the decision workflow. Otherwise, you will oscillate between over-reporting low-risk anomalies and under-reporting high-risk malfunctions because the team lacks shared context.

4) Key definitions that drive reportability decisions

MDR programs get into trouble when teams “kind of know” the definitions. Part 803 forces precision. The goal is not legal trivia; the goal is consistent decisions and defensible rationales.

The easiest way to keep definitions aligned is to implement a decision workflow that forces structured inputs: outcome category, device role, malfunction description, recurrence severity logic, and a recorded rationale for “not reportable.” Free-text-only decisions will drift across reviewers and across time, and drift is the enemy of defensibility.

5) Who reports what to whom and when

The reporting obligations differ by reporter type. Your system should not treat “MDR” as a single monolith; it should explicitly encode obligations for manufacturers, importers, and user facilities, including the recipient(s) and the timeline. The table below is a practical operational summary.

The compliance reality is that these timelines create multiple concurrent clocks (especially for manufacturers): the initial awareness clock, the remedial-action clock (when applicable), and the supplemental-information clock. If your workflow doesn’t track these explicitly, you will either miss deadlines or burn time arguing about which date “counts.”

6) The MDR clock and the “become aware” control point

The “become aware” date is the single most important control point in an MDR program because it is the anchor for timeliness. In a well-designed system, the moment awareness enters the organization, the system creates an event record, stamps an awareness date, and routes the record into triage. In a weak system, awareness is treated as a conversational concept and is later reconstructed (“I think we heard about it last week”), which creates immediate vulnerability in an inspection.

Practically, “awareness” often enters through one of five channels: customer complaint, service call, distributor communication, literature/social media, or internal testing/trending. If any channel is not connected to the MDR workflow, the organization will not detect its own awareness consistently. This is why event-driven design matters: every inbound signal that could reasonably suggest a reportable event must be able to trigger the MDR triage workflow automatically, even if the signal is incomplete at first contact.

There is a second clock nuance that frequently surprises teams: the five-day reporting requirement is not “five days from the event,” it is five work days after awareness of a qualifying trigger. If your process requires a committee meeting to decide whether remedial action is necessary, you must still be able to show when the organization became aware of the event and when the decision point occurred, with audit trails that make it obvious you are not backdating decisions.

7) 30-day, 5-day, and supplemental reports

Part 803 effectively defines three operational “report types” you must control: initial (often called 30-day) reports, expedited (5-day) reports for specific circumstances, and supplemental/follow-up reports when new required information becomes available. The most important discipline is to treat these as workflow states with explicit transitions, not as ad hoc activities performed by email.

30-day reports are the baseline pattern for manufacturers and importers: once you become aware of information that reasonably suggests reportability, you report within the required window. The hard part is not the form; it is locking the reportability determination, building a coherent narrative, and ensuring the required device identifiers and event facts are not missing.

5-day reports exist for situations where public health risk is higher or FDA specifically requests expedited reporting. The operational mistake is to treat the five-day path like “a faster 30-day.” It is a different path: it should have pre-assigned roles, pre-defined escalation rules, and a “minimum viable submission” mindset that captures what is required now while preserving the ability to supplement when additional facts are learned.

Supplemental/follow-up reporting is where defensibility is won or lost. Weak programs either never supplement (because it is operationally painful) or they supplement in ways that look like narrative rewriting. Strong programs treat supplemental reporting as a controlled mechanism to add new, changed, or corrected information while preserving the original decision logic and maintaining traceable report identifiers.

8) MDR procedures and MDR event files

Part 803 is explicit that MDR compliance requires documented procedures and retained evidence. In operational terms, you need two things that are inspection-ready at all times: (1) written MDR procedures that define how your organization receives information, evaluates it, decides reportability, submits, and follows up; and (2) MDR event files that preserve the event record, the rationale, and the supporting evidence for the required retention period.

Recordkeeping is not a clerical detail. It is how you prove that decisions were made contemporaneously, by qualified roles, with consistent logic. If you cannot show the MDR event file for a sample case quickly, your program will be treated as unreliable, and the inspection will expand.

Retention expectations are not optional. MDR event files must be retained for defined time periods, which in practice means your system must enforce retention, protect integrity (audit trails), and prevent silent deletion or unlogged edits. A mature approach also links MDR event files to complaint files and investigations so the same evidence does not have to be copied into multiple uncoordinated repositories.

9) Data requirements and Form 3500A mapping

The MDR submission is structured data plus narrative. The most common execution failure is treating it like narrative-only. In reality, a large portion of MDR defensibility is simply having the required structured fields present and consistent: patient outcome, event dates, device identifiers, manufacturer information, reporter information, and (when applicable) device evaluation results and corrective actions.

Data completeness is why MDR needs integration to manufacturing and service systems. If the complaint system cannot reliably capture device identity, and the execution systems cannot reliably produce genealogy evidence, MDR narratives will remain “best effort” instead of defensible records.

10) “Reasonably known” information and investigation depth

For manufacturers, Part 803 makes a key point that many teams ignore: you are expected to submit all information that is “reasonably known” to you, which includes information you can obtain by contacting the reporter, information in your possession, and information you can obtain by analysis/testing/evaluation of the device. That is a practical definition of expected diligence. If you do not attempt to obtain missing information, your file will look thin, and your report will look careless.

This is where MDR intersects with engineering discipline. You do not need perfect certainty to report, but you do need to show that you took reasonable steps to understand the event, evaluate the device, and preserve evidence. If information is missing, you need to show why it is missing and what steps were taken to obtain it. In mature systems, these are structured fields: “contact attempt log,” “device return status,” “evaluation performed,” “evaluation pending reason,” and “supplemental submission required.”

Operationally, the rule of thumb is simple: if you have enough information to decide reportability, you almost always have enough information to start the investigation workflow. MDR becomes safer (and easier) when investigation is not treated as a separate downstream project, but as the work that stabilizes and justifies the MDR record over time.

11) Complaint handling, CAPA, and MDR: one system, not three

Companies get into compliance trouble when they operate three parallel workflows: (1) complaint handling, (2) MDR reporting, and (3) CAPA. In reality, these are different views of the same underlying truth. A complaint is the inbound signal; MDR is the regulatory reporting decision and submission; CAPA is the systemic corrective response when the signal indicates process or design weakness.

Part 803 essentially requires that the MDR decision be traceable to complaint evaluation logic. If a complaint is closed without an MDR assessment, you cannot credibly claim the program is controlled. If MDR is filed but the complaint record lacks key evidence, the submission will look ungrounded. If CAPA is opened but not linked to the MDR/complaint, your corrective action record will be missing the forcing function that justified it.

A practical governance pattern is to treat “Reportability Assessment” as a mandatory stage in complaint workflow closure and to treat “MDR Submitted” as a linked state with report identifiers, dates, and follow-up tasks. That creates a single evidence chain rather than three partially-overlapping stories.

12) Traceability and genealogy: making MDR narratives defensible

MDR narratives are only as strong as the traceability behind them. When an event involves a specific unit, FDA expects that you can identify that unit, its configuration, its manufacturing history, and (when relevant) its service history. When an event suggests systemic risk, FDA expects you can scope potentially affected product and explain what you did with that scope (additional investigation, field action, targeted communication, etc.).

This is where execution-layer evidence becomes a compliance asset. If you can link a complaint to a UDI/serial/lot, and then link that identity to execution-level genealogy, your investigation stops being guesswork. You can answer: which lots of a component were used, which work orders touched the unit, which rework nodes occurred, which process deviations happened, and whether similar devices share the same risk conditions. That makes your MDR determination and your follow-up actions measurable instead of subjective.

Traceability also prevents a common failure: “we can’t find the unit, so we can’t investigate.” You may not always be able to recover a device, but you should still be able to investigate manufacturing and distribution truth. A strong MDR system therefore treats manufacturing order traceability and UDI linkage as core inputs to the MDR event file, not as optional attachments.

13) Electronic MDR (eMDR) and submission integrity

MDR submission is not only about content; it is also about submission integrity. Electronic reporting requirements mean you must be able to generate consistent structured data and preserve what was submitted, when it was submitted, and by whom. From a governance standpoint, this looks like “submission as a controlled action” with role authorization, audit trails, and prevention of post-submission edits that rewrite history.

The practical requirements are straightforward: your system should store a submission package, confirmation/acknowledgment artifacts, and submission identifiers; it should enforce that submissions can only be performed by authorized roles; it should lock critical timestamps; and it should ensure that follow-up information becomes supplemental reporting rather than retroactive editing of the initial record.

This is also where segregation of duties becomes real. The person drafting an MDR should not be the person who unilaterally approves submission when risk is high. Role-based workflows reduce both error and the appearance of impropriety. When FDA sees a clean separation between data entry, medical/technical judgment, and final submission authority, MDR programs look controlled instead of improvised.

14) Trending, remedial action, and when MDR becomes a forcing function

Part 803 is not only reactive reporting; it also creates pressure for proactive control. When malfunction reports cluster, your organization is expected to notice. When the same hazard appears repeatedly, you are expected to act. And when action is required to prevent unreasonable risk of substantial harm to public health, MDR can move into expedited reporting territory.

Operationally, this means your MDR system should not be isolated from trending. You should be able to trend by device family, failure mode, complaint code, adverse event code, supplier lot, production line, software version, and service modality. Trending is not optional if you want to prevent the “we didn’t realize this was systemic” outcome that turns an MDR program into a crisis response.

Mature programs treat MDR as both an external reporting system and an internal risk telemetry system. The reporting obligation is the floor. The control value comes from making signals visible fast enough to drive CAPA, field actions, and design/process corrections before harm clusters escalate.

15) Inspection readiness: what gets tested and how findings happen

FDA inspections do not primarily test whether you can fill out a form. They test whether your MDR system behaves like a controlled system. Inspectors typically sample complaint files, service records, and investigations and then ask: was an MDR assessment performed, was the determination defensible, were timelines met, and is the MDR event file complete and retrievable? They also look for patterns: repeated late reporting, inconsistent malfunction logic, or repeated “not reportable” rationales that look like policy rather than judgment.

Findings often come from mismatches. A complaint says “patient hospitalized,” but the MDR decision says “not serious.” A service record documents a failure mode that would likely cause serious injury if it recurred, but no malfunction MDR exists. A CAPA references a systemic failure mode, but MDR reporting shows no awareness of that risk. These mismatches are not subtle; they are the signature of disconnected systems.

The fastest way to increase inspection readiness is to implement cross-link validation: the system should detect when complaint keywords/outcomes imply severity and force a reportability review; it should detect when certain failure modes map to likely serious harm and force escalation; and it should prevent closing a complaint without a documented MDR determination.

16) Operational playbook and dashboard model

If you want MDR to be reliable, you need a routine playbook that works under stress. The goal is to make the compliant path the fastest path and to make exceptions visible, governed, and auditable.

Dashboards should not be vanity metrics. The most useful MDR dashboard is one that shows time-to-triage, time-to-reportability decision, approaching deadlines, event-file completeness, and the proportion of cases requiring supplemental follow-up. If you can’t see those metrics, you can’t manage timeliness.

17) Selection pitfalls: how MDR systems get faked

• “Be aware” is negotiable. If the awareness date can be edited without strong governance and audit trail visibility, timeliness is not provable.
• Malfunction logic is outcome-based. If you only report malfunctions when harm occurred, you will under-report and trend signals will be invisible.
• Free-text reportability decisions. Without structured rationale fields, decision consistency will drift and defensibility will collapse.
• Complaint/MDR/CAPA separation. Parallel workflows produce mismatches, which is how inspections expand.
• No device identity discipline. If UDI/serial/lot capture is optional at intake, your investigation becomes guesswork.
• Submission without controls. If anyone can submit, edit, or “fix” MDR records, the system will not survive scrutiny.
• Missing “reasonably known” diligence. If you cannot show contact attempts and evaluation effort, files will look thin and conclusions will look asserted.
• Deadlines managed by memory. If deadlines live in calendars and inboxes, you don’t have a controlled MDR system.

18) How this maps to V5 by SG Systems Global

V5 supports MDR readiness by connecting regulated workflow governance (QMS) with execution truth (MES/WMS) so MDR event files and narratives can be built from defensible, traceable evidence rather than reconstructed stories. The practical value is not “we can store MDR forms.” The value is that the system can enforce role-based actions, preserve audit trails, link complaints to device genealogy, and make deadlines visible as operational controls.

• Quality governance: V5 QMS supports complaint intake, reportability assessment workflow, investigation tasks, approvals, and auditable event files.
• Execution evidence: V5 MES supports execution-level traceability and links MDR investigations to work order evidence.
• Inventory/identity integrity: V5 WMS supports lot/container/serial control and status governance supporting scope and investigation quality.
• Integration integrity: V5 Connect API supports structured connectivity so inbound signals and device identity data feed MDR workflows without bypassing controls.
• Platform view: V5 solution overview.

19) Extended FAQ

Q1. What is 21 CFR Part 803?
It is FDA’s Medical Device Reporting (MDR) regulation that requires manufacturers, importers, and device user facilities to report certain device-related adverse events and product problems within defined timelines, and to maintain MDR procedures and MDR event files.

Q2. Do I need certainty that the device caused harm before reporting?
No. The operational threshold is whether information reasonably suggests device involvement for death/serious injury, or whether a malfunction would likely cause or contribute to serious harm if it recurred. MDR is designed for imperfect information; you report, investigate, and supplement as facts develop.

Q3. Why are malfunctions so important in Part 803?
Because malfunction reporting is an early-warning mechanism. A malfunction can be reportable even if no one was harmed in that incident, if recurrence could plausibly cause death or serious injury.

Q4. What should be in an “MDR event file”?
At minimum: the intake record, awareness date, reportability rationale (including any medical judgment basis for “not reportable”), investigation and evaluation artifacts, contact attempts, submission package and identifiers, and any supplemental follow-up submissions and linked actions (CAPA/field actions where relevant).

Q5. What is the biggest MDR governance red flag?
When dates and decisions are editable without strong controls. If the “become aware” date can be negotiated after the fact, timeliness cannot be proven and the program becomes indefensible.

Q6. How do I make MDR faster without making it sloppy?
Make the routine path structured and fast: enforce required fields at intake, use standardized decision logic with required rationales, pre-assign roles and escalation paths, and link MDR investigations to execution-level traceability so you are not hunting for device identity and history under deadline pressure.

Related Reading
• Glossary Crosslinks: Medical Device Reporting (MDR) | MDR Reportability Assessment | Become-Aware Date Control | Segregation of Duties in MES | Event-Driven Manufacturing Execution | UDI-Linked Execution Genealogy
• Implementation Guides: Execution-Level Genealogy | Operator Action Validation | Role-Based Execution Authority | Execution Context Locking | Review by Exception