Post-market surveillance under MDR is the manufacturer's ongoing, proactive system for collecting and analysing real-world data on a device after it has been placed on the market, and for acting on what that data shows. The obligation is set out in Articles 83 to 86 of Regulation (EU) 2017/745 and the technical documentation requirements are fixed in Annex III. PMS is not vigilance and it is not clinical follow-up — it is the umbrella system that feeds both. Every manufacturer of every class of device must have one, proportionate to the risk class and the type of device.

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

TL;DR

  • Post-market surveillance is required by MDR Article 83 for every manufacturer, regardless of device class. It is a proactive, planned system — not a reaction to complaints.
  • The PMS plan is a technical documentation requirement under Annex III. Without it, the technical file is incomplete and the device cannot be CE marked.
  • Class I devices document their PMS in a PMS Report (Article 85). Class IIa, IIb, and III devices document it in a Periodic Safety Update Report, or PSUR (Article 86).
  • PMS feeds directly back into risk management under EN ISO 14971:2019 + A11:2021 and into the clinical evaluation update cycle under Article 61 and Annex XIV Part B.
  • MDCG 2025-10 (December 2025) is the current operational guidance on how PMS systems should work in practice, including for startups with small teams.

Why this matters — the sleep device that passed every lab test

A small MedTech company we worked with built a sleep-monitoring device with a sensor that strapped to the upper arm. The casing was a combination of plastic and a textile blend — the kind of detail that looks trivial on a bill of materials and turns into a real problem on a patient's skin. Biocompatibility testing was done per EN ISO 10993-1 before market. Everything passed. The notified body accepted the file. The product launched.

And then, weeks into real-world use, the complaints started. Skin irritations. Mostly mild, a few not mild. The pattern was consistent: extended wear, perspiration, and the specific textile-polymer interface that had never been tested against weeks of continuous contact in real conditions. Lab testing did what lab testing does — it simulated. Real users did what real users do — they wore it overnight, for months, sweating, sleeping, moving.

This is the story that ends the debate about whether PMS is bureaucracy. The lab passed. The regulatory file passed. The patients still got hurt. The only reason the problem was caught, traced, and fixed before it escalated was that a PMS system was actually running — logging complaints, trending them against expected rates, flagging the correlation, and triggering a corrective action that updated the material specification. PMS is the safety mechanism that catches what pre-market evidence cannot. That is not a philosophical statement. That is what happened to an arm strap on a real device.

Which is why the Regulation treats PMS as a core obligation, not a formality. And why understanding it matters before you ship.

PMS, vigilance, and PMCF — the triangle

One of the most persistent confusions in startup regulatory work is the relationship between three terms that get used interchangeably and are not interchangeable. Before anything else in this post, fix the distinction in your head.

Post-market surveillance (PMS) is the umbrella system. Article 83(1) of Regulation (EU) 2017/745 requires manufacturers to plan, establish, document, implement, maintain, and update a post-market surveillance system. It is proactive, systematic, and continuous. The PMS system collects every kind of real-world data about a device — complaints, incidents, literature, user feedback, trend data, service records, and more — and analyses it to identify whether the device still performs as intended and whether the risk-benefit balance remains acceptable.

Vigilance is a subset of what the PMS system feeds. Articles 87 to 92 of the MDR govern the reporting of serious incidents and field safety corrective actions to the competent authorities. Vigilance is reactive and time-bound: when a serious incident occurs, specific reporting deadlines apply. A PMS system is what surfaces incidents in the first place, assesses them, and triggers the vigilance reporting process when the thresholds are met. MDCG 2023-3 Rev.2 (January 2025) is the current Q&A guidance on vigilance terms and concepts, including the distinction between incidents and serious incidents. Vigilance is not PMS. Vigilance is what PMS escalates into when something bad happens.

Post-market clinical follow-up (PMCF) is the clinical side of PMS. Annex XIV Part B of the MDR requires manufacturers to proactively collect and evaluate clinical data from the use of a device that is CE marked and placed on the market. PMCF is how the clinical evaluation is kept current during the device lifecycle. It is a specific activity within the broader PMS system, with its own plan and its own report. Article 61(11) connects PMCF back to the clinical evaluation update cycle.

The cleanest way to hold these three in mind: PMS is the system, PMCF is the clinical arm of the system, and vigilance is the regulatory reporting channel the system feeds when certain thresholds are crossed. Founders who collapse the three into one word — usually "PMS" — end up building a system that does one job and misses the other two.

