The post-market surveillance report for Class I devices is required by Article 85 of Regulation (EU) 2017/745. It summarises the results and conclusions of the analyses of post-market surveillance data gathered under the PMS plan, together with a rationale and description of any preventive and corrective actions taken. It is updated when necessary and made available to the competent authority upon request. The content is analytical — not a raw complaint log — and the document must exist before a request arrives, not be produced retroactively.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • Article 85 of Regulation (EU) 2017/745 requires manufacturers of Class I devices to prepare a post-market surveillance report (PMSR) summarising the results and conclusions of PMS data analyses and describing any preventive and corrective actions taken.
  • The PMSR is updated "when necessary" — the Regulation does not fix a calendar cadence — and made available to the competent authority upon request.
  • The content is analytical. A raw complaint log is not an Article 85 report. The report must contain results, conclusions, rationale, and CAPA description.
  • The PMSR is the output of the PMS plan under Article 84 and Annex III. A weak plan produces a weak report.
  • Higher-class devices (IIa, IIb, III) prepare a Periodic Safety Update Report (PSUR) under Article 86 instead — different content, different cadence, different submission route.
  • MDCG 2025-10 (December 2025) is the current operational guidance that notified bodies and competent authorities apply when assessing Class I PMS reports in practice.

Why this report exists and why Class I founders underestimate it

The PMSR for Class I devices is the document most commonly treated as optional by first-time founders. The reasoning is seductive and wrong: the device is low risk, the Regulation says "when necessary" rather than "annually," the report is made available only "upon request." Put those three phrases together and it sounds like a document that can be written the week a competent authority asks for it. That interpretation fails Article 85 on its face. The report exists before the request. "Upon request" controls delivery, not existence.

The arm-strap sleep-monitoring device story from the PMS pillar post is the reason this matters even for low-risk Class I devices. Skin irritations from prolonged wear that lab testing under EN ISO 10993-1 had not predicted. The manufacturer caught the pattern because the PMS system was actually running and the PMSR surfaced the trend across review cycles. If the report had not existed, the pattern would have surfaced months later, after more patients. Article 85 is not a paperwork exercise. It is the document that proves — to the manufacturer, to the authority, and eventually to the next auditor — that the Class I PMS system is doing the job Article 83 requires.

This post walks the Article 85 requirement element by element. What the text says, what must be in the report, how it differs from the PSUR, how often to update it, where to keep it, and how to present it to a competent authority without scrambling.

What Article 85 actually requires

Article 85 of Regulation (EU) 2017/745 is short. Manufacturers of Class I devices shall prepare a post-market surveillance report summarising the results and conclusions of the analyses of the post-market surveillance data gathered as a result of the post-market surveillance plan referred to in Article 84, together with a rationale and description of any preventive and corrective actions taken. The report shall be updated when necessary and made available to the competent authority upon request.

Read that sentence twice. It contains five distinct obligations that a competent authority or a notified body (for devices that later move up in class, or during an unannounced visit) can test independently.

Obligation 1 — The report exists. Not "can be produced." Exists. As a document. Dated. Version-controlled. Inside the technical documentation file referenced in Annex III.

Obligation 2 — It summarises results and conclusions. Not raw data. Analysis. The report transforms PMS data into findings the reader can act on.

Obligation 3 — It covers data gathered under the PMS plan. The report is the output of the plan from Article 84 and Annex III. If the plan names ten data sources, the report reflects what those ten sources produced. A report that ignores half the plan is non-compliant on its face.

Obligation 4 — It includes rationale and description of preventive and corrective actions. Every CAPA triggered by PMS findings is explained: what was found, why action was taken, what action was taken, what the result was. "No CAPAs this cycle" is also a valid conclusion — but it is a documented conclusion, not silence.

Obligation 5 — It is updated when necessary and available on request. "When necessary" is discussed in its own section below. "Available on request" means the document is retrievable fast, in a current version, by the person who owns it.

Five obligations. Any one of them missing is a finding. This is why Article 85 looks easier than Article 86 and is actually just as unforgiving.

What must be in the report — the content walkthrough

The Regulation prescribes content, not format. The PMSR for Class I devices, at minimum, covers the following blocks. Each block traces directly to the Article 85 text or to the Annex III plan the report is summarising.

Block 1 — Device identification. Which device, which version, which UDI-DI, which intended purpose, which classification rule under Annex VIII. One paragraph is enough if the detail lives in the tech file and the report references it.

