IEC 62304 Walkthrough

Dr. Oliver Eidel
Updated October 1, 2024
0 comments

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.

Read: 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.

Read: 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:

Read: How to Document SOUP

Software Architecture

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

Read: 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.

Read: Software Verification For Medical Device Software

Software System Testing

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

Read: 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.

Read: 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 different note: Do you still have lots of questions about the EU MDR and would you like to talk to a human? No worries! Just book a free 30-minute consulting call.

Or, if you don’t like talking to humans, check out our Wizard instead. It’s a self-guided video course which helps you create your documentation all by yourself. No prior knowledge required.

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

Congratulations! You read this far.
Get notified when we post something new.
Sign up for our free newsletter.

Comments

Leave the first comment