For the deep dive on vigilance specifically, see what is vigilance under MDR. For PMCF, see PMCF under MDR — a guide for startups.

What Articles 83 to 86 actually require

The core obligation lives in four articles. Each one addresses a different layer.

Article 83 — the PMS system. Every manufacturer must plan, establish, document, implement, maintain, and update a post-market surveillance system that is proportionate to the risk class and appropriate for the type of device. The system must be an integral part of the manufacturer's quality management system under Article 10(9). It must actively and systematically gather, record, and analyse relevant data on the quality, performance, and safety of the device throughout its entire lifetime. The findings of the PMS system must be used to update the benefit-risk determination, update the design and manufacturing information, update the clinical evaluation, update the summary of safety and clinical performance where applicable, identify needs for preventive or corrective action, and identify options to improve the usability, performance, and safety of the device. This is a long list of obligations written into a single article. Every one of them has teeth at audit.

Article 84 — the PMS plan. The plan is the document that describes how the PMS system actually works for a specific device. It is part of the technical documentation and is specified in detail in Annex III. The plan says what data will be collected, from which sources, how it will be analysed, what the trigger criteria are for corrective action, and how the findings will feed into the other QMS processes. Article 84 makes the plan explicit because without it, PMS becomes a post-hoc exercise driven by whatever complaints happen to come in — which is the opposite of the proactive system the Regulation requires.

Article 85 — the PMS Report for Class I devices. Manufacturers of Class I devices prepare a post-market surveillance report summarising the results and conclusions of the analyses of PMS data gathered under the PMS plan, together with a rationale and description of any preventive and corrective actions taken. The report is updated when necessary and made available to the competent authority upon request.

Article 86 — the PSUR for Class IIa, IIb, and III devices. Manufacturers of Class IIa, IIb, and III devices prepare a Periodic Safety Update Report for each device and, where relevant, for each category or group of devices. The PSUR summarises the results and conclusions of the analyses of the PMS data, together with a rationale and description of any preventive and corrective actions taken. The PSUR also states the conclusions of the benefit-risk determination, the main findings of the post-market clinical follow-up, and the volume of sales of the device and an estimate of the size and other characteristics of the population using the device and, where practicable, the usage frequency of the device. The PSUR is updated at least annually for Class IIb and Class III devices. For Class IIa devices, the PSUR is updated when necessary and at least every two years. For Class III devices and implantable devices, the PSUR is submitted via the electronic system to the notified body involved in the conformity assessment and is made available through the electronic system to the competent authorities.

For the article-by-article walkthrough with examples, see MDR Articles 83 to 86 — the PMS framework explained.

The PMS plan — what Annex III demands

Annex III of the MDR specifies the technical documentation on post-market surveillance. It is short, dense, and non-negotiable. The plan has to address at least the following elements — paraphrased here in plain language, with the caveat that the Annex text itself is the authoritative source.

The plan describes the processes for collecting and using the available information, in particular complaints and reports from healthcare professionals, patients, and users on their experience with the device; information from similar devices on the market; publicly available information about similar devices and state-of-the-art evaluations; and relevant data on serious incidents, including information from Periodic Safety Update Reports and field safety corrective actions.

The plan sets out effective and appropriate methods and processes to assess the collected data. It describes the tools used to investigate complaints and analyse market-related experience collected in the field. The plan specifies the methods and protocols to manage events subject to trend reporting under Article 88, including the methods and protocols for identifying any statistically significant increase in frequency or severity of incidents. It describes the methods and protocols for communicating effectively with competent authorities, notified bodies, economic operators, and users. It references the procedures to fulfil the manufacturer obligations laid down in Articles 83, 84, and 86. It sets out systematic procedures to identify and initiate appropriate measures including corrective actions. It describes effective tools to trace and identify devices for which corrective actions might be necessary. And it includes a PMCF plan, or a justification as to why PMCF is not applicable.

The PMCF plan itself is specified in Annex XIV Part B, and it is a separate document inside the broader PMS plan structure. For a startup, the critical move is understanding that Annex III does not require a specific template — it requires that the plan actually addresses each of these elements in a way that is traceable and auditable. Elegant structure beats elaborate volume.

For the full walkthrough of building a PMS plan against Annex III, see the PMS plan under MDR Annex III.

Class I PMS Report versus higher-class PSUR — what actually differs