Block 2 — Reporting period. The window the report covers. For "when necessary" reporting, the window is defined by the plan — typically twelve months for an active device, longer for a stable low-volume device, shorter when a finding forces an interim report.

Block 3 — Data sources reviewed. The same sources named in the PMS plan under Annex III, Element A. Complaints, user feedback, service records, returns, literature monitoring, similar-device monitoring, state-of-the-art reviews, and any other source the plan lists. Each source is named with the volume of data reviewed and the review method.

Block 4 — Results of the analyses. What the numbers showed. Complaint rates per unit sold or per user. Trend analysis against the previous period. Any signals identified by the literature or similar-device monitoring. The analytical method from Element B of the plan is applied here.

Block 5 — Conclusions. The interpretation of the results. Is the device still performing as intended? Is the benefit-risk balance still acceptable? Are there emerging hazards not covered by the risk file? Are the IFU and labelling still adequate? The conclusions answer these questions explicitly.

Block 6 — Preventive and corrective actions. Every CAPA triggered by the findings, with the rationale for why it was taken, what it consisted of, and what the status is. Actions not triggered by PMS findings do not belong here. Actions triggered by PMS findings but handled outside the PMSR are also non-compliant — the report is the canonical place.

Block 7 — Feedback into risk management and clinical evaluation. How the findings flowed into the risk management file under EN ISO 14971:2019 + A11:2021 and, where applicable, into the clinical evaluation update cycle. Article 83(3) names these loops as mandatory uses of PMS findings, and the PMSR is where the manufacturer demonstrates the loops closed.

Block 8 — Conclusions and next steps. A short closing paragraph naming the state of the PMS system for this device, whether the PMS plan itself needs updates, and when the next review is scheduled.

Eight blocks. On a Class I device with low complaint volume, the complete PMSR is typically five to twelve pages. The volume is not the compliance signal — the coverage of every block is. A four-page report that addresses every block beats a thirty-page report that buries the conclusions.

How the Class I PMSR relates to the PSUR for higher classes

A recurring founder question: if the device later moves up in class, or if we have a mixed portfolio, how different is the PMSR from the PSUR under Article 86?

The PSUR for Class IIa, IIb, and III devices under Article 86 is a superset of the Class I PMSR content. The PSUR contains everything the PMSR contains, and adds three elements that Article 86 names explicitly: the conclusions of the benefit-risk determination, the main findings of the post-market clinical follow-up (PMCF), and the volume of sales together with an estimate of the size and other characteristics of the population using the device and, where practicable, the usage frequency of the device.

Article 85 does not require those three elements for Class I. In practice, most well-run Class I PMSRs include at least a lightweight benefit-risk statement in the conclusions block — not because the article demands it, but because Article 83(3) names updating the benefit-risk determination as one of the mandatory uses of PMS findings. The report is the natural place to document that determination.

The other differences are operational. The PSUR for Class IIb and III devices is updated at least annually; for Class IIa, at least every two years. The Class I PMSR is updated "when necessary." The PSUR for Class III and implantable devices is submitted via the Eudamed electronic system to the notified body; the Class I PMSR is made available to the competent authority upon request. Different submission routes, different cadences, different content specs. For the PSUR mechanics see PSUR for Class IIa, IIb, and III devices under MDR. For the full article-level walkthrough see MDR Articles 83 to 86 — the PMS framework explained.

The practical takeaway for Class I manufacturers: build the PMSR structure now in a way that can scale. If the device ever reclassifies upward, or the portfolio adds a Class IIa sibling, the existing PMSR blocks map cleanly to the PSUR. Structure is portable. Rebuilding from scratch on the day a notified body asks for a PSUR is not a path anyone wants to walk.

Update frequency — what "when necessary" actually means

"When necessary" is the phrase founders misread most often. It is not "never." It is not "when the authority asks." It is the cadence at which the report stays aligned with what the underlying PMS system has produced.

The practical interpretation, which aligns with MDCG 2025-10 (December 2025) and with what competent authorities expect to see, has three triggers.

Trigger 1 — A full review cycle of the PMS plan has completed. The plan names cadences for each data source and each analysis activity. When a cycle of those activities has run and produced findings, the report is updated. For most Class I devices this is an annual cadence, though it can be longer for stable low-volume devices or shorter for devices in their first year on the market.

Trigger 2 — A finding warrants documentation. A CAPA is triggered. A trend is identified. A new hazard surfaces. A risk file update is driven by PMS data. Any of these is a "when necessary" event. The PMSR is updated to capture the finding and the response, even if a full review cycle has not elapsed.

