Executive takeaways
- The FDA is shifting focus from compliance to quality: the agency is encouraging automation and new technologies that enable more effective testing and less time spent on documentation.
- Computer Software Assurance (CSA) is a risk-based validation approach: it focuses on testing instead of documentation and leverages supplier qualification, user acceptance testing, and less formal testing to right-size evidence.
- You don't have to wait for the final guidance: the risk-based approach isn't new, and CSA can be adopted now across pharmaceuticals and biologics, not just medical devices.
- Flip the ratio: instead of 20% testing and 80% documenting, the FDA is encouraging teams to spend 80% testing and 20% documenting.
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. Because so much of that evidence underpins electronic records and signatures, mature programs map their validation work back to 21 CFR Part 11 expectations as well.
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.
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.
Right-sizing evidence by risk
- Low / indirect impact (complaint handling, bug tracking, load testing, lifecycle tools): lighter, less formal testing and minimal documentation can be sufficient to show the system works as intended.
- Higher / direct impact (patient safety, product quality): more rigorous, scripted testing and fuller documentation, scaled to the level of risk.
- Evidence source: lean on supplier qualification, user acceptance testing, and unscripted/ad hoc testing before defaulting to heavy scripted protocols.
- Screenshots: capture them only when the data is reused in a later test case or when a high-risk requirement can't be demonstrated any other way.
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. A defensible, risk-based program is also the foundation of strong data integrity—the testing evidence you generate is the record that proves your systems behave as intended.
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.
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. Pairing CSA with a managed approach like USDM Cloud Assurance can keep that validated state current as your systems and vendors change.
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. To go deeper on operationalizing the lifecycle, see our overview of validation lifecycle management for life sciences teams.
FAQ: Adapting CSV to evolving FDA guidance
What is the difference between CSV and CSA?
Computer System Validation (CSV) produces documented evidence that systems used to generate or modify records work for their intended use, and it has historically been documentation-heavy. Computer Software Assurance (CSA) is a risk-based approach that keeps the same goal but emphasizes testing over documentation, leveraging supplier qualification, user acceptance testing, and less formal testing to right-size the evidence.
Do I have to wait for the final FDA guidance to adopt CSA?
No. The risk-based approach isn't new, and the FDA is actively promoting the CSA framework. ISO regulations and GAMP guidance are consistent with CSA, so pharmaceutical and biologics organizations—not just medical device manufacturers—can adopt the streamlined approach now.
Which systems is CSA intended for?
CSA is intended for systems used by product manufacturers' operations—such as Quality Management systems, ERP, MES, and labeling systems—where there is indirect or potentially direct impact to patient safety, product quality, and the quality management system. It is not intended for medical device products themselves, software that is a medical device, or software developers' use.
When do I still need to capture screenshots?
Screenshots should be captured only when you need the data in a later test case, or when you are demonstrating that a high-risk requirement is met and it can't be shown any other way. For most testing, exhaustive screenshots are unnecessary and add documentation burden without adding assurance.
How do I get IT and Quality teams on board?
Start with a pilot on a system where you already have validation results so teams can see the difference firsthand. If the pilot works, expand it to other systems while making sure stakeholders understand how and why the risk-based approach is more effective.
Ready to transition from CSV to CSA?
USDM helps life sciences organizations adopt a risk-based validation approach, run a successful CSA pilot, and scale it across their systems. Contact us to talk through how CSA can reduce your documentation burden while strengthening the quality of your validation evidence.
Additional Resources
Considering CSA? Here’s what you need to know
Top CSA Insights
Upgrade to Oracle ERP Cloud and Transition from CSV to CSA
Whitepaper: Automate Validation Across Your Tech Stack