Early access registrations are open for Headstart, a predictable, fixed-price program for becoming compliant.

Updated May 11, 2021

ISO 14971 Walkthrough

Dr. Oliver Eidel
ISO 14971

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 analysi & 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.

Congratulations! You read this far.

Get notified when I post something new.

Sign up for my free newsletter.

I work as a regulatory consultant for Healthcare software startups. I try to publish all my knowledge here so that startups can certify their medical devices themselves in the future.

If you're still lost and have further questions, just send me an email and I'll be happy to answer them for free. More about me

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.