Postmarket Surveillance

This topic is part of the SG Systems Global medical device lifecycle, vigilance & regulatory compliance glossary.

Updated December 2025 • Medical Device QMS, Medical Device Reporting (MDR), MedWatch Form, Customer Complaint Handling, CAPA, QRM, PQR, APR, Data Integrity, QMS, V5 QMS, V5 MES

Postmarket Surveillance (PMS) is everything you do to understand how your medical device actually behaves once it leaves the clean controlled world of development and enters messy real life. It is the structured, proactive system for collecting, analysing and acting on safety, performance and quality data after launch – complaints, adverse events, MDRs, recalls, real‑world evidence, registry data, literature, usability feedback and more. In the US and EU, PMS is not optional “nice‑to‑have monitoring”; it is a legal requirement baked into device regulations and your QMS.

Regulators use PMS to close the loop: premarket submissions are based on clinical and bench data under defined conditions, but postmarket surveillance shows whether the benefit–risk profile actually holds across broader populations, indications, users and environments. For manufacturers, PMS is the early‑warning radar that catches weak signals before they become headline‑level crises or consent decrees.

“If the first time you really understand your device in the field is when lawyers get involved, you didn’t have postmarket surveillance – you had wishful thinking.”

1) What Postmarket Surveillance Actually Is

Postmarket Surveillance for medical devices is a defined system inside your QMS that:

• continuously gathers information about device performance and safety once in routine use,
• analyses that information for trends, signals and emerging risks,
• triggers corrective and preventive action where needed, and
• feeds updated evidence into labeling, risk management, design, clinical evaluation and regulatory submissions.

Critically, PMS is proactive and systematic – not just reacting to the loudest complaint. EU guidance explicitly frames PMS as a comprehensive system that collects experience from real‑world use and connects to vigilance and market‑surveillance activities, as well as CAPA and technical‑documentation updates.:contentReference[oaicite:2]{index=2} FDA describes MDR and related tools as core postmarket mechanisms to monitor device performance and inform benefit–risk decisions over the product lifecycle.:contentReference[oaicite:3]{index=3}

2) Why PMS Exists (Regulatory and Practical Rationale)

Premarket data are necessary but never sufficient:

• Clinical studies are usually smaller, more controlled and shorter than real‑world use.
• Off‑label use, comorbidities, user error, misuse and mixed product combinations create scenarios not seen premarket.
• Software updates, manufacturing changes, supplier shifts and maintenance practices all shift risk profiles over time.

Regulators therefore treat PMS as a core lifecycle responsibility, not an afterthought. EU MDR/IVDR dedicate an entire chapter (Chapter VII) and Annex III to PMS systems, PMS plans and related reporting obligations.:contentReference[oaicite:4]{index=4} The FDA’s device framework explicitly lists postmarket requirements – quality systems, MDR, corrections/removals, and postmarket surveillance studies – as part of the regulatory package for cleared or approved devices.:contentReference[oaicite:5]{index=5}

From a business perspective, PMS is your cheapest way to learn from reality. It lets you:

• spot systemic quality issues early (before they become field actions),
• detect unexpected use patterns or user errors and adjust labeling or training,
• differentiate with real‑world performance evidence, and
• feed actual field data into design improvements and next‑generation products.

Ignoring PMS doesn’t save effort – it simply moves cost into recalls, remediation projects, litigation and reputational damage.

3) Core Building Blocks of a PMS System

A credible PMS system inside a medical device QMS usually includes:

• PMS plan: scope, objectives, data sources, methods, responsibilities and metrics for each device or device family (explicitly required under EU MDR Article 84).:contentReference[oaicite:6]{index=6}
• Data collection mechanisms: complaint handling, vigilance/MDR, literature surveillance, registry participation, user surveys, service data, sales/returns, social‑media/online feedback (where risk‑based justification exists).
• Signal detection and analysis: trending, statistics, risk re‑evaluation, clinical evaluation updates, usability analysis.
• Escalation pathways: when a signal triggers investigation, CAPA, field corrective action, recall or regulatory reporting.
• Reporting and feedback: PMS reports, PSURs, management review inputs, product‑quality reviews (PQR/APR), design‑input updates.

If your “PMS system” is just a complaints inbox and a pile of spreadsheets, you are under‑delivering what MDR/IVDR and modern FDA expectations intend.

4) US FDA Postmarket Surveillance Landscape

In the US, PMS is a combination of passive and active tools, including:

