Most medical device manufacturers use many, many software programs, systems, or services to automate quality system This software is not to be confused with product software – that is, software that runs as part of a medical device. Medical device in this context could be custom hardware devices or Software as a Medical Device (SaMD). Often this type of software is categorically referred to as “Non-Product Software”, “Quality System Software”, or “Tools.”
Software programs or services are used in many ways to automate quality system processes, and many of those processes are part of the product software development lifecycle. For example, software systems are very often used to manage software requirements and specifications, track bugs or defects, manage software source code versions/branches, plan software development and verification activities, automatically execute test cases and evaluate pass/fail criteria, and many others. Automation of quality system processes using software is highly encouraged as it reduces potential for human error, often captures richer data from the process, and ensures repeatability as staff members change.
However, both US regulations and international standards expect or require software that is used to automate quality systems processes to be validated for its intend use. Validating this software clearly makes sense and should be part of our overall effort at assuring “product software quality.” The FDA gives guidance on validating this type of software in the General Principles of Software Validation. The approach, rigor, and on-going monitoring required to validate Non-Product Software greatly depends upon the “risk to product quality” resulting from failures of that Non-Product Software. A common mistake is to attempt to approach validation of tools with a one-size-fits-all mentality or naively thinking that some standard (e.g., GAMP) will be appropriate for all types of tools. Manufacturers, in their effort to assure quality, end up wasting enormous time and resources conducting very low value validation paper-work that, ironically, leads to less assurance of quality. Obviously a “process risk analysis” should be used to properly plan and scale the validation – but that is another topic for another time.
A significant challenge that a manufacturer or developer will face is with the use of tools where the configuration will rapidly change. Often we find this situation with cloud-hosted tools where the tool vendor will be deploying new versions/updates frequently. This presents a challenge for one to argue that the tool “continues to be” in a validated state. This raises many questions and every tool may likely have a different set of answers:
- Should a manufacturer re-validate the tool each time a new configuration/version is pushed?
- Can the manufacturer control the pushes and decide when to accept the new version?
- Does the tool vendor notify of new releases?
- Does the tool vendor identify what has changed from the previous version? and to what detail do they provide?
- Does the tool vendor have any scheme for major, minor, and patch level releases?
- Is there a way to deploy a test environment to validate the new release prior to deployment to the live environment?
- Does the overall process, for which the tool automates some portion, have downstream quality control checkpoints that would catch potential software errors?
- Does the automated workflow self-check in any way such that potential tool software errors might be caught?
There are likely many other questions to ask as well. The answers to these questions, along with the process risk analysis, will help you formulate a plan appropriate and efficient for that tool or maybe even a class of tools.
