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

Articles Technical Documentation

Updated May 24, 2023

ISO 14971 Walkthrough

Dr. Oliver Eidel

When developing software as a Medical Device, you need to do Risk Management. What’s that?

In simple terms, you need to think about what could go wrong with your software and how that would harm patients. As an auditor put it, “you do risk management in your head all the time anyway, you just need to write it down!”. Sounds easy. It almost is!

If you haven’t gotten your hands on a PDF copy of the ISO 14971, head over to my article on accessing standards for less than 30€. You won’t get around reading the standard so you might as well start now.

Alright, let’s get down to business and see what needs to be done.

ISO 14971 Requirements

Compared to the IEC 62304 (see my walkthrough), the ISO 14971 is substantially shorter. That means that understanding the work involved typically only takes two years. Kidding. Maybe an afternoon or a few days. Unless your consultant over-engineers it. That could force your company to do risk analysis for 6 months - I’ve seen this happen!

Let’s stop the ranting and look at the work. As always, it’s all about setting up processes and creating documents.

Risk Management Process

You need to have a process for risk management. This process should describe how you systematically and regularly analyze product-based risks at your company.

How is this implemented? Typically, you’ll write a document which is a SOP (Standard Operating Procedure) for your risk management and train your team to actually adhere to it.

As part of this risk management process, you’ll create a risk management plan, risk analysis & risk table and risk management report.

Risk Management Plan

The risk management plan is a document in which you describe how you plan to do risk management for a certain product. It typically includes roles and methods.

Risk Analysis & Risk Table

The actual risk analysis is by far the largest chunk of work. In simple terms, you need to list all things which could go wrong with your software and what would subsequently happen to patients. Obviously, you can go into infinite detail here so it’s important to strike a balance between “detailed enough” and “getting it done”.

Article

FMEA, Part 1: Risk Acceptance Matrix (ISO 14971 Risk Analysis)

Read

Risk Management Report

Once you’re done with risk analysis, e.g. before shipping the initial version of your software as a medical device, you summarize everything in a document called risk management report. This hardly contains any new information, except one important thing: It states whether, in summary, you think your risks are acceptable.

Post-Production Activities

There are various post-production activities involved in risk management. You probably could have guessed this - risk management doesn’t magically end when you ship your medical device for the first time.

Instead, you need to continuously check whether new risks are discovered which may harm patients. And of course, as soon as you start changing your software, new risks could be introduced and all your documentation needs to be updated.

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!

Comments

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.