MDR Evidence Packs for SaMD Software Updates

A SaMD release is not finished when the build is green. Under the EU Medical Device Regulation, a software update is either a controlled change with evidence or an uncontrolled drift of the device on the market. Teams that treat patches as “just IT” discover the gap when a notified body or competent authority asks for the pack that proves the update remained safe and effective.

What MDR expects when software moves

The European Commission’s overview of the new medical devices regulations situates software within a lifecycle of conformity, vigilance, and post-market obligations. For manufacturers, that means each release that can affect clinical performance or safety must be classified, justified, verified, and documented before it reaches users — and monitored afterwards.

MDR does not invent a separate universe for software, but it amplifies software’s awkward property: you can change the device overnight without shipping a new box. That speed is a product advantage and a regulatory hazard. The evidence pack is how you keep speed without losing control.

Significant change versus routine maintenance

Not every commit is a significant change. Typo fixes in non-clinical copy, dependency patches with no behaviour change in intended use, and infrastructure hardening may stay inside maintenance — if you can show the analysis. Changes that alter intended purpose, clinical algorithms, risk controls, user interface for critical tasks, or interoperability behaviour that feeds clinical decisions usually trigger a deeper path: updated risk management, verification and validation, and potentially notified-body involvement depending on classification and your quality system commitments.

Rule: Decide significant change before you schedule the release train, not after marketing announces the version number.

Document the decision with a short change-impact record: what changed, which hazards are touched, which claims still hold, which tests are required, and whether the technical documentation or clinical evaluation needs revision. Ambiguous “looks minor” notes are how teams accumulate silent significant changes.

The evidence pack, item by item

A usable MDR evidence pack for a SaMD update is a curated set, not a dump of the CI folder. At minimum, most teams need:

• Change description linked to requirements and risk files.
• Significant-change determination with named approver.
• Updated software of unknown provenance (SOUP) and cybersecurity notes where relevant.
• Verification results for units and integrations that the change can affect.
• Validation evidence proportionate to clinical risk — including regression against prior accepted behaviour.
• Traceability from requirement to test to residual risk.
• Labeling / IFU / release-note updates that match the actual build.
• Deployment record: which customers received which digest, when.

Clinical evaluation expectations for SaMD are framed internationally in the IMDRF document on Software as a Medical Device: Clinical Evaluation. Even when your route is EU MDR rather than a US filing, the three-legged idea — valid clinical association, analytical/technical performance, clinical performance — is a practical checklist for what an update must not undermine.

Regression evidence is the frequent weak link

Teams often re-test the new feature and assume the rest of the device still behaves. For SaMD, regression is part of the clinical safety story. If a triage score, measurement pipeline, or alerting rule silently shifts, clinicians inherit a different device under the same name.

Strong regression practice for regulated software looks like this:

• A frozen set of clinical scenarios and golden datasets versioned with the release.
• Explicit tolerance bands for numeric outputs where floating noise is expected.
• UI task scripts for critical use scenarios when the interface changed.
• Negative tests for failed inputs, disconnected services, and degraded modes.
• Comparison reports that a reviewer can read without opening a debugger.

If your SaMD / AIaMD development programme includes machine-learning components, regression also means checking data drift monitors, model cards, and whether the update is a locked model refresh or a learning-system change with its own protocol. Do not hide that distinction inside a generic “AI improvement” release note.

Packaging updates for scrutiny

Notified bodies and auditors do not want archaeology. Structure the pack so a stranger can answer, in one sitting: What is the device version? What changed? Why is it still conforming? What was tested? What residual risks remain? What will you watch after release?

Practical packaging tips from programmes that survive audits:

1. One index PDF or HTML that links every artefact with checksums.
2. Stable identifiers for builds (not only marketing versions).
3. Diff summaries written for clinical and quality readers, not only engineers.
4. Separation between “evidence of this change” and “entire QMS library.”
5. A post-market follow-up plan: complaints tags, vigilance triggers, metrics to review at a defined interval.

Rule: If the pack requires a tribal guide to navigate, it will fail the first independent review.

Coordination with custom hospital deployments

Many SaMD products land inside larger hospital estates built or integrated through healthcare software development programmes. Update evidence then has a second audience: the customer’s change board. They need deployment windows, rollback criteria, interface impact, and training notes. Align manufacturer evidence with customer change control early, or you will ship a compliant build into an institution that refuses it for lack of local paperwork.

Interface contracts deserve explicit regression. A FHIR profile tweak or HL7 mapping change can alter clinical display without changing your core algorithm. Include those consumers in the impact analysis when the update touches interoperability.

Common failure modes

Hotfixes without packs. Emergency patches still need proportional evidence and a follow-up complete pack. “We will document later” becomes never.

Marketing versions ≠ technical versions. Customers on 4.2.1-hotfix3 while the CER still cites 4.2.0 is a classic finding.

Test environments that are not representative. Synthetic data that never stressed edge populations will not defend a clinical claim after an algorithm change.

SOUP blindness. Upgrading a cryptography or imaging library can be a significant change even when your application code barely moved.

Closing

MDR evidence packs turn SaMD software updates from hopeful releases into controlled device changes. Significant-change discipline, clinical-evaluation continuity, and readable regression evidence are the three pillars. Build the pack as you build the software — not as a scramble the week before a surveillance audit.

If you are reshaping release governance for a CE-marked or CE-bound product, a short architecture review with Yoctobe’s SaMD practitioners can surface gaps in impact analysis and regression design before the next notified-body interaction.