Managing MDR Transition Across Multiple Device Families: A Practical Programme Guide

Why multi-device transitions fail differently than single-device ones

Managing one device through MDR transition is a compliance project. Managing ten devices simultaneously is a programme management challenge — and most manufacturers who have struggled with transition delivery have done so not because of regulatory complexity on any single device, but because the interactions between concurrent workstreams across their portfolio created bottlenecks they did not see coming.

The most common pattern: all devices need updated clinical evaluations, and the clinical team is the scarcest resource. All devices need updated technical documentation, and the QMS team is managing documentation changes across the whole portfolio at once. And Notified Body submissions for different devices are timed without adequate account of the NB's own review capacity. The result is that work piles up at the same bottlenecks simultaneously, timelines slip, and the interdependencies that were not mapped at the start mean that a delay on one device has downstream effects on others.

A multi-device MDR transition needs to be run as a structured programme with explicit sequencing, resource mapping, and dependency tracking from the beginning.

Start with a portfolio map, not individual device plans

Before you build workstream plans for individual devices, you need a complete map of your portfolio's transition status. For every device family, capture: the device class, the current MDD/AIMDD certificate status and expiry date, the Notified Body and whether a written agreement or application was submitted by 26 May 2024, the transition deadline that applies under Regulation 2023/607, the clinical evaluation approach (own data, equivalence, or PMCF), and any known gaps in technical documentation.

This map gives you three things. First, it shows you which devices are time-critical — those closest to their transition deadline define the programme's hard constraints. Second, it shows you where equivalence dependencies exist: if three devices all rely on equivalence claims that are under reassessment, those three clinical workstreams have the same upstream uncertainty. Third, it shows you where shared documentation exists — if a family of device variants shares a risk management file or a technical documentation structure, changes to one have knock-on effects on the others.

Without this map, individual device teams optimise for their own device in isolation, and the programme-level dependencies are invisible until they become crises.

Prioritisation: not all devices are equal

Once you have the portfolio map, the transition sequence should be driven by a combination of deadline urgency and strategic importance — not just deadline urgency alone.

Devices that face the earliest transition deadlines get the most resources. That is the baseline. But within a given deadline window, prioritise devices that are clinically critical (no available substitute on the market), devices with straightforward clinical evaluation paths (own data available, equivalence confirmed), and devices that generate significant revenue or serve high-volume patient populations. Devices that are candidates for wind-down — older platform products that will not be re-engineered for MDR — should be identified early and managed differently: not as active transition candidates but as structured end-of-life products where the priority is managing the sell-off period and customer communications, not full MDR certification.

Getting clarity on which devices are active transition candidates and which are wind-down candidates early in the programme prevents teams from investing resources in documentation work for devices that will ultimately not be certified.

Resource sequencing: the clinical evaluation bottleneck

In almost every multi-device MDR transition, the clinical evaluation team is the binding constraint. Clinical evaluation reports take longer to write than most teams estimate, they require specific expertise that is in limited supply (internally and in the consultancy market), and they cannot be parallelised easily because each CER requires dedicated reviewer time.

The approach that works is sequential rather than parallel: build the clinical workstream schedule with explicit handoff dates between devices, not with all devices starting at the same time. The Notified Body will also process MDR certifications sequentially — they do not review your entire portfolio simultaneously. Aligning your clinical preparation schedule with your NB's review capacity means knowing how many submissions your NB can handle per quarter and spacing your submissions accordingly.

One frequently missed planning point: technical documentation updates and clinical evaluation updates are interdependent. The technical documentation section on clinical evaluation pulls from the CER. Changes to the CER may require updates to the technical documentation. Sequencing these correctly — ensuring technical documentation is not finalised before the CER is stable — saves significant rework.

Notified Body management at programme scale

If you have a multi-device portfolio in transition, your Notified Body relationship is a programme-level resource to be actively managed — not just a point of contact for individual submissions.

Have a programme-level conversation with your NB about your full portfolio and transition timeline. Most NBs will provide a rough indication of their review capacity and preferred submission spacing. Some will flag that certain device categories take longer due to specialist clinical reviewer availability. Knowing this at the programme level allows you to space submissions in a way that avoids your portfolio competing with itself for NB review time.

If different devices in your portfolio are certified by different Notified Bodies — a common situation after acquisitions or where historical certification choices differed by geography — the coordination challenge is more complex. In this case, consider whether consolidating to a single NB for future MDR certifications is worth the additional migration work, particularly if your current NB relationships are performing differently in terms of responsiveness and capacity.

Governance: what to track and when to escalate

A multi-device transition programme needs regular governance — a standing review cadence (typically monthly at programme level, more frequently for active workstreams) with a consistent view of the portfolio map, a traffic-light status for each device, and explicit flagging of any device approaching a decision point that carries programme-level implications.

Decision points that require escalation are: a confirmed equivalence block on a device that was previously planned as an equivalence path; a PMCF study initiation decision for any device (this has resource and timeline implications for the whole programme); a Notified Body declining or significantly delaying a submission; and any device that drops below a six-month runway to its transition deadline without a confirmed NB submission date.

The teams most likely to get through multi-device transitions in reasonable shape are those that run this as a programme from the start — with explicit accountability, a shared portfolio view, and a governance structure that makes inter-device dependencies visible before they become delivery problems.