Regulatory Guide to Medical Software Compliance in the EU and UK

When launching clinical software in the EU or UK, medical software compliance should be a top priority. It’s not just about creating a great digital health product. Understanding safety regulations is key to getting your solution to market and protecting patients.

As digital health tools take on a bigger role in diagnosis, treatment, and patient care, regulators have introduced strict rules to ensure quality and reliability. If your software supports clinical decisions, such as diagnosing conditions, monitoring patients, or managing treatments, it will likely be classified as a medical device.

That classification comes with specific legal requirements under the EU Medical Devices Regulation (MDR 2017/745)and the UK Medical Devices Regulations 2002. Understanding these requirements early helps you avoid delays and ensures your software is ready for distribution and use.

This guide walks you through each critical step. From CE or UKCA marking to technical documentation, labelling, registration, and post-market responsibilities, it gives you the clarity you need to launch with confidence.

Ebook

EU/UK Guide for Medical Software Compliance

A helpful guide providing a comprehensive overview of EU and UK compliance for Medical Software.

Download

Understanding Safety Regulations for Medical Software in the EU and UK

Is Your Software a Medical Device?

If your application helps with diagnosis, supports clinical decisions, or is used for planning treatment, it likely qualifies as a medical device. This is true even when there’s no physical hardware involved. Software used on its own in a medical context is still regulated under:

• EU MDR 2017/745
• UK MDR 2002(UK law derived from the earlier EU directives)

The classification affects how strict your medical software compliance process needs to be. Under Rule 11 of the EU MDR, most clinical software is placed in Class IIa or higher, especially if it impacts diagnosis or treatment decisions. In these cases, a third-party review is usually required. If the software poses minimal risk, it may fall under Class I, which allows for self-certification instead. The EU’s updated guidance on software qualification and classification, MDCG 2019-11 Rev.1 (June 2025), gives worked examples and should be your first reference.

Classification can also differ between markets. The UK MDR 2002 has no equivalent of Rule 11, so software that is Class IIa or higher in the EU may still be Class I in Great Britain. Classify your software separately for each market.

Before anything else, determine:

• Is the software a medical device?
• What is its intended use and risk classification?
• Will you need a Notified Body (EU) or Approved Body (UK)?
• Are you based within the EU/UK, or will you need a local representative?

These decisions form the foundation for your compliance strategy.

CE Marking for Medical Software: Compliance for the European Union

If you’re marketing your software in the EU, your product must carry the CE mark, signifying full conformity with MDR requirements. It’s a legal declaration that your product meets safety, performance, and quality standards.

Core Requirements for CE Marking

1. Medical Device Classification (MDR Rule 11)Most software with clinical functions will be classified as Class IIa or higher. This classification is important because it defines your compliance path. It determines whether you can self-certify or need to involve a Notified Body for assessment.
2. Conformity Assessment
   • Class I software(very low risk) may self-certify by compiling the technical file and signing a Declaration of Conformity.
   • Class IIa, IIb, or III softwaremust undergo formal review by a Notified Body, which will evaluate the software’s technical documentation, risk controls, and quality systems. If successful, a CE certificate is issued.
3. EU Declaration of ConformityThis is a legally binding document signed by the manufacturer. It confirms that the software meets the MDR and any other relevant EU legislation, and it must include the device’s Basic UDI-DI. As part of your safety regulations for medical software process, the EU DoC must reference applicable laws and harmonised standards. It should also include product identifiers and details about the manufacturer.
4. Appointing an EU Authorised Representative(for non-EU companies)If your company is based outside the EU, you’ll need to appoint an EU Authorised Representative (EU AR) for safety regulations for medical software compliance. This representative acts as your local point of contact and manages regulatory communications. They must be located within the EU, appointed under a written mandate (MDR Article 11), and listed on your product labelling.
5. EUDAMED RegistrationManufacturers (or their EU AR) must register in EUDAMED, the EU’s central database. Registration requires:
   • An “actor” registration and Single Registration Number (SRN)
   • Product details, including the Basic UDI-DI and UDI-DI
   • The correct European Medical Device Nomenclature (EMDN) code
6. Since 28 May 2026, four EUDAMED modules have been mandatory: actor registration, UDI/device registration, notified bodies and certificates, and market surveillance. New devices must be registered before they are placed on the market. Devices already on the market before that date must be registered no later than 12 months after the Commission’s notice was published in the Official Journal in November 2025, which falls in late November 2026.

These steps are not one-time events. Compliance must be maintained post-market, with ongoing surveillance, updates, and documentation.

UK Compliance for Medical Software: MHRA Registration and UKCA Marking

Since Brexit, the UK has established its own regulatory system for medical devices, separate from the EU. If you plan to market medical software in Great Britain (England, Scotland, or Wales), you’ll need to follow the UK Medical Device Regulations 2002. You must also register your product with the MHRA (Medicines and Healthcare products Regulatory Agency).

