Validation:

“A planned sequence of activities to establish documented evidence which

provides a high degree of assurance that a specific process or system will

consistently produce a product meeting its pre-determined specifications and
quality attributes”.
Types of Validation: -

• A) Prospective validation (or premarket validation)

• B) Retrospective validation.
• C) Concurrent validation.
• D) Revalidation.

Computer system validation (sometimes called computer validation or CSV) is the process
of documenting that a computer system meets a set of defined system requirements.
Validation of computer systems to ensure accuracy, reliability, consistent intended
performance, and the ability to discern invalid or altered records is a critical requirement of
electronic record compliance, as described in the FDA 21 CFR 11.10(a) and EMA Annex 11.

GAMP 5 – Software Categories: -

GAMP guidance aims achieve computerized system that are fit for intended use and meet
current regulatory requirements, by building upon existing industry good practice in an
efficient and effective manner.

• The GAMP Guide contains the validation framework and associated procedures and
guidelines. It draws together the key principles and practices, and describes how they
can be applied to determine the extent and scope of validation for different types of
systems, ensuring that validation is scalable.

• Category 1 – OS and Firmware (Ex: Operating System, Security software, Anti

virus).

• Category 2 – Firmware (Obsolete)

• Category 3 – Non configured product (Ex: Notepad, Standard Excel sheet)

• Category 4 – Configured Product (Any configurable product, Excel sheet with

formula)

• Category 5 – Customization/Bespoke product (complete customization product

from scratch).
• Closed System - “An environment in which system access is controlled by persons

who are persons who are responsible for the content of electronic records that

are on the system.”

• Open System - “An environment in which system access is not controlled by

persons who are responsible for the content of electronic records that are on the

system.”

• Electronic record - any combination of text, graphics, data, audio, or pictorial

information represented in digital form that is created, modified, maintained,

archived, retrieved, or distributed by a computer.

• Electronic signature - Electronic signature" means an electronic sound, symbol, or process

attached to or logically associated with a record and executed or adopted by a person with the
intent to sign the record.

«Audit Trail» - An audit trail is a process that captures details such as additions, deletions, or
alterations of information in a record, either paper or electronic, without obscuring or over-
writing the original record. An audit trail facilitates the reconstruction of the history of such
events relating to the record regardless of its media, including the “who, what, when and
why” of the action.

Data Migration: Data migration activities are highly dependent upon the specific technology
and file structure of the electronic records being migrated.

Change Control: - Change Management applies to computerized systems subject to validation

throughout the system lifecycle from the Installation qualification phase to the retirement.

Backup & Restore: -, the 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.

Data Integrity: -
Data integrity is the maintenance of, and the assurance of the accuracy
and consistency of data over its entire life-cycle, and is a critical aspect to the design,
implementation and usage of any system which stores, processes, or retrieves data.
CAPA: -Corrective actions and preventive actions (CAPAs) are a very important part
of pharmaceutical quality systems. ... Actions should be taken to correct the existing product
nonconformity or quality problems (corrective actions) and to prevent the recurrence of the
problem (preventative actions).

• What is traceability Matrix?

Requirement Traceability Matrix (RTM) is a document that maps and traces user
requirement with test cases. It captures all requirements proposed by the client and
requirement traceability in a single document, delivered at the conclusion of the
Software development life cycle. The main purpose of Requirement Traceability
Matrix is to validate that all requirements are checked via test cases such that no
functionality is unchecked during Software testing/qualification.

Working in previous systems:

1.Refracto meter
2. Voltmeter
3.Barcode and pharma code verifier
4.visco meter
5.FTIR
6. Melting point Apparatus (MPA)
7.Polymeter

Validation Lead/Expert Interview Questions

Validation Lead/Expert Interview questions

• Difference between validation and Verification?
Validation is the process of checking whether the specification captures the
customer’s needs. “Did I build what I said I would?”
Verification is the process of checking that the software meets the specification. “Did
I build what I need?”
Verification Validation
1. Verification is a static practice of verifying 1. Validation is a dynamic mechanism of
documents, design, code and program. validating and testing the actual product.
2. It does not involve executing the code. 2. It always involves executing the code.
3. It is human based checking of documents
3. It is computer-based execution of program.
and files.
4. Verification uses methods like inspections, 4. Validation uses methods like black box
reviews, walkthroughs, and Desk-checking (functional) testing, gray box testing, and
etc. white box (structural) testing etc.
5. Validation is to check whether software
5. Verification is to check whether the
meets the customer expectations and
software conforms to specifications.
requirements.
6. It can catch errors that validation cannot 6. It can catch errors that verification cannot
catch. It is low level exercise. catch. It is High Level Exercise.
7. Target is requirements specification,
7. Target is actual product-a unit, a module, a
application and software architecture, high
bent of integrated modules, and effective final
level, complete design, and database design
product.
etc.
8. Verification is done by QA team to ensure
8. Validation is carried out with the
that the software is as per the specifications
involvement of testing team.
in the SRS document.
9. It generally comes first-done before
9. It generally follows after verification.
validation.

