Computer system overview

PRIVILEDGED AND CONFIDENTIAL
COMPUTER SYSTEM OVERVIEW
1 of 41

2 of 41
COMPUTER SYSTEM VALIDATION
 A computer system consists of hardware components that have been carefully chosen
so that they work well together and software components or programs that run in
the computer.
 A computerized system consists of the hardware, software, and network components,
together with the controlled functions and associated documentation
 In recent years there has been an increasing trend to integrate electronic record and
business management systems across all operational areas. In the future it is expected
that our reliance on computer systems will continue to grow, rather than diminish. The
use of validated, effective, GxP controlled computerised systems should provide
enhancements in the quality assurance of regulated materials/products and associated
data/information management. The extent of the validation effort and control
arrangements should not be underestimated and a harmonised approach by industry and
regulators is beneficial.
 Types of computer system in Pharma industry:-

2 of 41

2 of 41
 Categories of Software :-
Category 1 – Infrastructure Software:
Infrastructure elements link together to form an integrated environment for running
and supporting applications and services.
There are two types of software in this category:
Established or commercially available2 layered software: Applications are
developed to run under the control of this kind of software. This includes operating
systems, database managers, programming languages, middleware, ladder logic
interpreters, statistical programming tools, and spreadsheet packages (but not
applications developed using these packages
Infrastructure software tools: This includes such tools as network monitoring
software, batch job scheduling tools, security software, anti-virus, and configuration
management tools.
Risk assessment should, however, be carried out on tools with potential high impact,
such as for password management or security management, to determine whether
additional controls are appropriate.

2 of 41
 Category 3- Non Configured Products
This category includes off-the-shelf products used for business purposes(Short for
commercial off-the-shelf, an adjective that describes software or hardware products that
are ready-made and available for sale to the general public. For example, Microsoft Office
is a COTS product that is a packaged software solution for businesses.). It includes both
systems that cannot be configured to conform to business processes and systems that are
configurable but for which only the default configuration is used. In both cases,
configuration to run in the user’s environment is possible and likely (e.g., for printer
setup). Judgment based on risk and complexity should determine whether systems used
with default configuration only are treated as a Category 3 or Category 4.
Supplier assessment may not be necessary. The need for, and extent of, supplier
assessment should be based on risk. User requirements are necessary and should focus
on key aspects of use.

2 of 41
 Category 3- Non Configured Products
Functional and design specifications are not expected from the user, although there
should be sufficient specification to enable testing (typically covered by the User
Requirements Specifications (URS) and other relevant documentation). Verification
typically consists of a single test phase.
All changes to software should be controlled, including supplier-provided patches.
Standard Operating Procedures
(SOPs) should be established for system use and management, and training plans
implemented.
Configuration management should be applied. For systems where the default
configuration is used, configuration management demonstrates that the defaults are
accurately selected.
Category 4 – Configured Products
Configurable software products provide standard interfaces and functions that enable
configuration of user specific business processes.

2 of 41
Configurable software products provide standard interfaces and functions that enable
configuration of user specific business processes. This typically involves configuring
predefined software modules. Much of the risk associated with the software is dependent
upon how well the system is configured to meet the needs of user business processes.
There may be some increased risk associated with new software and recent major
upgrades.
While Functional Specifications (FSs) may not be owned by the user, there should be
adequate specification available to ensure traceability and adequate test coverage.
Verification should ensure that the software product meets the user requirements with
particular focus on the configured business process. Custom modules should be handled as
Category 5 components.
The approach should address the layers of software involved and their respective
categories. The approach should reflect the outcome of the supplier assessment, GxP risk,
size, and complexity. It should define strategies for the mitigation of any weaknesses
identified in the supplier’s development process.

2 of 41
Custom software components such as macros developed with internal scripting language,
written or modified to satisfy specific user business requirements, should be treated as
Category 5.
In the absence of an adequate supplier Quality Management System (QMS), suppliers should
be encouraged to develop such a QMS based on the principles in this Guide. Under such
circumstances the software should be considered as Category 5. Regulated companies are,
however, responsible for ensuring the quality of the software and hardware, and the fitness
for purpose of the computerized system when used in the GxP environment.
Category 5 – Custom Applications:-
These systems or subsystems are developed to meet the specific needs of the regulated
company. The risk inherent with custom software is high. The life cycle approach and scaling
decisions should take into account this increased risk, because there is no user experience or
system reliability information available.
Main Body. The approach to supplier assessment should be risk-based and documented. A
Supplier Audit is usually required to confirm that an appropriate QMS is established to
control development and ongoing support of the application. In the absence of an adequate

2 of 41
Category 5 – Custom Applications:-
QMS, suppliers may use this Guide to provide the foundation for managing application
development and support. The approach should address the layers of software involved and
their respective categories. It should reflect the assessment of the supplier and any audit
observations, GxP risk, size, and complexity. It should define strategies for the mitigation of
any weaknesses identified in the supplier’s development process.
The validation documentation should cover all the steps of the life-cycle with appropriate
methods for measurement and reporting, (e.g. assessment reports and details of quality and
test measures), as required. Regulated users should be able to justify and defend their
standards, protocols, acceptance criteria, procedures and records in the light of their own
documented risk and complexity assessments, aimed at ensuring fitness for purpose and
regulatory compliance.

2 of 41
 Computerised systems may simplistically be considered to exist as three main
application types, i.e.: process control systems, data processing systems,
(including data collection/capture) and data record/ storage systems. There may
be links between these three types of system, described as ‘interfaces’. For
critical systems, user’s specifications, reports, data, acceptance criteria and
other documentation for various phases of the project. The regulated user
should be able to demonstrate through the validation evidence that they have a
high level of confidence in the integrity of both the processes executed within
the controlling computer system and in those processes controlled by the
computer system within the prescribed operating environment.

2 of 41
Regulatory and industry developments focus attention on patient safety, product
quality, data integrity and
• Avoid duplication of activities (e.g., by fully integrating engineering and computer
system activities so that they are only performed once)
• Leverage supplier activities to the maximum possible extent, while still ensuring
fitness for intended use
• Scale all life cycle activities and associated documentation according to risk,
complexity, and novelty
• Recognize that most computerized systems are now based on configurable
packages, many of them networked
• Acknowledge that traditional linear or waterfall development models are not the
most appropriate in all cases.
It would be expected that the regulated user’s Validation Policy or Validation
Master Plan (VMP) should identify the company’s approach to validation and its
overall philosophy with respect to computerised systems. The VMP should: Identify
which computerised systems are subject to validation.

2 of 41
The validation documentation should cover all the steps of the life-cycle with
appropriate methods for measurement and reporting, (e.g. assessment reports
and details of quality and test measures), as required. Regulated users should
be able to justify and defend their standards, protocols, acceptance criteria,
procedures and records in the light of their own documented risk and
complexity assessments, aimed at ensuring fitness for purpose and regulatory
compliance.
A formal, extensive review of the history of the Supply Company and the
software package may be an option to consider where an additional degree of
assurance of the reliability of the software is needed. This should be
documented in a Supplier Audit Report. Prospective purchasers should consider
any known limitations and problems for particular software packages or
versions and the adequacy of any corrective actions by the Supplier.
Appropriate, comprehensive documented customer acceptance testing should
support the final selection of the software package.

2 of 41
Errors often come to light after implementation and it is important for
the Supplier to advise/assist the Customer concerning any problems
and modifications to resolve errors. For so called ‘standard software
packages’ and COTS (as referenced in the GAMP guide and commercial
literature), it is important that purchasers are vigilant in maintaining
reliable systems.
The business/GxP criticality and risks relating to the application will
determine the nature and extent of any assessment of suppliers and
software products. GAMP Forum and PDA have provided advice and
guidance in the GxP field on these matters

2 of 41
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.
The following aspects will be covered: a. hardware b. operating system
c. network system d. data base management system e. system software
f. strategy g. compliance h. project plan i. system life cycle j. change
control Apart from the above-mentioned subjects, supporting activities
as training of personnel, documentation and use of checklists will be
covered. Attention will be given to the aspect of risk-analysis in relation
to validation of computerised systems.

2 of 41
The depth and scope of validation depend on the criticality of the computerised
functionality. This has to be established by means of a risk analysis at an early stage of
the validation process. Compliance critical key points to be considered include: • Proven
fit for purpose • Access control /user management. • Data integrity including:
prevention of deletion, poor transcriptions and omission. • Authorised / unauthorised
changes to data and documents • Critical Alarms handling (Process) • Audit trails •
Disaster recovery / Back up and retrieval • System maintenance and change control •
Training Evidence of sufficient control of these issues should be demonstrated in the
validation documentation. This compliance must be integrated using the system life cycle
approach (SLC), and clearly identified in the user requirements phase for any new
computerised systems as detailed in chapter 0. For existing systems, for which a life cycle
model was not applied, a gap analysis must be undertaken against cGMP compliance
issues. Identified issues must be tested and documented following a formal qualification
plan/report. For any identified non-conformances, the following alternatives should be
considered: • upgrading • ensuring the requested control level through additional
procedure (s) if the upgrading is not feasible • replacing/upgrading the system where
gaps are substantial and cannot be covered by the previous measures

The System Life Cycle concept describes all aspects of the life cycle of a
computerised system that could consist of: • planning; • specification • design •
construction • testing • implementation and acceptance • ongoing operation; •
archiving of the system when replaced.
2 of 41

VALIDATION STARTUP:
2 of 41

2 of 41
Activities / output
Business need
(Main) system requirements
Results feasibility study
Project Plan
Validation plan
User Requirements Specification (URS)
Acceptance criteria
Risk analysis report
Acceptance test plan (IQ/OQ/(PQ)
Request for proposal
Supplier review/audit report
Contract with supplier; with contractual requirements
Acquisition order

2 of 41
Activities / output
Supplier review/audit report
Contract with supplier; with contractual
requirements
Acquisition order
Functional specification
System design specification
DQ report (can be included in the URS
traceability matrix)
Software; module test report
Supplier audit report on system
development

2 of 41
Activities / output
Functional specification
System design specification
DQ report (can be included in the URS
traceability matrix)
Software; module test report
Supplier audit report on system
development
System description (including
hard/software diagrams)
System installation procedure
Manuals and user guides

2 of 41
Activities / output
IQ report (FAT, SAT can be included)
OQ report (FAT, SAT can be included)
Internal Audit/review report
Final approved (IQ/OQ reports1
Implementation plan
PQ report
Procedures
Training record
Validation report

41 of 41
THANK YOU

Computer system overview

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Computer system overview

Similar to Computer system overview (20)

Recently uploaded

Recently uploaded (20)

Computer system overview