AI Medical Device Adverse Event Reporting 2026: MDR, Malfunctions and the 30-Day Clock

The Five Clocks, and What Starts Them for an AI Product

Deadlines here are short and they run from awareness, not from conclusion. For each: the legal trigger, and the AI-specific event that satisfies it.

30-day MDR — death or serious injury

The trigger: You become aware of information reasonably suggesting your device may have caused or contributed to a death or serious injury.
What sets it off in an AI product: A missed finding on an imaging triage tool, a sepsis score that never fired, a dosing recommendation acted on. 'Contributed to' does not require the device to be the sole cause, and the fact that a clinician was in the loop does not by itself take the event out of scope.

30-day MDR — malfunction

The trigger: A malfunction that would be likely to cause or contribute to a death or serious injury if it were to recur.
What sets it off in an AI product: This is the category AI products systematically under-file. A model returning a confidently wrong output within its intended use is a malfunction of the device, not a limitation of the technology, and the recurrence test is almost trivially satisfied by software that will behave identically on the next matching input.

5-day MDR

The trigger: An event that requires remedial action to prevent an unreasonable risk of substantial harm to public health, or where the agency has made a written request.
What sets it off in an AI product: A deployment-wide defect — a bad model version, an inverted label mapping, a units bug in preprocessing — is precisely the fact pattern this exists for, because every installation is affected simultaneously and the fix is a push rather than a field visit.

Correction and removal reporting

The trigger: A correction or removal initiated to reduce a risk to health or to remedy a violation, reportable within ten working days.
What sets it off in an AI product: Shipping a patch is a correction. Teams reflexively classify a model rollback as ordinary maintenance, and the classification decision — reportable or not — has to be made deliberately and recorded either way, including for the ones you decide are not reportable.

Complaint intake

The trigger: Every complaint received must be captured, evaluated for MDR reportability, and investigated where the complaint concerns a possible failure to meet specifications.
What sets it off in an AI product: The AI-specific failure is channel fragmentation. Clinicians report model problems into support tickets, sales channels, in-app thumbs-down widgets and clinical champions' email. Each is a complaint under the regulation, and none of them is usually wired into the complaint file.

Drift Is a Postmarket Obligation, Not an Engineering Preference

Surveillance is required, and for a model the thing being surveilled is performance against a moving world rather than component wear. Four points that change how the monitoring should be built.

Drift is not an excuse, it is a signal

Performance decay against a shifting patient population, a new scanner, a changed lab assay or an updated EHR mapping is foreseeable. The regulatory question is not whether drift occurred but whether your surveillance would have detected it before a patient did, and what your procedures said you would do when it did.

A locked model still changes

Even without retraining, the input distribution moves and the surrounding integration changes underneath you. A device that has not been modified since clearance can nonetheless be performing materially worse than its clearance data, and 'we changed nothing' is a statement about your codebase rather than about the device's real-world performance.

The change-control plan cuts both ways

An authorised predetermined change control plan lets specified modifications ship without a new submission. It is also a commitment: it defines the modification protocol and the performance boundaries you said you would stay inside. Shipping a change outside that envelope is a modification requiring submission, and having a plan makes that easier to demonstrate, not harder.

Site-level performance is the unit that matters

Aggregate metrics across all customers can look stable while a single hospital's performance has collapsed after an upstream change. Surveillance that only reports the global number will not see the event that generates the report, and the site that is failing is rarely the one that calls you.

Who Files When Four Companies Touch One Prediction

The modern deployment has a model vendor, a clearance holder, an integrator and a hospital in the path. Regulatory roles are assigned by conduct, not by contract.

Party	What actually falls on them
Manufacturer	Files MDRs, maintains the complaint file and MDR event files, reports corrections and removals, and holds the quality-system obligations. The label is functional: whoever designs, develops or specifies the device and puts it into commercial distribution under their own name is generally in this seat.
Model vendor under someone else's clearance	Frequently believes it has no reporting duty and is frequently wrong about the practical consequence. Even where the clearance holder files, contractual quality agreements will impose complaint-transfer obligations with tight internal deadlines — often 48 to 72 hours — and missing those is a breach that surfaces in the holder's audit rather than yours, which is worse.
Health system deploying the tool	May have user-facility reporting duties for deaths and serious injuries, on their own timeline and to different recipients. Their report and yours describe the same event, and inconsistencies between them are noticed. Establish who says what before you have an event.
Reseller or integrator	Distribution roles carry recordkeeping and complaint-forwarding duties even without manufacturing ones. An integrator who modifies configuration, thresholds or intended use can move into a manufacturer role without anyone deciding to, which is a determination made on conduct rather than on the contract.

The intake test

Search your support system, your sales CRM notes, your in-product feedback widget and your shared clinical channels for the last ninety days, for any message describing an output as wrong, missed, dangerous or overridden. Count them. Now count how many reached the complaint file.

The gap between those two numbers is your exposure, and it is measured in days against clocks that started on the earliest of those timestamps. Every one of those messages was the company becoming aware.

Frequently Asked Questions

Is a wrong AI prediction a reportable malfunction?

