50+
Questions Covered
15
Major Topics
5
GAMP Categories
100%
Comprehensive Coverage

Introduction

Q. Introduction Topics:
  • About Yourself including education
  • Family
  • Hobbies
  • Working Experience

What is Validation / CSV

Q. What is Validation / CSV?

Definition 1:

It is a document evidence which provides high degree of assurance demonstrating that a procedure, process or activity carried out in testing then production maintains the desired level of compliance at all stages.

Definition 2:

It is the process of achieving and maintaining compliance with applicable regulation and fitness for intended use of computerized system by:

  1. Adopting principles, approaches, and life cycle activities within framework of validation plan and reports.
  2. Applying appropriate operational controls throughout the life cycle of the systems.

Definition 3 (Computer System Validation):

Confirmation by examination and provision of objective evidence that software specification conform to user needs and intended uses, and that the particular requirement implemented through software can be consistently fulfilled.

Types of Validation

Q. Types of Validation:

1. Prospective Validation

Prospective validation is establishing documented evidence, prior to system implementation, that a system performs as is intended, based on preplanned protocols. Production is not started until all validation activities are completed.

In Prospective Validation, Validate the New System.

2. Retrospective Validation

Retrospective validation will be required to justify the continued use of existing computerized systems that have been inadequately documented for validation purpose. Retrospective validation is not equivalent to prospective validation and it not an option for new systems.

In Retrospective Validation, Validate the existing system.

3. Concurrent Validation

Validation carried out in exceptional circumstances, justified on the basis of significant patient benefit, where the validation protocol is executed concurrently with commercialization of the validation batches.

In concurrent Validation, Validate the Run Time System (Batch Running System)

4. Revalidation

Repeating the original validation effort fully/partially with investigative review of performance data. The approach is essential to maintain the validated status of the system and ensuring that changes made to the process have not resulted in adverse effects on quality or process.

Types of Computer System Validation Environment

Q. Types of Computer System Validation Environment:

Production Environment: Validate Actual System. Validates those systems which actually used for production. e.g. RMG, FBD

Validation Environment: Validate Dummy System. At the time of server validation, we create the dummy Copy of Server and validate them. e.g. Chromeleon

Why CSV Required

Q. Why CSV Required:

Computer system validation helps to ensure that both new and existing computer systems consistently fulfill their intended purpose and produce accurate and reliable results that enable regulatory compliance, fulfillment of user requirements, and the ability to discern invalid and/or altered records.

  • Product Quality
  • Patient Safety
  • Data Integrity
  • Regulatory Compliance

CSV Documents Flow

1. GxPA (GxP Assessment)

This document identifies the GxP impact of the system and GAMP Category based on pre-defined criteria. GxP assessment evaluates and justifies whether the system is required to follow the Electronic Records applicability (Sub-part B) of 21 CFR Part 11 (ER/ES) and /or Electronic Signatures requirement (Subpart C) of 21 CFR Part 11 regulation (ER/ES).

2. URS (User Requirement Specification)

A document describing what the user accepts the software to do. A condition or capability that must be met or possessed by a system. The specification for equipment, facilities, utilities or systems should be defined in a URS.

3. FRS (Functional Requirement Specification)

I. If FRS document provided by vendor, same shall be reviewed by Lupin team for adequacy and may be accepted in the vendor template. User/system manual provided by vendor may be used as FRS wherever applicable.

II. Each functional requirement specified in the URS document for the system shall be addressed in the FRS document. In case any specific requirement defined in the URS cannot be implemented as a part of the system then reason for the same shall be addressed.

4. FRA (Functional Risk Assessment)

I. Assessment of requirements/specifications to determine risk class.

II. To determine rigor of testing as per identified risk class.

5. DCS (Design and Configuration Specification)

If DCS document is provided by vendor, then same shall be reviewed by Lupin team for adequacy and can be accepted in the vendor template. User/system manual provided by vendor can be used as DCS wherever applicable. Design configuration specification includes the configuration items for the application, hardware, software, operating system, interface (if any) and data for the implementation of system.

6. IQ (Installation Qualification)

IQ should confirm that the required physical hardware and software components have been installed and configured correctly in accordance with the specifications. IQ shall be executed as per preapproved test script. IQ shall be done on validation and production environment where ever applicable.

