When software is a regulated medical device, and when it stays an unregulated wellness product

The line between a regulated medical device and an unregulated wellness product is not drawn by the technology. It is drawn by intended use. The same code, running on the same phone, can sit inside or outside the device definition depending on what the developer claims it does. Both the US and the EU frameworks turn on that intended-purpose analysis first, and only then apply a risk-based test to decide how much oversight attaches. This article walks through how FDA and the EU Medical Device Coordination Group (MDCG) actually make the call, and where the boundary sits in practice.

The controlling question: what does the software claim to do?

In the United States, whether a software function is a device is governed by section 201(h) of the Federal Food, Drug, and Cosmetic (FD&C) Act, and FDA resolves it through intended use. Intended use is the objective intent of the person legally responsible for the software, shown by labeling claims, advertising materials, oral or written statements by the manufacturer, and the circumstances surrounding distribution and use ⁴⁶. If the software is intended for diagnosis of disease or other conditions, or for the cure, mitigation, treatment, or prevention of disease, it is a device under section 201(h), unless it is excluded by section 520(o) ⁴⁶⁴².

FDA's analysis is function-specific, not platform-specific. The same function can be regulated or not depending on the claims made, not the hardware it runs on ⁴⁶³⁵³⁸. FDA's own examples make the point:

A mobile app that simply makes an LED illuminate objects is not a medical device if no medical use is claimed. If the manufacturer markets it as a light source for doctors to examine patients, its intended use becomes similar to a conventional ophthalmoscope and it becomes a device ⁴⁶.
A mobile app that analyzes and interprets EKG waveforms to detect heart irregularities is a device software function, in the same way that desktop software performing that function is regulated as an electrocardiograph ⁴⁶³².
FDA's long-standing hypnotherapy example: tape recordings labeled only for behavior modification, self-improvement, habit correction, learning, and simple relaxation are not devices, but the identical recordings labeled for therapeutic or medical use, or for mitigation, treatment, or cure of a specific disease, are devices ¹³⁷.

The practical implication for regulatory teams is that claims creep is the single most common way a wellness product falls into the device world. The engineering can be frozen while the marketing copy moves the product across the line.

The US carve-outs: section 3060 of the 21st Century Cures Act

Section 3060 of the 21st Century Cures Act amended section 520(o) of the FD&C Act so that the term "device" does not include five categories of software function ⁶²⁶¹:

Software for administrative support of a health care facility.
Software for maintaining or encouraging a healthy lifestyle, unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.
Software that serves as electronic patient records, subject to the statutory criteria.
Software for transferring, storing, converting formats, or displaying medical device data, medical imaging data, or clinical laboratory and other device data and results, unless it is intended to interpret or analyze that data.
Software that provides clinical decision support, if it meets all four statutory criteria in section 520(o)(1)(E).

Categories 2 and 5 are where most consumer and clinical software disputes live, so they are worth taking in turn.

General wellness: the two intended-use categories and the low-risk test

FDA's General Wellness policy defines a general wellness product as one that meets two factors: it is intended only for general wellness use as defined in the guidance, and it presents a low risk to the safety of users and other persons ¹². Both factors must be met before FDA's policy of not examining the product applies.

A general wellness intended use falls into one of two buckets ²⁶⁸:

Maintaining or encouraging a general state of health or a healthy activity, with claims that do not reference any disease or condition ². FDA lists weight management, physical fitness and recreational use, relaxation or stress management, mental acuity, self-esteem, sleep management, and sexual function as examples ²⁸. Sample claims include promoting a healthy weight, encouraging healthy eating, promoting relaxation, or improving concentration and eye-hand coordination ².
A healthy lifestyle claim intended to help reduce the risk or impact of certain chronic diseases where it is well understood that lifestyle choices may play an important role in the outcome ²⁶⁸. Here the relationship must be phrased as "may help to reduce the risk of" or "may help living well with" a chronic disease ⁶. FDA names heart disease, high blood pressure, and type 2 diabetes as examples ⁴.

The low-risk test then screens out products that need active regulation. A product is not low risk, and therefore outside the policy, if it is invasive (penetrating or piercing the skin or mucous membranes), if it is implanted, or if it involves an intervention or technology that may pose a safety risk if regulatory controls are not applied, such as lasers or radiation exposure. FDA also asks whether CDRH actively regulates products of the same type ³⁶¹⁵. Examples FDA gives of products that are not low risk include sunlamps for tanning, implants for self-image or sexual function, a laser marketed to rejuvenate skin, a neurostimulation product claimed to improve memory, and a venipuncture-based lactic acid test ¹⁵.