Trigger 3 — A change to the device, the intended purpose, or the plan itself. When the input side changes, the output side updates. A new data source added to the plan is reflected in the next report. A change to the intended purpose triggers a re-baseline.

In practice, the cleanest pattern for Class I devices is an annual review cycle documented as the "standard" PMSR cycle, with interim amendments driven by findings. Competent authorities that see an annual PMSR on a Class I device with a date stamp and a current version will not press on cadence. Competent authorities that see the last PMSR was written three years ago and nothing has changed on the file will press hard.

Where to keep it and how to present it on request

The PMSR is part of the technical documentation under Annex III. Physically and logically, it lives with the PMS plan, the risk management file, and the clinical evaluation. Three rules for storage and presentation matter in practice.

Rule 1 — Version control and date stamps. Every PMSR has a version number, a creation date, a "covers period" field, and an author. When a competent authority asks, the manufacturer must be able to say "this is the current version, dated X, covering the period Y to Z, authored by the PRRC under Article 15(2)." Ambiguity here signals a system that is not running.

Rule 2 — Fast retrieval. "Available upon request" in practice means a competent authority expects the document within the response window defined by national law — typically days, not weeks. The PMSR should be retrievable in minutes by the person who owns it. QMS document management under EN ISO 13485:2016 + A11:2021 handles this natively if the PMSR is filed under the correct procedure.

Rule 3 — Presentation format. The PMSR is a controlled document, not a spreadsheet with live data. When presented to an authority, it is presented as a finalised, signed, versioned document — the same way any other tech file element is presented. Supporting data (the complaint log, the literature search results, the service records) lives in the underlying records the PMSR references; those are available too, but they are not the report.

Notified bodies see the Class I PMSR indirectly — Class I devices without a measuring function or sterile element are self-declared, so a notified body typically does not review a Class I PMSR unless the device has a measuring, sterile, or reusable surgical element that brings it under notified body scrutiny (see Class I with measuring function — what changes). For self-declared Class I devices, the audience for the PMSR is the competent authority in the Member State of registration, and the presentation standards are set by that authority's document request procedures.

Common mistakes on the Class I PMSR

A handful of drafting mistakes come up repeatedly at first-time Class I manufacturers. Each one is traceable to a specific Article 85 obligation.

Mistake 1 — The report does not exist. The team assumed "when necessary" meant "when asked" and never wrote one. Fails Obligation 1.

Mistake 2 — The report is a complaint log. Raw data pasted into a document with no analysis, no conclusions, no CAPA description. Fails Obligations 2 and 4.

Mistake 3 — The report ignores data sources named in the plan. The PMS plan names literature monitoring and similar-device review, but the PMSR only covers complaints. Fails Obligation 3.

Mistake 4 — No feedback loop to the risk file. Findings are listed but there is no reference to how the risk management file was updated, or to why no update was needed. Fails Article 83(3) indirectly via the PMSR content spec.

Mistake 5 — No rationale for the CAPAs. Actions are listed without the "why." The report states that a material specification changed but does not explain that the change was driven by a skin-irritation signal from field complaints.

Mistake 6 — The report is not dated or versioned. Competent authorities cannot confirm it is current. Under QMS discipline this is a documentation control finding separate from the PMS finding.

Mistake 7 — Copy-paste from the previous cycle. The report repeats the prior period's text with the dates updated. Fails the "results and conclusions of the analyses" test because no new analysis is visible.

Mistake 8 — The plan and the report do not match. The plan names one set of activities; the report describes a different set. The gap is visible on the first cross-reference the auditor runs.

The Subtract to Ship angle

The Subtract to Ship framework for MDR applied to the Class I PMSR produces one rule: build the smallest report that addresses every Article 85 obligation and every block that traces back to the PMS plan. Everything beyond that is drag. Everything less is a finding.

For a Class I startup, a minimal viable PMSR looks like a five-to-twelve-page document with the eight blocks walked through above, produced annually from the outputs of the PMS plan, signed and versioned by the PRRC, filed in the QMS document system, and updated interim whenever a finding warrants. No dashboards, no executive summaries for an audience of one, no repeated template boilerplate that nobody reads, no elaborate statistical sections for a device with twelve complaints in a year.

