FDA Transition to Computer System Assurance: The New CSV

The 2003 FDA guidance paved the road for the implementation of efficient computer system validation for the pharmaceutical industry.

Following that FDA guideline, the life science industry has become more efficient in validating computer systems and documentation in order to comply with regulations, inspections, compliance, and audits.

The FDA launched the Case for Quality in 2011 following an in-depth review of device quality data and feedback from both FDA and industry stakeholders. The Center for Devices and Radiological Health (CDRH) initiated the Case for Quality, a new program that identified barriers in the current validation of medical device software (released in 2002). Now, CDRH in cooperation with the Center for Biologics Evaluation and Research (CBER) and the Center for Drug Evaluation and Research (CDER) is preparing to release new guidance, Computer Software Assurance (CSA) for Manufacturing, Operations and Quality Systems Software. Although the new guidance was due for release in late 2020, the COVID-19 crisis has delayed the release date. Regardless, the FDA is encouraging the industry not to wait for its release because it is going to be a non-binding guidance.

This new guidance will provide streamlined testing with significance on critical thinking, risk management, patient and product safety, data integrity, reduced validation effort, and quality assurance. The FDA has indicated to consider the guidelines when deploying non-product, manufacturing, operations, and quality systems software solutions such as quality management systems (QMS), enterprise resource planning (ERP) systems, laboratory information management systems (LIMS), learning management systems (LMS), and electronic document management systems (eDMS).

Let’s find out why there is a paradigm shift from Computer System Validation (CSV) to Computer Software Assurance (CSA) and how CSA can refocus validation on what’s important in the new world of digital technologies.

Why do we need a new approach?

The FDA Guidance on Computer System Validation is already back-dated to 2003 and is no longer aligned with new technologies. The burdensome approach, heavy documentation, and lack of clear testing approach have been a constraint for the Life Science industry to adopt new technology.

FDA believes the use of automation, information technology, and data solutions throughout the life cycle can provide significant benefits to enhance quality and patient safety, and to support the use of new technologies, the FDA is drafting new guidelines.

What is CSA?

Computer System Assurance (CSA) is a framework designed to help manufacturers within the Life Sciences industry achieve computer system validation (CSV). CSA clarifies the stance and methodology used to determine what high risk is and what is not, therefore minimizing misinterpretation by manufacturers. It identifies common pain points; FDA’s current thinking puts patient safety and product quality at the heart of the risk assessment process.

Common CSV Pain Points

Currently, the industries that are following FDA guidance are facing a lack of adoption of automation technology, which has resulted in numerous unintended consequences.

CSV vs CSA

The focus of current CSV processes is creating accurate and approved documentation to present information to auditors, as they require evidence and records in order to be compliant with the regulation. Therefore, the CSV methodology inspires a compliance mindset rather than an innovative one. The existing CSV approach results in manufacturers spending around 80% of their time producing documentation and only 20% of their time doing actual testing of the software.

Documentation will always be a vital part of the process, but it must be the least burdensome activity, while critical thinking should be the focus of the validation efforts. The intention of the upcoming CSA guidance is to support product quality and patient safety by emphasizing critical thinking in the validation process. The FDA wants manufacturers to spend 80% of their time on critical thinking in order to apply the right level of testing to higher-risk activities, with only 20% of time spent documenting.

Old CSV Ways

New CSA ways

CSA Process

The FDA intends to introduce updated guidance with new re-defined terminologies as Direct and Indirect systems on the basis of the impact on patient safety, product quality, and integrity. This change allows manufacturers to define testing strategies and apply critical thinking.

Let’s get familiar with systems and new testing terminologies:

• Direct system software has a direct impact on patient safety and product quality. A high-risk system will require testing based on risk, and expected deliverables are similar to current expectations (i.e., the riskier the application, the more testing and documentation are required).
• An indirect system is software that does not directly impact the product or patient safety but does impact the quality system (e.g., Learning Management tools, Document Control, Complaint Management, Lifecycle Management tools). The same rigor is not needed for the assurance of these types of systems, and they require less documentation.

Scripted vs Unscripted Testing: What’s the Difference?

Traditionally, all the test scripts were written in detail, maybe for high-risk, medium-risk, or low-risk features. So, the same level of testing effort was being put into creating test documentation for low risk as well as high-risk systems. CSA introduces the terms Scripted Testing and Unscripted Testing.

‘Scripted Testing’ is traditional testing implied for a high-risk system or feature. Scripted tests usually include, at a minimum, a test Objective for the test script, a step-by-step test procedure, Expected Results, and a Pass/Fail. Scripted Testing is to be used to test higher-risk (Direct) systems or features as the software does not directly impact the product or patient safety.

‘Unscripted Testing’ is testing that is carried out without the use of detailed test scripts. Unscripted Testing is used to test lower-risk (Indirect) systems or features as the software does not directly impact the product or patient safety but does impact the quality system. There should be a Test Objective and a Pass/Fail, but no step-by-step test procedure.

As per the risk of the system or feature, the testing strategy and the amount of testing required can be defined as below:

The objective of the CSA guidance is to promote critical thinking and a streamlined testing approach. The CSA process can be described in four broad steps:

• Identify the software’s intended use: The CSA approach starts with identifying the intended use of the software. On the basis of the impact on patient safety, device quality, or quality system integrity, the systems can be classified as Direct or Indirect software systems. For example, to ensure your quality trainings are done properly, use a platform like eLeaP to ensure your team has the tools to do their jobs successfully.
• Prioritize risk and determine your approach: The next step is to apply a critical thinking approach and develop a validation plan on the basis of the risk of the system. Establish measurable Key Quality Attributes that can account for system quality and consistent performance. Determine if the failure of these parameters will result in a direct patient safety risk. Establish appropriate risk-based assurance activities for identified high-risk parameters and ensure that the system performs as intended.
• Methods and Activities: The organizations must leverage existing activities and supplier data and use process control to mitigate the risk. The transition to CSA involves a test automation strategy and implementation plan which will offer shorter implementation time, efficient automated testing, fewer defect and human errors, reduction in validation documentation, use of new testing tools, and improvement in test process quality.
• Conduct testing activities based on determined risk level: The testing strategy should be based on the identified risk of the system or feature. For high-risk requirements, extensive validation activities (scripted testing) and documentation are necessary. For low-risk systems, an unscripted testing approach must be applied, and minimum documentation is required.
• Appropriate record: CSA focuses on having less documentation which encompasses the intended use of the system, what needs to be assured, determination of the feature, operation or function impact and risk level, the identified critical parameters, and the evidence captured to demonstrate acceptance of the result. The record needs to be the value to the organization, not to the auditors.

Risk-Based Approach

FDA has introduced a new angle to look at the risk of the systems, focusing more on testing approach, leveraging vendor audits, and scaling validation activities based on risk.

Deliberations in the transition from CSV to CSA

The guidelines haven’t been released yet, and the implementation will take some time. In the meantime, the industry can implement the CSA vision:

• Change the culture from a compliance-centric mindset to a quality-focused culture.
• Perform supplier audits.
• Know the intended use of your computer system.
• Know the high-risk features, operations, and functions of the computer application.
• Know the existing gaps in your current validations and approach to close it.

The bottom line

The FDA is providing a fresh breeze of new guidance that organizations should immediately embrace. The paradigm is shifting to automated testing and critical thinking, which ultimately will drive better patient outcomes, reduced cost, reduced documentation, more effective software systems, and faster time to market.