Typically, IQ may contain following tests (as applicable):

  • Verification of workstation configuration (host name, operating system, processor, RAM, hard disk, IP address etc.)
  • Verification of connected instrument/equipment name, ID, serial number
  • Verification of installed software Name and Version
  • Verification of Document
  • Verification Power Utility Test
  • Verification Environmental Condition Test
7. OQ (Operational Qualification)

OQ should confirm that system operates according to written and pre-approved specifications. The operational tests shall be designed to challenge and demonstrate the system’s ability to operate in accordance with the functional specifications. OQ shall be executed as per preapproved test script. OQ shall be done on validation environment. In case validation environment not applicable, then validation shall be done on production environment.

Typically, OQ may contain following tests:

  • Verification of SOP Test
  • Verification of Input / Output Test
  • Verification of User Management Test
  • Verification of ranges and boundaries
  • Verification of Screen Test
  • Verification of Communication Failure Test
  • Verification of Power Failure Test
  • Verification of Alarm Test
  • Verification of Report Generation
  • Verification of Data Backup and Restoration Test
8. PQ (Performance Qualification)

PQ should confirm that system is capable of performing the activities according to written and pre-approved specifications, while operating in its specified operating environment. PQ shall be executed as per preapproved test script. PQ shall be done on production environment.

Typically, PQ may contain following tests:

  • Verification of performance
9. TM (Traceability Matrix)

Traceability Matrix shall be prepared to ensure that all applicable requirement specifications have been verified.

10. VSR (Validation Summary Report)

All the activities performed during project phase shall be summarized in Validation Summary Report (VSR).

The VSR may describe the following points:

  • Validation overview/summary
  • IQ/OQ/PQ testing summary
  • Summary of validation deliverable

GAMP 5

Q. What is GAMP 5?

GAMP stands for Good Automated Manufacturing Practices. GAMP are guidelines provided for both users of automated pharmaceutical products and manufacturers of these products. GAMP was founded in 1991 by pharmaceutical industry professionals, with the aim of addressing the needs of the industry and basically to improve the changing expectations of regulatory agencies. It mainly wanted to provide understanding on how pharmaceutical companies should validate their computer systems.

GAMP-5 or version 5 of GAMP is the latest standard of the guidelines and was released in February 2008 by the International Society for Pharmaceutical Engineering (ISPE), a GAMP Partner Company.

GAMP provides practical guidelines that:

  • Facilitates the interpretation of regulatory requirements
  • Establishes a common language and terminology
  • Promotes a system life cycle approach based on good practice
  • Clarifies roles and responsibilities

GAMP 5 Software Categories

Q. GAMP 5 Software Categories:

Category 1: Infrastructure/Standard Software

Layered software, Software used to manage the operating environment.

Examples: Operating System, Database

Category 1

Category 3: Non-configured Software

Run-time parameters/minimal configuration may be entered and stored, but the software cannot be configured to suit the business process. If the product is purchased off-the-shelf and does not require configuration to support business processes, or where the default configuration is used by the regulated company, supplier involvement with the regulated company is typically limited to the provision of documentation, training, support and maintenance.

Examples: Firmware based applications, COTS (Commercial Off-the-Shelf Software)

Category 3

Category 4: Configurable Software Packages

Software, often very complex, that can be configured by the user to meet the specific needs of the user’s business process.

Examples: CDAS, SCADA, DCS, SAP, QAMS, LMS, DMS, Chromeleon

Category 4

Category 5: Custom (Bespoke) Software

Software custom designed and coded to suit the business process.

Examples: Internally and externally developed IT applications/Process systems, Custom ladder logic, Custom firmware, Customized spreadsheet (VBA/macro)

Category 5

GAMP 5 Hardware Categories

Q. GAMP 5 Hardware Categories:

Standard Hardware Components:

The majority of the hardware used by regulated companies will fall into this category.

Examples: Standard Communication cables, Standard Relays, Standard PLCs

Custom Built Hardware Components:

These requirements are in addition to those of standard hardware components. Custom items of hardware should have a design specification (DS) and be subjected to acceptance testing.

Examples: All custom built components

Commercial Off-the-Shelf Software (COTS)

Q. What is Commercial Off-the-Shelf Software?

Software defined by a market-driven need, commercially available, and whose fitness for use has been demonstrated by a broad spectrum of commercial users. Also known as COTS.

OR

COTS means, we use the system as available in the market, we can’t configure them.

21 CFR Part 11

Q. What is 21 CFR Part 11?

