Non-product software validation is one of the most misunderstood processes in the medical device industry. In reality, software validation should be something that companies embrace! The whole intent is to ensure that the software does what it’s supposed to do, is robust enough to handle whatever its users do, and can be maintained for the life of the software. So why all the consternation? Typically, it’s because it’s done in a way that’s inefficient and cuts directly into the bottom line. As a result, management has no tolerance for the extra expense and is inclined to avoid improving operations through strategic use of software just to avoid the cost. In this webinar, we’ll look at the current state of affairs in non-product software validation and discuss why there is so much fear, confusion, and avoidance.  Another contributor to the confusion is that there’s often no centralized approach and company “silos” do things differently. We’ll note what led to all this confusion and concern and why most of the fears are quite misplaced.

Another source of confusion is due to the variety of software applications that should be covered under the system. Yes, Excel spreadsheets should be validated if they are used for regulatory purposes. Then there are home-grown applications, commercial applications, scripts on top of other applications, customizations for particular applications (e.g., individual programs driving a Coordinate Measuring Machine (CMM)), and enterprise applications like CMR systems and eQMS systems.

We’ll then step back and discuss what validation should be and why it’s important. FDA has recently issued a draft guidance that suggests an approach to computer software assurance. This approach is practical, allows companies to leverage aspects like supplier testing, and, of course, provides a risk-based approach to validation. 

Using the approach laid out in the draft FDA guidance, we’ll discuss a practical application for establishing a corporate-level approach to computer software assurance/software validation.  We’ll show one approach to driving the process using a risk-based approach.

We’ll then discuss a variety of test methods. We can’t completely eliminate testing but we can certainly take a risk-based approach to what testing we do. One of the least-used approaches is exploratory testing. We’ll discuss how this approach can greatly supplement a validation program and give better insight into how robust a system is.

Circling back a bit, we’ll discuss establishing requirements for computer systems. These are key to both understanding how to approach validation and ensuring the system fulfills its intended purpose over the life of the software.

Finally, we’ll discuss an approach to maintaining the validated state over the life of the software. No software is completely static over its life. Obviously, any changes to the software could impact the validated state; however, there are numerous other “influencers” that could affect the validated state: underpinning support software (e.g., database engine), operating system updates, and even changes in use. 

Who Should Attend

Why Should You Attend

There’s no shortage of fear, uncertainty, and doubt when it comes to non-product computer software validation. The reality is that companies should want to optimize operations through the strategic application of software utilities and ensure that the software actually does what it is intended to do. Frequently, though, companies avoid using software that can substantially improve operations because of the fear associated with validation. In the same vein, companies may avoid needed upgrades because they don’t want to re-do validation. Just as bad, companies receive findings from auditors and inspectors because they are using software that should be validated but don’t realize the software falls under the scope of the requirement. In the pharmaceutical industry, a convention was established for process validation (GAMP) with three aspects to validation: Installation Qualification, Operational Qualification, and Performance Qualification. These approaches are good for process validation but when companies tried to apply the concepts to non-product software, they were effectively using a hammer to put in a screw. It might work, but it’s not efficient and if you ever had to remove the screw (relating to if the software changed), there could be a lot of damage (yet more difficulties). Conversely, companies may have taken a “home-grown” approach to validation and ran into other difficulties: didn’t take a risk-based approach (so overdid it for the application), didn’t consider factors like testing done by the provider and widespread use, and didn’t consider how validation would be maintained for the life of the application. All of these have led to wasted budget, delayed use of applications, security holes due to patches not being applied for fear of having to re-validate, and end-user dissatisfaction. 

Topic Background

FDA Regulations (21 CFR 820) and ISO 13485 both require that software used in the execution of the quality management system be validated. The intent is to drive companies to ensure that the software they are using performs the intended operations and is sufficiently robust to perform over the life of the software.