The guide to tool validation for medical device development

The inadequate and ill-informed tool validation process is often the reason why medical devices are not considered safe to use and compliant with the medical standards by the FDA, the EMA (with their MDR), the MHRA UK and equivalent regulatory bodies in different countries. It’s also a process that’s commonly overlooked by medical device manufacturers, including software providers.  

In today’s blog post, we focus on providing actionable advice for building your own tool validation process for any medical devices you develop, with support from our Healthcare and Life Sciences Business Unit Director, Krzysztof Minicki.

Why validate medical device development tools? 

Before you start thinking about validating medical device development tools, make sure that the tools you’re about to assess are not eventually a part of the medical device. They could be anything that supports medical device development (including software), but that you can’t include in the final product as such. 

Why should you validate these tools? 

First things first, you’re obligated to validate these tools because otherwise, you wouldn’t be able to fulfil the requirements posed in the medical standards such as IEC 62304 or ISO 14971.  

To give you an example, imagine that you manufacture medical devices and use versioning software that supports your development and your Quality Management System. If this software backslides, your labelling system won’t work correctly either. The device itself could still be functional, but your device tracking system fails if the versioning is inoperative. 

Another example is a workflow management system that supports your requirement management and change approval. If it’s unusable for any reason, then you can’t guarantee that the medical devices you produce will be fail-proof. The list goes on, but due to the nature of the medical device development process, if one element fails and/or is unstable, the entire system is considered dysfunctional. A misstep at any stage means that we’re no longer able to claim that we follow the medical standards for our processes. 

Therefore, the main goal of the medical device development tool validation is to minimise this risk and mitigate any threats associated with it. 

Once you set out to assemble the validation process, consider the risk of the occurrences following the failure of the tools you’re about to validate. What would happen if this tool broke down, and how severe would the consequences be? Consider the validation process from the perspective of our processes, the procedures that we follow, and the daily work of the people involved: developers, testers, Scrum Masters and analysts. This initial assessment will help you understand what approach you should take when validating medical device development tools.  

How to build your validation process for medical device development tools? 

It’s worth mentioning that each organisation needs to build their own process. However, there are certain elements that are crucial for the process and make it successful. Regardless of these elements, the process’s foundation should always be a risk-based approach where you assess each segment based on the risk it poses to other features and the severity of the potential threats. 

Use the following 4-step process as a list of the best practices for creating a self-sufficient tool validation procedure aligned with the medical norms such as IEC 62304, ISO 13468 and ISO 14971.  

Define the requirements 

What are the requirements for the tool? What should it do and deliver? Prepare a guideline or a statement of work with descriptions of what the tool does, its specificity, the intended use, the functionalities, a list of areas it will impact, the stakeholders as well as the processes it will be included in.  

If the tool itself can pose more risk to our development process, we can make these descriptions far more advanced and detailed. If not, we can keep them short and to the point. 

Assess the risk 

Based on the descriptions from the step above, assess the overall risk from the perspective of: 

• What would happen if the tool didn’t work? 
• What would happen if the people who use the tool made a mistake? 
• Is using this tool understandable and apparent, or does it require any expert knowledge or training? 
• What would happen in case of any issues with the tool’s supplier? 

It’s also essential to assess how configurable the tool is. If the tool is an off-the-shelf product with low configurability, then the risk of failure will be decreased as well. In case of a higher level of configurability, the risk will increase. 

Define the validation process 

There are two paths that you can take here. 

If the intended use is straightforward, the tool itself is controllable, doesn’t require any configuration, and the risk is low, you can validate it using qualification – it’s enough to follow the two steps above. 

If the tool is highly configurable and used on a few different levels, i.e. for change, requirement and test management, you need to have a more advanced validation process in place. If the tool is multi-purpose and can be configured in a few different ways, then consequently, the risk will be higher as well – you can’t risk not knowing if the changes you introduced have been properly processed and approved. The same goes for the tests, the requirements, the reports, etc.  

In that case, the first step is to define the processes where you use the tools and check what steps are required for each of them. Then focus on listing requirements and writing test cases. Although this validation process may sound burdensome and lengthy, it’s the only way to ensure that the tool will be working as you intend it to do. 

After these two steps, it’s time to assess the tool’s functionalities by responding to these questions: 

• Is the tool installed correctly? 
• What about its performance and efficiency? Will it function without fail even when used in several projects and by multiple persons at once? 

Once this stage is completed and the validation tests are done, you can decide whether to use the tool. 

Conduct regular re-validations 

Tool re-validations can be tricky, and at times, it can be challenging to assess whether to go through the entire process once more, i.e. if the software that we use has been upgraded. So, before you embark on this course, make sure that you have detailed information on: 

• What does this upgrade include? In case of any new functionalities, what impact may they have on the tool’s configuration? 
• What is the reputation of the tool’s supplier? 

If we have answers to these questions and the changes don’t pose too much risk to our development process, we can conduct a short validation based on the critical points we’d defined before the validation process. These points are the backbone of the tool, and we know they cannot fail for the tool to be working correctly. We can also introduce test automation to help us go through the entire process quicker. After it’s completed, we need to report confirmed, and that the re-validation process has been successful. 

Over to you 

As you can see, building a tool validation process that will work for your business can be challenging and lengthy, but it will give you a competitive advantage and an ability to address any requirements of the IEC 62304, ISO 14971 and ISO 13485.  

If you need any support, you can always check our medical device development services and contact Krzysztof Minicki on LinkedIn.