This document provides an introduction to computerized system validation. It discusses the importance of validating computerized systems used in quality and testing laboratories to ensure accurate and reliable results. The document outlines some of the key regulatory requirements for computerized system validation from international regulations like EU GMP and US CFR Part 11. It also discusses the difference between qualification and validation activities and explains the various stages of the computerized system validation life cycle from creating specifications and risk assessments to testing, documenting results and ensuring ongoing compliance.

1. ©2015 Waters Corporation 1
Introduction to Computerized System
Validation
Charlie Wakeham
ISPE Philippines Conference April 2015

2. ©2015 Waters Corporation 2
Use of Computerized Systems
 Computerized systems:
– Are widely used in quality and testing laboratories
– Offer faster data processing and analysis
– Return more repeatable results
 However, they also:
– Can be used to falsify data
– Can function incorrectly, depending on the quality of the system
– Can lose large amounts of data in the event of a crash
 They are just one component of the interaction between people,
processes, instruments and environment that can affect quality-
critical product decisions.

3. ©2015 Waters Corporation 3
Data Integrity for an analysis result
When
What
Why
Who Collected
Who Processed
Any Changes
Who Reviewed
Who Approved
Unique
Result
Original
Instrument Method
LC/GC System Used
Calibration / Suitability
Product Code/
Stage Reagent
LIMS ID
Unchanged
Raw Data
File
Original
Processing Method
Standards used
for Calibration
Sample
Sets
Calibration
Curves
Validation Deliverables
Training Records
SOPs

4. ©2015 Waters Corporation 4
And still more!
 Before:
– Sample preparation methods
– Method validation
 After
– Review the audit trails… actively look for any repeat testing /
reprocessing / manual integration
– Raw data and reports must be available throughout the retention
period
o Backup the data
o Test the backup
o Check it will restore when needed
 Periodic Review

5. ©2015 Waters Corporation 5
Regulatory Drivers

6. ©2015 Waters Corporation 6
International Requirements for Pharma
 Annex 11 - EU GMP and PIC/S
– The application should be validated.
– Where a computerised system replaces a manual operation, there
should be no resultant decrease in product quality, process control or
quality assurance. There should be no increase in the overall risk of
the process.
 US Code of Federal Regulations 21 CFR Part 11, §11.10 (a)
– Validation of systems to ensure accuracy, reliability, consistent
intended performance, and the ability to discern invalid or altered
records.
 US Code of Federal Regulations 21 CFR Part 211, §211.68(b)
– (b) Appropriate controls shall be exercised over computer or related
systems to assure that changes in master production and control
records or other records are instituted only by authorized personnel.

7. ©2015 Waters Corporation 7
What is Validation?

8. ©2015 Waters Corporation 8
Qualification vs. Validation
“Validation Cake”
IQ/OQ qualification are just two
ingredients in the Validation Cake

9. ©2015 Waters Corporation 9
Application Qualification vs. Validation
SOPs
Validation Plans/
Reports
Extended OQ
Specifications
/ RTM
IOQ
Product
Qualification:
The product is
installed and
operating correctly to
vendor specification
at that point in time
Computerized System
Validation* (CSV) :
Achieving and maintaining
compliance with applicable GxP
regulations and fitness for intended
use by:
• the adoption of principles,
approaches, and life cycle
activities within the framework of
validation plans and reports
• the application of appropriate
operational controls throughout
the life of the system
* Definition taken from GAMP® 5

10. ©2015 Waters Corporation 10
Design &
Configuration
Specification
Risk Assessment
Test Plan
Validation
Summary
Report
Customised OQ/PQ
Project Stages of the Life Cycle
Computerized System Validation
Life Cycle
Validation Plan
User
Requirements
Specification
IQ / OQ
Traceability
Matrix

11. ©2015 Waters Corporation 11
Specification: Vendor vs. URS
USER REQUIREMENT
SPECIFICATION
Engine Diesel
Seats 7
Transmission Auto; 4 WD
Load Space Camping /
Fishing
Suspension Comfortable
Vendor’s Specification (page 1 of 20)

12. ©2015 Waters Corporation 12
Fit for Intended Use
Car Computerized System
Diesel (fuel) IQ/OQ Qualifications
Oil, Coolant, Tyre pressure Validation Documents
Driving Licence Trained Users
Insurance, Registration SOPs
Annual Service Periodic Review

