How to Use AI for Medical Device Post-Market Surveillance

Most of post-market surveillance is reading. A complaint handler reads a free-text narrative and decides what happened. A PMS lead reads MAUDE reports for their own product codes and for competitors'. Someone reads recall notices from FDA, Swissmedic, MHRA and Health Canada, and someone else reruns the literature search for the clinical evaluation. The volume grows with every device sold, and the most common finding in this area is a PMS system that amounts to the complaint process and little else.

Language models are good at that reading. They can code a narrative, pull the same fields out of five hundred reports, and compare this week's recall notices with last week's. They should not decide whether an event is reportable or whether a risk is acceptable. The regulations put those decisions on the manufacturer, and a model drafting the first pass doesn't move them.

FDA is heading the same way internally. When it rolled out agentic AI to all staff in December 2025, it listed post-market surveillance among the intended uses.

The obligations behind the work

In the US the duties sit in several parts of Title 21.

• Medical Device Reporting, 21 CFR 803. A report is due within 30 calendar days of becoming aware that a device may have caused or contributed to a death or serious injury, or malfunctioned in a way that would be likely to if it recurred (803.50). A 5-work-day report applies when an event needs remedial action to prevent an unreasonable risk of substantial harm, and the regulation says that need can be identified from "any information, including any trend analysis" (803.53).
• Complaint handling, which since the QMSR took effect on February 2, 2026 runs through ISO 13485 clause 8.2.2. 21 CFR 820.35 adds what a complaint record must hold, including the UDI, the nature of the complaint and any corrective action, and requires a documented reason when a complaint is not investigated.
• Corrections and removals, reported under 21 CFR 806.10 within 10 working days.

The EU MDR is more prescriptive. Article 83 requires a PMS system that gathers data "actively and systematically". Article 86 sets the PSUR cadence: at least annually for class IIb and III, and at least every two years for class IIa. Article 87 sets vigilance deadlines of 15 days for a serious incident, 10 for a death or unanticipated serious deterioration, and 2 for a serious public health threat. Article 88 requires a report of "any statistically significant increase in the frequency or severity" of non-serious incidents or expected side effects. Annex XIV Part B makes PMCF a continuous process that updates the clinical evaluation.

In December 2025 the Commission proposed changing several of these, including a 30-day deadline for some serious incidents and a less frequent PSUR. The proposal had not been adopted when this post was published, so the current text applies.

Code every complaint the same way

Complaints arrive as free text: an email from a hospital biomedical engineer, a call transcript, a field service note. Two handlers can read the same narrative and code it differently, and inconsistent coding is what breaks trending later.

A model can read each narrative and fill the same fields every time: device and model, event date, IMDRF event type, patient harm, device involvement, suspected root cause and corrective action. Each value should cite the sentence it came from, so the reviewer checks a quote instead of rereading the file. Laid out as a table, with one complaint per row and one question per column, the output also shows where a narrative is silent. A missing event date is worth knowing early. The MDR clock runs from when you became aware, and an incomplete record is how a 30-day report turns into a late one.

The model can also mark a complaint as a possible MDR or vigilance case. That gets the file to the right reviewer sooner. The decision and its rationale belong in your complaint record, made by someone trained to make it.

Trend rates, not counts

Article 88 asks for a statistically significant increase, and that is a statement about rates. A rate needs a denominator: units sold, procedures performed, devices in use. Complaint counts that rise with sales are not a trend.

Public data has the same problem in a stronger form. FDA says MAUDE is "not intended to be used either to evaluate rates of adverse events" and that the incidence or cause of an event "cannot be determined from this reporting system alone." Reports under the Voluntary Malfunction Summary Reporting program make counting harder still, because one summary report can stand for many malfunctions. A model that reads a MAUDE report count as a frequency will draw a confident chart about nothing.

Put the method in your PMS plan and the arithmetic in something you can audit, such as a script or a controlled spreadsheet running the statistical test the plan names. The model works upstream of that. It assembles a clean numerator from coded complaints, asks for the denominator when it is missing, and writes up the result with each figure traced to its source.

Watch similar devices across regulators

Ignoring similar devices is a frequent gap, and the data for it is public. For a product code you can pull MAUDE reports and FDA recalls (try our recall search), then check field safety notices from Swissmedic, MHRA, Health Canada and TGA for comparable devices.

Run the search weekly against your own devices and the benchmarks named in your PMS plan, and compare each run with the previous one. Most weeks the comparison is short. In the week a competitor issues a field safety notice for a failure mode your device shares, the owner of your risk file should hear about it by Monday.

