International Symposium of Laboratory

Automation and Robotics (ISLAR) Presentation

Computer Related System Validation

The Ashvins Group, Inc.

6161 Blue Lagoon Dr
Suite 340
Miami, FL 33126
1-877-ASHVINS
www.ashvinsgroup.com

ABSTRACT
This presentation summarizes approaches for project leaders in the
pharmaceutical, biotech, drug discovery and clinical fields who must validate
software used to automate laboratory research procedures, consolidate data
collection and analysis and/or run sophisticated QC or manufacturing operations.
The goal of this presentation is to outline general validation principles and quality
system regulations (QSRs) that build a framework to establish a comprehensive
approach to software validation. Validation technology may be addressed through
a variety of formats such as:
Installation Qualification/Operational Qualification (IQ/OQ)
Validation and Verification (V&V)
Computer Related Systems Validation (CRSV)
Several approaches to software validation exist and may be appropriate for the
specific project. The scope of any validation effort depends upon a number of
factors, including the size and complexity of the software, the origin of the
software (custom vs. off-the-shelf) and whether the functions are critical or noncritical in nature. By effectively planning the process, validation time and
resources can be reduced while meeting regulatory requirements.

INTRODUCTION
In recent years there has been a significant increase in the use of
computer-related systems in the Life Sciences industries. Its clear that
these systems must satisfy cGMP requirements, but legitimate questions
have been raised concerning the scope and methods which should be
employed in validations.
A. It is the responsibility of the end-user to assure that systems used
are in compliance with applicable regulations; however, many
users rely too heavily upon vendor-supplied information and test
data to support their system validation.
B. The extent of testing and the type of documentation required to
support validation is unclear, and it is difficult to delineate vendor
and user responsibilities when validating vendor-supplied
systems.
C. Validation of computer-related systems is often complex, and any
number of alternate approaches can be utilized.

Computer Related System Validation

Defining CRSV can be modeled after the FDAs

definition of Process Validation :
Establishing documented evidence which provides a high
degree of assurance that a specific computer-related
system will consistently produce a product meeting its
pre-determined specifications and quality attributes.

Computer Related System

Validation Lifecycle
New Computer System

Existing Computer System

Def inesy st em
Funct ion Struct ure

D ef ine Sof t ware

D ef inesy st em
Function St ructure

D esign/ Specif y
hardware
Qualif y Sy st em

Dev elop
Sof tware

I nstall hardware

R ev iew operat ing

experience

Verif y Sof t ware

Qualif y hardware

Test I ndiv idual

Modules (C omput er
Sy st em)

D at a

I nt egrat e
C omputerizedSy st em

D at aanaly s is

Test Integrat ed
modules
(C omput erized
Sy st em)

Validation
Accept anc e

D emons trat et otal

s y st em operation
(Comput er-Relat ed
Sy st em)

Ongoingsy st em ev aluat ion

Change

C onduct sy st em
test ing (if needed)

FileD ocumentation

Computer Related System Validation

System Concepts
A computer-related system (CRS) is a computerized system
performing its intended function in its operating environment.
A. A CRS can not be validated unless the process it is executing
can be validated.
B. Applicable Quality Regulations include:
cGMPs/GLPs/GAMP
CFR Part 820 and Part 11
Systems requiring validation include all systems directly or indirectly
related to the regulatory process:
A.
B.
C.
D.
E.
F.
G.

Medical Devices with computer components

Decision-support/decision-making systems
Inventory systems
Lab systems including lab automation
Data management and reporting systems
Testing systems
Statistical analysis systems

Computer Related System Validation

System Concepts
Computer Related System Boundary

OPERATING
PROCEDURES

SOFTWARE

HARDWARE

EQUIPMENT
(OPTIONAL)

COMPUTER SYSTEM

CONTROLLED FUNCTION

COMPUTERIZED SYSTEM

OPERATING ENVIRONMENT

Build the Validation Team

The Validation Team incorporates multi-functional participation and
depending on the complexity of the validation effort may include:
A.
B.
C.
D.
E.
F.

Management Information Systems

Developers
Vendors
Consultants
Software QA
Executive Management

The Validation Team is responsible for defining, planning, assessing

risk, evaluating intended use, executing, documenting, reviewing and
approving the validation efforts.
The Validation Team should have a combination of skill sets for
effective results. This will include individuals who are experienced with
regulations, validation approaches, systems, processes and intended
uses associated with the validation effort.

Documentation:

Write It Down

The level of documentation required depends on the complexity

and intended use of the system; and also on the origin of the
software/system (vendor supplied or developed internally).
Examples of documentation required to support validation:
A.
B.
C.
D.
E.
F.
G.
H.
I.
J.
K.
L.
M.
N.

Validation SOPs and Policies

Project Management Plan
Validation Plan
Risk (Hazard) Management Plan
Configuration Management Plan
Change Management Plan
System Test Plans
Computer-Related System Requirements Specification
Computerized System Design Specification and Documents
Traceability Analysis
System Topology and Installation Summaries
Validation Protocols / Test Case Procedures
IQ/OQ/PQ Reports
Validation Reports

Validation Approach:

8 Step Model

1. PLAN
Validation Activities

4. DESIGN
5. CONSTRUCT

2. DEFINE

6. INTEGRATE/INSTALL

Requirements

7. QUALIFY
8. EVALUATE

