Cv 1

Computer Validation Fundamentals Training Manu

al

Computer Validation Training Series

Why do you need to be here?

● As you use or support regulated computer systems, you may impact their

validated state● This subject has been identified as a key concern by the highest levels of our

company● We are expected to validate and control our important computer systems in

accordance with GSK expectations● If important computer systems at your site operate poorly, it may reflect badly

on all of GSK and cause a loss of customer confidence worldwide

After this training you should be able to….

● Describe the background behind computer validation as it applies to GSK

● Understand why GSK views this topic as a key business, safety, and

regulatory benefit

● Recognise the GSK Computer Validation Life Cycle and its major activities

and deliverables

● Explain the items included in the Computer System Validation Checklist

● Know where to learn more about the GSK expectations for computer

validation

Introduction

● Computerisation is now dominating almost every aspect of our jobs at GSK

● Computer validation has rapidly become a critical issue in GSK and

throughout the rest of our industry

● Many of our employees may not be aware that they routinely impact the

validated state of computer systems

● Computer validation is mostly important for business and safety reasons

● However, many people first noticed computer validation because of

regulatory scrutiny

Process Validation Roots

● Process Validation began before Computer Validation

● Regulators and the drug companies have both been focused on Process

Validation for a long time

● Process Validation terminology (e.g. IQ,OQ,PQ) and mindset carried over to

Computer Validation

Is Computer Validation new?

● No, it has been required for over 20 years● For many years, it was usually overlooked during regulatory inspections● During the last 5 years, it has quickly increased in importance to the

regulators and drug companies● Many drug companies now see that there is high risk of severe punishment

from regulators for not doing it properly ● Everyone that uses, supports, buys, or develops regulated GSK computer

systems must understand how their actions impact the validated state of those systems

What is a Computer System?

In general, a combination of hardware, software, people, documents, inputs,

processing, and outputs working together

Inputs outputs

Software Hardware

Controlling SystemOperating Procedures &

Documentation

Equipment

Controlled process People and Training

What Computer Systems do you use?

● MRP/ERP system?

● LIMS system?

● Laboratory Instruments (e.g. Chromatography)?

● Automated manufacturing or packaging equipment?

● IT systems, including those supporting network and infrastructure?

● Spreadsheets or databases?

Applicability?

● Do you know how to identify whether a system you use requires validation?

● Global Quality Guideline 1401A is our tool to sort these out

● Do you know if the systems you sue have not been validated or were already

validated?

● Ask your local Computer Inspection Readiness representative or validation group.

Your systems should be listed on a local system register that includes the

validation status

Who plays a validation role?

● Users play a key validation role in:

─starting the process for new or existing systems

─performing some major steps (e.g. Requirements)

─writing and following operating procedure

─maintaining the validated state while in use

● Developers play a key role in many steps including:

─design, coding, testing, changes, support

● Support groups (IT, IR, SCS, Infrastructure):

─maintain proper network environment

─troubleshooting and maintenance

─desktop and infrastructure control

Who plays a validation role?

● QA and Validation

─author some major documents

─approve major documents that others write

─provide advice, training, auditing

● Senior management for each group decides:

─which systems to buy or build

─how much resource to make available

─what risks are acceptable

How can computers systems be better than people doing the same tasks?

● Computer systems that work properly...

● are faster than people

● make less mistakes than people

● do not need sleep (24 hour operation is possible)

● are less expensive than people (no salary)

How can computers systems be worse than people doing the same tasks?

● Computer systems that work improperly...

● cause people to lose time while they fix the errors

● make much more serous mistakes than people

● can stop all production or release or product

● are far more expensive than people

Why can defects in computer systems be worse than other equipment problems?

● When equipment breaks, there are typically obvious and immediate symptoms.

Catastrophic results can often be avoided

● Computer system defects can typically be very difficult to recognise and severe

problems may result without being detected until well after the problem started

● Drug companies, the airline industry, public utilities, nuclear power plants and

other industries where quality is critical have seen very expensive consequences

from improper computer system operation

● Many of these consequences cost far more than the cost of Computer Vlidation

What is Computer Validation?

● The ongoing process of establishing documented evidence which provides a

high degree of assurance that a system will consistently perform according to

its predetermined specifications and quality attributes

