Software Updates That Trigger Recertification: The Evidence Gap

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

This scenario plays out more often than it should. Software updates feel incremental to development teams. To regulators and Notified Bodies, some of these updates represent fundamentally different devices requiring the same level of clinical evidence as a first submission.

The disconnect comes from how we frame the question. Manufacturers ask: “Is this change significant enough to report?” Regulators ask: “Does this change affect the clinical safety and performance claims we previously assessed?”

Those are not the same question.

The Regulatory Baseline: What MDR Actually Requires

MDR Article 61 establishes that manufacturers must notify their Notified Body of any changes to the device or its intended purpose. Annex IX and XIV specify that significant changes require a new conformity assessment.

For software, the challenge is defining “significant.” Unlike hardware where you can point to new materials or dimensional changes, software modifications exist in code. The impact is functional, not physical.

MDCG 2020-3 on significant changes provides guidance, but it remains principle-based. The document lists examples: changes affecting safety or performance, modifications to the intended purpose, alterations to the clinical benefit.

Here is what I observe in real audits: manufacturers interpret these principles through their development process. Regulatory and clinical teams interpret them through evidence requirements.

The gap between these interpretations is where certificates get suspended.

When Software Changes Invalidate Clinical Evidence

Your clinical evaluation report supports specific performance claims based on specific software behavior. When that behavior changes, the evidence may no longer apply.

Consider a diagnostic algorithm. Version 2.0 was validated showing 92% sensitivity and 88% specificity. Your CER includes clinical data, literature, and bench testing supporting these claims.

Version 3.0 modifies the algorithm core. Sensitivity increases to 95%. Specificity drops to 85%.

Is your previous clinical evidence still valid?

The development team sees improvement. Sensitivity increased. Regulatory sees a new performance profile that was never clinically evaluated. The specificity decrease might affect clinical decisions differently than the original claims.

This is not theoretical. I have reviewed submissions where manufacturers updated machine learning models, retrained on new datasets, and considered it a performance enhancement. The clinical evaluation remained unchanged. The Notified Body rejected the entire submission because the training data change meant the algorithm was effectively new.

The Evidence Continuity Test

Before releasing any software update, ask this question: Can the clinical evidence in my current CER defend the performance claims of this new version?

If the answer requires assumptions, extrapolations, or statements like “the underlying principles remain the same,” you likely need new evidence.

This test applies across several dimensions:

Algorithm Changes: Any modification to diagnostic logic, decision trees, or calculation methods affects the clinical validity of previous performance data.

Input Data Changes: If the software now accepts different data types, ranges, or formats, your clinical evidence must cover these scenarios.

Output Changes: Modified displays, added parameters, or different result presentations can affect clinical interpretation and therefore clinical safety.

Intended Use Expansion: Adding patient populations, new clinical indications, or extended operating ranges always requires corresponding clinical evidence.

The Notification Decision Matrix

Not every software update triggers full recertification. But determining which notification path applies requires clinical thinking, not just regulatory process knowledge.

The decision tree has three branches:

No notification required: Changes that do not affect safety, performance, or the approved device characteristics. Bug fixes that restore intended behavior, security patches with no functional impact, user interface refinements that do not change clinical workflow.

Even here, you document the clinical impact assessment. Auditors will ask why you determined no notification was necessary.

Minor change notification: Changes affecting the device but not requiring new conformity assessment. This is the narrow path. The change must be within the scope of your existing technical documentation and clinical evaluation.

In practice, this applies to incremental improvements where existing clinical evidence directly supports the modified claims. The key phrase is “directly supports.” Not “reasonably supports” or “by extension supports.”

Significant change requiring new assessment: Any modification that affects the clinical safety and performance profile in ways not covered by existing evidence.

This includes algorithm changes affecting clinical output, expanded intended use, new patient populations, modified safety claims, or changed risk-benefit profiles.

Where Manufacturers Misstep

The most common error I see is treating clinical evidence as static. The thinking goes: “We have a valid CER, so we are covered for reasonable updates.”

Clinical evidence is claim-specific and version-specific. Your CER evaluated version X with performance characteristics Y. When version or performance changes, the evidence scope changes.

Another pattern: relying on equivalence to your own previous version. MDR equivalence requires demonstrating that devices are similar in clinical, technical, and biological characteristics. Your version 3.0 might be technically similar to version 2.0, but equivalence still requires clinical evaluation data.

More importantly, if version 3.0 has different performance than version 2.0, you cannot claim equivalence. You need to justify the new performance clinically.

Building Evidence Plans for Software Lifecycles

Here is the strategic approach that survives audit scrutiny:

Treat your software as a product line, not a single device. Each significant version is a variant requiring evidence that connects back to a validated core.

Your clinical evaluation strategy should include:

Core evidence package: Foundational clinical data supporting the basic principles of your technology. This typically includes mechanism of action, literature on the clinical methodology, and data on the fundamental approach.

Version-specific performance evidence: Clinical data or testing demonstrating that each version achieves its claimed performance. This updates with each significant modification.

Comparative evidence: When you release a new version, generate data comparing it to the previous version. This demonstrates continuity or explains differences.

PMCF strategy aligned to software evolution: Your post-market clinical follow-up should capture real-world performance across versions. This becomes evidence for future updates.

