Risk management for medical software: ISO 14971 without the stress

Earlier in this series we covered what Software as a Medical Device is and how the IEC 62304 software safety classes work. Both of those came back to one word: risk.

This post looks at risk properly, through ISO 14971:2019, the international standard for risk management of medical devices. If any part of the system sounds daunting, it is often this one. It does not need to be.

At heart, ISO 14971 asks a question your team already asks: what could go wrong for the people who use our product, and what are we doing about it? The standard simply gives that conversation a shared vocabulary and a clear order, so the answers are thorough and easy to follow.

You know your product better than anyone. That makes you well placed to do this well.

Five words that unlock the standard

Most of the confusion around ISO 14971 comes from a handful of terms that sound alike. Here they are, using the standard's own definitions (clause 3).

• Harm (3.3): injury or damage to the health of people, or damage to property or the environment.
• Hazard (3.4): a potential source of harm.
• Hazardous situation (3.5): a circumstance in which people, property or the environment are exposed to one or more hazards.
• Risk (3.18): the combination of the probability of harm occurring and the severity of that harm.
• Residual risk (3.17): the risk that remains after you have put your risk controls in place.

The key insight is that harm does not appear from nowhere. There is a sequence of events from a hazard, through a hazardous situation, to harm. Your job is to understand that chain and break it in the right places.

A software example, step by step

Take the insulin dose calculator from the previous post.

1. Something goes wrong in the software. A unit conversion error causes the calculator to recommend a dose that is too high.
2. The hazard. An excessive dose of insulin is a potential source of harm.
3. The hazardous situation. The patient follows the recommendation and injects, and is now exposed to that excess insulin.
4. The harm. The patient experiences severe hypoglycaemia.

Notice where the software sits. It is rarely the hazard itself. It is usually a link in the sequence of events that leads to one. That way of thinking is what makes risk analysis for software workable, because it tells you exactly where your controls can act.

The steps, in order

ISO 14971 sets out a process you follow and then keep alive for the life of the product.

1. Set your criteria before you start. Top management defines a policy for establishing criteria for risk acceptability (clause 4.2), and your risk management plan sets the criteria for this product (clause 4.4 d). Deciding in advance what "acceptable" means keeps later decisions fair and consistent.

2. Analyse the risks (clause 5). Describe the intended use and reasonably foreseeable misuse (5.2), identify the characteristics related to safety (5.3), identify the hazards and hazardous situations (5.4), and estimate the risk of each (5.5).

3. Evaluate them (clause 6). Compare each estimated risk against your criteria. Is it acceptable, or does it need reducing?

4. Control them (clause 7). This is where the standard is most helpful, because it tells you which kind of control to reach for first (clause 7.1):

• Inherently safe design. Change the product so the problem cannot happen. For example, the calculator refuses any dose above a clinically set maximum.
• Protective measures. Detect the problem and protect the user. For example, an unusually high recommendation triggers a clear confirmation step.
• Information for safety. Warn or train. For example, the instructions for use explain how to check a recommendation.

You then implement each control and verify that it works (7.2), evaluate the residual risk (7.3), weigh benefit against risk where a residual risk is still not acceptable (7.4), check that the controls have not created new risks (7.5), and confirm you have covered each hazardous situation you identified (7.6).

5. Look at the overall picture (clause 8). Step back and judge whether the overall residual risk is acceptable when weighed against the benefits of the product.

6. Review before release (clause 9). Confirm the plan was carried out and record the outcome in a risk management report.

7. Keep listening (clause 10). Once the product is in use, collect and review information from the real world, such as complaints, support tickets and feedback, and feed it back into your analysis.

The EU Medical Device Regulation asks for the same order of priority for risk controls in Annex I, section 4, and requires a risk management system under Article 10(2). Doing this once, well, serves both.

What about probability for software?

This is where many teams get stuck, and the answer is reassuring.

It is hard to put a reliable number on how often a particular software bug will occur. The IEC 62304 guidance (Annex B, section B.4.3) recognises this. For the software failure itself, it suggests assuming the worst case. Where you cannot estimate the rest of the sequence either, it suggests focusing your evaluation on the severity of the harm.

In practice, that frees you from inventing statistics. You can concentrate on two things you can genuinely reason about: how bad the harm could be, and what stands between the failure and the patient. Where other parts of the chain can be estimated, such as how often a clinician would catch a wrong result, you can use that knowledge too.

The risk file is a living record

A risk management file is not something you write once and put away. It grows with the product.

New features add new risks. A bug report might reveal a sequence of events you had not considered. A change to a third-party library might affect a risk control. Each of those goes back through the same steps: analyse, evaluate, control, verify.

This is also why risk connects to so much else. Your risk controls often become requirements. Those requirements need tests that show the controls work. Your releases should show that the risk review happened. And your complaints feed back into the analysis. In the final post of this series we will show how these connections form one system.

You do not have to get it perfect on day one

Risk files start small. A first version might cover a handful of hazardous situations, each with a clear control and a verification. That is a real, useful starting point, and it gets better each time you learn something new about how your product is used. Our guide to the QMS a medtech startup needs in year one shows where the risk file sits among your other early records.

The teams who do this well are not the ones with the longest spreadsheets of hazards. They are the ones who think honestly about their users, write down their reasoning, and keep it current.

How we help

QualiHQ keeps your risk analysis as a living register for each product, recording each risk before and after its controls, and brings it into a risk review as part of each release. AI suggestions help you get a first set of risks on the page, and you stay in charge of each judgement.

Next in this series, the final post: how ISO 13485, IEC 62304, ISO 14971 and the other standards fit together into one working system.

Book a demo and let us show you how a living risk file fits into your everyday work.