• What is Risk Assessment/Analysis? Have you performed any risk analysis in your
current job?
Quality risk management A systematic process for the assessment, control communication,
and review of risks to the quality of the pharmaceutical product across the product life-cycle.
risk Combination of the probability of occurrence of harm and severity of the harm. Yes, I
have performed functional risk assessment using FMEA tool

• Tell me how do you perform risk Assessment? Do you use any risk analysis tools?
Risk Management is a systematic process for the assessment, control, communication and
review of risks.

A Risk Management Program starts with identifying the possible risks associated with a
product or function or with the process used to develop, manufacture, and distribute the
product.
As part of risk assessment, we identify the risk scenarios for each requirement or product and
then categorize the probability, severity and detectability for each risk scenario. We conclude
the risk category based on multiplication of Severity (S) * Probability (P) * Detectability (D).
Based on risk priority, we plan to mitigate risks by testing or providing technical controls.

• What are the software categories as per GAMP 5?

Category 1: Infrastructure (OS and Firmware)
Category 2: Not Applicable
Category 3: Non configurable products
Category 4: Configurable Products
 Category 5: Customizable Products (Bespoke)

• What is CSV and why CSV is important?

Computer system validation (sometimes called computer validation or CSV) is the
process of documenting that a computer system meets a set of defined system
requirements. But the FDA’s idea of validation is much broader than simply
executing the software to validate output meets specification requirements (dynamic
testing).
Benefits of effective computer system validation

• Ability to provide all required documents readily by FDA, other regulatory agencies
and your customers.
• Maximize the value of the computer system and the employees that use it.
• Reduce labour cost by enhancing employee efficiency and effectiveness
• Effective project management are scheduled on time and budget
• Save money and time by discovering defects at early stage.
• Reduces risk, legal liability, not regulatory, is often the most important reason to
perform validation.
• Promotes continual process improvement.

• What are the challenges you face during your CSV project implementation?
o Interpretation of regulatory requirements
o Training
o Requirements
o Governance
o Personnel
o Tools used during implementation and post implementation
o Follow GDP requirements

• What are the different phases involved in Project life cycle?

o Concept/Initiation
o Project
o Operation
o Retirement

• Define different Qualification phases you involved?

IQ: The Installation Qualification Protocol verifies the proper installation and
configuration of a System. This can include ensuring that necessary files have been
loaded, equipment has been installed, the necessary procedures have been approved,
or the appropriate personnel have been trained.

DQ: Design Specifications describe how a system performs the requirements outlined
in the Functional Requirements. Depending on the system, this can include
instructions on testing specific requirements, configuration settings, or review of
functions or code. All requirements outlined in the functional specification should be
 addressed; linking requirements between the functional requirements and design
specification is performed

OQ: The Operational Qualification Protocol is a collection of test cases used to verify
the proper functioning of a system. The operational qualification test requirements are
defined in the Functional Requirements Specification. Operational Qualification is
usually performed before the system is released for use.

PQ: Performance Qualifications are a collection of test cases used to verify that a
system performs as expected under simulated real-world conditions. The performance
qualification tests requirements defined in the User Requirements Specification (or
possibly the Functional Requirements Specification). Sometimes the performance
qualification is performed by power users as the system is being released

• What is Master Validation Plan?

A Validation Master Plan, also referred to as "VMP", outlines the principals involved
in the qualification of a facility, defining the areas and systems to be validated, and
provides a written program for achieving and maintaining a qualified facility.

A VMP is a document that details the way a company will operate, who has control
over the various aspects of the validation activities, and how production, quality
control, and personnel management will be directed. The VMP allows companies to
agree upon and document an overall validation strategy, which can be provided to
regulators to serve as clear justification for the validation effort. The VMP allows
manufacturers to show they are in control of their quality system and focused on
quality.

Components in VMP:
Introduction
Purpose
Scope
Roles and Responsibilities
Validation Strategy
Validation Deliverables
Training Requirements
SOPs to be followed
Maintaining Validation state
Abbreviations
References

• What is traceability Matrix?

Requirement Traceability Matrix (RTM) is a document that maps and traces user
requirement with test cases. It captures all requirements proposed by the client and
requirement traceability in a single document, delivered at the conclusion of the
Software development life cycle. The main purpose of Requirement Traceability
 Matrix is to validate that all requirements are checked via test cases such that no
functionality is unchecked during Software testing/qualification.

• What is IQ, DQ, OQ and PQ?

Installation Qualification (IQ)
Installation qualification, or IQ, is a documented verification process that the
instrument or piece of equipment has been properly delivered, installed and
configured according to standards set by the manufacturer or by an approved
installation checklist.

