SaMD Classification FDA: Class I, II or III?

Software that treats or diagnoses a critical condition sits at the top of the IMDRF risk scale, whether it runs in an EHR, in the cloud, or on a phone. That fact shapes SaMD classification FDA decisions from the first intended use draft. This article works through device status, exclusions, IMDRF categories, FDA classes, and a hypothetical sepsis example.

What Makes Software a Medical Device

FDA classifies software by intended use and medical purpose, not by platform. The FDA Software as a Medical Device page describes a risk based approach that does not depend solely on whether software runs on a computer, phone, or cloud platform. Under the IMDRF definition, SaMD is software intended for a medical purpose that performs that purpose without being part of a hardware device.

Section 201(h) of the Federal Food, Drug, and Cosmetic Act supplies the statutory device definition. Functions aimed at diagnosis, cure, mitigation, treatment, or prevention of disease can bring software into device scope. FDA guidance explains the agency's current thinking, while IMDRF documents provide shared terminology rather than binding U.S. law.

Assess each function separately. A scheduling module with no medical purpose can sit outside scope while a triage module in the same codebase sits inside it. Teams scoping this boundary often need engineering and regulatory work to run together, which is the focus of our healthcare AI and integration work.

Write the intended use statement before you fix the architecture or evidence plan. That statement should name the user, condition, use environment, and decision the output supports.

This article is general information, not legal or regulatory advice.

Clinical Decision Support and Wellness Exclusions

Check exclusions before you assign a class. The 21st Century Cures Act added section 520(o)(1)(E) to the Federal Food, Drug, and Cosmetic Act, and qualifying clinical decision support can fall outside the device definition when it meets all four statutory criteria.

The four CDS criteria

• The software doesn't acquire, process, or analyze a medical image or a signal from an in vitro diagnostic, or a pattern or signal from a signal acquisition system.

• It displays, analyzes, or prints medical information.

• It supports or provides recommendations to a health care professional.

• It enables that professional to independently review the basis for the recommendation, so the professional doesn't rely primarily on the software.

Patient facing software usually fails the third and fourth criteria because its user isn't a health care professional who can review the basis independently. Don't test only the clinician screen. Test every user, output, and claim.

FDA revised its CDS guidance in January 2026, and the FDA Clinical Decision Support Software guidance states that FDA does not intend to enforce device requirements for CDS that presents a single recommendation when it is the only clinically appropriate option and the other criteria are met. That is enforcement discretion, not a finding that such software meets the third criterion. That change doesn't rescue software that fails another criterion.

General wellness claims

General wellness software is intended for maintaining or encouraging healthy activity and doesn't make disease claims. Sleep tracking for general fitness is different from detecting a specific sleep disorder. The second claim points toward a medical purpose.

FDA also revised its General Wellness guidance in January 2026, so check current wording before you rely on an old claim set. A marketing change can move software back into device scope even when the code hasn't changed. Products such as a clinic AI assistant still need this claim by claim review, because an assistant that drafts text is assessed differently from one that recommends treatment.

List every claim in labeling, onboarding, sales material, and in product text. Test each claim against the exclusion criteria and keep the result in writing.

IMDRF Risk Categories and How to Map Them

Classify the software's clinical function and the healthcare situation it addresses. The FDA presentation on the global SaMD approach describes the IMDRF framework's two axes: the significance of information and the healthcare situation. Their intersection gives four risk categories, from Category I to Category IV. The framework documents are available from the International Medical Device Regulators Forum.

Significance describes what the software does: inform clinical management, drive clinical management, or treat or diagnose. The healthcare situation is non-serious, serious, or critical.

Significance of information	Healthcare situation	IMDRF category
Treat or diagnose	Critical	Category IV
Treat or diagnose	Serious	Category III
Treat or diagnose	Non-serious	Category II
Drive clinical management	Critical	Category III
Drive clinical management	Serious	Category II
Drive clinical management	Non-serious	Category I
Inform clinical management	Critical	Category II
Inform clinical management	Serious	Category I
Inform clinical management	Non-serious	Category I

For example, software that informs clinical management in a serious situation maps to Category I. If it drives clinical management in a critical situation, it maps to Category III. Software that treats or diagnoses in a critical situation maps to Category IV.

Choose the significance level by examining the output's role in care. Does it provide information, shape the next clinical action, or perform diagnosis or treatment? Then assess how serious the situation is and how quickly harm could follow from an incorrect output.

Use the IMDRF category to describe SaMD risk, not to determine the FDA class or submission route. Record the intended function, healthcare situation, user population, and workflow, along with the reasoning behind each choice. FDA makes the final classification decision.

FDA Device Classes and the Pathway Each One Triggers

FDA device class sets the usual premarket route: most Class II devices require 510(k) premarket notification and clearance, while most Class III devices require Premarket Approval (PMA). The FDA guidance on device software functions also describes De Novo as a route for novel devices presenting low to moderate risk.

Class or route	Risk or use case	Typical premarket outcome
Class I	Low risk	Most devices are exempt from premarket review; applicable general controls still apply
Class II	Moderate risk	Usually 510(k) premarket notification and clearance
Class III	High risk	Usually Premarket Approval (PMA)
De Novo	Novel, low-to-moderate risk, no predicate	Establishes a new classification that later devices may use as a predicate
Enforcement discretion	FDA policy for specified device software functions	FDA generally does not intend to enforce certain applicable requirements for functions covered by its policy

Class I devices remain subject to applicable general controls, and some require premarket review. Check the regulation and product code before treating a device as exempt. For Class II, predicate research can set the schedule: identify devices under the relevant regulation and product code, then assess whether one supports a 510(k) pathway.