A common startup question: why does the Regulation distinguish between the PMS Report (Class I) under Article 85 and the PSUR (Class IIa, IIb, III) under Article 86, and what does the difference actually mean for my documentation?

The short answer is that the Regulation scales the rigour of the post-market report to the risk class of the device. The longer answer has four dimensions.

Content. The PMS Report under Article 85 summarises the results and conclusions of the PMS data analyses and describes any preventive and corrective actions taken. The PSUR under Article 86 adds explicit requirements: the conclusions of the benefit-risk determination, the main findings of the PMCF, and the volume of sales plus an estimate of the population using the device and the usage frequency where practicable. The PSUR is a more substantive document because the devices it covers are higher risk and therefore warrant richer post-market scrutiny.

Update frequency. The PMS Report for Class I devices is updated when necessary. The PSUR for Class IIa devices is updated when necessary and at least every two years. The PSUR for Class IIb and Class III devices is updated at least annually. The frequency is set by the Regulation itself, so there is no negotiation on the update rhythm.

Submission route. The PMS Report for Class I devices is made available to the competent authority upon request. The PSUR for Class IIa and IIb devices is made available upon request. The PSUR for Class III devices and implantable devices is submitted via the Eudamed electronic system to the notified body involved in the conformity assessment, and is made available through the electronic system to competent authorities. This is a meaningful difference: for high-risk devices, the PSUR becomes part of an active regulatory dialogue, not a document that sits in a drawer waiting for a request.

Notified body involvement. For Class IIa, IIb, and III devices, the notified body evaluates the PSUR and adds its evaluation to the electronic system for Class III and implantable devices, along with the action taken. This is not a rubber stamp. An auditor who reads a weak PSUR will press on it.

For startups shipping their first device, the practical takeaway is: know which report the Regulation requires for your class, build the PMS system to produce it on the correct cadence from day one, and do not assume a Class I lean path means a Class IIa lean path. For Class I specifics, see the PMS Report for Class I devices. For PSUR mechanics, see PSUR for Class IIa, IIb, and III devices under MDR.

How PMS feeds risk management and clinical evaluation

PMS does not exist as an isolated process. Two of the most important MDR documents — the risk management file and the clinical evaluation — both depend on PMS data to stay current. A PMS system that does not feed these two loops is a PMS system that is broken.

Risk management feedback. EN ISO 14971:2019 + A11:2021 is the harmonised standard for application of risk management to medical devices. The standard establishes risk management as a lifecycle activity, which means the risk file is not a pre-market deliverable that gets archived at CE marking — it is a living document. The feedback loop works like this: PMS data surfaces an event (a complaint, an incident, a trend). The event is assessed against the risk file. If the event represents a hazard that was not identified, or an occurrence rate higher than what the risk analysis assumed, or a severity higher than estimated, the risk file is updated. New risk control measures may be triggered. The residual risk is re-evaluated. The benefit-risk determination is refreshed. And the updated risk file feeds back into the design, the instructions for use, or the labelling, depending on what the analysis concludes. Article 83 makes this loop explicit by naming the update of the benefit-risk determination as one of the required uses of PMS findings.

The sleep arm strap story from earlier in this post is exactly this loop in action. The skin irritations were a PMS signal. The signal was assessed against the risk file. The risk of prolonged skin contact under perspiration was upgraded. The material specification was updated. The labelling and IFU were refreshed. The loop closed.

Clinical evaluation feedback. MDR Article 61 and Annex XIV Part B require the clinical evaluation to be updated throughout the lifetime of the device with data obtained from the PMCF plan. Clinical evaluation is not a one-shot pre-market exercise. PMCF data — from real-world use, registries, literature, or follow-up studies — feeds back into the clinical evaluation report, which in turn feeds back into the conclusions about clinical performance and clinical safety. For higher-class devices, the PSUR under Article 86 explicitly names the main findings of the PMCF as a required element, which ties the clinical feedback loop directly to the post-market report.

Auditors know these loops exist and they look for them. A PMS plan that does not explain how findings flow into risk management and clinical evaluation is a PMS plan that will generate questions at audit.

Real-world signals auditors expect to see

