What is computer system validation (CSV) in GMP
- Published on: Mar 25, 2024
Computer system validation or CSV is also called software validation.
Regulated companies must prove with evidence that their software systems are performing as they are intended to perform correctly every time.
According to the FDA, the general principle of software validation is “Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses and that the particular requirements implemented through software can be consistently fulfilled.”
As general guidance, computer system validation in a GMP environment can be explained as “all new and legacy computerized systems that affect regulatory compliance processes (i.e., manufacturing, packaging, testing, storage and/or distribution of products) shall be validated to provide assurance that their system is capable of producing without error and that the results are robust and reproducible.”
Manufacturing facilities incorporate computer and computerized systems at all levels, from local Programmable Logic Controllers (PLCs) controlling manufacturing and laboratory equipment to high-level standalone systems.
Validation of those computerized systems provides evidence that the process outcomes are fit for purpose at all times.
Who should do what during Computer System Validation
1. System Owner:
All computer systems should have a System Administrator/Owner who is responsible for the implementation and management of the system by the end user and for approving the completion of the validation status.
2. Validation Team:
The validation team is responsible for establishing and maintaining computer validation programs, developing and approving computer validation policies, plans, protocols, and reports, and completing verification testing of all computer validation activities in compliance with regulatory and GAMP guidelines.
3. Application Owner:
The Application Owner is responsible for ensuring that validated computer systems are used for all GMP-related operations and that all computer systems are validated until retirement.
4. Information Technology (IT):
The IT team is responsible for ensuring that the validation studies accurately reflect the operation of the system and are practical, logical, and achievable.
IT is also responsible for supplying resources to assist with computer validation studies where required.
5. Quality Assurance Team:
Quality Assurance team is responsible for ensuring that the GMP aspects of the computer system validation program are performed in accordance with relevant procedures.
The team ensures that critical parameters meet regulatory expectations and that the validation report is conclusive with supporting evidence.
240 SOPs, 197 GMP Manuals, 64 Templates, 30 Training modules, 167 Forms. Additional documents included each month. All written and updated by GMP experts. Checkout sample previews. Access to exclusive content for an affordable fee.
Defining hardware and software categories
The depth and scope of validation activities depend on the type and criticality of the hardware and software built into the system.
The quality of the software development and testing need to be detailed in the impact (risk) assessment studies.
Hardware is generally divided into 2 categories:
i. Category 1 Standard hardware components
Standard hardware components should be documented, including manufacturer or supplier details and version numbers. Hardware Acceptance or installation qualification should verify the installation and connection of components.
ii. Category 2 – Custom built hardware components
These requirements are in addition to those of Category 1 components.
Bespoke (custom-built) hardware should have a design specification and be subject to acceptance testing.
A supplier audit should be performed for bespoke hardware development.
Assembled systems using bespoke hardware from different sources require verification testing confirming compatibility of interconnected hardware components.
Any hardware configuration should be defined in the design documentation and verified in the installation qualification stage.
Software is divided into 5 categories:
The validation approach and minimum requirements for software validation depend on the system’s category and GMP impact.
- Category 1: Operating Systems
- Category 2: Firmware (e.g. Standard Instruments, Micro Controllers, Smart Instrumentation)
- Category 3: Standard Software Packages
- Category 4: Configurable Software Packages
- Category 5: Custom Built or Bespoke Systems
Note: A System could have more than one software category.
What is the validation lifecycle?
The implementation of computer system validation shall follow the Lifecycle model (lifecycle phases and respective deliverables) as detailed below.
Just so you know, all phases of the lifecycle detailed do not apply to all categories of computer systems.
Validation lifecycle phases and deliverables
Phase 1: Definition
– Develop User Requirement Specification (URS).
Phase 2: Planning
– Update Site Validation Master Plan.
– Validation project Plan.
– Impact / Risk Assessment.
– System development Audit Report.
Phase 3: Design
– Develop Functional Specification (FS).
– Design Specifications.
– Design Qualification (Traceability report).
Phase 4: Construction
– Coding and Configuration Standards.
– Documented Source Code.
– Code Reviews.
– Unit and Integration Testing.
Phase 5: Installation and Configuration
– Technical Documents (e.g., installation guides).
– Baseline Hardware and Software Configuration.
Phase 6: Testing
– Installation Qualification (IQ).
– Operational Qualification (OQ).
– Performance Qualification (PQ).
Phase 7: Reporting
– Generate final computer system validation report.
Phase 8: Operational Management
– System Recovery Plan.
– Standard Operating Procedures (SOPs).
– Training.
– Periodic Review.
– Change Management.
– Maintenance.
– Errors and Deviations.
Phase 9: System Decommission
– Generate System Decommission Plan.
Primary elements of computer system validation
As you can see, the detailed validation lifecycle includes many activities. Not all of those are applicable in every situation.
We can compress those activities into fewer essential or primary steps of most validation efforts.
Note that we also did not include system development (construction, installation, and configuration) in our essential list of elements as, in many cases, those are done in a vendor environment and are mostly applicable to customizable software systems.
Element 1. Computer system validation plan
Each validation effort (original validation and re-validation required by extensive changes) must have a computer system validation plan.
The validation plan should define a list of computerized systems that require validation, the approach and activities, documentation, and records.
The individual validation plan is also called the validation project plan.
The computer validation plan must address all elements of the validation methodology, including the quality policy and the overall approach to complying with each element.
If a particular element is identified as “not applicable,” the plan must explain why it does not apply.
The system owner must approve the computer validation plan. The system owner can designate someone else to sign the plan (e.g., the system responsible). However, this must be clearly noted.
Suppose quality assurance (QA) approval of the validation documentation is required (e.g., for GMP systems) or desired (e.g., for GCP, GLP systems) before the computer system is used in production.
The appropriate QA group must approve the computer validation plan in that case.
Computer system impact assessment
All new computer systems (software project requests, computer hardware requests), legacy computer systems, or any changes to GxP systems must be assessed for their effect on product quality before project/change implementation.
The impact assessment must be performed during the planning phase and include the URS and FS in its scope to determine whether functions affect regulatory compliance.
The impact assessment should include a list of all functions and processes assessed and the results. This assessment is part of the change control system to determine validation requirements.
If validation is required, system components should be assessed and categorized to determine the validation approach required.
As required, you must document the outcome of the impact assessment in the validation project plan or protocol.
If the review determines that validation is not required, then a justification must be documented.
We have prepared a template in the section below to give you a good idea of conducting a computer system validation impact assessment.
240 SOPs, 197 GMP Manuals, 64 Templates, 30 Training modules, 167 Forms. Additional documents included each month. All written and updated by GMP experts. Checkout sample previews. Access to exclusive content for an affordable fee.
Element 2. User requirement specification (URS)
The user requirement specification (URS) should be done at the definition phase.
The URS defines the system’s intended uses. It should include all essential requirements (musts) and, if possible, a prioritized set of desirable requirements (wants).
Requirements should be linked to Performance Qualification, which tests the system in its operating environment, including the associated procedures.
Element 3. Functional specification (FS)
The creation of functional specifications is part of the design phase.
The system developers shall prepare the functional specification (FS) and describe how the system will function.
The FS shall identify the process and functions to be provided by the computerized system to meet the requirements defined in the URS.
The FS must be maintained and updated to reflect the system as implemented.
The functional specification links to Operational Qualification, which tests all specified functions.
Element 4. Design specifications
Developers and IT/Engineering will need to prepare design specifications as required.
These specifications shall specify minimum requirements for system hardware and software, ancillary software tools, and the baseline configuration.
This stage identifies how the System will meet the functional specification.
Element (vendor side): System Development – Construction, Installation & configuration
The construction phase of configurable and custom software packages includes programming, unit testing, integration testing, and code and/or configuration reviews.
Documentation of the construction phase shall include and is not limited to:
– Approved coding standards,
– Configuration documentation,
– Documented source code,
– Documentation of code review(s), and
– Unit and integration testing documents (e.g., protocols, test procedures, or test scripts) and results.
Before installing the system, a Factory Acceptance Test (FAT) may be carried out at the vendor’s premises in the presence of site personnel.
This should follow a FAT Plan/Protocol approved by the vendor and GMP site.
Site Acceptance Tests (SAT) may be performed before qualification testing. They should ensure that the system operates as indicated in the functional specification and meets the user requirements defined in the URS.
The validation team should perform a system integration test for custom software packages in which more than one software module has been integrated into a single system.
This test defines those tests that demonstrate that all software units communicate with each other correctly and the software system meets its pre-determined acceptance criteria.
Element 5: Installation qualification (IQ)
The purpose of the Installation Qualification (IQ) is to verify and document that all the key aspects of the hardware and software installation, including operating system details, adhere to approved design specifications (including hardware and software design specifications if applicable), manufacturer’s recommendations, and environmental conditions.
An IQ protocol should be prepared, and the level of validation required will be defined.
Element 6: Operational qualification (OQ)
The purpose of Operational Qualification (OQ) is to verify and document that the individual and integrated components of the system perform reliably and consistently within specified operating ranges as stated in the functional specification.
Operational qualification testing will be based on the impact assessment.
You must conduct the testing in a production or validation environment that has been demonstrated to be equivalent to the production environment.
Element 7: Performance qualification (PQ)
The Performance Qualification (PQ) aims to challenge the fully configured system in its normal integrated environment.
A protocol shall be prepared to verify the system’s performance in accordance with the approved user requirement specification, standard operating procedures, and related documentation.
Testing will be developed to challenge the system as it is used and operated under routine conditions and environmental parameters.
Element 8: Computer validation report
The Computer Validation Report should contain:
– The Computer Validation Plan
– The results from completed computer validation activities (e.g., completed computer validation activities table)
– A list of deliverables generated from the activities (e.g., SOPs, requirements, specifications, test scripts, and results) and the location of the deliverables.
This list is the cumulative “master index” for the system’s original validation documentation and must be updated for each subsequent re-validation or change.
– A statement or report summarizing the overall results of the validation indicating the system’s suitability for use.
240 SOPs, 197 GMP Manuals, 64 Templates, 30 Training modules, 167 Forms. Additional documents included each month. All written and updated by GMP experts. Checkout sample previews. Access to exclusive content for an affordable fee.
Other areas to remain focused on during computer system validation
Computer System Register:
GMP sites should maintain a register or master validation plan listing the computerized system requiring validation, re-validation, approach, and documentation.
A computer system master validation plan provides an overarching view of the validation status of all hardware and software assemblies.
Risk-based system assessment:
GMP sites should follow a risk-based (impact) system assessment to focus on what is useful and doable for quality assurance and compliance.
The impact assessment must be performed during the planning phase and include the user requirement specifications and functional specifications in its scope to determine if functions affect regulatory compliance.
Please don’t run vague test scripts because precise validation testing confirms systems perform as intended.
Vendor Audit:
Before purchasing bespoke or user-configurable software, a vendor audit should be performed to ensure that the software has been produced to appropriate quality standards.
The audit results shall be documented and used in the testing strategy.
Electronic Data, Electronic Records and Signature:
Computerized systems that capture electronic signatures or systems used to create, modify, maintain, or transmit electronic records for regulatory compliance should be validated.
Part 11 of Title 21 of the Code of Federal Regulations (21 CFR Part 11) provides industry guidance on implementing Electronic Records and Electronic Signatures.
Legacy systems:
Legacy computerized systems utilized for manufacturing process steps requiring regulatory compliance should be included in computer system validation projects.
Competent and responsible team:
The success of the validation efforts is heavily dependent on the team, which must have prior experience and awareness of the validation process, compliance guidelines, lab processes, and technology.
The team must also have sufficient members to avoid stress during the validation process.
Traceability Report:
A Traceability Report should be generated for each validation project.
This report should detail the traceability of the user, functional and design specifications, and qualification testing.
The report lists all relevant qualification documentation. Any acceptance criteria specified in the IQ, OQ, or PQ protocols should be traceable back to earlier phases of the lifecycle.
Documentation:
The computer system validation activities and results must be documented clearly, truthfully, and in real time.
They must also pass internal quality expectations and regulatory agency audits to ensure that all the required documentation is created for submission.
Change Control and Deviation:
The validation team should implement and follow a documented approach to deal with planned and unplanned deviations.
If a change is necessitated, an impact assessment must be carried out before implementing the change.
Training:
Training on the validated computer system should be part of the Qualification. All system operators need to be trained before using the system.
System Decommission:
If a System is to be replaced or no longer used, the validation team should prepare a decommissioning plan.
The retiring system’s data generated, stored, and calculated may have to be archived, transferred, or deleted orderly.
Conclusion:
A well-planned and executed computer system validation provides objective evidence that the system can produce exactly as intended.
It provides confidence that the process’s outcome is precise, accurate, robust, and reproducible. It qualifies the system to comply with regulatory expectations.
Ultimately, it facilitates the creation of a manufacturing environment for safe, pure, effective, and identifiable products for human and animal use.
A computer system validation project is difficult to accomplish.
It requires a team approach comprised of people experienced in validation, quality systems procedures, and regulatory frameworks.
A clearly written validation plan and strategy make the tasks achievable.
Please share your thoughts and ideas on this topic in the comment section below.
Author: Kazi Hasan
Kazi is a seasoned pharmaceutical industry professional with over 20 years of experience specializing in production operations, quality management, and process validation.
Kazi has worked with several global pharmaceutical companies to streamline production processes, ensure product quality, and validate operations complying with international regulatory standards and best practices.
Kazi holds several pharmaceutical industry certifications including post-graduate degrees in Engineering Management and Business Administration.
Related Posts
How to Perform GMP Audit in Six Steps
Deviation Investigation Guidelines in GMP Facilities
How to perform periodic review of systems and processes in pharmaceuticals?
Good information provided
Required full validation process example with documentation
Also give knowledge for GAMP 5