EU MDR (Medical Device Regulation) - A Practical Guide for Software-Driven Medical Devices

The EU Medical Device Regulation has come along and really shaken up product development in the EU. And yet all these years on since MDR officially took over from the Medical Device Directive, we still see loads of companies treating it as more of a tick box exercise - something to get through with the paperwork, rather than the fundamental shift in how medical software should be designed, built and looked after.

I'm writing this article as the founder of a software company that mainly works on medical device software - embedded systems and SaMD. We've been living with MDR long enough to say this with certainty: MDR is not just a legal problem, it's an engineering problem .

Yes, it is a regulation, yes it is dense, and yes it can be really frustrating sometimes. But at it's heart, MDR makes manufacturers answer some pretty tough questions about their products:

• Do we really understand how our software behaves in those edge cases that crop up?

• Can we track down every safety requirement to the actual code and tests we ran?

• Are we treating cybersecurity risks as a patient safety issue, or just an IT headache?

• Can we safely update our product after it has gone on sale?

For software-driven medical devices, MDR is especially demanding. Software is flexible, fast-moving, and easy to change - while MDR is rigid, risk-focused, and obsessive about keeping track of things. The tension between those two worlds is where most MDR problems come from.

What makes things worse is that loads of teams think they are "already compliant" because:

• The device was certified in the first place,

• The software passed some verification tests,

• or the Notified Body didn't ask any difficult questions yet .

But in reality, MDR introduced a lifecycle mindset . Compliance is no longer something you achieve at the point of release - it's something you have to keep on maintaining as your product evolves, gets updated, connects to new systems, or runs into new cyber threats.

This article is not a legal breakdown of MDR. We aren't lawyers and we won't pretend to be. What you will find here is a software engineer's take on MDR - looking at things from architecture to risk management and the real-world trade-offs that medical device manufacturers face on a daily basis.

If your product relies heavily on software (and these days most medical devices do) then MDR will shape the way you build it, whether you like it or not.

If you are:

• a Founder or CEO of a medical device company making strategic decisions under MDR pressure,

• a CTO or Engineering Manager responsible for delivery, architecture, and long-term maintainability,

• a Product Owner or Technical Lead translating regulatory requirements into real software,

• or a Software Engineer working on embedded systems, SaMD, or connected medical products,

then this article is for you.

What Is EU MDR - In One Page (Without the Legalese)

The EU Medical Device Regulation (MDR) - formally Regulation (EU) 2017/745 - is the law book that governs how medical devices get designed, developed, certified, and maintained in the European market. It replaced the old Medical Device Directive (MDD) with one clear aim: increase patient safety and transparency across the whole product lifecycle .

From a software point of view, MDR changed three key things.

First, it upped the ante on risk . Safety is no longer just about the device itself - software behaviour, failure modes, cyber threats, and even how people might misuse it are now all part of the safety conversation.

Second, the MDR expects end-to-end traceability . Requirements have to be linked to risks, risks to design decisions, design to code, code to testing, and testing to verification. If you can't track something down, then from the auditor's point of view, it's like it doesn't exist.

Third, MDR treats medical devices as living products . Certification is not the finish line - updates, bug fixes, and new functionality must be introduced through controlled processes and supported by appropriate risk assessment.

In short, MDR forces manufacturers to prove that their software is not only functional but also safe, under control, and predictable throughout it's whole life cycle .

Does MDR Apply to Software?

Short Answer: Yes. Long Answer: It depends

And in many cases, it already does, even if manufacturers don't fully realize it.

MDR doesn't regulate software because of how it's made, but because of what it does . If software is trying to:

• diagnose,

• monitor,

• predict,

• or influence clinical decisions or treatment

then MDR is nearly certainly involved.

Software might fall under MDR in a few different ways:

• as stand-alone software ( Software as a Medical Device - SaMD),

• as embedded software controlling or influencing a physical medical device,

• or as software that drives or supports a medical function , even if it's running in the cloud.

Medical software is classified into one of four levels: Class I, IIa, IIb, or III . One of the most important and most misunderstood aspects of MDR is  Rule 11 , which determines how medical software is classified. Under MDR, many software products were recategorized compared to the old directive, often jumping straight into Class IIa or higher.