● ongoing...- starts at initial concept, does not stop until retired

● documented...- written testing

● predetermined...- must document what we want at the start

Is it difficult?

● It depends!

● If you begin the process at the start, when the computer system is first considered

for possible purchase or development, then it should be much easier

● Lack of understanding of computer validation will make it more difficult, take more

time, and result in more errors

Is it expensive?

● It depends! Where do you draw the line between good business practice and

required computer validation steps?

● Many of these required computer validation steps are considered good business

practice that many of us are taught during computer programming classes

● If you compare it to the price of not validating, then the price is typically very low

Why Validation?

● Business reasons

● Safety reasons

● Regulatory reasons

Cost to Fix

When Problem found Cost to correct

requirements

design

code

test

implement

How can defects in your computer systems

hurt the entire company?

● The world is now much smaller with the use of the internet and mass media

communications

● Defects in your computer systems that cause harm to public may be rapidly

communicated globally to all customers

● Customers may then assume that they could be harmed by using our products

made at any of our sites

● This can reflect poorly on global product sales and stock values

Would you allow this surgical computer system to be used on you?

The Regulatory Benefit?

● Regulatory agencies around the world are rapidly increasing their scrutiny of

computer systems─ In the first 5 months of 2001, there were 50% more computer validation findings than in all of 2000 (2nd highest category for From 483 observations)

● GSK has come very close to severe penalties by the FDA for poor computer validation

● Regulators have made it clear to us that they consider that problems at one site are an indication of conditions for the entire company

The GMP “Hook” to Computer SystemsFDA:21 CFR 211.68

● “ … equipment, including computers… that will perform a function satisfactorily…

can be used in manufacturing, processing, packaging an holding of a a drug

product.”

● Requires “ … written program designed to assure proper performance.”

● Requires “ appropriate controls shall be exercised over computer or related

systems…” input/output accuracy check, backup file of data that is exact and

complete

● Requires written record of the program to be along with “ appropriate” validation

data

The GMP “Hook” to Computer SystemsMCA: Annex 11

● “ Where a computerised system replaces a manual operation, there should be no

resultant decrease in product quality or quality assurance”

● “Where critical data are being entered manually … there should be additional

check of accuracy of the record… This check may be done by a second operator

or by validated electronic means”

● “Before a system using a computer is brought into use, it should be thoroughly

tested and confirmed as being capable of achieving the desired results”

There are also other regulatory agencies increasing attention on computer systems. These are just a few…

Regulatory Focus● We receive regular input on regulatory trends and expectations through many

sources including…

● Direct communication with the regulators

● Representation in industry groups (e.g. GAMP, ISPE, PDA)

● The FDA posts recent Warning Letters on their web site at

http://www.fda.gov/foi/warning.htm

● “GMP Trends” publishes excerpts from Form 483 observations semi-monthly