De Novo provides a route for a novel, low-to-moderate-risk device with no suitable predicate. A granted De Novo establishes a classification that later devices may use as a predicate. Most Class III devices follow the PMA route, which carries the greatest evidence burden among the routes listed here.

Three errors often distort founder timelines:

• Assuming a predicate exists before searching under the relevant regulation and product code.

• Treating simple code as proof of Class I, instead of assessing the clinical consequences of the software output.

• Deferring predicate research until after the submission plan is set.

FDA's policy on device software functions subject to enforcement discretion describes functions for which the agency generally does not intend to enforce certain requirements. Apply that policy only when the function fits its stated scope; enforcement discretion is not a device class or a blanket exemption. Check the applicable regulation, product code, predicate options, and policy scope before setting the submission timeline.

Working Through the Classification Decision

Work in this order, and don't let architecture decisions outrun step 1. The FDA page on device software functions including mobile medical applications applies the same risk based approach used for other devices, with obligations set by the specific software function and its intended use. Our SaMD solutions work follows that function level split.

1. Write the intended use statement. Name the user, use environment, condition, and decision supported. The usual slip is writing it after the architecture is fixed.

2. Test device status and exclusions. Apply the device definition, then the CDS and wellness criteria to every output, not only the safest screen.

3. Split independent functions. Assess a diagnostic alert separately from scheduling, visualization, or data transport so low risk features don't hide a higher risk function.

4. Assign an IMDRF category per function. Use the matrix for each function rather than rating the whole product by its most cautious claim.

5. Find the FDA regulation, class, and product code. Search the FDA product classification database and check whether an exemption applies.

6. Choose the pathway. Decide between exemption, 510(k), De Novo, or PMA only after the predicate search, and check enforcement discretion in current FDA documents.

7. Map risks to evidence. Link each risk to verification, validation, cybersecurity, human factors, and clinical evidence, plus reasonably foreseeable misuse.

8. Ask FDA early when uncertain. Use a Q-Submission for presubmission feedback when intended use, predicates, or evidence expectations are unclear. Formal classification remains FDA's call through the relevant review division.

Keep four documents from this work, the intended use statement, function list, category rationale, and predicate search. The pathway you choose is only as reliable as the intended use statement in step 1.

A Hypothetical Sepsis Alert Classified Step by Step

This example is hypothetical, and FDA would make the final classification call. Say a module reads vitals and laboratory Observation resources from an EHR through a FHIR R4 interface, computes a sepsis risk score, and shows the result in a nurse worklist with a recommendation to escalate care.

Start with two draft intended use statements. In the first, the module flags patients for clinician review and shows the input values behind the score. In the second, it prompts a specific escalation pathway for patients above a threshold.

Sepsis can progress quickly, so assess the healthcare situation as critical in both drafts. The first draft informs clinical management, which gives Category II for a critical situation in the matrix. The second draft drives clinical management, which gives Category III.

The alert wording moves the category here, not a change in the model.

Split the functions before you settle the route. Assess the FHIR ingestion pipeline, the risk model, and the worklist display separately, because the pipeline moves data, the model produces the clinical output, and the display shapes how a nurse acts on it. A failure in each function has a different risk and a different control.

Then test the clinician facing output against the CDS criteria, including whether the nurse can independently review the basis for the recommendation from the displayed Observations, time windows, and threshold logic. If the basis isn't reviewable, don't plan around the exclusion.

Evidence follows the chosen claim. Expect to define validation datasets that match the target population, clinical evaluation for the score and its intended benefit, human factors work on the worklist, and cybersecurity controls for the EHR interface and audit trail. Write both intended use versions, compare the categories and evidence burden, and pick the claim before you build the model.

Confirm the Class Before You Build Further

Classification is the first step. For the EU view, see our EU MDR Rule 11 guide. For what comes next, see our guides to FDA pathways for AI medical devices, IEC 62304 software safety classification, AI in MedTech engineering, and the predetermined change control plan.

This article is part of our Medical Device Software Regulation: A Complete Guide, which covers device status, US and EU classification, routes to market, and the engineering standards in one place.

Conclusion

Classification affects more than the initial submission. A change to intended use, indications, performance, or risk controls can change a product's regulatory position. Set release governance, monitoring, validation, and audit trails into the software architecture so changes can be assessed and documented before deployment.

Ekipa AI provides technology-focused compliance support for FDA SaMD requirements, including software classification and audit-ready system architecture. To confirm your classification and plan the build, explore our SaMD solutions or book a consultation.

Frequently asked questions

What is the difference between SaMD and software in a medical device?

SaMD performs its medical purpose on its own, without being part of a hardware device. Software in a medical device (SiMD) is part of a hardware device, such as firmware that controls an infusion pump, and is reviewed as part of that device.

Is all clinical decision support software regulated by the FDA?

No. CDS that meets all four criteria in section 520(o)(1)(E) of the FD&C Act is not a device. Software that analyzes medical images or signals, or that is intended for patients rather than health care professionals, usually does not meet those criteria.

Does De Novo need a predicate?

No. De Novo is a route for a novel, low-to-moderate-risk device when no suitable predicate exists. A granted De Novo request establishes a classification that later devices may use as a predicate.

Can a wellness app become a medical device?

Yes. Claims to detect, diagnose, or treat a specific condition can change the regulatory position of software previously presented for general wellness. Review marketing and in-product claims whenever they change.

What is a Q-Submission, and when should we use one?

A Q-Submission lets a sponsor request FDA feedback before a premarket submission. Consider it when intended use, the predicate strategy, or evidence expectations remain uncertain. FDA makes the final classification decision.

The Q-Submission process takes time, so factor it into the development schedule. Prepare focused questions and supporting materials around the specific issues that could affect your submission strategy.