Installation qualification requirements include checking for proper location, proper

energy supply and acceptable environmental conditions. There is also checking of
contents against the packing list, verifying software installation, documenting
computer-controlled instrumentation, verifying connections with peripherals, and
recording calibration and validation dates, among others.

Design qualification is defined as a verification process on the design to meet

particular requirements relating to the quality of pharmaceuticals and manufacturing
practices.
Operational Qualification (OQ)
Operational qualification is the next step in quality assurance and involves testing the
equipment and making sure it performs as specified, within operating ranges as listed
by the manufacturer. All aspects of the equipment receive individual testing and the
tester documents the proper operation of each.

Operational Qualification is necessary after installation, significant maintenance or

modifications to the equipment, or as a feature of scheduled quality assurance testing.
Operational qualification aspects that will be tested may include leveling and
fluctuation, repeatability, keyboard controls, deviation reports, calibration and
certificates, as well as performance reports.

Performance Qualification (PQ)

Before your equipment can be truly rated as qualified, you will need to put it through
performance qualification. Your process performance qualification protocol will
feature verification and documentation that all equipment is working within the
accepted range as specified, does it perform as expected under real conditions. All
instruments are tested together according to a detailed test plan and must generate
reproducible results.

Performance qualification protocols and validation should typically include but not be
limited to:

Data summary — A list of data that needs to be analyzed or recorded during the
testing procedure
Manufacturing conditions — Such as component inputs, operating parameters and
equipment environment
 Calibration and validation
Sampling plan — What sampling methods are used (if applicable)
Analysis methodology
Variability limits
Nonconformance contingencies

• Explain typical documents in CSV projects?

Validation Plan
URS/FRS/DRS
Risk Assessment
GxP Assessment
Qualification Protocol (IQ, OQ and PQ)
UAT scripts
RTM
Validation Summary Report

• difference between GAMP and CFR Part 11

GAMP is a Guideline and CFR Part 11 is standard set forth by FDA

CFR-21, Part 11 is a regulation set forth by the FDA that must be followed in regard
to electronic records and electronic signatures. More specifically, it requires
companies to implement controls, including audits, system validations, audit trails,
electronic signatures, and documentation for software and systems involved in
processing electronic data.
GAMP5 (Good Automated Manufacturing Practice) is a validation method for CFR-
21. It is essentially a set of document management requirements to ensure patient
safety, product
quality and data integrity in manufacturing.

• How do you review user requirement document? requirements of URS or FRS?

• Different types of requirement in your requirement document?

Functional Requirements
Data Requirements
Administration Requirements
Reporting Requirements
Regulatory Requirements
Integration Requirements
Interface Requirements
Audit Trail Requirements
End User Requirements
Technical Requirements
• Do you know anything about GAMP?
 GAMP stands for Good Automated Manufacturing Practice. This document is
published by an industry trade group called the International Society for
Pharmaceutical Engineering (ISPE) based on input from pharmaceutical industry
professionals.
A Risk-Based Approach to Compliant GxP Computerized Systems provides a
framework for the risk-based approach to computer system validation where a system
is evaluated and assigned to a predefined category based on its intended use and
complexity. Categorizing the system helps guide the writing of system documentation
(including specifications and test scripts and everything in between).
GAMP®5’s approach can be summed up by the V-model diagram. The V-model
juxtaposes the specifications produced for a system to the testing performed as part of the
verification process. The types of specifications associated with a system are tied to its degree
of complexity. For example, for a configured product (Category 4), requirements, functional
and configuration testing is conducted to verify the requirements, functional and
configuration specifications. However, functional and configuration specifications are not
required when using commercial off-the-shelf software (Category 3). As a result, the extent
of the testing performed would also be reduced.

The aim of conducting verifications is to demonstrate that the system functions as intended.
This is accomplished by using the requirements and specifications as an objective standard to
which the system is tested. The test scripts are traced to the requirements and specifications
they verify. If the test passes, the executed test script serves as documented evidence that the
associated requirements and specifications were met.

• What is CFR Part 11?

21 CFR Part 11 is the FDA's regulations for electronic documentation and electronic
signatures. It outlines the administration of electronic records in a medical device
company's quality management system.
• What is Open system and closed system? difference between both systems during
validation?
Closed System: Closed Systems means “an environment in which system access is
controlled by persons who are responsible for the content of electronic records that
are on the system.”
Open System: Open system means “an environment in which system access is not
controlled by persons who are responsible for the content of records that are on the
system.”

More security related tests should be performed for Open systems during validation

• What are the Key concepts of GAMP?

• Product and process understanding
• Life cycle approach within a QMS
• Scaleable life cycle activities
• Science based quality risk management
• Leveraging supplier involvement

• Have you involved in any Audits?

