Writing a Software Development and Maintenance Plan for IEC 62304 Compliance

Check It Out: Free Video Available

While you’re gathering your motivation to read yet another article on regulation, let me jump in briefly! We’ve actually recorded a video on this topic in the meantime. I think this video will help you understand the topic even better because it’s to-the-point and super concrete. After watching it (and reading this article), you should be able to write your own documentation. Check it own below and take a look for yourself!

And if you liked this video, take a look at our Wizard which includes step-by-step instructions, templates and videos for even more topics. It’s way cheaper and more efficient than paying consultants (like us) to explain it to you. Startups love it and I’m sure you’ll like it, too!

But now, let’s move on to the actual article.

Introduction

If you’re developing software in an IEC 62304 – compliant way, you need to document certain things about your software development (no surprises there). While some things may be company-specific, other things are more product-specific.

Something company-specific could be how you develop software. An example for something product-specific could be that you use Python as a programming language for a certain project.

It makes sense to put the product-specific things into a so-called Software Development and Maintenance Plan. That sounds more fancy than it actually is: It’s just a document in which you describe stuff.

Great. Let’s see what you need to include.

I’ve also open-sourced a software development and maintenance plan template. Feel free to open that in another tab while reading this article. It also has lots of explanations.

Software Development Plan Content

Processes

Mention the processes which you’ll be using for your software development activities. Typically, this would include your Software Development, Risk Management, Usability and Problem Resolution processes.

Required Resources

List who will be working on this software and in what role. Typically, you will have some frontend and backend developers. You also should mention them by name.

Next, talk about the technical resources you need. At the minimum, you need a compiler or a runtime (e.g. CPython 3.8). You’ll probably also have some sort of IDE software.

The IEC 62304 also specifically talks about how you “plan to avoid common software defects based on your selected programming technology”. Translated to human language, this means that your programming language may introduce problems. Those could be something like “hey we could have runtime exceptions because Python is dynamically typed”. Here’s a good place to mention how you plan to avoid those. In this example, you could say “oh my god, our test coverage is so great that we’ll never run into runtime exceptions, ever”.

Configuration Management

Describe how you do configuration management. Wait, what’s that? That’s simply what sort of version control software you use (I’d guess it’s git), how you name versions and how you create branches / merges during development.

Verification Activities

Next, describe how you do verification. Software verification is yet another vague term, but for practical purposes, let’s just say that that refers to “code review” in human language (you could also do other stuff like static analysis, feel free to go into more detail here).

So: Describe how you do code review and especially according to which criteria a code review is “passed” for this software. Do you follow style guides? There’s PEP8 for Python. How do you enforce those? Do you have linters? Does the code reviewer also check whether the code actually implements the software requirement, i.e. does it actually do what it was supposed to do?

Software System Test Activities

Describe how you test your software. Typically, you’ll have some CI tests running on each Pull Request (do you?). Describe how that works, where the results are saved and what happens in either case (pass / fail).

Maintenance

Finally, state for how long you plan to maintain this software. This is quite important because it has implications in your risk management: The longer your software is on the market, the more things can go wrong.

Software Development Plan Template

Check out my totally free software development and maintenance plan template which includes all sections mentioned above with some further explanations. And let me know if anything’s unclear. Good luck!

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.

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

Comments

Leave the first comment