What This Page Covers
We support software and digital health developers across the full regulatory lifecycle, from qualification and classification through IEC 62304 compliance, clinical evaluation, Notified Body submission, and post-market surveillance, covering EU MDR/IVDR, the EU AI Act, UKCA, FDA, and global markets (via regulanet®).
This page covers software as a medical device (SaMD), medical device software (MDSW), AI/ML-enabled medical devices, digital therapeutics (DTx), and digital health applications including DiGA (Germany) and DiPA (Germany). It addresses both MDR-regulated and IVDR-regulated software products. For physical medical devices, see Medical Devices. For in vitro diagnostics that are not software-only, see In Vitro & Companion Diagnostics. For drug-device combination products, see Combination Products.
Visitors who previously worked with CE plus will find the same teams and expertise here. CE plus has been fully integrated into regenold, and all device, IVD, and software capabilities continue under the regenold brand.
Qualification Comes First
Before classification, before standards, before anything else: does the software qualify as a medical device? MDCG 2019-11 is the EU guidance document on this question. Software qualifies as a medical device when the manufacturer’s intended purpose includes diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease or injury in individual patients. The key word is “intended.” It is the manufacturer’s stated purpose that determines regulatory status, not the software’s technical capability.
Software that simply stores, communicates, or displays data without processing or interpreting it generally does not qualify. Software that provides information for general wellness or fitness purposes does not qualify. But software that analyses patient data and generates a clinical recommendation, a risk score, or a diagnostic output almost certainly does.
The boundary cases are where qualification disputes arise. Clinical decision support software that processes patient-specific data and provides a recommendation to a clinician typically qualifies. Software that provides general reference information (drug databases, clinical guidelines) typically does not. Software that drives or controls a hardware medical device is not classified as SaMD; it is a component of the device and regulated with it. Documenting the qualification rationale clearly at the start avoids problems later, especially at Notified Body review.
Classification Under MDR Rule 11
Once software qualifies as a medical device under MDR, classification follows Rule 11 (MDR Annex VIII). Rule 11 assigns software to classes based on the significance of the information it provides to the clinical decision:
- Software intended to provide information used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if those decisions could cause death or irreversible deterioration (Class III), serious deterioration (Class IIb), or relate to monitoring physiological processes where the nature of variations could result in immediate danger (Class IIb).
- All other software is classified as Class I.
The practical reality: most SaMD ends up in Class IIa or above. The existence and scope of genuine MDR Class I software is debated within the regulatory community. Some interpretations argue that if software makes any clinical claim at all, Rule 11 pushes it to at least Class IIa. Manufacturers should not assume Class I without a documented, defensible analysis. Notified Bodies will scrutinise this.
For software falling under IVDR (e.g., standalone diagnostic software), classification follows IVDR Annex VIII rules. Companion diagnostic software is Class C. Other diagnostic software classifications depend on the risk class of the information provided.
The Standards That Matter
Three standards form the core technical framework for medical device software:
IEC 62304 (software lifecycle processes)
This is the foundation. It defines requirements for the development and maintenance of medical device software, including software development planning, requirements analysis, architectural design, detailed design, unit implementation, integration and testing, and system testing. The level of rigour required scales with the software safety classification (Class A, B, or C under IEC 62304, which is separate from the MDR device classification). For Class C software, full documentation of every lifecycle activity is expected. Many software developers underestimate the documentation overhead, particularly if they come from an agile development background where written specifications are minimal.
IEC 82304-1 (health software products)
Applies to standalone health software products. Covers requirements for labelling, instructions for use, and the process for handling customer complaints and adverse event reporting.
IEC 62443 / MDCG 2019-16 (cybersecurity)
Cybersecurity is now a regulatory requirement, not an optional add-on. MDCG 2019-16 sets out expectations for pre-market and post-market cybersecurity management. Notified Bodies assess cybersecurity controls as part of the conformity assessment. Software that processes or transmits patient data must address data integrity, access control, encryption, vulnerability management, and software update mechanisms. The NIS2 Directive (applicable from October 2024) adds further obligations for manufacturers whose software is used by healthcare providers classified as essential or important entities.
All of this requires an ISO 13485-certified QMS. For companies that develop the software but do not want to take on the MDR legal manufacturer role (with its ongoing obligations around post-market surveillance, vigilance, and Notified Body relationship), we can act as legal manufacturer through our ISO 13485-certified platform. The software developer retains control of the product design and development; we hold the regulatory obligations and the CE mark.
The EU AI Act Overlay
AI/ML-enabled medical device software now faces dual regulation: MDR (or IVDR) and the EU AI Act (Regulation (EU) 2024/1689). The AI Act entered into force in August 2024, with high-risk AI obligations fully applying from August 2026.
The interaction works as follows: if the AI system is a medical device (or a safety component of one) and requires Notified Body involvement under MDR, it is automatically classified as high-risk under the AI Act (Article 6(1)). The Notified Body assesses compliance with both frameworks. The AI Act requirements can be integrated into the existing MDR technical documentation rather than maintained as a separate file, but the content requirements are additional: 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 medical device AI systems (“MDAI”). For manufacturers: the practical implication is that AI-specific requirements (training data documentation, model validation, performance monitoring, bias detection) must be built into the development and QMS processes from the start. Retrofitting AI Act compliance onto an existing CE-marked device will be significantly more difficult than designing it in.
For Class I SaMD that does not involve a Notified Body under MDR, the AI Act classification follows Annex III criteria separately. This creates a scenario where a device that is Class I under MDR could still be high-risk under the AI Act, requiring a separate conformity assessment for the AI component.
Software Combined with Medicinal Products
There is a growing category of products that combine medical device software with a medicinal product to create an integrated therapeutic offering. These are sometimes called Connected Combined Products (CCPs) or Digital-Enabled Therapeutics (DETs). Examples include apps that monitor adherence and optimise dosing for a specific drug, software that manages side effects alongside pharmacotherapy, or digital tools that address aspects of a disease that the medicine alone does not reach (e.g., behavioural components of chronic conditions).
In the EU, these products fall under the drug-device combination framework: the medicinal product is regulated under Directive 2001/83/EC, and the software component must meet MDR requirements as MDSW. The regulatory challenge is that there is no unified EU framework equivalent to the FDA’s Prescription Drug Use-Related Software (PDURS) guidance. Making clinical claims about the combined benefit requires expertise in both pharmaceutical and device regulation simultaneously.
For pharma companies, the strategic interest is significant: integrating MDSW can create new IP protection beyond active ingredient patent expiry, differentiate against generics and biosimilars, support value-based pricing, and generate real-world evidence that strengthens the product’s position with payers and HTA bodies. Pharma companies that prefer not to take on MDR obligations for the software component can use our legal manufacturer model for the MDSW while retaining the MA for the drug. We cover this topic in detail on our Combination Products page, including the regulatory pathways, development strategy, and practical examples.
What is Needed Across the Development Journey
Discovery & Concept
Qualification assessment: does the software qualify as a medical device under MDCG 2019-11? If yes, classification under MDR Rule 11 or IVDR Annex VIII. If AI/ML is involved, preliminary AI Act risk classification. Intended purpose definition (critical: this drives everything else). Identification of applicable standards (IEC 62304, IEC 82304, IEC 62443). For DiGA/DiPA: check BfArM eligibility criteria.
Design & Development
IEC 62304 software lifecycle documentation: development plan, requirements specification, architecture, detailed design, unit and integration testing. Software safety classification (IEC 62304 Class A/B/C). Risk management per ISO 14971 integrated into the development process. Cybersecurity risk assessment and controls. QMS per ISO 13485, with software-specific processes. For AI/ML: training data governance, model validation strategy, bias assessment, predetermined change control plan if applicable. Usability engineering per IEC 62366.
Clinical
Clinical evaluation: for SaMD, this typically relies on literature review, clinical experience data, and potentially a clinical investigation. The clinical evaluation must demonstrate that the software performs as intended and delivers the claimed clinical benefit. For AI/ML: validation using independent datasets not used in training. For DiGA: evidence of positive healthcare effect (pVE) required for permanent BfArM listing.
Regulatory Submission & Approval
Technical documentation per MDR Annex II/III, including software-specific documentation (IEC 62304 outputs, cybersecurity assessment, clinical evaluation report). Conformity assessment via Notified Body for Class IIa and above. For AI/ML: integrated AI Act documentation (data governance, model transparency, human oversight). Declaration of Conformity and CE marking. For UK: UKCA route. For US: FDA pathway (510(k), De Novo, or PMA; FDA’s predetermined change control plan framework for AI/ML devices). For DiGA: BfArM Fast-Track application.
Launch & Market Access
EUDAMED registration (mandatory from May 2026). UDI assignment. Labelling and IFU per MDR/IVDR. For DiGA: listing in the BfArM DiGA directory enables reimbursement through statutory health insurance in Germany. For other markets: reimbursement pathway varies significantly and should be assessed early.
Post-Market & Lifecycle Management
PMS Plan, PMCF/PMPF, PSURs as applicable. Cybersecurity monitoring and patch management. For AI/ML: ongoing model performance monitoring, bias drift detection, and documentation of any model updates. Software version management and change impact assessment against MDR significant change criteria. Vigilance reporting for software-related incidents.
Example Projects
Clinical Decision Support SaMD: MDR Class IIa CE Marking
A health tech company developed a clinical decision support tool that analyses patient data to generate treatment recommendations for chronic disease management. We conducted the qualification and classification analysis, supported IEC 62304 lifecycle documentation, prepared the clinical evaluation based on literature and real-world evidence, and managed the Notified Body conformity assessment. CE marked under MDR on the first assessment cycle.
AI-enabled Diagnostic Software: Dual MDR and AI Act Compliance
A start-up developed an AI-powered imaging analysis tool for radiology. We supported the integrated regulatory strategy covering both MDR Class IIb requirements and EU AI Act high-risk obligations: training data governance documentation, model validation with independent datasets, bias assessment, cybersecurity controls, and technical documentation that satisfied both frameworks. Currently in Notified Body review.
DiGA Fast-Track Listing
A digital therapeutics company developed a prescription app for a mental health indication and sought BfArM DiGA listing for reimbursement in Germany. We supported the application including evidence of positive healthcare effect, data protection assessment, interoperability requirements, and the fast-track process. Provisional listing achieved within the BfArM target timeline.
Developing or Certifying Medical Device Software?
Tell us about your software, its intended purpose, and your target markets. We will assess the regulatory pathway and outline how we can support.
Speak with an ExpertFrequently Asked Questions (FAQ)
How do I know if my software qualifies as a medical device?
MDCG 2019-11 is the starting point. If the intended purpose includes diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease or injury in individual patients, it likely qualifies. Software that only stores, displays, or communicates data without interpretation generally does not. Document the rationale either way.
Is there such a thing as MDR Class I software?
It is debated. Rule 11 classifies most software that makes clinical claims as Class IIa or above. Some software with limited clinical significance may qualify as Class I, but the boundaries are not clearly defined and Notified Bodies tend to challenge Class I classifications. Do not assume it without a defensible analysis.
How does the EU AI Act affect my medical device software?
If the software uses AI/ML and requires Notified Body involvement under MDR (Class IIa or above), it is automatically high-risk under the AI Act. High-risk obligations apply from August 2026 for new products (August 2027 for devices already on the market). The Notified Body assesses both frameworks. Additional requirements cover data governance, bias mitigation, transparency, human oversight, and ongoing AI performance monitoring. MDCG 2025-6 clarifies the interaction. Start now; August 2026 is not far away.
What is IEC 62304 and why does it matter?
IEC 62304 defines the software lifecycle processes required for medical device software. It covers planning, requirements, design, implementation, testing, release, and maintenance. The documentation depth scales with the software safety class (A, B, or C). Notified Bodies expect full IEC 62304 compliance in the technical documentation. Developers coming from agile backgrounds often underestimate the documentation requirements.
What is a DiGA?
A DiGA (Digitale Gesundheitsanwendung) is a CE-marked, low-risk (Class I or IIa) digital health application listed in the BfArM DiGA directory in Germany. Listing enables prescription and reimbursement through statutory health insurance. The application process requires evidence of a positive healthcare effect (pVE), data protection compliance (including data processing within the EU/EEA), and interoperability. It is one of the few established national reimbursement pathways for digital therapeutics in Europe.
Do we need separate submissions for EU and US?
Yes. The EU follows MDR/IVDR with Notified Body conformity assessment. The US follows FDA pathways: 510(k), De Novo, or PMA depending on the device. FDA has its own SaMD framework and has introduced a predetermined change control plan (PCCP) mechanism for AI/ML-based devices that allows pre-approved modifications without new submissions. We coordinate parallel programmes to maximise documentation reuse.
What if we don't have a device QMS?
For co-packaged products and CCPs, the device or software component needs its own legal manufacturer under MDR with an ISO 13485-certified QMS. Pharma companies often don't have this, and building one from scratch for a single device component is rarely efficient. We can act as legal manufacturer for the device or MDSW component, taking on the MDR obligations (CE marking, technical documentation, Notified Body relationship, post-market surveillance) while the pharma company focuses on the MA for the drug. This model keeps the two regulatory tracks cleanly separated. For integral DDCs, the situation is different: there is no separate device LM role, and the pharma company must address device requirements within their pharmaceutical QMS.