Software as Medical Device (SaMD) Classification: FDA Risk Framework

Software as Medical Device (SaMD) Classification: FDA Risk Framework

Key Takeaways

The Device Definition Applied to Software

Whether software qualifies as a medical device depends on Section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act). Under this definition, a medical device is "an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article" that is intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease, or intended to affect the structure or function of the body.

Software meets this definition when its intended use falls within these purposes. A mobile application that analyzes electrocardiogram data to detect atrial fibrillation is a medical device. A mobile application that stores patient contact information is not.

The critical factor is intended use. Identical software functionality can be a device or a non-device depending on the manufacturer's intended use statements, marketing claims, and labeling. FDA evaluates intended use based on the totality of evidence, including marketing materials, user documentation, and statements made to investors or in press releases.

SaMD vs SiMD: The Core Distinction

The IMDRF SaMD Working Group established the distinction between SaMD and SiMD in the "Software as a Medical Device: Key Definitions" document (IMDRF/SaMD WG/N10FINAL:2013):

Software as a Medical Device (SaMD): Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. SaMD can run on general-purpose computing platforms including smartphones, tablets, cloud servers, and desktop computers.

Software in a Medical Device (SiMD): Software that is integral to a hardware medical device. SiMD cannot function independently of the hardware device it is designed to operate with. It is regulated as a component of the parent device, not as a standalone device.

Practical Examples

Why the Distinction Matters

The SaMD/SiMD distinction determines the regulatory approach:

• SaMD is classified and regulated as a standalone device. It has its own product code, classification, and premarket submission.
• SiMD is regulated as part of the parent hardware device. Its risks and performance are evaluated within the parent device's premarket submission.

A software function that starts as SiMD can become SaMD if the manufacturer separates it from the hardware and markets it as a standalone product. This change triggers a new classification and potentially a new premarket submission.

Software Functions Excluded from Device Regulation

The 21st Century Cures Act (Public Law 114-255, Section 3060, December 2016) amended Section 520(o) of the FD&C Act to exclude specific software functions from the definition of a medical device. These exclusions apply regardless of the platform the software runs on.

Category 1: Administrative Support

Software intended for administrative support of a healthcare facility, including:

• Patient scheduling
• Billing and claims processing
• Inventory management
• Staff scheduling

Category 2: Healthy Lifestyle

Software intended for maintaining or encouraging a healthy lifestyle, unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition. Examples include general fitness trackers, calorie counters, and wellness apps that do not make medical claims.

Category 3: Electronic Patient Records

Software that acts as electronic patient records, provided the software is not intended to interpret or analyze clinical laboratory test or other device data. An EHR system that stores lab values is excluded. An EHR system that flags abnormal lab values based on clinical rules may not be excluded, depending on the nature of the analysis.

Category 4: Data Transfer, Storage, Conversion, Display

Software intended for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, without interpreting or analyzing the data. A PACS viewer that displays DICOM images is excluded. A PACS viewer that uses AI to highlight suspicious regions in images is not excluded.

Category 5: Clinical Decision Support (CDS)

Software that meets all four of the following criteria is excluded from device regulation:

1. Not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system
2. Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information
3. Intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition
4. Intended for the purpose of enabling the healthcare professional to independently review the basis for the recommendation so that it is not the intent that the professional rely primarily on the recommendation

All four criteria must be met. Failure to satisfy any single criterion means the software does not qualify for the CDS exclusion and may be regulated as a medical device.

Category 6: Five Additional Categories

The Cures Act also excludes software for:

• Certain lab information systems
• Communication tools (secure messaging between providers)
• Hardware device communication protocol conversion

FDA's guidance on clinical decision support software (January 2026) and "Policy for Device Software Functions and Mobile Medical Applications" (updated September 2022) provide detailed interpretation of these exclusions.

The IMDRF Risk Categorization Framework in Detail

The IMDRF published "Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations" (IMDRF/SaMD WG/N12FINAL:2014). This framework uses a 3x3 matrix to assign SaMD to one of four risk categories (I through IV).

Dimension 1: State of Healthcare Situation or Condition

This dimension evaluates the clinical context in which the SaMD output will be used:

Critical: Situations involving conditions that are life-threatening, require major therapeutic interventions, or where the time to act is critical. Incorrect SaMD output in a critical situation could directly lead to death or irreversible injury. Examples include acute stroke, myocardial infarction, and sepsis.

Serious: Situations involving conditions that are significant and require medical intervention, but are not immediately life-threatening. Incorrect SaMD output in a serious situation could lead to significant harm but would not typically be immediately fatal. Examples include cancer staging, chronic disease management, and surgical planning.

Non-Serious: Situations involving conditions that are minor, self-limiting, or where incorrect SaMD output is unlikely to cause significant harm. Examples include common cold symptom tracking, skin rash identification for non-malignant conditions, and general health monitoring.

Dimension 2: Significance of Information Provided

This dimension evaluates the role of SaMD output in the clinical decision:

Treat or Diagnose: The SaMD output is the sole or primary basis for a treatment or diagnostic action. The healthcare professional or patient acts directly on the SaMD output. Examples: autonomous diagnostic (AI reads mammogram and provides diagnosis without radiologist review), software-directed treatment (algorithm adjusts insulin dose automatically).

Drive Clinical Management: The SaMD output is used as a significant factor in clinical management decisions but is considered alongside other information. The healthcare professional uses the SaMD output to guide but not determine the clinical decision. Examples: risk prediction tool that recommends further testing, AI-flagged finding that prompts radiologist review.

Inform Clinical Management: The SaMD output provides information that a healthcare professional considers as one of many inputs to a clinical decision. The SaMD output is additive rather than directive. Examples: population-level disease prevalence dashboard, clinical literature summary tool.

