Software as a Medical Device (SaMD): The Complete Regulatory Guide

What Is Software as a Medical Device?

Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. That definition comes from the International Medical Device Regulators Forum (IMDRF), and it is the foundation upon which every major regulatory authority has built its approach to regulating medical software.

The key phrase is "without being part of." SaMD runs independently. It is not firmware controlling a ventilator or the software inside a CT scanner. It is software that stands on its own and qualifies as a medical device based on its intended purpose.

Examples include a mobile application that analyzes dermatoscopic images to assess skin lesion malignancy risk, a cloud-based algorithm that interprets ECG data to detect atrial fibrillation, a clinical decision support tool that recommends chemotherapy dosing based on patient genomics, or a machine learning model that triages chest X-rays by flagging suspected pneumothorax for priority radiologist review.

The IMDRF Definition

The IMDRF published its foundational SaMD guidance in 2013 (IMDRF/SaMD WG/N10FINAL:2013), with subsequent documents on clinical evaluation, quality management, and risk categorization. The IMDRF defines SaMD as:

"Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."

The IMDRF further clarifies what SaMD is not:

• Software that drives or controls a hardware medical device is not SaMD — it is software in a medical device (SiMD)
• Software used in the manufacture or maintenance of a medical device is not SaMD
• Software that is a general-purpose tool (e.g., a spreadsheet used by a clinician) is not SaMD unless the manufacturer specifically intends it for a medical purpose

The intended use is what determines whether software qualifies as SaMD. A general-purpose video conferencing application is not SaMD, even when used for telemedicine. But a platform specifically designed for remote patient monitoring with clinical decision support crosses the line — its intended purpose is medical.

SaMD vs. SiMD vs. Hardware: Understanding the Distinctions

The distinction between SaMD, SiMD, and hardware-based medical devices is not academic. It determines your regulatory pathway, documentation requirements, quality system obligations, and classification.

Category	Definition	Examples	Regulatory Implication
SaMD (Software as a Medical Device)	Standalone software that performs a medical function independently of any hardware medical device	AI-based diagnostic imaging analysis, clinical decision support apps, remote monitoring platforms	Regulated as an independent medical device; classification based on software's intended purpose and risk
SiMD (Software in a Medical Device)	Software that is integral to a hardware medical device — it controls, drives, or influences the device's function	Firmware in an infusion pump, operating software for a CT scanner, embedded software in a pacemaker	Regulated as part of the parent device; software documentation submitted with the hardware device's regulatory submission
Software as accessory	Software that connects to or augments a hardware medical device but is not the device itself	A companion mobile app that displays data from a glucose monitor, software that configures a hearing aid	May be regulated as an accessory to the parent device or independently, depending on jurisdiction and intended use
Non-device software	Software used in healthcare but without a medical intended purpose	EHR systems (administrative functions), hospital scheduling software, general wellness apps	Not regulated as a medical device (though may be subject to data privacy regulations)

Why the Distinction Matters

If your software is SiMD, it rides along with the hardware device through the regulatory process. Your classification is determined by the parent device, not the software independently. If your software is SaMD, it must go through the regulatory process on its own — its own classification, regulatory submission, clinical evidence, and post-market surveillance plan.

Practical tip: If your product takes data from a hardware medical device (like a sensor or monitor) and performs independent analysis, diagnostic interpretation, or clinical recommendations, it is almost certainly SaMD — even though it requires hardware to acquire the data. The software's independence in performing the medical function is what makes it SaMD.

SaMD Classification

Classification is the first and most consequential regulatory decision for any SaMD product. It determines which regulatory pathway you must follow, what level of clinical evidence you need, and how much scrutiny your product will receive from regulators. Three classification frameworks matter most: the IMDRF framework, the FDA's approach, and the EU MDR's Rule 11.

IMDRF Risk Categorization Framework

The IMDRF published its risk categorization framework for SaMD in 2014 (IMDRF/SaMD WG/N12FINAL:2014). It uses a two-dimensional matrix that considers the significance of the information provided by the SaMD to the healthcare decision and the state of the healthcare situation or condition.

Dimension 1 — Significance of information to healthcare decision:

• Treat or diagnose: The SaMD provides information used to take immediate or near-term action — treatment, diagnosis, or action to prevent disease
• Drive clinical management: The SaMD provides information used to aid in treatment decisions, clinical management, or determine urgency/timing of intervention
• Inform clinical management: The SaMD provides information that is not intended to trigger immediate action but informs clinical management decisions (e.g., trending data, aggregated population data)

Dimension 2 — State of the healthcare situation or condition:

• Critical: Life-threatening or requires urgent intervention to prevent permanent impairment
• Serious: Requires medical intervention to prevent long-term irreversible consequences or significant impact on health
• Non-serious: Slow-progressing conditions or conditions that do not require urgent medical intervention

The intersection of these two dimensions produces the IMDRF risk category:

	Critical	Serious	Non-serious
Treat or diagnose	Category IV	Category III	Category II
Drive clinical management	Category III	Category II	Category I
Inform clinical management	Category II	Category I	Category I

• Category I — lowest risk. Example: software that aggregates and displays population health trends for general wellness purposes.
• Category II — moderate risk. Example: software that assists clinicians in identifying drug interactions based on patient medication lists.
• Category III — higher risk. Example: AI software that analyzes retinal images to detect diabetic retinopathy.
• Category IV — highest risk. Example: software that autonomously determines radiation therapy dosing parameters.

FDA Classification of SaMD

The FDA does not directly use the IMDRF category labels (I through IV) for regulatory purposes. Instead, SaMD is classified into FDA device classes (Class I, II, or III) based on the level of risk, the intended use, and the applicable product code and classification regulation.

In practice, the FDA has mapped its approach to be broadly consistent with the IMDRF framework:

IMDRF Category	Typical FDA Class	Typical FDA Pathway	Level of FDA Review
Category I	Class I (exempt) or Class II	Exempt or 510(k)	Low — may not require premarket submission
Category II	Class II	510(k) or De Novo	Moderate — standard premarket review
Category III	Class II (with special controls)	De Novo or 510(k)	Significant — rigorous review, clinical data often required
Category IV	Class III	PMA	Highest — full clinical evidence, PMA review

The FDA has also carved out certain categories of software that are not regulated as medical devices at all. Under the 21st Century Cures Act (2016) and subsequent FDA guidance, the following types of software are excluded from device regulation:

• Clinical Decision Support (CDS) software that meets all four Cures Act criteria: (1) not intended to acquire, process, or analyze a medical image, signal, or pattern from an in vitro diagnostic device or patient; (2) intended for the purpose of displaying, analyzing, or printing medical information; (3) intended for the purpose of supporting or providing recommendations to a healthcare professional; and (4) intended for the purpose of enabling the healthcare professional to independently review the basis for the recommendation so that they do not have to rely primarily on the software
• Administrative support software (e.g., billing, scheduling, claim processing)
• Software for maintaining or encouraging a healthy lifestyle (general wellness) that presents low risk to users

Software that does not meet all four CDS criteria — for example, software that processes medical images or does not allow the clinician to independently review the basis for recommendations — remains regulated as a medical device.

Practical tip: The four-criteria CDS exclusion is narrower than many software companies assume. If your software provides a clinical recommendation and the clinician cannot independently review the underlying basis — for example, because the recommendation comes from a black-box AI model — your software does not qualify for the exclusion and is regulated as a device. Do not design your regulatory strategy around this exclusion without careful legal analysis.

EU MDR Rule 11 Classification

The EU MDR classifies standalone software through Rule 11 of Annex VIII. Rule 11 represents a significant change from the MDD era, where most standalone software was Class I. Under the MDR, the classification depends on the purpose and risk of the decisions the software informs.

Rule 11 classification logic:

• Class III — Software intended to provide information used to make decisions for diagnosis or therapeutic purposes that could cause death or an irreversible deterioration of a person's state of health
• Class IIb — Software intended to provide information used to make decisions for diagnosis or therapeutic purposes that could cause a serious deterioration of a person's state of health or a surgical intervention
• Class IIa — All other software intended for diagnostic or therapeutic decision-making purposes
• Class I — All other medical device software not covered above

The practical impact of Rule 11 has been dramatic. Software that was Class I under the MDD is now Class IIa or higher under the MDR. This means many software manufacturers that previously self-certified their products now require Notified Body involvement — and many have struggled to find available Notified Body capacity.

Comparison of classification approaches:

