This guide covers what a compliant PMS system looks like, what documents you need to produce for each device class, what data sources MDR expects you to use, and how to build a program that functions as a real quality system — not just paperwork.

What EU MDR requires for post-market surveillance

EU MDR Articles 83 through 86 form the legal framework for post-market surveillance. Each article covers a distinct element:

• Article 83 defines the manufacturer’s obligation to plan, establish, document, implement, maintain, and update a post-market surveillance system for each device
• Article 84 specifies what a Post-Market Surveillance Plan (PMSP) must contain
• Article 85 requires a Post-Market Surveillance Report (PMSR) for Class I devices
• Article 86 requires a Periodic Safety Update Report (PSUR) for Class IIa, IIb, and III devices

The European Commission’s Medical Device Coordination Group published MDCG 2025-10 guidance providing updated interpretation of these PMS requirements, reflecting findings from notified body audits across the EU. The guidance confirms that PMS must be a living, data-driven process — not a static document produced at certification time.

PMS plan vs PMS report vs PSUR: what each document is

Many quality teams conflate these documents. They serve different purposes and have different update frequencies.

Post-Market Surveillance Plan (PMSP)

The PMSP, required under Article 84, describes how you will collect and analyze post-market data for a specific device. It must cover:

• The proactive and reactive data collection methods you will use
• Performance indicators and thresholds that would trigger action
• Reference to applicable standards and guidance documents
• Specific timelines for data collection and review activities
• How findings will feed back into your risk register, clinical evaluation, and technical documentation

The PMSP is part of your technical documentation and must be device-specific. A single generic PMSP for all products does not satisfy MDR.

Post-Market Surveillance Report (PMSR) — Class I devices

For Class I devices, Article 85 requires a PMSR that summarizes the results of your PMS activities, states whether corrective or preventive measures are needed, and confirms the benefit-risk determination remains favorable. There is no mandatory update frequency stated in Article 85 — the PMSR is updated when significant changes occur or when new information from PMS activities warrants it. Notified bodies have generally interpreted “when needed” to mean at least every two to three years.

Periodic Safety Update Report (PSUR) — Class IIa, IIb, and III

The PSUR under Article 86 has defined update requirements. Class IIa devices: PSUR updated at minimum every two years. Class IIb and III devices: PSUR updated annually. For Class III and implantable Class IIb devices, the PSUR is submitted to the notified body and assessed as part of the conformity assessment process.

The PSUR must include: a summary of PMS data, conclusions of benefit-risk analysis, a summary of any FSCA/field safety corrective actions taken, results of post-market clinical follow-up (PMCF) if applicable, and proposed corrective and preventive actions.

Data sources your PMS system must use

Article 83 MDR specifies that the PMS system must gather, record, and analyze relevant data from the post-production phase. Article 84(a) provides a list of data sources. Your PMSP should address each of these explicitly:

Complaints and feedback

Your complaint handling process feeds directly into PMS. Every complaint, whether from users, patients, healthcare professionals, or distributors, is post-market data. The PMS system should analyze complaint trends — not just individual incidents — to identify signals that may not be visible at the single-event level.

Vigilance and serious incident reporting

Serious incidents and field safety corrective actions (FSCAs) reported under MDR Article 87 are both inputs to your PMS system and outputs from it. If your PMS data analysis identifies a pattern that meets the serious incident threshold, that triggers the vigilance reporting obligation. The two systems are connected.

Literature surveillance

Article 84(d) requires manufacturers to monitor scientific and technical publications relevant to their device, including equivalent devices. This means a structured, documented literature search — not an informal awareness of publications. The MDCG 2020-6 guidance on clinical evaluation describes the search methodology in detail, and the same methodology applies to ongoing PMS literature review.

Registries and real-world data

For implantable devices and Class III devices, MDR expects manufacturers to draw on device registries where they exist. In practice, this means monitoring national registries in EU member states where your device is marketed, and documenting what that monitoring showed.

Social media and user feedback

MDCG 2022-21 confirms that social media monitoring can be a PMS data source — specifically for identifying safety concerns that do not reach you through formal complaint channels. This is not a major burden for most manufacturers, but it should be addressed in your PMSP.

Distributor and importer reports

If you have authorized representatives, importers, or distributors in the EU, they have obligations under Articles 13 and 14 MDR to pass information relevant to PMS back to you. Your quality agreement with these parties should specify what they are required to report and how frequently.

Post-Market Clinical Follow-Up (PMCF)

PMCF is a specific subset of PMS. It covers the ongoing collection of clinical data on a device already on the market, to confirm continued safety and performance, identify emerging risks, and monitor long-term outcomes.

PMCF is required for all Class III devices and implantable devices by default. For other classes, PMCF is required unless the manufacturer can justify why it is not necessary — and that justification must be documented in the PMCF evaluation report.

