Software for Medical Devices: The 2026 SaMD Classification Guide

Introduction: Why Classification Comes Before Code

Most resources on software for medical devices fall into one of two camps. Dense regulatory explainers parse FDA guidance and EU MDR annexes but rarely touch engineering reality. “Best eQMS” listicles compare platforms but skip the question that determines which tools a team needs at all. This guide bridges both.

The premise is simple. Every downstream compliance decision (the FDA submission pathway, the EU MDR class, the IEC 62304 safety class, and the scope of quality system and cybersecurity obligations) flows from one upstream decision: correctly classifying the software.

This guide is written for medtech founders, QA/RA leads, and engineers who need a decision framework before architecture and documentation rigor are locked in. It also covers three 2026 regulatory inflection points:

• The February 2, 2026 transition to FDA’s Quality Management System Regulation (QMSR)
• FDA’s February 3, 2026 cybersecurity guidance
• The January 6, 2026 shift in Clinical Decision Support (CDS) and general wellness guidance

This is not a vendor comparison. It is a classification-first framework for building correctly from day one.

What Software for Medical Devices Actually Means in 2026

“Software for medical devices” is an umbrella term that splits into three distinct regulatory categories that builders routinely conflate: Software as a Medical Device (SaMD), Software in a Medical Device (SiMD), and Clinical Decision Support (CDS).

The category is large and growing. The SaMD market reached $3.83 billion in 2025, and FDA had authorized more than 1,350 AI-enabled devices by early 2026.

SaMD vs. SiMD: The Architecture Line That Changes Everything

SaMD is standalone software with a medical purpose that runs on general-purpose platforms such as PCs, smartphones, or cloud servers. SiMD is software embedded in and inseparable from device hardware. It is subject to different lifecycle and validation expectations because its behavior is bound to the physical device.

This distinction is the first fork in the decision tree. It determines whether the software is regulated as a device in its own right or reviewed as part of a hardware submission.

• SaMD examples: a smartphone app that analyzes photos of skin lesions, a cloud service that flags suspected strokes on CT scans, desktop software that calculates radiation therapy doses.
• SiMD examples: infusion pump firmware controlling flow rates, pacemaker control software, embedded code running an imaging scanner.

Clinical Decision Support (CDS): The Contested Middle Ground

The 21st Century Cures Act excludes certain CDS software from the device definition if it meets four criteria. The software must:

1. Not acquire, process, or analyze medical images, signals, or patterns
2. Display, analyze, or print medical information
3. Support or provide recommendations to a healthcare professional
4. Enable that professional to independently review the basis of the recommendation, so they are not primarily relying on it

This exemption remains contentious and unsettled, requiring careful self-assessment rather than assumption. On January 6, 2026, FDA updated its CDS and general wellness guidance and withdrew its SaMD Clinical Evaluation guidance. The update signaled a deregulatory lean, including enforcement discretion for certain prediction software.

Enforcement discretion is not the same as exemption. Regardless of where a product lands, teams should document their rationale.

What’s Explicitly Excluded from SaMD Regulation

Standard exclusions include:

• Administrative tools, such as scheduling and billing software
• EHR display functions
• General health and wellness apps, such as fitness trackers
• Medical Device Data Systems (MDDS), which transfer, store, or display device data without analyzing it

Misreading these exclusions causes errors in both directions: some teams over-engineer compliance for low-risk tools, while others dangerously under-engineer borderline products that actually meet the device definition.

Market Snapshot: Why the Numbers Don’t Agree

SaMD market estimates for 2026 range from roughly $5–6 billion to $47 billion, depending on scope and definition. Mordor Intelligence, for example, sizes the market at $5.24 billion in 2026. The spread is not a data error; it signals that the category is still being defined inconsistently.

Two segments stand out:

• Diagnostic and screening software held a 42% share in 2025, making it the dominant SaMD subtype.
• Medical imaging diagnostics accounts for roughly 39% of the high-risk SaMD market in 2026, driven by AI-enabled image interpretation and case prioritization in radiology.

Major companies in the space include Siemens Healthineers, Medtronic, Philips, GE Healthcare, and Roche. They are named here to show the category’s scale, not as recommendations.

The Classification Decision Framework: Answer These Questions Before You Build