Often yes, and the instinct that it is merely a known limitation is where most under-reporting starts. A device malfunction is a failure of the device to meet its performance specifications or to perform as intended. If your cleared indications say the tool triages intracranial haemorrhage and it returns negative on a study containing one, the device did not perform as intended on that case — irrespective of the fact that every model has a false-negative rate and that the rate was disclosed. What the disclosed rate establishes is that the behaviour is expected in aggregate; it does not convert an individual failure into a non-event. The reportability test for malfunctions then asks whether the malfunction would be likely to cause or contribute to a death or serious injury if it recurred, and deterministic software satisfies the recurrence limb almost automatically. The practical filter is severity and causation on the specific case, not novelty of the failure mode. Document the analysis for the ones you decide are not reportable, because the file showing a considered decision is the difference between a defensible judgement and an inspection finding.

When exactly does the 30-day clock start?

On the day any employee or agent of your company becomes aware of information reasonably suggesting a reportable event — not on the day your regulatory team learns of it, and not on the day the investigation concludes. That distinction is where AI companies lose weeks. A support engineer who reads a ticket saying the model missed a finding and the patient deteriorated has made the company aware. A clinical account manager copied on a hospital's internal safety email has made the company aware. A data scientist who spots an anomaly in a monitoring dashboard and mentions it in a channel has arguably made the company aware. The regulation contemplates awareness reaching the organisation through any of its people, which is why complaint-intake routing is a regulatory control and not a support-operations preference. Two consequences follow. Every customer-facing channel needs a defined path into the complaint file with a timestamp preserved. And an incomplete investigation is not a reason to miss the deadline — you file what you know, mark the unknowns, and supplement.

Does a predetermined change control plan remove the reporting obligation for model updates?

No. It changes when you need a new marketing submission; it does not touch postmarket reporting, complaint handling or correction-and-removal duties. An authorised plan describes modifications you may make — retraining on new data, threshold adjustments, expanding to a new scanner model — together with the protocol you will follow and the performance you will maintain. Shipping inside that envelope avoids a new submission. It does not mean the update is invisible. If the update is being shipped because the deployed version was performing unsafely, that is a correction and the reportability analysis applies to it. If the update itself degrades performance at a site, that is a new event. And the plan creates its own evidentiary exposure: you have committed in writing to a modification protocol and to acceptance criteria, so an update that skipped a step or missed a criterion is now demonstrably outside your own authorised process. The plan is a discipline you asked for. Teams that treat it as a permission slip find that the protocol they wrote is the standard they are audited against.

We supply the model; our customer holds the clearance. Who files?

The clearance holder is the manufacturer of record and files, but that answer resolves less than it appears to. Three things sit on you regardless. Your quality agreement almost certainly obliges you to transfer complaints and safety information within a very short internal window, and the holder cannot meet a 30-day clock that starts at your support desk unless you move in days. Your own conduct can put you in the manufacturer seat — if you specify intended use, control the model that constitutes the device's function, and ship changes on your own schedule, the functional test may reach you even though someone else's name is on the submission. And the events will be attributed to your model in public regardless of the filer, so the reports in the public database will name behaviour you own while the narrative is written by someone with less insight into why it happened. The practical posture is to run your own complaint file, do your own reportability analysis, and treat the holder's filing as the output of a joint process rather than as a duty you have outsourced.

What does postmarket surveillance actually look like for an AI device?

It looks like production monitoring with regulatory teeth, and the two most useful properties are stratification and thresholds set in advance. Stratification means you compute performance by site, by scanner or instrument, by demographic subgroup and by software version, because aggregate stability hides site-level collapse and subgroup degradation — and a subgroup gap that widens after deployment is both a safety issue and a discrimination issue in parallel. Thresholds set in advance mean deciding, before you look, what level of decay triggers an investigation, a customer notification, a rollback or a report; a threshold chosen after seeing the number is not a control. Around that sit the mundane parts: label-feedback loops where ground truth becomes available, input-distribution monitoring so you see the upstream change that will cause the decay rather than the decay itself, retention of enough of the input to reconstruct a specific case months later, and a defined trending review with named attendees and minutes. Nearly every AI device company has the dashboards. Far fewer have written down what number makes them act.

Is pushing a model fix a recall?

It can be, and the terminology causes teams to reach the wrong conclusion. A correction is a repair, modification, adjustment, relabelling or inspection of a distributed device without physically moving it — which describes a software patch precisely. A correction undertaken to reduce a risk to health or to remedy a violation is reportable within ten working days, and none of that requires the word recall, a press release or product being returned. The common error is reasoning backwards from consequences: a company decides the fix cannot be a recall because a recall would be a serious event, and then classifies it as routine maintenance. The classification is determined by why you shipped it. Build the decision into your release process — every change gets a documented reportability determination, with the reasoning retained for the ones determined not reportable — because the alternative is making that judgement under time pressure while an inspector reads your release notes. Release notes are the most quietly damaging artefact in this area: 'fixed an issue where the model could underestimate severity in paediatric cases' is a health-risk correction described in a changelog.

How do the public reports affect us commercially?

Adverse event reports are published in a searchable public database, and for AI devices they are becoming a routine input to procurement rather than a regulatory backwater. Health-system evaluation committees search it, competitors search it, journalists search it, and plaintiff-side firms search it systematically. Two practical implications follow. The narrative text you write in the report is the version of the event that becomes public and durable — a vague or defensive narrative reads worse over time than a precise one, and precision costs nothing when the underlying analysis was done properly. And the comparison is relative: a product with reports filed and a visible investigation trail can look better to a sophisticated buyer than a comparable product with none, because zero reports across a large install base reads to an experienced reviewer as an intake problem rather than as a safety record. Under-reporting is not a quiet strategy. It is a strategy that produces a suspicious number.

Clearance Was the Easy Part. Now You Have Thirty Days From a Support Ticket.