PMCF activities include device registries, post-market clinical studies, surveys of users and patients, and systematic literature review. The plan for PMCF goes into Annex XIV Part B of your technical documentation. Results feed into the PSUR and the clinical evaluation report.

How PMS connects to your broader QMS

PMS does not operate as a standalone activity. The outputs of your PMS system are inputs to multiple parts of your quality management system:

• Risk management — PMS data may reveal new hazards or change probability/severity estimates for known risks. Your risk register should be updated when PMS findings warrant it.
• Clinical evaluation — the PSUR feeds back into the clinical evaluation report. Changes in the benefit-risk assessment must be reflected in both documents.
• CAPA — when PMS identifies a trend or signal requiring action, that action is processed through your CAPA system.
• Design control — significant PMS findings may indicate that design outputs need to be revisited. This can trigger a design change review under your change management process.
• Labeling and IFU — if PMS reveals that users are misusing the device in ways that could cause harm, labeling changes may be required.

This interconnection is exactly why MDR requires the PMS system to be fully integrated with the quality management system — not managed by regulatory affairs as a separate workstream with no links to quality events or risk files.

Common gaps notified bodies find during technical documentation review

Generic PMS plans not tailored to the device

A PMS plan that applies identical data sources, indicators, and review timelines to a Class I bandage and a Class IIb active implant will not satisfy MDR. Notified bodies flag this repeatedly. The PMSP must reflect the specific risk profile, intended use, user population, and regulatory history of the device it covers.

No defined action thresholds

Article 84 requires the PMSP to specify performance indicators and threshold values. Many manufacturers describe data collection activities but never state what result would trigger a response. If you collect complaint data but never defined the rate at which complaints become a signal, your PMS system cannot generate actionable output.

Literature searches that are too narrow

MDCG guidance confirms that literature surveillance must cover equivalent devices, not just your own device. A search limited to your own product name will miss clinical evidence on comparable devices that may be relevant to your benefit-risk assessment.

PMSR and PSUR not updated after significant events

If a serious incident occurred, an FSCA was issued, or a complaint trend was identified and resolved, the PMSR/PSUR should reflect it. Documents that look unchanged from the original submission despite real-world events in the interim draw immediate scrutiny from notified bodies and national competent authorities.

No documented connection between PMS and risk management

Notified bodies look for evidence that PMS outputs actually influenced risk management decisions. If your PMS reports are produced and filed but never change anything in your risk file or CAPA system, auditors will question whether the system is active or purely procedural.

Building the PMS system in your QMS

The practical challenge for most manufacturers is that PMS data flows in from multiple sources — the complaint system, vigilance reports, literature searches, registry monitoring, distributor reports — and needs to be consolidated, trended, analyzed, and documented in a format that produces the PMSR or PSUR on a defined schedule.

Paper-based PMS systems fail at this. Data sits in separate folders for each source, trending requires manual compilation, and producing the PSUR involves weeks of document assembly. By the time the document is ready, the analysis is already outdated.

Cloudtheapp’s quality management platform connects complaint handling, CAPA, adverse event tracking, and risk management in a single system. PMS data collected through complaints, deviations, and adverse event records feeds automatically into dashboards that support PMSR and PSUR preparation. When a CAPA is opened in response to a PMS finding, it is linked to the originating PMS record — giving you the audit trail MDR requires showing that findings drove action.

Want to see how Cloudtheapp handles post-market surveillance documentation for Class IIa, IIb, and III devices? Book a demo to walk through the system with a specialist.

Notified body and competent authority access to PMS data

Under MDR Article 83(4), national competent authorities have the right to request access to post-market surveillance data. For Class IIb and III devices, the PSUR is submitted to your notified body and subject to formal assessment. This means your PMS records need to be retrievable, coherent, and complete — not reconstructed when a request arrives.

The EUDAMED database, as it reaches full functionality, will include modules for vigilance and post-market surveillance data. Manufacturers are expected to upload incident reports and summaries of safety and clinical performance (SSCPs) for implantable and Class III devices directly to EUDAMED. The timeline for full EUDAMED go-live has shifted several times; confirm current requirements with your notified body.

Summary

A compliant EU MDR post-market surveillance program has five elements that all need to work together: a device-specific PMSP with defined data sources and action thresholds, active data collection from complaints, vigilance, literature, registries, and distributor networks, a systematic analysis process that produces trend data and signals, PMSR or PSUR documentation produced on the correct schedule, and documented connections between PMS outputs and risk management, CAPA, and design changes.

The companies that struggle with MDR PMS compliance are generally those that treat it as a documentation obligation rather than a quality function. The regulation is designed for manufacturers that actually use post-market data to improve their devices. Build the system around that intent, and the documentation follows naturally.

Cloudtheapp’s 60+ quality and compliance applications cover complaint management, CAPA, adverse events, and risk management — all of the functions that feed your PMS system. Schedule a demo to see how it all connects.

This post created by and appeared first on Cloudtheapp