When a notified body auditor reviews a PMS system at audit, they are not asking "do you have a binder labelled PMS." They are asking whether the system actually runs. MDCG 2025-10 (December 2025) is the current operational guidance on how PMS systems should work in practice, and it is the document to read before an audit. A few of the signals that separate a real PMS system from a decorative one:

  • Complaint intake exists, is logged, has a timestamp, has an owner, and produces an assessment within a defined timeframe.
  • Trend analysis runs on a defined cadence against defined metrics, not only when someone complains.
  • Literature monitoring is actually performed and documented, with search terms, databases, and dates.
  • Similar-device monitoring is performed and documented, with evidence of what was reviewed and when.
  • The PMS findings have a documented path into the risk file, the clinical evaluation, the CAPA system, and the change management process.
  • Vigilance thresholds are defined in the plan and the decision rule for reporting a serious incident is traceable.
  • The PMS Report or PSUR exists, is current against the class-specific cadence, and reflects the underlying data rather than being a copy-paste of the previous cycle.
  • PMCF activities are executed according to the PMCF plan, not postponed indefinitely.

A PMS system that runs on these signals will survive an audit. A PMS system that only exists on paper will not. This distinction matters more than almost any other single item in the post-market file.

One more story — the claims that outran the file

A second story worth telling here because it illustrates where PMS quietly catches problems that have nothing to do with incidents. A company we worked with had a technical file that described a specific intended purpose and a specific set of performance claims. Over time, the marketing team updated the website. New claims appeared. The product page said things the technical documentation did not support. Not dramatically — just a drift. A phrase here. A benefit there. A use case that had never been evaluated under Article 61. The technical file and the marketing material had started speaking different languages.

A functioning PMS system catches this, because monitoring the alignment between real-world claims and the authorised intended purpose is part of the scope. The intended purpose is defined in MDR Article 2(12) as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, or in promotional or sales materials or statements, and as specified by the manufacturer in the clinical evaluation. Promotional and sales materials are explicitly part of the intended purpose. A website that says more than the technical file backs up has, by definition, drifted the intended purpose — and that is a post-market signal the PMS system is supposed to surface.

The lesson is simple: PMS is not only about incidents and complaints. It is also about whether the device, as actually sold and marketed, still matches the device the file authorises. Skipping that check is one of the cheapest ways a startup can turn a clean CE marking into a non-compliance finding.

The Subtract to Ship angle — a minimal viable PMS that actually runs

The Subtract to Ship framework for MDR applied to PMS produces a clear rule: build the smallest PMS system that satisfies every Article 83 to 86 obligation for your device class, and make sure every component of that system actually runs. Everything beyond that is waste. Everything less is a non-conformity.

For a Class I startup, minimal viable PMS looks something like this.

One complaint intake channel that everyone in the company knows about and actually uses. One logging system — a spreadsheet with version control is not ideal but is better than a fancy system nobody opens. A defined review cadence, say monthly for a low-volume device, with the review documented and signed. A defined escalation rule for when a complaint becomes a potential serious incident under Article 87. A literature search performed on a defined cadence, with the search string and the databases documented. A similar-device review on a defined cadence. A PMS plan that names each of these activities and ties each to the relevant Annex III element. A PMS Report under Article 85 that is updated when necessary and summarises what the reviews actually found. And a documented feedback loop into the risk file and the clinical evaluation.

That is a lean PMS system. It is not a token PMS system — every element traces to a specific MDR obligation. But it can be run by a three-person startup without swallowing anyone's week. The two-phase development approach frames the principle more broadly: get the thing running before polishing it, and polish based on what actually happens, not what might happen.

What the minimal viable PMS does NOT include: elaborate dashboards nobody reads, Kaplan-Meier analyses for devices with no clinical investigation data, quarterly reports that repeat the previous quarter's copy, or process documents that describe activities the team does not actually perform. Every one of those is subtraction bait.

The critical move is the test from the Subtract to Ship framework: for every element in the PMS system, can you trace it to a specific article, annex, or MDCG 2025-10 section that requires it? If yes, keep it. If no, cut it. The PMS that survives this test is the PMS that actually runs, and the PMS that actually runs is the PMS that catches an arm-strap skin irritation before it becomes a safety action.