For pure software, this is why a music app that claims to "soothe and relax" and "manage stress," an app that logs energy expenditure for cardiovascular fitness, and a food-logging app for weight management all sit comfortably outside device regulation ⁵¹³. For non-invasive sensing products that estimate physiologic parameters, FDA adds conditions: the product must not be intended for diagnosis, cure, mitigation, prevention, or treatment; must not substitute for an FDA-authorized device; must not prompt or guide specific clinical action; and must not output values that mimic clinically used values unless validated to reflect them ⁴. That last point is the boundary that trips up wearables. A wrist wearable tracking sleep and pulse can remain a wellness product, but blood pressure output has to be validated to those clinical values to stay in bounds ⁷.

Device software functions: the three-bucket framework

FDA's Policy for Device Software Functions and Mobile Medical Applications sorts every software function into one of three buckets ³¹³⁸³⁶:

Bucket 1, the focus of oversight. These are functions that are devices and whose failure could pose a risk to patient safety ³⁶. FDA's examples include functions that turn a mobile platform into a regulated device using built-in light, camera, or sensors; functions that capture and display an ECG signal; electronic stethoscope functions; and functions that perform patient-specific analysis and provide a diagnosis or treatment directive to a clinician or patient ³²³³. Concrete examples in this bucket include radiation therapy dose planning software, computer-aided detection (CAD) image processing, software that detects a time-critical condition such as stroke or sepsis and alerts a clinician, software that flags out-of-range glucose readings, and software that analyzes an ECG waveform to detect arrhythmias such as atrial fibrillation ³³.

Bucket 2, enforcement discretion. These functions may meet the device definition but pose low enough risk that FDA does not intend to enforce requirements ³¹³⁸³⁴. Examples include functions that coach or prompt patients to manage cardiovascular disease, hypertension, diabetes, or obesity through healthy weight, nutrition, exercise, or simple medication-schedule prompting; functions that let patients capture and send an image, such as a photo of a skin lesion, to supplement a consultation; and functions that perform simple calculations routinely used in clinical practice ³⁴. Non-Device medical device data system (MDDS) functions that transfer, store, convert, or display data without modifying it, and without controlling connected devices, also fall here ⁴⁹.

Bucket 3, not a device at all. Many functions do not meet the device definition and are not regulated as devices ³¹³⁸³⁷. FDA's examples include access to electronic medical textbooks and reference materials with generic search (medical dictionaries, the Physician's Desk Reference, DSM, first-aid encyclopedias), and educational or training tools such as medical flash cards and quiz apps ³⁷. Apps that provide electronic access to a device's own cleared labeling or instructions for use, and software used in device production or quality-system recordkeeping, are also outside the definition ⁴⁷⁵².

The critical distinction between bucket 1 and bucket 3 is analysis and interpretation. Storing, displaying, or referencing information is generally not a device function; performing patient-specific analysis and producing a diagnostic or treatment output generally is ³³³⁷.

Non-Device clinical decision support: the four criteria

The narrowest and most litigated carve-out is clinical decision support (CDS). A CDS software function is excluded from the device definition only if it meets all four criteria in section 520(o)(1)(E) ³⁰:

It does not acquire, process, or analyze a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system. FDA reads a single discrete clinically meaningful measurement as medical information, but continuous sampling of the same information as a pattern or signal that fails this criterion and keeps the software a device ³⁰⁵⁸.
It displays, analyzes, or prints medical information about a patient or other medical information. FDA reads "other medical information" to include peer-reviewed studies, clinical practice guidelines, and similarly validated, evidence-supported information ³⁰⁵⁸.
It supports or provides recommendations to a health care professional (HCP) about prevention, diagnosis, or treatment of a disease or condition. FDA reads this as condition-, disease-, or patient-specific recommendations that enhance, inform, or influence a decision but do not replace or direct the HCP's judgment. A list of options, a prioritized list, or a list of follow-up steps can qualify. Recommendations directed at patients or caregivers rather than HCPs are device functions ³⁰²⁰⁵⁸.
It is intended for a purpose where the HCP can independently review the basis of the recommendation and is not required to rely primarily on it. FDA expects the software or labeling to provide the underlying inputs and sources in plain language, to identify the datasets and their quality, and not to omit material information. FDA also weighs the level of automation and the time-critical nature of the decision, noting that automation bias is greater in urgent situations ³⁰⁵⁷.

The tension sits between criteria 3 and 4. A function may inform or influence clinical management under criterion 3, but to stay Non-Device CDS it must also present its basis so the clinician can independently validate the recommendation before acting under criterion 4 ²⁰⁵⁷⁵⁸. Software that a clinician must trust without being able to check its reasoning, or that outputs to a patient, is a device.

The SaMD risk grid behind the classification

