View the talks from the OpenRegulatory Conference 2021!

Updated September 30, 2021

IEC 62304 Walkthrough

Dr. Oliver Eidel
IEC 62304

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.

Article

Writing a Software Development and Maintenance Plan

Read

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.

Article

Writing Software Requirements Based on IEC 62304

Read

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:

Article

How to Document SOUP

Read

Software Architecture

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

Article

Medical Device Software Architecture Documentation (IEC 62304)

Read

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.

Article

Software Verification For Medical Device Software

Read

Software System Testing

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

Article

Software System Testing Based on the IEC 62304

Read

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.

Article

Doing a Software Release in Compliance With IEC 62304

Read

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.

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.