Software Function	IMDRF Category	FDA Class (Typical)	EU MDR Class (Rule 11)
AI that autonomously adjusts insulin pump dosing in a critical situation	IV	Class III (PMA)	Class III
AI that detects diabetic retinopathy from fundus images	III	Class II (De Novo)	Class IIb or III
Software that calculates cardiac output from echocardiogram measurements	II–III	Class II (510(k))	Class IIa or IIb
App that tracks blood pressure trends and presents data to clinician	I–II	Class II or exempt	Class IIa
Wellness app that tracks step count and provides exercise motivation	Not SaMD	Not a device (general wellness)	Not a device (if no medical intended purpose)

Practical tip: Do not assume that your FDA classification translates directly to your EU MDR classification. Many SaMD products that are Class II (510(k)) in the US are Class IIb or even Class III under the EU MDR. Plan your classification strategy for each jurisdiction independently.

The FDA Digital Health Center of Excellence (DHCoE)

Before diving into specific regulatory pathways, it is important to understand the organizational home for SaMD oversight within the FDA. The Digital Health Center of Excellence (DHCoE), established in 2020 within the Center for Devices and Radiological Health (CDRH), is the FDA's central coordinating body for digital health technology. It aligns and coordinates digital health work across the entire agency, and it is the primary point of contact for SaMD-related regulatory strategy.

DHCoE's Role and Functions

The DHCoE serves several functions that directly affect SaMD manufacturers:

• Regulatory guidance development: The DHCoE leads development of guidance documents specific to SaMD, AI/ML-enabled devices, cybersecurity, and digital health technologies broadly
• Pre-submission consultation: The DHCoE provides a pathway for manufacturers to engage the FDA early in the development process through Q-Submission (Pre-Sub) interactions, which are increasingly structured to address SaMD-specific questions around classification, clinical evidence, and AI/ML considerations
• AI/ML device oversight: The DHCoE maintains the public database of AI/ML-enabled medical devices authorized by the FDA — a critical resource for identifying predicates, understanding regulatory precedent, and tracking market trends
• Cross-agency coordination: Digital health technologies often intersect with multiple FDA centers. The DHCoE ensures consistent regulatory treatment across these centers

The Software Precertification (Pre-Cert) Pilot Program

The DHCoE's predecessor initiative, the Software Precertification (Pre-Cert) Pilot Program, launched in 2017 to explore whether the FDA could streamline oversight of SaMD by evaluating the software developer's organizational excellence rather than reviewing every individual product. Nine companies participated in the pilot, including Apple, Fitbit, Samsung, Johnson & Johnson, Roche, and Verily.

The pilot concluded in September 2022 with a final report. The FDA found that while the concept showed promise, further development would be needed before organizational excellence alone could substitute for product-level premarket review, given the wide range of device indications, technologies, and testing nuances. The Pre-Cert program did not become a permanent pathway, but its learnings influenced subsequent FDA thinking on total product lifecycle approaches and the PCCP framework.

The TEMPO Pilot Program

In December 2025, the FDA announced the Technology-Enabled Meaningful Patient Outcomes (TEMPO) for Digital Health Devices Pilot — a collaboration between the FDA and the Centers for Medicare & Medicaid Services (CMS). TEMPO represents a significant new approach to digital health device access.

What TEMPO does: Under the pilot, the FDA will exercise enforcement discretion for selected digital health devices that do not yet have premarket authorization, allowing them to be used within CMS's Advancing Chronic Care with Effective, Scalable Solutions (ACCESS) model. This means certain SaMD products can reach Medicare and Medicaid patients before completing the traditional premarket authorization process, provided they meet the pilot's safety criteria.

Scope: TEMPO targets digital health devices (including AI-enabled SaMD) intended for use in cardio-kidney-metabolic, musculoskeletal, and behavioral health conditions. The FDA plans to select up to approximately ten U.S. manufacturers for participation.

Timeline: Statements of interest were accepted starting January 2, 2026. Follow-up requests to potential participants began around March 2, 2026. CMS plans to launch the associated ACCESS model on July 1, 2026.

Significance for SaMD manufacturers: TEMPO signals the FDA's willingness to use risk-based enforcement discretion to accelerate patient access to digital health technologies, particularly in therapeutic areas with significant unmet need. While TEMPO is a pilot and not a permanent pathway, it may establish precedent for future regulatory frameworks that integrate market access with real-world evidence generation.

Practical tip: Even if you do not participate in the TEMPO pilot, monitor its outcomes closely. The pilot is likely to influence the FDA's long-term approach to SaMD oversight, real-world evidence requirements, and the intersection between regulatory authorization and reimbursement. If your SaMD addresses chronic disease management, the TEMPO/ACCESS model may become directly relevant to your commercialization strategy.

FDA Regulatory Pathways for SaMD

Once you have determined that your software qualifies as SaMD and identified its FDA classification, you need to select the appropriate premarket pathway. The FDA has three main pathways, and for SaMD, each has specific considerations.

510(k) — Premarket Notification

The 510(k) is the most common pathway to the US market for SaMD products. It requires demonstrating substantial equivalence to a predicate device — a legally marketed device with the same intended use and similar technological characteristics.

When 510(k) works for SaMD:

• Your software has a clear predicate — another SaMD product that has been cleared through 510(k) or classified through De Novo
• Your intended use is the same as or a subset of the predicate's intended use
• Your technological characteristics (algorithm type, input data, output format) do not raise new questions of safety and effectiveness compared to the predicate

SaMD-specific 510(k) requirements:

• Software documentation level per FDA's "Content of Premarket Submissions for Device Software Functions" guidance — the level of documentation depends on the Level of Concern (now replaced by a documentation level framework based on risk)
• Software description including architecture, algorithm description, data flow diagrams
• Software testing — unit testing, integration testing, system testing
• Cybersecurity documentation per FDA's 2023 premarket cybersecurity guidance
• Clinical performance data (standalone clinical evidence or comparison to predicate performance)
• If AI/ML-based: description of training data, algorithm architecture, performance metrics, and known limitations

De Novo — Classification Request

The De Novo pathway is for novel devices that are low to moderate risk but have no predicate. For SaMD, this is an extremely important pathway because many AI/ML-based SaMD products are genuinely novel — no substantially equivalent predicate exists.

A successful De Novo creates a new classification regulation (product code and classification) with associated special controls. This new classification then serves as a predicate for future 510(k) submissions by the original manufacturer or competitors.

When De Novo is right for SaMD:

• Your software performs a function for which no cleared or approved predicate exists
• The risk level is low to moderate (not Class III/PMA-level risk)
• You can demonstrate safety and effectiveness with performance data, clinical validation, and appropriate special controls

Real-world De Novo SaMD examples:

Product	Company	Year	Function	Created Product Code
IDx-DR (now LumineticsCore)	Digital Diagnostics	2018	Autonomous AI detection of diabetic retinopathy from fundus images	QMTr
Caption Guidance	Caption Health (acquired by GE)	2020	AI guidance for cardiac ultrasound image acquisition by non-expert users	QMT
Embrace2	Empafit (now part of Nile Health)	2018	Seizure monitoring using electrodermal activity and accelerometer data	QMI
Viz LVO	Viz.ai	2018	AI-powered large vessel occlusion stroke triage from CT angiography	QAS

Many of these De Novo authorizations have subsequently enabled 510(k) clearances for competing or follow-on products. The De Novo pathway is particularly critical for the AI/ML SaMD ecosystem because it creates the regulatory infrastructure for entire new device categories.

De Novo process specifics:

• Average review time: 150 to 290 days (though some have taken significantly longer)
• Requires a risk-based classification recommendation and proposed special controls
• FDA user fee applies (substantially higher than 510(k) fees)
• Clinical data is almost always required — often a prospective clinical validation study
• Successful De Novo results in a classification order and associated product code

PMA — Premarket Approval

The PMA pathway is required for Class III devices — those with the highest risk. For SaMD, PMA is relatively uncommon because most software does not independently pose the level of risk that triggers Class III classification. However, PMA applies to SaMD intended to drive life-critical clinical decisions autonomously, such as software that determines radiation therapy dosing without physician override.

PMA characteristics:

• Requires valid scientific evidence demonstrating reasonable assurance of safety and effectiveness
• Clinical trials (often pivotal studies) are typically required
• Review time: 12 to 18 months or longer
• Highest user fees
• Post-approval requirements include PMA annual reports and PMA supplements for significant changes

Choosing the Right Pathway

Decision Factor	510(k)	De Novo	PMA
Predicate exists?	Yes — required	No — you create one	Not applicable
Risk level	Low to moderate	Low to moderate (novel)	High
Clinical data burden	Variable (depends on device type)	Usually required	Almost always required (pivotal trial)
Review timeline	~3–5 months	~6–12 months	~12–18+ months
Cost	$$	$$$	$$$$
Creates new classification?	No	Yes	No
Post-clearance/approval changes	New 510(k) or letter-to-file	New 510(k) or letter-to-file	PMA supplement

