Hiring or looking for a job in Digital Health? Check out our Digital Health Jobs board

Articles Questions

July 27, 2020

Software as a Medical Device: What's a Significant Change?

Dr. Oliver Eidel


We’ve got the first version of our software as a medical device certified and on the market. Now we’re working on the next version and wondering whether we have to involve our notified body. Apparently, you have to do that if your version includes something called a “significant change”. Does our product include a significant change and who can help us there?

Short Answer

There is no short answer. It’s a mess and depends on your auditor, that is, if you can reach them. There’s the MDCG 2020-3 guidance document which could be useful for you. You could ask consultants like me but my opinion might differ from your auditor’s and from other consultants, too.

Try to minimize business risk: Before devoting expensive development resources to a new version, get a clear indication on whether it’s a significant change.

See also my answer on changes to machine learning - based software as a medical device.

Long Answer

If I could name one topic which is the most unclear and messy in medical software certifications, it might be this. Evaluating whether a change to your (certified) software as a medical device is a significant one is so subjective, it’s almost ridiculous. It’s highly dependent on your notified body and on your auditor. The worst part is that your auditor can’t provide any consulting services to you (which makes sense), but that leaves you in a bad place because nobody else can tell you whether your planned change is significant.

But before I continue my rant, let’s look at MDCG 2020-3 which is a guidance document on significant changes. It at least gives us some indications on what we could expect. I’ll spare you reading yet another guidance document with poor formatting and titled “DRAFT”. Maybe we could invest some EU money in training people in using Microsoft Word?

Here’s what’s a significant change according to the document. I fixed the 50 typos and added question marks behind unclear phrases.

Changes of the Intended Use

Not significant:


Changes of the Design or Performance Specification


Software Changes

Not significant:


Summary of the MDCG 2020-3 Guidance

Most of those points make sense. A change of the intended use always constitutes a significant change, unless you limit it.

The design and performance spec changes make sense, except one: Why should a new risk which requires risk control measures constitute a significant change? This shouldn’t be based on whether a risk control measure was needed. Instead, it should take into account whether the total risk profile of the device became worse.

Some of the software points also make sense. Bug and security fixes aren’t significant changes.

Other points are less clear and sound quite limiting:

If you haven’t noticed by now: It’s a mess. Ready for more confusion? Based on the experiences I had with auditors in the real world, changes to the software (even major ones) were generally fine as long as the intended use remained the same and the risk analysis didn’t become worse. To me, this sounds like a good and pragmatic approach. It however contradicts the guidance document. And I could imagine there are auditors out there who handle this differently.. welcome to regulatory hell.

In case you missed the link above: I also answered a slightly different question regarding changes to machine learning - based software as a medical device.

On a slighty different note: You want to get your medical software certified under MDR but don't know where to start? No worries! That's why we built the Wizard. It's a self-guided video course which helps you create your documentation yourself. No prior knowledge required. You should check it out.

Or, if you're looking for the most awesome (in our opinion) eQMS software to manage your documentation, look no further. We've built Formwork, and it even has a free version!

If you're looking for human help, did you know that we also provide some limited consulting? It's limited because we are not many people. We guide startups from start to finish in their medical device compliance.

Congratulations! You read this far.

Get notified when we post something new.

Sign up for our free newsletter.

Dr. Oliver Eidel

I'm a medical doctor, software engineer and regulatory dude. I'm also the founder of OpenRegulatory.

Through OpenRegulatory, I've helped 100+ companies with their medical device compliance. While it's also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)

If you're still lost and have further questions, reach out any time!


If you have any questions or would like to share your opinion publicly, feel free to comment below. If you'd like to reach out privately, send us a message.

No QMS on this planet will save you from creating crappy software.