The Risk Matrix Applied

Category Characteristics

Category I (Lowest Risk):

• Incorrect output unlikely to cause significant harm
• Broad oversight, minimal premarket review
• Examples: wellness apps with low-risk clinical features, general health information displays

Category II:

• Incorrect output could cause non-serious harm or could delay appropriate care in serious situations
• Moderate oversight, standard premarket review
• Examples: clinical decision support for non-critical conditions, triage suggestions for non-urgent situations

Category III:

• Incorrect output could cause serious harm or affect clinical decisions in critical situations
• Significant oversight, rigorous premarket review
• Examples: AI-based cancer detection that drives further diagnostic workup, disease progression prediction driving treatment selection

Category IV (Highest Risk):

• Incorrect output could directly lead to death or irreversible injury
• Highest level of oversight, most rigorous premarket review
• Examples: autonomous diagnostic systems in critical care, AI-directed treatment decisions in life-threatening conditions

FDA Classification Process for SaMD

Step 1: Determine if the Software Is a Device

Apply Section 201(h) of the FD&C Act and evaluate against the Section 520(o) exclusions. This analysis should be documented and should address:

• The software's intended use as stated in labeling and marketing materials
• Whether the software meets any Cures Act exclusion criteria
• Whether the software function fits the IMDRF SaMD definition

Step 2: Identify Existing Classifications

Search the following FDA databases for existing SaMD classifications that match the intended use:

1. FDA Product Classification Database: Search by device name, product code, or description
2. 510(k) Database: Search for cleared predicates with similar intended use
3. De Novo Database: Review granted De Novo requests for similar SaMD products
4. PMA Database: Check for approved PMAs in the same product category

FDA has established numerous software-related product classifications, but sponsors should confirm the relevant classification through FDA's public classification and marketing submission databases for the specific intended use at issue.

Step 3: Apply the Classification Factors

If no existing classification matches, classify the SaMD using the statutory framework under Section 513 of the FD&C Act:

• Class I (General Controls): Sufficient to provide reasonable assurance of safety and effectiveness
• Class II (Special Controls): General controls alone insufficient; special controls (guidance documents, performance standards, post-market surveillance) are necessary
• Class III (Premarket Approval): Class I or II controls insufficient; requires premarket approval demonstrating safety and effectiveness

Classification Examples by Clinical Domain

Digital Health Center of Excellence

FDA established the Digital Health Center of Excellence (DHCoE) within CDRH in September 2020 to provide centralized expertise and coordination for digital health regulatory activities. DHCoE is organized into three focus areas:

1. Policy and Guidance

DHCoE leads the development of guidance documents related to SaMD, AI/ML devices, digital health technologies, and cybersecurity. Key guidance documents developed or coordinated through DHCoE include:

• Content of Premarket Submissions for Device Software Functions (2023)
• Marketing Submission Recommendations for a PCCP for AI/ML-Enabled Device Software Functions (2023)
• Cybersecurity in Medical Devices (2023)
• Clinical Decision Support Software (2022)
• Digital Health Technologies for Remote Data Acquisition in Clinical Investigations (2024)

2. Pre-Submission and Review Support

DHCoE staff participate in Pre-Submission meetings and premarket reviews for digital health products, providing subject matter expertise on software-specific issues including:

• Algorithm performance evaluation
• Software lifecycle documentation
• Cybersecurity risk assessment
• AI/ML-specific considerations (training data, bias, drift)
• Predetermined Change Control Plans

3. International Harmonization

DHCoE coordinates FDA's participation in international SaMD harmonization efforts, including:

• IMDRF SaMD Working Group
• Good Machine Learning Practice (GMLP) principles (jointly with Health Canada and MHRA, published October 2021)
• Bilateral engagements with EU MDR implementation bodies, PMDA (Japan), and TGA (Australia)

Common Classification Mistakes

Mistake 1: Assuming Software Is Not a Device

Manufacturers sometimes assume that software running on a smartphone or web browser is not regulated as a medical device. The platform is irrelevant. If the software meets the device definition under Section 201(h) and does not qualify for a Cures Act exclusion, it is a medical device regardless of the platform.

Mistake 2: Conflating SaMD and SiMD Regulation

Treating SaMD as if it were SiMD (or vice versa) leads to incorrect regulatory strategies. SaMD requires its own classification and premarket submission. Bundling SaMD into a hardware device's submission when the software functions independently can cause regulatory issues.

Mistake 3: Misapplying the CDS Exclusion

The four Cures Act CDS criteria are conjunctive (all four must be met). Many manufacturers focus on criteria 3 and 4 while overlooking criterion 1. If the software processes a medical image or an IVD signal, it fails criterion 1 and cannot qualify for the CDS exclusion, regardless of whether it meets the other three criteria.

Mistake 4: Using IMDRF Categories as FDA Classifications

The IMDRF risk categories (I-IV) are not FDA device classifications (Class I, II, III). The IMDRF framework informs FDA's risk assessment but does not determine classification. An IMDRF Category II SaMD might be FDA Class I (exempt) or Class II depending on the specific intended use and existing classifications.

Mistake 5: Ignoring Post-Market Obligations

SaMD is subject to the same post-market requirements as hardware devices, including:

• Medical Device Reporting (MDR) under 21 CFR Part 803
• Corrections and removals under 21 CFR Part 806
• Quality System Regulation under 21 CFR Part 820
• Registration and listing under 21 CFR Part 807

Software patches, updates, and algorithm retraining may trigger additional premarket submission requirements unless covered by an authorized PCCP.

Key Regulatory References

References