Post-Market Surveillance for SaMD: Articles 83–92 and Real-World Data Obligations

The part that catches SaMD teams by surprise

Most SaMD manufacturers invest heavily in pre-market compliance — qualification, classification, technical documentation, clinical evaluation — and then discover that MDR's post-market obligations are almost as demanding. Articles 83 to 92 establish a post-market surveillance system that is not a one-time exercise but a continuous process. For software, that system has characteristics that don't map cleanly from hardware device experience.

The core obligation is Article 83: manufacturers must plan, establish, document, implement, maintain, and update a post-market surveillance system for each device they place on the market. This system must be proportionate to the risk class and type of the device. For a Class I SaMD, that might mean a relatively lightweight system. For Class IIb or III, it means a structured, actively maintained surveillance programme with documented data collection, analysis, and feedback loops into your technical documentation and risk management file.

What the PMS system for software actually monitors

Hardware PMS is largely complaint-driven — you track field issues, malfunctions, adverse events, and complaints from users and healthcare facilities. For software, those channels still apply, but they don't cover the most important failure modes. Software can perform exactly as designed and still produce incorrect clinical outputs in specific patient populations, edge cases, or deployment environments that weren't fully anticipated at design time.

A properly structured SaMD PMS system should include:

Complaint and adverse event monitoring — the basics: a system to receive, record, and analyse complaints from users and healthcare facilities. For software deployed in hospitals, this typically means a formal channel through clinical engineering or IT operations teams. Consumer-facing SaMD needs a direct user feedback mechanism.

Incident reporting — Article 87 requires manufacturers to report serious incidents to the relevant competent authority. For software, a serious incident can include algorithm errors that led to a diagnostic error, software failures that resulted in unavailability of critical functionality, or cybersecurity breaches affecting patient safety.

Real-world performance data — this is where SaMD differs most from hardware. For diagnostic or decision support software, your PMS system should include mechanisms to collect data on the software's real-world clinical performance: how often outputs align with actual clinical outcomes, whether performance differs across user populations or settings, whether there are patterns in the cases where the software underperforms.

Trend analysis — Article 88 requires manufacturers to report significant increases in the frequency or severity of non-serious incidents and expected, undesirable side-effects. For software, this means your PMS data needs to be analysed for trends — not just individual incidents.

Literature and market surveillance — monitoring the published literature for new information about your software's clinical domain, comparable technologies, and emerging safety signals. Also monitoring for new regulatory guidance relevant to your software type.

PMCF for SaMD — the ongoing clinical obligation

Post-Market Clinical Follow-up is covered in Annex XIV Part B and applies to all devices where the clinical evaluation identified gaps in evidence or where the benefit-risk conclusion depended on assumptions that need to be verified post-launch. For SaMD, PMCF is almost always warranted because:

Initial clinical evidence at launch is typically limited — performance studies on pre-defined datasets don't capture the full diversity of clinical deployment conditions. Real-world performance may differ from controlled study conditions.

Software performance can change over time in ways that hardware performance doesn't — as the clinical environment, user population, or integration landscape evolves.

The PMCF plan must be specific. What clinical data will you collect? How will you collect it — through structured real-world performance studies, registry participation, prospective observational studies? What are your endpoints? How many patients or observations are needed? Over what timeframe? What conclusions will trigger a change in your clinical evaluation?

"We will monitor adverse events through our PMS system" is not a PMCF plan. It describes complaint handling. PMCF requires active, structured clinical data collection with a defined methodology.

PSUR and the documentation feedback loop

Article 86 requires manufacturers of Class IIa, IIb, and III devices to produce a Periodic Safety Update Report at defined intervals — at least every two years for Class IIa, at least annually for Class IIb and III. The PSUR must include an analysis of post-market surveillance data, a benefit-risk assessment, and conclusions about whether any action is needed.

For SaMD, the PSUR feeds directly back into your technical documentation. If your post-market data shows something unexpected — performance degradation, a pattern of use errors, new evidence about the clinical domain — your CER, risk management file, and IFU may need updating. The PSUR is not a standalone document; it is the trigger mechanism for keeping the rest of your technical file current.

One thing teams consistently underestimate: writing a credible PSUR requires having collected the right data throughout the preceding period. You cannot write a meaningful PSUR if you have no structured post-market data to analyse. The data collection system needs to be set up from launch, not retrofitted when the PSUR deadline approaches.

Practical architecture for a SaMD PMS system

A few structural choices that make SaMD PMS manageable:

Define your data sources up front — before launch, identify where your PMS data will come from. Complaint system, customer success conversations, clinical site data sharing agreements, literature alerts, regulatory intelligence subscriptions. Each source needs a named owner and a defined review cadence.

Connect PMS to risk management explicitly — every PMS data review should include an assessment: does this new information change any of our risk estimates or benefit-risk conclusions? If yes, trigger a risk management file update. This connection is required by MDR and is often missing in practice.

Establish signal detection thresholds — don't wait for problems to become obvious. Define in advance what volume or type of signals would trigger an unscheduled review or a change to clinical documentation. This is part of the "trend analysis" obligation under Article 88.

Involve clinical stakeholders — the best SaMD PMS systems involve the clinical teams using the software, not just the regulatory and quality functions. Clinicians often notice performance issues long before they generate formal complaints.

The Class I SaMD exception — and its limits

Class I SaMD manufacturers are not required to produce PSURs. But Article 83 still applies — you still need a PMS system, and you still need to analyse post-market data and act on it. The difference is the reporting obligation, not the underlying surveillance requirement. If your Class I SaMD causes or contributes to a serious incident, the incident reporting requirements of Article 87 apply regardless of class.

Don't let the PSUR exemption lead you to conclude that post-market surveillance for Class I software is optional. It isn't.