Essential ISO 14971-compliant software guide for MedTech leaders

Developing medical software goes far beyond writing code – it requires a systematic approach to risk analysis. To ensure safety, you need to build an ISO 14971-compliant software. Here’s how to get started.

TL;DR – what does ISO 14971 require for software?

ISO 14971 is an international standard that provides manufacturers with a framework for risk management of medical devices (including medical software). By complying with ISO 14971, you meet the risk management requirements specified in the Medical Device Regulation.

The risk management process of the ISO 14971-compliant software is multistep. First, you must prepare a risk management plan, including all the information about assessing risks throughout the medical software's life cycle.

Then, you will go through six crucial steps – risk analysis, risk evaluation, risk control, evaluation of overall residual risk, risk management review, production and post-production activities. Simply put, each step focuses on identifying, reducing and managing different risk areas.

Although the ISO 14971:2019 standard includes crucial information about managing risk, you might want to get to know ISO/TR 24971, which offers numerous guidelines for medical software manufacturers.

What is ISO 14971?

ISO 14971:2019 (Medical Devices – Application of risk management to medical devices) is an international standard containing requirements for the manufacturers of medical devices (including software as a medical device and in vitro diagnostic medical devices) in terms of developing and maintaining a risk management process through the life cycle of the product.

This document provides comprehensive instructions to manage risk associated with medical devices, including medical software. This standard explains key concepts and lays out a structured process for a risk analysis through development, production, and post-production.

ISO 14971 is a roadmap to ensure that potential risks are recognised, minimised, and properly tracked to maintain patient and user safety.

Do I need to meet ISO 14971 requirements when developing medical software?

If you intend to develop medical software you are obliged by the Medical Device Regulation to prepare a risk management strategy.

Even putting regulatory requirements aside, it is worth remembering that medical devices directly affect people's health. Thus, for users’ safety, it is crucial to identify and manage risks throughout the software's or medical device’s life cycle.

Also, meeting the requirements of ISO 14971:2019 enhances your medical software’s reliability and marketability.

So, let’s dive into that topic and explain every step of this process.

What are basic definitions for ISO 14971-compliant software?

Let’s start with some basic definitions we will be using to discuss the software compliant with ISO 14971.

The three terms you will encounter most often when reading ISO 14971 are:

• harm is an “injury or damage to the health of people, or damage to property or the environment”,

• hazard is a “potential source of harm”

• hazardous situation is “a circumstance in which people, property or the environment is/are exposed to one or more hazards” (source: ISO 14971).

To understand it better, check out the examples of hazards, hazardous situations, and harms in the table below.

What is risk according to ISO 14971?

Risk is a certain probability that a hazard may lead to a hazardous situation and then to harm, and how severe that harm will be for the patient, user or environment.

Yet, bear in mind that hazards are not risks. Hazards indicate the potential source of harm. On the other hand, risks result from analysing the frequency of occurrence and potential hazards. Check out the examples in the table below.

What is demanded from ISO 14971-compliant software?

The manufacturer is obliged by the ISO 14971 to establish, implement, document, and maintain an ongoing process of:

• identifying hazards and hazardous situations associated with a medical device,

• estimating and evaluating the associated risks,

• controlling these risks,

• monitoring the effectiveness of the risk control measures.

All of this has to be applied throughout the entire life cycle of the medical software and recorded in a risk management file.

What is the point of the risk management file?

The risk management file serves as the repository documenting all activities related to risk management. It provides complete traceability for every identified hazard, detailing how each risk was assessed, controlled, and verified for effectiveness.

By maintaining this structured record, manufacturers can demonstrate compliance with ISO 14971 requirements, ensure consistency across development stages, and provide clear evidence during audits.

What does the risk management process consist of?

We’ll break down the risk management process step by step to make it as easy to understand as possible. Basically, this process is built around six main parts:

• risk analysis,

• risk evaluation,

• risk control,

• evaluation of overall residual risk,

• risk management review,

• production and post-production activities.

We’ll take a closer look at them, but first let’s talk about the risk management plan – the basis for all actions required by ISO 14971.

What belongs in an ISO 14971 risk management plan?

We can’t just jump into the risk analysis without a plan! Consider a risk management plan as a roadmap for how your company finds, assesses, and reduces risks throughout the medical software’s life cycle.

Risk management plan should include:

• the scope of the risk management activities,

• assignment of responsibilities and authorities,

• requirements for review of risk management activities

• criteria for risk acceptability, based on the manufacturer’s policy,

• a method to evaluate the overall residual risk,

• activities for verification of the implementation and effectiveness of risk control measures (e.g., testing and validation),

• activities related to the collection and review of relevant production and post-production information.

The risk acceptability might’ve caught your attention when going through that list. So, what is it? Regarding medical devices, not every risk can be eradicated – so, what level of risk is still acceptable? ISO 14971 requires manufacturers to have a policy on risk acceptability, which sets the rules for deciding when a risk can be considered low enough.

This policy defines how risks should be controlled, for example, reducing them “as far as possible” or keeping them “as low as reasonably achievable” (ALARA) without reducing the device’s benefits.