This has real-world engineering implications: Stricter development methodologies, more formal testing and validation, deeper documentation and involvement of an independent third party (aka Notified Body) are all part of the MDR regulations.

Key MDR Requirements That Hit Software the Hardest

While MDR puts the entire medical device in the regulatory spotlight, software carries a disproportionate amount of regulatory weight . A number of MDR requirements consistently cause the most headaches in software-driven projects, not because they are ambiguous, but because they require discipline and a structured approach.

General Safety and Performance Requirements (Annex I)

Annex I is where MDR connects software behaviour with patient safety in a direct line . Every safety-related software function has to have a justification, implemente,d and verified in relation to identified risks. Avoiding the assumption that all will be ok and any undocumented behaviours or hidden dependencies are difficult to defend during assessment.

Software Lifecycle and Verification & Validation

MDR expects software to be developed following a structured lifecycle , typically aligned with IEC 62304 . Verification and validation are not optional best practices, but a regulatory requirement. Each requirement must be tested, and the overall software behaviour must be validated against it's intended medical use.

Medical software verification and validation testing rarely stop at in-house code. Operating systems, third-party libraries, middleware, and open-source components all become part of the safety argument under MDR. These elements must be identified, justified and controlled throughout the product lifecycle.

Under MDR, such components are typically treated as Software of Unknown Provenance (SOUP) and must be risk-assessed accordingly. In practice, this is closely tied to maintaining an accurate Software Bill of Materials (SBoM) , which allows manufacturers to understand what software they are actually shipping and how changes or vulnerabilities may impact patient safety and compliance.

Usability Engineering for Software

User interface design is not limited to just a UX topic under MDR. Software usability directly affects patient safety and is closely linked to IEC 62366. Design choices, error prevention mechanisms, and user workflows must be validated, especially when software is influencing clinical decisions or guiding user actions.

Cybersecurity as a Safety Requirement

MDR treats cybersecurity risks as potential safety hazards , not just IT issues. Unauthorized access, data manipulation, or loss of availability can all lead to patient harm. Software teams must therefore integrate security design, access control, update mechanisms, and vulnerability handling into the core system architecture.

Clinical Evaluation of Software

For medical software, clinical evaluation isn't just limited to clinical trials. It also involves demonstrating that the software achieves it's intended purpose safely, based on clinical data, literatur,e or equivalence. Unsupported claims or assumptions about software performance are common causes of non-conformities.

MDR and the Product Lifecycle - Before and After Market Launch

One of the biggest shifts introduced by MDR is that compliance doesn't stop at market release . For software-driven medical devices, the most challenging part often begins the moment the product is already in use.

Before Market Launch

Before a product can be put on the market, software must be fully developed in a controlled process. This includes finalized requirements, risk controls implemented in code, complete verification and validation, and documentation that shows everything works together consistently. From a software point of view, this phase rewards teams that planned for MDR from the outset, rather than trying to adapt at the last minute.

After Market Launch

Once the software is in the field, MDR introduces ongoing obligations. Post-market surveillance, incident handling, and change management become part of everyday life. Even minor software updates – bug fixes, performance improvements, or security patches – must be assessed for their potential impact on safety and compliance.

For higher-class software, updates often trigger additional verification, regression testing, and documentation updates. Informal release practices that may work in non-regulated industries quickly become a liability under MDR.

The upshot is clear: software must be designed to accommodate change . Architectures that support impact analysis, controlled updates, and predictable behaviour make long-term MDR compliance manageable. Those that don't tend to accumulate regulatory and technical debt over time.

Common MDR Pitfalls We See in Software Projects

Despite MDR being around for years, the same software-related problems still keep cropping up across different projects and companies. Most of them aren't caused by lack of effort, but by delayed or incomplete understanding of how deeply MDR affects software development .

Treating MDR as a Documentation Exercise

One of the most common mistakes is focusing on documents instead of processes. Teams try to "fill the gaps" just before certification, only to find that missing traceability or unclear design decisions can't be fixed with documentation alone.

Underestimating Software Classification Impact

Misjudging software classification early on often leads to painful corrections later. When software ends up in a higher class than expected, existing development and validation practices may no longer be sufficient – forcing rework, delays, or architectural changes.

