Tailoring validation with a smart risk strategy
Tailoring validation with a smart risk strategy
27. April 2023
Validation is a critical aspect of the software development and implementation process. It ensures that the software meets its intended use (the user requirements), works as expected, and is free from defects.
However, validation can be time-consuming, resource-intensive, and costly. Tailoring validation with a smart risk strategy can help overcome these challenges and deliver better results.
Risk management for computerized system validation (CSV) is a process of assessing potential risks associated with the system and developing strategies to mitigate those risks.
Risk assessments are conducted at various stages of the validation process. The risk assessment technique is also applied as part of the change control process to identify verification and revalidation needs.
An overall risk management process flow for CSV is presented and discussed based on two questions:
“Do I need to validate?”
and
“What level of validation is required?”
Image: Qudits Validation Approach, © Qudits
Description: Green highlights indicate smart risk strategy, starting with Risk-based Decisions During Planning (High-Level Risk Assessment), continuing with Functional Risk Assessment, Risk-based Decisions During Testing (qualification phase in orange), Functional Risk Assessment in Change Control (System Operation), and closing with Risk-based Decisions During Retirement (Retirement).
This includes initial risk activities such as software/hardware categorization, GxP impact assessment, FDA 21 CFR Part 11 electronic records/signatures assessments, supplier assessments, functional risk assessments and impact assessments for changes/release upgrades.
That’s the theory. But what about the practice? We asked our validation expert Sandra Weniger-Niederberger.
What do you mean by Tailoring Validation?
Tailoring Validation means identifying the critical aspects of the solution that require validation and focusing on those areas, while reducing the validation effort and time spent on non-critical aspects.
Tailoring Validation is not a one-size-fits-all approach.
Does it require different risk assessment tools throughout the system and validation life cycle chain – as suggested by GAMP?
Four risk assessments with accompanying risk controls, measures, and decisions have been proven effective:
- Supplier assessment (mandatory)
- System high-level risk assessment covering all initial categorizations and assessments (Do I need to validate?)
- Functional risk assessment (What level of validation is required?); and
- Impact assessment for system changes/upgrades/ retirements
How do I set a logical rationale for the risk-based assessments and decisions?
For this, experience and common sense are required. Experts should be consulted. All risk-based assessments and decisions must be traceable, documented, and approved by dedicated responsibilities. The rationale behind a decision must be transparent. Decisions can be based on objective numerical factors as well as subjective expert opinions. GxP relevant aspects such as patient safety, product quality, and data integrity should always be considered.
"Tailoring Validation means identifying the critical aspects of the solution that require validation and focusing on those areas. It is not a one-size-fits-all approach.
With a smart, risk-based approach, validation costs can be reduced by 10-20%."
Sandra Weniger-Niederberger
How do I assess the supplier and what factors increase or reduce the risk?
This can be done on a risk-based approach due to the complexity of the solution (as-a-service vs. on-premise, standard vs. configured or custom-built interfaces, reference customers) and its deployment area (affected business processes and use of new technologies such as AI, blockchain, and cloud).
It is highly important to clarify the supplier's knowledge of GxP/CSV and FDA 21 CFR Part 11, as well as their understanding of regulated processes in software development and documentation, testing, operations (backup, restore, archiving), and especially IT security, data privacy, user and change management.
Questions to consider include how updates are applied, whether there are documentations provided, and how contact and documentation provision are managed during inspections.
If a supplier can demonstrate a certified or compliant quality management system with clearly defined responsibilities and documentation processes, this is a good starting point. From an economic perspective, on-going operational costs related to changes, documentation, and support inquiries should be considered.
What are the key components of a High-Level Risk Assessment (HLRA)? What role does the business process play in the HLRA? How can it effectively be combined with other projects and initiatives?
We recommend considering the HLRA as a comprehensive system analysis, integrating other aspects such as records management and data privacy with the appropriate experts, even if they are not part of the principal validation process.
Typical components of the HLRA include a brief description, responsibilities, software/hardware categorization (standard, configured, etc.), technologies used, impacted business processes, (optional: data privacy, records management criteria, system and data availability requirements etc.), and the final GxP relevance (yes/no).
Individual system modules can be declared as non-GxP relevant. The HLRA is typically documented as an approved checklist with questions to be answered.
Which standard is suitable for a functional risk assessment?
In principle, any method can be used that corresponds to the intended purpose and provides the corresponding result. Nevertheless, a two- or three-stage Failure Modes and Effects Analysis (FMEA) has proven to be effective, and inspection acknowledged.
What are mandatory components of a FMEA and how do I define plausible test measures? What is suitable as a risk mitigation actions?
A standard FMEA defines a list of functions (not user requirements), potential failure modes, effect of failures, severity classification, potential failure causes, occurrence classification, current controls, and detection classification. The three classifications define the risk classification number (severity x occurrence (stage 1) + detection (stage 2)).
Depending on its criticality, the definition of risk mitigation actions on a functional (system changes), testing (no testing, positive and negative testing, stress testing), documentation (procedures, instructions, specifications), or training level is required. Optionally, a third stage can be added to create a new risk classification number AFTER a defined risk mitigation action is or has been implemented. This can be useful if the FMEA is used – as foreseen – as system lifecycle document.
To what extent can risk mitigation actions minimize a FMEA risk number?
Risk mitigation actions can minimize an existing risk classification and lead to a new risk classification. It is an acknowledged state-of-the-art codex that a risk classification can only be reduced by one level, even if there are multiple or major mitigation actions defined.
Can a risk-based approach reduce validation costs?
Yes! With a smart, risk-based approach, validation costs can be reduced by 10-20%.
In conclusion, tailoring validation with a smart risk strategy can help in delivering better results, reducing costs, and ensuring compliance with regulatory requirements by customizing the validation process focusing on the critical aspects of the solution.
Author
Riad Beqiri
Riad's consulting focus is on ensuring uniform PM standards for efficient collaboration, optimizing project execution, and supporting project management. In addition, he accompanies software validations.
Author
Sandra Weniger-Niederberger
Sandra's consulting focus is on the interpretating and risk-appropriately implementating regulatory requirements in processes and systems, coaching, and digital transformation projects in Compliance, Quality Management as well as Regulatory Affairs.
