Computer System Validation: A Requisite Approach for Laboratory

Article
Computer System Validation: A Requisite
Approach for Laboratory
1
Gaurav Tiwari*, 1 Ruchi Tiwari, 1 Kaushlesh Prasad and 1 Awani K Rai
1
Department of Pharmaceutical Sciences, Pranveer Singh Institute of Technology, Kanpur (UP).
As quality is the most important aspect of any manufacturing process, it becomes necessary to validate or
examine all the peripherals connected to the manufacturing instruments used in pharmaceutical industries.
Among all these peripherals, computer is the main equipment, as it controls and handles all the activities
of manufacturing process starting from input to finalized output. So the requirement of Computer System
Validation (CSV) has naturally expanded to encompass computer systems used both in the development
and production of pharmaceutical products and medical devices. American FDA and the UK MHRA regulate
the guidelines for the use of computer systems in pharmaceutical industries. Validation is based on taking a
structured life-cycle approach by initial planning of the project through development, testing and release to
final operation and maintenance of the computer. A 4Q model is recommended for the whole process with
just four phases: design qualification (DQ), installation qualification (IQ), operational qualification (OQ) and
performance qualification (PQ). Through validation there is documented evidence that a process or a system
meets the previously specified parameters. Validation ends when the system is retired and all important quality
data is successfully migrated to the new system. The ultimate goal of any CSV project is to realize and sustain
compliance, while ensuring the peak performance and functionality of computer systems. Above all the system
must be shown to operate correctly, consistently, and according to its specifications.
Keywords: Validation, Computer System, Phases of Validation, Validation of Hardware, Validation of Software.
Introduction
Pharmaceutical product research,
development, manufacturing, and distribution
require considerable investment of both
time and money, and computerization has
become a key to improving operational
efficiency. Computer system application
is expected to support the fundamental
requirement of minimizing risk to product
identity, purity, strength, and efficacy by
providing consistent and secure operation
and reducing the potential of human error.
In the last decade, computerized systems
have become a vital part in the manufacture
of Active Pharmaceutical Ingredients.
Proper functioning and performance of
software and computer systems play a
major role in obtaining consistency, reliability
and accuracy of data. Therefore, cGMP
regulations imply that the functionalities of
those computerized systems, which have
an influence on the quality of API, should
be validated and thus Computer System
Validation (CSV) should be a part of any
good development and manufacturing
practice. Validation shall demonstrate that
the parameters defined as critical for its
operation and maintenance are properly
(adequately) controlled and managed.
It is essential that the validation is
practical and achievable, adds value to the
project, and is concentrated on the critical
elements of the system [1] .
The computer system qualification for
validation program requires the regulated
*Email id: lda_mpharm@rediffmail.com
pharmaceutical industry to provide
guidance and reference on regulatory
requirements, validation methodologies,
and documentation. The pharmaceutical
organization requires to follow GxP
regulations from the U.S. Code of Federal
Regulations (CFRs) and the Food and Drug
Administration (FDA) to conduct proper
CSV program for company’s regulatory
requirement and for quality policy of the
company.
Validation
The word ‘validate’ is defined in the
dictionary as to make ‘valid’, ‘to legalize’
or indeed ‘to confirm’. But what does
this exactly mean? Through validation
there is documented evidence that a
process or a system meets the previously
specified parameters. It is a scientific
method for confirming the value of a system
for a specific purpose. So, validation in
the pharmaceutical and medical device
industry is defined as the documented
act of demonstrating that a procedure,
process, and activity will consistently lead
to the expected results. It often includes the
qualification of systems and equipments.
The US FDA in 1987 defined validation
as “Establishing documented evidence that
provides a high degree of assurance that a
specific process will consistently produce
a product meeting its pre-determined
specifications and quality attributes”.
This definition was originally applied to
the drug manufacturing processes, but
validation is applied to many aspects of the
healthcare and other regulated industries
and businesses which include services,
equipment, computer system, processes &
cleaning. So, it is the process by which all
aspects of a process (including buildings,
equipments, and computer systems) are
shown to meet all quality requirements,
and comply with the applicable rules and
regulations regarding product quality,
safety and traceability. In each case,
the objective of validation is to produce
documented evidence, which provides a
high degree of assurance that all parts of
the facility will consistently work correctly
when brought into use. In case of computer
systems there is an expectation that
validation should allow quality to be built
into all stages of a regulated system’s life
cycle in order to minimize system errors
and problems. It is a requirement for
Good Manufacturing Practices and other
regulatory requirements. Since a wide
variety of procedures, processes, and
activities need to be validated, the field
of validation is divided into a number of
subsections as follows:
1. Cleaning Validation
2. Process Validation
3. Analytical Method Validation
4. Computer System Validation
The use of the word ‘Validation’, in
connection with computers has originated
Pharma Times - Vol. 44 - No. 02 - February 2012 20

