Software as a Medical Device (SaMD): Development, Regulation & AI

Most teams building medical software underestimate what they’re walking into. They focus on the algorithm and defer the regulatory question. That is the wrong order. The classification question shapes everything else, and it needs to be answered before you write a single line of production code.

What Is Software as a Medical Device (SaMD)? The Official Definition

Software as a Medical Device is defined by the IMDRF as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device,” a definition that has been adopted by regulators across the FDA, EU MDR, and most national competent authorities worldwide.

The phrase “without being part of a hardware medical device” is the operational boundary. SaMD runs on commercial off-the-shelf hardware. It does not require a proprietary physical device to function. That independence is what makes SaMD a distinct regulatory category and what separates it from Software in a Medical Device (SiMD), which we will address directly in the next section.

Two elements determine whether your software meets the SaMD definition. First, there must be a medical purpose: diagnosis, prevention, monitoring, treatment, or alleviation of disease or injury. Second, that medical purpose must be fulfilled by the software itself, not by hardware it happens to run on. A fitness app counting steps has no medical purpose in the regulatory sense. A software application analyzing ECG data to detect atrial fibrillation does, and it qualifies as SaMD.

The IMDRF, or International Medical Device Regulators Forum, also published its risk categorization framework for SaMD (N12FINAL:2014) in September 2014, establishing the foundational two-dimensional matrix that regulators now use globally to assign risk categories to SaMD products. That framework remains the backbone of how FDA, EU MDR, and other authorities think about SaMD risk.

SaMD vs SiMD vs General Health Software: Key Differences

Software as a Medical Device (SaMD), Software in a Medical Device (SiMD), and general health or wellness software occupy three distinct regulatory categories, and confusing them is one of the most costly mistakes a development team can make.

SiMD is embedded software that drives or controls a physical medical device. Think of the firmware in a pacemaker, the control software in an infusion pump, or the embedded operating system in an MRI scanner. SiMD cannot be separated from its hardware. It is regulated as part of the device itself and does not meet the SaMD definition because it is, by design, part of a hardware medical device.

SaMD has no such hardware dependency. It delivers its medical purpose on a general-purpose platform. The same SaMD application can run on a hospital workstation, a physician’s laptop, or a cloud server. That hardware independence is what defines it.

General health software sits outside medical device regulation entirely. The FDA’s 2019 guidance on software functions distinguishes between functions that meet the medical device definition and functions that do not. A wellness app that encourages healthy habits, tracks sleep, or logs meals does not have a medical purpose in the regulatory sense and is not a medical device. The moment that same application adds a function to diagnose a sleep disorder or recommend a medication adjustment, it may cross into SaMD territory.

The line between SaMD and general health software is not always obvious, and regulators expect manufacturers to document their reasoning. Intended use is the key. If your software is labeled, marketed, or designed to support clinical decision-making, it will likely be treated as SaMD regardless of whether you call it a wellness tool.

How to Determine If Your Software Qualifies as SaMD

Determining whether your software qualifies as Software as a Medical Device requires a structured analysis of intended use, the medical purpose claimed or implied, and the independence of the software from any specific hardware platform.

Start with intended use. Intended use is the specific objective the manufacturer claims for the software, and it is the primary basis on which regulators decide whether the SaMD definition applies. If your intended use statement describes a medical purpose, diagnosis, monitoring, treatment, or alleviation of a disease or condition, you are in SaMD territory.

Next, examine your indications for use. Indications for use describe the target patient population, disease, or condition the software addresses. A software tool that generates reports from wearable data may have a neutral intended use, but if the indications for use reference patients with heart failure or diabetics requiring glucose trend analysis, regulators will treat it as SaMD.

Third, consider how you market and label the software. Regulators look at labeling, promotional materials, and how users actually interact with the product. A company that sells a general analytics platform but markets it specifically to cardiologists for arrhythmia detection has effectively claimed a medical purpose, even if the intended use statement does not say so explicitly.

Finally, check hardware independence. If the software requires a proprietary hardware device to function, you may be looking at SiMD rather than SaMD. If it runs on general-purpose computing hardware, it clears that element of the SaMD definition.

Real-World Examples of Software as a Medical Device

