PMSPost-Market Surveillance

Post-Market Surveillance (PMS) is the lifelong, proactive, documented programme by which a medical device manufacturer collects, analyses and acts on real-world performance and safety data once the device is on the market. It is not the same thing as complaint handling, and it is not the same thing as vigilance reporting — those are inputs. PMS is the higher-order programme that turns those inputs (plus production data, returns, service records, literature, registries, social-media monitoring, post-market clinical follow-up and competitor information) into signals, conclusions and actions that update the risk file, the technical documentation, the IFU, the labelling and ultimately the design itself.

EU MDR Article 83(1) defines it precisely: 'manufacturers shall plan, establish, document, implement, maintain and update a post-market surveillance system in a manner that is proportionate to the risk class and appropriate for the type of device.' Article 83(2) lists what that system shall do — collect, record, analyse data; use the data to update risk evaluation, design, manufacturing, IFU and labelling; trigger preventive and corrective actions; detect statistically significant increases in incidents and trends; identify need for FSCAs; and contribute to PMS reports / PSURs / SSCP updates. ISO/TR 20416:2020 provides the framework recommended by Notified Bodies to operationalise the Article 83 obligations.

EU MDR moved PMS from a back-office activity into a primary regulatory deliverable. Every device on the EU market — Class I, IIa, IIb and III — must have a PMS plan (Article 84) and produce either a PMS report (Class I, Article 85) or a Periodic Safety Update Report (Class IIa, IIb, III; Article 86). PSURs are reviewed by the Notified Body and (for Class III and implantable IIb) uploaded to EUDAMED. Class III SSCPs (Article 32) summarise the safety + clinical performance for the public-facing summary. The PMS plan is part of the Technical Documentation (Annex II §1.1(j)). A missing or weak PMS plan is a Notified Body major non-conformity that prevents CE certificate issuance or renewal.

On the FDA side, PMS sits under three regulations. 21 CFR 822 lets FDA order specific post-market surveillance studies for Class II and Class III devices (e.g. when a device is implanted for more than a year, intended to support life). 21 CFR 803 (MDR) and 21 CFR 806 (Reports of Corrections and Removals) cover the reporting half. QSR/QMSR §820.198 and §820.100 require complaint handling and CAPA, which together form the day-to-day PMS engine even though the words 'post-market surveillance' do not appear in §820. The QMSR transition (effective 2 February 2026) does not change this; the ISO 13485:2016 §8.2 / §8.5 expectations are the new operative text.

Beyond compliance, PMS is the cheapest reliability programme a manufacturer has. Early signal detection on a complaint cluster can prevent a recall. A PMCF that confirms long-term performance defends the CE certificate. A trend that shows usability difficulty in a sub-population can be corrected with an IFU update before it becomes a vigilance event. Companies that do PMS well are the companies that avoid recalls; companies that do PMS poorly are the companies that show up in the recall newsletter.

Annex III §1.1 lists the required content of the PMS plan. A defensible plan covers each of the following with specifics — not template platitudes:

1. Description of the PMS information sources — complaints, vigilance reports, service reports, returns/RMAs, distributor feedback, literature reviews, similar-device registries, post-market clinical follow-up studies, social media monitoring, competitor product information, regulatory authority feedback.
2. Procedures and methods for assessing collected data — how often each source is reviewed, by whom, with what tools, against what thresholds. Statistical methods used for trend detection where applicable.
3. Quality / performance / safety indicators — the metrics that will be tracked, their data sources, their reporting cadence, and the action thresholds.
4. Investigation and trend-reporting procedures — what counts as a signal, who investigates, what evidence is collected, how trends are reported.
5. Tools and procedures for communicating with competent authorities, Notified Bodies, economic operators and users — including FSCA and FSN procedures.
6. Procedures to fulfil vigilance obligations (Articles 87-92) — the connection between the daily complaint workflow and the regulatory-clock workflow.
7. Systematic procedures for identifying CAPA — the criteria that escalate a signal into a CAPA.
8. Effective tools for tracing devices in the field that may require corrective action — UDI lookup, distribution database, FSN distribution mechanism.
9. PMCF plan or justification for non-applicability — for higher-risk devices, the proactive plan to generate ongoing clinical data through the lifecycle.

A robust PMS programme does not rely on complaints alone; complaints are the largest source but also the most biased (under-reporting in lower-severity events, channel bias). The full input map should at minimum cover:

• Customer complaints — every channel (phone, email, web form, sales/field, distributor return, social media monitoring, regulator forwarding). Captured per /glossary/customer-complaint.
• Vigilance / MDR / MedWatch reports — internal regulatory submissions cross-referenced into the PMS dataset.
• Service reports and field intervention records — what was repaired, replaced, recalibrated, and why.
• Returns / RMAs — root-cause-coded returns even when no complaint was raised.
• In-house complaint pre-cursors — quality-hold lots, post-release deviations affecting marketed lots, supplier-driven changes that affected released lots.
• Post-market clinical follow-up (PMCF) — proactive clinical data per MDCG 2020-7 / 2020-8.
• Literature surveillance — scheduled searches across PubMed, EMBASE and similar; competitor product safety signals where they affect risk-file inputs.
• Registries — implant / device registries (e.g. NJR for hip/knee implants, RCSI for cardiac devices).
• Distributor / dealer feedback channels — formal cadence for first-line feedback.
• Authorised representative correspondence — questions from competent authorities forwarded by the EU REP / UK REP.
• Social media monitoring — structured monitoring for high-volume consumer-facing devices.
• User-experience research and customer satisfaction surveys — supplementary qualitative input.
• Internal audit findings and CAPA outcomes — the QMS feedback loop into PMS.