For example, a radiation therapy device may follow ALARA principles to limit radiation exposure. At the same time, a diabetes app may define criteria ensuring that the clinical benefits clearly outweigh any small residual risks.

We encourage you to take your time when developing a risk management plan, as you will regularly come back to it when going through the next steps of the risk management strategy.

How to perform risk analysis according to ISO 14971 – a step-by-step guide?

Risk analysis is a “systematic use of available information to identify hazards and to estimate the risk” (source: ISO 14971). It consists of four steps: intended use and reasonable foreseeable misuse, identification of safety-related characteristics, identification of hazards and hazardous situations, and risk estimation.

Step 1 – Intended use and reasonable foreseeable misuse

If you are developing a medical device, you’ve probably already stated its intended use, including other necessary information such as user profile, use environment, operating principle, etc.

If by any chance you haven’t gotten through that process, you should write down the intended use (or intended purpose) as it’s demanded not only by ISO 14971 but also by the Medical Device Regulation.

You are also obliged to document reasonably foreseeable misuse – situations where your medical software is used in a way that wasn’t intended but can be anticipated based on predictable human behaviour. For example, suppose your software is designed for use only by healthcare professionals. In that case, you should still consider the possibility that a patient might access the app and enter incorrect data, leading to misleading results.

Step 2 – Identification of characteristics related to safety

Next, a manufacturer must identify characteristics related to safety. They are features or properties of a medical software that can influence whether it is safe to use. Simply put, information about your device, such as screen layout, response time, and data integrity, could make a difference between safe operation and a potential hazard.

Once you identify them, you should define their acceptable limits, e.g., maximum capacity, minimum accuracy tolerance.

Step 3 – Identification of hazards and hazardous situations

We already know the definitions of hazards and hazardous situations. Now is the time to identify and document any known and foreseeable hazards which can be associated with your medical software. You should consider the sequences or combinations of events that can result in hazardous situations for each of them.

Step 4 – Risk estimation

Once you document all the hazardous situations, you should estimate associated risks using available information or data. You can gather information for assessing risk from many sources, such as published standards, scientific investigations, clinical evidence, expert opinion, and more.

During this risk analysis step, you consider the probability of the occurrence of harm and the severity of the harm. But how exactly can you establish the severity of it?

To determine severity, you start by asking: what could happen to the patient or user if this risk occurs – is it mild discomfort, temporary deterioration of health, serious injury or death? Severity focuses on the consequences of the hazardous situation, which is often categorised using qualitative scales, for example:

• negligible – no injury or slight injury,

• moderate – reversible or minor injury,

• significant – death or loss of function or structure (source: ISO/TR 24971).

Once you do it, you can compare the severity to the probability of occurrence, and form a matrix that supports decisions on whether you need to reduce the risk or consider it acceptable.

This kind of matrix can look like the table below (as proposed by ISO/TR 24971).

Which tools are used in risk analysis activities?

There are many methodologies which can be implemented in your organisation to help you during the risk analysis activities.

Some suggested in the guidance for ISO 14971 are:

• Preliminary Hazard Analysis (PHA),

• Fault Tree Analysis (FTA),

• Failure Mode and Effects Analysis (FMEA),

• Hazard and Operability Study (HAZOP),

• Hazard Analysis and Critical Control Point (HACCP).

At Revolve Healthcare (custom medical software development company), our Regulatory Affairs Team uses FMEA (Failure Mode and Effects Analysis). The main idea of this method is asking the question “what happens if…?”. For example, in medical software compliant with ISO 14971, FMEA can reveal that the program could calculate the wrong drug dose if a user enters the incorrect data.

A supporting element of FMEA is that it incorporates a “bottom-up mode”, which means that you start at the lowest level of the system and then work your way upward to see how failures could affect the larger system.

Risk evaluation in ISO 14971 – why do you need this?

Risk evaluation is a complementary process to the risk analysis. During this step, a manufacturer compares the estimated risks with the criteria for risk acceptability, which your company previously estimated. Essentially, you look at the identified risks and ask yourself if they are small enough to accept or need to be reduced.

For example, if a medical imaging software could mislabel patient scans, implementing automated cross-checks with patient IDs and mandatory user verification before saving any changes is a risk reduction measure.

How do I implement risk control per ISO 14971?

Another thing you, as a manufacturer, are obliged to do is set and implement risk control measures. What are those? Well, those are measures which reduce or maintain risks to acceptable levels. They can reduce the severity or the probability of occurrence of the harm.

ISO 14971 suggests options for managing risk control measures. It can be:

• inherently safe design and manufacture,

• protective measures in the medical device itself or in the manufacturing process,

• information for safety and, when appropriate, training to users.

Bear in mind that you not only have to set them but also verify their implementation and effectiveness.

But that’s not all when it comes to risk control. You also need to go through three mandatory steps.

1. Evaluation of the residual risk

   After that, you should evaluate the residual risk (risk remaining after risk control measures have been implemented) using the criteria for risk acceptability, which you’ve previously defined in the risk management plan.
   
   