Software as a Medical Device products now cover a wide range of clinical applications, from AI-powered radiology tools to chronic disease management platforms, and understanding what qualifies helps teams scope their own development programs accurately.

Diagnostic Imaging and AI Screening Tools

AI-enabled radiology software that analyzes medical images to detect findings such as pulmonary nodules, diabetic retinopathy, or breast cancer is among the most established categories of SaMD. These products take DICOM images as input, process them through machine learning algorithms, and output findings to assist radiologists or ophthalmologists. The FDA has cleared multiple products in this category, and they consistently require a 510(k) premarket submission.

IDx-DR, the FDA-cleared AI system for detecting diabetic retinopathy, is a well-known example. It operates without requiring a clinician to interpret each image in real time. The software output alone drives the clinical recommendation to refer or not refer a patient. That level of autonomy places it squarely in a higher SaMD risk category.

Clinical Decision Support Software

Clinical decision support (CDS) software that provides patient-specific recommendations based on clinical data is SaMD when the software output is intended to replace or inform a clinical judgment rather than simply present reference information. A drug interaction checker that alerts a pharmacist to a contraindication is closer to non-device CDS. A sepsis prediction algorithm that outputs a risk score and recommends intervention is SaMD.

Chronic Condition Management and Remote Monitoring

Software applications that monitor patients with diabetes, heart failure, or hypertension by analyzing data from connected devices and alerting clinicians to deterioration qualify as SaMD. The medical purpose is monitoring a condition, and the software delivers that purpose independently. Paired with wearables, these platforms are one of the fastest-growing SaMD segments. The AI-enabled SaMD market reached USD 9.25 billion in 2025 and is projected to grow to USD 31.18 billion by 2031, according to Mordor Intelligence’s AI-enabled SaMD market report. That 22.45% compound annual growth rate reflects how much clinical demand there is for software that can make sense of continuous patient data streams.

Mental Health and Digital Therapeutics

FDA-authorized digital therapeutics for conditions like substance use disorder and ADHD, including products such as reSET and EndeavorRx, represent SaMD that delivers a therapeutic intervention directly through the software experience. These are not companion apps to a drug. The software is the treatment. That distinction places them in a high-significance medical purpose category under the IMDRF framework.

SaMD Risk Classification Framework

The IMDRF risk categorization framework for Software as a Medical Device uses a two-dimensional matrix that combines the significance of the information provided by the SaMD with the state of the healthcare situation or condition it addresses, producing four risk categories that map to regulatory requirements.

The two axes work together. On one axis: how significant is the SaMD’s output to the clinical decision? Informing, driving, or treating are the three levels, from lowest to highest significance. On the other axis: what is the severity of the healthcare situation? Non-serious, serious, or critical or life-threatening.

A SaMD that informs a clinician about a non-serious condition sits in Category I, the lowest risk tier. A SaMD whose output directly treats or drives a decision in a critical or life-threatening situation sits in Category IV, the highest. Most AI-powered diagnostic tools land in Category II or III, which is where the regulatory burden becomes substantial.

The FDA maps this IMDRF framework to its Class I, II, and III device classification system. Class I devices face the least regulatory control. Class II devices typically require 510(k) premarket notification, demonstrating substantial equivalence to a predicate device. Class III devices require Premarket Approval (PMA), the most rigorous pathway, reserved for SaMD that supports or sustains human life or presents a high risk of illness or injury.

As of August 2024, the FDA cleared approximately 97% of AI-enabled medical devices via the 510(k) pathway, according to ICON’s analysis of FDA AI medical device regulations. That figure tells you where most SaMD products sit on the risk curve, and it underscores why getting the 510(k) submission right is the practical priority for most development teams.

How SaMD Is Regulated: FDA, EU MDR, and Global Frameworks

Software as a Medical Device faces distinct regulatory requirements in the United States, the European Union, and across international markets, with the IMDRF framework providing the harmonization layer that connects them.

FDA Regulation of SaMD

The FDA regulates SaMD under the Federal Food, Drug, and Cosmetic Act, treating qualifying software as a medical device subject to the same premarket review, quality system requirements, and postmarket surveillance obligations that apply to hardware devices. The FDA uses the term “device software function” (DSF) to describe software that meets the medical device definition.

