Risk management in medical devices
By: Mateusz Knyć
Is risk management in medical devices important? Or should it say „why is the 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 put 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 on 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
We already know, that ISO 13485 (link) is the standard to follow when developing medical devices. It’s a so called risk-based standard. Meaning that we should think about activities and processes we do in the context of 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 truth be told, when there is a flexibility, there’s also more work required on the manufacturer’s side. Consequently, we can’t just “do what the ISO says and forget”. We must do our own 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. It 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 than 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 nearest future, but at the same time inevitable.
I mentioned about the negative consequences of neglecting software validation in one of the previous articles that led to developing of 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 on 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 to be updated, hardware needs to be upgraded, 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, approach is very simple and particular medical device agnostic
Each of these steps can be further expanded into much more details. 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):
The source of the data used to create the chart and the chart template comes from:
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.
I believe it’s worth pointing out – risk management in medical devices is not a solo job. It is performed at every stage of the product development and as such there are many stakeholders that 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.
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.