Software as a Medical Device (SaMD): Regulatory Guide

Written By Caroline

October 2025

Medical devices are no longer purely mechanical instruments limited to physical functions. Today, they actively assist healthcare professionals in their work and guide medical decision-making. The integration of electronic components, touchscreens, and software, combined with connectivity and artificial intelligence, has made them more precise, reliable, and user-friendly. Behind the data they collect and process lies one or more layers of software.

Among these, Software as a Medical Device (SaMD) holds a distinctive place. Recognized as a medical device in its own right, it is governed by a strict regulatory framework established by the FDA in the United States, Health Canada, and the European Union Medical Device Regulation (EU MDR).

Its potential to enhance healthcare delivery is already well demonstrated, and SaMD is emerging as one of the most influential trends in the MedTech industry. The global SaMD market is projected to reach $93.08 billion by 2031, up from $30.17 billion in 2023.

If your goal is to develop Software as a Medical Device, this article outlines the key aspects you should understand before getting started:

What is Software as a Medical Device (SaMD)?

Software as a Medical Device is standalone software intended to diagnose, treat, or prevent disease without being embedded in dedicated hardware. The International Medical Device Regulators Forum (IMDRF) defines it as an independent independent digital application or cloud-based platform that runs on smartphones, tablets, or desktop computers to serve a medical purpose.

Software is not classified as SaMD when its functions are purely administrative, such as billing or appointment scheduling, because these tasks carry no clinical intent or patient care purpose.

It is also excluded when integrated as part of a physical medical device to control core hardware functions. In that case, it may be classified as Software in a Medical Device, also known as SiMD, embedded software, firmware, or microcode.

The distinction helps determine which regulatory requirements apply and shapes the development process from design through market approval.

To better understand these nuances, here’s a comparative table with concrete examples:

Software as a Medical Device	Not Software as a Medical Device
A mobile app that analyzes ECG data to detect arrhythmias and recommend medical follow-up.	Software that controls the electrical signals of a pacemaker (SiMD).
An AI-driven platform that reviews patient health data to propose personalized treatment options.	A hospital information system that stores patient records or billing data.
A cloud-based tool that predicts risk of diabetic complications based on patient-entered data.	A fitness tracker app that measures steps and calories.
Software that calculates radiation dose for oncology treatments.	Software embedded in a radiation therapy machine to deliver the actual treatment (SiMD).

How is Software as a Medical Device (SaMD) Used in Healthcare?

SaMD supports clinical workflows across diagnosis, treatment, monitoring, and prevention. Each application delivers measurable impact by processing medical data and supporting healthcare decisions. Below are four key areas where medical device software performs.

Diagnosis

Diagnostic software interprets medical images, signals, or patient data to support clinical decision-making. It can detect tumors in CT scans, identify eye diseases in retinal images, or flag abnormal heart rhythms from ECG recordings. These capabilities help reduce diagnostic delays and improve accuracy in high-volume clinical settings.

Treatment

Therapeutic software records and analyzes patient health data to calculate or adjust therapy. Insulin dosage calculators guide diabetes management, oncology software plans radiotherapy dose, and algorithms personalize drug regimens based on individual biomarkers. All three may improve patient outcomes when integrated into care pathways.

Monitoring

Monitoring apps continuously track patient health in real time. They record cardiac activity, track respiratory function, and measure oxygen levels. When significant changes occur, the system alerts both patients and clinicians to prompt timely intervention before complications escalate.

Prevention

Preventive software collects data from connected medical devices to identify risk factors and avoid delayed treatment. Genetic analysis programs assess predisposition to conditions such as cancer, cardiovascular disease, or gestational diabetes, enabling earlier lifestyle or clinical interventions.

How Do Regulators Classify Software as a Medical Device?

Identifying the correct classification for software as a Medical Device is the first step toward market approval. Each regulatory body assigns risk-based categories that determine the specific compliance requirements a product must meet before it can be sold.

While the main authorities classify software according to the level of patient risk, their systems differ in structure and scope. These classes correspond to those used for all medical devices, not just software.

FDA Classification

The FDA uses a three-tier classification system that aligns risk with regulatory scrutiny.

Class I includes the lowest-risk software, such as applications supporting general wellness or basic diagnostic functions. These products face general controls only.

Class II covers moderate-risk software, such as ECG interpretation tools or insulin dose calculators. The FDA applies additional special controls to Class II devices to ensure reliability and effectiveness.

