With the growing importance of information management and electronic documentation within the pharma GMP world, it was only a matter of time until regulators made software validation a focal point of their work. “The FDA has increased its awareness of software validation and investigators are now more mindful of it during the inspection process,” notes Michael Gregor, CEO of Compliance Gurus (Boston, Mass.). “In fact, FDA investigators are after objective evidence of regulated applications requiring software validation.”
Most manufacturers have yet to adapt to this change, says Gregor, but they now have little choice. In this conversation, Gregor offers insight into the fundamentals, and pitfalls, of software validation efforts:
PhM: What’s behind FDA’s increased awareness of software validation, and has it caught manufacturers off-guard?
M.G.: An increase in federal investigators has allowed the FDA to concentrate on a more broad range of regulations. Yes, many manufacturers have been caught off-guard.
PhM: What’s the status of software validation guidance, and are there updates on the horizon?
M.G.: There are no updates to software validation on the horizon. There was a pledge by the FDA to update 21 CFR Part 11, Electronic Records and Electronic Signatures, but they have yet to provide any further guidance or update the final rule itself.
PhM: What are some of the pitfalls you see with software validation projects?
M.G.: The biggest pitfall is the lack of good requirements. Requirements are the source of the system functionality and design and therefore should be properly written. Another pitfall is the lack of traceability from requirements to test scripts. Lastly, there is a lack of adherence to change control procedures, therefore resulting in systems no longer maintaining a validated state.
PhM: Why is this happening? Aren’t validation teams prepared or competent enough?
M.G.: Many teams are facing tight deadlines, which contributes to the lack of attention to planning and detail. Oftentimes validation teams are rushed through the process and therefore many key validation attributes are overlooked. There is a lack of a representative group to author requirements. Too many times requirements are written in a vacuum!
A good practice for establishing solid system requirements is to ensure you have a representative group involved in the author, review, and approval of system requirements. Typical and recommended representatives are: Quality Assurance, Users, and IT.
PhM: How about change control? What’s the secret to continued validation?
M.G.: The trick to maintaining your validated systems in a validated state is to have a change control procedure that covers both software and hardware changes. The procedure should also require a representative group to reside on a change control board. Again, recommended members are: Quality Assurance, IT, and the User community. It’s important to note that more than one user is okay and even encouraged, as it is not only important to assess the impact of the change to the system, it is also important to understand the impact of the change to the business.
PhM: Are COTS [commercial off-the-shelf] vendors providing better validation packages than in the past, and should manufacturers still be wary of software products that come with “complete” validation packages?
M.G.: Great question. The quality of validation packages has been consistently poor and they continue to lack the quality needed to pass FDA standards. COTS vendors fail to realize that objective evidence is needed to prove a system operates as intended. Furthermore, oftentimes COTS applications are highly configured and therefore require a level of validation that is much more significant than the standard “out of the box” test scripts provided by COTS vendors.
PhM: As more manufacturers are taking advantage of Software-as-a-Service and “hosted” options, are there special validation considerations they need to be aware of?
M.G.: Yes, there are several considerations where security is concerned. Both physical and network security are crucial when an application is hosted by a third party. Validation considerations are security, change control, and installation.
PhM: What is “intended use” and why do manufacturers struggle to interpret its true essence?
M.G.: As the name implies, it describes how a software application is intended to be used. Intended use drives the need for validation and also leads the way for system requirements, which are a key component to any validation effort. Manufacturers struggle with the concept because they often lack the procedural controls to identify and define “intended use” in the first place.
PhM: How prevalent are warning letters related to “failure to validate computer software for its intended use,” and what are the underlying issues that the Agency is calling out?
M.G.: Warning letters related to the failure to validate software are not too common. However, in the last year, this has changed, as the FDA as stepped up efforts and has become more vigilant when it comes to software validation and intended use.
PhM: A lot of new products are coming on the market for analytical and modeling applications (to assist in Quality by Design efforts and other work). Might there be specific intended use issues (or general validation issues) for these types of products?
M.G.: Applications of these types are often complex applications. The more complex the application, the more difficult it is to properly validate for its intended use. In most cases, proper requirements are often lacking with complex applications. This alone can cause a validation effort to fail, as system requirements are the root to system functionality and design.