FDA premarket pathways for SaMD depend on the device classification. Class II SaMD predominantly goes through the 510(k) pathway, which requires demonstrating substantial equivalence to a legally marketed predicate device. Class III SaMD requires a PMA application with clinical evidence demonstrating reasonable assurance of safety and effectiveness. The De Novo pathway exists for novel low-to-moderate risk SaMD with no predicate, and it has become an important route for first-of-kind AI applications.

The FDA issued final guidance on “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions” on February 3, 2026, according to Berkley Life Sciences’ analysis of the FDA AI/ML SaMD framework. Cybersecurity is no longer a postmarket afterthought. The FDA expects SaMD manufacturers to address it throughout the quality management system and in premarket submissions, including a Software Bill of Materials (SBOM) and a documented vulnerability management plan.

EU MDR and SaMD in Europe

The EU Medical Device Regulation (EU MDR 2017/745) introduced stricter classification rules for software than its predecessor, the Medical Device Directive (MDD). Under EU MDR, most SaMD products that previously sat in Class I have been reclassified into Class IIa or higher, requiring conformity assessment by a Notified Body and CE marking before market access.

EU MDR uses Rule 11 specifically for software classification. A SaMD intended to provide information used to make decisions with diagnosis or therapeutic purposes is at minimum Class IIa. SaMD that drives decisions in situations that may cause death or irreversible health deterioration is Class III. Manufacturers must compile a Technical File and conduct a clinical evaluation demonstrating the SaMD’s clinical performance and safety, supported by real-world data where available.

Germany’s DiGA framework, which creates a reimbursement pathway for digital health applications under the national health insurance system, had over 40 DiGAs pass through it as of mid-2024, according to Intuition Labs’ digital therapeutics market analysis. DiGA is a nationally specific layer on top of EU MDR, and it represents one of the most mature market access models for SaMD in the world. Other EU member states are building similar frameworks.

IMDRF Global Harmonization

The International Medical Device Regulators Forum coordinates regulatory alignment across its member jurisdictions, which include the FDA, the European Commission, Health Canada, Japan’s PMDA, and others. The IMDRF’s SaMD working group has published a series of guidance documents including N12 on risk categorization, N23 on clinical evaluation, N41 on analytical and clinical validation, and N56 on Good Machine Learning Practice. In 2025, the IMDRF also published updated guidance titled “Characterization Considerations for Medical Device Software and Software-Specific Risk,” further refining how regulators assess software-specific risk factors.

Key Standards for SaMD Development: IEC 62304, ISO 13485, ISO 14971

IEC 62304: Software Lifecycle for Medical Devices

IEC 62304 defines the software development lifecycle requirements for medical device software, including SaMD. It covers software development planning, requirements analysis, architectural design, detailed design, implementation, integration, testing, and maintenance. It also addresses the management of software of unknown provenance (SOUP), which is any software component not fully developed under the quality management system, including open-source libraries and third-party components.

IEC 62304 assigns safety classifications to software units based on the severity of harm that could result from a software failure. Class A software, where failure cannot cause harm, has the lowest requirements. Class C software, where failure can result in death or serious injury, has the highest. Most SaMD with a meaningful medical purpose falls into Class B or Class C, which means documentation requirements are substantial.

ISO 13485: Quality Management System for Medical Devices

ISO 13485 specifies quality management system (QMS) requirements for organizations involved in the design, development, production, and service of medical devices, including SaMD. A QMS compliant with ISO 13485 is required for EU MDR conformity assessment and is strongly expected in FDA premarket submissions. The standard covers design controls, document control, corrective and preventive action (CAPA), internal audits, supplier controls, and change control, all of which directly affect how SaMD is developed and maintained.

Design controls are particularly important for SaMD. They require documented design inputs, design outputs, design verification, design validation, and design transfer. For AI-powered SaMD, design validation must include clinical validation data showing the software performs as intended on the target patient population, not just on the development dataset.

ISO 14971: Risk Management for Medical Devices

ISO 14971 provides the risk management framework for medical devices and SaMD. It requires manufacturers to identify hazards, estimate and evaluate associated risks, implement risk control measures, and evaluate residual risk against defined acceptability criteria. The standard mandates a risk management file that covers the entire product lifecycle, from development through postmarket surveillance.