13. ©2015 Waters Corporation 13
 The VP should provide an overview of the entire project, focusing on
aspects related to patient safety, product quality, and data integrity
 The plan should define:
– What regulations the system must meet
– What activities are required
– How they will be performed and who is responsible
– What their output (deliverable or service) will be
– What are the requirements for acceptance
– How the system will be maintained in a compliant state for the duration
of its use i.e. throughout its operating life
 The level of detail in the plan should reflect the risk, complexity,
and novelty of the system.
Validation Plan

14. ©2015 Waters Corporation 14
 URS captures WHAT the customer WANTS from the system
– E.g. faster reporting, better data integrity, secure storage etc.
 It clearly defines the highly critical requirements, such as:
– Security, data integrity
– Differential access of roles
– Global policies configured in the application
– Regulatory requirements, 21 CFR part 11
– Data Acquisition, Processing,
Reporting
– Recovery of system during an
interruption in network or
database connectivity
User Requirement Specification

15. ©2015 Waters Corporation 15
Risk Assessment
 The Risk Assessment documents the risk priority determined for
each function from the URS
 The risk priority is determined by a combination of severity of
harm, likelihood of occurrence and probability of detection
 It is very important to clearly define the scope of the risk
assessment
– What is in scope e.g. system limits and functionality
– What is out of scope e.g. IT infrastructure, other applications to
which the system interfaces
(such as SAP, LIMS)

16. ©2015 Waters Corporation 16
 DCS documents HOW the supplier product has been configured to meet
the customer’s needs, and to mitigate identified risks
 It is essential to provide a record of what has been installed and
configured at the customer site.
– The DCS defines the hardware components, architecture, or interfaces.
– The DCS details the configuration of the Informatics software and how it is
intended to be used in Production.
– The DCS includes the definitions of all
settings and parameters.
– The DCS defines the software modules that
make up the complete software
package and the interfaces between
those modules.
– Can also be called SDS, SCS, PCS, CS
Design and Configuration Specification

17. ©2015 Waters Corporation 17
Extended Testing
 Based on the outcome of the risk assessment, there may be
areas identified as high risk where additional testing (above the
standard IOQ) may be justified
– This is documented in the Test Plan.
 Additional tests may need
to be written as a customised
OQ, to test the limits and
boundaries of high risk priority
functions (critical functions)
 There will need to be a PQ
written, to verify that the user
configuration provides a system
that is fit for intended use

18. ©2015 Waters Corporation 18
Requirements Traceability Matrix
 The RTM provides a list of requirements which are mapped to
relevant validation deliverables, such as SOPs, DCS, IQ, OQ,
PQ, and/or vendor documentation.
 The RTM document provides the level of detail necessary to
understand:
– How the system is configured
to meet requirements.
– Where test results are located for
each requirement.
– The potential impact when
considering a change to the
system.

19. ©2015 Waters Corporation 19
Validation Summary Report
 A Validation Summary Report
includes:
– An outline of all testing completed,
including any deviations and
discrepancies encountered during
the execution of the test plan as
described in the Validation Plan.
– A description of any outstanding
technical issues.
– A summary of any customer user
requirements (from the URS) that
have not been met by either
technical or procedural controls.
– A recommendation if the system is
fit for intended use.

20. ©2015 Waters Corporation 20
Life Cycle in Detail
Functions identified as
high risk priority are
given focus in the
Test Plan
Detailed Test Plan
Design &
Configuration
Specification
Controls to reduce risk
are included in the SDS,
and pass into the System
Configuration
Risk Assessment
Functions from the URS are
assessed in the Risk
Assessment
Configuration
Project Planning
Initial Definition
User Requirements
Specification
Definition is expanded
to capture
requirements
Validation
Plan
Verification
Activities
Verification activities
challenge the
risk-reduction
controls
Validation Summary
Report
Summary report
details any
deviations and
residual
risks

