The question the agency had to answer
The FDA’s early inquiries into mobile medical applications addressed a basic question: when does software that handles health information become a medical device? Not every health app performs a medical function. Some software records information, helps users remember tasks or organizes personal data. Other software analyzes data to produce a diagnosis or controls a device. Treating both types of software in the same way would make the regulatory boundary too broad to provide a useful distinction.
The agency adopted a risk-based approach. Software that performs a medical device function, such as analyzing data to produce a diagnosis or controlling a device, falls within the FDA’s medical-device framework. Software that records what someone eats or reminds that person to take a pill generally does not. For most low-risk wellness software, the FDA said it would exercise enforcement discretion.
The software’s function determines the distinction. A health-related purpose or a polished interface does not by itself make an app a regulated device. The relevant question is whether the app performs a medical device function or remains a low-risk wellness tool, a distinction also relevant to where telehealth sits in software as a medical device. The app’s appearance, branding or general connection to health care does not answer that question.
Why the boundary matters in practice
The boundary has held reasonably well, but it becomes harder to apply when software takes on a more consequential clinical role. A food log differs from software that analyzes data to produce a diagnosis. A medication reminder differs from software that controls another device. As the software’s function becomes more consequential, the FDA’s device framework becomes more directly relevant.
The approach also separates a software product’s regulatory status from the larger service built around it. A platform may look structured and clinical without the platform itself being a regulated device. By contrast, placing a medical function inside a consumer app does not turn that function into ordinary wellness software.
This distinction matters because public availability does not mean that the FDA reviewed the service or included it among device approvals, denials and clearances. An app can be offered to the public even if its full workflow has not been reviewed as a medical device. The FDA’s framework addresses a narrower question: whether the software performs a regulated device function. That classification does not establish that the service’s clinical processes are sound or that the agency evaluated them.
The platform is not the same as the care
A GLP-1 telehealth app is not usually a regulated device. It provides a channel through which a patient connects with a clinician. The regulated parts are generally the clinician’s licensure and the medication, rather than the telehealth platform. No agency reviewed the platform before it launched.
Several features therefore remain outside the device review described in the source notes. A platform’s clinical workflow, dose escalation defaults and process for triaging side-effect reports are commercial design decisions rather than approved processes. These choices can affect how a patient communicates with a clinician and how information moves through the service. They do not, by themselves, turn the platform into an FDA-reviewed device.
This difference matters when comparing services. Two services can both fall outside device regulation while handling clinical oversight in different ways. A service may connect a patient with a clinician, but that connection does not explain how the workflow handles escalation or side-effect reports. Our clinic rankings for clinical oversight assess how providers handle that responsibility in practice rather than treating the existence of an app as evidence that the workflow received FDA approval.
The platform’s role and the provider’s care process should therefore be considered separately. The app may carry information between a patient and a clinician, but its presence does not show how the provider makes decisions or responds to information. Those matters belong to the provider’s operating model, not automatically to the device classification of the software.
What remains for patients to evaluate
The FDA’s risk-based approach leaves room for low-risk wellness tools while directing regulation toward software that performs a medical device function. This creates a workable boundary, but it does not make every unregulated health platform equivalent. The absence of device regulation describes the software’s function. It does not answer how the provider handles clinical oversight.
The distinction also shows where evaluation must take place. When a platform connects a patient with a clinician, its interface and workflow can affect how information is collected, when that information reaches the clinician and how a report is routed. Those processes do not receive approval simply because they are built into an app. They remain part of the provider’s operating model.
The recurring policy question is not whether every health app should be regulated as a device. The question is whether the risk-based approach gives people a clear way to tell what the FDA evaluated, what it did not evaluate and where responsibility for oversight rests. A device classification can describe the software’s function, but it cannot by itself describe the quality of the surrounding clinical service.