Introduction
While many organizations have a dedicated Computer System Validation (CSV) team, CSV is never a solo effort. That being said, how do we explain the concepts and basics to those who support CSV, but may not be too familiar with the process? ISPE’s GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems is a thorough and comprehensive guide for anyone who wants to learn more about CSV. Here, we have condensed the important concepts into easily digestible bites in order to give CSV-tangential personnel a crash course of sorts.
Basics
Depending on their proximity to the validation process, personnel can have wildly varying levels of CSV knowledge and understanding. Sometimes it’s easiest to begin with the basics:
What is validation?
o Validation is the establishment of documented evidence that a system is installed and operates within a predefined range of parameters for an intended use.
What is a computer system?
o By technical definition, a computer system contains one or more computers and associated software. However, the focus for CSV are computer systems subject to GxP regulations. This may include anything from automated laboratory equipment to cloud enterprise software and anything in between.
Even the simplest devices have ‘computers’ these days. Does that mean everything is subject to CSV?
o While the number of computerized systems in use is increasing in a typical GxP space, it’s important to draw the distinction between systems that generate, store, manipulate, or delete GxP data and those that do not. For all intents and purposes, only the former require CSV.
o Example: You have a device that upon use generates a physical printout with run parameters and results. However, this device does not generate any electronic data or store this data locally or to a network. While this system technically contains a computer (in the form of low level firmware), it would not be subject to CSV and can be treated as a non-computerized system.
The 4 phases of the CSV lifecycle
CSV is comprehensive of the entire lifecycle of a system, from even before the system arrives on premise to the day of its retirement. The goal of this article is to break these phases down into simple, easy-to-understand concepts.
Concept Phase
o This is the phase at which your organization has identified a need or purpose that will be fulfilled by a computerized system. The system is not on-premise and your organization may not even be sure which make or model is needed. During this time, the focus will be on appropriate allocation of resources, initial risk/GxP impact and determination of what the system must be capable of.
Project Phase
o The system you’ve chosen has now either been ordered or is already on site. This is the pre-implementation window where you finalize allocation of resources (i.e. project teams) and lifecycle documentation. This tends to be the most ‘active’ phase in the CSV lifecycle because it’s when the bulk of documentation is generated and testing is performed.
Operation Phase
o This is the phase during which your system is used for the GxP purpose it was originally acquired for and begins upon completion of your initial validation. This does not necessarily signify the end of traditional validation activities (i.e. lifecycle documentation, testing), as changes to a system can trigger necessary updates to the validation package.
Retirement
o This is the phase during which a system is removed from GxP use and ensures system decommissioning takes place and appropriate actions are taken to migrate GxP data as appropriate.
Creating a project team
Reiterating what was stated in the introduction, CSV is not a solo endeavor. At a minimum, you’ll want to establish a team that covers the four following functions:
Process Owner (PO)
o This is the owner of the business process the computer system will be utilized in. This could be QC when validating a lab instrument, or Manufacturing when validating a piece of automated manufacturing equipment. Their expertise is critical in defining system requirements, helping to evaluate risk/GxP impact and ensuring the standards to which we are validating are appropriate for ensuring fitness for purpose.
System Owner (SO)
o The SO is responsible for ensuring the computer system is available and maintained. Additionally, they are responsible for the security of the computer system and data that resides on it. The SO typically provides input when defining system requirements and ensuring the design and configuration is fitting to ensure continued security of the system and contained data.
Validation/CSV
o The Validation/CSV representative is responsible for facilitating the authoring and/or execution of validation lifecycle documentation. They will also serve as the validation SME – ensuring the purpose and intent behind the validation process is communicated to the project team to ensure resources and expertise is effectively utilized to cover as many bases as possible.
Quality
o The Quality representative will ensure the validation process complies with established regulatory requirements and internal SOPs. While not generally a technical subject matter expert, the quality representative will typically be familiar with the validation life cycle and ensure adherence to the established validation program. Ultimately, the quality representative will give the final ‘go ahead’ to release for GxP use based on the completion of validation and any other implementation tasks.
Critical CSV Deliverables and their purpose
The following deliverables are common validation lifecycle deliverables, but the list is not exhaustive. Depending on the complexity of the project or implementation, deliverables can be added or removed as necessary with the proper justification.
GxP Assessment/Initial Risk Assessment
o Typically initiated in the concept phase and finalized in the project phase, this is one of the first documents generated as part of the validation lifecycle. It serves to formally assess the GxP impact of the intended use of the system and identify (at a high level) risks to patient safety, product quality and data integrity.
User Requirements Specification
o Typically initiated in the concept phase and finalized in the project phase, the document is utilized to establish all the requirements the system must be capable of meeting. This document’s use is twofold: it serves to identify the right system for your organization (during the concept phase) and also serves as a list of requirements to test against (during the project phase).
Data Integrity Assessment
o Typically initiated and finalized in the project phase, it’s recommended to perform a data integrity assessment that assesses the system against relevant regulatory requirements. This assessment allows the project team to be proactive about identifying critical system gaps and creating a mitigation plan that can be tracked throughout the project phase.
Validation Plan
o Typically initiated and finalized in the project phase, the validation plan lays out the groundwork for how a system validation will be carried out including deliverables, strategy for release, and how the system will be handled post-release. While your CSV SOP may prescribe a set of activities or deliverables, there may be unique considerations to keep in mind from one system implementation to the next. The validation plan can serve to document project-specific considerations in addition to the more formulaic and consistent validation planning activities.
Risk Assessment
o Typically initiated and finalized in the project phase, risk assessments are utilized to categorize and appropriately mitigate risks associated with various aspects of the system operation. Appropriate management of risk can assist in ensuring adequate test rigor for different aspects/requirements. There is no single risk assessment template/format that is appropriate for validation, but rather, each style of risk assessment has its pros and cons and there is no one size fits all approach. A complex risk assessment such as the FMEA may be too much for a simple computerized system, whereas a functional risk assessment may not be granular enough for a highly complex and interconnected system.
Configuration/Functional/Design Specifications
o Typically initiated and finalized in the project phase, the specification document includes critical information regarding the design, functionality and configuration of the computerized system. For more complex systems, the specification documentation provides much needed information regarding how the product was built, altered and/or customized to meet the business process. Additionally, the specification documentation helps establish a state of control over the system that can be updated and modified as appropriate when changes are made.
Installation/Operational/Performance Qualification (IQ/OQ/PQ)
o The qualification protocols are typically initiated and executed in the project phase. These documents serve to establish test scripts that verify the installation, operational and performance requirements as dictated by your system specifications (i.e. user requirements specification, configuration specification, etc). Protocols can be combined or separated as needed, but ultimately should serve to verify all critical components, interfaces and functionality necessary to support the business process.
Requirements Traceability Matrix
o The Requirements Traceability Matrix is typically initiated and completed in the project phase after completion of qualification work. This document serves to trace requirements documented in the user requirements specification (or other relevant documents) to the appropriate section and step(s) in the qualification protocol(s).
Validation Summary Report
o The Validation Summary Report is typically initiated and completed in the project phase in order to fully document the completion of validation deliverables and summarize validation protocol activities and any associated discrepancies if applicable. The approval of this document typically signifies the completion of the project phase and release of the system for GxP use.
Other supporting processes and deliverables
While not necessarily part of the validation life cycle, there are other supporting processes and deliverables to consider before wrapping up initial validation and releasing for GxP use. Some other considerations include:
Standard Operating Procedures (SOPs)
o During the project phase and prior to GxP use, SOPs should be established at a minimum for Operation/Maintenance and System Administration. Other SOPs can be created as necessary based on system-specific and business process-specific considerations. While the creation of SOPs is oftentimes seen as an activity parallel to validation, treating the processes holistically can lead to more cohesive and complete documentation. The validation project team is typically the first group of people to interface with the system and will often have strong insight and input when it comes to SOP development.
Supplier Assessment
o Like every other supplier in the GxP space, the supplier of a computerized system should be assessed. The supplier will provider ongoing support throughout the remainder of the asset lifecycle and appropriate actions should be taken to ensure the vendor has a robust quality management system and ability to perform the actions and services required. While the supplier assessment and qualification process is not directly tied to the validation process, it is one of the many requirements that must be considered when validating a system for GxP use.
This is only the tip of the proverbial ‘CSV iceberg’. We hope it has helped you – if even slightly – become more familiar with the basics of CSV.