This section is the practical core of the guide: a structured sequence of questions that determines classification before architecture decisions are final. Answering them out of order, or skipping them, is the root cause of most late-stage compliance rework.

Question 1: What Does the Software Do With Clinical Information?

The International Medical Device Regulators Forum (IMDRF) framework sorts software by the significance of the information it provides:

• Inform clinical management: providing options or aggregating data
• Drive clinical management: guiding next diagnostics or treatment steps
• Treat or diagnose: directly determining a diagnosis or therapy

This answer feeds directly into both the FDA risk class and the EU MDR Rule 11 outcome.

Question 2: What’s the Significance of the Information and the State of the Healthcare Situation?

Risk classification works on two axes:

• Significance of the information: inform, drive, or treat/diagnose
• Criticality of the healthcare situation: non-serious, serious, or critical

Software that only informs management of a non-serious condition sits at the low end. Software that diagnoses a critical condition sits at the top. As either axis rises, classification escalates from Class I toward Class III under FDA, and from Class IIa toward Class III under MDR.

Question 3: Does It Run on Dedicated Hardware or a General-Purpose Platform?

This is the SaMD/SiMD fork in decision-framework form:

• A cloud inference engine reading uploaded imaging studies is SaMD.
• An algorithm bound to device firmware that cannot run independently is SiMD.

The answer affects how the submission is bundled. SiMD is typically reviewed as part of the hardware device submission, not on its own.

Question 4: Is It Recommending Action or Just Organizing/Displaying Data?

Apply the CDS test as a practical checklist:

• [ ] Does it avoid processing images, signals, or patterns?
• [ ] Is the source and basis of each recommendation displayed?
• [ ] Can a clinician independently review that basis?
• [ ] Is it intended to support clinical judgment rather than replace it?

AI/ML-based recommendation engines rarely satisfy the exemption cleanly: their reasoning is often opaque, and many process signals or images, which pushes most of them into regulated SaMD territory.

Putting It Together: From Answers to Classification Outcome

Profile	Likely FDA Class	Likely MDR Class	CDS Exemption Viable?
Displays guideline-based options, transparent logic	Possibly non-device	Possibly not a device, or IIa	Often yes
Informs diagnosis of a serious condition	Class II	IIa	Rarely
AI-driven triage of a critical condition	Class II or III	IIb or III	No
Drives therapy where errors may cause death	Class III	Class III	No

The output of this framework becomes the input for every later layer of the compliance stack.

FDA Classification and Submission Pathway Mapping

Once classification is determined, it dictates a specific FDA submission pathway and documentation burden.

Risk Classes I, II, III and What Determines Them

• Class I: low-risk software, typically informing management of non-serious conditions. Often exempt from premarket review.
• Class II: moderate-risk software. Most SaMD lands here, including many diagnostic aids.
• Class III: high-risk software that supports or sustains life, or whose failure could cause serious harm.

The class follows directly from the outputs of Questions 1 and 2.

Choosing the Pathway: 510(k), De Novo, or PMA

• 510(k): demonstrates substantial equivalence to a legally marketed predicate device.
• De Novo: for novel low-to-moderate risk devices with no suitable predicate.
• PMA (Premarket Approval): for Class III devices. It requires the most extensive evidence, often including clinical data.

Lead time and evidence requirements grow from 510(k) to De Novo to PMA. RA leads and engineers should plan for the chosen pathway before development starts, because it shapes what verification and validation data the team must generate.

AI-Enabled Devices and the Predetermined Change Control Plan (PCCP)

A Predetermined Change Control Plan lets manufacturers of adaptive or learning algorithms get defined future modifications authorized in advance, so those changes do not each require a new submission. A PCCP describes the planned changes, the methods for implementing and validating them, and an assessment of their impact.

With more than 1,350 AI-enabled devices authorized by early 2026, PCCPs are becoming central to SaMD strategy for any team planning to retrain models after launch.

The January 2026 CDS and Wellness Guidance Shift

This update, effective January 6, 2026, has proven volatile in practice: it withdrew the SaMD Clinical Evaluation guidance and adopted a more deregulatory posture, including enforcement discretion for certain prediction software. Teams should therefore document their risk rationale even where enforcement discretion may apply, so they are prepared if expectations tighten again.

EU MDR Annex VIII Rule 11: How Classification Differs Across the Atlantic

