You are on page 1of 41

Introduction to Computerized System

Validation

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

Calibration
Original Curves
Processing Method

Unchanged
Raw Data
File
Unique
Result
Original
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
SOPs
©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
period
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
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.

©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
/ RTM

IOQ Qualification:
The product is
installed and
operating correctly to
Product
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


Summary
User Report
Requirements
Traceability
Specification
Matrix

Risk Assessment IQ / OQ

Design & Customised OQ/PQ


Configuration
Specification

Test Plan

©2015 Waters Corporation 10


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

USER REQUIREMENT
SPECIFICATION
Engine Diesel
Seats 7
Transmission Auto; 4 WD
Load Space Camping /
Fishing
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,
Reporting
– 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
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)

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

©2015 Waters Corporation 18


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.

©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
requirements

User Requirements Validation


Specification Plan

Functions from the URS are


assessed in the Risk
Assessment

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
Specification
Verification activities
challenge the
risk-reduction
controls
Configuration

©2015 Waters Corporation 20


Effective Vendor Involvement -
Deliverables

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 &
SOPs.
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
Report…

©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
replaced

System security issues Issue resolved:


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

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

Monitoring and CAPA


process

Records
Management
Incident Business System use
Process
continues
escalated Continuity
Management Records
Process available for
audit and
review
Audit Records
Corrective
generated
actions
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
SOPs

 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


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…

©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
US FDA

©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


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

©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
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?
©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


Summary

©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
validation).

©2015 Waters Corporation 39


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

©2015 Waters Corporation 40


©2015 Waters Corporation 41