The digital health market is expanding fast – IQVIA’s Digital Health Trends 2024 estimates there are roughly 337,000 health-related apps today. Behind that impressive number lies a worrying statistics: around 90% of startups never reach a market release, and of those that do, roughly 20% shut down within the first year. For developers and investors, this is a landscape full of hidden traps, where success depends not only on the strength of the idea but also on the ability to navigate dense regulatory filters.
One of the hardest questions is the boundary between wellness apps and software as a medical device (SaMD). In practice, that line remains blurry, while decisions about classification must be made as early as the planning stage. A mistake here can cost months of work and substantial financial losses.
What is complicating matters further is a tightening web of requirements – from GDPR to MDR/IVDR and the new EU AI Act. Understanding these frameworks is becoming an essential element of strategy for any developer working in digital health.
To make sense of where health app regulation is heading and how it shapes the industry, we held a webinar with Sigrid Berge van Rooijen – a Health-AI Consultant and Trainer focused on ethical implementation, patient safety, and regulatory alignment. What follows is a condensed, lightly edited version of that conversation, preserving the key ideas and practical takeaways from the discussion.
2Digital: Why is there such a gap between the sheer number of wellness apps and the relatively small pool of certified medical solutions? What keeps developers from going through certification?
Sigrid: There are hundreds of thousands of health-related apps worldwide, and many sit in a gray zone where they could, in theory, fall under the MDR. Not all are aimed at the EU market, of course, but quite a few could be classified as medical devices.
A lot of it comes down to choice. On the one hand, wellness developers decide for themselves whether to pursue medical-device certification. On the other hand, sometimes it’s simply a lack of awareness – not ignorance as such, but underestimating the complexity of the process. These days, anyone can build an app: “I’ll build something simpler, friendlier, faster.”
I’ve spoken with people who started building tools because of personal experiences – they were hospitalized and couldn’t follow what the doctor was saying. They created a tool to help themselves understand their diagnosis and treatment. Initially, it was just for personal use. But the moment you start sharing that tool to help others understand their disease or treatment options, you’re very quickly in medical-device territory.
2Digital: Developers often remain in the wellness category even when their products are, in essence, medical devices. Is that due to unawareness or a deliberate choice?
Sigrid: Partly choice. If developers don’t know the requirements, they simply won’t build a medical device. In reality, many existing apps could meet the definition, but the awareness element is missing.
At the same time, some companies consciously decide not to go that route because it’s harder: time to market is longer, and costs are higher. You invest heavily without knowing if you’ll make it to market at all. So yes, it’s a deliberate decision – and the reasons are a mix of factors.
2Digital: According to the Stanford AI Index 2025, registered AI-related issues in 2024 were 56% higher than in 2023. That’s not limited to healthcare, but our sector isn’t exempt – for example, a transcription tool that inserted fabricated content into medical transcripts. Since ChatGPT arrived, the market has been flooded with chatbots. Can we trust regulations like the AI Act to be “future-proof” and anticipate risks one or two years out?
Sigrid: I understand the question is about the AI Act, but take the MDR, which arrived earlier – parts of it already felt dated when it came into force.
Regulations do lag and don’t fully capture technological change. They’re not written exclusively by technologists who live and breathe the trends. Anticipating future risks is hard; the AI Act tries, but can we foresee all of them? I’m not sure.
Look at the AI Act’s “general-purpose” systems (GPAI). We have LLMs, ChatGPT. Base versions aren’t designed for clinical use. But “intended purpose” and real-world use are two different things.
If someone uses ChatGPT or another general LLM for mental-health support – and we’ve heard such stories – then strictly under the AI Act logic, that’s edging into “high risk.” Yet these models aren’t categorized that way because they’re general-purpose.
Another angle: users – especially on free tiers – click “Agree to the terms.” How many actually read them? Most terms say “not for medical use.” So you’ve acknowledged you’re using the tool outside its intended purpose. If something goes wrong, who is responsible?
Do we recognize the risks that could arise with health app regulation? That’s just one fresh example. What about developments just around the corner – say, agentic AI? Was that considered when drafting the AI Act?
2Digital: Let’s discuss a particular case that went viral recently: a “smart” ring’s battery swelled and got stuck on a tech blogger’s finger. It was removed without surgery, thankfully. The ring is not a medical device – it’s a wellness gadget. Could clinical studies or MDR-style requirements have changed the outcome if such checks had been required? And is it even realistic to test every device that way?
Sigrid: I suspect recommendations will indeed change – the precedent shows there’s a real risk. There were prior mentions that batteries in such rings can swell.
Under the MDR, you must conduct clinical evaluation, anticipate risks, report them, and mitigate them. So yes, I think things could have played out differently.
If the user had been in Europe, this might also touch on the EU Product Liability Directive, which focuses on defects and malfunctions.
Still, the risk posture is different. The MDR is much stricter – thanks to clinical evaluation, you at least understand device behavior before market entry. Consumer gadgets are different: they ship, and then we see what happens. So there’s a real difference in approach and in accountability.
Much also depends on the user manual. What usage limits and warnings were specified? Is flying with the ring addressed? In this case, the user had multiple flights in quick succession. Many people experience swelling in hands and feet when flying. Perhaps the manufacturer already knew air travel could matter. Under the MDR, with larger safety datasets, such a risk might have been identified earlier – though there are no guarantees.
2Digital: Can medical-device certification actually improve a product’s market resilience – via reimbursement and greater trust from clinicians and users?
Sigrid: We need newer reimbursement pathways, and Germany’s DiGA is ahead here. Other countries are moving in similar directions. That’s progress because there are just so many apps.
Insurers and clinicians struggle with what to recommend. And if they do recommend something, who pays? The health-system impact can be direct: clinician workload, patient volumes, and so on.
Reimbursement pathways help to clarify this. In many cases, they require MDR certification or some form of validation – at minimum, evidence of effectiveness and safety. Having those certificates makes choices easier for patients, clinicians, and payers: what to use, what to reimburse.
That’s especially important in the crowded wellness market. Which apps should be taken seriously? On the flip side, certification makes market entry costlier than for non-certified tools. Will “every passerby” be able to use such a tool, or does that create a barrier to adoption – and is that what we want?
That’s why DiGA-type schemes are interesting: they make clinically validated tools more accessible. More countries are exploring this – but much depends on system design. I’m from Norway – a fully public system without private reimbursement; the state pays.
I now live in the Netherlands – a mix of public funding and insurance. Some systems are fully insurance-based. Reimbursement design follows from that. I see real potential, but if each country has its own reimbursement checklist, it’s inefficient.
Imagine I have a wellness app and want reimbursement. Do I need separate approvals country by country? How much time and money does that take?
2Digital: On October 8, the UK’s MHRA announced they were moving into alignment with the FDA. There’s cautious optimism that “regulatory bridges” could become the norm. Is meaningful alignment between the EU, the UK, and the US actually possible?
Sigrid: It’s a positive step and could help, especially because many requirements are similar (not identical, but close). Even modest alignment that smooths market entry for startups and scale-ups would be welcome – right now, many teams are stretched thin and forced to choose markets.
If approvals in one market can open the door to others – that’s a big plus.
Another question: how to maintain quality if the FDA’s budget is cut? How do we avoid negative spillovers for devices entering the UK? If reduced resources mean more AI is used in reviewing submissions, will AI catch what humans catch? Will it be as discerning?
If we approve a product in the US and then, via a “cross-route,” in the UK, how does that affect the UK market and its standards? Alignment can’t just be about the rules; it also has to cover the review procedures themselves.
2Digital: A frequent developer mistake is to build for a broad consumer audience rather than for clinicians. It feels “safer,” but in practice, it often moves the product closer to SaMD. If you provide advice to lay users who can’t critically assess it, you’re elevating risk, and that needs to be taken seriously.
Sigrid: Exactly. Consider official public-health portals: they publish general information – on diabetes, weight loss, mental health – essentially national guidance. If an app merely relates to that kind of general, publicly available information – fine. But the moment you personalize advice – when the app starts addressing a specific individual – you have to ask whether you are now within the MDR’s scope.
2Digital: What counts as “representative data” under the EU AI Act for use in Europe and how can developers demonstrate it?
Sigrid: Representative data essentially means relevant data that reflects your target group.
Data should be as accurate and complete as possible to minimize bias – acknowledging the debate over whether truly “unbiased” datasets exist. The core is avoiding discriminatory bias and reflecting the real structure of the population you’re building for.
If you’re developing a breast-cancer diagnostic tool, your primary target is women (acknowledging that men can develop breast cancer). But your dataset should still reflect European diversity – ethnicity, age, geography, and so on.
As for demonstrating this, broadly you need to:
– Document data-collection processes;
– Describe sources and provenance;
– Show how you validated the data;
– Provide statistical analyses demonstrating that your sample reflects your target population – especially if you plan an EU rollout.
All of this should live within a data-governance framework that records how and why the data was collected and processed.
2Digital: So the logic is: there’s little value in repeating clinical trials country by country to re-prove what’s already been shown elsewhere. Startups just don’t have the resources for that many studies.
Sigrid: Right – but you can run a multicenter study: one trial, multiple countries and populations.
Take Iceland as an example – a highly homogeneous population. There’s a running joke about a dating app that checks whether you’re related to your date. Results based solely on Iceland are not representative of Europe. That doesn’t mean you exclude Iceland; include it – but ensure the overall sample reflects the broader population you aim to serve.
2Digital: Real-world data (RWD) isn’t the same as clinical-trial data, and it can’t simply replace it. Still, the momentum seems to be in the right direction.
Sigrid: RWD is powerful. People call it “messy,” “noisy,” “too large.” But clinical trials collect very limited datasets. RWD lets you see more: patient state, disease course, and how interventions work under real conditions rather than pristine protocols. In trials, participants come to a tightly run site; at home, life intrudes. So I wouldn’t underrate RWD or call it “less valuable.” As you note, there’s a shift – RWD is increasingly taken seriously.
2Digital: If a clinical study was conducted in a single region – say, in Asia – because costs were lower, can that block approval by a notified body in Europe?
Sigrid: If you can demonstrate that the data are relevant and transferable to another population – yes, it can be acceptable. But for the EU, you still have to justify applicability to European populations.
Using data generated outside the EU is possible, but a notified body will require evidence of transferability – why you believe the data reflect the characteristics of the group you want to serve.
And it’s not only population traits. If the device interacts with clinical practice, you have to show how it fits the target health-system context and whether conditions of use are comparable to those in Europe.
2Digital: When does an app become a medical device under the MDR? What exactly “triggers” it, and when does a notified body get involved at a high level?
Sigrid: It depends on intended use. If an app has a medical purpose, it becomes SaMD and falls under the MDR. Medical purposes include diagnosis, prevention, monitoring, treatment – in short, any function that influences a clinical decision.
My key test is: does the app influence a clinical decision by a clinician or a patient? If yes, you’re in MDR territory.
Take speech-to-text tools. Developers often say, “It’s administrative – we record the encounter and create a summary for the EHR. It doesn’t influence clinical decisions.” But look closer: the tool determines what goes into the note and what doesn’t.
If I’m the only clinician seeing this patient, perhaps I remember details. Six months later – or for my colleague picking up care – the clinical decision will depend on what the record contains.
So the tool does influence clinical decisions, albeit indirectly. It’s easy to say “we just store data,” “we’re like an EHR,” but if your app affects how a clinician or patient makes a medical decision, you’re under the MDR and a notified body will need to be involved.
2Digital: Requirements on data quality and bias control often overwhelm small teams. Are we regulating startups out of the market? Have we over-engineered the process when we could simplify?
Sigrid: I saw this debate on LinkedIn today. People ask: what could we remove? Safety? Quality management? Risk reduction? Every element is there for a reason.
But yes, when the MDR came in, who got approvals first? Big companies – they had resources, expertise, established processes. Startups didn’t; they struggled to bring products into compliance.
So the real question is how to smooth the way. Could we create a provisional approval for startups below a certain capital or market-size threshold? Faster entry, then structured post-market data collection, then full certification. Not “bending rules” but introducing a series of stages: provisional approval → evidence build-up → full MDR compliance.
I do think we’ve made life too hard for startups. That doesn’t mean compromising safety – never. It’s a delicate balance.
2Digital: What red and green flags do investors see when reviewing health and wellness apps?
Sigrid: A few thoughts. If an investor understands med-devices and healthcare, I hope these are obvious.
A green flag is a clearly defined medical purpose and stated intended use. If you recognize your product is medical and plan to pursue MDR, that’s a good sign. If there’s a medical purpose but no regulatory thinking, that’s a red flag.
Early regulatory awareness can spook investors – more cost, time, complexity. But if the team is serious and has mapped the steps ahead, that signals maturity. For wellness apps hovering at the edge of MDR, there’s no harm in adopting elements of quality management: document development, record risks, track data quality. That doesn’t take years, and it lays a foundation if the product pivots to medical.
So, data governance, transparent documentation, and a coherent development plan are unequivocal green flags.
2Digital: If you only had two due-diligence questions to separate signal from noise in a health-AI app, what would they be?
Sigrid: First, a clearly defined intended purpose – we’ve covered why that’s pivotal.
Second, the reliability and representativeness of the data used to validate the model: how diversity is ensured, how bias is controlled, and how data are monitored after deployment. Ultimately, it all comes back to data: how they’re collected and how you control them once the system is live.