Regulatory Overview

The UK’s system is similar to the EU’s in many ways, but there are key differences. These include how products are marked, the timelines for registration, and the roles of authorised representatives. CE marking is still accepted in Great Britain. On 21 October 2026 the government confirmed that it will accept CE-marked medical devices on a long-term basis, following a consultation that ran from 16 February to 10 April 2026. This means devices already approved for the EU market will not need an additional approval route. The end dates in the current MHRA guidance (30 June 2028 and 30 June 2030) had not yet been updated when this guide was checked, so confirm the position before you plan.

MHRA Registration

Before a medical device can be sold in Great Britain, it must be registered with the MHRA. This involves:

• Submitting product and manufacturer details through the MHRA portal
• Providing documentation including the Declaration of Conformity and relevant conformity assessment certificates
• Paying any registration fee that applies

This requirement applies to all classes of devices, including software. The registration must be completed before the product is placed on the market.

The Role of the UK Responsible Person (UKRP)

If you’re based outside the UK, you must appoint a UK Responsible Person. This individual or organisation:

• Submits the MHRA registration on your behalf
• Ensures the product’s technical documentation and declaration are in place
• Communicates with the MHRA on regulatory matters
• Must be named on your product labelling or digital IFU when UKCA marking applies

Much like an EU Authorised Representative, the UKRP plays a critical role in enabling foreign manufacturers to access the UK market legally.

UKCA Marking for Medical Software Compliance

The UKCA mark is the UK’s equivalent to the CE mark. Although it became available from January 2021, the UK government has allowed a transition period:

• Software CE-marked under the EU MDR can be placed on the GB market until 30 June 2030
• Software CE-marked under the older MDD can be placed on the market until 30 June 2028 (or until its certificate expires, if earlier)
• On 21 October 2026 the government confirmed it will accept CE-marked devices on a long-term basis. Check GOV.UK for the legislation and dates that give effect to this

UKCA Conformity Assessment

UKCA compliance follows the legacy structure of EU directives (MDD/AIMDD), pending the UK’s full regulatory update. Manufacturers can:

• Self-certify for non-sterile, non-measuring Class I devices
• Engage a UK Approved Body for higher-risk devices (Class IIa and above)

If you already hold a valid CE certificate, it can serve as a foundation for UKCA assessment. The UK is also moving towards relying on other regulators: the draft Medical Devices (Amendment) Regulations 2026, published in May 2026, introduce an International Reliance pathway and a Predetermined Change Control Plan (PCCP) route for software updates. Most provisions are expected to apply from around June 2027, but this is not confirmed and depends on Parliament.

Registration Specifics and Timelines

During MHRA registration, manufacturers (or their UKRP) must provide:

• Device classification and intended use
• The correct GMDN (Global Medical Device Nomenclature) code
• A valid Declaration of Conformity
• Conformity assessment certificates (if applicable)

Keep in mind that failure to register means your product cannot legally be marketed in Great Britain.

A Note on Northern Ireland

Northern Ireland follows a different set of rules under the EU-UK Withdrawal Agreement. Medical devices placed on the market there must still comply with the EU MDR and carry the CE mark. If a UK-based body is used for certification, the product must also include the UK(NI) marking.

Technical Documentation & Compliance File

Whether you’re working toward CE or UKCA marking as part of your medical software compliance, both regulatory systems require detailed technical documentation. This documentation must show that your software is safe, effective, and meets all compliance requirements.

What Goes into a Technical File?

Your technical file should be clear, complete, and organised to support both initial assessments and ongoing regulatory needs. It typically includes:

• Device description: Overview of your software’s intended purpose, user profile, and clinical function. Screenshots or architecture diagrams help clarify usage.
• Product specifications: Performance features, software requirements, and operational constraints.
• Development lifecycle documentation: Version history, update strategies, and development environment.
• Risk management: A formal risk assessment following ISO 14971, detailing known hazards, mitigations, and verification that residual risks are acceptable.
• Design verification and validation: Documentation of test results, clinical evaluations, cybersecurity testing, and usability studies.
• Software architecture: Diagrams, algorithm summaries (especially if AI/ML is involved), and lifecycle compliance evidence per IEC 62304.
• Labelling and user interface: Copies of all labels, UI screens showing conformity information, and your digital Instructions for Use (IFU).
• GSPR checklist: For EU submissions, a table mapping your device’s compliance with the General Safety and Performance Requirements.
• Declarations of Conformity: One for each jurisdiction (EU/UK), referencing the applicable regulations and signed by a responsible party.
• Conformity certificates: Issued by your Notified Body (CE) or UK Approved Body (UKCA), if your software is Class IIa or higher.

Post-Market and Supporting Materials

In addition to the core file, authorities often request:

