Risk management in medical devices

people who working on risk analysis in medical devices project

Is risk management in medical devices important? Or should it say „Why is risk management important”? We do risk management all the time. Both in our everyday life and in our business, quite often not even realizing that. When crossing the street or when choosing a business partner. It doesn’t cause that much fuss, it’s obvious, isn’t it?

And now someone (“the ISO guy” maybe) tells you that if you want to develop medical devices you need to pay strong attention to risk management and make it explicit. Actually, in everything you do, you always have to stay on your toes for the risks it may entail.

But here’s the catch: not at your risk.

The key to risk management in medical devices is the safety of patients and users of our products. Yes, we specifically need to think about what could go wrong when someone uses our products. And how we can prevent, or at least minimize, the potential negative effects.

Standards-based on risk management in medical devices

We already know, that ISO 13485 (link) is the standard to follow when developing medical devices. It’s a risk-based standard. We should think about our activities and processes in the context of the risks they introduce to our product.

This approach is both sensible and quite flexible. It is also used in other well-established standards like ISO 27001 (link), and also in regulations like General Data Protection Regulations (GDPR). But the truth is that, when there is flexibility, more work is required on the manufacturer’s side. Consequently, we can’t just “do what the ISO says and forget”. We must do our analysis and make our own decisions that we’ll need to be able to justify during audits.

Is it any different for software?

When thinking about medical devices we imagine things like respirators, syringes or CT scanners. We barely think of software, either standalone or as a part of physical devices, as medical devices. But software is one of the fastest developing areas out there. This is even more true of the medical devices field.

One of the hottest topics recently is using Artificial Intelligence (AI) for… well, for almost anything that can be done using computers.” And this has already got ahead of current regulations and guidance. Certifying AI-based products will be one of the hardest tasks out there for the near future, but at the same time inevitable.

I mentioned the negative consequences of neglecting software validation in one of the previous articles that led to the development of the IEC 62304 standard. And guess what? IEC 62304 also addresses risk management in medical devices all over the guidance.

Just like a respirator device can break down, our software product may malfunction as well. It’s easy to imagine mechanical parts to wear off. But how should we know when our software will start to work incorrectly? How will we know it has even malfunctioned? And what will it mean for the patient?

The good news about software

It doesn’t wear off. If we keep using it in the environment we designed it for, feed it with data we tested it with, and so on – it will always work as expected. Or rather – as designed. And this is the bad news – any bug in the software is actually designed. And the assumptions on the environment or data rarely ever withstand the test of time.

Operating systems need updating, hardware needs upgrading, and CT scanners will provide data in higher resolutions. All this may reveal errors in our product we were not aware of (even though we had been trying to foresee them). And using AI just adds another whole new level of complexity and uncertainty.

So, is it any different, really? I am afraid I cannot provide a definitive answer. But for sure, this is a specialized field that requires an open mind and broad thinking, beyond the current moment in time.

Approach to risk management in medical devices

ISO 13485 and ISO 14971 (link) are tightly coupled together. ISO 14971 is THE standard for risk management in medical devices – when developing medical devices. Actually I personally find it one of the best standards I have ever had a chance to read. However, in our case we should strictly consider also IEC 62304 (link) in the process.

On the high level

First, we need to identify risks – and find out what risks our product might introduce.
Then, we shall evaluate those risks – determine how often they might occur and how severe the effects might be. BTW: do you remember about designing bugs (and thus risks) and how hard it is to foresee their probability of occurrence?
And then we shall control risk. That means we shall introduce mechanisms that will allow us to eliminate (hopefully) or at least mitigate particular risks.
Yes, typically we mitigate risks one by one, but we won’t be able to eliminate all the risks. And even though we minimize all of them to a level as low as possible. And it might turn out that all of these residual risks still sum up to quite a risky product. Therefore residual risks analysis shall be done at the end.

Risk analysis – think ahead

It is possible to provide more detailed information about each of these steps. But those details will differ depending on the type of products you are developing. And yes, those details need to be noted in Standard Operating Procedures of your QMS.

What is worth reminding, is that risk management in medical devices is a continuous process, and not series of one-time events. You might have heard that the later in the process of software development a bug is discovered, the more expensive it is to fix (often magnitudes higher):

chart presenting relative cost to fix bugs, based on time of detection, risk management in medical devices

The source of the data used to create the chart and the chart template comes from:
https://deepsource.io/blog/exponential-cost-of-fixing-bugs

And pretty much the same goes for risk analysis. If you figure out at the very end of the project that particular solution to mitigate the risk requires that complete rebuilding of architecture, it might jeopardize the whole project. So instead of thinking of risk management in medical devices as a way to produce great and safe product, you might consider it to be just an additional obstacle to releasing the product, but in the long run it actually might prove to be a more risky strategy.

text on risk management in medical devices and ways to mitigate the risk

Interdisciplinary team

I believe it’s worth pointing out – risk management in medical devices is not a solo job. It performes at every stage of the product development and as such many stakeholders might have an impact on the process. These might be clients and doctors who will be using the product, developers who know about technical limitations and project managers who need to ensure sufficient budget for the development of additional control mechanisms. These might even be marketing guys, who will be preparing marketing materials and can’t provide misleading information. Seriously, they can’t lie in advertisements (and for that reason they need to know the product).

So, what shall we show to the auditor?

Typically, an auditor will not be looking through each and every risk you have analised. But for sure they will want to find out about your approach, hear the justification for it, see your risks list/matrix and risk summary report. So yes, we prove the process works through documentation. And even though it’s up to the manufacturer on how exactly he does that, it might be sensible to consider using one of the widely known methods for risk analysis (I think that would be FMEA-based one) and following ISO guidelines as to documents’ contents.

Risk management in medical devices – the new kid on the block

The General Data Protection Regulation, or GDPR. It’s already over 2 years old, but when it comes to law and regulations time goes slowly and global adaptation takes time. GDPR is not a “medical standard”, it concerns personal data. But isn’t software built mostly to process patient’s data in one way or another? And then yes, we need to follow GDPR rules as well.

GDPR itself is a big regulation with many nuances. But for our today’s post there are two concepts we should mention, often abbreviated as PbD.

These are:

Privacy by Design, which obliges manufacturer to think about user’s data protection right from the start, from the moment you are designing the product and not as something to add at the end of the project, if we still have time and budget.
This goes perfectly well with the design phase in ISO13485 and it’s also worth to include risks and related controls in the risk matrix.
Privacy by Default, which instructs a manufacturer to set up the application in such a way, that it provides protection to patient’s data by default. And not only after patient/doctor/IT guys make additional configuration changes. Think for example of allowing access to particular patient’s examination results only to that patient’s doctor, and not the whole hospital department.Since this quite often might be configuration settings, it’s worth including in procedures related to product handover and maintenance.

Risk management in medical devices – summary

Answering the very first question – risk management in medical devices is not important, it is critical. At the same time, if thought of from the beginning of the project, it might as well fit into the regular development process itself. Providing users with safer software and better experience (there’s another standard for making sure of that, IEC 62366-1, just in case you were curious). Standards and guidelines are there, but specifics require manufacturers to figure out their own way of managing risk. But the benefits of that far outweigh the cost and time invested into it. And if that doesn’t convince you or your team, it still is required and better to handle risks your way than the hard way.

See the previous post by Mateusz Knyć: IT provider with ISO 13485 – is it really crucial?