View the talks from the OpenRegulatory Conference 2021!

Updated September 30, 2021

Start Here: The Blueprint for Certifying Medical Software

Dr. Oliver Eidel

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 consultant industry has spawned around this topic and most consultants are paid by the hour. So a lot of people are incentivized to make this very complex.

But that’s not you. You want to get stuff done in a simple way. So here’s a step-by-step guide. Good luck!

What Does This Apply To?

This only applies to the EU (MDR, and partially IVDR). We don’t have much experience with FDA certifications. There is probably a lot of overlap as many of the standards are the same.

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.

Follow These Steps

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.

Article

Intended Use for Software as a Medical Device

Read

Next, it’s important for you to know which Medical Device Class your software belongs to.

Device Classification

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 MDD don’t need an external audit, 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. I wrote a separate article on this topic.

Article

Medical Device Classification

Read

Found Your Company

For class II and III products, you 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 often puts startups in a tricky spot: Often they’re not founded yet, or they’re still part of some parent organization like an University or an incubator.

There’s not much you can do about this. Just found your company.

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.

Article

Accessing Standards For Less Than 30€

Read

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.

Article

Choosing a Notified Body

Read

Do Clinical Evaluation

You need to do your clinical evaluation which provides evidence for the medical benefits of your software.

Article

Clinical Evaluation Report (CER) For Medical Devices: 3 Easy Steps

Read

Hire or Train Regulatory People

There are two sorts of people you must have as a medical device manufacturer:

  1. A person responsible for regulatory compliance under MDR, or under MDD a medical device safety officer
  2. At least one medical device consultant

Here’s how to get them.

Article

People You Need: Person Responsible for Regulatory Compliance, Safety Officer, Medical Device Consultants

Read

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:

  1. The QMS audit: Typically, three days (!) in which an auditor drops by and checks out your company.
  2. 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? Then let’s get down to work.

Company-Wide: Quality Management System

You need to implement a Quality Management System in your company based on ISO 13485. That’s a standard.

What does that mean? The ISO 13485 is mainly about processes. It states that your company has to have certain processes which are described there. For example, a process to handle customer complaints. And a process to evaluate suppliers before purchasing things from them.

You need to set up those processes in your company and document them, e.g. by having flowcharts or writing them down. You also need to prove that you’re actually adhering to those, so if your customer complaint process says that you always send flowers to your customers, you better have some flowers lying around to prove it! That was a joke.

I’ll write an article about setting up a 13485-compliant QMS in the future.

Product-Specific: Technical Documentation

For each product you want to certify, you need to create documentation. It’s called “Technical Documentation”. It needs to cover some very specific things which are stated in certain standards: The IEC 62304 for your Software Lifecycle, the ISO 14971 for Risk Management and the IEC 62366 for Usability Engineering.

While these standards also make you implement some processes, more importantly, they specify what the output of those processes should be. For example, you need to write a Software Development Plan. And you need to conduct User Testing with your (final) software.

Article

Writing Technical Documentation

Read

Congratulations! You read this far.

Get notified when I post something new.

Sign up for my free newsletter.

I work as a regulatory consultant for Healthcare software startups. I try to publish all my knowledge here so that startups can certify their medical devices themselves in the future.

If you're still lost and have further questions, just send me an email and I'll be happy to answer them for free. More about me

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.