• Medical Device Reporting (MDR): mandatory reporting of certain device‑related deaths, serious injuries and malfunctions by manufacturers, importers and user facilities. MDR is explicitly described by FDA as one of the key postmarket surveillance tools for monitoring device performance and safety.:contentReference[oaicite:7]{index=7}
• Corrections and Removals / Recalls: requirements to report and manage field corrections or removals when a device may pose health risk or is otherwise in violation.
• 522 Postmarket Surveillance Studies: for some Class II and III devices, the FDA can order mandatory postmarket surveillance studies under Section 522 of the FD&C Act, implemented via 21 CFR 822.:contentReference[oaicite:8]{index=8} These are structured, often multi‑year studies answering specific safety or effectiveness questions for high‑risk or widely used devices.:contentReference[oaicite:9]{index=9}
• Active surveillance and real‑world data: registries, electronic health records, billing claims and other real‑world data sources are increasingly used to detect safety issues and support regulatory decisions.:contentReference[oaicite:10]{index=10}

FDA has been steadily expanding active postmarket surveillance capabilities, moving beyond purely passive voluntary reporting towards structured use of large data sets and mandated studies where necessary.:contentReference[oaicite:11]{index=11}

5) EU MDR / IVDR Postmarket Surveillance

Under EU MDR 2017/745 and IVDR, PMS is heavily formalised. Manufacturers must implement a PMS system that is:

• proactive and systematic,
• proportionate to device risk class and type, and
• integrated into the QMS and clinical‑evaluation processes.

Key MDR requirements include:​:contentReference[oaicite:12]{index=12}

• Article 83 – PMS system: mandates a system to actively and systematically collect, record and analyse relevant data throughout the device’s lifetime, and to draw necessary conclusions and implement any preventive and corrective actions.
• Article 84 – PMS plan: each device must have a PMS plan defining data sources, methods, indicators, trigger criteria for actions and links to PMCF (Post‑Market Clinical Follow‑up) where applicable.
• Articles 85 and 86 – PMS report / PSUR: lower‑risk devices require periodic PMS reports; higher‑risk devices require Periodic Safety Update Reports (PSURs) summarising PMS data, conclusions, volume of sales, populations and risk–benefit evaluation over defined intervals.
• Annex III – Technical documentation on PMS: defines structure and content of PMS technical documentation, including PMS plans and outputs.

EU guidance and industry white papers underline that PMS is expected to drive updates to clinical evaluation, risk management and technical documentation – not just produce standalone reports.:contentReference[oaicite:13]{index=13}

6) Data Sources: Passive vs Active PMS

A robust PMS system blends multiple data sources:

• Passive PMS: signals initiated by others and received by the manufacturer, such as customer complaints, product returns, MDRs, service reports and distributor feedback.
• Active PMS: manufacturer‑initiated activities like user surveys, registries, PMCF studies, targeted follow‑ups, real‑world evidence analyses and periodic literature reviews.:contentReference[oaicite:14]{index=14}

Typical sources include:

• complaints and complaint‑handling records,
• adverse‑event reports (MDR/MedWatch, vigilance reports, field alerts),
• trend reports for non‑reportable incidents that may indicate emerging risk,
• service/maintenance logs, device logs and error codes,
• registry or real‑world database outputs,
• post‑market clinical follow‑up (PMCF) results,
• scientific literature and safety communications, and
• market‑surveillance findings from authorities.

The point is not to hoard data; it is to systematically convert data into risk‑relevant insight and action.

7) PMS, Complaints, MDR and Recalls – How They Fit Together

PMS is the umbrella; complaints, MDR and recalls are sub‑processes within it:

• Customer Complaint Handling: captures any expression of dissatisfaction related to device identity, quality, durability, reliability, safety or performance. Complaint triage and investigation determine whether events are reportable under MDR/vigilance and whether CAPA is needed.
• Medical Device Reporting (MDR): for US, certain deaths, serious injuries and malfunctions must be reported to FDA, typically via MedWatch or electronic MDR systems. FDA explicitly describes MDR as a core postmarket surveillance tool.:contentReference[oaicite:15]{index=15}
• Field Safety Corrective Actions / Recalls: when risk justifies corrective or removal actions, PMS provides the evidence and traceability to define scope, root cause and effectiveness checks.

All of these feed into CAPA and risk management. If your PMS system does not connect complaint handling, MDR decisions and recall management inside one traceable chain, you are inviting gaps that regulators will eventually find.

8) PMS Planning, Reporting and Feedback to Design

PMS is not just operations; it is part of design‑lifecycle management. A solid PMS process will:

