Let’s explore the differences between Computer Systems Validation (CSV) and Computer Software Assurance (CSA):

Tony is a truck driver, and he’s driving his truck on mountain terrain. The speed limit says 40 MPH, and he’s driving his truck at 39 MPH – still, he has an accident, even though he was following road signs.  

It’s a rainy day, the road is slippery, and visibility is poor. The speed limit is applicable for a normal day, so Tony did not foresee the risks associated with the road. Road signs are guidelines for public and vehicle safety; however, the onus is on the driver to identify risks and road conditions while driving,   

Tony is good example of the current Computer Systems Validation (CSV) practices in the industry. Rather than testing the system functions based on the system criticality and risk associated with the use of the system, more emphasis is being given to documentation, like screen shots, and maintaining compliance. Though documentation is an integral part of system validation activities, many pharmaceutical, biologics, and medical device clients tend to overlook the risk-based testing piece. This is the biggest drawback of current validation practices. 

To negate this issue, the FDA proposed a move from validation to Computer Software Assurance (CSA). The crux of this guideline is to test the system based on its risk to the patient safety, efficacy, product safety, and data integrity. Any system that might directly impact the safety, efficacy, and quality triage are to be tested thoroughly, and the extent of this testing depends on the complexity of the system. 

History of Software Validation 

In January 2002, the FDA issued the final draft of General Principles of Software Validation, which provided the general principles applicable to the validation of software used to design, develop, or manufacture medical devices.   

The FDA issued this guidance based on analysis of 3,140 medical device recalls conducted between 1992 and 1998. In-depth analysis of the recalls revealed that 242 of them (7.7%) were attributable to software failures. Of those software related recalls, 192 (or 79%) were caused by software defects that were introduced when changes were made to the software after its initial production and distribution.  

The initial software validation guidelines were directed toward the medical device industry. The regulations were more stringent, as devices with embedded software applications were in direct contact with human organs internally (pacemakers) or applications were controlling the functioning of the device (automated dialysis units). The stringent regulations were needed because of the criticality of the software’s intended use.   

In 2003, the FDA later realigned this guidance for the applicability of the entire pharma, biologics, and device industries. as the software validation guidelines were relevant to any process, equipment, or instrument that had a software used for manufacturing, testing, storing, and distributing a pharma/biologic/device product. The device industry was regulated by the stricter Quality Management System (QMS) guidelines – in addition to the software validation and Good Automation Manufacturing Practices (GAMP) guidance — while the pharma and biologic industries were governed under CSV and GAMP, since the risks associated with software were not as critical as in the device industry. 

What is Computer Systems Validation? 

Computer Systems Validation (CSV) is a process for verifying and documenting that a regulated computer-based system performs as intended in a consistent and accurate manner and that it’s secure, reliable, and traceable. 

The CSV process creates an indelible electronic data trail that allows us to treat the regulated data and electronic signatures captured in drug discovery, human trials, commercial manufacturing, distribution, and storage as the legal equivalent of paper records and handwritten signatures and have the equivalent level of confidence in their accuracy, reliability, and data integrity. 

Regulatory controls are required to be in place for replacing paper records and handwritten signatures with electronic records and electronic signature, as well as to maintain the data integrity throughout the data life cycle.  

Some of the key controls are: 

• Data should be stored in electronic format and should be attributable to the source information, the person responsible for generating data, and the reason for generation (Audit Trail). 
• System must have the capacity to archive and retain the data as determined by the process requirement and must be retrievable in human readable form (legible), as and when required. 
• System generated data should be contemporaneous i.e., date and time of generation should always be traceable to the original date and time of generation. 
• Data and records generated should be in the original format and shouldn’t be in a modified state or be falsified. 
• Records must be accurate and consistent with the source data. 
• The system must ensure that electronic signatures are as trustworthy and secure as a handwritten signature. 

The mentioned controls are critical for complying with ERES (Electronic Records; Electronic Signatures) and maintaining data integrity; however, many CSV projects deviated from their core objective of ensuring that the system performed as intended, accurately, and consistently. They weren’t identifying the risk the software posed to vital product life cycle processes (manufacturing, testing, storing, and distributing) and weren’t sticking to a lean but effective testing approach to negate the identified risk. As such, the FDA decided to move away from CSV. 

What is Computer Software Assurance (CSA)? 

The FDA proposed a new guideline called Computer Software Assurance (CSA) in September 2020. CSA is a more risk-based approach to traditional CSV. The new guidance provided clarity on the procedure used to determine what is high-risk (and therefore what should be tested more stringently) to minimize misinterpretation. The intent was to improve quality, reduce validation cost and time, decrease testing issues, and deliver value faster. This approach included less emphasis on compliance, allowing manufacturers to focus on enhancing quality and patient safety, as well as implementing automated systems and new technologies faster and more abundantly. A risk-based approach is nothing new, but these principles and approaches are now applicable to all regulated organizations.  

This concept evolution centers on a risk-based approach using critical thinking. The risk determination will still be based on the software’s impact to patient safety, impact to product quality, and impact to quality system integrity, but inspectors will now focus their review on higher risk activities and the critical thinking behind the compliance methodology chosen. Then, they’ll focus on assurance needs, testing activities, and documentation, ensuring that most of a manufacturer’s time is spent applying the right level of testing to higher-risk activities instead of time spent documenting.   

Preparing for the Shift from CSV to Computer Software Assurance

In early 2021, the FDA conducted a panel discussion during the “FDA Discusses Data Integrity Challenges and CSA Application” webinar. During the discussion, the following opinion polls were conducted:  

1. When will you start implementing Computer Software Assurance? 

• 47% of the participants said they were unsure of the implementation timeline 
• 46% of the participants were willing to start immediately or in 2021 
• 7% had no plans 

2. If unsure or no plans (54%), what is preventing you from adopting Consumer Software Assurance? 

• 40% needed guidance for implementing 
• 33% of the participants were waiting for others to implement 
• 27% had internal resistance (from QA/CSV/Management) to implement the change 

The opinion polls indicated that a majority of clients are willing to accept and implement CSA, and they’re looking for guidance and support. 

Though the principles and guidelines surrounding the CSV process are very robust, interpreting and implementing CSV is where most projects falter. Too much emphasis on testing low-value attributes, focusing on testing activities, ambiguity during requirements generation, and unwanted documentations are some of the key reasons for CSV not being effective and lead to unnecessary controls and costs and discourage technological innovation without providing added benefit to the public health.  

With the shift to CSA, the focus will be on the quality of the computer software, working toward an approach where compliance is a by-product of the culture. If your organization is looking for guidance on the shift from CSV to CSA, partnering with a team of quality experts is a great way to get started. To learn more about Clarkston’s validation services, please contact us today. 

Contributions from Dinesh Srinivasan