in USA. The term ‘validation’, as used in the
USA, refers to any type of evidence about
a state of affairs. ‘Validated’ is therefore
not an adjective for an object, but rather an
adjective for a property of an object. The
terms validation and qualification are very
often used interchangeably. The precise
meaning of and the difference between the
terms is discussed more in theory than in
practical usage. Because a distinction is
only possible in theory, the line between
qualification and validation is indeed blurred.
However, as already shown in practice, a
clear distinction is not necessarily required.
For completeness the terms are explained
briefly below. The following definitions of
the terms have been established as a type
of standard.
• H a r d w a r e a n d d e v i c e s a r e
qualified.
• Methods and processes are
validated.
The combination of qualified hardware
and validated processes and methods
results in a validated computer system [2] .
Computer System Validation
Computer system installed in the
corporations are validated to assure that
they are of high quality, meet business
needs, and are designed, implemented and
managed in compliance with appropriate
regulatory requirements to perform in a
manner consistent with their intended
functions. The intent of validation is to
ensure that regulated systems meet the
criteria listed below:
1. Systems are developed according to
quality software engineering principles.
2. Systems meet the business needs of
their users and
3. Continue to operate correctly and reliably
throughout their life cycle.
So in general, CSV is mostly just good
software engineering practice in a formal
setting; making sure that the right system
is built and managing changes. CSV
can be defined as “an ongoing process
of establishing documented evidence to
provide a high degree of assurance that a
computerized system (and its components)
will consistently perform to predetermined
specifications”. For a process supported
by a computer system, we can say that
CSV provides documented proof that
the system (e.g. hardware, software,
peripherals and networks) will repeatedly
and reliably do what it is designed to do,
is “fit-for-purpose”, and complies with the
applicable rules and regulations. CSV
must show that the system operates
predictably according to its specifications,
and that conclusion is supported by formal
and documentary evidence. The ultimate
goal of any CSV project is to realize and
sustain compliance, while ensuring the
peak performance and functionality of
these systems. CSV is a sound business
practice that supports quality assurance,
and promotes responsible and profitable
operations. CSV provides the evidence that
a computer system does what it is intended
to do according to the system specifications
and operating procedures [3] .
CSV: Regulatory
Requirements
In 1983, FDA published a guide to the
inspection of Computerized Systems in
Pharmaceutical Processing, also known as
the ‘bluebook’ (FDA 1983). Recently, both
the American FDA and the UK Medicines
and Healthcare Products Regulatory Agency
have added sections to the regulations
specifically for the use of computer systems.
FDA introduced 21 CFR Part 11 for rules on
the use of electronic records and electronic
signatures (FDA 1997). FDA regulation is
harmonized with ISO 8402:1994 (ISO 1994),
which treats “verification” and “validation”
as separate and distinct terms. On the
other hand, many software engineering
journal articles use the terms “verification”
and “validation” interchangeably, or in
some cases refer to software “verification,
validation, and testing (VV&T)” as if it is a
single concept with no distinction among
the three terms. The General Principles
of Software Validation defines software
verification as “that which provides objective
evidence that the design outputs of a
particular phase of the software development
life cycle should meet all of the specified
requirements for that phase.” The software
validation guideline states: “The software
development process should be sufficiently
well planned, controlled, and documented to
detect and correct unexpected results from
software changes.” U.S. regulations related
to computer systems are listed in Table1.
A lot of regulatory agencies worldwide
pay increasing attention on computerized
systems:
1. AIFA (Agenzia Italianadel Farmaco)
www.agenziafarmaco.it
2. Eudralex www.ema.europa.eu
3. MHRA www.mhra.gov.uk
4. ICH www.ich.org
CSV: Overview
Validation of computer systems is not
a once off event. Validation should be
considered as part of the complete life cycle
of a computer system. This cycle includes
the stages of planning, specification,
programming, testing, commissioning,
documentation, operation, monitoring and
modifying. For new systems, validation
starts when a user department has a need
for a new computer system and thinks
about how the system can solve an existing
problem. For an existing system, it starts
when the system owner gets the task of
bringing the system into a validated state.
Validation ends when the system is retired
and all important quality data is successfully
migrated to the new system. Important steps
in between are validation planning, defining
user requirements, functional specifications,
design specifications, validation during
development, vendor assessment for
purchased systems, installation, initial
and ongoing testing and change control.
In other words, computer systems should
be validated during the entire life of the
system. Because of the complexity and
the long time span of computer validation,
the process is typically broken down into
life cycle phases. V-model describes the
system development life cycle and is
frequently used. This model comprises of
User Requirement Specifications (URS),
Functional Specifications (FS), Design
Specifications (DS), development and
testing of code, Installation Qualification
(IQ), Operational Qualification (OQ) and
Performance Qualification (PQ). The
V-Model is quite good if the validation process
also includes software development. It also
looks quite complex for true commercial, off
the shelf system with no code development
for customization. Phases like design
specification or code development and code
testing are not necessary. For such systems
the 4Q model is recommended with just four
phases: design qualification (DQ), installation
qualification (IQ), operational qualification
(OQ) and performance qualification (PQ).
Both the 4Q and the V-model do not address
the retirement phase. The 4Q model is
also not suitable when systems need to
be configured for specific applications or
when additional software is required that
is not included in the standard product and
is developed by the user’s firm or by a 3rd
party. In this case a life cycle model that
combines system development and system
integration is preferred.
User representatives define User
or System Requirement Specifications
(URS, SRS). If there is no vendor that
offers a commercial system, the software
needs to be developed and validated
by following the steps on the left side of
Figure 3. Programmers develop functional
specifications, design specifications and the
code and perform testing in all development
phases under supervision of the quality
assurance. The vendor that best meets the
user’s technical and business requirements
is selected and qualified [5] .
Pharma Times - Vol. 44 - No. 02 - February 2012 21

