Is my healthcare app a medical device? FDA’s January 2026 CDS guidance explained

As of October 2026, most healthcare apps are not medical devices: scheduling, records, billing, telehealth video, general wellness features and decision support that a clinician can check for themselves are outside FDA device regulation. Your app is likely a device if it analyzes medical images, physiological signals or lab-instrument data, gives patients diagnosis or treatment advice, or drives time-critical clinical decisions. FDA revised its Clinical Decision Support (CDS) guidance in January 2026, most notably relaxing its stance on software that gives a single recommendation, and updated its general wellness guidance the same month. This guide explains both, with a decision tree and examples taken from the guidance itself.

1. What Changed in January 2026

FDA issued a revised final guidance, Clinical Decision Support Software, on 6 January 2026, replacing the September 2022 version. It then reissued it on 29 January 2026 with a minor correction; the 29 January document is the current one. FDA updated General Wellness: Policy for Low Risk Devices on 6 January 2026 as well, replacing the 2019 version.

Two points keep this in proportion. First, enforcement discretion is not an exclusion: the software is still a device in law, FDA simply doesn’t intend to enforce requirements, and it can change that position. Second, the guidance is non-binding; the statute is what defines a device. Law firms reviewing the update, such as Covington, described it as an adjustment rather than a deregulatory overhaul.

2. The Five Statutory Exclusions for Software

The 21st Century Cures Act added section 520(o) to the Food, Drug and Cosmetic Act. It removes five kinds of software function from the definition of a device:

1. (A) Administrative support of a health care facility: scheduling, billing, inventory, workflow.
2. (B) Healthy lifestyle software, for maintaining or encouraging a healthy lifestyle and unrelated to diagnosing, curing, mitigating, preventing or treating a disease or condition.
3. (C) Electronic patient records, under conditions, including that the function isn’t intended to interpret or analyze the records for diagnosis or treatment.
4. (D) Transferring, storing, converting or displaying lab test or other device data and results, without interpreting or analyzing them.
5. (E) Clinical decision support that meets four criteria, covered next.

Most of what app builders make, such as booking, patient portals, intake forms, telehealth video, secure messaging and EHR integrations, sits in (A), (C) or (D). It is the analysis and recommendation features that need a closer look.

3. The Four Non-Device CDS Criteria

Under section 520(o)(1)(E), a CDS function is not a device only if it meets all four criteria, as quoted in the guidance:

1. Criterion 1: it is “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. Criterion 2: it is “intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines).”
3. Criterion 3: it is “intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition.”
4. Criterion 4: it is “intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.”

In plain terms: inputs must be medical information (a lab result, a symptom list), not images, signals or sensor streams; the output goes to a clinician; and the clinician can see why the software recommends what it does.

What FDA expects for Criterion 4

The guidance recommends that the software or its labeling:

• state the intended use, intended clinician user and patient population;
• identify the required inputs, how to obtain them and data quality requirements;
• give a plain-language description of how the algorithm was developed and validated, including the general approach (for example clinical studies, expert panel, statistical modelling or AI/ML techniques), the data relied on, and validation results;
• show the clinician the relevant patient-specific information and what is unknown, such as missing or unexpected inputs.

FDA does not consider software meant for a critical, time-sensitive task to meet Criterion 4, because the clinician won’t have time to review the basis. The concern is automation bias: over-reliance on automated suggestions.

4. Patient-Facing Apps and the General Wellness Update

The CDS exclusion only covers software for health care professionals. The guidance says plainly that software supporting or giving recommendations to patients or caregivers meets the definition of a device. That doesn’t mean every patient app is regulated: FDA applies its device software functions and mobile medical apps policy, which lists many patient-facing functions where it doesn’t intend to enforce requirements, such as tools that help patients self-manage a condition without giving specific treatment suggestions, or that track and organise health information.

The January 2026 general wellness guidance