(http://www.gmptrends.com)

● Other magazines, web sites, industry conferences, and more

Summary of Benefits● Computer systems now serve in critical roles in every aspect or our business

● Because of the unique nature of computer systems, problems can be hard to

detect in advance, but catastrophic

● Poorly built systems can easily

─ halt production and product release

─ harm the public before we know of a defect

─ result in severe regulatory penalty

● We cannot afford to ignore the need for ensuring that quality is built into our

computer systems

Planning

Planning

Supplier Assessment

Requirements

Design and CodeDevelopment

Testing

Deployment

Use

Decommissioning

Cross-PhaseCross-PhaseActivitiesActivities(always)(always)

Phases of

Computer System Lifecycle

Phases of the LifecycleReference Global Quality Guideline 1205

●Planning●Supplier Assessment●Requirements●Design and Code●Development Testing●Deployment●Use●Decommissioning●Cross Phase-Activities

Planning Phase● Business Requirements

─high level, not product-specific

─can be used to make business case and select product

─required functions and constraints,

─enough detail to make compliance assessment

● Compliance Assessment - is system GxP-related?

● ERES Assessment - if GxP, assess based on GQG 1401A

● Validation Planning─defines standards to maintain quality during life of system

─key roles and responsibilities

─deliverables, rationale for approach

Supplier Assessment Phase

● Compare supplier’s validation activities/deliverables with ours

● Information used to determine activities needed by GSK where supplier is deficient

● Validation Plan should state whether supplier audit is needed and when it will be

done

User-Supplier Relationship

User RequirementsSpecification

FunctionalSpecification

OperationQualification

PerformanceQualification

DesignSpecification

InstallationQualification

Build System

Requirement Specification System Testing

Unit TestingDesignSpecification

Primary Responsibilityfor Specification

Primary Responsibilityfor Testing

User User

Supplier Supplier

Testing of the URS

Testing of the

Functional Specification

Testing of the

Design Specification

Mo

re U

se

r in

volv

em

en

t fo

r cu

sto

m

syst

em

s, le

ss f

or

pa

cka

ge

d

Mo

re S

up

pli

er

invo

lve

me

nt

for

cust

om

sy

ste

ms,

less

fo

r p

ack

ag

ed

Requirements Phase

● Business Requirements are further developed to make the User Requirements

Specifications (URS)

● URS details what the system should do, but not how

● Categorise level of importance- must, should, could

Computer System require more detailed specifications...

User Requirements SpecificationRequirements Phase

● Requirements traceable to Functional Specifications and testing

● Unambiguous, clear, concise

● Testable and measurable

● Typically written and approved by end-user

● Basis for system acceptance testing

● Should be approved before the design review

Functional SpecificationDesign and Code Phase

● The highest level design document responding directly to the User Requirements

Specification

● All system inputs, outputs, and interfaces

● All functions and performance requirements

● Error definition and handling

● Ranges, limits, defaults

● Safety considerations

Design SpecificationDesign and Code Phase

● Defines how the system should meet the requirements, including…

● Architecture AND interfaces

● All functions

● Data processing and integrity

● Security

● Backup, archive, and restoration

● disaster recovery

● Data definition

Design ReviewDesign and Code Phase

● Activity performed to verify that all deliverables from Requirements and Design

Phases are produced and…

● are clear and concise

● are complete, current, and traceable

● electronic record and signatures addressed

● are testable

● show system fit for purpose

Coding and ConfigurationDesign and Code Phase

● Design Review should be complete before starting

● Should be performed in accordance with written Programming Standards

● Programming Standards should define appropriate rules for writing source code

(e.g. dead code, structure, naming)

● Example of Dead Code:

Line 5: GOTO Line7;

Line 6: Add 5 to all input variables;

Line 7: Add 3 to all input variables;

For this example, it should not possible for Line 6 t execute during actual system

operation

Code and Configuration ReviewDesign and Code Phase

● Should be completed before formal testing

● Verify code complies with Programming Standards

● Check to ensure all pre-defined system specifications are addressed

● Check for coding errors

Development Testing Phase

Testing at Multiple LevelsDevelopment Testing Phase

‘White Box’ *

● Unit Testing/Structural Testing

● Low level ‘Black

Box’ *

● System & Acceptance testing

● Functional Testing

● Higher level

* -Unofficial term used for explanation of concept

in

in

out

out

Manual Calculation

Test PlanDevelopment Testing Phase

● Define and justify the how the system will be tested and how much

● Address how tests are traceable to specifications

● Testing approach should address

—normal operation

—entire design range, boundaries, stress

—failure modes, including power failure

● Should be approved before testing starts

Test CaseDevelopment Testing Phase

●Lists the test objective

●Traceable to specifications

●Lists test pre-requisites

●Reproducible test steps

●Clear acceptance criteria

Test ResultsDevelopment Testing Phase

● Record all raw data and derived results

● Ticks, ‘ok’, ‘yes/no’, ‘Pass/Fail’ or similar are not valid results

● Record a ‘Pass/Fail’ conclusion of whether results met acceptance criteria

● Signature and date of test performer

● Signature and date of test result approver

● References to incident log for failures

Test ReportDevelopment Testing Phase

● Used to…

═collate test result documentation

═conclude each phase of testing

═authorise subsequent testing phases

● Summarises the testing outcome, addresses test failures

Deployment Phase

● Data Load

● Operational and Support Plans (e.g. SOP, training, service contracts, security,

support processes)

● Installation Qualification (IQ) - verifies installed in accordance with specifications

and diagnostics checks performed

Deployment Phase

● Operational Qualification (OQ) -user acceptance testing of base functionality

under normal and stress conditions

● System Release - can use in live environment before PQ

● Performance Qualification (PQ) - verify OK while in actual use

● Validation Report - summarise all activities, address deviations, provide

conclusion

Use Phase

● Implementation of Operational and Support Plans

● Dial-in Support Services - be very careful if you allow this

● Upgrades and fixes - manage through change control

● Periodic Reviews - verify still in a validated state

● Revalidation as required

Archive and Decommission Phase

● Occurs at end of system life

● Store records to ensure compliance with rules for electronic records and record

retention

Cross Phase Activities

●Requirements Traceability

●Change Control

●Configuration Management

●Incident Management

●Documentation Management

●Training

Validation Planning

● “ A documented plan exists for validation this system”

● Sample Regulatory Observation

No original planning documents included in the validation

materials for the programs

● “ This plan includes the deliverables and activities that were to result from the

validation effort”

● Sample Regulatory Observation

‘The procedure calls for the same individual who writes/revises the

program to validate the program’

● “The supplier of this system has been audited (report available)”

● “ A system description or overview is available”

Functional Requirements(document in the User Requirements Specification)

● “ Functional Requirements (or equivalent named document) exist for this system”

● “The Functional Requirements identifies all functions that the system must

perform”

● “The Functional Requirements are approved using a signature”

● “The Functional Requirements are updated for each system functional change”

● “The Functional Requirements include enough detail to allow objective test

measurement”

● Sample Regulatory Observation

‘The procedure discusses discrepancies in decimal places between the

computer and manual results and …” significant values”. There is no

definition of “significant values”’

Functional Requirements(document in the User Requirements Specification)

● “ Either the Functional Requirements or Design Specifications provide a system

overview”

● “Function Requirement are traceable to corresponding design elements”

● “ Function Requirement are traceable to corresponding test elements”

Summary/Release Documentation● “ The system was not released prior to completion of the activities defined in the

validation plan”

● “ Version numbers are used to identify each component of the computer system

installed for use and it’s current supportive documentation”

● Sample Regulatory Observation

‘Inadequate software version control’

● “ All required approval signatures were obtained prior to release of the system”

● Sample Regulatory Observation

‘Inconsistencies in the review of the validation documents’

● “A summary of the validation documents and activities for this computer system is

available”

● “ The system was released into production in accordance with a SOP”

● Sample Regulatory Observation

‘There were no written requirements/specifiactions and validation protocol

SOP at the time of validation’

System Maintenance and Operation

● “ Change were tested prior to placing the change into production use”

● “ Enhancements and modifications to computerised systems and associated

documentation re implemented under change control and configuration

management that maintains version history of computer components”

● “ Changes were approved prior to placing the change into production use”

● Sample Regulatory Observation

‘Inconsistencies in the review of the validation documents’

● “ The site’s change control documentation fully describes proposed or actual

changes”

● “There is a SOP defining how users are to interact with the system to perform their

jobs”

System Maintenance and Operation● “ All system users have been trained on the system operation SOP”

● “The need for possible regression testing was addressed in the change control

documentation”

● “ There is a written Disaster Recovery Plan that will restore operation of this

system”

● “ Documented testing of the Disaster Recovery Plan has been performed”

● “ Changes have a documented evaluation of whether a complete system re-

validation is warranted”

● “ The site can provide a list of authorised users and their security access profile”

● “ There is evidence that access is terminated for transferred or terminated

employees”

● “ There is a documented process and criteria to revoke system access”

Electronic Records/Electronic Signatures

(ERES)

● “A written ER/ES compliance assessment, suitable for presentation to an

investigator, is available for this system”

● “ The application has an automatic, electronic audit trail to record changes to

electronic records”

● “ Authorised deletions of electronic records are only performed with an appropriate

audit trail”

● This completes the Computer System Validation Self Inspection Checklist, but

there are many other critical computer validation points on the other Self

Inspection Checklists that are not specific to individual systems

What about Legacy System?

● Your site may have systems that are not validated or that don’t meet today’s

regulatory expectations

● These systems must be validated to comply with GSK policy on computer

validation (Global Quality Policy 1205)

● GQP 1205 does not allow retrospective validation as an acceptable substitute for

prospective validation

● For systems that are in use without validation, retrospective validation should be

done as a prospective

Scalability

● Many deliverables in the computer validation life cycle may be combined into the

same document or made smaller

● This scalability is dependent on the size, complexity, intended use, and risks

associated with the computer system

● However, some deliverables cannot be combined because of their intended role

and timing in the life cycle

● For example, Business Requirements can often be combined with the User

Requirements Specification, but Requirements and Testing cannot be combined

Can this be done more than one way?

● Yes!

● GQG 1205 describes how several key areas of intended use for computer

systems may be validated differently═Laboratory systems

═Control systems

═Desktop applications

═IT systems

═IT infrastructure

═Software tools

Should this always be done the same way?

● No!

● You probably don’t have the resource to use a “one-size-fits-all” approach to

computer validation

● Regulatory agencies have made it clear that they do not insist on a “one-size -fits-

all” approach

● Attempting to validate spreadsheets using the same method as for a MRP system

may be wasting resource that could be better applied to fixing compliance gaps

Is this a one-time effort?

● Validation does not end when a system is put into use

● When systems are changed, the validation deliverables may need to be updated

● As your site’s priorities and resources change, more work may be required to

improve the compliance of system

● As regulatory expectations for computer validation change, more validation

activities are required

● Significant resource is always needed on permanent basis to maintain the

validated state of systems already in use

Popular Misconceptions?

● “ We bought it from a vendor…” so we can get by with very little for validation

● The vendor supplies a validation package - that’s all we need

● “ Validation can be done at the end - just be fore turnover

● The Validation Department approved it - there shouldn’t be any bugs

● Computer Validation is slowing down this project

● We can’t afford to perform Computer Validation

● The Regulatory Agencies will not look at our Computer Validation

● Testing is Validation

What does success look like?

● Many of our manufacturing sites have not yet experienced a computer system

inspection, but will soon

● Without having first-hand knowledge of what it takes to succeed during a computer

system inspection, many sites need help

● Global Computer Validation can help by providing training, coaching, consultation,

and examples

Challenges

● Staff that are not trained or experienced in performing computer validation and

don’t know what they don’t know

● Lack of resource-people, time, money

● Resources are not always allocated based on a complete understanding of the

challenges faced in achieving compliance in computer validation

● Specific regulatory expectations can be hard to define, since much of them are not

written directly into regulations

What should we target first?

● We must comply with commitments made by GSK to the regulators

● We must avoid deficiencies that have repeatedly been the source of citations to

GSK and other pharmaceutical companies

● These are all defined in the Computer Inspection Readiness Self Inspection

Checklists

● We must also follow all of Gsk policy, but start with these checklists

Priorities

● Computer validation is only one of many high priorities that your site or group

faces

● Your site or group is responsible for determining the proper balance of resource

and risk for each of these challenges

● The Computer Inspection Readiness (CIR) Training outlines the prioritisation

strategies that you should use for addressing your computer systems

● The CIR Self Inspection Checklists indicate numerical weighting of many relevant

topics

Risk Management

● Management staff for your site or group will decide their tolerance level for risk in

each major category of issues

● Poor computer validation can be very expensive. These risks are business, safety,

and regulatory related

● This guideline is called “ Computerised Systems - Management of Risk to Product

Quality and the Application of Interim Measures”

Quick Wins

● Improving the “perception of control” of your computer systems can reduce your

regulatory risk somewhat without adding resource

● Strategies for increasing this perception of control are described in the Computer

Inspection Readiness Training, offered by Global Computer Validation

● Interim measures can be applied for short-term mitigation of risk (e.g. procedural,

administrative workarounds)

● Incremental improvement starting with the most critical computer systems (MRP,

LIMS,CDS, Process Control) is recommended

Planning

Quick Review of the Big Picture

Supplier Assessment

Requirements

Design and CodeDevelopment

Testing

Deployment

Use

Decommissioning

Cross-PhaseCross-PhaseActivitiesActivities(always)(always)

Phases of

Computer System Lifecycle

Summary

● Computer validation has become very high visibility in our industry and at GSK● There is very real business and safety benefit, in addition to concerns with

regulatory agencies● GSK has a guideline that clearly describes the entire computer validation life cycle

and GSK expectations● The Computer System Self Inspection Checklists, published on the web, give

excellent focus to the most critical issues

Finale