21. ©2015 Waters Corporation 21
Effective Vendor Involvement -
Deliverables
Item Prepared by Executed by Comments
User
Requirement
Specification
Vendor in
consultation with
customer
N/A URS defines what the system must do
for the customer
Validation Plan Vendor based on
customer strategy
N/A Must implement customer’s site/global
validation strategy
Risk Assessment Customer, with
vendor as facilitator
Stakeholder
meeting
Customer makes final decision on
high, medium, low risk categories
Configuration
Specification
Vendor Vendor CS records exactly what will be (has)
been installed and all the parameters
and settings applied
Standard and
Extended IQ/OQ
Vendor Corporate
Validation Group
Vendor Validation
Specialist
May use automated tools. Completed
protocols/results must be approved by
the customer’s Quality Rep
Customised
tests/PQ
Vendor, based on
Risk Assessment
Lab Analysts Additional tests, from Risk
Assessment, to test intended use &
SOPs.
Traceability
Matrix
Vendor N/A Maps requirements from URS through
testing
Validation
Summary Report
Vendor N/A Report will cover any deviations.
Completed protocols/results/reports
must be approved by the customer’s
Quality Rep and Project Manager

22. ©2015 Waters Corporation 22
It doesn’t stop at the Validation Summary
Report…

23. ©2015 Waters Corporation 23
Operational Activities requiring SOPs
Service
Management
and
Performance
Monitoring
Scheduled
support
activity/
performance
monitoring task
becoming due
System
superseded or
ready to be
replaced
A system
change is
required
Incident
Management
and CAPA
process
Audit and
Review Process
Business
Continuity
Management
Process
Security and
System
Administration
Records
Management
Process
System security issues
and administration
requests received
Incident resolved
and preventative
actions taken
where required.
Records
available for
audit and
review
An incident
occurs
Change completed
and change
management
records generated.
Issue resolved:
Request fulfilled;
Security and administration
records generated
Incident
escalated
Audit Records
generated
Operational life of
system begins
Link To: System
Handed over to
business
System Operation
Operational records
generated
Other supporting processes: Document Management, Calibration, Training, Maintaining End User Procedures
Service records and performance
information generated
Service or
support required
Corrective
actions
identified
Scheduled record
management activity/task
becoming due
Figure 2.1: Major Relationships Between Operational Activities
Change
Management
Process
System use
continues
Data Migration
and System
Retirement
Diagram © ISPE 2009

24. ©2015 Waters Corporation 24
SOPs
 Handover
 Routine Use
 System Administration
 Backup and Restore
 Support Services
 Incident Management
 Corrective and Preventive
Action
 Operational Change
 Configuration Management
 Document Management
 Business Continuity
 Security Management
 Performance Monitoring
 Data Migration
 Training
 Calibration
 Repair Activity
 Periodic Review

25. ©2015 Waters Corporation 25
Enforcement Action

26. ©2015 Waters Corporation 26
US FDA Enforcement
 FDA publishes all its warning letters online
http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/default.htm
 FDA mainly cites against:
Sec. 211.68 Automatic, mechanical, and electronic equipment.
(a) Automatic, mechanical, or electronic equipment or other types of equipment, including
computers, or related systems that will perform a function satisfactorily, may be used in
the manufacture, processing, packing, and holding of a drug product…Written records of
those calibration checks and inspections shall be maintained.
(b) Appropriate controls shall be exercised over computer or related systems to
assure that changes in master production and control records or other records are
instituted only by authorized personnel. Input to and output from the computer or
related system of formulas or other records or data shall be checked for accuracy. …
Sec. 211.194 Laboratory Records
(a) Laboratory records shall include complete data derived from all tests necessary to
assure compliance with established specifications and standards, including
examinations and assays…

27. ©2015 Waters Corporation 27
USV 2013
 21 C.F.R. §211.68(b)
– … Our inspection team found that current computer users in the
laboratory were able to delete data from analyses. Notably, we also
found that the audit trail function…was disabled at the time of the
inspection. Therefore, your firm lacks records for the acquisition, or
modification, of laboratory data.
– Moreover, greater than (b)(4) QC laboratory personnel shared login
IDs for (b)(4) high performance liquid chromatographs (HPLC)
units… Analysts also shared the username and password for the
Windows operating system for the (b)(4) GC workstations and no
computer lock mechanism had been configured to prevent
unauthorized access to the operating systems. Additionally, there
was no procedure for the backup and protection of data on the GC
standalone workstations.