Table 1. U.S. Regulations Applicable to Computer Systems
CFR TITLE SYSTEM IMPACT
People
21.CFR.211.25
21.CFR.211.34
Hardware
21.CFR.211.63
21.CFR.211.67
21.CFR.211.68 (a)
Personnel qualification
Consultants
Equipment design, size and location
Equipment cleaning and maintenance
Automatic, mechanical and electronic
equipment
Qualifications, training and experience for assigned functions
Qualifications, training and experience to provide the service
Record qualifications and work undertaken
System design, capacity and operating environment
Preventative maintenance program at appropriate intervals,
to formal procedures identifying responsibilities, schedule,
tasks.
System reliability with routine calibration, inspection or checks
to formal maintenance procedures; results to be documented
Software
21.CFR.211.68 (a), (b)
Automatic, mechanical and electronic
equipment
Accuracy, Repeatability and Diagnostics
Application software documentation
Configuration agreement
Access Security
Input/ Output signal accuracy and device calibration
Data Storage
Software backup, archiving and retrieval
21.CFR.211.100
Written procedures: Deviation
Formal approved and documented procedures (Software)
Deviation report
21.CFR.211.101 (d)
21.CFR.211.180 (a), (c),
(d), (e)
21.CFR.211.182
21.CFR.211.186 (a), (b)
21.CFR.211.188 (a), (b)
21.CFR.211.192
21.CFR.211
FD and C Act, Section
704 (a)
Charge-in of components
General requirements (Records and
Reports)
Equipment cleaning and use log
Master production and control records
Batch production and control records
Production record review
Electronic record; electronic
signatures
Inspection
Automated component, addition verification
Data record availability, retention, storage medium and
reviews
Maintenance records
Application software documentation
Data reproduction accuracy
Documented verification of process steps
Operator identification
Data record review by quality control
Electronic record/ electronic signature type, use, control and
audit trial
Access to computer system
Qualifications of CSV
Design Qualification (DQ): “Design
qualification (DQ) defines the functional and
operational specifications of the instrument
and details the conscious decisions in the
selection of the supplier”. DQ should ensure
that computer systems have all the necessary
functions and performance criteria that will
enable them to be successfully implemented
for the intended application and to meet
business requirements. Errors in DQ can
have a tremendous technical and business
impact, and therefore a sufficient amount of
time and resources should be invested in
the DQ phase. For example, setting wrong
functional specifications can substantially
increase the workload for OQ testing, adding
missing functions at a later stage will be
much more expensive than including them
in the initial specifications and selecting a
vendor with insufficient support capability
can decrease instrument up-time with a
negative business impact. Steps for design
specification normally include:
1. Description of the task the computer
system is expected to perform.
2. Description of the intended use of the
system.
3. Description of the intended environment
(Includes network environment).
4. Preliminary selection of the system
requirement specifications, functional
specifications and vendor.
5. Vendor assessment.
6. Final selection of the system requirement
s p e c i f i c a t i o n s a n d f u n c t i o n a l
specifications.
7. Final selection and supplier.
Installation Qualification (IQ): Installation
qualification establishes that the
computer system is received as designed
and specified that it is properly installed
Pharma Times - Vol. 44 - No. 02 - February 2012 22