• Do you have knowledge about ISO 27001 or 9001

• what are the basic requirements of electronic records?

Basic requirements for recordkeeping systems that manage records on electronic
media. Collectively these requirements cover:

life cycle management

metadata
retrieval
integrity
security
backup
migration
permanent records
procedures
training
• What are the Security requirements for e-signatures?
Same as below:
• What are the basic requirements for e-signatures?
Signature Manifestation:
Any time an electronic record is signed, the following information must be visible and
associated with the signature:
✓ Printed name of signer
✓ Date and time of signature
✓ Meaning of signature (e.g., content is accurate, format is correct, data calculations
were verified)
All signed records clearly indicate who signed the record, when the signature was
executed, and the meaning of the signature

Each person must have a unique electronic signature that has never been and never
will be used by anyone else.
Electronic signatures that are NOT biometric (i.e., not based on a physical feature,
like a fingerprint) must be designed as follows:
They must be made up of at least two distinct parts (i.e., user ID and password).
❑ The first time a user signs a record after logging into a system, the system must
require them to enter ALL of the parts of their signature (i.e., user ID and password).
Subsequent signings during that same session only require the use of ONE part (i.e.,
password).
❑ Each time a user logs out and logs back in (or gets timed out by the system), the clock
restarts and the first record signed after logging in must require ALL parts of the
signature.
❑ Electronic signatures can only be used by the individuals to whom they are assigned.
❑ However, if an individual’s electronic signature must be used by someone it’s not
assigned to, the system must require at least two people to work together to do so.
❑ Electronic signatures that are biometric (e.g., fingerprint scan, retinal scan) can only
be used by the individuals to whom they are assigned.
❑ ID and password – each combination must be unique – and each user ID can only be
assigned to one individual, ever (no re-use allowed)
❑ Passwords must be checked, recalled, or changed from time to time

• What are the typical roles in CSV projects?

System Owner
Project Manager
Business Analyst
Validation Manager
Validation Team
QA Team
IT Team
• how do you classify the issues identified during qualification phases?
We classify issues based on severity on functionality or feature of the
application/system and following classifications are considered: Minor, Major and
Critical

• what is the defect life cycle?

#1) New: This is the first state of a defect in the Defect Life Cycle. When any new defect is
found, it falls in a ‘New’ state, and validations and testing are performed on this defect in the
later stages of the Defect Life Cycle.
#2) Assigned: In this stage, a newly created defect is assigned to the development team for
working on the defect. This is assigned by the project lead or the manager of the testing team
to a developer.
#3) Open: Here, the developer starts the process of analyzing the defect and works on fixing
it, if required. If the developer feels that the defect is not appropriate then it may get
transferred to any of the below four states namely Duplicate, Deferred, Rejected, or Not a
Bug-based upon the specific reason.
I will discuss these four states in a while.

#4) Fixed: When the developer finishes the task of fixing a defect by making the required
changes then he can mark the status of the defect as ‘Fixed’.
#5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester for
retesting the defect at their end, and till the tester works on retesting the defect, the state of
the defect remains in ‘Pending Retest’.
#6) Retest: At this point, the tester starts the task of working on the retesting of the defect to
verify if the defect is fixed accurately by the developer as per the requirements or not.
#7) Reopen: If any issue persists in the defect then it will be assigned to the developer again
for testing and the status of the defect gets changed to ‘Reopen’.
#8) Verified: If the tester does not find any issue in the defect after being assigned to the
developer for retesting and he feels that if the defect has been fixed accurately then the status
of the defect gets assigned to ‘Verified’.
#9) Closed: When the defect does not exist any longer then the tester changes the status of the
defect to ‘Closed’.
Few More:
• Rejected: If the defect is not considered as a genuine defect by the developer then it is
marked as ‘Rejected’ by the developer.
• Duplicate: If the developer finds the defect as same as any other defect or if the
concept of the defect matches any other defect then the status of the defect is changed
to ‘Duplicate’ by the developer.
• Deferred: If the developer feels that the defect is not of very important priority and it
can get fixed in the next releases or so in such a case, he can change the status of the
defect as ‘Deferred’.
• Not a Bug: If the defect does not have an impact on the functionality of the
application then the status of the defect gets changed to ‘Not a Bug’.

• Have you involved in any data migration projects? if yes, how do you verify data
migration projects?
I will discuss on this

• Have you authored any process documents or SOPs?

Yes.
• What is change management? Have you involved
Change Management is a process of initiating, analysing, documenting,
implementing, and tracking the changes without impacting the validation status of the
system/process. The steps include Change Initiation, Impact Analysis, Change
Approval, Implementation and Review/Closure.
Need Supported document’s: -

• Vendor Qualification documents.

• Security assessments
• Gap assessment
• User manual
• Sop’s
• IRA
• QRM