• Define PMS plans at design‑transfer: as devices approach launch, PMS requirements (data sources, indicators, PMCF needs) are locked into the technical file and QMS.
• Run periodic PMS cycles: aggregate and analyse data on defined intervals and event‑driven triggers.
• Issue PMS reports / PSURs: summarise findings, volume of sales, populations and updated risk–benefit conclusions as required by EU MDR/IVDR.:contentReference[oaicite:16]{index=16}
• Feed design and risk management: update design inputs, risk analyses, usability files and clinical evaluation in light of new evidence.
• Inform management review: highlight systemic risk, field issues and lifecycle trends.

Done properly, PMS closes the lifecycle loop: premarket assumptions get stress‑tested against real‑world evidence, and those learnings shape the next iteration of devices and indications.

9) Risk Management, CAPA and PMS

Postmarket Surveillance, Quality Risk Management and CAPA are inseparable:

• PMS data reveal new hazards, new hazardous situations or changed probabilities/severity for risks already identified in the risk file.
• Risk management processes re‑assess these and decide whether risk‑control measures, labeling or IFU changes are needed.
• CAPA processes implement and verify those changes, ensuring effectiveness and preventing recurrence.

EU MDR explicitly requires that PMS outcomes feed back into risk‑management and clinical‑evaluation documentation; failure to demonstrate this feedback loop is a common audit and notified‑body finding.:contentReference[oaicite:17]{index=17} FDA inspections similarly look for evidence that complaint trends and MDRs drive meaningful CAPA and risk‑based actions, not just case‑by‑case fixes.:contentReference[oaicite:18]{index=18}

10) Digital PMS, Real‑World Evidence and Active Surveillance

Modern PMS is increasingly digital and data‑driven:

• Real‑world data (RWD): registries, EHRs, claims and other data sources are being used for active surveillance and benefit–risk evaluations. FDA guidance recognises the role of real‑world evidence for medical‑device decisions, including in postmarket contexts.:contentReference[oaicite:19]{index=19}
• Advanced analytics: trending, signal detection and sometimes machine‑learning models help identify clusters, rare events and drift.
• Integrated complaint/MDR/CAPA platforms: reduce manual hand‑offs and lost context.
• Postmarket study registries and 522 databases: structured tracking of mandated PMS studies and their status.:contentReference[oaicite:20]{index=20}

The direction of travel is clear: regulators expect firms to use the data they already generate – not just store them. That means your PMS story increasingly needs to include “how we mine our data for signals,” not just “we keep them for 10 years.”

11) PMS for Software and AI‑Driven Devices

For software as a medical device (SaMD) and AI/ML‑based devices, PMS takes on extra weight:

• frequent updates and continuous deployment change device behaviour over time,
• performance can drift as data distributions change (“dataset shift”), and
• usability or workflow issues may only appear at scale.

Regulators are pushing towards lifecycle approaches where PMS is integral to change management, algorithm retraining and performance monitoring – not a bolt‑on. Real‑world evidence and continuous‑performance dashboards become key components of PMS for these technologies, and firms should treat PMS planning as part of their software lifecycle and AI risk‑management frameworks, not as just another QMS SOP.:contentReference[oaicite:21]{index=21}

12) Implementation Roadmap & Practice Tips

If your PMS setup is currently “complaints + some reports,” a practical route to a defendable system is:

• 1. Map the current reality. Document how complaints, MDR, field actions, literature and service data actually flow today – who sees what, where it’s stored, and how decisions are made.
• 2. Define device‑family PMS plans. For each family, write a risk‑based PMS plan listing data sources, indicators, triggers and reporting obligations (including MDR/PSUR). Tie this to your risk‑management files and clinical‑evaluation reports.
• 3. Clean up complaint and MDR handling. Standardise intake, triage, investigation, reportability assessment, timelines and linkages to CAPA. Ensure MedWatch / vigilance reporting is embedded in the process, not a last‑minute scramble.
• 4. Add structured analysis. Introduce regular trending and signal‑review meetings with QA/RA, clinical and engineering, and record decisions and rationales.
• 5. Integrate PMS with CAPA and change control. Make sure systemic signals from PMS feed CAPA, and that CAPA and changes document how they respond to PMS evidence.
• 6. Formalise PMS outputs. Create standard PMS report / PSUR templates and link them into management review and product‑quality reviews.
• 7. Digitise where it counts. Move from email + spreadsheets to integrated systems that connect PMS data, quality events and product history in one place.

The goal is simple: every serious device manufacturer should be able to show, on demand, how real‑world experience flows into safety decisions, design changes and regulatory communication – without detective work or heroics.

