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

Articles Technical Documentation

Updated May 24, 2023

Software Verification For Medical Device Software (IEC 62304)

Dr. Oliver Eidel

Software Verification is another of those regulatory buzzwords. Unless you’ve worked at an enterprise company before, chances are that you have no idea what it means.

Surprisingly, Wikipedia has an entry on it so I’ll just cite it:

Software verification is a discipline of software engineering whose goal is to assure that software fully satisfies all the expected requirements.

Totally clear, right? Not quite.

Let’s look at an example. You’re building a Covid-19 tracking app. You’ve written some [software requirements]. Those software requirements specify behavior of your software.

Now one of your developers starts working on it, writes some code and opens a pull request on GitHub. The stage for software verification is set. Exciting!

The goal now is to ensure that the specifications have been met. In human language: Have you written the correct code which works as intended?

How could you prove that? Here are some ideas.

Examples for Software Verification Methods

So what should you choose in practice? Here’s what I would propose:

If you team has more than one developer, always do code review. It’s an easy win regulatory-wise, improves your code quality and gives developers opportunities for peer learning.

If your programming language has a well-accepted linter / code formatter, consider using that. There’s no golden rule here. For very dynamic, meta-programming-heavy languages like Ruby, developers may be annoyed by it and it might not provide a lot of value. For languages which make it easy to write broken code (JavaScript), those may be a good choice.

Write unit and integration tests. If you’re using a framework like Django or Rails which is batteries-included, the barrier of entry is incredibly low. Such frameworks often already have an integrated test suite with ready-to-use integration test setups (e.g. Rails + Capybara). If you have to roll your own, it’s more painful, but that’s what professional software development is about :)

Software Verification vs. Software System Testing

Ready for some confusion? The 62304 also requires Software System Testing. How is this different from software verification if that already covers unit and integration tests?

Tricky. I don’t know. Here’s what I’ve seen in practice: Software verification is done on each code change, e.g. each time a pull request is opened on GitHub. It’s code review and “the stuff which runs automatically”, like CI tests. Software system tests on the other hand are only done before you release a new version to the public. Those tests must cover all of your software requirements. And not all of your software requirements are covered by pull request and your CI pipeline. For example setting up a firewall may be a software requirement, but there may be no code for it. You still have to “test” (or at least prove) it. That would be the software system test. In this case, a screenshot of the correctly configured firewall may suffice.

Software Verification vs. Software Validation

Software Validation is another buzzword. Luckily, the 62304 doesn’t mention it, but it is often mentioned in the context of medical device software.

Wikipedia to the rescue, again:

Software verification asks the question, “Are we building the product right?”; that is, does the software conform to its specifications? (As a house conforms to its blueprints.)

Software validation asks the question, “Are we building the right product?”; that is, does the software do what the user really requires? (As a house conforms to what the owner needs and wants.)

And the good news is that you cover validation during your usability tests which you need for 62366 compliance anyway.

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.