in the selected environment, and that this
environment is suitable for the operation
and use of the instrument. The list below
includes steps as recommended before and
during installation.
1. Before installation
• Obtain manufacturer's recommendations
for installation of site requirements.
• Check the site for the fulfillment of
the manufacturer’s recommendations
(utilities such as electricity, water, gases
and environmental conditions such as
humidity, temperature, vibration levels
and dust).
2. During installation
• Compare computer hardware and
software, as received, with purchase
order (including software, accessories,
spare parts).
• Check documentation for completeness
(operating manuals, maintenance
instructions, standard operating
procedures for testing, safety and
validation certificates).
• Check computer hardware and
peripherals for any damage.
• Install hardware (computer, peripherals,
network devices, cables).
• Install software on computer following
the manufacturer’s recommendation.
• Verify correct software installation,
e.g., are all files accurately copied on
the computer hard disk. Utilities to do
this should be included in the software
itself.
• Make back-up copy of software.
• Configure network devices and
peripherals, e.g. printers and equipment
modules.
• Identify and make a list with a description
of the hardware, include drawings where
appropriate, e.g., for networked data
systems.
• Make a list with a description of the
software installed on the computer.
• Store configuration settings either
electronically or on paper.
• List equipment manuals and SOPs.
• Prepare an installation report.
Installation and installation qualification
(IQ) of larger commercial system is normally
performed by a supplier’s representative.
Both the supplier’s representative and a
representative of the user should sign off
the IQ documents [6, 7] .
Operational Qualification (OQ):
“Operational qualification (OQ) is the
process of demonstrating that a computer
system will function according to its functional
specifications in the selected environment.”
Before OQ testing is done, one should
always consider what the computer system
will be used for. There must be a clear
link between testing as part of OQ and
requirement specifications as developed in
DQ phase. Testing may be quite extensive if
the computer system is complex and if there
is little or no information from the supplier
on what tests have been performed at the
supplier’s site. Extent of testing should be
based on a justified and documented risk
assessment. Criteria are: Impact on product
quality, Impact on business continuity,
Complexity of system, Information from the
vendor on type of tests and test environment,
Level of customization.
Most extensive tests are necessary
if the system has been developed for
a specific user. In this case the user
should test all functions. For commercial
off-the-shelf systems that come with a
validation certificate, only tests should be
done of functions that are highly critical
for the operation or that which can be
influenced by the environment. Specific user
configurations should also be tested, for
example, correct settings of IP addresses of
network devices should be verified through
connectivity testing.
Performance Qualification (PQ):
“Performance Qualification (PQ) is the
process of demonstrating that a system
consistently performs according to a
specification appropriate for its routine use”.
Important here is the word ‘consistently’.
Important for consistent computer system
performance is regular preventive
maintenance, e.g., removal of temporary
files and making changes to a system in
a controlled manner and regular testing.
In practice, PQ can mean testing the
system with the entire application. For a
computerized analytical system this can
mean, for example, running a system
suitability testing, where critical key system
performance characteristics are measured
and compared with documented, preset
limits. PQ activities normally can include
complete system test to prove that the
application works as intended. For example
for a computerized analytical system this
can mean running a well characterized
sample through the system and compare
the results with a result previously obtained,
Regression testing: reprocessing of data
files and compare the result with previous
result, Regular removal of temporary files,
Regular virus scan, Auditing computer
systems.
Most efficient is to use software for
automated regression testing. The software
runs typical data sets through a series of
applications and calculates and stores the
final result using processing parameters
as defined by the user. During regression
testing the data is processed again and
the results are compared with previously
recorded results. Normally such tests do
not take more than five minutes but gives
assurance that the key functions of the
system work as intended [8] .
Validation of HARDWARE and
SOFTWARE
Validation of Hardware
Hardware validation is essential when
the hardware is to be used in complex
systems that are used in cost-critical and
life-critical applications. This motivates
the need for a systematic approach to
verify functionality. Hardware verification
complexity has increased to the point
that it dominates the cost of design. In
order to manage the complexity of the
problem, we have to investigate validation
techniques, in which functionality is verified
by simulating (or emulating) a system
description with a given test input sequence.
However, formal techniques suffer from
high complexity, so the verification of large
designs using formal techniques alone
is often intractable. The complexity of
validation can be made tractable by using
a test sequence of reasonable length,
and the degree of certainty provided can
become arbitrarily close to 100%. A practical
difficulty in the validation of large hardware
systems is choosing the proper design
abstraction level which provides a trade off
between simulation complexity and error
modelling accuracy. In practice, validation
is performed at all levels of abstraction from
behavioural down to layout. Behavioural
hardware description languages, such as
VHDL and Verilog, have only been fully
accepted by industry for less than a decade,
and research in behavioural validation is still
developing.
Validation of Software
As the pharmaceutical and chemical
research and testing industries phase in and
start to comply with GALP, we are becoming
more frequently summoned, to provide
information and documentation which may
help to satisfy the reporting and compliance
requirements.
The Software Life Cycle
Concept
An idea for software improvement is
expressed and formed usually in one of the
following ways:
1. A user has a need for some feature
or improvement, and makes a specific
request.
Pharma Times - Vol. 44 - No. 02 - February 2012 23

