Risk and Use Determine Levels of Computer System Validation Needed
The FDA has shifted its regulatory focus from software to whole computer systems — and regulated life sciences companies must adjust for that when developing effective validation programs, former FDA investigator Martin Browning said at a recent FDAnews audioconference.
“The focus is on systems, not just software,” he said. But companies have not always adjusted to this new reality. Instead, many suffer from a lack of computer system validation (CSV) understanding that manifests itself in ill-defined, uncontrolled processes, inadequate time and resources allocated and an inadequate quality system.
“To the FDA, validation is a restatement of the scientific method” used by a company in its operations, he said. Browning is president and co-founder of EduQuest. He worked for 22 years at the FDA as a local, national and international expert investigator, and then as a special assistant to the associate commissioner for regulatory affairs. During his tenure at the FDA, he co-chaired the working group that drafted 21 CFR Part 11, served as one of the agency’s national experts on computerized systems and was centrally involved in establishing many of the FDA’s regulatory guidance documents and internal training related to software and computerized systems.
The key to understanding and implementing a CSV program is to have the right perspective on risk, Browning said. In validation, the bottom line is to apply the appropriate level of control based on the level of risk regarding the intended use of the specific system component, Browning indicated.
“Far too often, companies have implemented validation policies of ‘one size fits all,’ and this can make validation difficult for the smaller systems,” agreed Ty Mew, president of Ofni Systems. “Many times these [same] systems go unvalidated because the level of effort required to validate is too great.” Like Browning, Mew champions using different risk methodologies for different types of systems, and even for different parts of the same system.
CSV is also important because it can help firms avoid warning letters and other types of regulatory heat, Browning noted. FDA inspectors look for telltale signs such as high rejection rates or out-of box failures for medical devices, he said. But a good CSV program can help you spot and correct those trends yourself before they become the focus of a warning letter.
The FDA’s CSV expectation is that companies establish documented evidence that provides a high degree of assurance that a specific system will consistently result in a product that meets its predetermined specifications and quality attributes for that product, Browning said.
Because the FDA and its inspectors “look at the past” to determine your company’s current CSV compliance status, documentation is critical, Browning said. “We tend to neglect that,” he added.
Documentation that proves validation is critical, agreed Mew. He noted that Browning wisely uses a screen recorder to document the exact steps executed during the protocol execution. “This would not only be a more accurate way to record exactly how the test steps were performed but also would be a tremendous time saver,” Mew said.
When developing a CSV program, Browning advised setting clear, predetermined specifications with defined requirements. “It is important to know what [the system] is trying to do” and to demonstrate that you have preset acceptance criteria and endpoints, Browning said.
But the documentation is key, he stressed. “You need documentation that explains [internally and to an FDA inspector] how you arrived at ‘X’ number,” he said. The right documentation is “proof” that the process used was appropriate, and that it followed and met predetermined specifications. In addition, the “right” documentation will also allow you to spot trends over time to help guide and ultimately improve your processes, Browning said.
The FDA has not provided an abundance of guidance about how it views specific risk situations. For some companies that has been freeing because it allows them to develop plans that make sense from their own business viewpoint. But other companies have struggled with the agency’s relative lack of clarity in this area.
Browning advises that “risk and use” dictate the level of validation necessary. Essentially, the more an erecord or aspect of the CSV directly affects product efficacy and patient safety, the more rigorous its validation should be.
A good CSV includes a formalized process for evaluating system use and determining risk. That is where the predetermined specifications and endpoints come into play. Your system should be monitoring those specifications and using them as a “trigger,” or early warning system, he said. But remember not to stubbornly use one process for an entire CSV. For example, it is often a good idea to use a different risk methodology for system maintenance.
When struggling to determine the proper level of validation, Browning noted that the most common cause of failure is a lack of understanding of your processes, or the loss of that understanding after the system “goes live.”
While it has limitations, and is geared more toward devices than drugs, Browning advised that companies take a close look at the Hazard Analysis and Critical Control Point (HACCP) risk management method as a starting point for defining risk-oriented specifications. The strengths of HACCP include predefined corrective and preventative action (CAPA) plans, scalability, and guidance on managing critical control points, he said.
Scalability is most important, Browning said. Don’t be rigidly drawn to “flavor-of-the-month standards unless you are in the business of validating similar systems over and over again.” In addition, if you choose to rely completely on a single standard, an FDA inspector is liable to hold you rigidly to that system and find fault with your approach if you don’t meet the system’s criteria.
To order a transcript or CD of the audioconference, go to http://www.fdanews.com/wbi/conferences/csvalidation.html.
— Michael Causey