5 Things You Need to Know About Computer Software Assurance (CSA)

The Computer Software Assurance for Production and Quality System Software draft guidance stems from a multi-year collaboration between the FDA and industry. It identifies the common pain points and the FDA’s current thinking. The CSA guidance puts patient safety and product safety at the heart of the FDA assessment process. Watch our on-demand webinar with CSV specialist Darren Geaney “Achieving Computer Software Assurance with Digital Validation” to learn more about what the guidance means for validating computer systems.

Following the launch of their “Case for Quality” initiative in 2011, the FDA was uncertain why so few companies were investing in automated solutions and why so many continued to run long-outdated versions of software. The initiative, which set out to study quality best practice in medical device manufacturing, found that the burden of Computer Systems Validation (CSV) deterred technology investments and, as a result, inhibited quality best-practice.

The entire Life Sciences industry and the FDA joined forces and decided to take a collaborative approach on why it took so long to get a product to market and to validate software. The FDA then examined the traditional, document-driven Computer System Validation process and in September 2022 it issued its draft guidance on Computer Software Assurance for Production and Quality System Software which aims to enable a more effective and efficient risk-based approach to Computer System validation.

Read this article to discover five things that you need to know about Computer Software Assurance (CSA):

• Risk is based on the impact to patient safety and product quality
• CSA calls for the least burdensome documentation approach
• It can significantly reduce paperwork with unscripted and ad-hoc testing
• It results in less issues encountered in Production
• CSA is supported by regulatory bodies

1. Risk is Based on the Impact to Patient Safety and Product Quality

Software is not a physical thing—it is designed, it is lines of code, and it is not something that you can look at and measure. The CSA approach calls for risk to be assessed based on the impact to patient safety and product quality, measured against the requirement complexity. Product quality can impact patient safety, and, at the end of the day, the patient is the end user, not the manufacturer. If you have a particular feature or function that the software performs, what is the impact on the patient and what is the impact on product quality?

FDA recommends that manufacturers examine the intended uses of the individual features, functions, and operations to facilitate development of a risk-based assurance strategy. Manufacturers may decide to conduct different assurance activities for individual features, functions, or operations.

2. Least Burdensome Documentation Approach is Taken

Although the FDA has always called for the least burdensome approach to documentation, in the past not everyone has taken that to heart. Validation professionals have taken one process and no matter how risky it is, no matter what impact it may have, they have always followed the same process—they don’t really think before they act, because the process has dictated what they must do.

This meant that the traditional computer system validation approach, for organizations that wanted to implement a software system to drive efficiency and quality improvements, was arduous and time-consuming. Critical thinking was not applied, every feature was tested in the same way, and a burdensome documentation approach was applied.

Now, with CSA methodology, the FDA wants to flip the traditional approach so that 80% of a manufacturer’s time is spent on testing based on the appropriate risk level as a result of applying critical thinking, while only 20% of their time is spent on documentation. 

3. Reduces Paperwork With Unscripted Testing

Scripted testing is the traditional look and feel of Computer System Validation. You have a test instruction, with an expected result for that test instruction. You meet the test step and then proceed onto the next one.

With scripted testing, actual results are recorded, along with detailed test steps, and screenshots may not be required (see figure 1).

Figure 1: Example of Scripted Testing in Kneat

The FDA looked at this process and considered the best testing approach, based on the level of risk attached to what the actual feature or operation will be. As a result, validation professionals have been asked to think more critically about the risk level attached to their process and unscripted and ad-hoc testing concepts were introduced for lower-risk systems or features.

With unscripted testing, high-level test plan objectives should be established—no step-by-step test script procedure is required. Each test has a “pass” and “fail”, and the name and date of the tester is captured (see figure 2).

Figure 2: Example of Unscripted Testing in Kneat

With ad-hoc testing techniques, there are no pre-approved test scripts. Each Test has a Pass and Fail. You should just describe what was tested to verify that the feature worked correctly and include the name of the tester and date of test execution (see figure 3).

Figure 3: Example of Ad-Hoc Testing in Kneat

It is important to note that ad-hoc testing does not equal no documentation; you have features and functions that you must make sure that the system is verified for its intended use. Ad-hoc does not mean that you don’t have any objective evidence that the test has been completed.

4. Results in Less Issues Encountered in Production

Taking the traditional Computer System Validation approach typically involves drafting all the documentation, perhaps even undertaking one or two pilots, or dry runs, of test protocols, for example, OQs. The reason that is done is because organizations don’t want to see issues when it’s deployed on a particular production, or they don’t want the auditor to see that they had a particular issue in development.

The unscripted and ad-hoc testing that CSA allows for lower-risk features or systems will almost certainly result in less issues encountered in Production and that is basically the end goal of where validation and quality stakeholders want to get to. We all want to make sure that we conduct our computer software assurance cycle, we follow our procedure, we do it taking a risk-based approach—but when it comes to Production—we want to make sure that we are seeing far less issues than we might currently have. The CSA approach allows validation professionals to concentrate more on testing the functions that impact patent safety, product quality, and the complexity of those functions that the software is intended to perform. 

5. CSA is Supported by Regulatory Bodies

Using a risk-based approach is nothing new, and regulatory agencies such as the International Society for Pharmaceutical Engineering (ISPE®) who author Good Automated Manufacturing Practice (GAMP®) have been advocating this for two decades.

The ISPE published its second edition of GAMP®5 in July 2022, in advance of the FDA’s CSA guidance that was released in September 2022 and has dedicated an entire chapter to critical thinking.

The regulatory bodies, the FDA and the ISPE® have come together to take a commonsense approach based on the risk of a certain feature or system to patient and product safety. This new approach helps to drive industry investment in automated technology and new software, while ensuring that the regulations are met.

Final Thoughts

It is important to remember that the regulations have not changed. The guidance does not replace Computer System Validation; it is simply a framework designed to help manufacturers achieve software validation. When finalized, the guidance will supplement the FDA’s General Principles of Software Validation guidance except this guidance will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”) of the Software Validation guidance.

CSA is just a different approach to make sure that we still fulfill those regulations.

Learn More

Life sciences companies are increasingly relying on computer systems to produce the products patients need but haven’t changed their approach to validation. The FDA recommended CSA seeks to speed Computer System Validation (CSV) without sacrificing quality, but there’s a lot to know before you get started.

Our eBook, Understanding Computer Software Assurance (CSA), will give you a foundation of understanding so you can take the first step in your CSA journey. Read it to learn:

• What CSA is and why it is recommended by the FDA
• How CSA benefits life sciences companies
• Why digital validation complements CSA

GET YOUR COPY NOW

Presented by:

Darren Geaney, BEng, Kneat
A Computer Systems Validation specialist, Darren has over 23 years’ experience in software validation, providing right-sized computer system validation solutions to medical device companies. Knowledgeable in regulations FDA 21 CFR Part 820, 21 CFR Part 11, ISO 62304 and ISO 14971, Darren is ‘Lead Auditor’ accredited and experienced in supporting both internal and external audits (including FDA, IMB, TUV, and BSI).

About the Author

Lisa Wright, BA, GDL – Content Writer, Kneat

Lisa is an experienced writer whose work is focused on contextualizing the challenges and opportunities for validation, quality assurance, and compliance professionals operating in highly regulated industries. Outside of the office, she’s committed to education and has completed Kneat Academy End User and Power User 1 digital validation software training.