DEV Community

Priya Nair
Priya Nair

Posted on

Why PMCF under MDR feels harder than it reads (and what I actually do about it)

I’ve been writing PMCF plans and defending them to notified bodies for the better part of five years. On paper, PMCF under MDR is straightforward: Annex XIV sets out the requirement for ongoing clinical follow‑up after CE marking, and Annex II section 6.1 tells you to include clinical evidence in the Technical File. In practice, “ongoing” turns into multi-year commitments, and “evidence” turns into a negotiation with your notified body about what is acceptable and what isn’t.

Below I share the recurring practical problems I see, concrete workarounds that have saved me time, and the eQMS features that actually matter when you’re trying to keep PMCF honest and audit‑ready.

The usual PMCF friction points

  • Scope creep from the notified body. We submit a focused PMCF to address specific residual risks; the NB frequently asks for broader endpoints or a different comparator. To be fair, their job is conservative — but in practice this means bigger studies or unrealistic timelines.
  • Data access and quality. Registries, hospital EHRs and national databases are attractive sources of real‑world data but are heterogenous, incomplete, and slow to negotiate for access (GDPR, data sharing agreements). Matching your device’s UDI to clinical outcomes is often harder than the vendor sales pitch made it sound.
  • Equivalence and comparator debates. Claims of equivalence keep coming up. Notified bodies have different thresholds for accepting equivalence-based evidence; this can change mid-review.
  • Study design expectations. Some NBs push for prospective, device‑specific cohorts even when a well‑designed retrospective analysis would answer the question faster and with less patient burden.
  • Resourcing and timelines. PMCF is a perpetual activity. Small manufacturers frequently underestimate costs and staff time; the result is delayed PSURs and unhappy auditors.

What I actually do (step‑by‑step)

  1. Start earlier than you think you need to. Annex XIV requires a PMCF plan proportionate to risk; I write the plan during technical file preparation, not after. This gives you evidence trail in Annex II and a realistic resource plan.
  2. Be explicit about the objective. State the precise question the PMCF will answer (safety signal, long‑term performance, specific patient subgroup). If your objective is narrow, defend that rationale with a risk‑based argument.
  3. Map data sources and show feasibility. Before committing to a sample size or timeline, draft a short data availability assessment: registries, EHRs, sales data (for usage rates), literature. If you can’t match UDI to outcomes in a registry, say so and provide mitigation.
  4. Keep your protocol pragmatic. Where possible use:
    • Retrospective analyses of existing data
    • Registry partnerships with agreed case definitions
    • Targeted prospective cohorts only for endpoints that truly require them
  5. Document the decision trail. Use your Technical File (Annex II section 6.1) to show the PMCF plan, feasibility assessment, and change history. When the NB asks for changes, document why you accepted/rejected them and update risk management accordingly.

Useful evidence sources (and their caveats)

  • Device registries: excellent if they include UDI and standardised outcome fields; otherwise labour‑intensive linkage work.
  • Hospital EHR extraction: faster for specific endpoints but privacy and coding variability are barriers.
  • Literature and device implant registries: good for context and long‑term signals, but beware of class vs device differences.
  • Post-market vigilance and complaints: immediate signal detection but not a substitute for systematic PMCF.

eQMS features that actually help

If your QMS can’t link PMCF tasks to risk items, the device UDI, and the Technical File sections, it’s not worth the pretty interface. I use and recommend QMS workflows that provide:

  • Traceability from PMCF findings to risk management and corrective actions (Annex II tie‑in)
  • Automated reminders for data collection milestones and PSUR frequency
  • Versioned PMCF protocols and feasibility assessments for audit trails
  • Simple exports for notified body review (we still send PDFs; the NB ecosystem is not fully EUDAMED‑native yet — so ist das halt)

Practical negotiation tips with notified bodies

  • Lead with a risk‑based rationale, not with study design. Explain why your chosen endpoints address the residual risk.
  • Offer interim analyses or conditional mitigation measures if the NB is nervous about long follow‑up.
  • If an NB asks for broader endpoints, propose a staged approach: start with the focused PMCF and add elements if signals emerge.

Compliance realities: where the text and practice diverge

Annex XIV says PMCF must be “planned and conducted,” and Annex II requires you to include clinical evidence. Article 83 (PMS system) makes clear you must monitor and report. But the regulations don’t tell you what sample size is “enough,” or which registries are acceptable. That ambiguity is by design; it’s also why different notified bodies draw different red lines. To be effective, your PMCF planning needs to translate those high‑level rules into executable, evidenceable steps you can show in a Technical File.

Final, practical checklist before you submit a PMCF plan

  • Objective: Clear, risk‑based question
  • Feasibility: Map of data sources and their limitations
  • Design: Proportionate and pragmatic (justify why prospective/retrospective)
  • Traceability: Links from PMCF to device risk items, UDI, and Technical File
  • Resources: Budget, staffing, and timeline with interim checks

I’d be lying if I said every NB now accepts pragmatic, registry‑based PMCFs — they don’t. But documenting your rationale, showing feasibility up front, and using eQMS traceability reduces rework and keeps audits calm.

How are others handling notified bodies that insist on device‑specific prospective PMCF when existing data sources would answer the question faster?

Top comments (0)