EU MDR for software teams
When software counts as a medical device in the EU, how Rule 11 sets its class, and what a manufacturer must do before and after the product reaches patients.
What EU MDR is
Regulation (EU) 2017/745 on medical devices (Medical Device Regulation)
The EU Medical Device Regulation, Regulation (EU) 2017/745, sets the rules for placing medical devices on the EU market. It has applied since 26 May 2021 and replaced the older medical device directives.
Software can be a medical device on its own. The definition in Article 2 names software, and what decides it is the intended purpose the manufacturer gives it: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, among others.
If software is a device, it needs a class, a conformity assessment and a CE mark before it is sold. Most decision-support software lands in class IIa or higher under Rule 11, which means a notified body must review it.
Who it applies to
Manufacturers
Whoever places the software on the EU market under their own name, wherever they are based. Non-EU manufacturers need an authorised representative in the EU.
Software with a medical purpose
Apps and platforms that diagnose, monitor, predict or guide treatment for individual patients, including AI symptom checkers, imaging tools and digital therapeutics.
Importers and distributors
Companies that bring devices into the EU or sell them on have their own checks and record-keeping duties.
Software for general wellbeing, lifestyle or fitness, and software that only stores, archives or moves data without acting on it for a patient, is usually not a device. The line depends on the intended purpose in your labels, claims and marketing, so a single new claim can move a product inside the MDR.
Key requirements, and what they mean for the build
Each row links the official text. Read the source for the exact wording before you rely on it.
Is the software a medical device?
A medical device is any instrument, apparatus, software or other article the manufacturer intends for a listed medical purpose for people.
Write down the intended purpose early, and keep product claims, onboarding text and app store copy consistent with it.
Software classification
Software that gives information used for diagnostic or therapeutic decisions is class IIa, IIb if a wrong decision could cause serious deterioration or surgery, and III if it could cause death or irreversible harm. Software that monitors physiological processes is IIa, or IIb for vital parameters where changes could mean immediate danger. All other software is class I.
Classify each feature that has a medical purpose, and keep features that would raise the class behind a separate release decision.
Software that drives a device
Software that drives or influences a device takes the class of that device. Software independent of any device is classified in its own right.
Decide early whether the software is an accessory to hardware or a device on its own, because the paperwork follows that choice.
Software safety and performance
Software is designed for repeatability, reliability and performance, developed under a life cycle with risk management, information security, verification and validation, and adapted to the mobile platforms it runs on. Manufacturers set minimum hardware, network and IT security requirements.
A documented development life cycle, a risk file per release, security testing, and supported device and OS versions stated in the instructions.
Quality system and technical documentation
Manufacturers run a quality management system, keep technical documentation for the device, and keep both up to date.
Requirements, design, risk, test and release records produced by the same pipeline that ships the software, so documentation does not drift from the code.
Person responsible for regulatory compliance
Manufacturers have at least one person with the required expertise who is responsible for regulatory compliance.
Give that person sign-off on releases that change the intended purpose, the risk file or the instructions for use.
Conformity assessment
Before placing a device on the market, the manufacturer runs the conformity assessment for its class. Class IIa and above need a notified body.
Plan notified body review into the roadmap. Changes after certification may need to be reported or reviewed before release.
Clinical evaluation
Conformity with the safety and performance requirements is backed by clinical data that gives enough clinical evidence.
Log the data needed to show the software performs as claimed, and keep evaluation datasets versioned with the model or algorithm they tested.
Unique device identification
Devices carry a unique device identifier (UDI) for traceability.
Show the UDI and software version in the app, and change the identifier when a change requires it.
Post-market surveillance and vigilance
Manufacturers run a post-market surveillance system for each device and report serious incidents. The general limit is 15 days after becoming aware, and shorter for serious public health threats, deaths or unexpected serious deterioration.
In-app feedback and error reporting that reach the quality team, complaint triage with the reporting clock built in, and release notes tied to each fix.
Engineering controls for EU MDR
How the rules change the way the software is designed.
- 01
Intended purpose record
One controlled statement of what the software is for and who it is for, checked against every claim in the product and its marketing.
- 02
Feature classification
Each medical feature with its Rule 11 reasoning, so a new feature cannot raise the class without a decision.
- 03
Life cycle and risk file
Requirements, hazards, risk controls and tests traced together, and updated on every release.
- 04
Change control
Each change is assessed for its effect on safety, performance and the certificate before it ships.
- 05
Security by design
Threat modelling, access control, encryption and patching, with minimum IT requirements stated for users.
- 06
Usability evidence
Tests with real users in the real setting, focused on errors that could harm a patient.
- 07
Field data loop
Complaints, crash reports and performance data that feed post-market surveillance and vigilance reporting.
- 08
Version and UDI in the app
The software version and device identifier are visible to users and support, and match the technical file.
Key dates
- 26 May 2021The MDR applies, after a one-year delay.
- 26 May 2024Deadline for a formal application to a notified body to keep using the extended transition.
- 26 September 2024Deadline for a written agreement with the notified body under the same conditions.
- 31 December 2027End of the extended transition for class III and most class IIb implantable devices certified under the old directives.
- 31 December 2028End of the extended transition for other class IIb, class IIa and certain class I devices.
The transition dates apply only to devices already certified or declared under the old directives, and only if the conditions in Regulation (EU) 2023/607 are met. New software devices must meet the MDR now. In December 2025 the European Commission proposed a targeted revision of the MDR. It is not law until the Parliament and Council adopt it, so check the Commission's page before planning around it.
Checked against the official sources on 2026-10-25.
9 OceanLab product builds cite EU MDR
Counted from our published case studies: a build counts when EU MDR is in the list of rules it was built for.
Leitstern - AI Symptom Checker with a Clinical Governance Console
Designed and built the clinical governance console for a CE-marked symptom checker that tells people in Austria how urgently to seek care: releases of clinical content, red-flag rules and locked models approved by e-signature against a passing regression run, real-world under-triage tracked from follow-ups, and vigilance deadlines kept in view.
Lichtung - Prescribable AI Journaling App with a Clinical Safety Console
Designed and built a clickable clinical console for a prescribable CBT journaling app on the German DiGA pathway: clinical review of every patient-facing text, an AI release register with safety gates and sign-offs, and a crisis detection log that staff review without ever reading a journal entry.
Schaukasten - Cloud X-ray Viewer and Archive with Secure Sharing
Designed and built a clickable cloud imaging viewer and archive for a Kassel software company serving German dental practices and vet clinics: one study list per patient or animal, a browser viewer with window/level, calibrated measurement and annotation, findings, and expiring PIN-protected links for referrers and owners.
Atalaya - Radiology Information System from Order to Signed Report
Designed and built a clickable radiology information system for a private imaging group with nine centres in Andalucía, Madrid and Cataluña: radiologists protocol orders against safety rules, read from one worklist ranked by urgency and time to SLA, sign structured reports behind a pre-sign checklist, and prove every critical finding reached a clinician.
Lysning - Type 2 Diabetes Programme with a Coach Console and GP Escalations
Designed and built a clickable coach console for a Danish type 2 diabetes programme that municipalities buy for their residents: a caseload sorted by risk, rule-based flags with a service standard, a full participant record, and letters to GPs that go through clinical review and MedCom delivery.
Latu - Wearable Data Dashboard for Endurance Athletes and Coaches
Designed and built a clickable athlete app for a Finnish sports-tech company that joins heart rate, HRV, sleep and training load from several wearables: a daily readiness score that explains itself, training load and fatigue charts, every workout in one list with duplicates merged, and sleep trends against the athlete's own normal range.
Check your product
Other frameworks and industries
Build with EU MDR in mind from day one
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
EU MDR questions
Is our health app a medical device?
It depends on the intended purpose. An app that diagnoses, monitors or guides treatment for a patient usually is. An app for general fitness or wellbeing usually is not. MDCG 2019-11 walks through the decision step by step.
Why does so much software end up in class IIa?
Rule 11 puts software that informs diagnostic or therapeutic decisions in class IIa at least. That means a notified body must assess it, which takes time to plan for.
Does the EU AI Act apply too?
Often yes. AI in a medical device that needs a notified body is treated as high-risk under the AI Act. The Commission has published joint guidance on how the two fit together.
Can we ship updates after certification?
Yes, under change control. Each change is assessed for its effect on safety, performance and the intended purpose. Significant changes may need the notified body before release.
How does OceanLab approach EU MDR on a build?
We fix the intended purpose and classification with your regulatory lead first, then build the risk file, traceability and change control into the delivery process. The builds below list the EU MDR in the rules they were built for.
Official sources
- Regulation (EU) 2017/745 (MDR), EUR-Lex
- Regulation (EU) 2023/607: MDR transition extension, EUR-Lex
- European Commission: medical devices overview
- European Commission: MDCG guidance, including MDCG 2019-11 on software
- European Commission: MDCG 2019-11 rev.1, qualification and classification of software (June 2025)
