Part 803 has no separate category for AI, so an AI-enabled device reports on the same triggers as any other: a death or serious injury the device may have caused or contributed to, or a malfunction that would likely cause one if it recurred. What is different is that the clock runs from awareness rather than from the event, and that a model authorized to change under a PCCP may have moved in between. A report describes what the device did. A changed device cannot answer that retroactively.
Most clinical AI writing about things going wrong is about liability, which is the question of who pays. We covered that in who is liable when a clinical AI decision is wrong. This is the earlier and more concrete question: what you are legally required to file, on what clock, and which factual fields you will be asked for that are expensive to reconstruct after the fact.
Who reports, and on what trigger
Part 803 creates three categories of mandatory reporter: manufacturers, importers, and device user facilities, which include hospitals, surgical centers, nursing homes and outpatient diagnostic or treatment facilities.[1]
Manufacturers must report when they learn that a device "may have caused or contributed to a death or serious injury," and separately when they become aware that the device "has malfunctioned and would be likely to cause or contribute to a death or serious injury if the malfunction were to recur."[1] Importers report deaths and serious injuries to both the FDA and the manufacturer, and malfunctions only to the manufacturer. User facilities report suspected device-related deaths to both the FDA and the manufacturer, and serious injuries to the manufacturer, or to the FDA where the manufacturer is unknown.[1]
The second manufacturer limb deserves attention for AI specifically. It is a recurrence test, not a harm test. A model that produced a clearly wrong output which a clinician caught before it reached the patient has harmed no one, and can still be a reportable malfunction if the same failure recurring would likely cause serious injury. Teams that think of reportability as triggered by patient harm systematically under-count that case.
The clocks
| Reporter | Event | Goes to | Deadline |
|---|---|---|---|
| Manufacturer | Death, serious injury, reportable malfunction | FDA | 30 calendar days from awareness |
| Manufacturer | Where remedial action is needed to prevent unreasonable risk of substantial harm, or FDA requests it | FDA | 5-day report, 21 CFR 803.53 |
| Importer | Death or serious injury | FDA and manufacturer | Per Part 803 |
| User facility | Suspected device-related death | FDA and manufacturer | 10 working days |
| User facility | Serious injury | Manufacturer, or FDA if unknown | 10 working days |
Two notes on reading that table honestly. The 30-day clock "starts the day you receive or otherwise become aware of information that reasonably suggests the event is MDR-reportable,"[2] which is earlier than most teams assume and is not the date your investigation concludes. And on the 5-day report, published summaries disagree about whether the count is in work days or calendar days, so read the counting basis off 21 CFR 803.53 itself rather than off any secondary description, including this one.
The question a changed model cannot answer
Here is where AI-enabled devices differ from the rest of Part 803 in practice rather than in text.
A report describes an event and the device's role in it. For a fixed device that is a stable question: the device that was involved is the device you still have. Under an FDA-authorized Predetermined Change Control Plan, a model can be updated without a new marketing submission, so the version in force is a function of the date. We covered the mechanics in one record, two regulators.
Now put that on the MDR timeline. The event occurs. Some weeks later a complaint, a clinician query or a support ticket surfaces it, and awareness begins. Somewhere in that window the model is updated inside its authorized plan. You now have thirty days to file a description of what the device did, and the device in front of you is not the one that did it.
Why "we checked the logs" is thinner than it sounds
Most teams will say the inference logs answer this. Sometimes they do. The question is what the log is worth once it leaves your building.
An ordinary application log records that an inference occurred. It can be edited, rotated or regenerated, and it usually does not bind the output to a specific set of weights on specific inputs. Inside an investigation that is often good enough, because everyone in the room is acting in good faith. In a filing that a regulator reads, and that a plaintiff expert may read later beside it, a record that could have been altered and a record that could not are different categories of thing. We covered what closes that gap in what tamper-evident actually requires.
What to have ready before you need it
Two things, and only one of them is technical.
The technical one is the set of fields that are expensive to reconstruct after the fact: the model version and a digest of the weights that actually ran, the identity of the inputs, the output, the timestamp, and the identifier of any authorized modification in force at that moment. Sealed at the time, those answer the factual half of a report without an archaeology project.
The organizational one matters just as much and costs nothing. Decide in advance who is authorized to declare awareness, and write it down. The clock starts on awareness, not on the completion of your investigation, so an unclear internal trigger is how a thirty-day clock quietly becomes a twenty-day clock while people debate whether a support ticket counted.
What we are careful never to claim
RankShieldMD does not determine reportability, does not file your reports, and is not legal or regulatory advice. Whether a given event is reportable is a determination for your regulatory affairs function and your counsel, and the analysis turns on facts a software layer cannot see. We are not a medical device, we do not render or score clinical decisions, and we never see PHI.
What we do is narrower and checkable. We bind a model version to an output at the moment it is produced, in a tamper-evident, externally anchored, PHI-free record that a third party can verify without trusting us. That answers the factual question of which version was involved. It does not answer the regulatory question of what you owe.
References
- [1] U.S. Food and Drug Administration. Medical Device Reporting (MDR): How to Report Medical Device Problems. Reporter categories and the manufacturer, importer and user facility triggers. fda.gov
- [2] Complizen. Adverse Event Reporting for Medical Devices: Complete FDA Medical Device Reporting (MDR) Guide. Source for the awareness-based start of the 30-day clock and the user facility 10 working day timelines. complizen.ai
- [3] 21 CFR Part 803, Medical Device Reporting, including 803.50 and 803.53. Read the day-counting basis for the 5-day report directly from the regulation. ecfr.gov
