Is Your Software a Medical Device? FDA, EU and India Compared

A product does not become a medical device merely because it handles health data, runs in a hospital or uses machine learning. The central question is whether its intended purpose falls within the jurisdiction’s device definition. That purpose is evidenced by labeling, product requirements, website claims, sales material, user interface, validation protocol and the clinical workflow the manufacturer designs.

Start with a one-sentence statement: “The software is intended to [function] for [patient population], used by [user] to [clinical purpose], producing [output] that informs or performs [action].” Ambiguous verbs such as support, assist or enable do not neutralize a medical claim. Regulators look at the real function and the consequence of its output.

FDA begins with the “device” definition in section 201(h) of the Federal Food, Drug, and Cosmetic Act. Software intended for diagnosis, cure, mitigation, treatment or prevention of disease—or intended to affect the structure or function of the body—can meet that definition. The 21st Century Cures Act added section 520(o), excluding specified functions such as certain administrative support, healthy-lifestyle tools, electronic patient records and some clinical decision support.

The clinical decision support exclusion is narrow. Among other conditions, a healthcare professional must be able to independently review the basis for a recommendation so they do not rely primarily on it. FDA’s Clinical Decision Support Software guidance explains how the agency interprets those criteria. A patient-facing diagnostic recommendation, an opaque risk score used for an urgent decision, or software that acquires or analyzes a medical image will often remain a device function.

FDA evaluates functions rather than branding. A multi-function product can contain non-device and device functions, and FDA may assess whether the non-device function affects the safety or effectiveness of the device function. After qualification, identify the regulation number, product code, class and likely pathway using FDA’s classification database and comparable cleared products.

Article 2(1) of Regulation (EU) 2017/745 includes software in the definition of a medical device when the manufacturer intends a listed medical purpose. Recital 19 draws a useful boundary: general-purpose software and lifestyle or wellbeing software are not medical devices, even when used in healthcare. Accessories and software that drives or influences a device require separate analysis.

MDCG 2019-11 provides a decision framework for qualification and classification. Software that merely stores, archives, communicates or performs simple search generally does not qualify on that activity alone. Software that acts on data for the benefit of individual patients may qualify when its purpose is medical.

For classification, MDR Annex VIII Rule 11 frequently governs. Software providing information used for diagnostic or therapeutic decisions is class IIa, unless an erroneous decision could cause death or irreversible deterioration (class III), or serious deterioration or surgical intervention (class IIb). Monitoring software is generally class IIa, escalating to IIb when it monitors vital physiological parameters whose variation could create immediate danger. Other software is class I. The consequence analysis must be clinically justified, not selected to reach a preferred class.

India’s Medical Devices Rules, 2017 operate with the Drugs and Cosmetics Act and central-government notifications. The 2020 notification brought all devices within the statutory definition into a phased regulatory framework and expressly refers to software intended by its manufacturer for diagnosis, prevention, monitoring, treatment or alleviation of disease or disorder.

Qualification should therefore map the claimed function to the notified definition and then to the applicable CDSCO classification list. India uses classes A through D, from low to high risk. Standalone software classification depends on intended use and risk; the CDSCO lists and current licensing position should be checked rather than mechanically translating an FDA or EU class.

The manufacturer should document whether the product is standalone software, software in a physical device, an accessory or a non-device health product; identify the responsible licensing authority; and verify current import or manufacture licensing requirements. India-specific labeling, authorized-agent and quality-system obligations may apply even where the technical product is unchanged.

Use a controlled qualification memo rather than a slide or informal email. Record the product version, intended purpose, users, population, inputs, processing, outputs, clinical workflow, claims reviewed and exclusions considered. Then state a separate conclusion for each jurisdiction with pinpoint references to the controlling law or guidance.

Do not assume that “not a device” is permanent. A new claim, patient-facing feature, image-analysis module or integration that drives treatment can change the conclusion. Add regulatory review to product change control and marketing approval so the qualification memo stays aligned with the released product.