FDA Transition to Computer System Assurance: The New CSV
The 2003 FDA guidance paved the road for 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 the documentation in order to comply with regulation, 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 to not wait for its release, because it is going to be a non-binding guidance.
This new guidance will provide streamline 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 system 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. 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, 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 who are following FDA guidance are facing lack of adoption of automation technology and have 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
The FDA intends to introduce an updated guidance with new re-defined terminologies as Direct and Indirect system on the basis of the impact on patient safety, product quality and integrity. This change allows manufacturers to define testing strategy and apply critical thinking.
Let’s get familiar about systems and new testing terminologies:
- Direct system software has 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 is required).
- 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, may be it for a 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 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, 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 the patient safety, device quality or quality system integrity, the systems can be classified as a Direct or Indirect software system. 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, supplier data, and use of the 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 is necessary. For low-risk systems, 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 for 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 toward 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 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.