Each input should be funnelled into a structured dataset (per Annex III §1.2) that allows trend analysis across all of them, not just within one channel at a time. A complaint cluster that does not look significant alone may look highly significant when combined with a returns cluster and a service-call cluster on the same root cause.

EU MDR Article 83(3)(c) explicitly requires the PMS system to 'enable the manufacturer to identify any need to apply immediate corrective action; corrective action; preventive action' and 'serve as an input into the process of updating the benefit-risk determination'. Article 88 separately requires reporting to competent authorities of any 'statistically significant increase in the frequency or severity of incidents that are not serious incidents or of expected side-effects'. The PMS plan must define what 'statistically significant' means for each indicator.

Practical signal-detection patterns:

• Volume-based — rolling 13-month chart of complaints per unit sold; flag when current month exceeds upper control limit (typically mean + 3σ on log-normalised data).
• Severity-based — % of complaints classified critical or major; flag when severity mix shifts upward regardless of total volume.
• Code-based — Pareto by failure code; flag when a code's contribution to total exceeds threshold, or when a previously-rare code starts trending.
• Site / lot / operator-based — distribution by manufacturing site, by lot, by production operator team; flag concentration that suggests a process driver rather than a use driver.
• User / geography-based — distribution by user (hospital, end-customer), by country; flag concentration that suggests a training or environmental driver.
• Time-from-deployment-based — complaint cluster by months-in-service; flag a wear-out failure shifting earlier (reliability degradation).
• Risk-file-based — incidents mapped to hazards in the RMF; flag when an incident occurs that the RMF marked as effectively controlled (residual risk acceptable) — that signal demands an RMF update.
• Cumulative-similar-event — count of similar non-serious incidents that, in aggregate, may meet the Article 88 'statistically significant' threshold for reporting.

Annex XIV Part B of EU MDR requires manufacturers of higher-risk devices to perform PMCF as part of the PMS system. PMCF is proactive — it generates new clinical data on the marketed device, in real-world use, throughout its lifecycle. The aims (Annex XIV Part B §6.1): confirm safety and performance throughout the expected lifetime; identify previously unknown side-effects and monitor known ones; identify and analyse emergent risks; ensure continued acceptability of the benefit-risk ratio; identify possible systematic misuse or off-label use.

MDCG 2020-7 specifies the PMCF plan content (objectives, methods, evaluation criteria, time schedule). MDCG 2020-8 specifies the PMCF evaluation report (data analysis, conclusions, impact on risk-benefit). Both are de-facto mandatory templates as far as Notified Bodies are concerned. Acceptable PMCF methods include: prospective single-arm or comparative studies; device registries; user surveys with structured outcome measures; structured retrospective reviews; literature analyses where they generate device-specific outcome data. The choice should match the device's risk profile and the open questions in the clinical evaluation.

Where PMCF is judged not applicable, the manufacturer must produce a documented justification — accepted by the Notified Body — explaining why generic PMS data is sufficient for that device. The justification bar is high for Class IIb and Class III; routine for Class I.

Article 85 PMS Report (Class I): summary of results and conclusions of the PMS data analyses, plus rationale and description of any preventive / corrective actions taken. Updated when necessary; available to competent authority on request. No mandatory submission cadence.

Article 86 PSUR (Class IIa annually-or-better, IIb annually, III annually with submission to NB): all the PMS report content above plus the conclusions of the benefit-risk determination, the main findings of PMCF, the volume of sales, the size and other characteristics of the population using the device, and the usage frequency of the device. Class III and implantable IIb PSURs are submitted to the Notified Body and uploaded to EUDAMED; Class IIb (non-implantable) and Class IIa PSURs are submitted on competent authority or Notified Body request. MDCG 2022-21 specifies the recommended structure.

Expected PSUR sections (per MDCG 2022-21): administrative information; executive summary; description of the device and target population; status of PSUR / SSCP / risk management; data sources; sales and usage data; complaints and FSCAs; PMCF activity and results; trend analysis; benefit-risk evaluation; conclusions on the state of the device's safety/performance; planned actions for the next period.

ISO 14971 §10 (production and post-production information) is the explicit handshake between PMS and risk management. PMS data feeds §10.2 (information collection), §10.3 (information review), §10.4 (actions). When a PMS signal indicates a previously-unidentified hazard or that residual-risk acceptability is no longer supported, the risk-management file is updated and the change-control process begins. If the change touches the design, §820.30(i) / §7.3.9 design-change controls apply, with regulatory-impact assessment (new 510(k)? PMA supplement? significant-change notification under MDR Article 120?).