28. ©2015 Waters Corporation 28
USV 2013 (2)
 In your response, you indicate that your firm performs periodic
back-ups of data, however your firm lacks assurance that the
periodic backed up data includes all of the original data
generated. Your response to this deficiency does not discuss
how you will ensure that data audit trails will not be disrupted in
the future and lacked a computer life cycle approach to, for
example, assure routine verification of access controls in
computer systems.

29. ©2015 Waters Corporation 29
Wockhardt 2013 (1)
 21 CFR 211.68(b)
Facility X: The inspection documented that all of your QC
laboratory computerized instruments ((b)(4) HPLCs) were found
to be stand-alone, and laboratory personnel demonstrated that
they can delete electronic raw data files from the local hard
drive. Your firm deleted multiple HPLC data files acquired in
2013 allegedly to clear up hard drive space without creating
back-ups. Your QC management confirmed that there is no
audit trail or other traceability in the operating system to
document the deletion activity. Furthermore, your analysts do
not have unique user names and passwords for the computer
and laboratory information systems; your QC analysts use a
single shared user identifier and password to access and
manipulate multiple stand-alone systems.

30. ©2015 Waters Corporation 30
Wockhardt 2013 (2)
 In response to this letter, provide your evaluation of all
laboratory equipment that may be affected by the lack of
adequate controls to prevent data manipulation. In addition,
address the root cause of your quality unit's failure to control
and detect the manipulation or alteration of laboratory
documents and describe actions to prevent recurrence. In
response to this letter, provide your procedures to manage all
computerized data and how the data will be used, retained and
stored to ensure its integrity.

31. ©2015 Waters Corporation 31
ISPE Annual Meeting, Las Vegas 2014
Karen Takahashi,
Senior Policy Advisor
US FDA

32. ©2015 Waters Corporation 32
When the trust has been broken…

33. ©2015 Waters Corporation 33
Consequences for Wockhardt

34. ©2015 Waters Corporation 34
Legacy Systems Validation

35. ©2015 Waters Corporation 35
Scenario
 The QC lab has been using their Chromatography Data System
for the last two years
 They had the vendor execute IQ/OQ after installation but never
did Computerized System Validation
 They are now worried about their next audit

36. ©2015 Waters Corporation 36
Legacy Validation Planning
 Involve the vendor
– Leverage their product knowledge and validation templates for
maximum efficiency
– Start by capturing how the system is used currently as this will form
the URS
 Be realistic about timescales
– If you’ve used the system for 2 years without validation, a few more
weeks is not that significant
– Allow time to complete the process in a controlled, documented
manner
 Use the Risk Assessment for past as well as present risks
– Where are the risks to data integrity in the system?
– Are there valid concerns about the integrity of data from previous
batches?

37. ©2015 Waters Corporation 37
Executing Legacy Validation
 Follow the V model
 Start by base-lining the current system: ‘what is’
 Use the validation process to optimise the system configuration
and SOPs: ‘what would be best’
 Invest time and effort in capturing all points of view –
remember the analysts
are experienced system
users by now
 Implement re-training for
users to reinforce the
‘what would be best’
 Use Periodic Review to
review the new approach

38. ©2015 Waters Corporation 38
Summary

39. ©2015 Waters Corporation 39
Common CSV concerns
 How much validation effort is enough?
– Use a Risk-Based approach to focus effort on the functions which can
directly impact data integrity, product quality and patient safety.
– Validate smarter, not extra.
 We have to do CSV but we don’t know how / don’t have
resource available.
– Choose a software vendor who can assist with validation activities.
– Hiring an outside consultant is slower (no product knowledge).
 We have had a computerized system in place for some time, but
we never did the validation. What do we do now?
– It’s never too late.
– A subject matter expert can still apply validation activities to an
existing system (legacy systems validation / retrospective
validation).

40. ©2015 Waters Corporation 40
Summary
 Validation activities provide a framework for the system which:
– Documents the system’s requirements and configuration
– Identifies and verifies the critical functions
– Formally assesses that the system is fit for intended use
– Provides a roadmap that can be used to manage the system during
its operational life
 Maintaining system compliance is ongoing
– Change Control to manage software updates / change of use
– System Administration to manage users and data
– Periodic Review to evaluate compliance during operation

41. ©2015 Waters Corporation 41