The Computer Software Assurance (CSA) framework is a risk-based validation process that involves more testing and less documentation.
There is a lot of discussion in the life sciences industry about the U.S. Food and Drug Administration (FDA) changing focus from compliance to quality and encouraging the use of automation and new technologies to enable more effective testing and less time spent on documentation. Slated for December 2021, the FDA’s Center for Devices and Radiological Health (CDRH) plans to release new draft guidance for CSA that applies to manufacturing, operations, and quality system software.
Computer System Validation (CSV): What it is and how it has evolved
Computer system validation is documented evidence that the computer systems used to generate or modify records work for their intended use. Validation is required by predicate rules (like 21 CFR Part 820 for a medical device, 21 CFR Part 210 and 211 for pharmaceuticals, and the European Union’s Annex 11 for good manufacturing practices [GMP]).
The resulting CSV report notes any constraints, restrictions, or deviations that were encountered and states whether or not the system functions for its intended use based on the evidence generated during the validation effort.
Why the FDA is changing the focus
The FDA wants manufacturers to consider using automation in their manufacturing and quality management system (QMS) processes; they see that industries using automation have increased product safety and quality. Many organizations think automation is too expensive because of the validation effort required, but the validation requirements referenced are from a guidance document that is more than 20 years old; hence, development of the CSA methodology.
CSA is a risk-based approach for quality products that focuses on testing instead of documentation and promotes the use of automation in the manufacturing of medical devices, pharmaceuticals, and biologics.
CSA is very similar to a standard GAMP CSV approach, but it leverages your supplier qualification, user acceptance testing, and other ad hoc, less formal testing to reduce the need for documentation. Based on the level of risk associated with your product, you can leverage different types of documentation, from ad hoc to robust scripted testing.
There are misconceptions about who can use the CSA approach. CDRH is producing the new draft guidance, but it’s not just for medical device manufacturers. ISO regulations and Good Automated Manufacturing Practice (GAMP) guidance’s are consistent with the CSA methodology. The pharmaceutical and biologics industries can adopt this streamlined and effective approach now without waiting for the FDA to release a guidance document.
The CSA guidance is not intended for medical device manufacturing products like medical devices, medical devices as services, or in software that is a medical device. Also, it is not intended for software developers’ use. CSA is intended for systems used by product manufacturers’ operations (Quality Management systems, ERP, MES systems, labeling systems, etc.) where you have indirect or potentially direct impact to patient safety, product quality, and the quality management system. Indirect impact systems—meaning it doesn’t have a direct impact on the product like your complaint handling systems, your CSV-type process systems like bug tracking systems, and other tools like load testing tools—and life management tools are good examples of when this approach can be leveraged.
Life cycle management tools don’t directly impact a product, so they require less documentation; however, you should consider the level of testing necessary to show the system works as intended. Systems with a direct impact on patient safety or product quality require more documentation and testing based on their risk.
Are you using a risk-based validation approach?
There are concerns in the industry about implementing CSA before the guidance document is finalized and published, but the risk-based approach isn’t new, and the FDA is promoting the CSA framework to ensure that your testing activities are consistent with it. You don’t need to wait until the guidance document comes out.
For example, if you have a Corrective and Preventive Actions (CAPA) system that needs additional validation, you could do ad hoc testing where you document who tested what in the system, the results of that testing, log the dates of testing, and sign off. Instead of spending 20% of your time testing and 80% documenting, the FDA is encouraging you to spend 80% of your time testing and only 20% documenting.
If you’ve printed out thousands of screenshots in your career, you’re probably excited about not having to show so much objective evidence. You don’t need screenshots for everything, which saves you a lot of time and effort over the course of several validation events. Screenshots should be made only when you need to use the data in a later test case or when you are showing that a high-risk requirement is met and it can’t be shown otherwise.
The IT and Quality perspective
There may be Quality people who are skeptical about the CSA approach, but those concerns can be alleviated by understanding how and why it’s a more effective approach. Large companies with well-established CSV processes are learning to embrace the CSA approach; the time savings is their ROI.
Perhaps you are excited about the CSA approach, but you are encountering roadblocks in your IT and Quality departments. In that case, consider a pilot program for a system where you have validation results and see how it’s different. If that pilot works, then expand it to other systems and make sure your teams are on board.
For smaller or emerging companies that don’t already have processes in place, the CSA methodology can get validation efforts off to a good start, and saving time and money is always smart.
Remember, CSA is applicable now; you don’t have to wait for the guidance to be published. Establish your level of risk aversion and leverage it in your testing and documentation.
Whitepaper: Automate Validation Across Your Tech Stack