MDR 745 Specialist

Post-Market Surveillance Plan — MDR Art. 84 Requirements

Under MDR 2017/745, the PMS plan must be device-specific and include all elements of Annex III. Generic plans get flagged immediately.

Required PMS plan elements (Annex III, §1.1):

1. Proactive PMS data sources

Source	Frequency	Responsible
App store reviews (iOS/Android)	Weekly monitoring	QA/RA team
Customer support complaints	Continuous	Customer Success
In-app feedback surveys	Post-use, 30-day	Product
Literature surveillance (PubMed: wound assessment, SaMD)	Quarterly	Clinical Affairs
EUDAMED vigilance database + FDA MAUDE	Quarterly	RA
Competitor FSCA monitoring	Quarterly	RA

2. Complaint handling integration All complaints must be:

• Triaged for MDR reportability (Art. 87) within 24 hours
• Classified: serious incident / non-serious / near-miss / user error
• Trended quarterly for signal detection

3. Benefit-risk analysis update triggers Document criteria that trigger a benefit-risk reassessment:

• Complaint rate exceeds [X per 1,000 uses]
• New literature changes the clinical background
• Serious incident reported
• Software update changes intended purpose

4. PMSR vs PSUR — which applies?

• Class IIa SaMD: Periodic Safety Update Report (PSUR) required at minimum every 2 years (Art. 86)
• Your NB may request annual PSUR given active user base

PSUR must include:

• Summary of PMS data collected
• Conclusions from clinical evaluation update
• Main findings and corrective actions taken
• Updated benefit-risk determination
• Sales volume and user estimates

5. Measurable thresholds (the part most plans are missing) Your NB flagged weakness here. Define specific, quantified thresholds:

Serious adverse event rate:     > 0.01% → immediate MDR vigilance report
Non-serious complaint rate:     > 2% of users/month → CAPA trigger
App crash rate:                 > 0.5% → software fix within 14 days
Wound assessment accuracy drift: > 5% deviation from clinical ground truth → retrain trigger

Want me to write the full PSUR template and the complaint signal detection procedure?

AI/ML Algorithm Update — Significant Change Assessment under EU MDR

An architecture change to an AI/ML model is almost always a significant change under EU MDR 2017/745. Here is how to work through the formal determination.

---

The Regulatory Framework: Article 120(3) and MDCG 2020-3

Article 120(3) of MDR applies to legacy devices (those on the market under MDD/AIMDD) and requires a new conformity assessment for significant changes to design or intended purpose. For devices already CE marked under MDR, the same logic applies via the conformity assessment procedures in Annex IX/X — any change that could affect conformity with the MDR requirements requires reassessment.

MDCG 2020-3 ("Guidance on significant changes regarding the transitional provisions under Article 120") provides the decision framework. The core question is:

Does the change affect the intended purpose, clinical performance, safety, or the benefit-risk determination?

---

The Decision Tree for Your Situation

Work through these in order:

1. Does the change affect intended purpose? Your case: same indication, same clinical output (AFib flagging / wound assessment / whatever it is). Intended purpose unchanged — this factor alone does not trigger significance.

2. Does the change affect safety or performance in a way that could affect the benefit-risk profile?

• Architecture change: Yes. A different algorithm architecture (e.g., CNN → transformer, rule-based → neural) represents a different technological implementation. Even if performance metrics appear equivalent, the failure modes, edge cases, and distributional sensitivities are different. MDCG 2020-3 explicitly identifies "changes to the software algorithm" as a category requiring careful significance assessment.
• Performance improvement within validated range: If sensitivity improved but you can demonstrate the improvement is within the validated operating range of your original clinical evaluation, this may not be significant — but you must document that determination rigorously.
• Any drift beyond your originally validated performance envelope: Significant, full stop.

3. Does the change affect the clinical evaluation? Architecture change: Yes. Your clinical evaluation was based on evidence generated with the original architecture. A new architecture requires updated clinical evidence — at minimum, a new analytical performance study; potentially new clinical study data depending on the risk class and what your Notified Body accepted previously.

Conclusion for your case: The architecture change almost certainly constitutes a significant change. The performance improvement is secondary — the architectural difference alone triggers the assessment.

---

What "Significant Change" Requires

If you determine the change is significant, you need:

Document	What to update
Change description	Detailed technical description of what changed — old architecture vs. new, training data differences, hyperparameters
Impact assessment	Structured analysis against MDR Annex I GSPRs — which requirements are affected, how the change addresses or affects each
Updated clinical evaluation	New performance data (training/validation/test split, demographics, site diversity); updated SSCP if publicly accessible
Risk management file update	Reassess failure modes for the new architecture; new FMEA rows if new failure modes exist
Technical file update	Annex II/III sections covering the algorithm, software lifecycle (IEC 62304), and usability (IEC 62366) as applicable
Conformity assessment	Notify your Notified Body — significant changes require NB review before implementation

---

EUDAMED Update Requirement

Under MDR Art. 29 and the EUDAMED registration obligations, significant changes that affect the device registration data must be reflected in EUDAMED. The UDI-DI may need to change depending on whether the change qualifies as a new device version. Check your UDI assignment rules — in most cases an architecture change with preserved intended purpose warrants a new production identifier (UDI-PI) at minimum; your Notified Body may require a new UDI-DI.

---

Practical Advice: Engage Your Notified Body Early

Before committing to full documentation, submit a significant change proposal to your Notified Body. Most NBs have a defined process for this — a short document (2–5 pages) describing:

• What changed and why
• Your preliminary significance determination
• Proposed evidence package

This costs far less than submitting full updated documentation only to have the NB request a different evidence approach. For AI/ML architecture changes, NBs are increasingly asking for explainability documentation, bias analysis across demographic subgroups, and prospective performance monitoring plans — get alignment on scope before you start generating evidence.

The MDCG 2021-6 guidance on AI/ML-based SaMD should also be on your desk for this exercise. It is not legally binding but reflects current NB expectations for AI/ML change assessments.