SaMD: Designing, Certifying, and Evolving Your Software

Introduction

Developing a Software as a Medical Device (SaMD) must meet a dual imperative: to comply with the requirements of Regulation (EU) 2017/745 (MDR) from the outset, and once on the market, to update or enrich the software without compromising its compliance or CE marking.

At Certeafiles, we work to lower regulatory barriers and free your innovation. Follow our practical guide and turn certification into a true performance lever for your SaMD publishing company.

Let’s break it down in two parts:

1. Regulatory and technical design of an MDR-compliant SaMD.
2. Managing evolutions—updates, new features, and bug fixes—while preserving the validity of the CE marking.

1. Regulatory and Technical Design under the MDR

1.1 Qualification and Classification: The First Building Block

Qualification (Article 2, MDCG 2019-11)

• Determine whether your software meets the definition of a medical device based on its intended use (diagnosis, prevention, prognosis, monitoring, or medical decision support).
• Document this decision in a qualification memo that will accompany you through certification and facilitate any re-assessment.

Classification (Annex VIII, MDCG 2019-11, MDCG 2021-24)

All classification rules apply, and a SaMD is considered an active medical device. Rule 11 of Annex VIII is dedicated to software, including SaMD:

• Software intended to provide information used to make decisions for diagnostic or therapeutic purposes, or to monitor physiological processes, is classified at least as Class IIa (and even IIb or III if the impact can be serious or endanger the patient). This requires a Notified Body (NB) review.
• Only other software may qualify for Class I.

1.2 Applicable Standards: Pillars of Your Compliance

1.3 Required Documentation per IEC 62304

IEC 62304 addresses the software lifecycle for medical device software, including SaMD, according to its software safety class (A, B, or C). The required documentation in the software file depends on classification and risk factors. However, some elements are mandatory regardless of device class:

1.Software Design and Development
A detailed software development plan is expected, outlining processes, deliverables, requirements traceability, configuration management, and issue resolution. This plan must be updated throughout software development.
A list of software requirements must also be documented, detailing each requirement with its verification method. It should cover the following themes: software system inputs/outputs, interfaces with other systems, alarms, safety, database, installation/acceptance, operation/maintenance, user documentation, regulatory requirements.
A V-model software development lifecycle must be implemented, decomposing the system into software units (descending branch of the V) and validating those units before integrating back into the system (ascending branch of the V).
Once decomposed, a unit implementation and verification plan must be established.
A list of released software versions must be maintained, and a software maintenance plan must be in place.

2.Software Issue Management
Feedback must be captured, recorded, and evaluated as part of a software issue resolution process. These feedback items must be traced and logged by type, domain, and severity, enabling formal change requests.
Trend analysis can be useful to identify recurring issues or anticipate future failures. Configuration management is also crucial: maintain an accurate inventory of software components, versions, and associated documentation. This includes identifying third-party software (SOUP), whose failures or lack of support must be factored into risk management.

3.Change Management
Change management is fundamental for lifecycle control. Each change must undergo a formal impact assessment (technical and regulatory), be approved, documented, and communicated to stakeholders: users, Notified Bodies, etc. Implementation of changes must include complete verification to ensure updated software remains compliant with original requirements. Traceability of changes must be maintained up to the release of the new version.

1.4 Clinical Evaluation: Scale Effort to Risk

1.Literature Review
For established calculations or scores, a targeted bibliography review plus regression tests may suffice.

2.Clinical Study/Technical and Clinical Performance Study
Mandatory when introducing a novel algorithm (AI, machine learning): use an independent dataset, an AUC/Se-Sp metric, and a risk-appropriate protocol.

3.Data Compilation
Clinical data are compiled in a Clinical Evaluation Report.

4.Post-Market Clinical Follow-up (PMCF)
Complements the initial evaluation: user feedback, incidents, real-world performance indicators.

Recommendation: Tailor your clinical evaluation plan to risk class and innovation level, not to a one-size-fits-all format.

2. Managing Evolutions: Keeping the CE Marking Up to Date

2.1 Submitting Change Requests to the Notified Body

The MDR (EU 2017/745) governs change management:

• Manufacturer: Each change is handled within the QMS (Art. 10 § 9) and must be notified to the NB before implementation if it could affect safety, performance, or intended use (Annex IX § 4.10).
• Notified Body: Per Annex VII § 4.9, the NB receives the request, assesses the impact, and decides—either an addendum to the certificate or a full re-assessment—via a reasoned decision.
• Legacy MDs: Devices certified under AIMDD/MDD before MDR entry and governed by Art. 120, per MDCG 2020-3 guidance:
  • Non-significant changes may be implemented during the transition period;
  • Significant changes require full MDR conformity before deployment.

2.2 Predetermined Change Control Plan (PCCP) for AI

The AI Act (EU 2024/1689) requires high-risk AI system providers to document planned modifications and measures ensuring ongoing compliance. MDCG 2025-6 (Section V) clarifies that a device incorporating a learning system whose evolutions were evaluated during initial review does not need a full procedure redo—hence the value of including a PCCP, inspired by FDA practices, in the original CE submission.

A robust PCCP rests on five guiding principles:

• Scoped and Delimited: Define the perimeter of authorized changes (hyperparameters, thresholds, versions, retraining).
• Risk-Based: Integrate into the ISO 13485 QMS and ISO 14971 risk management.
• Evidence-Based: Fixed test protocols and KPIs to revalidate each update.
• Transparent: Alert thresholds and formal NB notification process.
• Total Product Lifecycle (TPLC): Periodic reviews and internal audits for continuous compliance verification.

This approach avoids full re-certification for each iteration while preserving safety, performance, and agility.

3. Agile Compliance Best Practices

• Modularity: Isolate UI, clinical engine, and AI pipeline to limit the scope of each change.
• Automated Traceability: Each merge request feeds your technical file (commit → tickets → CE annexes).
• “Live” Post-Market Monitoring: Anonymous dashboard of performance, incidents, and KPIs in real time.
• Standardized “No-Notify” Memos: Three-page documents with cross-references to MDCG guidance, signed by RA/QA.
• Cross-Functional Rituals: Sprint reviews with RA/QA and risk reviews with developers to maintain a common language.

Conclusion

Designing and evolving a SaMD under the MDR is not a fixed constraint but a dynamic process:

• Robust standards (ISO 13485, IEC 62304, ISO 14971) provide a clear framework.
• Structured change management protects you without slowing innovation.
• A proactive partnership with your Notified Body turns an audit into a simple verification step.

Ready to turn SaMD certification into a real asset?
At Certeafiles, we support you at every stage:

• Personalized guidance from our experts.
• Hands-on, tailored training.
• Internal audits.
• Coming soon: our digital tool to guide you step by step from A to Z toward CE certification of your medical device software.

👉 Contact us for a free initial consultation and discover how Certeafiles can accelerate and secure your market launch.