For developers, the challenge is not just any one of these frameworks. It is the fact that they overlap, interact, and in some cases contradict each other. This page covers what that regulatory environment looks like in practice, where the pressure points are, and where the opportunities sit for companies that navigate it well.
The Classification Problem That Has Not Been Solved
Whether software qualifies as a medical device under MDR depends on the manufacturer’s intended purpose. MDCG 2019-11 Rev.1 (updated June 2025) provides the qualification framework, and its revision introduced the term “Medical Device Artificial Intelligence” (MDAI) for the first time, along with expanded guidance on modular software and interoperability with Electronic Health Records under the European Health Data Space. But qualification is only the first question and classification is where often the real friction sits.
Rule 11 of MDR Annex VIII determines the risk class for software. Under the current text, software intended to provide information used to take decisions with diagnostic or therapeutic purposes is classified as Class IIa at minimum, escalating to Class IIb or III based on clinical severity. The practical result: most SaMD that makes any clinical claim ends up in Class IIa or above, requiring Notified Body involvement. The existence of genuine Class I medical device software under the current Rule 11 is debated within the regulatory community, and Notified Bodies tend to challenge Class I classifications when they encounter them.
The Commission’s December 2025 proposal (COM(2025) 1023) would rewrite Rule 11 so that software generally starts as Class I and is up-classified based on intended use in “serious” or “critical” clinical situations. On the surface, this is a fundamental shift. In practice, analysis by multiple regulatory groups suggests that the proposed wording may still result in most clinically relevant software being classified as Class IIa, because the terms “serious” and “critical” are not yet defined and the MDCG guidance would need to be updated to operationalise them. The proposal must pass through Parliament and Council before becoming law, a process unlikely to conclude before late 2026.
For developers building products now, the practical approach is to classify under the current Rule 11, document the rationale defensibly, and track the reform. If the revised Rule 11 eventually lowers your classification, you benefit. If it does not, you have not lost time.
Three Regulatory Frameworks But Just One Product
A software developer bringing an AI-powered clinical tool to the EU market in 2026 faces at least three regulatory layers. Understanding how they interact, and where they may simplify, is the difference between a workable development plan and one that stalls.
MDR: the device framework.
Classification, technical documentation per Annex II/III, IEC 62304 software lifecycle compliance, IEC 81001-5-1 cybersecurity, risk management per ISO 14971, usability per IEC 62366-1, and conformity assessment via a Notified Body for Class IIa and above. This is the core regulatory pathway and it applies regardless of whether the software uses AI.
EU AI Act: the AI overlay.
Under the EU AI Act (Regulation (EU) 2024/1689), AI systems that are medical devices requiring third-party conformity assessment under MDR are automatically classified as high-risk (Article 6(1)). Full high-risk obligations apply from 2 August 2027 for devices already on the market. For new products entering the market after that date, compliance is required immediately. Obligations include data governance, bias mitigation, transparency, human oversight, and post-market AI performance monitoring. MDCG 2025-6 (published June 2025) provides the first official guidance on how MDR/IVDR and the AI Act interact for MDAI systems. The Notified Body assesses both frameworks.
An important development: the Commission’s November 2025 Digital Omnibus proposal would move medical devices from Section A to Section B of the AI Act’s Annex I. If adopted, this would mean that most AI Act requirements would not apply to medical devices, on the basis that MDR already provides sufficient safety oversight. MedTech Europe has supported this direction, though some commentators argue the timeline may slip further, with full application potentially pushed to August 2028 or 2029. Until the Omnibus is adopted, the current AI Act framework stands.
National reimbursement: DiGA and beyond.
Germany’s DiGA programme remains the most established national reimbursement pathway for digital therapeutics in Europe. As of late 2025, 68 DiGAs were listed in the BfArM directory. Cumulative reimbursements reached €234 million by December 2024, with prescriptions rising from 41,000 in the first year to over 200,000 annually. The programme is evolving: from 2026, mandatory outcomes-based success measurement (AbEM) applies, with at least 20% of reimbursement contingent on demonstrated results. Eligibility is also expanding from Class I/IIa to include Class IIb devices.
Beyond Germany, France introduced its PECAN fast-track pathway in May 2023, and Belgium has had a staged approval process since April 2022. Austria is planning a DiGA-equivalent system as part of its E-Health Strategy 2024–2030, with implementation targeted for 2026. Finland launched a pilot for DTx reimbursement in November 2025. The landscape is fragmented, but the direction is clear: more European markets are building reimbursement pathways for digital health, and Germany’s model is the template most are following.
For developers targeting multiple European markets, the regulatory strategy must account for MDR compliance as the baseline, AI Act obligations as the overlay (where applicable), and national reimbursement requirements as the market access layer. Getting these aligned from the start avoids rebuilding evidence packages and documentation for each pathway separately.
Digital-Enabled Therapeutics: Where Pharma Meets Digital Health
A newer and increasingly important category sits at the intersection of pharmaceutical regulation and medical device software. Digital-Enabled Therapeutics (DETs) combine a medicinal product with medical device software to create an integrated therapeutic offering: apps that monitor adherence and optimise dosing for a specific drug, software that manages side effects alongside pharmacotherapy, or digital tools that address behavioural components of chronic conditions that the medicine alone does not reach.
In the EU, DETs fall under the drug-device combination framework: the medicinal product under Directive 2001/83/EC, the software component under MDR as MDSW. There is no unified EU framework equivalent to the FDA’s Prescription Drug Use-Related Software (PDURS) guidance. Each component follows its own regulatory pathway, and the clinical claim for the combined therapeutic effect must be supported by evidence that satisfies both frameworks.
The strategic interest for pharma companies is substantial. Patent expiries on established molecules put significant revenue at risk. Integrating MDSW can create new IP protection beyond active ingredient patent expiry, differentiate branded products against generics and biosimilars, support value-based pricing by demonstrating improved outcomes, and generate real-world evidence that strengthens payer and HTA positioning. The drug-software combination is a new product with its own regulatory identity, which can extend commercial life well beyond the original molecule’s exclusivity period.
The development challenge is that DETs require simultaneous expertise in pharmaceutical regulation, MDR compliance for MDSW, IEC 62304 software lifecycle, clinical validation of the combined therapeutic effect, and QMS integration across pharmaceutical GMP and device ISO 13485 requirements. For pharma companies that do not have device QMS infrastructure, we can act as legal manufacturer for the MDSW component through our ISO 13485-certified platform, while the pharma company retains the marketing authorisation for the drug. The regulatory tracks stay cleanly separated, with one team coordinating both. For the full regulatory pathway on combination products, see Combination Products.
What We Bring to Digital Health and SaMD
We have, officially and with dedicated teams, worked in medical device software regulation since 2009. Our software, digital health, and active medical device team includes regulatory, clinical, quality, and technical specialists who work specifically on SaMD, MDSW, AI/ML-enabled devices, and digital therapeutics. They sit alongside our medical device and IVD teams within the broader organisation, which means digital health clients have access to device regulatory, clinical development, pharmacovigilance, and quality expertise under one roof.
Three aspects of how we work are particularly relevant for digital health companies.
We handle the regulatory framework, you can focus on building the product.
We manage qualification, classification, IEC 62304 process design, cybersecurity documentation, AI Act assessment, Notified Body submissions, and post-market obligations. For companies that prefer not to take on MDR legal manufacturer responsibilities (with their ongoing PMS, vigilance, and NB obligations), we can act as legal manufacturer through our ISO 13485-certified platform. The developer retains control of the product; we hold the CE mark and the regulatory obligations.
Pharma and device expertise in one organisation.
For DETs and Connected Combined Products, the regulatory pathway spans pharmaceutical and device frameworks simultaneously. Our pharma regulatory, CMC, and clinical teams work alongside the software regulatory team on these programmes. One contract, one project lead, both regulatory tracks coordinated.
Global reach through regulanet®.
EU CE marking and DiGA listing are often the starting point, not the end. We coordinate FDA submissions (510(k), De Novo, and the predetermined change control plan framework for AI/ML devices), Health Canada licensing, TGA registration, and other international pathways through our global network.
Across the Development Journey
Discovery & Concept
Qualification: does the software qualify as a medical device (MDCG 2019-11)? If yes, classification under Rule 11 or IVDR Annex VIII. If AI/ML: preliminary AI Act risk classification. Intended purpose definition is critical and drives everything downstream. For DiGA: check BfArM eligibility.
Design & Development
IEC 62304 software lifecycle processes, software safety classification (Class A/B/C), risk management (ISO 14971), cybersecurity (IEC 81001-5-1), QMS (ISO 13485). For AI/ML: training data governance, model validation, bias assessment. Usability engineering (IEC 62366-1). This is where most of the compliance effort concentrates.
Clinical
Clinical evaluation: typically literature review, clinical experience data, and potentially clinical investigation. For DiGA: evidence of positive healthcare effect (pVE). For AI/ML: validation using independent datasets. For DETs: clinical validation of combined drug-software therapeutic effect.
Regulatory Submission & Approval
Technical documentation per MDR Annex II/III with software-specific content. NB conformity assessment for Class IIa+. For AI/ML: integrated AI Act documentation. CE marking. For DiGA: BfArM Fast-Track application. For international markets: FDA 510(k)/De Novo, Health Canada, TGA.
Launch & Market Access
EUDAMED registration (mandatory from May 2026). UDI assignment. For DiGA: listing in the BfArM directory enables prescription and reimbursement. For other European markets: reimbursement pathway varies significantly and should be assessed early.
Post-Market & Lifecycle Management
PMS, cybersecurity monitoring, software version management, change impact assessment against MDR significant change criteria. For AI/ML: ongoing model performance monitoring, bias drift detection, algorithm update documentation. Vigilance reporting for software-related incidents.
Example Projects
Clinical Decision Support SaMD: Qualification Through CE Marking
A health technology company developed a clinical decision support tool for chronic disease management. We conducted the qualification and classification analysis (Class IIa under Rule 11), designed an IEC 62304 lifecycle documentation framework compatible with their agile development process, prepared the clinical evaluation, built the cybersecurity file, and managed the Notified Body conformity assessment. CE marked on the first assessment cycle.
AI Diagnostic Imaging Tool: Dual MDR and EU AI Act Compliance
A medical AI company developing a tool for voice analysis needed an integrated regulatory strategy covering both MDR Class IIa requirements and EU AI Act high-risk obligations. We mapped the AI Act requirements against the existing MDR framework, developed an algorithm change management procedure for model retraining, created the post-market AI performance monitoring plan, and compiled the technical documentation addressing both frameworks. Currently in Notified Body review.
Digital-Enabled Therapeutic: Pharma Company Extending a Branded Product with MDSW
A pharma company sought to develop a software-enhanced version of an existing chronic disease medication, combining an adherence monitoring and dosing optimisation app with the marketed drug. We developed and introduced potential pathways to support the decision-making on management-level.
Developing Medical Device Software, Navigating SaMD Classification, Preparing for the EU AI Act, or Planning a DiGA Development?
Tell us about your software and where you are in development, and we will outline how we can help.
Speak with an ExpertFrequently Asked Questions (FAQ)
How do I know if my software qualifies as a medical device?
MDCG 2019-11 Rev.1 (June 2025) is the starting point. Software qualifies when the manufacturer's intended purpose includes diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease in individual patients. Software that only stores, displays, or communicates data without interpretation generally does not qualify. Document the rationale either way, because the qualification decision is one of the first things a Notified Body reviews.
Is there such a thing as Class I medical device software under the current MDR?
It is debated. The current Rule 11 classifies most software with clinical claims as Class IIa or above. The Commission's December 2025 proposal would nominally make Class I the default starting point, but analysis suggests the proposed wording may still push most clinically relevant software to Class IIa. Do not assume Class I without a defensible, documented analysis.
When does the EU AI Act apply to my software?
If your software uses AI/ML and requires Notified Body involvement under MDR (Class IIa or above), it is automatically high-risk under the AI Act. Full obligations apply from 2 August 2027 for devices already on the market. The November 2025 Digital Omnibus proposal would potentially push this to 2028 or 2029 and reduce AI Act applicability for medical devices, but that proposal is not yet adopted. Design for compliance now; if the timeline shifts, you benefit from being ahead.
What is changing with DiGA in 2026?
Three significant changes. First, mandatory outcomes-based success measurement (AbEM), with at least 20% of reimbursement price contingent on demonstrated results. Second, eligibility expanding to Class IIb devices. Third, updated data security requirements under BSI TR-03161. The DiGA programme continues to grow: 68 listed apps, €234 million in cumulative reimbursements, and over 860,000 prescriptions since launch.
What is a Digital-Enabled Therapeutic?
A DET combines a medicinal product with medical device software to create an integrated therapeutic offering. The drug is regulated under pharmaceutical law, the software under MDR as MDSW. There is no unified EU framework for this category (the FDA's PDURS guidance is further along). The strategic opportunity for pharma companies is significant: differentiation against generics, new IP protection, value-based pricing, and extended commercial life beyond patent expiry. Development requires simultaneous pharma and device regulatory expertise.
What if we do not have a device QMS?
You need one for MDR compliance. Building an ISO 13485 QMS from scratch for a single software product is rarely efficient. We can act as legal manufacturer, taking on the MDR obligations (CE marking, technical documentation, NB relationship, post-market surveillance) while you retain control of the product design and development. This model is used by health tech companies without device regulatory infrastructure and by pharma companies that need MDR coverage for their MDSW component.
Key Regulations & Guidance
The key regulatory frameworks and guidance documents that most directly shape digital health and SaMD work.