MEDDEV 2.7.1 Rev 4 vs MDR: What Changed in Clinical Evaluation

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

The shift from MEDDEV 2.7.1 Rev 4 to MDR was not a simple update. It was a structural change in how clinical evidence is collected, analyzed, and maintained throughout a device’s lifecycle.

Yet many teams still treat MEDDEV 2.7.1 Rev 4 as the operational guide. They follow its structure, reference its sections, and then wonder why Notified Bodies raise questions that feel disconnected from what they prepared.

The problem is not that MEDDEV 2.7.1 Rev 4 became obsolete overnight. The problem is that MDR introduced requirements that MEDDEV 2.7.1 Rev 4 never anticipated. And those gaps show up clearly during reviews.

MEDDEV 2.7.1 Rev 4: The Foundation That Shaped Everything

MEDDEV 2.7.1 Rev 4 was published in 2016. It provided the first comprehensive framework for clinical evaluation under the Medical Device Directive. It introduced the concept of equivalence in a structured way. It defined what a Clinical Evaluation Report should contain.

Most importantly, it gave manufacturers a clear path: demonstrate equivalence to a device already on the market, or generate your own clinical data.

This worked under MDD because the regulatory environment accepted equivalence broadly. If you could show similarity in technical characteristics, biological characteristics, and clinical performance, equivalence was defensible.

The CER structure in MEDDEV 2.7.1 Rev 4 reflected this. It was built around demonstrating equivalence first, and only when equivalence failed, generating clinical investigation data.

MDR Article 61: A Different Logic

MDR Article 61 does not start with equivalence. It starts with clinical data generated for the device itself.

This is a fundamental shift. Under MDR, the baseline expectation is that clinical evidence comes from your device, in your intended population, under your instructions for use.

Equivalence is allowed. But it is framed as an exception, not the default. And that exception comes with strict conditions that did not exist in MEDDEV 2.7.1 Rev 4.

Article 61(5) defines what equivalence requires: clinical data from the equivalent device, full access to that data, and demonstration that the devices are truly equivalent in all relevant aspects.

This is harder than it sounds. In practice, I see manufacturers claiming equivalence without meeting any of these criteria. They reference literature on similar devices. They cite predicate devices they have no data-sharing agreement with. They assume that technical similarity is enough.

It is not enough under MDR. And reviewers reject it immediately.

SOTA: From Section to Requirement

MEDDEV 2.7.1 Rev 4 mentioned state of the art. But it did not treat it as a standalone regulatory obligation.

MDR changed that. Annex I, Section 1 makes SOTA a general safety and performance requirement. Annex XIV, Part A explicitly requires the CER to include an analysis of the current state of the art.

This is not a literature summary. It is an evaluation of whether your device meets the level of safety and performance currently expected in clinical practice.

In practical terms, SOTA analysis must answer: What are patients and clinicians getting today with the best available treatments? How does your device compare?

This comparison is not optional. It is not background context. It is a mandatory part of demonstrating compliance with MDR.

Yet I still see CERs that include a literature review but never explicitly compare their device to current standards of care. The SOTA section exists, but it does not fulfill the regulatory function that MDR demands.

What SOTA Analysis Must Address

The state of the art is not static. It evolves as new evidence, new techniques, and new devices enter the market.

Your SOTA analysis must reflect this evolution. It must identify the benchmark against which your device is evaluated. And it must show that your device meets or exceeds that benchmark.

This means tracking clinical guidelines, meta-analyses, and emerging evidence in your field. It also means understanding what alternative treatments your patients have access to.

When SOTA is weak or outdated, reviewers immediately question whether the manufacturer understands the clinical landscape. And that question extends to the entire clinical evaluation.

PMCF: From Optional to Central

MEDDEV 2.7.1 Rev 4 acknowledged post-market clinical follow-up. But it was framed as an additional activity, not a core component of the clinical evaluation.

MDR made PMCF mandatory for most devices. Article 61(11) requires manufacturers to actively collect and evaluate clinical data throughout the lifecycle of the device.

This is not post-market surveillance repackaged. PMCF is distinct. It focuses on confirming that the conclusions of the clinical evaluation remain valid in real-world use.