Each source lags differently. FDA updates the MAUDE database monthly and openFDA's device event data weekly. FDA has also said MAUDE data will move into its new Adverse Event Monitoring System (AEMS) during 2026, so confirm which system a query reads before relying on its dates.

Keep the literature search running

A literature review run once for the CE mark and never repeated is another regular audit finding. PMCF and the clinical evaluation both expect it to continue.

A saved search protocol can be rerun on a schedule, with the model screening only papers it has not seen before against your inclusion criteria and recording the reason for each exclusion. The reviewer gets a short list of new candidates instead of a fresh export of four hundred hits.

Feed the risk file and the PSUR

Surveillance output has to change something. ISO 14971:2019, which FDA recognizes, has a production and post-production stage that sends this information back to the risk management file. In the EU it also feeds the clinical evaluation and the PSUR, whose expected content MDCG 2022-21 sets out. MDCG 2025-10, published in December 2025, covers the PMS system more broadly.

AI helps with the draft: complaints for the period by event type, trend results with their method, new literature, actions taken. Each statement should link to the record behind it. Conclusions about benefit-risk, and about whether a risk estimate changes, are the manufacturer's to make. A good draft also says where data is missing, such as a sales figure or a gap in the literature period, instead of papering over it.

Validate it like the rest of the QMS

A tool that codes complaints or screens literature is software used in the quality management system, and ISO 13485 clause 4.1.6 requires that software to be validated for its intended use. Describe what the model does in your procedure, test it against complaints your experienced handlers have already coded, and record who reviews its output. The computer system validation entry covers the approach.

FDA's first warning letter to cite AI was about drug manufacturing, but its standard carries over to devices: the quality system is responsible for reviewing a document, whoever drafted it.

How Arca handles post-market surveillance

Arca ships a Post-Market Surveillance playbook built to run on a weekly schedule. For a device and its benchmarks it pulls MAUDE reports, FDA recalls, and field safety notices from regulators including Swissmedic, MHRA, Health Canada and TGA. It compares the results with the previous run and emails a trend table to the people you name. It asks for sales volumes to compute rates, marks them as missing when you haven't supplied them, and does not decide reportability.

Complaint files go into a Grid, one row per complaint and a column per field, with every answer cited to the passage it came from. A separate PMCF literature playbook reruns your saved search each week and screens only the new papers.

For the drug side of the same problem, see How to Use AI to Monitor Competitor Drug Labels and Approvals.

Frequently asked questions

Can AI decide whether a complaint is MDR reportable?

It can flag a complaint as a possible MDR or vigilance case and show the evidence. The reportability decision and its rationale belong to a trained person and go in the complaint record. 21 CFR 803 and EU MDR Article 87 put the obligation on the manufacturer.

Can MAUDE data be used to trend adverse event rates?

No. FDA says MAUDE is not intended for evaluating rates of adverse events. It is a passive system with under-reporting, and summary reports can combine many events. Use it to find failure modes in similar devices, and compute rates from your own complaint and sales data.

Does AI used in post-market surveillance need to be validated?

Yes. Software used in the quality management system has to be validated for its intended use under ISO 13485 clause 4.1.6, which the QMSR incorporates. Test it against complaints your team has already coded and document who reviews its output.

Sources

• 21 CFR 803.50 and 803.53, Medical Device Reporting: ecfr.gov, ecfr.gov
• 21 CFR 820.35, Control of records: ecfr.gov
• 21 CFR 806.10, Reports of corrections and removals: ecfr.gov
• FDA, Quality Management System Regulation (QMSR): fda.gov
• FDA, About the MAUDE database: fda.gov
• FDA, MDR data files: fda.gov
• FDA, Voluntary Malfunction Summary Reporting (VMSR) Program: fda.gov
• openFDA, Device adverse event API: open.fda.gov
• Regulation (EU) 2017/745, Articles 83 to 88 and Annex XIV: eur-lex.europa.eu
• European Commission, proposal COM(2025) 1023 amending the MDR and IVDR: health.ec.europa.eu
• MDCG guidance, including MDCG 2022-21 and MDCG 2025-10: health.ec.europa.eu
• FDA recognized consensus standard 5-125, ISO 14971:2019: accessdata.fda.gov
• FDA, FDA Expands Artificial Intelligence Capabilities with Agentic AI Deployment, December 1, 2025: fda.gov