Declaration DeskGuideAll guides

Guide

Is my app a medical device? US, UK, and EU

It is a fair question with an unfair answer: there is no single answer. The US, Great Britain, and EU/NI each ask it from a different law, starting from a different definition, and the same app can genuinely qualify in one market and not in another.

Every developer eventually runs into this question, usually while filling out a store form. It sounds like it should have one answer. It does not, because “medical device” is not one legal concept — it is three, defined by three separate bodies of law that were not written to agree with each other.

Three different starting points

The United States starts from a definition that reads more broadly on paper: the Federal Food, Drug, and Cosmetic Act (FD&C Act) defines a device as, among other things, anything intended for “diagnosis of disease or other conditions” or intended “to affect the structure or any function of the body.” But Congress then wrote five specific software exclusions directly into that same statute (FD&C Act §520(o)): certain administrative support software, certain wellness software (only if it is also unrelated to diagnosing or treating disease), certain electronic patient records, certain software that only transfers, stores, converts the format of, or displays data without interpreting it, and certain clinical decision support software built for healthcare professionals. Nothing quite like that statutory carve-out exists in UK or EU law — in the UK, the wellness exclusion lives in regulator guidance alone; in the EU, it lives in a recital of the Regulation and in guidance, not in an operative article.

Great Britain runs on older law: the UK Medical Devices Regulations 2002 (UK MDR 2002), rooted in the EU’s 1993-era directive rather than the 2017 MDR. Its purpose list is narrower on its face — disease; injury or handicap; anatomy or physiological process; and control of conception. It does not name “prediction and prognosis of disease” the way the MDR does. But MHRA guidance (the regulator’s own standalone-software document) treats an app that estimates a specific patient’s disease risk from their own data as capable of being a device anyway, while population-level risk information is treated as unlikely to be one. The guidance also makes a point worth remembering everywhere: what a developer calls the product is a starting point, not the last word — general disclaimers are not treated as sufficient if a medical claim is made or implied somewhere else in the product.

EU and Northern Ireland apply Regulation (EU) 2017/745 (the Medical Device Regulation, or MDR). A product qualifies if its manufacturer intends it, alone or in combination, for one or more of several listed medical purposes — among them: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability; investigation, replacement or modification of anatomy or of a physiological or pathological process or state; and providing information by means of in vitro examination of specimens from the human body. Separately, the Regulation also deems devices for control or support of conception to be medical devices. Software is explicitly within scope of that definition: a recital of the Regulation states that general-purpose software, and software intended only for lifestyle and wellbeing, is not a device, even when it is used in a healthcare setting. Guidance from the Medical Device Coordination Group (MDCG 2019-11 Rev.1) walks through how that line applies to real software.

The same app can land in different places

Here is a concrete case where the three markets diverge, drawn directly from the statutes and guidance above. Picture a clinical decision support feature built for physicians: it surfaces a recommendation, shows the peer-reviewed clinical evidence behind it, and is built so the physician can independently review that evidence rather than simply act on the software’s say-so. If it meets every condition the US statute sets for that exclusion, that feature can fall outside the FDA’s device definition entirely. Neither the EU MDR nor the UK MDR 2002 writes an equivalent exclusion for clinician-facing decision support into their own device definitions — the same feature is generally evaluated as a device under each of those frameworks instead. One function; three legal starting points; not automatically the same outcome in each.

That example runs in one direction. Other functions run the other way — a product with no disease-specific claim at all can clear the bar in all three markets without difficulty. The point is not that any one jurisdiction is stricter across the board. It is that the analysis has to be done three separate times, against three separate texts.

What actually decides the answer

None of the three tests above turns on a single fact. Across all three, the same handful of things move the answer:

  • The exact wording you use — on the label, in the app itself, in the app-store listing, and in marketing. All three regimes start from what the manufacturer says the product is for, even where they weigh that statement differently against what the product actually does.
  • Who the output is for — a general consumer, or specifically a healthcare professional. This is the entire hinge of the US clinical-decision-support exclusion above, and it matters in different, less absolute ways elsewhere.
  • Whether the claim names a disease or condition, versus describing general fitness or wellbeing. This is the line every wellness exclusion in every market is drawn around.
  • What data feeds the function — data drawn from an in-vitro diagnostic device, for instance, can put a function on a different regulatory track in the EU and GB than the same function fed by data the user typed in themselves.
  • What the software does with that data — displaying it, versus interpreting or analyzing it. Several of the US statutory exclusions above turn on exactly that distinction.

None of this resolves in the abstract. It depends on your app’s actual claims, actual functions, and actual users, checked against each market’s own text.

Sources

This guide is general information, not legal advice, and not an assessment of your app.