Is my software or AI tool a medical device? The key is in the purpose

There is an explosion of software and AI tools under development for healthcare applications. In conversations with software developers, healthtech companies and medical device manufacturers, one of the most challenging issues is whether a new product will be classified as a medical device, bringing with it significant regulatory and compliance requirements before it can be placed on the market.

Recent guidance from the MHRA and a recent decision of the Court of Justice of the European Union (CJEU) provides valuable insights into how regulators approach this question. The consistent theme is that classification depends less on the technology itself and more on the product’s intended purpose.

The MHRA’s focus on intended purpose

The MHRA’s recent guidance on ambient voice technology (AVT) reinforces a fundamental regulatory principle: whether a product is a medical device depends on its medical purpose, not simply the fact that it uses software or AI, operates in a healthcare setting or processes patient information.

Medical purpose is defined the Medical Devices Regulations 2002 (SI 2002/618, as amended), and includes:

  • diagnosis, prevention, monitoring, treatment or alleviation of disease; or
  • diagnosis, monitoring, treatment, alleviation of, or compensation for, injury or disability.

Many AVT products currently on the market are designed to transcribe consultations, generate draft clinical notes or support administrative workflows. According to the MHRA, these functions alone will not classify a product as a medical device as it does not serve a medical purpose.

The position changes where AVT software begins to analyse information and generate outputs used for a medical purpose. Examples include AVT products that provide diagnostic suggestions or treatment options, generate clinical insights or autonomously initiate follow-up actions. In these circumstances, the AVT software has a medical purpose and will classify as a medical device.

The guidance also highlights that product classification is not a one-off exercise. Software and AI systems are highly adaptable, and the addition of new functionality can alter a product’s regulatory status. Organisations should therefore reassess classification whenever significant new features are introduced.

Importantly, organisations cannot rely on a disclaimer stating that a product is ‘not intended for diagnosis’ if its functionality, design or marketing materials suggest otherwise. Medical purpose is assessed objectively by reference to labelling, instructions for use and promotional claims.

Lessons from the EU wristband decision

A recent judgment of the CJEU (Case C-427/24) confirmed the EU approach to classification when considering whether patient identification wristbands constituted medical devices.

The wristbands could be printed with patient information and barcodes and were promoted as helping to improve patient safety by reducing identification, medication and transfusion errors. Despite this, the court held that they were not medical devices.

The court distinguished between a product’s stated intended purpose and its medical purpose. Although the wristbands were used in healthcare environments, their actual function was administrative: identifying patients. As they did not diagnose, monitor, treat or prevent disease, nor did they directly influence clinical decision-making, the court concluded that the products did not have a medical purpose required by the EU MDR.

This judgment confirms that in the EU, neither a healthcare setting nor broad claims in an intended purpose about improving patient safety are sufficient, by themselves, to bring a product within medical devices regulation.

Practical takeaways

For software and AI developers in healthcare, the lessons are clear:

  • Define your intended purpose carefully.
  • Consider whether that intended purpose is, in fact, a medical purpose.
  • Ensure marketing claims, user documentation and product functionality are consistent with the intended purpose and any medical purpose.
  • Reassess classification when introducing functionality that supports diagnosis, treatment, monitoring or clinical decision-making.

Ultimately, both the MHRA guidance and the EU judgment reinforce the same principle: software does not become a medical device because it is used in healthcare. It becomes a medical device when it performs a medical purpose. Understanding that distinction early can help organisations avoid costly regulatory surprises as their products evolve.

This article was first published in Life Sciences Week magazine 2026.

Related expertise