2. Benefit-risk analysis

   The next step is very crucial. Imagine that residual risk is considered unacceptable. In that case, you have to conduct a so-called benefit-risk analysis. In this scenario, you gather and review data to determine if the benefits of the intended use outweigh this residual risk.

   Think about this example – you have an insulin dose calculator app. Despite multiple controls, there’s still a slight chance the software could miscalculate a dose. Yet, it may be acceptable because the benefit of glucose control using the app significantly reduces long-term complications of diabetes

   And what if the risk outweighs the benefit? It must be lowered to provide users with safe medical software, or you would have to rethink its intended use.
   
   

3. Risks arising from control measures

   Adding control measures to reduce risk in medical software doesn’t end your job yet. Each new control measure needs to be checked because sometimes they can create new hazards and hazardous situations.

   For example, changing the user interface might lower one risk but accidentally increase another, making it harder to notice critical information. That’s why every fix needs to be double-checked to make sure that there are no new issues.

   And if you identify new hazards or hazardous situations, you need to conduct a risk analysis from the beginning.

How to evaluate the overall residual risk?

We are getting closer to developing ISO 14971-compliant software. While conducting overall residual risk assessment, you look at your medical software as a whole. Before that, you’ve been analysing each risk independently, but now they must be considered together.

For example, an app for people with diabetes might have a slight chance of showing the wrong glucose trend and a small chance of dropping some data. Each issue alone may be acceptable, but combined, they could confuse the user. That’s why manufacturers check the big picture – weighing all the remaining risks against the device's benefits.

What is a risk management review?

We are almost there – a risk management review is a step that ensures that the entire risk management plan has been carried out according to the risk management plan, that the overall residual risk of the device is acceptable, and that processes are in place to monitor safety once the device is in use. It’s a final checkpoint before the commercial release of your medical software.

What activities are included in production and post-production phases?

Some new information might come up during production or after releasing the medical software. That’s why it’s so essential to maintain a system to collect:

• information generated during the production and monitoring of the production process;

• information generated by the user;

• information generated by those accountable for the installation, use and maintenance of the medical device;

• information generated by the supply chain;

• publicly available information; and

• information related to the generally acknowledged state of the art.

What’s more, the manufacturer is obliged to review collected information for possible relevance to safety. And in case it is relevant to safety, one must undertake some actions, e.g., review the risk management and determine if reassessment of risks or new risks is necessary.

This kind of post-market surveillance is a key part of ISO 14971 risk management. It helps manufacturers track how devices perform in real-world use, spot unexpected risks, check if safety measures work, and stay compliant with regulations – ensuring devices remain safe and reliable over time.

And that’s it! We made our way through developing 14971-compliant software.

What’s the difference between ISO 13485 and ISO 14971?

ISO 13485:2016 (Medical Devices – Quality management system – Requirements for regulatory purposes) is a QMS (quality management system) standard for medical devices. It tells manufacturers how to organise their processes to design, produce, and deliver safe medical devices.

On the other hand, ISO 14971 focuses on identifying, evaluating, and controlling risks throughout the device’s life cycle. You can think of it as a complementary to ISO 13485 which helps build a robust risk management process within the QMS.

The short summary of those two would be:

• ISO 13485 is about running a company in a way to make safe medical devices

• ISO 14971 is about handling risks to keep users of the devices safe.

What’s the difference between ISO 14971 and ISO 24971?

While reading this article, you have probably noticed that we have referred you to ISO/TR 24971 (Medical Devices – Guidance on the application of ISO 14971) several times.

This document offers numerous guidelines for medical software manufacturers in risk management. It is a supplementary paper we encourage you to read, as it may answer many of your questions about ISO 14971.

ISO 14971 and IEC 62304 – complementary standards

IEC 62304 and ISO 14971 are strictly connected. IEC 62304 focuses on applying risk management principles in software development. Notice that IEC 62304 is only about the medical software life cycle, whereas ISO 14971 is general risk management for both hardware, software, and other medical devices.

How to build an ISO 14971-compliant software?

The most important thing is not to neglect risk analysis and to carry out this process regularly throughout the product life cycle. This process may seem overwhelming, but it is essential to ensuring the safety of your medical software users.

To sum up, you should:

1. Plan your risk management process and write it down in a risk management plan.

2. Perform risk analysis.

3. Conduct risk evaluation.

4. Set and implement risk control measures.

5. Weight all the remaining risk against the device’s benefits.

6. Go through the risk management review.

7. Maintain the risk management file.

It is worth having someone on your team who knows the regulations in and out and will moderate risk analysis meetings, preventing other participants from burning out. We encourage you to consider your choice of the right person carefully to make sure your software is compliant with ISO 14971.

At Revolve Healthcare, we have an in-house Regulatory Affairs Team that supports development teams as they work on medical software. This way, we do everything possible to help our clients offer safe solutions. To see how we do this, check out our case study on the MDR class I, IEC 62304 class B Blended Psychotherapy system.