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