The Workbench · Craft

A PSUR is not a bigger PMS report

A post-market surveillance program built around a single template, updated on whatever cadence feels reasonable, has usually missed a distinction MDR draws on purpose. Regulation (EU) 2017/745 doesn't ask every device to file the same post-market document on the same schedule. Article 85 covers Class I devices with a post-market surveillance report, updated when necessary. Article 86 covers Class IIa, IIb, and III devices with a periodic safety update report — a different document, built around a different conclusion, and tied to a fixed reporting clock that Article 85's document doesn't carry. Treating “PSUR” and “PMS report” as interchangeable names for the same underlying artifact gets the two device tiers, and the two different duties MDR attaches to them, backwards.

Article 85 stops at Class I, on purpose

Article 85 of Regulation (EU) 2017/745 requires the manufacturer of a device to prepare a post-market surveillance report summarizing the results and conclusions of the analyses of the post-market surveillance data gathered under the manufacturer's own PMS plan, along with a rationale and description of any preventive and corrective actions taken. That duty applies to every device, but the article's own text keeps a document by this name to Class I devices, updated when necessary and kept available to the competent authority on request rather than filed to a fixed calendar. It's a real report with a real evidentiary function — but it's built for the lowest-risk tier of the classification system, and its update cadence is deliberately loose because that's the tier where MDR expects the least active churn in post-market findings.

Article 86 attaches a fixed clock the moment class rises

Class IIa, IIb, and III devices don't file the Article 85 report at all. They file a periodic safety update report under Article 86, and the difference isn't just the name on the cover page. A PSUR runs on a stated schedule tied to class: manufacturers of Class IIb and III devices update it at least annually, and manufacturers of Class IIa devices update it when necessary and at least every two years. Article 85's document waits for a reason to update; Article 86's document updates on a schedule regardless of whether anything unusual has happened, because the Regulation treats a higher class as owing periodic reporting on its own terms, not just reporting triggered by an event.

The content is built around a conclusion, not just a data dump

A PSUR isn't a longer version of the same summary a Class I manufacturer files. Article 86 calls for the report to draw an actual benefit-risk determination and its conclusions from the post-market surveillance data, alongside the main findings of any post-market clinical follow-up and the volume of sales and an estimate of the population using the device. That combination — sales volume and exposed population sitting next to a benefit-risk conclusion — is what lets a reader judge whether the underlying safety picture is stable relative to actual use, not just relative to however many complaints happened to arrive. A PMCF plan's findings are one of the direct inputs a PSUR is built to carry forward, not a separate document that stays parked in its own file.

For Class III and implantables, someone else reads it too

The PSUR for a Class III or implantable device doesn't stay internal to the manufacturer's own quality system. It becomes part of the technical documentation the manufacturer's notified body reviews as part of its ongoing conformity assessment, and the notified body's own evaluation of the PSUR gets added to that documentation. That's a different relationship to external scrutiny than a notified body's unannounced audit under Annex IX creates: the audit checks the quality system in person, on its own schedule, while a PSUR review is a standing, cyclical read of the manufacturer's own safety conclusions by the same body that issued the certificate in the first place.

Where this meets the file

A post-market surveillance program that builds one template and edits the update frequency by hand for each device has usually mapped one artifact where MDR actually asks for two, distinguished by class and by what each one has to conclude. A tracker built around this distinction needs the device's class recorded next to which document it owes, the update cadence that class carries, and — for Class III and implantable devices only — the notified body review date kept as a separate field from the PSUR's own authoring date. A PMS-report-versus-PSUR worksheet built around Article 85 and Article 86's own terms is previewed in the launch catalog. If your program tracks this differently, the shelf takes that correction directly.

The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.

All Workbench notes