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

Articles Technical Documentation

Updated May 24, 2023

IEC 62304 Walkthrough

Dr. Oliver Eidel

So you’ve decided to develop software which is a Medical Device. Now you need to develop it in an IEC 62304 - compliant way.

Resources on how to achieve that are scarce. To add insult to injury, not even the IEC 62304 can be accessed freely! See the article on accessing standards on how to access it.

This is a very opinionated guide on how to achieve IEC 62304 compliance. The approach which I present here is just one option. I don’t claim for this to be the only way of achieving it.

General Requirements

You need a Quality Management System. This pretty much means that you need to implement an ISO 13485 - compliant Quality Management System and get audited for that. Note that this is a company-wide requirement: Your company becomes a qualified Medical Device manufacturer by having such a Quality Management System. You don’t have to re-do this for each product you plan on developing.

You need some sort of Risk Management. Specifically, your risk management needs to adhere to IS 14971. This is product-specific: You need to evaluate what can go wrong with your products and assess whether it’s still safe to go ahead and bring it to market.

Great, that’s it? Easy. With that out of the way, let’s see what we have to get done next.

Important: Software Safety Classification

The IEC 62304:2006 defines so-called Software Safety Classes: A, B and C. Depending on the risk profile of your software, it is classified as one of those three classes.

How do they differ? There’s a mostly-easy-to-understand flowchart in the standard for that (section 4.3), but the gist of it is:

  1. If your software can cause serious injury or death, it’s class C.
  2. If it can cause non-serious injury, it’s class B.
  3. Otherwise it’s class A.

It’s also important to note that this class doesn’t necessarily apply to all software in your soon-to-be-certified medical device: You can (and probably should!) have separate software systems which may have different safety classes.

This is important because, based on your safety classification, there are different documentation and testing requirements. As you might have guessed, class C includes the most effort.

It makes sense for critical software systems to be well-tested, but you should be beware of over-classifying your software systems which causes unnecessary overhead. You should also consider extracting critical parts into separate software systems (e.g., running in separate docker containers) to both increase resilience and decrease testing effort.

IEC 62304 Requirements

Write a Software Development and Maintenance Plan

You need to write a Software Development and Maintenance Plan in which you describe your required resources, software, version control and testing.


Writing a Software Development and Maintenance Plan


Software Requirements

For you software, you need to document so-called Software Requirements. These describe what your software does. If you have no idea what I’m talking about: Don’t worry, read the article.


Writing Software Requirements Based on IEC 62304


Document Your Libraries / Dependencies (“SOUP”)

SOUP is the regulatory term for third-party dependencies or libraries which any sane developer uses in their code. You need to create some additional documentation for those and also monitor them regularly for issues like bugs or security vulnerabilities.

Check out my article on documenting SOUP:


How to Document SOUP


Software Architecture

Depending on your software safety classification, you need to document your software architecture.


Medical Device Software Architecture Documentation (IEC 62304)


Software Verification

Any time you write code, you have to verify that that code actually conforms to your specifications. No clue what that means? You’re not alone.


Software Verification For Medical Device Software


Software System Testing

You have to test your software and prove that you’ve covered all software requirements.


Software System Testing Based on the IEC 62304


Software Release

The 62304 has a few requirements regarding software releases. And this step is a good opportunity to check that you’re done with all other activities. And you have to determine whether you made a significant change to your product. In that case, you have to wait for approval from your Notified Body.


Doing a Software Release in Compliance With IEC 62304


Manage Feedback and Problems

You need a process to manage feedback and evaluate problems. Most importantly, you need to assess whether a serious problem with your product has occured.

Once you’ve identified a problem, you need to solve it. Then, you need to check whether your solution actually works - who would’ve thought? The standard calls this a Problem Resolution Process.

Change Management

Once your product is released (i.e., certified), you can’t just go ahead and change it however you like. You have to check whether a change is significant and requires approval of your Notified Body. For that, guess what? You need a process.

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.