Modern medical device regulations are putting more and more emphasis on the management of software tools.
These tools are software packages that are not part of the medical devices themselves, but support the device during its lifecycle.
Nowadays companies use dozens of applications, ranging from accounting tools to email clients to software compilers. Of course not all of them have an impact on the product, so which ones should be validated and how?
The first step for any situation is to assess the software tool for its impact on the medical device. If it can have an impact on the “quality” of the device (in the broader sense), then validation may be required. Consider also that the software tools used to manage your Quality System, including CAPAs, complaints, NCs, requirements, risks, etc., fall into this category.
The framework for the validation mimics the well known process used for process validation: plan, risk assessment, requirements, protocols, results, report.
This is all well and good if you have insight and knowledge in the object you are validating. But in most cases, especially for the off-the-shelf software tools, the user sees them only as black boxes. Setting up a comprehensive software validation without having an idea of its internal mechanism is a challenging tasks; not much for what you know, rather for what you don’t. It is difficult to develop tests for unknown boundaries and unclear algorithms. And typically this results in significant gaps in the validation coverage.
Recently, more mature software tool development companies have started providing pre-validated software and validation packages aimed at the medical device market. This is a priceless product for a medical company of any size, as it allows to demonstrate compliance using the expertise and knowledge of the developer(s) of the tool; due to their knowledge of the internal processes of the tool, they can put together a relatively lean protocol that adequately challenges the product. It also shows that the software tool developer has an idea about the regulatory framework of the medical device market, which may also help them design software tools that capture the key requirements so dear to the medical regulations but little known to the outside world (e.g. electronic records, electronic signatures, etc.).
A word of caution: it is best practice (if not actually expected by regulatory bodies) to repeat at least part of the validation protocol in-house, to confirm the results of the pre-validation provided by the developer. It is unlikely that you will be able to adequately control your software tool providers (read: audit them) to be able to solely rely on their own internal activities.
SoftComply is happy to inform you that the validation packages for both SoftComply Risk Manager Server version and for SoftComply Risk Manager Plus are now available.
SoftComply has also released an app for automated Validation for Confluence Cloud for regular validation testing of your own Confluence instance – you can try the app out for free!
For more information, please contact us.
References:
1. General Principles of Software Validation: Final Guidance for Industry and FDA Staff
2. Guidance for Industry Process Validation: General Principles and Practices