• Post-market surveillance plans
• Vigilance procedures
• Incident histories(if the product is already in use elsewhere)
• Written mandate (EU AR) and letter of designation (UKRP)

All documentation must be available on request. Notified Bodies, Approved Bodies, and authorities like the MHRA may audit your files at any time.

Labelling Requirements for Software-Only Medical Devices

Even if your medical software doesn’t come with physical packaging or hardware, proper labelling is still required. It must meet EU and UK safety standards and clearly communicate important safety and regulatory information to both users and authorities. These requirements apply to all software-only medical devices, whatever their class, under the EU MDR and UK MDR.

Key Labelling Elements

Whether presented in an app interface, a web dashboard, or a PDF, your labelling must include:

• Product name and version
• Manufacturer’s name and address
• Intended use and target users
• Unique Device Identifier (UDI): required for all classes in the EU, shown in plain text in an easily accessible place such as the “About” screen or start-up screen
• CE or UKCA mark, depending on the market
• EU AR or UKRP contact information (if applicable)

This information may appear on:

• Splash screens
• Digital IFUs
• App store descriptions
• Downloadable documentation

If your software is distributed digitally, there’s no need for physical labels. However, be sure to keep digital versions consistent with your regulatory submissions.

Electronic instructions for use (eIFU) are permitted for software under Implementing Regulation (EU) 2021/2226, as amended by Regulation (EU) 2025/1234. Under the UDI rules, a new UDI-DI is needed whenever a software change affects the original performance, safety, intended use or data interpretation. Minor revisions only need a new UDI-PI.

Special Labelling Considerations

• Sterilisation or storage infois not required unless your software ships on a physical medium used in sterile environments.
• MRI safetylabels apply only if your software is intended for use near or with MRI-compatible hardware. If not applicable, clarify this in your IFU (e.g., “This device is not intended for use in MRI environments.”).
• Warnings and precautionsmust be included where relevant. For example, a tool supporting clinical decisions should state it is not a substitute for medical judgment.
• Language requirementsvary by region. Your IFU must be provided in the official language(s) of each country where the software is sold.

Best Practices

Avoid cluttering your digital IFU with unnecessary symbols. Focus on clarity and user understanding. The goal is to satisfy legal requirements while ensuring healthcare professionals know how to use the software safely.

Device Classification: GMDN and EMDN Codes

Correctly classifying your medical software using recognised device nomenclature is an important step in both EU and UK compliance. This is where GMDN and EMDN codes come in.

What Are GMDN and EMDN Codes?

• GMDN (Global Medical Device Nomenclature)is used by theMHRAand many international regulators. It assigns a five-digit code to a generic device category, such as “clinical decision-support software” or “patient monitoring application.”
• EMDN (European Medical Device Nomenclature)is required for EUEUDAMEDsubmissions. Based on Italy’s CND system, it performs a similar function to GMDN but follows a different structure.

Why These Codes Matter

These codes are required for registration and classification. They help authorities:

• Understand what your product is and how it functions
• Place it in the appropriate regulatory category
• Track it accurately across national and international databases

If the wrong code is used, or if one is left out entirely, it can cause delays or lead to regulatory pushback. The MHRA will reject your registration if you don’t include a valid GMDN code.

Common Challenges

Innovative, niche, or borderline software products often don’t fit easily into existing categories. In these situations, choosing the right GMDN code means carefully reviewing your software’s:

• Intended medical use
• Functional capabilities
• Algorithmic logic (e.g. for AI/ML-based tools)
• Clinical context and user group

If a product is designed for aesthetic or wellness use but has a borderline medical purpose, classification becomes especially sensitive. Using the wrong term could lead to stricter regulatory requirements. In some cases, it might even result in your submission being rejected.

Tip: GMDN codes can be searched with a free GMDN Agency account. If your software doesn’t fit an existing term, your authorised representative or compliance consultant can help identify the right one.

GMDN vs. EMDN: Which One Do You Use?

• UseGMDNwhen registering with theMHRAin the UK.
• UseEMDNwhen submitting product information to EUDAMED in the EU.

Understanding both systems is important if your software is marketed in both regions. Each has slightly different scopes and terminology.

Your Medical Software Compliance Journey at a Glance

Launching medical software in the EU or UK can feel overwhelming at first, but the process is actually quite structured. Here’s a quick recap of the key steps, all brought together into one clear and streamlined path.

Step 1: Determine Regulatory Status

Begin by checking whether your software qualifies as a medical device. Clearly define its intended use and see if it falls under the EU MDR or UK MDR. You’ll also need to determine its risk classification. These steps will guide the rest of your medical software compliance process.

Step 2: Implement Quality Systems

Every manufacturer needs a Quality Management System under MDR Article 10(9), including for Class I software. ISO 13485 certification isn’t always required for lower-risk software, but it’s highly recommended. This is especially true if you’re aiming for CE or UKCA marking for Class IIa or higher.