Practical tip: For AI/ML-based SaMD, start your pathway analysis by searching the FDA's AI/ML-enabled medical device database. The FDA maintains a public list of authorized AI/ML devices with their product codes, regulatory pathways, and intended uses. If a device in your clinical domain has been authorized via De Novo and created a product code, you may be able to use the 510(k) pathway by referencing that De Novo as your predicate.

EU MDR and IVDR for Software

The European regulatory landscape for SaMD is defined primarily by the MDR (Regulation (EU) 2017/745) and, for in vitro diagnostic software, the IVDR (Regulation (EU) 2017/746). Both regulations treat standalone software as a medical device when it has a medical intended purpose.

MDR Requirements for SaMD

Under the MDR, SaMD manufacturers must:

1. Classify the software under Rule 11 (as described above)
2. Appoint an EU Authorized Representative if the manufacturer is established outside the EU
3. Designate a Person Responsible for Regulatory Compliance (PRRC) with defined qualifications
4. Implement a quality management system compliant with Article 10(9) of the MDR (in practice, ISO 13485 is the recognized standard)
5. Prepare technical documentation per Annexes II and III, including software-specific documentation (design, development, validation, architecture)
6. Conduct a clinical evaluation per Article 61 and Annex XIV — including a systematic review of available clinical data, and for Class III or implantable devices, a clinical investigation unless the manufacturer justifies reliance on existing data
7. Undergo conformity assessment via the appropriate Annex procedure:
   • Class I: Self-declaration (Annex IV)
   • Class IIa: Notified Body involvement (Annex IX, Chapters I and III, or Annex XI, Section 10)
   • Class IIb: Notified Body involvement (Annex IX, Chapters I and III, or Annex X with Annex XI)
   • Class III: Notified Body involvement with scrutiny procedure (Annex IX, Chapters I and II)
8. Establish a post-market surveillance system including PMS plan, periodic safety update reports (PSURs), and post-market clinical follow-up (PMCF)
9. Register the device in EUDAMED (when fully operational) and affix UDI
10. Maintain a system for reporting serious incidents and field safety corrective actions (FSCAs) to Competent Authorities

IVDR Requirements for Diagnostic Software

Software that qualifies as an in vitro diagnostic medical device — for example, software that analyzes laboratory data to produce a diagnostic result — falls under the IVDR rather than the MDR. The IVDR's classification system (Classes A through D) and conformity assessment requirements are different from the MDR, and the IVDR has its own software-related provisions.

Key differences for IVD software include:

• Classification under IVDR Annex VIII rules (not MDR Rule 11)
• Performance evaluation instead of clinical evaluation
• Common Specifications may apply for certain device categories
• Different Notified Body capacity constraints (IVDR Notified Body availability has been extremely limited)

The MDCG Guidance on SaMD

The Medical Device Coordination Group (MDCG) has published several guidance documents relevant to SaMD under the MDR:

• MDCG 2019-11 — Guidance on qualification and classification of software (updated in 2023). This document provides decision trees for determining whether software qualifies as a medical device and how Rule 11 applies.
• MDCG 2020-1 — Guidance on clinical evaluation of medical device software. Addresses the unique challenges of clinical evaluation for SaMD, including the role of analytical and clinical validation.
• MDCG 2024-7 — Q&A on Rule 11 classification for software. Provides practical examples and clarifications on how to apply Rule 11 to common SaMD use cases.

Practical tip: If you are entering the EU market with SaMD, read MDCG 2019-11 before you do anything else. Its decision trees are the authoritative guide for determining whether your software qualifies as a medical device under the MDR and, if so, how to apply Rule 11 classification. Many manufacturers have wasted months pursuing the wrong classification because they did not study this guidance carefully.

IEC 62304: Software Lifecycle Requirements

IEC 62304 (Medical device software — Software life cycle processes) is the international standard that defines the software development lifecycle requirements for medical device software. It is recognized by the FDA, referenced in EU harmonized standards, and adopted by regulatory authorities worldwide. If you are developing SaMD, IEC 62304 is not optional — it is foundational.

Software Safety Classification

IEC 62304 classifies software systems (and their constituent software items) into three safety classes:

Safety Class	Criteria	Documentation and Process Rigor
Class A	No injury or damage to health is possible	Minimal documentation requirements; basic development planning and testing
Class B	Non-serious injury is possible	Moderate requirements; verification required at unit, integration, and system levels
Class C	Death or serious injury is possible	Full documentation; comprehensive verification, detailed design documentation, code review, traceability

The safety classification drives the depth and rigor of every lifecycle activity. A Class C software item requires detailed architecture documentation, code reviews, comprehensive unit testing, integration testing, and full traceability from requirements through design, implementation, testing, and risk management. A Class A item needs far less.

Key Lifecycle Processes

IEC 62304 defines the following lifecycle processes:

Software development process:

• Software development planning
• Software requirements analysis
• Software architectural design
• Software detailed design (Class B and C)
• Software unit implementation
• Software unit verification (Class B and C)
• Software integration and integration testing
• Software system testing
• Software release

Software maintenance process:

• Problem and modification analysis
• Modification implementation
• Change control and configuration management

Software risk management process:

• Integration with ISO 14971 risk management
• Software items contributing to hazardous situations must be identified
• Risk control measures must be verified

Software configuration management process:

• Change control
• Configuration identification
• Configuration status accounting

IEC 62304 and Agile Development

One of the most common questions from software companies is whether IEC 62304 is compatible with agile development methodologies. The answer is yes — but with discipline.

IEC 62304 is process-oriented, not methodology-prescriptive. It defines what activities must be performed and what outputs must be produced, but it does not mandate a waterfall approach. You can implement IEC 62304 within Scrum, Kanban, SAFe, or any other agile framework, provided that:

• Each sprint or iteration produces the required documentation artifacts (requirements, design records, test records, traceability)
• Risk management activities are integrated into each iteration, not deferred to the end
• Change control is maintained throughout — agile is not an excuse for undocumented changes
• Software releases are formally controlled with defined release criteria
• Traceability is maintained from requirements through implementation and testing

The FDA has acknowledged the compatibility of agile with medical device software development, and many successful SaMD products have been developed using agile methods with IEC 62304 compliance.

Practical tip: The biggest pitfall in combining agile and IEC 62304 is documentation debt. Teams that defer documentation to "later" or treat it as a post-development exercise invariably find themselves months behind on documentation when they need to submit. Build documentation into every sprint. Treat it as a deliverable, not an afterthought.

IEC 62304:2006+AMD1:2015

The 2015 amendment to IEC 62304 introduced several important changes:

• Clarified the relationship between software safety classification and risk management
• Introduced the concept of "software of unknown provenance" (SOUP) — third-party software components whose development process is unknown — and defined requirements for their management
• Allowed the safety classification of individual software items, not just the entire software system, enabling a more granular approach to documentation rigor
• Updated references to align with ISO 14971:2007

A new edition of IEC 62304 is under development. Until it is published, the 2006+AMD1:2015 version remains the current standard.

IEC 82304-1: Health Software Product Safety

While IEC 62304 governs the software development lifecycle, IEC 82304-1 (Health software — Part 1: General requirements for product safety) addresses the safety of health software products as finished, deployable products. IEC 82304-1 is particularly relevant to SaMD because it applies specifically to standalone health software intended to operate on general-purpose computing platforms — which describes most SaMD products.

Relationship Between IEC 82304-1 and IEC 62304

IEC 82304-1 builds on and requires compliance with IEC 62304. Think of it this way: IEC 62304 defines how to develop medical device software safely, while IEC 82304-1 defines how to ensure that the finished software product is safe when deployed, installed, maintained, and eventually decommissioned. IEC 82304-1 covers the full product lifecycle from the product perspective, while IEC 62304 covers it from the development process perspective.

Key IEC 82304-1 Requirements

IEC 82304-1 addresses product-level safety considerations that IEC 62304 does not cover:

• Product safety requirements: Identification and documentation of safety requirements for the health software product in its intended operating environment
• Risk management integration: Application of ISO 14971 risk management at the product level, including risks related to the operating environment, user interactions, data integrity, and interoperability
• Installation and deployment: Requirements for safe installation, configuration, and deployment of the software product
• Maintenance and updates: Requirements for maintaining the software product throughout its lifecycle, including handling of updates, patches, and configuration changes
• Decommissioning: Requirements for safe decommissioning of the software product, including data handling and transition planning
• Accompanying documentation: Requirements for user documentation, including instructions for use, safety information, and technical specifications

Why IEC 82304-1 Matters for SaMD Manufacturers