Class III includes high-risk software that sustains or supports life, such as applications used to configure pacemakers. These devices may require premarket approval.

Health Canada Classification

Health Canada uses a four-class system that adds an extra tier to distinguish between high-risk from very high-risk software.

Class I includes the lowest-risk software and is generally exempt from licensing.

Class II covers moderate-risk software, such as image viewers capable of taking measurements.

Class III applies to high-risk software that supports critical therapeutic decision-making.

Class IV is reserved for very high-risk software, including tools used in cancer treatment, where malfunction could have life-threatening consequences.

EU MDR Classification

The European Union Medical Device Regulation (EU MDR) applies Rule 11, which assesses risk based on context and the severity of potential harm. The rule focuses particularly on software that supports diagnostic or therapeutic decisions.

Class IIa includes software that provides information used for diagnostic or therapeutic purposes.

Class IIb covers software where incorrect decisions could cause serious deterioration in health.

Class III applies to software that could lead to death or irreversible health deterioration. The rule ensures that higher-risk software undergoes more rigorous conformity assessment.

Despite their differences, all these classification systems share the same principle: the greater the potential impact of a software failure on patient safety, the stricter the regulatory requirements.

CLEIO’s development process aligns with each of these categories to ensure compliance from the earliest design stages.

What Are the Regulatory Pathways for Software as a Medical Device?

Once a software as a medical device product is classified, developers must follow the appropriate regulatory pathway to obtain market authorization. Each authority provides distinct submission routes based on the risk class of the product and its degree of novelty.

Selecting the right pathway early in the development process avoids costly delays and repositioning during regulatory review.

FDA Pathways

The FDA offers three main pathways for software as a medical device seeking market access in the United States.

510(k) Premarket Notification is the most commonly used pathway for Class II devices. It requires demonstrating that the SaMD is substantially equivalent to a legally marketed predicate device, making it the preferred route for moderate-risk software such as ECG interpretation tools or decision-support applications.

De Novo Classification applies when a novel moderate-risk device has no suitable predicate. Manufacturers can petition the FDA to establish a new regulatory classification with defined special controls, which then serves as a predicate for future 510(k) submissions.

Premarket Approval (PMA) is required for Class III devices that sustain or support life. It is the most rigorous pathway, demanding full clinical evidence, software documentation, and risk management files. Software driving life-critical decisions, such as AI tools used in oncology or cardiac care, typically falls under this category.

Health Canada Medical Device Licence (MDL)

In Canada, software as a medical device requires a Medical Device Licence (MDL) issued by Health Canada for Class II, III, and IV devices.

The application must include safety and effectiveness evidence, a risk management summary, and quality management documentation aligned with ISO 13485. Higher-risk classes require additional clinical evidence and software documentation in line with IEC 62304.

Canada also participates in the Medical Device Single Audit Program (MDSAP), which allows a single audit to satisfy requirements across multiple participating jurisdictions, reducing the compliance burden for manufacturers targeting several markets simultaneously.

CE Marking via Notified Body

In the European Union, software as a medical device must carry CE marking before reaching the market.

Class IIa and IIb devices require the involvement of a notified body, which reviews a technical file covering clinical evidence, risk management, and post-market surveillance plans.

Class III software undergoes a full quality assurance assessment, including review of the clinical evaluation report and design documentation, before a CE certificate is issued.

Manufacturers based outside the EU must appoint an Authorized Representative to manage regulatory obligations on their behalf.

Which Standards Apply to Software as a Medical Device Development?

Medical device software is subject to internationally recognized standards that ensure quality, safety, and regulatory compliance.

Together, these standards provide a common framework that guarantees the reliability of software used in clinical environments. Developers who follow them reduce the risk of regulatory rejection and accelerate time to market.

Below are four key standards that commonly apply to SaMD development across the industry.

IEC 62304

IEC 62304 is the primary standard for managing the life cycle of medical device software. It defines requirements related to development, maintenance, and risk control.

The standard classifies software into three safety classes based on the potential severity of harm caused by a failure.

This classification helps ensure that the level of effort invested in development aligns with the associated risk to patient safety.

Class	Level of Risk
Class A	No possibility of injury or damage to the patient.
Class B	Potential for injury, but not severe.
Class C	Potential for severe harm or death.

IEC 82304