It demonstrates that you follow controlled processes for development, testing, risk management, and corrective actions.

Step 3: Compile the Technical Documentation

This is the core evidence behind your compliance. Make sure your file includes:

• Device description and specs
• Risk analysis (ISO 14971)
• Design verification and usability reports
• Clinical evaluation summaries
• Software lifecycle documentation (IEC 62304)
• Labelling, IFUs, and conformity marks

You’ll also need to prepare a Declaration of Conformity for each region you target – EU and UK.

Step 4: Appoint Regulatory Partners

Depending on your base of operations:

• Appoint anEU Authorised Representativeif you’re outside the EU
• Appoint aUK Responsible Person (UKRP)if you’re outside the UK

These representatives are essential to registration, communication, and market access.

Step 5: Conformity Assessment and Certification

• Self-certify if your software is Class I (with limited clinical impact)
• Engage a Notified Body or Approved Body if your software is Class IIa or higher

After successful assessment, you’ll receive your CE or UKCA certificate.

Step 6: Apply the Mark and Register

Affix the appropriate conformity marking (CE or UKCA), then:

• Register with the MHRA (UK)
• Register in EUDAMED (mandatory since 28 May 2026)

Also ensure your GMDN or EMDN code is correctly applied in the registration system.

Step 7: Label Your Product Clearly

Your software (whether delivered via app, desktop, or browser), must carry digital labelling that includes:

• Conformity mark (CE/UKCA)
• Intended use and version
• Manufacturer details
• UKRP or EU AR info (if applicable)
• User instructions in local languages

Step 8: Maintain Post-Market Compliance

Even after launch, you must:

• Keep technical files up to date
• Monitor performance
• Respond to feedback and incidents
• Update documentation as needed

Regular internal reviews and surveillance help you stay ahead of audits or changes in regulation. In Great Britain, stricter post-market surveillance rules have applied since 16 June 2025, including a 15-day deadline for reporting serious incidents to the MHRA.

What’s Changing for Medical Software

AI Act: AI-based medical software that needs Notified Body assessment will also count as a high-risk AI system under the EU AI Act (Regulation (EU) 2024/1689). Under the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026), these obligations apply from 2 August 2028 for AI systems in products covered by Annex I of the AI Act, which includes medical devices.

Cybersecurity: The MDR requires secure design for software (Annex I, Section 17). MDCG 2019-16 and IEC 81001-5-1 are the main references. The Cyber Resilience Act does not apply to medical devices regulated under the MDR.

MDR revision: In December 2025, the Commission proposed a targeted revision of the MDR and IVDR to simplify procedures, and it is now going through the legislative process.

UK reform: The draft UK regulations introduce UDI, revised classification, and a PCCP pathway for software updates, expected from around June 2027 (not yet confirmed).

How Euverify Supports Your Medical Software Compliance Process

At Euverify, we support medical software companies with their EU and UK compliance. Whether you’re launching a new diagnostic platform or growing an existing product, we guide you through the regulatory process with clarity.

Here’s What We Can Do for You:

1. Regulatory Strategy & PlanningWe provide guidance to help you work out whether your software is a regulated device, how it may be classified under MDR or UK MDR, and which CE/UKCA marking pathway may apply.
2. UK Responsible Person ServicesIf you’re based outside the UK, our UK Responsible Person service supports your MHRA registration and your communication with UK authorities.
3. EU Authorised Representative SupportFor companies outside the EU, our EU Authorised Representative service supports your EUDAMED registration and your communication with EU authorities.
4. CE and UKCA Marking GuidanceWe provide guidance on the CE and UKCA marking routes and on preparing your technical file for assessment by a Notified or Approved Body.
5. Technical Documentation SupportWe provide templates and tools to help you organise your technical documentation and prepare your Declaration of Conformity, along with guidance on the documents your representatives need.
6. GMDN Code IdentificationWe provide guidance on selecting a suitable nomenclature code to help you avoid registration delays.
7. Ongoing Compliance MonitoringAfter launch, we keep you informed with regulatory alerts and news so you can keep your software aligned with changing standards.

Conclusion

Getting your medical software approved in the EU or UK can feel complex, especially at the start. But with a clear plan, the right documentation, and support from experienced partners, it becomes a manageable and structured process.

When you understand your software’s classification, prepare solid technical documentation, work with the right regulatory bodies, and follow through on labelling and post-market activities, you set the stage for long-term success and user trust.

And with support from Euverify, you’re never doing it alone.Download our detailed guide on medical software compliancefor a step-by-step roadmap and expert insights to help you move forward with precision and peace of mind.

Appoint your EU/UK representative and ensure compliance for your medical software

• Stay compliant with EU regulations
• Hassle-free EU representation for medical software.

Get a 14-Day Free Trial