How To Do Medical Device Software Development?


Our company wants to get into medical device software development. How do we get started and how do we have to change our existing software development processes?

Short Answer

You don’t have to change anything, but you now have to do tons of documentation. Other consultants typically have a very different opinion on this and will tell you that you have to change everything and focus on “quality management” blablabla, but those people typically have never written a line of code.

Long Answer

So, if you want to get into medical device software development and you already have experience developing software, that’s awesome! Because that means you have way more software experience than the average regulatory consultant and even auditor. It’s a weird industry, haha.. anyway!

Now the big question how large the difference is between what you’re currently doing and what you need to do if want to bring a medical device to market successfully.

That difference mostly lies in documentation. Some examples of documentation activities which you have to do for medical device software development are:

Documentation Requirements For Medical Device Software Development

  • Documenting User Needs (similar to user stories)
  • Writing a “Design Input” specification
  • Documenting your tests, and mapping them to Design Inputs
  • Setting up a “Quality Management System” (QMS).

If you think all of this sounds easy and you can easily automate all of this, this is unfortunately not true. The problem, in simplified terms, is that a list of design inputs is not equal to a list of all your user stores which you’re already documenting.

Your user stories typically look like this:

  1. Build login with Google
  2. Change login with Google so that user is automatically logged out after 20 minutes
  3. Fix login with Google
  4. etc.

You get the idea. Most user stories at most companies describe changes, and they assume that the reader already has a rough idea of how the software currently looks like. The problem is that, from a regulatory perspective, design inputs for medical device software development should look different, e.g. like this:

Design Inputs For Medical Device Documentation

  1. A user can log in with Facebook or Google.
  2. After 20 minutes, they are logged out.

So it’s an absolute specification of what your software does at a certain point in time.

This will mostly mean you’ll have to retrospectively document your software, because you almost certainly don’t know the exact features and behaviour your software is going to have once it’s done.

And that, in a nutshell, is why medical device software development adds a ton of overhead to your process.

For what it’s worth, there are tons of free articles on our website to help you get started, and we even published all our templates for free! If you want to automate things even further, check out our eQMS software, Formwork.

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 consulting? We’re a small company, so we can’t take on everyone – but maybe we have time for your project? We guide startups from start to finish in their medical device compliance.


Leave the first comment