A defensible chain in audit looks like: complaint received → trend signal detected → investigation closed → risk-file review opened → residual risk re-evaluated → CAPA opened → design change initiated → V&V repeated → design transfer updated → DMR updated → eDHR template updated → FSN/IFU update issued where necessary → PSUR records the closed-loop action. Every link in that chain is timestamped and signed; the chain is the proof that PMS is more than a data-collection exercise.

Vigilance is the regulatory-reporting half: serious incidents on the 2/10/15-day clock per MDR Articles 87-92; MDR/MedWatch 5/30-day clock per 21 CFR 803; field safety corrective actions and field safety notices per MDR Article 89. Vigilance is a subset of PMS — it is the highest-severity portion that requires regulator notification. PMS is the broader programme that includes vigilance plus complaint trending, non-serious incident analysis, PMCF, literature, registries and all the other input streams. An inspector who asks for the vigilance log and the PMS plan as separate documents expects to see them connect: every vigilance event should also appear in the PMS dataset, with trend implications captured.

Common 483/Notified Body finding: vigilance reporting on the clock, but no evidence that the same event was incorporated into the PMS trend analysis. Vigilance without PMS integration is reporting without learning.

• No PMS plan, or a PMS plan that is a template with no device-specific content.
• PMS plan exists but PMS data is not actually collected against its indicators.
• Trend thresholds undefined or set after the fact so nothing triggers an alert.
• Complaint trending performed but not linked to risk-file review.
• PSUR overdue, missing required content per MDCG 2022-21, or not uploaded to EUDAMED for Class III / implantable IIb.
• PMCF judged 'not applicable' without a credible, NB-accepted justification.
• PMCF plan exists but is not executed on schedule, or evaluation report not produced.
• Vigilance events not back-reflected in the PMS dataset / trend analysis.
• FSCA decisions made without a documented Article 89 decision rationale.
• Statistically significant trends per Article 88 not reported.
• SSCP not updated based on PSUR conclusions (Class III / implantable).
• PMS conclusions do not result in updates to risk file, IFU or labelling when the data warrants it.
• Distributor and AR feedback channels named in the plan but not actually receiving structured input.
• Literature surveillance scheduled but no evidence of execution; searches not documented with date, terms, hits and dispositions.
• Management review does not include PMS / PSUR conclusions as inputs.

• On-time PSUR submission rate (target 100%).
• Time from PSUR submission to NB acknowledgement (where applicable).
• Number of open PMS signals by status (under triage / under investigation / under CAPA / closed).
• Median time from signal detection to investigation closure.
• Number of PMS-driven risk-file updates per period.
• Number of PMS-driven design changes per period.
• Number of FSCAs initiated per period and median time from decision to FSN distribution.
• Article 88 'statistically significant trend' reports filed.
• Vigilance-PMS reconciliation rate (% of vigilance events represented in the trend dataset).
• PMCF plan adherence (% of planned activities executed on schedule).
• Literature-surveillance execution rate against schedule.
• Distributor / AR feedback receipts per period — flag silent channels.

V5 Ultimate models PMS as a device-scoped programme inside the QMS that draws from every existing data source automatically. Complaints, vigilance reports, NCRs, returns, service records, distributor feedback, AR correspondence, literature searches, registry feeds and PMCF results all stream into a single PMS dataset, tagged by device family, lot, site, operator team, geography, severity, failure code and risk-file hazard.

The PMS plan is a controlled document with the Annex III §1.1 sections enforced. Each indicator defined in the plan generates an automated dashboard tile with the pre-approved threshold; a breach raises a PMS signal task with owner and SLA. The signal-detection engine runs the volume, severity, code, site/lot/operator, geography and time-from-deployment trend analyses described above and flags both single-incident escalations and slow-burn aggregate trends.

PSURs and PMS reports are assembled live from the dataset against the MDCG 2022-21 / Article 85 structures. Sales and usage data flow in from the ERP integration; complaint and FSCA data from the QMS; PMCF results from the clinical workspace; literature surveillance from the scheduled-search log. The reviewer signs off section-by-section under two-person e-signature with the full audit trail. The completed report is locked and version-controlled, with the EUDAMED upload payload generated for Class III / implantable IIb.

PMCF activity is managed as a sub-programme with plan, schedule, milestone deliverables and evaluation report — all referencing the MDCG 2020-7 / 2020-8 templates by section. PMCF data flows into the PMS dataset and into the next PSUR automatically.

Closing the loop is the design point: a PMS signal that updates the risk file opens an ISO 14971 §10 record; a risk-file update that requires a design change opens a §820.30(i) / §7.3.9 design-change record with regulatory-impact assessment; a design change that warrants a customer notification opens an FSN distribution workflow with UDI-based reach calculation. Every link is timestamped, signed and walkable both forward and backward at inspection — the chain that proves PMS is the closed-loop reliability programme it is supposed to be.