computer system validation

1. Computer Validation Training Series
Computer Validation
Fundamentals Training
Manual

2. 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

3. 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

4. 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

5. 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

6. 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

7. What is a Computer System?
In general, a combination of hardware, software, people, documents, inputs,
processing, and outputs working together
Inputs outputs
Software Hardware Equipment
Operating Procedures &
Controlling System Documentation
Controlled process People and Training

8. 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?

9. 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

10. 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

11. 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

12. 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)

13. 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

14. 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

15. 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

16. 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

17. 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

18. Why Validation?
● Business reasons
● Safety reasons
● Regulatory reasons

19. Cost to Fix
When
Problem found Cost to correct
requirements
design
code
test
implement

20. 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

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

22. 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

23. The GMP “Hook” to Computer Systems
FDA: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

24. The GMP “Hook” to Computer Systems
MCA: 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”

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

26. 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

27. 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

28. Planning
Planning
Decommissioning
Supplier Assessment
Phases of
Use
Computer System Requirements
Lifecycle
Deployment
Developmen Design and Code
t
Cross-Phase Testing
Activities
(always)

29. Phases of the Lifecycle
Reference Global Quality Guideline 1205
●Planning
●Supplier Assessment
●Requirements
●Design and Code
●Development Testing
●Deployment
●Use
●Decommissioning
●Cross Phase-Activities

30. 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

31. 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

32. User-Supplier Relationship
Primary Responsibility Primary Responsibility
for Specification for Testing
Testing of the URS
User User Requirements Performance
Specification Qualification User
More Supplier involvement for custom
More User involvement for custom
Functional Testing of the Operation
systems, less for packaged
systems, less for packaged
Specification Functional Specification Qualification
Testing of the
Design Installation
Specification Qualification
Design Specification
Build System
Design Unit Testing
Specification Supplier
Supplier
Requirement Specification System Testing

33. 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

34. Computer System require more detailed specifications...

35. User Requirements Specification
Requirements 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

36. Functional Specification
Design 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

37. Design Specification
Design 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

38. Design Review
Design 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

39. Coding and Configuration
Design 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

40. Code and Configuration Review
Design 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

41. Development Testing Phase

42. Testing at Multiple Levels
Development Testing Phase
‘White Box’ *
● Unit Testing/Structural Testing
out
● Low level in
‘Black Box’ *
● System & Acceptance testing
● Functional Testing
● Higher level
in out
Manual Calculation
* -Unofficial term used for explanation of concept

43. Test Plan
Development 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

44. Test Case
Development Testing Phase
●Lists the test objective
●Traceable to specifications
●Lists test pre-requisites
●Reproducible test steps
●Clear acceptance criteria

45. Test Results
Development 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

46. Test Report
Development Testing Phase
● Used to…
═collate test result documentation
═conclude each phase of testing
═authorise subsequent testing phases
● Summarises the testing outcome, addresses test failures

47. 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

48. 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

49. 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

50. Archive and Decommission Phase
● Occurs at end of system life
● Store records to ensure compliance with rules for electronic records and record
retention

51. Cross Phase Activities
●Requirements Traceability
●Change Control
●Configuration Management
●Incident Management
●Documentation Management
●Training

52. 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”

53. 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”’

54. 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”

55. 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’

56. 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”

57. 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”

58. 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

59. 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

60. 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

61. 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

62. 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

63. 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

64. 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

65. 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

66. 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

67. 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

68. 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

69. 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”

70. 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

71. Quick Review of the Big Picture
Planning
Decommissioning
Supplier Assessment
Phases of
Use
Computer System
Lifecycle Requirements
Deployment
Developmen Design and Code
t
Cross-Phase Testing
Activities
(always)

72. 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