By Xisca Borrás, Partner – Life sciences regulatory and Ellie Handy, Senior Associate – Life sciences regulatory, Bristows

As femtech is intrinsically linked to health needs, a key question for femtech products is whether they are regulated as medical devices or merely consumer products.

Additionally, many femtech products are embracing the use of artificial intelligence (“AI”).

Therefore, another key question is whether products using AI will be regulated as “high-risk” AI systems under the EU’s new AI legal framework.

This article looks at when femtech apps and software qualify as medical devices in the EU and how the medical device and AI legal frameworks interact.

What is a software medical device?

The definition of “medical device” in the EU’s Medical Device Regulation 2017/745 (the “EU MDR”) includes software, used alone or in combination, that is intended by its legal manufacturer for a medical purpose.

These medical purposes are listed in the EU MDR and include (amongst others):

• diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease;
• diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability; and
• control or support of conception.

The legal manufacturer is the person that puts their name/branding on the device, and takes responsibility for it.

Whether software is considered a medical device will depend on whether the manufacturer states it has a medical purpose in the relevant documentation/materials.

The EU MDR defines intended purpose as “the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation” [emphasis added].

What is the test for qualifying as a medical device in the EU?

There is a selection of guidance documents that can assist you in determining whether a product should qualify as a medical device.

We summarise some of the key guidance below:

1. MDCG 2019-11 rev.1 

Under the EU MDR, the Medical Device Coordination Group (“MDCG”) has published guidance on the qualification and classification of software as a medical device.

It sets out five decision steps to help determine if a piece of software is a medical device in the EU. The steps are:

• Step 1: Is the product software?
• Step 2: Is it standalone software (e.,it is not an accessory nor driving/influencing the use of a hardware device) and does it not fall within Annex XVI^[1]?
• Step 3: Is it performing an action on data beyond storage, archival, communication, simple search or lossless compression?
• Step 4: Does it act for the benefit of an individual patient?
• Step 5: Does it have a medical purpose (as set out in the medical device definition)?

If the answer to all five questions is yes, it will qualify as a medical device.

In this case, manufacturers will have to ensure they comply with the pre-market requirements set out in the EU MDR before they can place the software medical device on the market.

Notably, they will need to set up a qualify management system, compile a technical file, undergo the appropriate conformity assessment and affix a CE mark.

Importantly, the manufacturers would also need to consider post-market requirements, such as having a post-market surveillance system and undertaking post-market vigilance.

3. Other relevant guidance

The MDCG has also published a Manual on borderline and classification of medical devices under the EU MDR.

Additional sources of guidance may also be available from national competent authorities.

The legal manufacturer could also look at examples of other products already on the market to see how they are regulated (e.g. looking at EUDAMED).

Although, we would caution anyone relying too heavily on the regulation of other products as there is no guarantee they are compliant.

What if you’re not a medical device?

If the software does not qualify as a medical device, the product will not have to comply with the EU MDR.

However, the manufacturer should be careful about how it promotes its product and the claims it makes about it because, as discussed above, a medical device is defined based on the manufacturer’s intended purpose.

Let’s take the example of a mere period app.

Using it for logging period dates, tracking ovulation, and predicting future cycles has no medical purpose and is therefore not a medical device.

However, if its manufacturer recommends this piece of software for contraception and/or to support conception it will suddenly have a medical purpose and so, it would qualify as a medical device.

As such, the manufacturer would either have to bring the device into conformity with the EU MDR or take action to change the promotional materials to remove the medical claims.

Interaction between medical devices and AI legal frameworks 

Under the EU MDR, devices are assigned risk classifications.

For the lowest risk devices (Class I medical devices), the manufacturer can self-certify compliance with the EU MDR prior to the product being placed on the market or put into service in the EU.

However, high risk devices (Class IIa or above medical devices) must undergo a third party conformity assessment carried out by a notified body.

Notified body conformity assessments require a detailed review of the manufacturer’s quality management system, technical documentation, systems and procedures.

The process will often take more than a year to complete.

Additionally, manufacturers have to grapple with ongoing burdens such as vigilance and post-market surveillance.

Under the EU MDR, most software as a medical device will be classified as a Class IIa or above.

Like the EU MDR, the EU’s Regulation (EU) 2024/1689 (the “AI Act”) also distinguishes between AI systems that pose different levels of risk.

The AI Act imposes onerous obligations on “high risk” AI systems, including in relation to accuracy, transparency, risk management, data quality and governance, and human oversight.

Although there is some overlap between the EU MDR and AI Act requirements, many are new AI-specific obligations.

These pose a significant additional regulatory burden, increasing the complexity and cost of compliance for stakeholders.

Notably, the risk classification of an AI system that is itself, or is included in, a medical device is linked to the device’s classification under the EU MDR. Under the AI Act, AI systems are classified as “high risk” systems if:

(a) the AI system is a safety component of a medical device or the AI system itself is a medical device; and 
(b) the medical device is required to undergo a third-party conformity assessment under the EU MDR.

Therefore, low risk medical devices (i.e., Class I medical devices) that are self-certified cannot be “high risk” AI systems.

Whereas, any device that requires a notified body to perform its conformity assessment will be a “high risk” AI system, and so will be subject to the additional AI Act requirements.

Unfortunately for those wishing to avoid the “high risk” AI system requirements, there are relatively few Class I devices under the EU MDR.

Therefore, the majority of medical devices that are an AI system or have an AI system as a safety component will qualify as a “high risk” AI system.

One notable example of a Class I device is software intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm.

If this kind of software medical device is also an AI system, it would not be classed as a “high risk” AI system, so it would not be subject to the more onerous requirements in the AI Act.

However, the manufacturers of these devices would need to carefully consider any product developments that add additional functionality, as this can impact the risk classification of the product under both the EU MDR and AI Act.

For example, if the manufacturer added functionality to the Class I device so it could also be used as a means of contraception, it would become a Class IIb medical device and would need a third party conformity assessment.

In turn, as the software is also an AI system, this would mean the AI system would be considered “high-risk” and be subject to additional regulatory requirements under the AI Act.

Whilst AI has the potential to provide tremendous benefits for femtech, it also triggers additional complexity that can be time-consuming and costly to navigate.

It is important to get it right in terms of compliance in order to maintain consumer trust, avoid regulatory penalties, and pave the way for long-term success and viability.