Risk-based computer system validation is a term widely used in our industry now, but understanding and implementing it can be challenging. Often, organizations want “cheaper, faster, better” but when the details of a risk-based computer system validation (CSV) plan are defined, they may find that their expectations have not been met. There are natural concerns with risk-based CSV such as loss of project quality and data integrity. Yet, there are straightforward ways to approach a validation plan to ensure that patient safety and product quality are being met in a risk-based computer system validation project
First, there are a couple of excellent resources to aid in the process of a risk-based computer system validation. The first is ISPE’s GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems. This is the seminal guideline on how to execute risk-based CSV. It is also one of the premier industry standards on CSV in general. One can follow the strategy and deliverable guidance outlined in the document to develop and execute a compliant and efficient project. For general CSV and some risk-based guidance, I also recommend the Drug Information Association (DIA) Computerized Data Systems in Nonclinical Safety Assessment-Current Concepts and Quality Assurance. This document complements GAMP 5 in many ways and offers another viewpoint on computer system compliance and quality. Of note – see our recent blog post on the FDA-propose update to the GLPs for nonclinical studies if you work in that industry and are considering computer system compliance.
The approach to a well-executed computer system validation project, as in any project, starts in planning. A formal planning deliverable, such as the Validation Plan, Validation Strategy, or Testing Strategy will drive the project’s scope, strategy, and documentation activities. These plans can include risks assessment that will refine the focus, approach, and criteria for success of the validation project. One must do more than claim a risk-based approach is being used. There should be a documented assessment to demonstrate due diligence when leveraging risk in a project.
There are many ways to develop a system risk assessment for the purpose of a risk-based validation. In general, one examines the business and regulatory risks involved with the system and identifies any areas that are more and less critical. For example, at the system level an application that collects data for study or production work is considered both business critical and subject to regulatory requirements. A web application that serves as a dashboard to the data collection system, but does not allow for data manipulation / transformation, might be looked at as less critical. The categories and criteria for assessment should be as objective as possible. Some suggested elements include:
- GAMP category (off the shelf, configured, customized – see GAMP 5 for more information on categorization)
- Vendor status (driven by a vendor audit)
- System functionality and complexity (what does it do? This is an important driver)
- Regulatory applicability and criticality (another major aspect of the assessment)
- The novelty of the system to the organization (such as in-house experience and adherence to infrastructure requirements / SOPs)
- The system’s use in the given industry (e.g. is it widely used in the CGMP world?)
- Business criticality (e.g. an organization may deem a system critical even though it is not subject to GxPs).
I recommend looking at RAMP (Risk Assessment and Management Process): An Approach to Risk-Based Computer System Validation and Part 11 Compliance (by Richard M. Siconolfi and Suzanne Bishop, 2007). Much of what I have laid out here is recommended in this approach. It is important to identify the stakeholders that should be involved in the assessment and to ensure they are included in the decision-making process.
Risk-based computer system validation can be done in a clean, clear-cut way that clearly documents the rationale for the project’s approach to validation and defines its objectives. The significant motivator behind a risk-based approach to computer system validation is clearly the justification for focusing testing efforts on the most business and regulatory critical aspects of the system. I will address how to actually do this in the next blog post.