Title 21 CFR Part 11 is the part of title 21 of the code of Federal regulations that establishes the United States food and drug administration (FDA) regulations on electronic records and electronic signatures (ERES). Part 11, as it is commonly called, defines the criteria under which electronic records and electronic signatures are considered trustworthy, reliable and equivalent to paper records.

Q. What is Electronic Record?

Electronic record means any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.

Q. What is Electronic Signature?

Electronic signature means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature.

EU Annex 11

Q. What is EU Annex 11?

It is a European Union Regulation. It not only covers the electronic record and electronic signature but it also covers other areas like security and documentation.

Data Integrity

Q. What is Data Integrity?

Data integrity is the degree to which data are complete, consistent, accurate, trustworthy, reliable and that these characteristics of the data are maintained throughout the data life cycle. The data should be collected and maintained in a secure manner, so that they are attributable, legible, contemporaneously recorded, original (or a true copy) and accurate.

Note:

  1. Data can be ‘electronic’ or ‘paper based’ or ‘Hybrid’
  2. Data lifecycle: From initial data generation and recording through processing (including transformation or migration), use, retention, archiving, retrieval and destruction

ALCOA++ Principles

Q. What is ALCOA++ Principle?

A – Attributable: When creating a record, you must record the identity of the person or computer system that collected or generated the data. It’s also important to record the date of the collection or generation.

L – Legible: Data shall be recorded permanently. Record shall be durable & readable.

C – Contemporaneous: The data shall be recorded at the time the work is performed. Signature / initial with date.

O – Original: Record should be original rather than copies.

A – Accurate: No errors or if editing shall be corrected properly.

C – Complete: All recorded data requires an audit trail to show nothing has been deleted or lost.

C – Consistent: This primarily means ensuring data is chronological, i.e. has a date and time stamp that is in the expected sequence.

E – Enduring: Ensuring that data is available in long time after it is recorded, decades in some situations.

A – Available: Data must not only exist, it must be accessible. The most efficient way of achieving this is normally by recording data electronically.

Audit Trail

Q. What is Audit Trail?

The audit trail is the form of metadata containing information associated with actions that relate to the creation, modification or deletion of GxP records. An audit trail provides for secure recording of life cycle details such as creation, addition, deletion or alteration of information in a record, either paper or electronic, without obscuring or overwriting the original record.

An audit trail facilitates the reconstruction of the history of such events relating to the record regardless of its medium, including the “who, what, when and why” of the action.

Audit trails (identified by risk assessment as required) should be switched on. Users should not be able to amend or switch off the audit trail. Where a system administrator amends or switches off the audit trail, a record of that action should be retained.

Quality Risk Management

Q. What is Quality Risk Management?

Quality risk management is a systematic process for the assessment, control, communication and review of risk. It is an iterative process used throughout the entire computerized system life cycle from concept to retirement.

Q. What are the Hazards?

To recognize the hazards to a computerized system requires judgment and understanding of what could go wrong with the system, based on relevant knowledge and experience of the process and its automation.

Q. What is the Harm?

Potential harm should be identified based on hazards. Examples of potential harm include:

  • Production of adulterated product caused by the failure of a computerized system
  • Failure of an instrument at a clinical site that leads to inaccurate clinical study conclusions
  • Failure of a computerized system used to access a toxicological profile
Q. What is the Impact?

In order to understand the impact on patient safety, product quality and data integrity, it is necessary to estimate the possible consequence of a hazard.

Q. What is Probability of Failure?

Understanding the probability of a failure occurring to a computerized system assists with the selection of appropriate controls to manage the identified risks. For some types of failure such as software failure, however, it may be very difficult to assign such a value, thus precluding the use of probability in quantitative risk assessments.

Q. What is the Detectability of Failure?

Understanding the detectability of a failure also assists with the selection of appropriate controls to manage the identified risk. Failure may be detected automatically by the system or by manual methods. Detection is useful only if it occurs before the consequences of the failure cause harm to patient safety, product quality, or data integrity.

Q. How will the Risk be Managed?

Risk can be eliminated or reduced by design, or reduced to an acceptable level by applying controls which reduce the probability of occurrence, or increase detectability. Controls may be automated, manual, or a combination of both.

Q. Example of Risk

Scenario: Usage of system which does not generate electronic records and user management data.

Severity is 4: High
System does not have provision for user management and to generate and store electronic data. Hence severity ranked as 4. However, verification of process parameter checks are available to ensure process quality.