The updated General Wellness guidance matters most for wearable and sensor apps. FDA now says that products using non-invasive sensing, such as optical sensors, to estimate blood pressure, oxygen saturation, blood glucose or heart rate variability may be general wellness products when the outputs are for wellness only and the product:

• is non-invasive and not implanted;
• is not intended to diagnose, cure, mitigate, prevent or treat a disease or condition;
• is not intended to substitute for an FDA-authorized device;
• does not prompt or guide specific clinical action or medical management;
• does not show values that mimic clinical ones unless they have been validated.

Such products may show values, ranges, trends and baselines in the context of sleep, activity, stress or recovery. They stop being wellness products if their labeling, advertising, interface or functions mention specific diseases or diagnostic thresholds, raise alerts that call for clinical action, give treatment guidance, or claim clinical-grade accuracy. A product may suggest that seeing a health professional could help when a reading is outside a wellness range, as long as it doesn’t name a disease, call the reading abnormal or give ongoing disease-management alerts.

5. Decision Tree: Is My App a Device?

Work through each software function separately. A single app can contain both device and non-device functions; FDA’s review focuses on the device functions, under its multiple function policy.

1. Is the function intended for a medical purpose: diagnosing, curing, mitigating, treating or preventing disease, or affecting the body’s structure or function? If no, for example scheduling, billing or general fitness, it’s not a device. Stop.
2. Is it only administrative, a patient record, or a transfer or display of data without interpretation? If yes, it’s excluded under 520(o)(1)(A), (C) or (D). Stop.
3. Is it a general wellness product under the January 2026 guidance, with no disease claims, thresholds or clinical alerts? If yes, FDA doesn’t intend to regulate it. Stop.
4. Does it acquire, process or analyze a medical image, an IVD signal, or a pattern or signal from a signal acquisition system (ECG waveforms, continuous glucose data, audio of a cough, NGS output)? If yes, it fails Criterion 1 and is a device.
5. Is the user a patient or caregiver rather than a clinician? If yes, it’s not CDS under 520(o)(1)(E). Check FDA’s mobile medical apps policy to see whether it falls under enforcement discretion; otherwise it’s a device.
6. Does it give a specific diagnostic or treatment directive, or support a time-critical decision (alarms for sepsis or stroke, dosing in an emergency)? If time-critical, it’s a device. If it gives a single recommendation that is the only clinically appropriate option, and isn’t time-critical, it may fall under enforcement discretion.
7. Can the clinician independently review the basis: inputs, sources, method, validation and what’s missing? If no, it fails Criterion 4 and is a device. If yes to all of the above, it’s non-device CDS.

Our free FDA checker walks through these questions for your app’s features. It’s a first pass, not a regulatory determination. If the answer is unclear, FDA’s Digital Health Center of Excellence accepts questions at DigitalHealth@fda.hhs.gov, and the 513(g) request process gives a formal classification.

6. Examples From the Guidance

7. AI, LLMs and Predetermined Change Control Plans

The CDS guidance doesn’t have separate rules for machine learning or large language models; the same four criteria apply. AI features raise three practical issues:

• Transparency (Criterion 4). The guidance names AI/ML techniques as an approach you must describe, along with the training data and validation results. An LLM that produces a recommendation without showing which patient data and which sources it relied on will struggle to meet Criterion 4.
• Accepted sources (Criterion 2). Several examples move from enforcement discretion to device when the software relies on information that can’t be verified as coming from well-understood and accepted sources. Ground clinical outputs in cited guidelines or labeling, and show the citation.
• Patient-facing chat. A symptom checker or chatbot that gives patients diagnosis or treatment advice isn’t CDS at all, because the user isn’t a clinician. Keep patient-facing AI to information, navigation and routing unless you plan for FDA review. Our intake chatbot guide shows that pattern.

