Skip to main content
Regulatory compliance activities, such as Computer System Validation (CSV), can often be burdensome and challenging if they are approached without risk assessment. Often CSV deliverable completion is driven by procedures that are not designed to account for risk in relation to system, requirement, and processes. It tends to be a process focused more on documentation and less on critical thinking. However, there is no reason that CSV can’t be a flexible, configurable process based on risk to patient safety, product quality and efficacy. A guidance topic currently in draft from the Center for Devices and Radiological Health (CDRH) titled ‘Computer Software Assurance for Manufacturing, Operations, and Quality System Software’ aims to change the paradigm on how computer system validation is performed. Yet, the principles to be presented in the draft guidance are ones that can be implemented now and have always been totally acceptable by the FDA. We (the industry) have created our own hurdles, not the FDA.
The Computer Software Assurance draft guidance hasn’t been issued yet. There have been multiple presentations and training on the topic led by material contributors and stakeholders involved in the development of the guidance. In a nutshell, Computer Software assurance focuses less on documentation and testing and more on critical thinking and assurance requirements. The figure below simply demonstrates the concept.
Computer Software Assurance is a risk-based approach. If you have been around validation before, I am sure you are familiar with risk-based approaches; it is not a new concept. What has been lacking in other guidance, perhaps, is a tangible, concrete way to implement and apply a risk-based approach to CSV. The Computer Software Assurance guidance will do that.
To make Computer Software Assurance effective, an in-depth understanding of the software’s risks to patient safety and product quality is essential. This is usually done in the form of a documented risk assessment. The risk assessment is “front-and-center” because it drives everything else that happens with the validation of the system/software. Again, this is not a new concept. However, in the CSV world, risk assessment results do not always lead to a different approach or different outputs. For example, there are types of software (e.g. learning management) that may have a low risk/criticality result from a risk assessment. Computer Software Assurance will contend that a system like this should have very little if any validation done. These are usually off-the-shelf and have little direct/indirect impact to patient safety or product quality. Or another example could result in a company still validating it but not taking any screen shots. Or perhaps performing ad hoc testing or unscripted testing. All of these options are completely acceptable to the FDA and will be presented in the guidance.
The reality is the FDA never explicitly said how to perform CSV. ISPE GAMP 5 is all about risk-based CSV and the concept is certainly not new. However, we have chosen (as an industry) to perform CSV a certain way when in reality – the FDA never said we must do it that way. The new guidance on Computer Software Assurance will present a practical and efficient way to approach software compliance that gives the risk assessment and critical thinking it’s appropriate importance.
Please contact Kevin Marcial for more information on computer system validation or computer software assurance or our Contact Us form.