Software regulated as moderate risk under FDA often lands in a stricter default tier under EU MDR.

The Default Outcome: Class IIa for Diagnostic/Therapeutic Decision Software

Under Rule 11, software that provides information used for diagnostic or therapeutic decisions defaults to Class IIa. In practice, this means Notified Body involvement for most clinical software.

Escalation Triggers: When Software Becomes IIb or Class III

• Class IIb: when decisions based on the software may cause serious deterioration of health or require surgical intervention.
• Class III: when those decisions may cause death or irreversible deterioration of health. This is the highest-risk tier under MDR.

Monitoring Physiological Processes: A Separate Sub-Rule

Software that monitors physiological processes is Class IIa by default. It becomes Class IIb when it monitors vital parameters whose variations could put the patient in immediate danger.

Where FDA and MDR Classification Diverge: Practical Implications

The same software can receive different classes in each jurisdiction. A decision-support tool that qualifies for CDS exemption or Class I treatment in the US may be Class IIa under MDR. A US Class II triage tool may be IIb in Europe. Global product teams must classify per jurisdiction rather than assume parity.

This area is still moving. RAPS has reported that proposed EU Commission changes aim to clarify Rule 11 and could delay AI Act implementation for medical devices.

The EU AI Act Overlay: When Your SaMD Is Also ‘High-Risk AI’

The AI Act functions as a parallel compliance layer, stacking on top of MDR classification rather than replacing it.

Automatic High-Risk Classification Under Annex III

Any AI system that is itself a medical device, or that serves as a safety component of an MDR/IVDR-regulated device, is automatically classified as high-risk AI. Because Notified Body review is required for most such software, nearly all ML-based SaMD falls into this tier.

Key Compliance Deadlines: August 2026 and August 2027

• Most high-risk AI obligations applied from August 2, 2026.
• CE-marked MDR/IVDR SaMD subject to Notified Body review has until August 2, 2027. This gives builders a concrete planning horizon.

Dual Compliance Strategy for MDR + AI Act Software

Few resources treat the overlap between the two regimes as a single problem. The practical recommendation is to run MDR Rule 11 classification and AI Act risk-tiering as one combined assessment early in design. Supporting practices include:

• Cross-referencing AI-specific risks (data bias, model drift) inside the ISO 14971 risk management file
• Maintaining unified technical documentation with sections mapped to both regimes
• Aligning data governance records with clinical evaluation evidence

IEC 62304 Safety Classes: Translating Risk Classification into Engineering Rigor

Regulatory risk class determines what a product needs for market access. The IEC 62304 safety class determines how rigorously the software must actually be engineered and documented.

Class A, B, C Defined by Potential Patient Harm, Not Regulatory Risk Class

IEC 62304 classes are assigned based on the software’s potential to contribute to patient harm. This is a separate axis from FDA or MDR risk class, though the two are related.

• Class A: no injury or damage to health is possible.
• Class B: non-serious injury is possible.
• Class C: death or serious injury is possible.

Clause 4 Prerequisites: QMS, Risk Management, and Software Safety Classification

Clause 4 sets three prerequisites before development proceeds:

1. An established quality management system (QMS)
2. Integration of ISO 14971 risk management
3. Formal classification of the software

Skipping this upfront classification is a common root cause of audit findings and late-stage rework.

The Closed-Loop Lifecycle: Clauses 5–9

The lifecycle runs through planning, specification, design, implementation, verification, release, monitoring and fixing, and updating. All of it operates under continuous configuration management and risk control.

The safety class scales the rigor required at each stage. Class C demands detailed design, unit-level verification, and exhaustive documentation. Class A permits a much lighter process.

Traceability Requirements That Auditors Actually Check

Auditors follow an end-to-end chain: requirements → architecture → implementation → testing → risk controls. Teams should build traceability into their ALM and development pipeline from day one. Reconstructing it retroactively before an audit is expensive and error-prone.

What IEC 62304 Does NOT Cover: Scope Boundary Clarity

IEC 62304 governs only the development and maintenance of medical device software. It does not cover validation and final release of the medical device itself, even when the device is entirely software. It also does not amount to full MDR compliance. Conformance is one component of the regulatory stack, not a complete program.

The February 2026 Compliance Stack: QMSR and Cybersecurity Obligations