Detectability is 2: High
Identified risk is 100% detected. For operation of purified water system, trained persons are available. Provision of recording of quality parameters such as UV Intensity for lamp, Conductivity, TOC (Total Oxidation Count) of purified water generation system (Distribution Unit) on printouts is available. Data recorded on printouts are checked and reviewed by engineering personnel. During operation any departure from established standard is handled through deviation SOP.

Procedure for calibration of measuring instruments is in place at site. All the instruments such as (but not limited to) Temperature Sensor, Pressure Transmitter, Pressure Gauge, Pressure Switch on the equipment are calibrated with defined frequency.

Provision to maintain Data Governance is in place at site to cover operational activities that have direct impact on the integrity of data, such as Employee training to ensure trained and competent persons are working on the machine. Hence detectability of risk ranked as 2.

Likelihood / Occurrence is 1: Unlikely to happen
Based on available controls, likelihood ranked as 1.

RPN is 8
Risk evaluation is LOW

Good Documentation Practices (GDP)

Q. What is GDP (Good Documentation Practices)?

There must be written procedures in place describing the process and systems governing the creation, control, distribution, use, retention and disposal of GMP documents and records. These include records and documents associated with performing, monitoring, recording and evaluating all activities and operations that can directly or indirectly influence product quality, patient safety or data integrity.

The issue, revision, superseding and withdrawal of all GMP documents must be controlled. The current status of control documents within the quality management system must be available.

Documents must be authored and approved by authorized persons according to the type of document, subject matter, applicable regulations and local procedures. Signatures must include the author and/or owner and one or more approvers; quality assurance must approve all GMP procedures. The purpose of each signature must be evident and the name, role and date of each signer must be clearly stated.

The effective or issue date of the document, and where applicable, the expiration or periodic review due date, must be defined.

Key Principles:

  • Documents shall be clear and legible
  • While recording data such as reading from a scale, gauge or instrument, record immediately and directly onto the record provided for documentation
  • Document should be error free
  • Wrong entry should be corrected with sign and date

Computerized System Life Cycle

Q. Computerized System Life Cycle

The life cycle for any system consists of four major phases:

1. Concept

Activities in this phase will depend on company approaches to initiating and justifying project commencement. Generally, these activities are outside the scope of GAMP. However, gaining management commitment to provide appropriate resources is an important pre-project activity.

2. Project

Stages of this phase are described in the V-Model section.

3. Operation

This section provides comprehensive guidance on system operation. Not all of these activities will be directly relevant to all systems. The approach and required activities should be selected and scaled according to the nature, risk and complexity of the system.

4. Retirement

This section covers system withdrawal, system decommissioning, system disposal and migration of required data.

Software Development Life Cycle (V-Model)

Q. Software Development Life Cycle (V Model) (Project Phase)

Planning

Planning shall cover activities, responsibilities, procedures. Deliverables in this phase are validation plan & data migration plan.

Specification

Specifications must be approved and maintained throughout the life cycle.

Code, Built & Configure

When code is written, program coding standards must be defined. Code subjecting GxP functionality are subject to document review. Code reviews shall be conducted and documented by SMEs within the organization developing the solution. Code review should include confirmation of conformance of the code to: coding standards & relevant specifications, such as design specifications.

Testing

  • Installation Qualification (IQ)
  • Operational Qualification (OQ)
  • Performance Qualification (PQ)

Reporting and Release

The system must be accepted for use in the operating environment and released into that environment in accordance with a controlled and documented process. It consists of validation summary report and system release certificate, or the decision to release system can be included in validation summary report.

Q. Validation vs Qualification

Validation:

A process of establishing and documenting that the specified requirements of a computerized system can be consistently fulfilled from design until decommissioning of the system or transition to a new system. The approach to validation should be based on a risk assessment that takes into consideration the intended use of the system and the potential of the system to affect human subject protection and reliability of clinical trial results.

Qualification:

Action of proving and documenting that equipment or ancillary systems are properly installed, work correctly, and actually lead to the expected results. Qualification is part of validation, but the individual qualification steps alone do not constitute process validation. Expected results for system qualification should be traceable to a system specification, e.g. a User Requirements Specification (URS).

Data Backup & Restoration

Q. What is Data Backup & Restoration?

Backup is the process of copying records, data and software to protect against loss of integrity or availability of the original. Restore is the subsequent restoration of records, data or software when required.

Procedures should be established to cover routine backup of records, data and software to a safe storage location, adequately separated from the primary storage location and at a frequency based on risk.

