Computer Software Assurance (CSA) vs. Computer Software Validation (CSV): FDA Adopts a Risk-Based Approach for Software Validation

At ComplianceQuest, we recently organized a webinar on – How Will FDA’s New Approach to CSV Make Implementations Easier?

In this webinar, Tim Fischer of Great Solutions Inc., gave us a detailed perspective of why the FDA is moving to a risk-based approach for software validation. In this post, we share key takeaways from the virtual event.

Computer System Validation (CSV), or software validation, as it is also called, is an FDA regulatory requirement for regulated companies to validate software projects and prove that their software or system is performing as expected and that there are no deviations. This takes a compliance-first approach and is very complex and time-consuming, requiring a lot of paperwork. It can cause delays in implementation and maintenance and the process of upgradation becomes challenging.

The world of standards is moving towards a risk-based approach, the case in point being ISO 13485 and ICHQ9 quality risk management documents that’s been permeating the life sciences industry. The FDA too is now looking at moving away from a compliance-centric approach of CSV to a risk-based approach with CSA or computer software assurance.

The Complex CSV Approach

In the traditional CSV approach, if you chose to implement three modules of a QMS System, for instance, for each of those you would have to run the entire process of:

• Creating a vendor charter document
• Auditing the vendor
• Establishing a vendor validation master plan
• Running through the process of vendor selection
• Qualifying and verifying that the software complies with Part 11 including audit trail and electronic signatures
• Ensuring a closed system
• And assessing various risks and possible impact

In the next stage, you would be required to design your functional specifications, complete IQ/OQ/PQ (installation qualification, operational qualification and performance qualification) protocols, manage deviations, connect user requirements with design functionality, and connect it with your traceability matrix. You have to establish your administration and process SOPs, and deliver complete training on the system before you can go live.

With the CSV approach, you have to follow a waterfall approach and even a six weeks per module schedule can extend to double the time per module due to the work involved in meeting the CSV requirements. As a result, a business would hesitate to even opt for more modules.

Release management (the process of releasing newer versions) under CSV is equally challenging and
maintaining your software system in a validated state requires humongous time and effort.

In the traditional CSV/GAMP3 approach, all systems are treated similarly, whether they are pre-configured products or not. Vendor documentation is underutilized, and even if the vendor has run an IQ/OQ on their systems, you are required to repeat the process in detail.

For the CSV work to be accomplished, internal experts need to be present, contributing to costs and time. If you need external experts, then the cost of validation can be as much as 50% of the software implementation cost. The project becomes intense and the risk of budget and timeline slippage is high.

For the FDA inspectors too, CSV is a lot of work, requiring paperchase and testing every feature of the computer system.

The new CSA takes cognizance of these challenges and is a breath of fresh air, easing many of the requirements and narrowing its focus on risks and critical quality attributes (CQA). Being initiated as part of Harmonization 2021, it aligns itself with other international standards such as ISO and allows an agile implementation environment for faster deployment and recovery of RoI from key software projects.

The CSA Approach

The FDA’s guidance document, titled Computer Software Assurance for Manufacturing and Quality System Software, has its roots in a 2011 FDA study of the Case for Quality which examined the 2002 guidance document, called Validation of Software in Medical Devices. The study revealed an inclination towards medical device software, which is the product software, not taking into consideration the supporting software such as the quality management software or PLMs. The CSA aims to correct this and minimize the CSV effort by specially focusing on COTS (Commercial, Off-The-Shelf) platforms to improve efficiency and validation, data visibility and accountability. Broadly, this would include non-product software systems that tie together automation, data management, patient safety, data integrity and product quality through the following automation systems:

• Quality Management Systems
• Laboratory Management Systems
• Document Management Systems
• Warehouse Management Systems
• Enterprise Resource Planning Systems
• Product Lifecycle Management Systems

With CSA, there would be a considerable reduction in the risk of decision complexity. Businesses will be able to define how much testing is required and only test based on risks and CQAs. There will be a heavy reliance on the vendor quality system and the IQ//OQ work they do instead of repeating the entire process. There is a clear demarcation of roles and responsibilities, enabling a shift from critical to quality thinking with focus on product quality, patient safety and data integration. Businesses will not only get a software product that does what it is supposed to do but also have the assurance that their vendor knows what they are doing and rely on their validation effort.

This may require using some unscripted testing to make sure the system is working properly but not run a test protocol to test every single function that the software has, thereby saving time and cost of deployment.

Also, unlike in CSV where the software was looked at in bits and pieces, CSA aims to focus on the full lifecycle of the total system. Last, but not the least, there will also be less paperwork for the FDA inspector with the higher level master overview, master validation summary and the company methodology and rationale detailed out.

Some of the key features of CSA implementation can be summarized as:

• Leverage supplier testing
• Review their test practices
• Ensure that their SDLC, data centre and servers are well qualified and have good support systems.
• Have a capable tester to create tests dynamically and run unscripted tests
• Limit scripted tests only for medium to high risk, and critical quality attributes
• Do a deeper test only in case of failures of these medium to high-risk attributes

In the new environment ‘verification’ is going to replace ‘validation’ for COTS.

With CSA, businesses can expect to achieve higher levels of patient safety, product quality and data integrity. Establish metrics based on risk assessments to determine the impact of critical features alone. This applies to new releases or new systems too where tests should be restricted to high-impact functions alone. This will, of course, require due diligence and critical assessment of vendor qualification documentation, with a specific focus on conducting a robust risk analysis process. Overall, adopting the CSA approach helps enterprises also shorten the time-to-market for new products or features.