3. SELECT
Vendors

Computerized System

STEP 1 :

Plan Validation Activities

Each organization should have written and approved validation

policies.
policies
There should be specific SOPs for the validation of Computer Related
Systems. Protocols should be developed, test data reviewed and
summary reports written in accordance with established procedures that
assure the validation objectives are met.
A Validation Project Plan is used to identify the systems to be included,
procedures to be followed and the timeline for a specific validation
project. This step also helps project resources and budget
requirements.
A Validation Project Plan can be written for a single system, a
combination of systems that support an associated process or an entire
facility. An important purpose of the Validation Plan is to establish
specific responsibilities and expectations for each validation activity.

STEP 2 :

Define Computer-Related System

Requirements

The first task for the internal Validation Team is to create a

document that summarizes the high level goals of the CRS.

The document specifies what at a high level should be

accomplished by the CRS. In order to define requirements,
requirements the
Validation Team reviews available documentation, conducts
interviews with users and maps existing processes.

The initial overview should concentrate on functionality,

operational and performance parameters, and overall objectives
for the validation effort.

Each requirement written should be described with sufficient

detail to support testing that requirement and defining
acceptance criteria. Testing protocols should be traced back to
each requirement (via a Traceability Matrix) in order to document
the comprehensiveness of the protocols.

STEP 3 :

Select Computerized System Vendors

The term vendor may apply to an internal development group as well

as an outside company. Whether the vendor is an outside company or
an internal department, the vendors ability to provide a system which
can be validated should be a primary consideration.

A suitable vendor must be technically competent and qualified to supply

and support the proposed system. Knowledge of validation
requirements and experience in providing systems for cGMP
applications are important selection criteria.

The importance of selection criteria for computerized systems

depends upon the type of software and hardware being evaluated.
A. For off-the-shelf software and standard hardware components,
such as operating systems and computing platform, the history
of customer satisfaction is of major importance.
B. For custom developed systems, primary importance should be
placed on evaluating the vendors Quality Assurance System.

STEP 4 :

Design Computerized System

A Computerized System Design Specification is a document or a

collection of documents that describes clearly and completely how
the computerized system will operate and satisfy the ComputerRelated System Requirements Specification.
A.
B.

C.
D.

The Design Specification can not be developed until the

vendors and the specific hardware and software have been
selected.
The Design Specification applies to both the computer
system and the controlled function/process, and should
contain all of the information required to describe both
normal and abnormal operating conditions.
The Design Specifications should be a joint responsibility of
the vendor and user.
It is important that the Design Specifications contain detailed
information about the interfaces between the computerized
system and its operating environment.

STEP 5 :

Construct Computerized System

The computerized system may be constructed by developing custom

software and hardware for the application - or purchasing established
products - or a combination of both.
A. From a validation perspective, custom developed software and
hardware require the greatest amount of testing since they have
never been proven effective.
B. Three categories of software can be defined:
1) System software
2) Configurable software
3) Application specific software
These categories are not intended to be rigid but they allow
distinctions to be made so that validation approaches are
appropriate.
C. Defined processes, assigned responsibilities, planned audits,
structured reviews and management controls, collectively promote
an environment to efficiently manage product quality.

STEP 6 :

Integrate and Install Computerized

System

Proper integration, installation and commissioning of a computerized

system is essential to the successful qualification of the system.
A packaged system may be integrated at the vendors site; more
complex systems will be integrated at the users site.
Procedures employed in the project should be specified in the
Validation Plan.
Responsibility for all tasks (including vendors) should be specified in
the Validation Plan.
Installation Qualification (IQ) will demonstrate proper installation of
hardware and software.

STEP 7 :

Qualify Computerized System (IQ/OQ)

Qualification is a procedure of testing and collecting data to provide a

high level of assurance that a computerized system operates in
accordance with the system specification. Protocols are written and
approved in advance and should specify the following:
A. Goals of testing
B. Test methods
C. Acceptance criteria
D. Who is responsible for testing
IQ (Installation Qualification) verifies that all aspects of installing
hardware and software meet specifications and that user manuals,
SOPs and backup procedures are in place.
OQ (Operational Qualification) verifies that the system operates
throughout its anticipated ranges according to its specifications and
identifies all important parameters.

STEP 8 :

Evaluate Computerized System in Its

Operating Environment (PQ)

PQ (Performance Qualification) verifies that a system performs

its intended function in accordance with its specifications. Testing
is completed on the entire system while operating in its normal
environment.
In order to assure that the system remains in a validated state,
Performance Monitoring is required to continually test a systems
performance in executing defined processes:
A.
B.
C.
D.

Periodic calibration and maintenance

Continuous monitoring of critical parameters
Confirmation of security measures
Provisions for contingency planning, disaster recovery
and personnel training

Change Control procedures must be established to keep a CRS

in a validated state during planned and unplanned changes.

SUMMARY
Build a framework to establish a comprehensive approach to
software validation in the following applications:
Automating laboratory procedures
Data collection and analysis
QC & Manufacturing operations

Validation techniques accomplished via:

IQ/OQ/PQ
Verification & Validation
CRSV

Scope of validation effort depends on:

Size and complexity of the software
Origin of the software (custom or OTS)
Criticality of the software function

Validation is specific to the intended use of the CRS.

Adequate preparation will reduce validation time / resources and
assure regulatory requirements are addressed.