2. A user or prospective customer raises
an issue and expresses its importance.
3. Individuals close to the development
process recognize and identify
improvement possibilities.
Analysis and Design
A program structure analysis is
conducted to determine the effects of the
improvement:
1. That the underlying structure of the
program can support the added
functionality.
2. That backward compatibility can be
maintained with data collected by
previous program versions.
3. The extent that modules, functions and
procedures will be affected.
4. The extent that additional functions,
procedures and algorithms will be
required.
5. A determination of program branch
points affected.
6. Specification of variables and flow
control flags needed for implementation
and control.
Coding and Implementation
During the coding and implementation,
phase organization issues are observed:
1. The coding languages, style and format
is kept consistent with the rest of the
application’s modules, functions and
procedures.
2. Variables and condition flags are
assigned and named in accordance
with Scintco’s standard mnemonic and
naming guidelines.
Test and Verification
The developer tests and verifies that:
1. The functionality of the improvement is
in accordance with the requirements and
specifications.
2. The user interface, input, branching,
processing and output are as specified
by the requirements.
3. The functionality within procedures
affected by the improvement is not
compromised when the improvement is
bypassed.
4. In special request cases, a pre-release
version may be available for beta testing
by those making the request.
Minor changes and cautionary notes are
appended to the Software Advisory Bulletins,
so they more accurately depict proper and
useful operation and advise the user of
issues requiring special consideration [2, 9] .
Validation and Release
The distributor receives the program
version package with the applicable
Software Advisory Bulletins, then tests and
verifies the system for proper operation, and
when satisfied that everything is in order,
prepares the version for final release.
Operation and Maintenance
User Documentation: The Software
Advisory Bulletins serve as the raw material
from which the distributor produces the
necessary user documentation and
incorporates it into the instruction manual.
The Software Advisory Bulletins are
normally included in an appendix of the
instruction manual. The distributor and the
developer provide recommendations and
guidelines which a user may find useful
when developing SOPs for a particular
study.
Anomaly Report
An Anomaly Report form is provided for
the purpose of reporting a software problem.
It includes:
1. A description of the location and place
within the software system, that an
anomaly is first encountered or observed,
i.e. the sequence of events which leads
to an expression of the anomaly.
2. A description of the effect and impact
the anomaly has on the system or on
the affected software function.
3. To the extent possible, report the cause
or perceived /believed cause of the
anomaly.
4. To the extent possible, report the level
of criticality the anomaly represents.
5. I n c l u d e r e c o m m e n d a t i o n s a n d
suggestions that represent a resolution
of the anomaly.
Validation Master Plan and
Project Plan
The Validation Master Plan is a document
that describes how the validation program
will be executed in a facility. It should be
developed according to company policies
and internal procedures, including both
infrastructures and applications. SOPs
should be in place together with a formal
System Life Cycle Concept which describes
all the relevant activities for creating and
maintaining qualified infrastructure and
application. All validation activities should be
described in a validation master plan which
should provide a framework for thorough and
consistent validation. A validation master
plan is officially required by Annex 15 of the
European GMP directive. FDA regulations
and guidelines don’t mandate a validation
master plan; however, inspectors want to
know what the company’s approach towards
validation is. The validation master plan is
an ideal tool to communicate this approach
both internally and to inspectors [10] . It also
ensures consistent implementation of
validation practices and makes validation
activities much more efficient. In case there
are any questions as to why things have
been done or not done, the validation master
plan should give the answer. Computer
Validation Master Plans should include:
1. Introduction with a scope of the plan,
e.g., sites, systems, processes.
2. Responsibilities by function.
3. Related documents, e.g., risk
management plans.
4. Products/processes to be validated and/
or qualified.
5. Validation approach, e.g., system life
cycle approach.
6. Risk management approach with
examples of risk categories and
recommended validation tasks for
different categories.
7. Vendor management.
8. Steps for Computer System Validation
with examples on type and extent of
testing, for example, for IQ, OQ and
PQ.
9. Handling existing computer systems.
10. Validation of Macros and spreadsheet
calculations.
11. Qualification of network infrastructure.
12. Configuration management and change
control procedures and templates.
13. Back-up and recovery.
14. Error handling and corrective actions.
15. Requalification criteria.
16. Contingency planning and disaster
recovery.
17. Maintenance and support.
18. System retirement.
19. Training plans (e.g., system operation,
compliance).
20. Validation deliverables and other
documentation.
21. Templates and references to SOPs.
22. Glossary.
23. V a l i d a t i o n R e p o r t a n d o t h e r
documents.
Validation Report
When the validation project is completed,
a validation summary report should be
Continued on pg 29
Pharma Times - Vol. 44 - No. 02 - February 2012 24