Q. When is Backup and Restoration Process Completed?

Backup and restoration process is completed when the size and number of files of backed up folder/file and restored is same.

Archival & Retrieval

Q. What is Archival & Retrieval?

Archiving is the process of taking records and data offline by moving them to a different location or system, often protecting them against further changes.

If data is archived, it must be checked for accessibility, reliability and integrity. If relevant changes are to be made to the system, then the ability to retrieve the data must be ensured and tested.

Data Migration

Q. What is Data Migration?

Data Migration is the activity of transporting electronic data from one system to another, or simply the transition of data from one state to another.

Data migration may take place multiple times during the life cycle of a single computerized system.

System Types

Q. What is a Server?

It’s used to collect and store the data from clients.

Q. What is Standalone Software?

Standalone computer software system stands for the software installed on a single personal computer (PC) which generates data on the same PC hard disk in a pre-specified folder.

Examples: IR Solution, Enviro, UV Probe, IPC as well as clients of client-server based software systems like Chromeleon, LabSolutions, etc.

Q. What is Active Directory?

Active Directory is a centralized and standardized system that automates management of user data, security, and distributed resources like print services, DNS Services and enables interoperation with other user directories.

In Active Directory, a user account or ID is an object that consists of all the information that defines a domain user, which includes user name, password, and groups in which the user account has membership. This also helps identifying user through various attributes like Location, Grade, Display Name, and Employee Code.

Q. What is Thick Client?

A thick client performs the bulk of data processing operations locally using software stored on the client. Data is typically stored on the server.

Q. What is Web Client?

A web-based client performs the bulk of data processing operations using web-based applications. Application installation is not required in web client. Data is typically stored on the server. Role of client is to run application through web browsers.

Q. What is a Computerized System?

A computerized system consists of the hardware, software and network components, together with the controlled functions and associated documentation.

Achieving and maintaining compliance with applicable GxP regulations and fitness for intended use by:

  • The adoption of principles, approaches, and life cycle activities within the framework of validation plans and reports
  • The application of appropriate operational controls throughout the life of the system

Key Differences

Q. Difference Between 21 CFR Part 11 and EU Annex 11

21 CFR Part 11 only covers the ER & ES (Electronic Records & Electronic Signatures), but EU Annex 11 also covers other areas like security and documentation.

Q. Difference Between Guideline and Regulation

Guideline concept is used for universal application and regulation concept is used for only specific or one country.

Example: GAMP is a Guideline – it is applicable for all countries. 21 CFR Part 11 is a Regulation specific for US.

Q. Difference Between Computer System and Computerized System

Computer System is a regular system used for multi-purpose activities, and Computerized System is used only for dedicated purposes.

Validation Approaches by Category

Q. Approaches for a Non-configured Product (Category 3)

Refer to GAMP 5 guidelines for specific approach details.

Q. Approaches for a Configured Product (Category 4)

Refer to GAMP 5 guidelines for specific approach details.

Q. Approaches for a Custom Application (Category 5)

Refer to GAMP 5 guidelines for specific approach details.

Documents Prepared by GAMP Category

Q. Documents Prepared Under Category 1
  • GxPA
  • IQ
Q. Documents Prepared Under Category 3
  • GxPA
  • URS
  • VPP
  • IQ
  • OQ
  • PQ
  • TM
  • VSR
Q. Documents Prepared Under Category 4
  • GxPA
  • URS
  • VPP
  • FRS
  • RA (Risk Assessment)
  • DCS
  • IQ
  • OQ
  • PQ
  • TM
  • VSR
Q. Documents Prepared Under Category 5
  • GxPA
  • URS
  • VPP
  • FRS
  • RA (Risk Assessment)
  • DCS
  • IQ
  • OQ
  • PQ
  • TM
  • VSR

Additional Questions

Q. If Deviation Occurs, What Will We Do?

This question requires context-specific answer based on company procedures and deviation handling SOPs.

Q. How are Patient Safety, Product Quality and Data Integrity Related with CSV?

Computer System Validation ensures that systems consistently fulfill their intended purpose and produce accurate and reliable results. This directly impacts:

  • Patient Safety: Validated systems prevent errors that could harm patients through incorrect dosing, contamination, or adverse interactions
  • Product Quality: CSV ensures manufacturing processes are controlled and consistent, maintaining product specifications and efficacy
  • Data Integrity: Validated systems maintain ALCOA++ principles, ensuring data is trustworthy for regulatory compliance and decision-making