Learnings from Frontiers Health 2026

This year’s Frontiers Health took place at the bcc Berlin Congress Center on 20–21 October. It was my 11th time at the event. And, as usual, it was great because of the people, the chats and the stories.

Frontiers Health always attracts the real innovators and first movers in digital health (kudos to the organisers). That makes it the perfect place to take the pulse of the industry. And every year, a new compliance hot topic emerges from the corridor conversations.

Here is what I heard over two busy days, and what it means if you are building a digital health startup.

TL;DR: key takeaways from Frontiers Health 2026

• AI is the baseline, not the innovation. Digital health startups now build on AI from day one, so AI Act and GDPR planning must start on day one too.
• On-prem AI agents are replacing traditional anonymisation techniques. They outperform k-anonymity and differential privacy on unstructured data, but their non-deterministic output is hard to prove compliant.
• “How do we avoid MDR?” was the top compliance question. Avoiding the EU Medical Device Regulation is often smart, but the better strategy is to push MDR back until you are ready, because certification can become a competitive moat.

AI is no longer innovative. It’s the starting point

One lesson stood out above all others. AI is no longer viewed as innovative. It’s the baseline.

A couple of years ago, founders were still debating whether to use AI at all. At this year’s event, nobody asked “should we use AI?”. AI is simply taken for granted. And so is the need to tackle the AI Act.

That is a big shift. It means compliance is no longer a question you can park until “the AI part” is ready. If AI sits at the core of your product from day one, your data protection and AI Act strategy needs to be there from day one too.

The good news? Founders are getting much more pragmatic. The conversations I had weren’t about whether AI is legal. They were about how to deploy it in the real world, inside hospitals and pharma companies. Which brings me to the first big topic.

On-prem agents for optimisation and anonymisation

People are building great solutions and already deploying them in hospitals and pharma. The common pattern? On-premise agentic workflows that do two jobs:

• Optimisation. Agents that streamline clinical and operational workflows and save staff time.
• Anonymisation. Agents that strip personal data out of records so the data can be reused.

The anonymisation part is the most interesting to me. In practice, these agents act as a substitute for the whole toolbox of anonymisation techniques we have relied on for years: differential privacy, k-anonymity, l-diversity and so on.

On one side, they are much better than anything we used before. They understand context. They catch the identifying detail buried in a free-text clinical note that a rule-based algorithm would miss.

On the other side, they are non-deterministic. Run the same record through twice and you may get two different outputs. That makes them hard to inspect, hard to assess and hard to guarantee.

And that matters, because under GDPR anonymisation is binary. Either the data is anonymous and falls outside the regulation, or it is not and every obligation still applies. If you can’t demonstrate that your agent anonymises reliably, a hospital DPO or an ethics committee will treat the output as personal data. Which defeats the whole point.

Here is how the two approaches compare:

‍

My advice: if you are building in this space, plan how you will prove your anonymisation works, not just how to build it. Think testing protocols, re-identification risk assessments and clear documentation in your DPIA. That is what will get you through procurement.

“How do we avoid MDR?”

This was the question I heard over and over again. And it’s a really interesting and complex one.

The issue is that iterative product improvements can suddenly turn your app into a medical device. It usually happens like this:

1. You build an AI tool to improve workflows and save clinicians time.
2. The product gets smarter and starts supporting clinical decisions.
3. Suddenly, you have crossed the threshold and you are a medical device under the Medical Device Regulation (MDR).

Nobody sets out to build a medical device by accident. But each sprint adds a feature that seems harmless on its own. A suggestion here, a risk score there. Then one day your intended purpose looks very different from the one you started with.

So where exactly is the line? The EU guidance on software under MDR (MDCG 2019-11 Rev.1, June 2025) hinges on your intended purpose: what you claim the software does, not how it works. Here are the typical signals:

If your roadmap moves features from the left column to the right, you are on your way to becoming a medical device.