Continued from pg 24
generated by the system owner. The report
documents the outcome of the validation
project [11] . The validation report should
mirror the validation project plan and should
include:
1. A brief description of the system.
2. Identification of the system and all
software versions that were tested.
3. Description of hardware used.
4. Major project activities.
5. Listing of test protocols, test results and
conclusions.
6. Statement on system status prior to
release.
7. List of all major or critical issues and
deviations with risk assessment and
corrective actions.
8. Statement that all tasks have been
performed as defined in the project
plan.
9. Statement that validation has been
performed according to the documented
procedures.
10. Listing of all deliverables.
11. Final approval or rejection statement.
12. The validation report should be reviewed,
approved and signed by QA and the
system owner.
Checklists
Checklists should help to verify that
validation tasks are identified and performed.
However, some validation tasks are specific
for specific systems. Therefore going
through checklists does not mean that
everything is covered for each system nor
does it mean that all checklist items are
applicable for every system.
Templates and Validation
Examples
Templates are useful to effectively follow
and document validation tasks and results.
Validation examples help to get adequate
information on how to conduct validation
and to prepare deliverables [12] .
Documentation
Basic Documentation
I n a d d i t i o n t o t h e b a s i c G L P
documentation (i.e. training record, job
description, and CV), there should be an
inventory of all computerized systems being
used in the facility listing system name,
system owner, location and validation
status.
Standard Operating Procedures
GLP requires a set of standard operating
procedures for the development and/or
routine use of validated computerized
systems addressing the following topics:
1. Operation: In addition to the User
Manual, an SOP should describe how
the computerized system will be used
for its intended purpose.
2. Security: Two levels of security should
be addressed:
Physical security of the system (e.g.
locked server room).
Logical security of the system (e.g. User
ID, password) including user rights.
3. Problem log: This should describe
measures how to document and solve
problems encountered during routine
operation of the system. Reference to
change management procedures should
be taken into account.
4. Maintenance: Regular and preventive
maintenance should be described.
5. Change control: Changes to the
computerized system, except regular
and preventive maintenance, should
be evaluated for their potential impact
on the validation status. The procedure
how to perform a change control should
be described.
6. Backup and restore: Procedures
for backup of the application and
data should be defined including their
frequency, period of retention for backup
copies, the method and responsibility
for periodic backups, and the process
of restoration.
7. Periodic testing: The system needs
to be monitored regularly for correct
operation including device checks. Basic
functionality testing should be performed
on a regular basis.
8. Contingency plan and disaster
recovery: A contingency plan should
specify procedures to be followed in
case of system breakdown or failure.
A detailed plan for disaster recovery
should be available.
9. Archiving and retrieval: Procedures
should describe how and where
documents, software and data are
archived, including the period of retention,
retrieval mechanism, readability, and
storage conditions.
10. Quality Assurance: Procedures how
QA will review and inspect the system
life cycle and the IT-infrastructure in a
GLP-regulated environment.
Apart from the SOP on operation of a
system, these SOPs may be as generic
as possible; i.e. they need not be written
separately for each application [7, 13] .
Additional System Specific
Documents
1. Installation manual: A set of instructions
that have to be followed when the
system is installed. In addition, it defines
the minimum hardware and operating
system requirements.
2. User manual: Describes how to use
the system, usually provided by the
vendor.
3. Release notes: Contain information
on changes and enhancements of
the software compared to a previous
version.
4. Vendor audit report: Describes the
results of the inspection of the vendor
concerning the software development
life cycle (SDLC) and the quality system
of the vendor. It also includes information
about software design and, in particular,
about software testing.
5. Logbook: Logbook should be established
to record all actions e.g. calibration,
cleaning, maintenance, change control
of all components of a computerized
system over the whole life cycle.
6. Source Code: The test facility should
have access to the source code of
application software. It is not necessary
to have it available at the test facility,
but the test facility should ensure that
the vendor of the software maintains the
source code for each version in a safe
place.
conclusion
Successful CSV is highly dependent
upon a quality management or quality
assurance system.CSV must establish
a “level of confidence” that the system
consistently meets all requirements and
user expectations. CSV is a critical activity
that should be pursued and formally
documented for all systems with regulatory
implications. CSV activities provide the
controlled testing conditions necessary
to ensure proactive identification and
resolution of operational and regulatory
issues. Above all, the system must be
shown to operate correctly, consistently,
and according to its specifications. Whilst
the concepts and principles behind
computer validation remain convincing
and relevant, it is clear that computer
validation practices need to be updated to
reflect modern computer technology and
development techniques.
“At the end of the day people make the
difference. Good people deliver not just
short term results but results that hold up
to scrutiny long-term too.”
Pharma Times - Vol. 44 - No. 02 - February 2012 29