You are on page 1of 41

Introduction to Computerized System


Charlie Wakeham
ISPE Philippines Conference April 2015

©2015 Waters Corporation 1

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.

©2015 Waters Corporation 2

Data Integrity for an analysis result

Sample Standards used

Sets for Calibration

Original Curves
Processing Method

Raw Data
Instrument Method

Who Collected When

Who Processed What
Any Changes Why
Product Code/
Validation Deliverables Who Reviewed
Stage Reagent
Training Records Who Approved
LC/GC System Used LIMS ID
©2015 Waters Corporation
Calibration / Suitability 3
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
o Backup the data
o Test the backup
o Check it will restore when needed

 Periodic Review

©2015 Waters Corporation 4

Regulatory Drivers

©2015 Waters Corporation 5

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

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

©2015 Waters Corporation 6

What is Validation?

©2015 Waters Corporation 7

Qualification vs. Validation

IQ/OQ qualification are just two

“Validation Cake” ingredients in the Validation Cake

©2015 Waters Corporation 8

Application Qualification vs. Validation
Computerized System
Validation* (CSV) :
Achieving and maintaining
SOPs compliance with applicable GxP
regulations and fitness for intended
use by:
Validation Plans/
Reports • the adoption of principles,
approaches, and life cycle
activities within the framework of
Extended OQ validation plans and reports
• the application of appropriate
operational controls throughout
Specifications the life of the system

IOQ Qualification:
The product is
installed and
operating correctly to
vendor specification
at that point in time

©2015 Waters Corporation * Definition taken from GAMP® 5 9

Computerized System Validation
Life Cycle

Project Stages of the Life Cycle

Validation Plan Validation

User Report

Risk Assessment IQ / OQ

Design & Customised OQ/PQ


Test Plan

©2015 Waters Corporation 10

Specification: Vendor vs. URS
Vendor’s Specification (page 1 of 20)

Engine Diesel
Seats 7
Transmission Auto; 4 WD
Load Space Camping /
Suspension Comfortable
©2015 Waters Corporation 11
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

©2015 Waters Corporation 12

Validation Plan

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

©2015 Waters Corporation 13

User Requirement Specification

 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,
– Recovery of system during an
interruption in network or
database connectivity

©2015 Waters Corporation 14

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
– 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)

©2015 Waters Corporation 15

Design and Configuration Specification

 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

©2015 Waters Corporation 16

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

©2015 Waters Corporation 17

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
– 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

©2015 Waters Corporation 18

Validation Summary Report

 A Validation Summary Report

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

©2015 Waters Corporation 19

Life Cycle in Detail
Project Planning Summary report Validation Summary
Initial Definition details any Report
deviations and
Definition is expanded residual
to capture risks

User Requirements Validation

Specification Plan

Functions from the URS are

assessed in the Risk

Risk Assessment

Controls to reduce risk Functions identified as

are included in the SDS, high risk priority are
and pass into the System given focus in the
Configuration Test Plan
Design & Detailed Test Plan Verification
Configuration Activities
Verification activities
challenge the

©2015 Waters Corporation 20

Effective Vendor Involvement -

Item Prepared by Executed by Comments

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

©2015 Waters Corporation 22

Operational Activities requiring SOPs
Operational life of
system begins Data Migration
Link To: System System Operation and System
Handed over to
business System Retirement
Operational records superseded or
Service or
generated ready to be
support required

System security issues Issue resolved:

and administration Request fulfilled;
requests received
Security and Security and administration
records generated

Change completed
A system and change
change is management
required Change records generated. Scheduled record
Management management activity/task
Scheduled Process becoming due
monitoring task Service Incident resolved
becoming due Management An incident
and preventative
and Incident actions taken
Performance Management where required.

Monitoring and CAPA


Incident Business System use
escalated Continuity
Management Records
Process available for
audit and
Audit Records
identified Audit and
Review Process
Diagram © ISPE 2009
Service records and performance
information generated

Other supporting processes: Document Management, Calibration, Training, Maintaining End User Procedures

©2015 Waters Corporation Figure 2.1: Major Relationships Between Operational Activities 23

 Handover  Document Management

 Routine Use  Business Continuity

 System Administration  Security Management

 Backup and Restore  Performance Monitoring

 Support Services  Data Migration

 Incident Management  Training

 Corrective and Preventive  Calibration

Action  Repair Activity
 Operational Change  Periodic Review
 Configuration Management
©2015 Waters Corporation 24
Enforcement Action

©2015 Waters Corporation 25

US FDA Enforcement

 FDA publishes all its warning letters online

 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…

©2015 Waters Corporation 26

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.

©2015 Waters Corporation 27

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.

©2015 Waters Corporation 28

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.

©2015 Waters Corporation 29

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.

©2015 Waters Corporation 30

ISPE Annual Meeting, Las Vegas 2014

Karen Takahashi,
Senior Policy Advisor

©2015 Waters Corporation 31

When the trust has been broken…

©2015 Waters Corporation 32

Consequences for Wockhardt

©2015 Waters Corporation 33

Legacy Systems Validation

©2015 Waters Corporation 34


 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

©2015 Waters Corporation 35

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

 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
©2015 Waters Corporation 36
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

©2015 Waters Corporation 37


©2015 Waters Corporation 38

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

©2015 Waters Corporation 39


 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

©2015 Waters Corporation 40

©2015 Waters Corporation 41