IEC 82304-1 is increasingly referenced by regulators and Notified Bodies as part of the conformity assessment process for SaMD. In the EU, it is a harmonized standard under the MDR, meaning that demonstrating compliance with IEC 82304-1 creates a presumption of conformity with the relevant General Safety and Performance Requirements. SaMD manufacturers who address only IEC 62304 without considering IEC 82304-1 may find gaps in their technical documentation related to product-level safety, deployment, and maintenance — areas that Notified Body assessors will examine.

Practical tip: If your SaMD is a standalone software product running on general-purpose hardware (smartphones, tablets, PCs, cloud infrastructure), IEC 82304-1 applies to you. Integrate its requirements into your quality system alongside IEC 62304. The standard's requirements for installation, deployment, and decommissioning are areas where many SaMD manufacturers have documentation gaps.

Predetermined Change Control Plans (PCCP)

One of the most significant regulatory developments for SaMD in recent years is the concept of the Predetermined Change Control Plan (PCCP). The FDA finalized its guidance on PCCPs in December 2024, fundamentally changing how SaMD manufacturers can manage post-market modifications.

Legislative Foundation: FDORA Section 515C

The legislative basis for PCCPs was solidified in late 2022 when the Food and Drug Omnibus Reform Act (FDORA) added Section 515C to the Federal Food, Drug, and Cosmetic Act, granting the FDA explicit statutory authority to authorize PCCPs as part of premarket submissions. This was a critical milestone — before FDORA, the FDA's ability to pre-authorize planned changes lacked clear statutory footing. With Section 515C, PCCPs became a codified element of the regulatory framework, not merely a policy experiment.

Evolution of PCCP Guidance

The PCCP guidance evolved through several stages:

• April 2023: FDA published draft guidance titled "Marketing Submission Recommendations for a Predetermined Change Control Plan for Machine Learning-Enabled Device Software Functions"
• October 2023: FDA, Health Canada, and MHRA jointly published "Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices: Guiding Principles" — five principles for international alignment
• December 2024: FDA finalized the guidance, notably broadening the terminology from "Machine Learning-Enabled Device Software Functions (ML-DSF)" to "Artificial Intelligence-Enabled Device Software Functions (AI-DSF)" — reflecting the FDA's recognition that PCCP principles apply to the full spectrum of AI technologies, not just machine learning

The terminology shift from ML-DSF to AI-DSF in the final guidance is significant. It signals that PCCPs are available for any AI-based software function, including rule-based AI systems, not only those using machine learning. Manufacturers working with non-ML AI techniques should note this expanded scope.

What Is a PCCP?

A PCCP is a plan submitted as part of a premarket submission (510(k), De Novo, or PMA) that describes:

1. Planned modifications — specific, anticipated changes to the device that the manufacturer intends to make after authorization
2. A modification protocol — the methodology the manufacturer will use to develop, verify, validate, and implement each planned modification while maintaining the safety and effectiveness of the device
3. An impact assessment — analysis of how each planned modification could affect the safety, effectiveness, or intended use of the device

If the FDA authorizes the premarket submission with the PCCP, the manufacturer can implement the described modifications — following the approved protocol — without submitting a new premarket submission for each change.

PCCP Modification Protocol in Detail

The modification protocol is the most technically demanding component of a PCCP. It must provide a step-by-step delineation of how each modification will be implemented while ensuring the device remains safe and effective. For AI/ML-based SaMD, the modification protocol typically includes:

• Retraining data requirements: Specifications for the quality, quantity, diversity, and provenance of new training data
• Validation methodology: The exact testing procedure that will be used to verify each modification, including the test dataset, performance metrics, and statistical methods
• Pre-defined acceptance criteria: Quantitative thresholds (e.g., minimum sensitivity, specificity, AUC) that the modified device must meet before the change is deployed — these must be specified in advance, not determined after the fact
• Performance monitoring plan: How the manufacturer will monitor real-world performance after deploying the modification, including metrics, sampling strategies, and triggers for corrective action
• Rollback procedures: How the manufacturer will revert to the previous version if a modification fails to meet acceptance criteria or causes unexpected performance degradation in post-deployment monitoring

Why PCCP Matters for SaMD

Traditional regulation assumes devices remain essentially static after market entry. Software does not work this way — SaMD products are updated frequently with bug fixes, performance improvements, algorithm updates, and model retraining.

Before PCCP, every significant change required a new 510(k) or PMA supplement. PCCP allows manufacturers to define a corridor of anticipated changes upfront and get advance FDA agreement on how those changes will be managed. This is particularly valuable for AI/ML-based SaMD, where model performance can be improved through retraining without changing the fundamental algorithm architecture.

PCCP Scope and Limitations

A PCCP can cover:

• Performance improvements (e.g., retraining an AI model on new data to improve sensitivity)
• Input data changes (e.g., expanding the device to accept images from additional scanner manufacturers)
• Intended use modifications (within defined bounds)
• Algorithm modifications (e.g., updating model weights, changing preprocessing steps)

A PCCP cannot cover:

• Changes that would introduce a new risk not addressed in the original premarket submission
• Changes that would require new clinical evidence that was not contemplated in the modification protocol
• Open-ended changes without defined boundaries — the planned modifications must be specific enough for the FDA to evaluate

Practical tip: Start thinking about your PCCP during product development, not after clearance. The most effective PCCPs are designed alongside the product architecture. If you know you will want to update your AI model quarterly with new training data, design your modification protocol early — define the retraining pipeline, the validation methodology, the performance acceptance criteria, and the monitoring plan. Presenting this as an afterthought in the premarket submission is less likely to succeed.

FDA AI/ML Framework and Good Machine Learning Practice (GMLP)

The FDA has developed a comprehensive framework for regulating AI/ML-based SaMD, recognizing that machine learning introduces unique regulatory challenges — particularly the ability of algorithms to learn and change over time.

The AI/ML Action Plan

The FDA's AI/ML framework has evolved through several key milestones:

• 2019: FDA published the "Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning-Based Software as a Medical Device" discussion paper
• 2021: FDA published the AI/ML SaMD Action Plan, outlining five key areas of focus: (1) a tailored regulatory framework for AI/ML-based SaMD, (2) good machine learning practice, (3) a patient-centered approach incorporating transparency to users, (4) regulatory science methods for algorithm evaluation and real-world performance, and (5) real-world performance monitoring pilots
• 2021: FDA, Health Canada, and MHRA jointly published the Good Machine Learning Practice (GMLP) guiding principles
• 2023: FDA published draft guidance on predetermined change control plans for ML-enabled device software functions
• 2024: FDA finalized PCCP guidance (December), broadening scope from ML-DSF to AI-DSF
• January 2025: FDA published the landmark draft guidance "Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations" — applying a Total Product Lifecycle (TPLC) approach to AI-enabled devices (comment period closed April 7, 2025)
• January 2026: FDA updated CDS and general wellness guidance documents and withdrew its guidance on adoption of IMDRF SaMD clinical evaluation principles, signaling a shift toward a more deregulatory approach to certain digital health technologies
• 2025–2026: FDA continues to refine its approach, with emphasis on real-world performance monitoring, transparency, and bias mitigation

The January 2025 TPLC Draft Guidance

The January 2025 draft guidance on AI-enabled device software functions deserves particular attention because it represents the FDA's most comprehensive articulation of how AI/ML-based SaMD should be managed across its entire lifecycle. Key elements include:

• Total Product Lifecycle (TPLC) approach: The guidance recommends that AI considerations — including data management, model design, bias assessment, and performance monitoring — be incorporated from the earliest stages of device development through decommission, not just at the premarket submission stage
• Transparency requirements: Recommendations for labeling AI-enabled devices to communicate how the AI works, what data it was trained on, known limitations, and subpopulation performance variations
• Bias analysis and mitigation: Explicit recommendations to collect evidence evaluating whether a device benefits all relevant demographic groups, with strategies to address identified disparities
• Marketing submission content: Specific recommendations for what to include in submissions — model description, data lineage and partitioning, performance metrics tied to clinical claims, bias analysis, human-AI workflow description, monitoring plans, and a PCCP if post-market updates are planned
• Post-market monitoring: Expectations for ongoing monitoring of AI model performance in real-world deployment, including detection of data drift and concept drift

FDA AI/ML-Enabled Device Authorization Statistics