This structure allows you to update efficiently while maintaining evidence validity. When version 4.0 releases, you reference the core package, provide version 4.0 performance data, compare to version 3.0, and incorporate PMCF learnings.

The Clinical Evaluation Update Process

When a software change requires new evidence, your CER needs a structured update. This is not just adding an appendix or updating a version number.

The clinical evaluation must reassess:

Clinical safety: Does the modification introduce new hazards or change the probability or severity of existing hazards? This requires updated risk analysis integrated into the clinical evaluation.

Performance claims: Are your stated sensitivity, specificity, accuracy, or other performance metrics still valid? If they changed, what clinical data supports the new metrics?

Clinical benefits: Does the modification affect the benefit side of the benefit-risk determination? Enhanced accuracy might improve clinical outcomes. Changed workflow might affect usability in ways that impact safety.

State of the art: Has the clinical or technical state of the art evolved since your last evaluation? Software updates often aim to match evolving standards or competitor capabilities.

Alternative treatments: Does your modification change how your device compares to alternatives? This affects benefit-risk balance.

Each of these sections requires evidence. When auditors review your updated CER, they look for the clinical reasoning connecting the software change to the evidence updates.

Documentation That Satisfies Scrutiny

Your technical file should contain a clear record connecting software versions to clinical evidence versions.

I recommend maintaining a software-clinical evidence matrix. This document maps each significant software version to the specific clinical data supporting it, the CER version evaluating it, and the regulatory submission covering it.

When a Notified Body asks “what clinical evidence supports version 3.2,” you should be able to point to specific studies, specific CER sections, and specific performance data within minutes.

This matrix also reveals gaps before they become deficiencies. If you cannot identify evidence for a particular version, that is your signal that the change required more clinical work than was performed.

Machine Learning and Algorithm Updates

Software as a Medical Device using machine learning presents a special case. The algorithm can change through retraining without explicit code modifications.

MDR does not provide specific guidance on adaptive algorithms. Regulators are developing positions as submissions increase.

What I observe consistently: any retraining that changes clinical performance characteristics requires new clinical evidence and potentially new conformity assessment.

If your model retrains automatically and performance drifts, you need mechanisms to detect this and trigger evidence generation. Your PMCF plan must include performance monitoring specific enough to identify clinically significant algorithm changes.

Some manufacturers implement locked algorithms post-certification, with retraining only in controlled updates. Others implement performance bounds that trigger notifications if exceeded.

Both approaches can work under MDR, but both require clear documentation of how clinical evidence remains valid across the algorithm lifecycle.

The Notified Body Perspective

Understanding how Notified Bodies evaluate software changes helps you prepare submissions that succeed.

Notified Body reviewers are not trying to block your updates. They are trying to ensure that the device they certify is the device described in your clinical evaluation.

When you submit a change notification, the reviewer asks:

Can I confirm that the clinical evidence covers this version?

If there is any ambiguity, any gap, any assumption required to connect evidence to version, they will question it. Their liability extends to the devices they certify.

This is why change notifications with extensive supporting rationale tend to proceed smoothly, while minimal notifications trigger requests for information.

Your submission should preemptively answer: What changed? Why does existing evidence remain valid? What new evidence supports the change? How does this affect the clinical safety and performance profile?

When you cannot answer these questions clearly, the Notified Body cannot approve the change clearly.

Practical Implementation

Here is what functional management of software updates and clinical evidence looks like:

Stage gate at design phase: Before significant software changes are finalized, Clinical Affairs reviews the clinical evidence implications. This happens during design, not after release.

Clinical impact assessment: Every software modification goes through a documented assessment of clinical evidence validity. This assessment determines the regulatory path.

Evidence generation planning: When a change requires new evidence, this is planned and budgeted as part of the development project, not discovered during regulatory review.

Regulatory strategy alignment: Regulatory Affairs participates in roadmap planning to ensure submission timing and content align with development timelines.

Documentation linkage: Version control systems connect software versions to clinical evidence versions to regulatory submissions.

Companies that implement these processes release updates smoothly. Those that treat clinical evidence as a post-development checkbox face delays, deficiencies, and sometimes suspended certificates.

When Updates Accumulate

A related scenario: multiple minor updates over time that individually seem insignificant but collectively represent major change.

Version 2.1 to 2.2: small interface update. Version 2.2 to 2.3: database optimization. Version 2.3 to 2.4: calculation precision improvement. Version 2.4 to 2.5: expanded input range.

None triggered recertification. But version 2.5 is substantially different from version 2.1 clinically.

Your clinical evaluation should periodically assess cumulative change. Even if individual modifications were minor, their combination might require evidence refresh.

Some manufacturers address this through annual CER updates that holistically evaluate the current device against the current evidence base. This catches gaps that incremental assessments miss.

The Strategic Question

All of this comes down to one strategic question: Are you managing clinical evidence as an ongoing requirement or as a one-time hurdle?

Software evolves continuously. Clinical evidence must evolve with it. Companies that integrate evidence generation into their development lifecycle maintain regulatory compliance efficiently.

Those that separate development from evidence generation face friction at every update.

This is not about regulatory burden. It is about demonstrating that what you claim clinically is what your device actually does, version by version.

That demonstration requires evidence. Not assumptions. Not extrapolations. Evidence.

When your next software update is planned, the clinical evidence question should be the first discussion, not the last approval.

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