Editor's note: This is the third post in a series of five summarizing a podcast series devoted to CSA. Links to previous posts are listed below.
In traditional Computer System Validation (CSV), assurance needs are near the bottom of the pyramid. In CSA, the FDA's modernized approach to validating computer systems, assurance needs are near the top, second only to critical thinking. Given the rising importance of assurance needs, defining them and understanding what you need to address in this crucial phase is essential.
What are assurance needs?
In a nutshell, assurance needs are the activities you need to address to ensure that a computer system works as intended. According to the FDA's Case for Quality initiative, determining these activities is a three-step process. First, you must identify the intended use of the system, which is explained in the user requirements. Second, you must employ a risk-based approach to pinpoint the high-risk areas of the system, focusing primarily on areas that directly impact patient safety. The final step is to determine when a failure in these identified areas will have a high-risk impact on the system's quality and safety. These areas will require the most rigorous validation.
Risk-based assurance activities
Once you have determined the assurance needs of the system, you will know the activities you must perform to address these needs. Key activities include:
Meet and validate user requirements: The intended use of the system must be clear. You must ensure that all user requirements have been met and validated and that using the system does not jeopardize quality or safety, with patient safety being the primary concern.
Ensure you are working from a quality-centric (not compliance-centric) mindset: The driving force behind CSA is the need to reclaim the quality-centric mindset lost to CSV. With CSV, the focus is on gathering documentary records for auditors. But focusing too much on regulatory requirements and compliance can cause (and has caused) life sciences professionals to lose sight of quality. Take an honest look at your organization. Do you have a quality culture? If you do, compliance is more or less assured.
Conduct a risk assessment: Assessing risk at the beginning of the validation initiative is critical to avoid wasting time and resources validating low- to medium-risk areas that do not warrant the highest degree of rigor. Risk-based assurance requires applying the appropriate level of rigor for the determined level of risk to patient safety or product quality. The risk assessment drives everything else that happens during the validation of the software.
Leverage available tools: The advancement of new technology means we have many tools at our disposal to perform validation. The CSA methodology encourages the use of computer system validation tools to automate assurance activities.
Test appropriately: Testing is the third phase of CSA, but determining which testing methods (scripted, ad hoc, exploratory or automated) to use and how much testing is required starts in the assurance needs phase. I'll deep dive into testing in my next post. The overall goal is to focus more on testing, less on scripting.
Identify documentation needs: Documentation is the fourth and final phase of CSA, but again, understanding the assurance needs associated with the documentation you will produce starts during this phase. What is adequate documentation? What is the objective evidence? These are the questions you must consider. I'll deep dive into documentation in a future post.
The end goal
In the assurance needs phase of CSA, you must demonstrate that the software will perform as intended and that you are using the right technologies, techniques, systems (manual and automated) at the right time. The end goal is to assure everyone, including regulators, that the validation effort meets or exceeds your quality standards and is in line with regulatory requirements.
Note: This blog post summarizes the third episode of a 5-part podcast series devoted to CSA. Next time, I'll examine the different testing modalities, such as scripted, ad hoc, exploratory and automated testing, and highlight a root cause common with poor test scripts and test steps.
Want to dive deeper into assurance needs? Click on the link below to listen to the full podcast.
Want to catch up on previous posts in this series?
Steve Thompson has worked in Life Sciences for over two decades in both Information Technology and Quality Assurance roles. He’s a certified systems auditor and has audited hundreds of companies globally. A published author, a frequent speaker at industry conferences, on the Board as a Director for PRCSQA, Editorial Advisory Board for ISPE, and Elite Faculty member for KENX, and Adjunct Lecturer, Temple University, School of Pharmacy, RA/QA Graduate Program. He was honored with an APEX 2020 award of excellence for a peer-reviewed article he co-authored for Pharmaceutical Engineering on Blockchain. Currently, as Director Industry Solutions at ValGenesis, Steve helps Life Science organizations realize the potential benefits of advanced technologies, along with inherent risks.