Reality Check — where do you stand?

  1. Can you point to a single document titled "Post-Market Surveillance Plan" that addresses every element of Annex III, or is your PMS scattered across multiple SOPs that never name the Annex III requirements?
  2. Do you know which class-specific post-market report applies to your device — PMS Report under Article 85, or PSUR under Article 86 — and on what cadence it must be updated?
  3. If a complaint came in tomorrow, who would log it, who would assess it, and how long until a documented decision exists? If you cannot answer in specifics, your intake process is not running.
  4. Can you demonstrate that PMS findings from the last review cycle fed into a specific update of the risk management file, the clinical evaluation, or the IFU? If no updates happened, can you document that the findings warranted no updates?
  5. Does your PMS plan include a PMCF plan, or a documented justification for why PMCF is not applicable to your device? "We forgot" is not a justification.
  6. Is there a defined trend-reporting rule for your device under Article 88, and who would detect a statistically significant increase in frequency or severity of incidents?
  7. When was the last time you monitored the alignment between your current marketing claims and the intended purpose in your technical file? If the answer is "never since launch," this is the first action to take.
  8. Have you read MDCG 2025-10 end-to-end, or have you only skimmed it?
  9. If your notified body requested the PSUR or PMS Report tomorrow, how long would it take to produce it and how confident would you be in the data behind it?
  10. For each activity in your PMS plan, can you name the specific MDR article, annex, or MDCG guidance that requires it? The activities that fail this test are the ones to cut or to justify.

Frequently Asked Questions

Is post-market surveillance required for Class I devices?

Yes. MDR Article 83 applies to every manufacturer regardless of device class. Class I devices document their PMS in a PMS Report under Article 85 rather than a PSUR, and the update cadence is "when necessary" rather than annual or biennial, but the obligation to plan, establish, document, implement, maintain, and update a PMS system is identical.

Is PMS the same as vigilance?

No. PMS is the overall system for collecting and acting on real-world device data throughout the device lifecycle. Vigilance, governed by Articles 87 to 92 of the MDR and clarified in MDCG 2023-3 Rev.2, is the time-bound reporting of serious incidents and field safety corrective actions to competent authorities. Vigilance is a subset of activities the PMS system feeds into when specific thresholds are crossed.

What is the difference between a PMS Report and a PSUR?

A PMS Report under Article 85 is required for Class I devices and contains a summary of PMS data analyses and any preventive and corrective actions taken. A PSUR under Article 86 is required for Class IIa, IIb, and III devices and contains the same summary plus the conclusions of the benefit-risk determination, the main findings of the PMCF, and sales volume and usage population data. The update frequency and submission route also differ by class.

Do I need to submit the PSUR to my notified body?

For Class III devices and implantable devices, yes — the PSUR is submitted via the Eudamed electronic system to the notified body involved in the conformity assessment. For Class IIa and Class IIb devices, the PSUR is made available upon request and the notified body involvement is handled during surveillance audits rather than continuous electronic submission. Check Article 86 for the exact requirements that apply to your class.

How is the PMS plan different from the technical documentation?

The PMS plan is part of the technical documentation. Annex III of the MDR is the section of the technical documentation that covers post-market surveillance, and the PMS plan is the central document inside Annex III. So the PMS plan is not separate from the tech file — it is a required component of it.

How often does the PMS plan itself need to be updated?

The PMS plan is a living document. It is updated whenever the PMS system changes — new data sources, new trigger criteria, new analysis methods — or whenever PMS findings reveal that the existing plan does not adequately cover the real-world risks. The Regulation does not set a calendar cadence for the plan itself; it is updated when the system changes.

What does MDCG 2025-10 add that is not in the MDR text?

MDCG 2025-10 (December 2025) is the current operational guidance on PMS for medical devices and in vitro diagnostic medical devices. It describes how the PMS system should work in practice, including the PMS plan, the main PMS activities such as data collection, assessment, and conclusions, and how PMS interacts with other QMS processes such as clinical evaluation, risk management, and vigilance. It does not override the Regulation, but it is the authoritative interpretation that notified bodies use when assessing PMS systems.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2(12) (intended purpose), Article 10 (general obligations of manufacturers), Article 61 (clinical evaluation), Articles 83 to 86 (post-market surveillance system, plan, PMS Report, and PSUR), Articles 87 to 92 (vigilance and reporting of serious incidents and FSCAs), Annex III (technical documentation on post-market surveillance), and Annex XIV Part B (post-market clinical follow-up). 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. MDCG 2023-3 Rev.2 — Questions and Answers on vigilance terms and concepts as outlined in Regulation (EU) 2017/745 and Regulation (EU) 2017/746. Medical Device Coordination Group, first publication February 2023; Revision 2, January 2025.
  4. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
  5. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.

This post is the pillar of the Post-Market Surveillance & Vigilance series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. For the specific PMS questions that every startup eventually hits — plan structure, PSUR cadence, vigilance thresholds, PMCF scoping — follow the spoke posts linked above, which each take one piece of this framework and walk it all the way through.