Post-marketEU

EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance

Operational workflows for lifecycle monitoring and reporting.

Build PMS/vigilance as an operating capability: signal detection to CAPA to risk + clinical evaluation updates.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 22, 2026

Updated

Feb 22, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 22, 2026

Updated Feb 22, 2026

Overview

PMS and vigilance are where MDR becomes real. They define how you detect issues, how you decide whether they are reportable, how you correct them, and how you prove that the system is working. Teams that treat PMS as a report often fail audits because they cannot show a functioning signal to action to verification loop.

Section 1

PMS vs vigilance: what is different under MDR

Post-market surveillance is the continuous system for collecting and analysing device experience. Vigilance is the regulated serious-incident and field-safety response layer that sits on top of that system.

Operational outcome: PMS creates the evidence base. Vigilance decides reportability, sends the report, tracks the corrective action, and closes the loop back into risk management and clinical evaluation.

PMS inputs: complaints, service reports, trend data, literature, cybersecurity findings, returned-product analysis, user feedback, and supplier signals.
PMS outputs: PMS plan, PMS report for class I devices, PSUR for class IIa, IIb, and III devices, trend-analysis records, CAPA triggers, and management-review inputs.
Vigilance outputs: reportability decisions, MIR submissions, FSCA records, field safety notices, competent-authority correspondence, and effectiveness checks.

Section 2

Build the PMS system as an Annex III workflow, not a static document

Article 83 requires a live PMS system, and Annex III requires a plan that describes how the system works. Reviewers will test whether the workflow is operating, not just whether the plan exists.

Control: tie each PMS data source to an owner, a review cadence, a metric, and an escalation threshold.

For class I devices, prepare a PMS report under Article 85. For class IIa, IIb, and III devices, prepare a PSUR under Article 86.
PSUR cadence matters: class IIb and class III at least annually, class IIa at least every two years, with the PSUR kept as part of the technical documentation.
For class III and implantable devices, the PSUR is submitted through the Article 92 electronic system to the notified body. For other class IIa and IIb devices, keep it available for the notified body and competent authorities on request.
Use historical PMS data where relevant for the first PSUR, especially for legacy devices moving from directive-era surveillance into MDR-style reporting.
Make PMS outputs change the file: CAPA, risk-management updates, labeling changes, CER updates, and PMCF decisions should be traceable from the same dataset.

Section 3

Vigilance workflow: serious incident, timeline, report, FSCA

Vigilance failures usually come from unclear ownership or weak clocks. Build one decision log that records awareness date, reportability reasoning, submission timing, and follow-up actions.

Control: use a vigilance log with timestamps and backup owners. Vacation cover is a real audit point.

Article 87 timeline for a general serious incident: immediately and no later than 15 days after the manufacturer becomes aware of the incident.
Article 87 timeline for a serious public health threat: immediately and no later than 2 days after awareness.
Article 87 timeline for death or unanticipated serious deterioration in a person's state of health: immediately and no later than 10 days after awareness.
Use the UDI and relevant device identifiers in incident and FSCA records so complaints, field actions, and registry data can be reconciled quickly.
Until the EUDAMED Post-market Surveillance and Vigilance module becomes mandatory, agree with the notified body how vigilance visibility and PSUR-related updates will be shared.

Section 4

Minimum evidence pack to keep ready

Auditors and competent authorities do not expect zero issues. They expect a functioning system that can show how issues are detected, assessed, corrected, and verified.

If you cannot retrieve these records quickly, fix retrieval first. Slow retrieval is usually a QMS failure, not an IT inconvenience.

PMS plan with data sources, metrics, trend thresholds, and review cadence.
PMS report or PSUR with issue date, period covered, linked CAPA and risk updates, and management-review evidence.
Vigilance log with awareness date, reportability rationale, Article 87 timeline calculation, submission proof, and FSCA effectiveness records.
UDI-linked complaint and incident records so the affected device family, variant, and packaging level can be identified quickly.
CER, PMCF, and risk-management update records that show post-market findings actually changed the evidence chain.

Recommended next step

Turn EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance into an operational assessment

Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance

Start from EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through EU Medical Device Regulation (MDR) 2017/745

Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance.

Explore next step

Primary sources