What Is Post-Market Surveillance (PMS) Under MDR? A Starter Guide
Post-market surveillance under MDR is the ongoing system for collecting and acting on real-world device data. Here is what Articles 83-86 require and how startups actually build it.
41 in-depth guides in this cluster
Post-market surveillance under MDR is the ongoing system for collecting and acting on real-world device data. Here is what Articles 83-86 require and how startups actually build it.
MDR Articles 83 to 86 define the post-market surveillance system, plan, report, and PSUR. Here is what each article requires and how they fit together.
MDR Annex III defines the contents of a PMS plan. Here is what must appear in it, how to structure it for a startup, and what auditors check.
Class I devices require a PMS report under MDR Article 85. Here is what goes in it and how to keep it current without building infrastructure you do not need.
The PSUR under MDR Article 86 is the periodic safety update for IIa, IIb, and III devices. Here is the structure, the frequency by class, and what Notified Bodies look for.
MDR Annex III lists the PMS data sources you must consider. Here is what each one looks like for a startup with limited footprint.
Reactive PMS waits for complaints. Proactive PMS goes looking for signals. MDR expects both. Here is how to build proactive methods into a startup PMS system.
Complaint handling is where most PMS systems break down. Here is the process under MDR and ISO 13485 that actually catches safety signals early.
MDR Article 88 requires manufacturers to report statistically significant increases in non-serious incidents or expected side-effects. Here is how to detect and report them.
A PMS system that runs without burning the team is achievable for a small MedTech company. Here is the lean PMS build that satisfies MDR Annex III.
Post-market surveillance for SaMD has unique requirements: telemetry, version performance, cybersecurity events. Here is how to design it.
Vigilance under MDR is the mandatory serious-incident reporting system. Here is what it covers, how it differs from PMS, and what startups must report.
MDR Articles 87 to 92 define the manufacturer vigilance obligations: serious incident reports, trend reports, field safety corrective actions, and the Eudamed flow.
A serious incident under MDR triggers mandatory reporting. Here is how to determine whether an event meets the threshold — and what to do once it does.
When a serious incident is reportable, you have 15, 10, or 2 days depending on severity. Here is the step-by-step reporting process.
MDR Article 87 sets three vigilance deadlines: 15 days for standard serious incidents, 10 days for death or unanticipated deterioration, and 2 days for public health threats.
A Field Safety Corrective Action under MDR is any manufacturer action taken to reduce risk on a device already on the market. Here is when to trigger one and how to execute it.
A Field Safety Notice is how you communicate safety corrective actions to users. MDR Article 2(69) defines it, MDCG 2023-3 Rev.2 shapes it. Here is how to write one.
A recall under MDR is an FSCA that withdraws a device from use or from the market. Here is the process, the reporting, and how startups should plan for the possibility.
PMS, vigilance, and CAPA are three interlocking MDR processes. Here is how they feed each other and what auditors check for integration.
PMCF under MDR is the ongoing collection of clinical data after CE marking. Here is the complete guide: plan, execution, report, and the lifecycle loop.
A PMCF plan under MDR Annex XIV Part B structures your post-market clinical follow-up. Here is what to include and how to keep it proportionate.
The PMCF evaluation report under MDR Annex XIV Part B summarises post-market clinical data. Here is the structure that satisfies auditors.
A PMCF study collects post-market clinical data on a CE-marked device. Here is how to design a prospective PMCF study that satisfies MDR Annex XIV Part B.
PMCF surveys and registries are low-cost ways to collect post-market clinical data. Here is when each fits and how to design them under MDR Annex XIV Part B.
PMCF is not always required under MDR. Here is when you can justify a no-PMCF position and what evidence the Notified Body expects.
PMCF for software and AI devices looks different from hardware PMCF. Here is how to design continuous performance monitoring that satisfies MDR Annex XIV Part B.
MDR requires PMS data to feed back into the risk file. Here is how the loop works under EN ISO 14971 and what auditors check for integration.
MDR requires PMS and PMCF data to update the clinical evaluation report on a lifecycle cadence. Here is how the CER-PMS loop actually closes.
When PMS data shows a new risk, the IFU has to change. Here is how to decide between an IFU update, an FSN, and an FSCA under MDR.
Competent Authorities perform market surveillance under MDR Articles 93-100. Here is what that means in practice and how startups should be prepared.
A Competent Authority market surveillance inspection lands differently than an NB audit. Here is how to handle it without making the situation worse.
SSCP under MDR Article 32 is a public-facing safety and performance summary for implantables and Class III devices. Here is what it must contain and who reads it.
Write an SSCP for Class III and implantable devices under MDR Article 32: section-by-section template, lay summary rules, and NB validation steps.
PMS tools and software for MDR startups: the categories that matter, the build-vs-buy decision, and the lean stack that satisfies Annex III.
AI can accelerate PMS by automating complaint triage, trend detection, and literature surveillance. Here is how to use it without losing the safety net.
The eight most common post-market surveillance mistakes in MDR startup audits — each with the article it violates and how to fix it.
PMS for a device sold across multiple EU Member States needs coordination across competent authorities. Here is how to design it under MDR.
Continuous compliance under MDR is demonstrated through PMS records that auditors can trace end to end. Here is how to make it visible.
The complete PMS reporting checklist for MedTech startups: what is due, when it is due, and which article mandates it — by device class.
IMDRF Adverse Event Terminology is how Eudamed codes vigilance data. Here is how to build the lookup into your complaint intake before you need it.