Crossing that line means certification, clinical evidence, notified bodies and stricter data requirements. That is months (even years) of extra work and a big hit to your budget and roadmap. And for a startup planning its runway around the next funding round, that can be fatal.

So, many founders now design their products around one goal: stay out of MDR at all costs.

Don’t avoid MDR at all costs. Push it back until you’re ready

Here is my hot take: avoiding MDR is often the right strategy. But my question back to founders was “Why do you actually want to avoid MDR?”

Yes, MDR is expensive and time consuming. But it can also open a lot of doors.

Sometimes MDR is a blocker. But sometimes it’s the moat that keeps your competitors out. Hospitals are more likely to award a contract to a certified product, because they know you had to prove its efficacy and safety. The same logic applies to reimbursement schemes like DiGA in Germany or PECAN in France. Certification is the price of entry, and your uncertified competitors can’t pay it overnight.

So, the strategy shouldn’t be “avoid MDR at all costs”. It should be “push back MDR until you are ready”. In practice, that means:

• Define your intended purpose deliberately. It’s what decides whether you are a medical device, so write it down and keep your product, marketing and sales claims aligned with it.
• Review every new feature against that threshold. Make it part of your product process, not an afterthought when a hospital asks for your CE mark.
• Build compliance foundations now. Solid GDPR, security and ISO 27001 practices will make an eventual MDR certification much faster. You won’t be starting from zero.
• Decide on MDR as a business choice. Go for it when the market, your customers or your investors make it worth the cost, not when an accidental feature forces your hand.

Playing the grey area correctly is possible. But you need to learn a lot to do it well, because the line between a workflow tool and a medical device is thinner than most founders think.

Final thoughts

So, what were my conclusions after two days in Berlin? Let me summarise them:

1. AI is now the starting point in digital health, not the innovation. That makes the AI Act part of day-one planning, not a later problem.
2. On-prem agents are changing the anonymisation game. They outperform traditional techniques, but you need to be able to prove they work, or hospitals and ethics committees won’t accept the output.
3. MDR is the new compliance hot topic. Avoiding it is often smart, but treat it as a strategic decision. Push it back until you are ready, and keep in mind that certification can become your moat.

Frequently asked questions

When and where was Frontiers Health 2026?

Frontiers Health 2026 took place on 20–21 October 2026 at the bcc Berlin Congress Center in Berlin, Germany. It is one of Europe’s leading events for digital health innovators, investors and industry leaders.

When does a digital health app become a medical device under MDR?

An app becomes a medical device when its intended purpose is medical, for example supporting diagnosis or treatment decisions for individual patients. Workflow features like scheduling or documentation usually are not. The risk is that iterative improvements, such as adding risk scores or clinical suggestions, can push a product over the line.

Should startups avoid MDR certification?

Avoiding MDR is often the right short-term strategy, because certification takes months or years and needs clinical evidence. But it shouldn’t be “avoid at all costs”. MDR certification can become a moat: hospitals and reimbursement schemes such as DiGA favour certified products.

Can AI agents anonymise health data under GDPR?

AI agents can anonymise health data effectively, especially unstructured text. But GDPR treats data as anonymous only if individuals can no longer be identified. Because agents are non-deterministic, you need testing, documented error rates and a re-identification risk assessment to prove the output is anonymous.

Does the AI Act apply to digital health startups?

Yes, if you develop or deploy AI systems in the EU. AI that is, or is part of, a medical device needing a notified body assessment under MDR is classed as high-risk under the AI Act, which adds further obligations. That is another reason to plan your MDR strategy early.

Need help figuring it out? We’re here to help!

Chino.io is the one-stop shop for solving all privacy and security compliance aspects. We have supported 200+ companies to pass audits and get reimbursed.

We combine an expert team with an AI-powered platform, so you get clear guidelines for your developers, predictable costs and a roadmap anyone can understand. Whether you need a DPO with real digital health experience, a DPIA that will survive an ethics committee review, or a compliance foundation that keeps your MDR options open, we can help.

Book a call with our experts to find out where you stand.

‍