What a post-market surveillance plan has to prove before the report gets written

A post-market surveillance file is often built as a relabeled complaint log with a cover page bolted on — the same intake records, summarized once a year and called a report. EU MDR 2017/745 Article 83 asks for something structurally different: an active and systematic system, run continuously for as long as the device is on the market, that gathers, records and analyses safety and performance data — not only whatever a complaint line happens to receive. That system has to produce different outputs on different schedules depending on the device's class, plus a separate, narrower obligation under Article 88 that most complaint-based files have no place to put at all. A PMS file that stops at the complaint summary has done a fraction of what Article 83 actually requires.

The system has to be active, not just receptive

Article 83 requires manufacturers to plan, establish, document, implement, maintain and update a post-market surveillance system proportionate to the risk class and appropriate for the type of device, as part of the quality management system. The system has to actively and systematically gather, record and analyse relevant data on the device's safety and performance throughout its lifetime, draw the necessary conclusions, and determine, implement and monitor any preventive or corrective action. “Actively” is doing real work in that sentence: a system that only opens a file when a complaint arrives is running the receiving half of Article 83's structure, not the gathering half the article names separately from it.

The plan and the report are not the same document

Article 84 requires the PMS system to be based on a PMS plan, which becomes part of the device's technical documentation and sets out the process for actively and systematically collecting and evaluating data on safety and performance over the device's expected lifetime, before that data starts arriving. The report, under Article 85 or 86, is what the plan's execution produces afterward. Treating the plan as a placeholder to be filled in retroactively from whatever the report ends up saying gets the sequence backwards — it's the plan's job to fix the method in advance, not summarize it in hindsight.

Which report you owe depends on class, and so does the clock

For Class I devices, Article 85 requires a post-market surveillance report (PMSR), updated when necessary and made available to the competent authority on request — no forced periodic cadence. For Class IIa, IIb and III devices, Article 86 requires a periodic safety update report (PSUR) instead: results and conclusions of the PMS data, together with the rationale and description of any preventive or corrective action taken, updated at least every two years for Class IIa devices and at least once a year for Class IIb and III devices. For Class III and implantable devices, the PSUR is submitted through the EUDAMED electronic system to the notified body involved in the device's conformity assessment, which reviews it and adds its own evaluation; other devices in the PSUR bracket make the report available to the notified body and, on request, to competent authorities, without that same built-in independent review. A PMS file built around one generic “annual report” misses this branch entirely — the frequency and the review path both depend on the class question the file has to answer first.

Trend reporting is a separate obligation, on a narrower trigger

Article 88 requires manufacturers to report any statistically significant increase in the frequency or severity of incidents that are not themselves serious incidents — or of expected undesirable side effects — that could meaningfully affect the benefit-risk determination and become unacceptable when weighed against the device's intended benefits. That's deliberately not the same test as serious-incident vigilance reporting: it catches events that individually never cross the serious-incident bar, but whose rate is moving. The article requires manufacturers to define, in the PMS plan itself, the methodology for that statistical determination and the observation period against which a “significant increase” gets measured. A file with no defined baseline period and no stated method for testing against it has no way to actually apply Article 88 when a rate does move — the trigger has to be built in before it's needed, not decided the day the numbers look off.

Where this reaches past the complaint pipeline

MDR's PMS system is the proactive counterpart to the reactive, per-event system a complaint record runs on the US side under Clause 8.2.2 and Part 803 — it has to reach into PMCF data, literature, registries and user feedback the complaint pipeline never sees on its own, and it feeds the same residual-risk conclusions a risk management file has to keep current under ISO 14971 Clause 10. A post-market surveillance plan built around this chain — Article 83's active-system definition, Article 84's plan-first structure, the PMSR/PSUR branch decided by class, and a trend-reporting methodology defined before it's needed — is previewed in the launch catalog. If your program owes a class branch or a trigger this doesn't cover, the shelf takes that correction directly.