This is the newest and most time-sensitive layer of the stack, and it took effect this year.

QMSR Replaces 21 CFR Part 820: ISO 13485:2016 Incorporated by Reference

Effective February 2, 2026, FDA’s QMSR amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. US manufacturers now operate under a quality system harmonized with the global standard rather than a separate US-specific structure.

What Changes Practically for QA/RA Teams

Gap-assessment priorities include:

• Aligning procedures with ISO 13485:2016 terminology and clause structure
• Strengthening risk-based thinking across all QMS processes, not just design controls
• Reviewing management review, supplier controls, and record requirements

Much legacy Part 820 documentation can be restructured and re-mapped rather than replaced wholesale. Design history and device master records, for example, often translate into ISO 13485 equivalents.

FDA’s February 3, 2026 Cybersecurity Guidance: Quality System and Premarket Content Expectations

This guidance supersedes the June 27, 2025 version and explicitly aligns with the QMSR, which took effect one day earlier. It details quality-system and submission content expectations for:

• Encryption
• Authentication
• Firmware signing
• Key management

Section 524B ‘Cyber Device’ Requirements: Monitoring, Vulnerability Process, SBOM

Premarket submissions for “cyber devices” must include three elements:

1. A plan to monitor, identify, and address postmarket vulnerabilities
2. A process that provides reasonable assurance of cybersecurity
3. A software bill of materials (SBOM)

The SBOM must cover commercial, open-source, and off-the-shelf components, not only proprietary code.

Building an SBOM That Passes Review

Reviewers expect SBOMs to cover every layer: the operating system, firmware, drivers, runtime libraries, dependencies, and cryptographic libraries. Accepted formats include SPDX 2.3 or CycloneDX 1.5+, incorporating the NTIA minimum elements.

SBOMs should be generated automatically as a build-pipeline artifact. Treating them as a manual pre-submission exercise invites gaps and stale data.

From Classification to Architecture: A Builder’s Decision Framework

A single classification output drives the FDA pathway, MDR class, AI Act tier, IEC 62304 safety class, and QMSR and cybersecurity scope at the same time.

Mapping Classification to Documentation Rigor Before Writing Code

Three artifacts should exist before the first sprint, not after feature freeze:

• The risk management file
• The software safety classification
• The SBOM pipeline

Early classification prevents costly architecture refactors driven by requirements discovered late.

Architecture Choices That Simplify (or Complicate) Compliance

Some design choices shrink the compliance surface:

• Modular architecture with documented interfaces
• Separating safety-critical Class C components from lower-risk Class A/B modules
• Isolating AI/ML inference components, so model updates under a PCCP do not ripple through the entire codebase

Deployment model matters too. Cloud-based SaMD raises distinct cybersecurity and SBOM considerations, including third-party infrastructure, shared responsibility, and continuous updates. On-premise SiMD has a more contained footprint.

Common Misclassification Mistakes That Cost Teams Months

• Assuming CDS exemption without documenting the four-criteria test
• Assuming FDA and MDR classification parity
• Treating IEC 62304 conformance as full regulatory compliance
• Ignoring the AI Act overlay for MDR-regulated AI components

Correct, early, well-documented classification is the single highest-leverage decision in a SaMD program.

Conclusion: Classification Isn’t a Compliance Checkbox. It’s a Design Decision.

Classification determines architecture, documentation rigor, and submission strategy. Getting it right early prevents rework in every subsequent compliance layer.

The 2026 landscape reinforces this point. QMSR harmonization with ISO 13485, stricter cybersecurity and SBOM expectations, a deregulatory nudge on CDS and wellness software, and the AI Act overlay all start from the same place: accurate classification. The framework applies regardless of which eQMS, ALM, or traceability tooling a team eventually selects.

Next Steps: Get Your Classification Right Before You Scale

Teams can use this framework as a working checklist for current or upcoming products:

1. Answer the four questions in order and record the rationale for each.
2. Classify separately for each target jurisdiction.
3. Assign the IEC 62304 safety class and set up the risk file and SBOM pipeline.
4. Revisit classification whenever software scope, AI/ML components, or deployment architecture changes materially.

For organizations moving from framework to implementation, Adiamed offers further guidance on navigating classification and the compliance stack that follows from it.