13) What Postmarket Surveillance Means for V5

On the V5 platform, Postmarket Surveillance stops being an after‑the‑fact paperwork exercise and becomes a data‑driven, connected lifecycle process. Instead of PMS living in isolated quality tools, V5 ties field experience directly to manufacturing, quality and warehouse history.

• V5 Solution Overview
  • Provides a single data model linking products, lots, devices, customers, quality events and regulatory documentation.
  • Lets you drill from a complaint or PMS signal back to the exact manufacturing lots, equipment and materials involved – and forward to all customers and markets impacted.
• V5 QMS – Quality Management System
  • Runs the core PMS processes: complaint handling, MDR assessment, deviations, CAPA, risk‑register updates, audits and management review.
  • Supports structured PMS plans, PMS reports, PSUR inputs and linkages to design, risk‑management and clinical‑evaluation documentation.
  • Enforces data‑integrity expectations with audit trails, e‑signatures and role‑based access for all PMS‑relevant records.
• V5 MES – Manufacturing Execution System
  • Captures detailed batch/lot and device‑level execution data (parameters, materials, equipment, alarms) that form the backbone of technical and PMS investigations.
  • Feeds quality events (deviations, in‑process failures, near‑misses) directly into V5 QMS, ensuring PMS does not ignore in‑plant signals.
  • Supports electronic batch/device history records that link manufacturing history to field performance.
• V5 WMS – Warehouse Management System
  • Provides precise genealogy: which devices/lots went to which customers, distributors and markets; which returns and field‑actions tie back to which inventory.
  • Enables fast, targeted recalls and field‑safety actions based on PMS signals – not broad, blunt recalls driven by poor traceability.
• V5 Connect API
  • Integrates external complaint portals, CRM, service systems, registries and EHR‑linked PMS tools into the V5 QMS backbone.
  • Allows structured data exchange with regulators and partners where PMS reporting or 522‑study data must be submitted or shared.

Net effect: with V5, Postmarket Surveillance is not a separate spreadsheet universe. It is a living extension of the same data that runs your plant and QMS – making it far easier to prove to FDA, EU regulators and customers that you know how your devices behave in the real world, and that you act on that knowledge quickly and systematically.

FAQ

Q1. Is Postmarket Surveillance only about adverse event reporting?
No. Adverse‑event reporting (MDR/vigilance) is one part of PMS, but regulators expect a broader, proactive system that also uses complaints, returns, literature, registries, PMCF and other data sources to monitor performance and update risk management, labeling and design.

Q2. Do Class I devices need a full PMS system?
Yes, but the depth is risk‑based. Even low‑risk devices under EU MDR must have PMS systems and PMS reports; the intensity of data collection, analysis and documentation is scaled to device risk and complexity, not switched off entirely.:contentReference[oaicite:22]{index=22}

Q3. When does FDA require 522 postmarket surveillance studies?
FDA can order 522 postmarket surveillance for certain Class II or III devices when device failure could cause serious health consequences, when devices are widely used in paediatric populations, implanted >1 year, or life‑supporting or life‑sustaining outside user facilities.:contentReference[oaicite:23]{index=23} These are in addition to routine MDR and quality‑system requirements.

Q4. How is PMS different under EU MDR compared with the old MDD?
MDR makes PMS more explicit and demanding: mandatory PMS plans per device, PMS/PSUR reports with defined content, stronger links to clinical evaluation and risk management, and more detailed technical documentation requirements in Annex III. Manufacturers that treated PMS as a light, mostly reactive activity under MDD are finding they must upgrade to more structured, evidence‑driven systems.:contentReference[oaicite:24]{index=24}

Q5. What’s the fastest way to improve a weak PMS process?
Start by formalising PMS plans and tightening complaint/MDR handling: standardise intake and triage, define clear reportability rules, link cases to CAPA and risk files, and implement basic trending. Once that loop works, layer in additional data sources (literature, PMCF, service data) and integrate outputs into management review and design‑change processes.

Related Reading
• Regulatory & Lifecycle: Medical Device Reporting (MDR) | MedWatch Form | FDA 510(k) Clearance | EU MDR 2017/745
• Quality & Risk: Medical Device QMS | Customer Complaint Handling Process | Quality Risk Management (QRM) | CAPA | Product Quality Review (PQR) | Annual Product Review (APR)
• Data & Evidence: Data Integrity | Audit Trail | Certificate of Analysis (CoA)
• V5 Platform: V5 Solution Overview | V5 QMS | V5 MES | V5 WMS | V5 Connect API