For SaMD, hazard identification must account for software-specific failure modes including incorrect outputs from AI algorithms, cybersecurity vulnerabilities, and performance degradation on data outside the training distribution. Risk management is not a one-time exercise. It continues through postmarket monitoring and must be updated when the software changes.

AI and Machine Learning in SaMD

AI and machine learning in Software as a Medical Device introduce regulatory challenges that standard premarket frameworks were not designed to handle, primarily because adaptive algorithms can change their behavior after deployment without a traditional software update.

The FDA’s approach to AI/ML-based SaMD has evolved significantly. The core concern is what the FDA calls “locked” versus “adaptive” algorithms. A locked algorithm produces the same output for the same input after deployment. Regulators know how to handle that. An adaptive algorithm updates its parameters based on new data it encounters in the real world. The performance characteristics you demonstrated in your premarket submission may no longer describe the product your users are actually running.

The FDA’s response to this is the Predetermined Change Control Plan (PCCP). A PCCP submitted as part of a premarket authorization describes the types of changes the manufacturer anticipates making to the AI/ML model, the methods used to evaluate those changes, and the performance criteria that will be met before implementing them. Approved changes within the scope of the PCCP can be implemented without requiring a new 510(k) or PMA supplement. This is a meaningful reduction in regulatory friction for AI SaMD developers who plan their change management strategy upfront.

Good Machine Learning Practice (GMLP) is the FDA’s framework of best practices for developing, testing, and deploying AI/ML-based SaMD. It covers dataset management, reference standards for training and testing, human-AI team performance, and transparency requirements. The IMDRF’s N56 guidance aligns with GMLP principles, creating a consistent global baseline.

In Europe, the EU AI Act introduces additional requirements for AI systems used in medical devices, classifying them as high-risk AI systems subject to conformity assessment, transparency obligations, and ongoing monitoring. Companies bringing AI-enabled SaMD to European markets now face both EU MDR requirements and EU AI Act compliance, and those frameworks must be addressed together, not sequentially.

For life sciences companies working through digital health strategy, the AI governance layer is not optional and not something to bolt on at the end. Build it into the QMS from the start. That is true whether you are developing a de novo AI diagnostic tool or integrating a third-party ML model into an existing SaMD platform.

Building a QMS That Supports SaMD at Scale

A quality management system for Software as a Medical Device must address software-specific requirements that general ISO 13485 implementations often underserve, including design control traceability, SOUP management, configuration control, and postmarket software performance monitoring.

The most common gap we see in life sciences companies building their first SaMD product is a QMS designed for a hardware device that has been stretched to cover software. It does not work. Software has different failure modes, different change velocities, and different validation requirements. Your QMS needs procedures that were written for software from the beginning.

Start with your design control procedure. Every SaMD requirement must be traceable from the initial user need through design inputs, design outputs, verification, and validation. For AI SaMD, your validation must include clinical validation data. The FDA’s guidance on software validation, combined with IEC 62304, gives you the framework. Your QMS must operationalize it.

SOUP management is a persistent pain point. Most SaMD products use third-party libraries, open-source frameworks, and cloud services. Each of those is SOUP under IEC 62304 and requires documented assessment of the functionality used, identification of known anomalies, and evidence that SOUP was tested in the context of your application. Your SBOM, which the FDA now requires in premarket submissions, is the starting inventory for SOUP management.

CAPA processes must cover software defects, field complaints, and cybersecurity vulnerability reports. Your postmarket surveillance plan needs defined metrics for SaMD performance, including algorithm performance on real-world data compared to the predicate dataset performance claimed in your submission. If those metrics diverge, your CAPA and change control processes must be ready to respond.

Digital innovation in life sciences is a journey, not a race. SaMD development that cuts corners on QMS infrastructure creates regulatory debt that compounds fast. Building with purpose means your QMS, your IEC 62304 lifecycle documentation, your ISO 14971 risk management file, and your clinical evaluation are constructed together as a coherent system, not assembled under submission deadline pressure.

If your organization is working through SaMD strategy, QMS implementation, or AI governance for medical software, Smartbridge’s life sciences consulting practice works with digital health and MedTech companies to bring structure and clarity to exactly these challenges. No generic playbooks. That’s the Smartbridge way.

Frequently Asked Questions About SaMD