The PMCF plan must specify what data will be collected, how it will be analyzed, and how it will feed back into the clinical evaluation. The PMCF evaluation report then documents whether the expected outcomes were observed.

In practice, PMCF is where many manufacturers struggle. They create a PMCF plan that is vague and generic. They fail to link PMCF objectives to the clinical claims made in the CER. And when they update the CER, they do not integrate the PMCF findings in a meaningful way.

The PMCF Feedback Loop

PMCF is not a separate activity. It is part of a continuous cycle: clinical evaluation identifies uncertainties, PMCF collects data to address those uncertainties, and the next clinical evaluation incorporates that data.

This cycle is central to MDR. It reflects the principle that clinical evaluation is never finished. It is updated as new evidence emerges.

If your PMCF plan does not define what uncertainties need to be addressed, it does not fulfill its regulatory function. And if your PMCF evaluation report does not feed back into the CER, you have broken the cycle that MDR requires.

Clinical Evaluation Report Structure: What Changed

The structure of the CER itself shifted under MDR. MEDDEV 2.7.1 Rev 4 provided a template that many manufacturers still follow. But MDR Annex XIV, Part A defines the content of the CER more precisely.

The biggest difference is in how clinical data is presented and analyzed. Under MEDDEV 2.7.1 Rev 4, the CER could be heavily weighted toward equivalence and literature review. Under MDR, the CER must explicitly appraise each piece of clinical data for relevance, reliability, and weight of evidence.

This appraisal is not superficial. It requires judgment. It requires understanding the limitations of each study, the applicability to your device and population, and the overall strength of the evidence base.

I see many CERs that list studies but never critically evaluate them. The literature is summarized, but not appraised. The conclusions are stated, but not justified by the quality of the evidence.

This is a major gap. Reviewers expect to see why each study was included, what its limitations are, and how much weight it carries in the overall evaluation.

Appraisal Methodology

MDR does not prescribe a specific appraisal methodology. But it expects one to be applied consistently.

In practice, this means using recognized frameworks for assessing study quality. It means documenting inclusion and exclusion criteria. And it means explaining why certain evidence was given more weight than other evidence.

Without this, the CER becomes a collection of summaries. With it, the CER becomes a reasoned evaluation that demonstrates compliance.

Benefit-Risk Determination: More Explicit, More Documented

MEDDEV 2.7.1 Rev 4 required a benefit-risk analysis. But it was often a qualitative conclusion at the end of the CER.

MDR requires a more explicit, more documented benefit-risk determination. Annex I, Section 1 makes it a general safety requirement. Annex XIV, Part A requires the CER to analyze benefit-risk in the context of the state of the art.

This means weighing the clinical benefits of your device against its risks, and comparing that balance to what is currently available.

In practical terms, this analysis must address: What benefits does your device provide? What are the residual risks after mitigation? How does this compare to alternative treatments?

If the benefit-risk profile is less favorable than current options, you must justify why your device should still be on the market. This is rarely straightforward.

I see manufacturers who present benefits and risks separately but never integrate them into a single, reasoned conclusion. The CER states that the device is safe and effective, but does not explain why the benefits outweigh the risks in clinical use.

What This Means for Your Work Today

If you are still using MEDDEV 2.7.1 Rev 4 as your primary reference, you are working from an outdated framework.

The concepts in MEDDEV 2.7.1 Rev 4 are still useful. But they do not cover what MDR requires. And the gaps are where reviews fail.

To align with MDR, you need to shift how you think about clinical evaluation. Start with the device-specific data. Treat equivalence as an exception that requires full justification. Build SOTA analysis into every CER update. Link PMCF directly to clinical evaluation gaps. Appraise your clinical data rigorously. And document your benefit-risk determination explicitly.

This is not optional. It is the baseline that reviewers expect under MDR.

The transition from MEDDEV 2.7.1 Rev 4 to MDR was not just regulatory language. It was a shift in how clinical evidence is evaluated, updated, and maintained. And that shift is reflected in every review, every audit, and every Notified Body assessment.

Understanding what changed is the first step. Applying it consistently in your clinical evaluation work is the only way to meet current expectations.

Peace,
Hatem
Clinical Evaluation Expert for Medical Devices
Follow me for more insights and practical advice.