The CDS guidance doesn’t address ambient AI scribes directly. Its closest example is software that drafts a summary of a radiologist’s own findings for the radiologist to finalise, which falls under enforcement discretion. A scribe that only records and summarises a visit for the clinician to edit is closer to documentation than decision support, but once it suggests diagnoses or orders, run those functions through the four criteria. See our AI scribe guide.

If your AI function is a device: PCCPs

Models change, and every significant change to a cleared device can need a new submission. FDA’s final guidance on Predetermined Change Control Plans for AI-enabled device software functions (the current page is dated August 2025) lets you describe planned modifications, such as retraining on new data, together with how you will develop, validate and implement them, in your original submission. Changes made within an authorized plan don’t need a new submission. FDA’s broader AI-enabled device software lifecycle guidance was still a draft (January 2025) when we checked.

Selling in Europe as well? Medical device software there is assessed under different rules; see our EU AI Act healthcare guide.

8. What This Means for How You Build

• Write an intended-use statement per feature before you build: who uses it, for what decision, how urgent the decision is. Most classification problems start with vague intended use.
• Keep the clinician in the loop by design. Show inputs, sources and missing data next to every recommendation, and require a clinician action to accept it.
• Keep patient-facing features to information and routing unless you are ready for device requirements.
• Keep marketing consistent with intended use. No disease claims for wellness features.
• Keep records. If you are building a device, design controls, software validation and electronic records rules apply; our guides to 21 CFR Part 11 for software and Part 11 compliant software cover the record-keeping side.

VertiComply generates full-stack healthcare apps (web, plus native iOS and Android) with HIPAA safeguards on every plan, including encryption, audit logging, role-based access control and session timeouts. It doesn’t make an app FDA-cleared; device status depends on your app’s intended use. Our FDA compliance overview and the FDA checker help you decide early which features need regulatory attention.

This article explains FDA guidance for product teams. It is not legal or regulatory advice; for a binding answer, consult a regulatory professional or ask FDA.

9. Frequently Asked Questions

Is my healthcare app a medical device?

Probably not if it handles scheduling, billing, records, messaging, telehealth video or general wellness, or gives clinicians recommendations they can independently check. It probably is if it analyzes medical images, physiological signals or lab-instrument data, gives patients diagnosis or treatment advice, or supports time-critical clinical decisions. Assess each feature separately against section 520(o) and FDA’s January 2026 guidance.

What changed in FDA’s January 2026 CDS guidance?

FDA issued revised CDS guidance on 6 January 2026, replacing the 2022 version, and a corrected version on 29 January 2026. The main change is enforcement discretion for software giving a single recommendation when only one option is clinically appropriate. It also drops the rule that risk scores are automatically devices.

What are the four criteria for non-device clinical decision support?

Under section 520(o)(1)(E) of the FD&C Act, the software must not analyze medical images, IVD signals or physiological patterns; must display, analyze or print medical information; must support or provide recommendations to a health care professional; and must let that professional independently review the basis for the recommendations so they don’t rely primarily on them.

Is a patient-facing symptom checker a medical device?

It can be. The CDS exclusion only covers software for health care professionals, so a tool that gives patients diagnosis or treatment recommendations meets the device definition. FDA may still choose not to enforce requirements for some low-risk patient tools under its mobile medical apps policy.

Are wearables that estimate blood pressure or glucose medical devices?

Not necessarily, as of the January 2026 general wellness guidance. Non-invasive products may estimate blood pressure, oxygen saturation, blood glucose or heart rate variability for wellness uses if they make no disease claims, don’t use clinical thresholds or alerts, don’t replace an authorized device, and show clinical-looking values only if validated.

Do AI features change whether my app is a device?

The same criteria apply to AI, but AI makes Criterion 4 harder: clinicians must be able to see the inputs, sources, method and validation behind a recommendation. LLM outputs that can’t be traced to accepted sources, or that go directly to patients, are more likely to be devices.

Last reviewed 12 October 2026. FDA guidance documents are revised from time to time; check FDA’s guidance pages for the current versions.