Weak Traceability Between Requirements, Code and Tests

Many projects struggle to clearly link safety requirements to implementation and verification. This becomes especially problematic during audits or when introducing changes, where the impact on safety must be demonstrated quickly and convincingly.

There are certain ways to do that in a smart way using popular software development tools such as Jira, so your requirements, code changes, tests, and reports are all interconnected.

Cybersecurity Treated as a Separate Topic

Cybersecurity is still often handled as an IT or infrastructure concern, detached from software design. Under MDR, this separation doesn't hold. Security weaknesses can translate directly into safety risks, and auditors are increasingly expecting them to be addressed at the software level.

Legacy Software Without a Regulatory Foundation

Products that were created before MDR or inherited from previous teams can often be found lacking the structure, documentation and traceability that MDR now demands. And let's be honest - trying to retrofit compliance into these systems is almost always going to be a very expensive business - a whole lot more expensive than if you'd built the thing right from the start.

These issues rarely come to the surface at the beginning of a project but they have a nasty habit of surfacing at the worst possible moment - during certification, audits or post-market incidents. And at that point, it's often too late to do much about it.

MDR From a Business Perspective

From a business view, MDR is not so much about being compliant itself but more about how much risk you're exposing yourself to . For software-driven medical devices, regulatory gaps don't stay quiet - they usually come along as delays, redesigns, or escalations with the Notified Bodies getting involved.

Software-related issues are among the most common causes of certification delays. And we're talking here about things like missing traceability, inadequate verification or unclear change impacts. This can easily push timelines back by months. For start-ups, this can put the whole project into jeopardy or block market entry and investor milestones altogether. For established manufacturers, it can mean postponed launches, lost revenue, and increased operational pressure.

And then there are the post-market obligations which just add to the business risk. If you're not careful, uncontrolled software updates, weak incident handling or poor cybersecurity measures can trigger corrective actions, additional audits or even temporary market withdrawal. And at that point, fixing the problem is going to be a lot more expensive than if you'd addressed it during development.

Companies that look at MDR as a quality framework that applies to both products and processes tend to have fewer surprises than those that don't. Predictable software development, controlled updates and clear documentation all go a long way to reducing regulatory uncertainty and making it easier to scale product portfolios. In this sense, MDR compliance is actually a stabilising force rather than a recurring business threat.

How We Approach MDR-Compliant Software Development

We've got a lot of experience with MDR as a result of building software that not only has to work technically, but also within regulated environments and under real-world audit conditions .

We develop medical software within processes that are aligned to ISO 9001:2015 and ISO 13485:2016 , which gives our engineering teams a solid framework for managing risk, documentation, traceability and continuous improvement. This makes it easier to integrate MDR requirements into everyday development as opposed to treating them as an external constraint that we have to jump through hoops to comply with.

From a technical perspective, we stick to proven and well-established technologies that are suitable for long-term, regulated environments. And this is not just because they're fashionable - it's because they support maintainable architectures, predictable behaviour, and long product lifecycles with controlled updates.

In practice, this means:

• starting with requirements that have been properly risk-assessed and are testable,

• designing architectures that support traceability and impact analysis,

• treating verification, validation, and cybersecurity as core engineering activities,

• and building software that takes into account post-market updates and audits right from the start.

We work closely with manufacturers' QA and RA teams to ensure that our software development aligns with their overall quality management system. Our goal is not to "get software ready for certification" but to build software that can stay compliant as it evolves over time .

This approach has worked well for us across embedded systems, SaMD, and complex products that combine devices, cloud services, and companion applications.

Final Thoughts

MDR raises the bar when it comes to what's expected from medical device software development. It requires teams to be upfront about risks, deliberate in their design, and disciplined in how software evolves over time.

For engineering teams, this shift is all about clarity over speed and structure over improvisation. Software that is modular, traceabl,e and designed with change in mind is not only easier to certify - it's also easier to maintain, test, and trust.

MDR doesn't demand perfection; it just demands predictability . Teams that get this approach early on tend to spend less time reacting to regulatory pressure and more time building software that is safe, robust, and fit for long-term use in clinical environments.