What the minimal PMSR cuts: copy-pasted consultant templates built for Class III devices, irrelevant sections covering PMCF findings when the device has no PMCF because the justification is documented elsewhere, extensive benefit-risk calculations when a short qualitative statement suffices, redundant references to procedures that live in the QMS. Every cut paragraph is a paragraph that does not have to be maintained quarter after quarter, and maintenance drag is what turns a functioning PMSR into a stale one.

The test at the end is the Subtract to Ship test: for every paragraph in the PMSR, can you trace it to Article 85, the PMS plan it summarises, or a specific Annex III element the plan is built on? If yes, keep it. If no, cut it. The PMSR that survives is the one the team will actually update when necessary, which is the whole point of the article.

Reality Check — where do you stand?

  1. Does a PMSR for your Class I device exist today as a dated, versioned document, or is it still something you plan to write when asked?
  2. When was the last update, and what triggered it — a full review cycle, a specific finding, or nothing (which means no update has happened)?
  3. Open the current PMSR. For each of the eight content blocks walked through above, can you point to the paragraph or section that addresses it?
  4. Does the report summarise every data source named in the PMS plan, or does it quietly ignore the proactive sources (literature, similar-device review) because no findings came from them?
  5. Are the conclusions analytical ("the benefit-risk balance remains acceptable because X") or do they wave at "no issues found" without supporting rationale?
  6. Does the report describe at least one documented feedback loop into the risk management file or the clinical evaluation, or is the loop invisible on the page?
  7. If a competent authority requested the PMSR tomorrow, how long would retrieval take and how confident would you be in the version you handed over?
  8. Is the cadence of updates defined somewhere in the PMS plan, or is "when necessary" being interpreted as "when we remember"?
  9. Has the PMSR been reviewed against MDCG 2025-10 (December 2025) since the guidance was published?
  10. For every paragraph in the PMSR, can you trace it to Article 85 or to a specific element of the Annex III plan the report is summarising?

Frequently Asked Questions

Is the PMSR required for every Class I device?

Yes. MDR Article 85 applies to every manufacturer of Class I devices regardless of sub-category. Class I devices with a measuring function, sterile Class I devices, and reusable surgical instruments also fall under Article 85 — the notified body involvement for those sub-categories affects the conformity assessment, not the existence of the PMSR obligation.

How often must the Class I PMSR be updated?

The Regulation says "when necessary" and does not fix a calendar cadence. In practice, competent authorities and MDCG 2025-10 expect the report to reflect current PMS findings. Most well-run Class I systems update the PMSR annually as the baseline cadence, with interim updates driven by specific findings. "Never updated since launch" is not a defensible interpretation of "when necessary."

What is the difference between the PMSR and the PSUR?

The PMSR under Article 85 is for Class I devices; the PSUR under Article 86 is for Class IIa, IIb, and III devices. The PSUR requires three additional content elements — benefit-risk conclusions, PMCF main findings, and sales and population data — and has fixed update cadences and, for Class III and implantables, an electronic submission route via Eudamed. The PMSR has none of those extras and is made available to the competent authority upon request.

Does the PMSR have to be submitted to anyone?

No — not proactively. Article 85 requires the report to be made available to the competent authority upon request. The manufacturer does not submit the PMSR on a schedule to any body. But the report must exist before the request, not be produced retroactively.

Can the PMSR be the same document as the PMS plan?

No. The plan is forward-looking — it describes what the PMS system will do. The report is backward-looking — it summarises what the system has actually produced. They reference each other but are separate documents with different audiences and different update cycles.

What happens if the Class I device has zero complaints in a period?

The PMSR is still written. The conclusions section documents that the review cycle ran, the data sources were checked, no signals were identified, and the benefit-risk balance remains acceptable. "Zero complaints" is a finding that must be documented; silence is not a PMSR.

Does the PMSR go into Eudamed?

No. Only the PSUR for Class III and implantable devices under Article 86(2) is submitted via the Eudamed electronic system. The Class I PMSR stays in the manufacturer's technical documentation and is made available to the competent authority upon request.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 83 (post-market surveillance system of the manufacturer), Article 84 (post-market surveillance plan), Article 85 (post-market surveillance report), Article 86 (periodic safety update report), and Annex III (technical documentation on post-market surveillance). Official Journal L 117, 5.5.2017.
  2. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices. Medical Device Coordination Group, December 2025.
  3. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
  4. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.

This post is a deep dive in the Post-Market Surveillance & Vigilance series of the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The Article 85 report is the document that proves a Class I PMS system is actually doing the job the Regulation requires — lean in shape, unforgiving in content, and written before anyone asks for it.