Once software is a device, its risk category follows the IMDRF Software as a Medical Device (SaMD) framework that FDA adopted. It uses two axes: the significance of the information the software provides (treat or diagnose, drive clinical management, or inform clinical management) and the state of the healthcare situation (critical, serious, or non-serious) ¹⁰⁰. The combination yields four categories, from Category I (inform in a non-serious situation) up to Category IV (treat or diagnose in a critical situation) ¹⁰⁰. The same logic underlies where a device software function lands in the US oversight buckets and, as below, how it is classified in the EU.

The EU framework: qualification then classification under MDR

The EU asks the same two questions in sequence, but formalizes them under the Medical Devices Regulation (MDR, 2017/745) and the In Vitro Diagnostic Regulation (IVDR, 2017/746), interpreted through MDCG 2019-11.

Qualification. Software is not automatically a medical device just because it is used in healthcare ¹²⁴. To be medical device software (MDSW), it must meet the definition of software and the definition of a medical device, and provide information for one of the medical purposes in MDR Article 2(1): diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation, investigation, replacement or modification of anatomy or a physiological or pathological process, or control or support of conception ¹²⁴¹²⁷. Software that creates information based solely on data from in vitro diagnostic devices is IVD MDSW instead ¹²⁷.

The decisive test is whether the software acts on data beyond storage, archival, communication, or simple search. MDCG defines simple search (retrieving records by matching metadata against search criteria) as not qualifying ¹²⁴. Software that processes, analyzes, interprets, calculates, creates, or modifies medical information for a medical purpose can qualify, for example by altering the representation of data for a medical purpose, searching images for findings that support diagnosis or therapy, or applying contrast, edge enhancement, or grayscale manipulation that serves as decision support ¹²⁴.

What does not qualify. Software that only records, stores, displays, or communicates information, without medical-purpose processing, generally is not a device ¹²⁴⁷⁸. MDCG's own examples of software that is not MDSW include diary-type apps that only record and display insulin doses without analyzing data or altering treatment; clinical information systems and patient data management systems that primarily store and transfer patient information; a pre-hospital ECG system that only stores and transfers ECG data to a remote doctor; needle counters; and an app that merely transmits data between partners because it performs no action on the data beyond communication ⁷⁸¹²⁵¹²⁶⁸⁶. In one borderline example, a sexually transmitted infection "risk calculation" was found not to have a medical purpose because it relied on indirect criteria and behavioral habits rather than physiological parameters ¹²⁶. This is the EU analogue to the US general-wellness line: absent a medical purpose acting on health data, the software stays outside the regulation.

Classification under Rule 11. Once software qualifies as MDSW, classification Rule 11 of MDR Annex VIII sets the risk class on the same significance-of-information and seriousness-of-condition logic as the SaMD grid ⁷⁵⁷⁶:

Class IIa by default for software providing information used to make decisions for diagnostic or therapeutic purposes ⁷⁵⁷⁶.
Class IIb where an incorrect output could cause serious deterioration of health or require surgical intervention, or where the software monitors vital physiological parameters whose variation could create immediate danger ⁷⁵⁷⁶⁷⁷.
Class III where an incorrect output could lead to death or irreversible deterioration of health ⁷⁵⁷⁶⁷⁷.
Class I for all other qualifying software ⁷⁵.

Rule 11 is notoriously broad. Because most clinical decision support informs a diagnostic or therapeutic decision, the default pulls a large share of MDSW to Class IIa or higher, which is a sharper contrast with the US approach, where qualifying Non-Device CDS can sit entirely outside device regulation.

Where the line actually sits

Two jurisdictions, one underlying logic. First ask whether the software has a medical intended use or purpose that acts on health data; if not, it is a wellness or administrative product outside device regulation in both systems. If it does, apply a risk test: FDA sorts functions into oversight, enforcement discretion, or non-device, with a specific statutory carve-out for qualifying clinical decision support; the EU classifies qualifying MDSW under Rule 11 from Class I to Class III.

The practical divergences worth flagging for a regulatory strategy:

The US gives a genuine off-ramp for clinician-facing CDS that meets all four 520(o)(1)(E) criteria. The EU has no equivalent statutory CDS exclusion, and Rule 11 tends to classify comparable software as an active device from Class IIa upward ³⁰⁷⁵⁷⁶.
Patient-facing versus clinician-facing matters enormously in the US. A recommendation delivered to a patient or caregiver is a device function even when the identical logic delivered to an HCP could be Non-Device CDS ²⁰.
The most common failure mode is claims creep. Because intended use and intended purpose are established by labeling, marketing, and manufacturer statements, a wellness product can be pushed into the device world by a single disease claim or a clinically validated output value, without any change to the underlying software ⁴⁶⁴¹²⁴.

For a product near the boundary, the durable answer comes from mapping the specific claimed function against these criteria in the target market, then pressure-testing the marketing language against it, rather than reasoning from what the technology is capable of.

Software as a Regulated Medical Device Versus an Unregulated Wellness Product