By Martin Piria, senior machine learning engineer at Ema

Search has changed.

For years, Women’s Health companies have invested in SEO, optimising their websites so Google would surface their content.

But now, as consumers increasingly ask health questions directly to AI like ChatGPT, Perplexity, Ema, or Claude, a new frontier is emerging for brands that want to market their women’s health product or service: Generative Engine Optimization (GEO).

Here’s how women’s health brands should think about GEO today.

GEO ≠ SEO — But They Overlap

Think of it like this:

• Google vs Bing: Searching on Bing doesn’t influence what you see on Google.
• LLMs vs Search: Similarly, what OpenAI scrapes to train its models isn’t connected to how Anthropic’s model is built. Each AI has its own training architecture and knowledge base.

SEO remains critical because most grounding searches still pull from Google.

But GEO adds a new layer: how your content is scraped, stored, and tokenized by large language models.

What LLMs “Love”

LLMs aren’t people. They’re statistical machines predicting the next token. To show up inside them, your content needs to be:

• LLM-friendly HTML: Clean, semantic code that models can parse.
• Fact highlights: Clear, authoritative statements that models can confidently repeat.
• Structured links & references: High-authority citations that reinforce your credibility.
• Accessible APIs: Easy integrations for platforms like Bing, Perplexity, or Google’s SGE.

You need to learn which tokens trigger what generations in the LLM.

Tokens that the model has well-modeled won’t go to the web. You want tokens where the model has low confidence, and you want to be the first hit when it grounds the answer.

How to Spot “Weak Tokens”

Weak tokens are concepts or queries where the model has low confidence and goes searching the web for reinforcement. That’s your opportunity.

If your Women’s Health company creates the most authoritative, well-structured page on that concept, you become the go-to reference.

Pro tip: Ask ChatGPT (or another LLM) to generate an answer in your space, then look for where it hesitates, says “I don’t know,” or provides shallow coverage.

Those are your GEO goldmines.

Action Steps for Women’s Health Brands

• Keep building SEO: Traditional search still drives discovery and traffic.
• Audit your content for LLM-friendliness: Is your HTML semantic? Are facts highlighted clearly? Do you have structured data?
• Target underserved queries: Use AI tools to test what’s missing from LLM answers in your domain.
• Be the first grounding result: For low-confidence tokens, make sure you’re the top hit on Bing, Perplexity, and Google.
• Think prevention-first: Just as we design Ema to prioritize safety and clarity, your content should be structured, factual, and easy to cite.

Resources to Go Deeper

• GPT-3 Linguistics 101 (Medium) — a great breakdown of how tokens and vocabularies work in LLMs.
• Research from AI marketing leaders on Generative Engine Optimization (GEO).
• Technical guides on schema markup and structured data for SEO, which often doubles as LLM-friendly content.

The Bottom Line for Women’s Health

• Clarity + authority = visibility. The more accessible and trustworthy your content, the more likely LLMs will surface it.
• Your opportunity: Make your Women’s Health brand the voice that AI turns to when women ask critical questions. SEO found you on Google. GEO will get you found inside the conversations that matter next.

Find out more about Ema at emaapp.co 

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.

By Xisca Borrás and Ellie Handy of the life sciences regulatory department at Bristows law firm

Femtech, short for female technology, is an important and fast growing sector. The EU is a key market for femtech, with five of the top 10 countries for femtech investment located in the EU.

Femtech products are developed for many areas of women’s health, such as menstrual health, pregnancy planning and monitoring, menopause and mental wellbeing.

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”.

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 (i.e., it is not an accessory nor driving/influencing the use of a hardware device) and does it not fall within Annex XVI?
• 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.

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