CSA vs CSV: who's the winner?

CSA vs CSV: And the winner is ... Quality!

A former colleague who was soon to retire once told me: “Old doesn’t mean bad.” While this certainly holds true for human beings, does it also apply to technology and methodology? Are the concepts of Computerized System Validation (CSV) and scalable life cycle activities outdated? Will they be washed away soon by Computer Software Assurance (CSA) – the new star on the horizon? This blog provides a critical review of the current hype about CSA. It sheds light on the common elements of CSV and CSA, eyes their differences, explains the main focus of CSA, and highlights how to achieve both, quality and compliance. As this is not a tutorial, we assume readers are already familiar with concepts like CSV and data integrity.

Illustration of the concept of "CSA vs CSV"

Stefan Münch - Vice President Validation & Qualification Consulting, Körber Business Area Pharma

"Read in less than 10 minutes why CSA is not a replacement for CSV!"
Stefan Münch
Director Validation & QM

The history of CSA

In 2011, the US Food and Drug Association (FDA) started the “Case for Quality” initiative. It originated in the Center for Devices and Radiological Health (CDRH). After some time, it was embraced by the pharmaceutical community and today is often being portrayed as a silver bullet for all kind of compliance problems. More specifically, CSA claims to address the following ‘CSV Pain Points’:

hampers automation
focus on evidence (for auditors), not on quality (“compliance culture”)
requires duplication of supplier activities
increases complexity of risk assessments
majority of test issues related to tester or quality of test script
leads to bad quality and many corrective and preventive action (CAPA)

Ten years after, CSA is still promoted as ‘FDA’s upcoming guidance’, being on CDRH’s A-list
for 2021. Although no draft is available for download and no concrete publication date is known, you find statements like “Do not wait!”, “Start your pilot now!”, and “Digitize!” Well, the latter seems to be a good recommendation in general, especially in the light of the pandemic, isn’t it? And the temperature is rising, even the ISPE has dedicated an appendix (S2) in its recent (Oct. 2020) Good Practice Guide (GPG) on Data Integrity by Design.

Let’s compare CSA to CSV, and verify if the new promises pass a reality check!

Same, but different

It is true that some view CSV as a burden, a formal activity to satisfy auditors, but not focusing on quality. Sometimes CSV is even regarded as a compulsory documentation exercise only, that does not add value, but introduces delay to a project.

Many still experience CSV as an impediment for innovation, and a regulatory burden that hinders progress. This is not how I have experienced validation in my career. And this is certainly not how we see and apply Validation Services at Körber Pharma! Instead of examining the pain points one by one, let’s review the arguments and ‘solutions’ provided by CSA ambassadors:

The second assessment leads to the same conclusion: Most aspects of CSA are well-known and non-unique.

Reality check

The arguments for CSA are often not specific and are either unclear or can be applied to CSV as well. So is the CSA approach to validation really new? Let’s review the statements and check if they withstand reality.

What’s new?

It should have become clear by now that the ‘CSV Pain Points’ listed above are a mixture of valid criticism, wrong accusations, and arguments intentionally linked to CSV, though they are unrelated. Truth be told, many arguments are not CSV- or CSA-specific, but relate to agility, quality, digitalization, automation, lean, etc.

All the promises that come with CSA (“better quality products”, “faster time to market”, “higher profitability” etc.) have yet to be proven, and the line of argument lacks a rationale why this cannot be achieved through CSV.

As a patient and consumer of medical treatment, I’d rather see the product, the process, and the system rigorously tested. I want a minimum of evidence (i.e. documentation) to be provided, and the validation process reviewed to minimize risk, and to increase my level of confidence.

Do I dislike or disapprove CSA? No, I do not! However I do not agree to the messages that strive to discredit CSV or portray CSA as a silver bullet for validation or compliance.

Let’s put things in perspective: CSA is a new term for a slightly different concept of ‘CSV 2.0’, emphasizing existing approaches like risk management, agility, automation, and digitalization. I fully support these trends and specifically like the shift towards more (upfront) thinking and less documentation, as shown in the following picture.

Finally, CSA is often used to promote digital tools for product lifecycle management (PLM), application lifecycle management (ALM), regulatory information management (RIM) etc. While the benefits of these tools may be attractive and the statements may be true, the tools do not relate to CSA in any way.

Let’s put things in perspective: CSA is a new term for a slightly different concept of ‘CSV 2.0’, emphasizing existing approaches like risk management, agility, automation, and digitalization.

Test documentation

In another blog on this topic, I found the following quote: “While testing all aspects of the software and validating its effectiveness were primary objectives of the CSV guidelines, it became more intrinsically focused on documentation and as a result was perceived as a deterrent to investing in more automated solutions.” And many webinars continue to use diagrams that show that with CSV 80 % of the time is spent on documentation, but only 20 % on testing, whereas it would be vice versa with CSA.

I could not be clearer: If you ever spent 80 % of your time on documentation in CSV, you simply misunderstood the concept and methodology! While the criticism to CSV may be applicable to a time when risk management was not mandatory (i. e. about 15 years ago), it is defeatism today.

Source: Mohamed Benkirane,
VP Medical Device Practice at Critical Manufacturing

First things first

The shift towards more (upfront) thinking and less documentation. While it’s more clear and certainly true, it’s not a paradigm shift.

Illustration with the process from documentation to critical thinking, and from critical thinking to documentation, and how they relate.

It’s a match! Achieving both, quality and compliance

Beware of a common mistake: “Good, better, best – never let it rest!” sounds tempting. However, while the best approach cannot be perfect, CSA is not the opposite of CSV.

Some publications even come with wrong statements and accusations like “CSV does not allow for automation” (e.g. automated testing), but this is simply wrong. The same goes true for flexibility and agility, two paradigms already applied for more than a decade. Overall, regulatory guidance supports and GAMP is consistent with all of the concepts now labelled as ‘CSA’.

So how to start (or continue) with your validation activities? The already mentioned appendix in the GPG on Data Integrity by Design certainly is not a promotion, but useful material describing CSA as an evolution of CSV, not a revolution. The shift towards critical thinking, less documentation, more agility etc. is clear and true, but it is not a paradigm shift. As an example, you already find the following statement in Appendix D5 of GAMP: “Unnecessary supporting documentation that does not add value to the normal test results should be avoided.” And GAMP 5 was published back in 2008 …

Instead of making a big fuss out of CSA, focus on real issues in the overall validation process, e.g.

misinterpretation/over-interpretation of regulations
risk-adverse compliance culture
lack of knowledge and expertise
wrong usage of risk-based approach

If you identify one of these, a ‘real’ solution that may help you to improve your approach would be the combination of the well-established GAMP 5 key concepts, critical thinking, and a focus on the intended use of your system.

Want to know more?

Let us discuss your CSA or CSV questions!