The IEC 82304 standard applies to standalone health software, such as mobile health applications and cloud-based diagnostic platforms. It provides essential guidance that is highly relevant to SaMD developers.

Unlike IEC 62304, which focuses on the internal software development process, IEC 82304 addresses the software product as a whole.

It covers labeling, instructions for use, cybersecurity, and performance throughout the product life cycle. Its goal is to ensure that health software remains safe, reliable, and user-friendly for both patients and clinicians.

ISO 13485

ISO 13485 is an international standard for quality management systems (QMS) specific to medical devices. For SaMD developers, applying this standard means integrating processes into a broader organizational framework that covers document control, design reviews, supplier management, and corrective actions.

A company certified to ISO 13485 demonstrates consistent practices and earns greater confidence from regulatory authorities and customers alike.

CLEIO maintains ISO 13485 certification to ensure that every project follows documented, repeatable quality processes from planning through post-market surveillance.

ISO 14971

ISO 14971 is the global reference for risk management in medical devices, including software. It requires identifying hazards associated with software use, such as algorithm errors, cybersecurity vulnerabilities, or data misinterpretation, and assessing their severity and likelihood of occurrence.

When risks are identified, appropriate measures must be implemented to mitigate them before the product reaches the market. ISO 14971 also emphasizes maintaining a risk management file that covers the entire product life cycle. This file must be continuously updated to track any design changes or new hazards.

Standard	Scope	Impact on Medical Device Software
IEC 62304	Software life cycle	Defines development, testing, and maintenance requirements.
IEC 82304	Standalone health software	Ensures safety, reliability, usability, and cybersecurity.
ISO 13485	Quality management system	Embeds software into organizational QMS practices.
ISO 14971	Risk management	Identifies, evaluates, and mitigates software-related hazards.

All of these standards align with the requirements of the FDA, Health Canada, and European Union regulations. Developing medical device software in accordance with their guidance facilitates regulatory approval and encourages adoption by healthcare professionals.

5 Best Practices for Successful Software as a Medical Device Development

SaMD development follows the same principles as other types of software. However, success depends on a structured process that incorporates the regulatory standards described above. It also requires applying best practices that address the complexity of products designed for high-risk medical environments.

At CLEIO, we integrate these practices into every project to help ensure compliance, safety, and performance.

Define and Document Requirements

Development is more effective when grounded in well-defined and documented requirements. By identifying clinical needs, user expectations, and regulatory constraints early, teams build a foundation that guides design decisions through verification and validation.

Keeping documentation up to date throughout the process ensures traceability, supports regulatory submissions, and simplifies future audits.

Integrate Risk Management from The Beginning

When software operates as a medical device, it must ensure patient safety. This requirement should be considered from the very first stage of development, before a single line of code is written.

Integrating risk management in accordance with ISO 14971 into design activities allows potential hazards to be identified early and mitigation strategies to be implemented effectively. This approach also minimizes the risk of product recalls and regulatory non-compliance, and patient harm.

Follow a Structured and Compliant Life Cycle

Adhering to IEC 62304 ensures that development, testing, and maintenance follow a recognized structure. This approach supports the creation of reliable software and makes it easier for regulatory bodies to assess during submissions and audits.

A structured life cycle also reduces rework, improves team coordination, and accelerates time to market without sacrificing quality.

Design for Maintainability

Modular coding and well-structured documentation make maintenance easier over months and years of operation. They also help ensure the software’s security and efficiency throughout its life cycle.

Maintainable code allows teams to respond quickly to security patches, feature requests, and regulatory changes without introducing new defects or destabilizing existing functionality.

Build Cybersecurity into Every Layer

Medical device software must be protected against unauthorized access and data breaches. Implementing strong security practices safeguards both patient data and software performance in clinical environments.

The FDA and European Union regulations now require cybersecurity to be addressed throughout the entire software life cycle. Integrating security into every stage of development is therefore a best practice that may no longer be overlooked.

SaMD is at the heart of innovation in health technology. When developed and maintained in compliance with relevant standards, it supports diagnosis, enhances treatment effectiveness, and improves patient care outcomes.

Our experts always got your back

With extensive cross-industry experience, we’re always ready to tackle medical device software development complexities and propel your success.

Get in Touch

Return to blog

Author & Collaborators

Written by
Caroline

Newsletter & Monthly Digest

Subscribe to get our insights delivered to your email inbox.