The distinction at the center of the framework
The FDA sought comment on harmonized guidance for the clinical evaluation of software as a medical device within the broader scope of FDA medical device regulation. An international forum developed the guidance to support consistent principles across jurisdictions. The central question is what the software does in a patient’s care.
The framework categorizes software by two factors: the seriousness of the condition involved and the significance of the information the software provides. Software that only displays data falls into a different category from software that informs a clinical decision. Software that drives a clinical decision falls into another category.
These distinctions describe different levels of involvement in care. Displaying information has a different function from informing a decision. Informing a decision has a different function from driving one. The framework focuses on the software’s role, rather than its appearance or presentation.
Harmonization matters because software can cross borders quickly, while regulatory systems do not operate in the same way everywhere. One product can reach users in several jurisdictions even when those jurisdictions use different regulatory approaches. Consistent principles can make those differences easier to assess. The FDA effort was a request for comment, however, and did not classify every digital health product.
Where telehealth fits
Most telehealth platforms are not medical devices. CMS telehealth coverage information addresses telehealth as a care channel. A platform that connects a patient with a clinician generally does not perform a medical device function. It acts as a channel for delivering care. The regulated components are the clinician’s license and the medication, subject to FDA drug regulation.
As a result, no agency evaluated the platform before it reached the patient. The platform’s intake logic, dose escalation defaults, and method for triaging a reported side effect are product design decisions. They form part of the way the service operates, even when the platform itself is not a medical device.
This distinction matters because a telehealth platform can include many features without automatically falling within the software framework. An intake process, treatment dashboard, or automated message may form part of the channel through which care is delivered. The relevant category depends on the function the software performs. It may display information, inform a decision, or drive a decision.
For people comparing clinical oversight and telehealth services, the policy question concerns what exists behind that channel. A polished interface does not show whether a service has serious clinical governance or very little. Comparing these systems requires a different inquiry from asking whether a platform looks modern or offers a convenient online process.
The product decisions behind the interface
An intake process is more than a visual form. Its logic determines what information the service requests and how it responds to the answers. Dose escalation defaults are product design decisions as well. The same applies to the way a platform handles a reported side effect.
These choices can affect how information reaches the clinician and how the service responds to a reported concern. They also explain why two services can look nearly identical while operating in very different ways. One may have serious clinical governance behind its intake, prescribing, follow-up, and escalation processes. Another may have very little.
The interface does not reveal this difference. A comparison limited to sign-up steps, page design, or the availability of an online consultation can miss the systems that shape the clinical process. The relevant question is whether the service has meaningful oversight behind its channel and how that oversight operates.
The software framework provides a useful vocabulary for examining these choices, even when a telehealth platform is not itself a medical device, as a related discussion of medical device cybersecurity illustrates. It separates the display of information from the use of information to inform a clinical decision. It also separates that function from software that drives a clinical decision. This vocabulary helps identify how software participates in care and where clinical responsibility remains.
Why classification still matters
The guidance effort does not make every telehealth interface regulated medical software. Its value comes from asking specific questions about function. What does the software do? How significant is the information it provides? How serious is the condition involved? Does the software display information, inform a clinical decision, or drive one?
These questions avoid two assumptions. A service is not automatically adequate because it operates as a communication channel. An automated feature is also not automatically medical device software. The software’s function matters, along with the clinical governance surrounding the service.
As care moves through digital channels, the boundary between communication, decision support, and decision-making will remain important. Clear categories can make that boundary easier to examine. The quality of a service still depends on the oversight and processes operating behind its interface.