Besides curing cancer and achieving nuclear fusion, getting software certified as Medical Device seems to be the most complex endeavour known to mankind.
Well, actually, certifying software as a Medical Device is pretty simple – once you know what to do. Unfortunately, a whole industry full of shady consultants has emerged around this topic and most consultants are paid by the hour. So a lot of people are incentivised to make this very complex, because then they can bill many hours.
But you got lucky, because you found this website. With all the free articles and templates we offer here, you should be able to get everything done by yourself, saving lots of time and money.
This article summarises everything you need to know in an easy, step-by-step structure. Good luck!
A quick note: I’m currently in the process of updating this article. It was the first article I published back when OpenRegulatory got started in the dark ages (2020), and now it’s 2024 and our website has way more content which I will be referencing here.
Step 1: Is Your Device a Medical Device?
The first step is to determine whether what you’re building (software or hardware) is a medical device at all. Check out the definition of a medical device according to the MDR here. If you think you fall under that definition, we’ve written up some example devices here (compare yourself to them).
A few quick side notes: Contrary to what many others say, MDR class I software does exist, but different competent authorities have different interpretations, e.g. if you’re company is located in Berlin, you’re screwed. Also, Telemedicine software is not class II (it’s not a medical device at all). In Germany, the BfArM offers to do an “official” classification assessment, but you shouldn’t do it because it easily takes one year or more.
Step 2: What Sort Of Compliance Are You Targeting?
Depending on which market you want to sell in, you have two options: The EU MDR for (you guessed it) the EU market, or the US FDA for, well, the US market. This website right now is mainly about the EU MDR, but we’ll be adding some US FDA content in the future. Also note that our eQMS software supports EU MDR and US FDA.
So, umm.. you just need to decide here and if you’re targeting the EU market, stay on this website (cool!). If you’re targeting the US market, well, you might have to look for helpful content on other websites of shady consultants (ugh), but you could still use our software to automate your documentation.
Step 3: How Long Does It Take, And How Much Does It cost?
Funnily enough, most consultants aren’t able to answer this question, so I’ll cut right to the chase:
Duration
- MDR class I: You can be done in 2-3 months if you choose our “method” (articles and templates here, and optionally our consulting). With other consultants, 3-4x longer, around 12 months.
- MDR class IIa and higher: You can get the work on your side done in 2-3 months (again, with our method), but you’ll have to wait for a so-called Notified Body to audit you and get their results which can easily take another 3-9 months. So 12 months in total.
Cost
- MDR class I: None, if you do it yourself. 750€ / month for a so-called external Person Responsible for Regulatory Compliance (PRRC), similar to a GDPR Data Protection Officer (DPO).
If you do it with consultants: 20-30k€ if you choose us, much more (~100k€) if you choose others. - MDR class IIa and higher: At the very least, you pay the cost for your auditors (the Notified Body) which can be anywhere between 30k€ and 100k€ (crazy), here’s an article.
If you do it with consultants: 60-70k€ if you choose us, much more (~120k€) if you choose others.
Check out this article on duration and this one on cost. Also, this video.
Step 4: What’s The Work To Be Done?
Roughly speaking, you can split the work into two areas: Company-wide stuff and product-specific stuff.
On a company-wide level, you need to establish a Quality Management System (QMS) which is compliant with ISO 13485.
And on a product level, you need to write so-called Technical Documentation for each product.
That’s it.
And what are those requirements all about? They are spelled out in so-called standards, e.g. the ISO 13485. Those are PDFs you have to purchase (yes, seriously). But the good news is that there’s a hack: You can purchase them from the friendly Estonian website for much less money. Check out our guide an accessing standards here.
Now, let’s look at the company-wide stuff first.
Step 4a: Company-Wide Stuff: Set Up a QMS
For your company, you have to set up a so-called Quality Management System (QMS). Regulators think that this improves the quality of your products while there actually is only very little evidence to back up this claim.
But anyway, moving forward.. you only have to do this once for your company. Your best bet would be to read our articles on quality management here.
Step 4b: Product-Specific Stuff: Technical Documentation
For each of your products, you have to write something called Technical Documentation. Greatly simplified as always, this includes writing down all the features of your software (“software requirements”), all risks it might have (“risk management”) and doing a user test (“usability engineering”).
Let’s look at a few examples next. You can find more information in the IEC 62304 Walkthrough and ISO 14971 Walkthrough.
Write Your Intended Use
Write down what your software does and in which context it is used. This is not only your starting point, but the most important document for your regulatory compliance. It determines whether you are a medical device or not. Read this article on Intended Use for Software as a Medical Device
Next, it’s important for you to know which Medical Device Class your software belongs to.
Medical Device Classification Under The MDR
The so-called class of your Medical Device determines what you have to do to get it certified. This can have a huge impact: Class I Medical Devices under the MDR don’t need an audit by a so-called Notified Body, so you can bring it to market as soon as you’re ready!
So you need to be very sure of this before you get started. We have quite a few articles on classification nowadays. Here’s a general article on classification and here are some MDR classification examples. If you think your might be MDR class I, check out our MDR Class I Walkthrough.
Step 5: Actually Found Your Company
For class IIa and higher products, you’ll need a Notified Body to audit your Quality Management System and Technical Documentation. The prerequisite for entering a business relationship with one of those is that your company already exists.
This especially puts University-backed startups in a tricky spot: Often they’re not founded yet as they’re still somewhat part of their University. So you need to solve this problem first – found your company. Depending on how “German” your University or their incubator is, this might easily take 1-2 years. Good luck.
Step 6: Buy and Read Standards
You might assume that the standards you have to comply with are freely available. Nope! But the good news is that there’s a hack which allows you to access them for reasonable prices.
Now you’re probably thinking “Damn, I don’t have time to read those standards”. But do you have to read them? Yeah, you sure do. I wrote an article on accessing standards for less than 30€, it’s a must-read. Also, here’s a video.
Step 7: Find a Notified Body
Unless your device is classified as class I, you now need to find a Notified Body. Those are companies who are allowed to audit medical device manufacturers and certify their devices.
Read: Choosing a Notified Body
Step 8: Do The Clinical Evaluation
You need to do your clinical evaluation which provides evidence for the medical benefits of your software. Personally, I think this is very painful and borderline shady / unnecessary (how come every manufacturer arrives at the conclusion that their product is “safe”?), but anyway, you have to do it. My colleagues wrote way better articles on this than I could ever have. Here’s on doing the literature review, here’s one on clinical evidence, another one on the clinical development plan, and.. anyway, I’m getting tired of linking articles here, you’ll find them if you look for them.
Step 9: Hire or Train Regulatory People, Find PRRC
It’s a regulatory requirement that you have a so-called Person Responsible for Regulatory Compliance (PRRC). This is similar to a GDPR Data Protection Officer (DPO). Here’s an article about people you need.
Step 10: Set Date for QMS Audit and Technical Documentation Hand-In
Once you’ve found a Notified Body, it’s time to set some dates with them. You’ll be setting two dates:
- The QMS audit: Typically, three days (!) in which an auditor drops by and checks out your company.
- Technical Documentation hand-in: A deadline until when you plan to hand in your Technical Documentation of your product.
So you need to do some planning and estimations. For 1., you need to estimate until when you can set up your QMS until it’s ready to be audited. For 2., you need to know until when your product will be completely developed.
Speaking from experience, all companies miss all deadlines, always. So estimate conservatively. And have a plan B for what to do once you miss your deadline. Inform your Notified Body early enough, you won’t be the first company to postpone their audit.
Got those dates? Cool
Step 11: Actually Hand Everything In And Get Audited
Just hand everything in and get your audit results. In most cases, auditors always find something, because finding nothing doesn’t quite feel right. And in all cases, those things will likely be completely different than what you expected – as an example, at one company we worked with the auditors noted that we cited standards with their wrong year, e.g. the ISO 13485:2016 instead of ISO 13485:2015. Hm.
Anyway, most of this is out of you control. Do the audits and get the results.
