Article
Computer System Validation: A Requisite
Approach for Laboratory
1Gaurav Tiwari*, 1Ruchi Tiwari, 1Kaushlesh Prasad and 1Awani K Rai
1Department of Pharmaceutical Sciences, Pranveer Singh Institute of Technology, Kanpur (UP).
*Email id: [email protected]
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
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 productionof 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.
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
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
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)
Software
21.CFR.211.68 (a), (b)
21.CFR.211.100
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)
Personnel qualification Consultants
Equipment design, size and location Equipment cleaning and maintenance
Automatic, mechanical and electronic equipment
Automatic, mechanical and electronic equipment
Written procedures: Deviation
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
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
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
Formal approved and documented procedures (Software)
Deviation report
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): Instal-lation qualification establishes that the computer system is received as designed
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
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. R e l a t e d d o c u m e n t s , e . g . , r i s k 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
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.”