As of 2025, the FDA has authorized over 1,000 AI/ML-enabled medical devices, with the pace accelerating rapidly — 258 to 295 devices were authorized in 2025 alone (the most in the agency's history), compared to approximately 170 in 2024. Key statistics:

• Radiology dominates: Approximately 75 to 80 percent of all authorized AI/ML devices are in radiology, reflecting the maturity of computer vision algorithms for medical imaging
• Cardiology accounts for roughly 10 percent of authorizations
• 510(k) is the primary pathway: Approximately 95 percent of AI/ML device authorizations come through the 510(k) pathway, with the remainder through De Novo
• SaMD accounts for approximately 62 percent of all AI/ML device clearances

The FDA maintains a publicly accessible database of all authorized AI/ML-enabled medical devices, updated regularly. This database is an essential resource for SaMD manufacturers conducting predicate searches, competitive analysis, and regulatory strategy development.

Good Machine Learning Practice (GMLP) — 10 Guiding Principles

The FDA, Health Canada, and the UK's MHRA jointly published 10 guiding principles for Good Machine Learning Practice. These are not binding requirements, but they represent regulators' expectations and are increasingly referenced in premarket reviews.

1. Multi-disciplinary expertise throughout the total product lifecycle — clinical experts, data scientists, software engineers, biostatisticians, and regulatory professionals must collaborate.
2. Good software engineering and security practices — IEC 62304 compliance, secure development, and data integrity throughout the ML pipeline.
3. Representative clinical study participants and datasets — training, validation, and test data must reflect the diversity of the intended patient population across age, sex, race, ethnicity, and comorbidities.
4. Training data independence from test sets — data leakage invalidates performance claims.
5. Reference datasets based on best available methods — ground truth labels must use the best available clinical methods with documented limitations.
6. Model design tailored to available data — algorithm complexity appropriate for dataset size; overly complex models on small datasets invite overfitting.
7. Human-AI team performance — evaluate performance in the context of human-AI collaboration, not algorithm performance alone.
8. Clinically relevant testing conditions — validation must reflect real-world variability in data quality, populations, and clinical workflows.
9. Clear, essential information for users — labeling must communicate intended use, performance, limitations, training data characteristics, and known subpopulation performance variations.
10. Post-deployment monitoring and retraining risk management — detect model degradation (data drift, concept drift) and manage retraining risks.

AI/ML-Specific Documentation for FDA Submissions

When submitting an AI/ML-based SaMD to the FDA, the following documentation elements are expected in addition to standard software documentation:

• Algorithm description: Architecture (e.g., convolutional neural network, random forest, transformer), input/output specifications, preprocessing steps, feature engineering
• Training data description: Sources, size, demographic and clinical characteristics, inclusion/exclusion criteria, labeling methodology, inter-annotator agreement
• Data partitioning: How data was split into training, validation, and test sets; methods to ensure independence
• Performance metrics: Appropriate metrics for the clinical use case (sensitivity, specificity, AUC, PPV, NPV, F1 score), with confidence intervals
• Subgroup analysis: Performance across clinically relevant subpopulations (age groups, sex, race/ethnicity, disease severity)
• Failure mode analysis: Known failure modes, edge cases, and conditions under which the algorithm may underperform
• Human factors: How the algorithm's output is presented to users, risk of automation bias, and how the interface supports appropriate clinical decision-making

Cybersecurity Requirements for SaMD

Cybersecurity is not a nice-to-have for SaMD — it is a regulatory requirement. The FDA, EU regulators, and international standards bodies have all established cybersecurity expectations that SaMD manufacturers must meet. The 2023 PATCH Act amendments and subsequent FDA guidance have made cybersecurity a non-negotiable element of premarket submissions.

FDA Premarket Cybersecurity Requirements

The FDA's 2023 final guidance on cybersecurity in medical devices establishes premarket documentation expectations. Section 524B of the FD&C Act (added by the Consolidated Appropriations Act of 2023) makes cybersecurity requirements statutory for "cyber devices" — devices that include software, connect to the internet, and could be vulnerable to cybersecurity threats. Most SaMD products qualify.

Required premarket cybersecurity documentation:

Element	Description
Threat model	Systematic identification of cybersecurity threats, vulnerabilities, and attack vectors relevant to the device and its deployment environment
Security architecture	Description of security controls including authentication, authorization, encryption, data integrity mechanisms, and secure communication protocols
Software Bill of Materials (SBOM)	Machine-readable inventory of all software components (including open-source libraries and third-party components) with version numbers and known vulnerabilities
Security testing	Results of security testing including vulnerability scanning, penetration testing, fuzz testing, and static/dynamic code analysis
Vulnerability management plan	Plan for identifying, assessing, and addressing vulnerabilities throughout the device's lifecycle, including coordinated vulnerability disclosure
Patch management plan	Process for developing, testing, validating, and deploying security patches
End-of-life plan	Plan for managing cybersecurity risks when the manufacturer will no longer support the device

SBOM Requirements

The Software Bill of Materials (SBOM) has become one of the most discussed cybersecurity requirements. The FDA expects a machine-readable SBOM that includes:

• All commercial, open-source, and off-the-shelf software components
• Version numbers for each component
• Known vulnerabilities (mapped to CVE identifiers where applicable)
• Software component dependency relationships

For SaMD, the SBOM extends to the entire software stack — operating system, runtime environment, application frameworks, libraries, AI/ML frameworks (e.g., TensorFlow, PyTorch), and all dependencies. Cloud-hosted SaMD must also address the software components in the cloud infrastructure that are under the manufacturer's control.

Postmarket Cybersecurity

Premarket cybersecurity documentation is only the beginning. SaMD manufacturers must maintain cybersecurity throughout the product lifecycle:

• Continuous monitoring for new vulnerabilities affecting device components
• Timely patching of critical vulnerabilities — the FDA expects manufacturers to address critical vulnerabilities within defined timeframes
• Coordinated vulnerability disclosure process — manufacturers must have a mechanism for receiving and responding to vulnerability reports from security researchers
• Customer communication — timely notification of customers about identified vulnerabilities and available patches
• Integration with post-market surveillance — cybersecurity incidents must be evaluated through the existing adverse event reporting framework (MDR reporting for events involving patient harm)

EU Cybersecurity Requirements

The EU MDR addresses cybersecurity through several mechanisms:

• Annex I General Safety and Performance Requirements (GSPRs): Sections 17.2 and 17.4 specifically address IT security requirements for devices that incorporate electronic programmable systems and software
• IEC 81001-5-1 (Health software and health IT systems safety, effectiveness and security — Security — Activities in the product life cycle): This standard, published in 2021, provides a comprehensive framework for cybersecurity in medical device software and is increasingly referenced by Notified Bodies
• Regulation (EU) 2024/2847 (Cyber Resilience Act): While medical devices are largely exempt from the CRA (as they are covered by the MDR/IVDR), manufacturers should be aware of the broader EU cybersecurity regulatory landscape

Practical tip: Start your SBOM management from day one of development, not when you are assembling your regulatory submission. Retroactively building an SBOM for a mature software product with dozens of dependencies is painful and error-prone. Use automated tools (such as SPDX-compatible SBOM generators integrated into your CI/CD pipeline) to generate and maintain your SBOM continuously.

Clinical Evaluation for SaMD

Clinical evaluation for SaMD follows the same general principles as for other medical devices — you must demonstrate that the device is safe and performs as intended — but the methodology has unique characteristics that reflect the nature of software.

The Three-Layered Clinical Evidence Framework

The IMDRF proposed a three-layered approach to clinical evidence for SaMD, which the FDA and EU regulators have broadly adopted:

Layer	Focus	Activities
Analytical validation	Does the software correctly process input data and generate accurate output?	Verification and validation of algorithms, accuracy testing against reference data, edge case testing, robustness testing
Clinical validation	Does the software's output achieve the intended clinical purpose in the target population?	Clinical studies comparing device output to clinical reference standard, prospective or retrospective studies, performance in real clinical workflows
Clinical evidence generation	Integration of analytical validation, clinical validation, and any relevant clinical experience data	Systematic literature review, compilation of all available evidence, risk-benefit analysis, evaluation of clinical utility

FDA Clinical Evidence Expectations

The FDA's expectations for clinical evidence vary by risk level and novelty:

For 510(k) SaMD with a well-matched predicate:

• Clinical performance data (sensitivity, specificity, etc.) compared to the predicate device's performance
• May leverage existing clinical literature if the predicate's clinical evidence is well-established
• Stand-alone clinical performance testing using an appropriate reference standard

For De Novo SaMD (novel device):

• Prospective or retrospective clinical validation study
• Clinically meaningful endpoints
• Adequate sample size with statistical justification
• Subgroup analysis across relevant demographic and clinical variables
• For AI/ML devices: performance on a held-out test set that is independent of training data

For PMA SaMD:

• Pivotal clinical study, often prospective and multi-center
• Well-defined primary and secondary endpoints
• Pre-specified statistical analysis plan
• Independent data monitoring committee (for higher-risk studies)

EU MDR Clinical Evaluation for SaMD

Under the EU MDR, clinical evaluation is required for all device classes — including Class I. For SaMD, the clinical evaluation must address:

• State-of-the-art analysis: Review of current clinical knowledge and alternative treatments/devices
• Appraisal of pertinent clinical data: Literature review, analysis of clinical experience data, and results of clinical investigations
• Demonstration of conformity with relevant General Safety and Performance Requirements (GSPRs)
• Benefit-risk analysis: Quantitative and qualitative assessment
• Post-market clinical follow-up (PMCF) plan: Required for all classes; scope depends on risk level

The MDCG 2020-1 guidance provides specific recommendations for clinical evaluation of SaMD, including how to handle the unique aspects of software validation (algorithm validation, data representativeness, and real-world performance monitoring).

Practical tip: For AI/ML SaMD, one of the most common FDA review questions concerns the representativeness of your clinical validation data. If your test dataset does not reflect the diversity of the US patient population — including underrepresented demographic groups — expect questions. Design your clinical validation study with demographic diversity as a primary consideration, not an afterthought.

QMS Considerations for SaMD

SaMD manufacturers must maintain a quality management system (QMS) that meets regulatory requirements. For the US market, this means compliance with 21 CFR Part 820 (the Quality System Regulation, transitioning to the QMSR aligned with ISO 13485 starting in 2026). For the EU market, ISO 13485 is the recognized standard.

Key QMS Elements for SaMD

QMS Element	SaMD-Specific Considerations
Design controls	IEC 62304 lifecycle integrated into design controls; software requirements, architecture, and design documentation; traceability from user needs through verification and validation
Risk management	ISO 14971 applied to software; risk analysis for algorithm failure modes, data quality risks, cybersecurity threats, and human factors risks
Document control	Version control for source code, documentation, and trained models; configuration management per IEC 62304
Purchasing controls	Management of third-party components (SOUP/OTS), cloud service providers, training data sources
CAPA	Corrective and preventive action for software defects, algorithm performance degradation, cybersecurity vulnerabilities
Complaint handling	Software-specific complaint categories (crashes, incorrect outputs, performance degradation); integration with bug tracking systems
Production and process controls	Software build and release processes; CI/CD pipeline validation; deployment procedures; rollback capabilities
Labeling	Electronic labeling requirements; app store descriptions as labeling; instructions for use including algorithm limitations and intended use environment

The QMSR Transition

The FDA finalized the Quality Management System Regulation (QMSR) in 2024, aligning US QMS requirements with ISO 13485:2016. The compliance date is February 2, 2026. For SaMD manufacturers already certified to ISO 13485, the transition is relatively straightforward. For those that built their QMS exclusively around 21 CFR Part 820, more work is required around management review, competence requirements, and documentation structure.

Cloud-Hosted SaMD and QMS

Many SaMD products run on cloud infrastructure (AWS, Azure, GCP), introducing QMS considerations that traditional manufacturers may not have encountered:

• Infrastructure qualification: The cloud environment must be validated, including compute, storage, networking, and security configurations
• Supplier management: Cloud service providers are suppliers under your QMS — requiring agreements, SLAs, and ongoing monitoring
• Deployment and release: CI/CD pipelines must be validated and controlled under your QMS
• Data integrity: Procedures for backup, disaster recovery, and multi-tenancy data isolation

Practical tip: Do not treat cloud infrastructure as outside the QMS boundary. FDA investigators have increasingly scrutinized cloud deployment practices during inspections. Your CI/CD pipeline and deployment procedures should be documented and controlled under your QMS.

Real-World Examples of SaMD Products and Their Regulatory Paths

Examining how specific SaMD products have navigated the regulatory landscape provides practical insight that theory alone cannot offer. The following examples span different clinical domains, risk levels, and regulatory pathways.

IDx-DR (LumineticsCore) — Autonomous AI for Diabetic Retinopathy

The first FDA-authorized autonomous AI diagnostic system (De Novo, DEN180001, April 2018). It autonomously analyzes fundus images to detect more-than-mild diabetic retinopathy without clinician interpretation. The De Novo created product code QMTr and established special controls for autonomous AI diagnostics. Clinical evidence came from a prospective, multicenter trial across 10 primary care sites with 900 participants, demonstrating 87.2% sensitivity and 90.7% specificity versus independent ophthalmologist reading.

Viz LVO — AI Stroke Triage

AI software that analyzes CT angiography to detect suspected large vessel occlusion strokes and alerts neurointerventional specialists (De Novo, DEN170073, February 2018). The "triage" intended use — flagging findings for prioritized expert review rather than making a diagnosis — influenced the classification. The De Novo created product code QAS, which has since served as a predicate for multiple 510(k) clearances of competing AI triage products.

Apple Watch ECG App — Consumer SaMD

The ECG app on the Apple Watch classifies heart rhythm as atrial fibrillation, sinus rhythm, or inconclusive (De Novo, DEN180044, September 2018). This demonstrated that consumer wearables can include SaMD functions — the ECG app is SaMD while the Watch hardware is a general-purpose consumer device. CE marked under the EU MDR as Class IIa.

Aidoc — AI Radiology Triage Platform

A suite of AI algorithms analyzing CT scans for critical findings (pulmonary embolism, intracranial hemorrhage, cervical spine fractures) with multiple FDA 510(k) clearances referencing De Novo-created product codes. Demonstrates the "platform" approach — a single software platform hosting multiple independently cleared algorithms, expanding clinical capabilities incrementally.

Paige Prostate — AI for Pathology

Product: AI software that analyzes digitized prostate biopsy images to identify areas suspicious for cancer, assisting pathologists in diagnosis.

Regulatory pathway: FDA De Novo (authorized September 2021, DEN200080)

Significance: This was the first AI-based pathology product to receive FDA authorization. Unlike radiology AI (which analyzes images from standardized imaging devices), pathology AI must handle enormous variability in tissue preparation, staining, and scanning — making the clinical validation particularly challenging. The De Novo created a new product code for AI-assisted pathology software.

Aidoc CARE1 Foundation Model — First Foundation Model in Clinical AI

Product: A foundation-model-powered clinical AI system for radiology triage and detection.

Regulatory pathway: FDA 510(k) clearance (February 2025)

Significance: CARE1 is notable as the first foundation-model-powered clinical AI to receive FDA clearance. Foundation models — large-scale AI models trained on broad datasets that can be adapted for multiple tasks — represent the next generation of clinical AI. The regulatory pathway (510(k) rather than De Novo) was possible because Aidoc referenced existing predicate devices from its earlier triage clearances.

Prenosis ImmunoScore — AI for Sepsis Diagnosis

Product: An AI-powered diagnostic tool for sepsis that analyzes routinely collected electronic health record data (laboratory values, vital signs, demographics) to assess sepsis probability.

Regulatory pathway: FDA De Novo (authorized April 2024)

Significance: ImmunoScore is notable because it does not analyze medical images — it applies AI to structured clinical data from EHR systems. This represents a different class of SaMD from the radiology and cardiology AI products that dominate the FDA's AI/ML device database, demonstrating that the regulatory framework applies equally to AI that processes clinical data beyond imaging.

Summary of SaMD Regulatory Path Examples

Product	Clinical Domain	FDA Pathway	FDA Class	EU MDR Class	AI/ML?
LumineticsCore (IDx-DR)	Ophthalmology	De Novo	Class II	Class IIb	Yes
Viz LVO	Neurology / Stroke	De Novo	Class II	Class IIb	Yes
Apple Watch ECG	Cardiology	De Novo	Class II	Class IIa	Yes
Aidoc Triage Suite	Radiology	510(k) (multiple)	Class II	Class IIa/IIb	Yes
Tempus ECG Analysis Platform	Cardiology	510(k)	Class II	Class IIa	Yes
Paige Prostate	Pathology	De Novo	Class II	Class IIb	Yes
Aidoc CARE1	Radiology	510(k)	Class II	—	Yes (foundation model)
Prenosis ImmunoScore	Critical Care (Sepsis)	De Novo	Class II	—	Yes

International SaMD Regulation Comparison

SaMD regulation varies significantly across jurisdictions. While the IMDRF framework provides a common vocabulary, individual regulators have implemented SaMD requirements differently. Understanding these differences is essential for manufacturers pursuing global market access.

Aspect	FDA (US)	EU MDR (Europe)	Health Canada	PMDA (Japan)	TGA (Australia)
SaMD definition	Aligns with IMDRF; codified through guidance documents and 21st Century Cures Act exclusions	MDR Article 2(1) — software with medical intended purpose qualifies as device	Aligns with IMDRF; SaMD guidance published 2019	Aligns with IMDRF; SaMD classified under PMDA device categories	Aligns with IMDRF; SaMD regulatory framework published 2021
Classification framework	Risk-based (Class I, II, III); product code system; some SaMD exempt	Rule 11 (Annex VIII); four classes (I, IIa, IIb, III) based on decision severity	Risk-based (Class I–IV); aligns with IMDRF categories	Risk-based (Class I–IV, corresponding to IMDRF categories)	Risk-based; aligns with IMDRF; ARTG inclusion
Pre-market pathway	510(k), De Novo, PMA; PCCP for planned changes	Conformity assessment via Notified Body (Class IIa+); self-declaration (Class I)	Medical Device License (Class II–IV); Class I: establishment license	Premarket certification (Class III/IV), premarket notification (Class II), self-declaration (Class I)	Inclusion in ARTG; conformity assessment varies by class
AI/ML-specific guidance	Comprehensive: AI/ML Action Plan, GMLP, PCCP framework	MDCG guidance on AI; no separate AI regulation (AI Act may interact)	GMLP co-authored with FDA/MHRA; guidance on AI/ML devices	PMDA AMED-guided approach; LEAP review designation for AI	TGA guidance on SaMD including AI/ML; regulatory sandbox
Cybersecurity	Mandatory (Section 524B FD&C Act); SBOM required; premarket and postmarket	GSPRs Annex I; IEC 81001-5-1 referenced; Cyber Resilience Act context	Premarket cybersecurity guidance; SBOM expected	Cybersecurity guidance for medical devices	Cybersecurity guidance aligned with IMDRF
Clinical evidence	Varies by pathway; GMLP principles; subgroup analysis expected	Clinical evaluation per Article 61 and Annex XIV for all classes	Clinical evidence proportional to risk	Clinical evaluation requirements per class	Clinical evidence proportional to risk; may accept international data
Change management	PCCP framework; traditional 510(k)/PMA supplement for non-PCCP changes	Significant changes require Notified Body review; ongoing conformity assessment	Change notification framework; significant change guidance	Re-certification for significant changes	Change notification requirements

Convergence and Divergence

Global convergence is increasing — the IMDRF framework, GMLP principles, and IEC 62304 provide a common foundation recognized across most markets. But significant differences remain:

• Classification outcomes differ. A SaMD product that is Class II in the US may be Class IIb or III under EU MDR Rule 11. You must classify independently in each jurisdiction.
• Clinical evidence expectations vary. The FDA may accept a retrospective study for a 510(k), while the EU MDR may require additional clinical evaluation and PMCF commitments at a higher classification.
• Change management approaches differ. The FDA's PCCP framework has no direct EU MDR equivalent, where significant changes require Notified Body review regardless.
• Timelines and costs vary dramatically. A US De Novo may take 6 to 12 months; CE marking for the same product at Class IIb or III may take 12 to 24 months due to Notified Body capacity constraints.

Practical tip: For multi-market launches, design your clinical validation and quality system to meet the most demanding jurisdiction first. Retrofitting for a second market is far more expensive than planning for both from the start.

United Kingdom — MHRA SaMD and AIaMD Framework

Post-Brexit, the UK has been developing its own independent regulatory framework for SaMD and AI as a Medical Device (AIaMD) through the MHRA. The UK regulatory landscape is in a period of significant transition, and SaMD manufacturers targeting the UK market need to understand both the current requirements and the forthcoming changes.

Current state: SaMD in the UK is currently regulated under the Medical Devices Regulations 2002 (UK MDR 2002), which carried over the EU MDD framework at Brexit. UKCA marking is required for the Great Britain market, while CE marking remains valid in Northern Ireland. However, the UK has extended the validity of CE marking for Great Britain multiple times, and most SaMD products continue to enter the market under CE marks.

The SaMD and AIaMD Change Programme: The MHRA has established a dedicated change programme for Software and AI as a Medical Device, organized into two streams and eleven work packages:

• Stream 1 (SaMD Lifecycle) covers qualification (WP1), classification (WP2), premarket requirements (WP3), post-market surveillance (WP4), and cybersecurity (WP5)
• Stream 2 (AIaMD-Specific) covers AI rigour (WP9), interpretability — known as "Project Glass Box" (WP10), and adaptivity — known as "Project Ship of Theseus" (WP11)

Key regulatory developments and timeline:

• February 2025: MHRA updated its guidance on Software and AI as a Medical Device, including new guidance on Digital Mental Health Technology (DMHT) qualification and classification
• June 2025: New post-market surveillance regulations came into force, applying to both CE and UKCA-marked devices
• 2025: MHRA published guidance on AI deployment, cybersecurity for SaMD, and collaborated formally with the FDA on shared standards for evaluating AI-based devices
• 2026: Pre-market regulation changes — including up-classification of SaMD, UDI mandates, and international recognition frameworks — are expected to be implemented

Classification changes: When the new UK rules take effect, most SaMD will be classified as Class IIa or higher, aligning the UK with the IMDRF risk categorization and the EU MDR classification approach. This is a significant change from the current regime, where many SaMD products remain Class I.

AI-specific initiatives: The MHRA has been particularly active in AI governance:

• Co-authored the 10 GMLP guiding principles with the FDA and Health Canada
• Published 5 guiding principles for Predetermined Change Control Plans for ML-enabled devices
• Published transparency principles on explainability and interpretability of ML-enabled devices
• Developed a methodology (with Brunel University) for determining "significant change" in adaptive AI algorithms
• Established the "AIaMD for all" bias mitigation framework addressing performance across populations

The "airlock" concept: The MHRA has explored a regulatory sandbox mechanism — termed the "airlock process" — that would allow innovative SaMD products meeting unmet clinical needs to enter the market under heightened monitoring, with clear entry and exit criteria. This is conceptually similar to the FDA's TEMPO pilot, though the implementation details differ.

Practical tip: If you plan to market SaMD in the UK, engage with the MHRA early. The regulatory framework is actively evolving, and requirements that apply in 2026 may differ significantly from those in effect today. Monitor the MHRA's SaMD and AIaMD Change Programme roadmap for updates on implementation timelines.

Canada — Health Canada SaMD and MLMD Framework

Health Canada has emerged as a leading voice in international SaMD regulation, particularly for AI/ML-enabled devices. Its approach combines IMDRF alignment with distinctive Canadian requirements.

Classification and licensing: Health Canada classifies medical devices into four classes (I through IV) aligned with the IMDRF framework. SaMD follows the same classification scheme. Class II through IV devices require a Medical Device License (MDL), while Class I devices require only an establishment license.

February 2025 Pre-Market Guidance for Machine Learning-Enabled Medical Devices (MLMDs): This guidance — Health Canada's most comprehensive statement on AI/ML device regulation — outlines the information manufacturers should provide to demonstrate safety and effectiveness of MLMDs. Key elements include:

• PCCP adoption: Health Canada's guidance introduces its own Predetermined Change Control Plan mechanism, allowing pre-authorization of planned changes to ML systems without requiring full license amendments for every update. This aligns Health Canada with the FDA's PCCP framework, though the specific requirements differ
• GMLP integration: The guidance explicitly requires manufacturers to describe how they have considered and implemented Good Machine Learning Practice throughout the product lifecycle — making GMLP compliance a substantive expectation, not merely aspirational
• Sex and Gender-Based Analysis Plus (SGBA Plus): Health Canada uniquely requires integration of SGBA Plus into risk assessments for MLMDs, ensuring that AI/ML devices are evaluated for equitable performance across sex, gender, age, race, ethnicity, disability, and other identity factors. This is more prescriptive than the FDA's recommendations on subgroup analysis and represents a distinctive Canadian regulatory requirement
• Submission requirements: Manufacturers must clearly state in their cover letter that the device uses ML (for Class II, III, and IV applications) and, if applicable, that the device includes a PCCP

International collaboration: Health Canada co-authored the GMLP guiding principles with the FDA and MHRA, and has been an active participant in IMDRF working groups on SaMD and AI/ML. Health Canada's approach tends to be closely aligned with the FDA's on substance, while maintaining its own procedural and legal framework.

Practical tip: Health Canada's SGBA Plus requirement for ML-enabled devices is unique among major regulators. If you are developing AI/ML-based SaMD for the Canadian market, build equity analysis into your clinical validation from the start. Ensure your training and validation datasets include sufficient representation across the identity factors that SGBA Plus addresses, and document your analysis explicitly.

Japan — PMDA SaMD Framework

Japan's Pharmaceuticals and Medical Devices Agency (PMDA) has been actively developing a supportive regulatory environment for SaMD, with several innovative programs designed to accelerate access to software-based medical devices.

Classification and approval: Japan classifies medical devices into four classes (I through IV), broadly aligned with the IMDRF categories. SaMD follows the same classification framework. Class III and IV devices require premarket certification (Shonin), Class II devices require premarket notification (Todokede), and Class I devices require self-declaration.

DASH for SaMD (Digital Transformation Action Strategies in Healthcare): Japan launched DASH for SaMD as a national strategy to support the development and implementation of innovative software-based medical devices. DASH for SaMD encompasses regulatory streamlining, reimbursement pathways, and innovation support — a whole-of-government approach that goes beyond regulatory requirements alone.

IDATEN System (Immediate Deployment and Acceleration of Technologies for the Nation): The IDATEN system is Japan's equivalent of the FDA's PCCP framework. It allows manufacturers to submit pre-approved improvement plans for AI-based SaMD, eliminating the need for regulatory re-approval with each update. This is particularly important for adaptive AI that continuously learns from real-world data.

Two-step approval mechanism: Implemented in 2024, this mechanism classifies SaMD into two categories — SaMD for disease diagnosis and SaMD for disease treatment — and provides specific examples of devices subject to the two-step approval scheme. The two-step approach allows initial authorization based on available evidence, followed by additional data collection and confirmation during a defined post-market period.

PMDA organizational changes: The PMDA's mid-term plan (JFY 2024 to JFY 2028) introduced a target review timeframe of 6 months for SaMD products undergoing priority review and committed to restructuring PMDA's organization to include a department dedicated to SaMD review — a significant institutional investment in SaMD regulatory capacity.

Market statistics: Over 20 AI-powered medical devices have been approved by Japan's Ministry of Health, Labour and Welfare (MHLW), with the majority focused on image analysis applications.

Practical tip: Japan's IDATEN system for pre-approved AI improvement plans and the two-step approval mechanism make it one of the more progressive markets for adaptive AI-based SaMD. If your product involves continuous learning or frequent model updates, Japan's framework may offer a more streamlined path than some other jurisdictions. Engage the PMDA early — they offer consultation services and have demonstrated openness to novel SaMD regulatory approaches.

Australia — TGA SaMD Framework

The Therapeutic Goods Administration (TGA) has developed a comprehensive framework for regulating SaMD that closely aligns with both the IMDRF framework and the EU MDR, while incorporating Australia-specific elements.

Classification: Australia adopted new SaMD classification rules effective February 25, 2021, aligning closely with the EU MDR classification approach. Software that was previously unclassified or low-class may now be classified higher under these rules, mirroring the impact of the EU MDR Rule 11 up-classification.

ARTG inclusion: SaMD must be included in the Australian Register of Therapeutic Goods (ARTG) before it can be supplied in Australia. The conformity assessment pathway depends on the device's classification, with higher-risk devices requiring more rigorous assessment.

August 2025 SaMD guidance: The TGA published comprehensive guidance in August 2025 clarifying the regulatory framework for SaMD, with a strong focus on AI and adaptive algorithms. Key elements include:

• Technology-agnostic, risk-based approach: Regulation is not tied to specific technologies or AI types, but to the risks posed by the device throughout its lifecycle
• Intended purpose as the decisive factor: The TGA confirms that intended purpose — not technology — determines whether software qualifies as a medical device and how it is classified
• Documentation, validation, and cybersecurity requirements: Aligned with international standards (IEC 62304, ISO 14971) and increasingly with EU MDR expectations
• International alignment: The TGA actively monitors and aligns with the EU AI Act, FDA approaches, and IMDRF developments

International reliance: The TGA has been expanding its pre-market reliance pathways, recognizing comparable overseas regulators including the EU, Canada, Japan, the US, Singapore, and Brazil. For SaMD manufacturers with existing authorizations in these jurisdictions, the TGA may rely on regulatory assessment and clinical evaluation evidence from comparable overseas regulators, potentially reducing the burden of the Australian marketing authorization process.

Practical tip: If you have already obtained FDA clearance or CE marking for your SaMD product, explore the TGA's international reliance pathways. Leveraging existing regulatory work from comparable overseas regulators can significantly reduce the time and cost of entering the Australian market.

IMDRF Developments: N88 and N81

At the international level, the IMDRF continues to drive SaMD regulatory harmonization. In January 2025, the IMDRF finalized two documents directly relevant to AI/ML-based SaMD:

• N88: Finalized the 10 Good Machine Learning Practice principles for AI/ML devices, aligning with the guiding principles previously published jointly by the FDA, Health Canada, and MHRA
• N81: Published characterization considerations for medical device software and software-specific risk, providing a harmonized framework for how regulators should evaluate software-related risks

These IMDRF documents do not have direct regulatory force, but they are adopted — in whole or in part — by member regulatory authorities. Demonstrating alignment with IMDRF N88 and N81 in your regulatory submissions is increasingly expected across jurisdictions.

Common Pitfalls in SaMD Development and Regulation

The following mistakes are drawn from real regulatory submissions, FDA warning letters, Notified Body audit findings, and industry experience.

1. Misclassifying Your Software

The most consequential mistake. Companies frequently underclassify their SaMD — misapplying Rule 11 in the EU, incorrectly assuming their software qualifies for the Cures Act CDS exclusion, or conflating IMDRF categories with FDA or EU classifications. Avoid it: Engage regulatory expertise experienced in SaMD before finalizing classification. Document your rationale. If ambiguous, seek a Pre-Submission meeting with the FDA or consult your Notified Body.

2. Treating Regulatory as an Afterthought

Software companies often build first and think about regulation later. By then, the architecture does not support IEC 62304 documentation, the AI training data lacks regulatory-grade provenance, and the quality system is nonexistent. Avoid it: Integrate regulatory planning from day one. Hire regulatory expertise before you write the first line of code.

3. Insufficient Clinical Evidence

Common problems: validation datasets too small, lack of demographic diversity, data leakage between training and test sets, and missing subgroup analysis. Avoid it: Plan your clinical validation with the same rigor as a drug trial. Define endpoints, sample size, demographics, and statistical methods before collecting data.

4. Ignoring Cybersecurity Until Submission

The SBOM requirement alone can derail a timeline if components have not been tracked throughout development. Retroactively building threat models and security documentation is time-consuming and often reveals architectural gaps. Avoid it: Implement cybersecurity practices from day one. Use automated SBOM generators in your CI/CD pipeline. Conduct threat modeling during design.

5. Inadequate Post-Market Surveillance

AI/ML models can degrade over time as patient populations or clinical practices change (data drift, concept drift). Cloud-hosted SaMD can be monitored in real time — and regulators increasingly expect that it is. Avoid it: Include real-world performance monitoring, algorithm tracking, and cybersecurity monitoring in your PMS plan.

6. Poorly Defined Intended Use

Intended use statements that are too broad invite higher classification; too narrow limits commercial utility. The intended use drives classification, pathway, and clinical evidence scope. Avoid it: Draft your intended use early. Iterate with regulatory, clinical, and commercial input. Test against classification rules in every target jurisdiction.

7. Not Planning for Change

If your strategy does not account for post-market modifications — software updates, algorithm improvements, bug fixes — you will be perpetually reactive, filing new submissions on a cadence that overwhelms your team. Avoid it: Develop a PCCP strategy for FDA products and a change management framework. Build your architecture to support modular updates.

8. Underestimating Notified Body Timelines

Notified Body capacity for SaMD reviews has been constrained since the MDR transition began. Lead times for initial certification can be 12 to 24 months. Avoid it: Engage your Notified Body during development, not after. Build their timelines into your launch plan.

9. Confusing Regulatory Clearance with Clinical Adoption

Clearance is necessary for market access but not sufficient for clinical adoption. Clinicians need trust, evidence of improved outcomes, and workflow integration. Avoid it: Invest in clinical utility evidence. Engage key opinion leaders. Publish peer-reviewed studies. Design for clinician workflows.

10. Neglecting Human Factors

How information is displayed, how alerts are prioritized, and how the software integrates with existing systems all affect safety. Automation bias is a real risk for AI/ML SaMD. Avoid it: Conduct formative and summative human factors studies per IEC 62366-1. Address automation bias in risk management.

Conclusion

SaMD regulation is evolving rapidly as regulators adapt frameworks designed for physical devices to accommodate software that can learn, change, and deploy globally in seconds. The fundamentals — risk-based classification, clinical evidence, quality management, and post-market surveillance — remain constant, but how they apply to software continues to develop.

The manufacturers that succeed treat regulatory as a design input from the beginning: hiring regulatory expertise early, building software architecture to support IEC 62304 documentation and cybersecurity requirements from the first commit, designing clinical validation with the rigor of a pharmaceutical pivotal trial, and planning for continuous improvement and monitoring throughout the product lifecycle.

The frameworks described in this guide — IMDRF classification, FDA pathways, EU MDR Rule 11, IEC 62304, PCCP, GMLP, and cybersecurity requirements — are not independent silos. They are interconnected elements of a single regulatory reality. Understanding how they fit together is what separates SaMD manufacturers that reach the market efficiently from those that spend years learning the same lessons the hard way.