Validation of Computerized Laboratory

Systems

RACI Conference - Chemical Analyses

Dr. Ludwig Huber

Ludwig_huber@labcompliance.com
 Overview

• FDA/EMA GxP and ISO 17025 requirements

• Recommendations from industry task forces
• Validation steps with examples for all validation phases
from setting specifications to reporting
• Leveraging supplier support for highest efficiency

Validation and use of Cloud

Computing in regulated areas?

Slide 2
 FDA GMP (211.68)
• (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.
• If such equipment is so used, it shall be routinely
calibrated, inspected, or checked according to a written
program designed to assure proper performance. Written
records of those calibration checks and inspections shall be
maintained

Slide 3
 US FDA 21 CFR Part 11
- Electronic Records, Electronic Signatures -
11.10 (a):
• Computer systems should be validated to ensure
accuracy, reliability and consistent intended
performance
Guidance: Scope and Applications
• We recommend that you base your approach for
validation on a justified and documented risk
assessment and a determination of the potential of
the system to affect product quality and safety, and
record integrity.
• For instance, validation would not be important for
a word processor used only to generate SOPs
•
Slide 4
FDA Warning Letter/483/EIR
• During the inspection, I asked if the computer software
has been validated. I was told that the software was
validated by the manufacturer.
• The managing director provided me a copy of the letter
the received from (the vendor). The letter indicated that
the software was validated.
• I told the managing director I still need to see what they
have done to validate the system since the computer
was making a decision to accept or reject potential
donors. (www.fdawarningletter.com, W-191)

Validate computer systems at the user’s site

Slide 5
FDA Warning Letter/483/EIR
• Failure to adequately validate computer software used in
an automated process for its intended use according to an
established protocol, as required by 21 CFR 820.70(i).
• For example, no person from your firm reviewed or
approved the third party approval test results for the
original "[redacted] Complaint System Validation" used in
your firm's quality system. (www.fdawarningletter.com, W-
210)

User firm should always review validation results

Slide 6
 FDA Warning Letter/483/EIR

• No IQ, OQ or PQ has been performed throughout

the life of the system. No validation reports have
been generated historically (for the legacy system).
• The (system) has not been maintained under
established procedures for change control. This is
true throughout the life of this software application.
(W-190)

Develop a procedure for validation and change control of

legacy system.

Slide 7
 FDA Warning Letter/483/EIR (2012)
• There are several instances of incomplete qualification of
equipment and incomplete laboratory data
• We recommend that you seek the advice of a third-party
consultant for assistance with a complete evaluation (W-276)

FDA Recommends 3rd Party Consultant for Lab

Equipment Qualification

Reference: www.fdawarningletter.com

Slide 8
FDA Warning Letter/483/EIR
• User access levels for the [redacted] software were not
established and documented. Currently, laboratory
personnel use a common password to gain access to
the system and there are no user access level
restrictions for deleting or modifying data. (W-198)

Assign unique user ID for each person

Reference: www.fdawarningletter.com

Slide 9
FDA Warning Letter/483/EIR
Data security protocols are not established that describe the
user's roles and responsibilities in terms of privileges to
access, change, modify, create, and delete projects and
data (242)

Develop a list with roles and responsibilities for functions

Implement and validate the procedures

Reference: www.fdawarningletter.com (242)

Slide 10
 FDA Warning Letter/483/EIR
• Your firm's review of laboratory data does not include a
review of an audit trail or revision history to determine if
unapproved changes have been made.. (229)
• Deviation: Missing Review of Audit Trail
• Root cause (assumed for the purpose of this case study):
No procedure for formally review electronic audit trail
• Corrective action to correct the existing violation
Develop and implement procedure for reviewing e-audit trail by
QA
• Preventive actions
Apply procedure to other computer systems that record e-audit
trail.

Reference: www.fdawarningletter.com (229)

Slide 11
Data Checks

• Built-in checks for correct and secure

entry and processing of data
• Additional check on accuracy for critical data
entry
– By second operator
– By validated electronic means
• Criticality and potential consequences of
erroneous or incorrectly entered data covered by
risk management

Slide 12
 Printouts
• Clear printed copies of electronically stored data
• For records supporting batch release
– Print-outs should indicate if any of the data
has been changed since the original entry
(audit trail)

Abs reprocessed
*
time

Slide 13
 Audit Trails
• System audit trail should be considered for
– Creation
– Change
– Deletion or records
• Reason for change
• Audi trail records should be convertible to a
generally intelligible form
• Audit trail records should be regularly reviewed
– Include this as checklist item in batch
record review

Slide 14
Computer System Validation:
Official Guidelines
• USP <1058> Analytical Instrument Qualification (Category C) (2008)
• PIC/S Good Practice Guide
Using computers in GxP environments (2003)
• Japan MHLW : Guideline on Management of Computerized Systems
for Marketing Authorization Holders and Manufacturers of Drugs and
Quasi-drugs
• GAMP 5 (2008)
A Risk based approach to Compliant GxP Computerized Systems
• GAMP Good Practices Guide (2012)
A Risk based approach to GxP Compliant Laboratory
Computerized Systems

PIC/S: Pharmaceutical Inspection Cooperation Scheme

Slide 15
 GAMP® 5
A Risk Based Approach to Compliant
GxP Computerized Systems
• Reference document for computer system validation
• Referenced in FDA and PIC/S Guides
• Uses V-lifecycle model, risk based approaches
• Defines four software categories (down from 5)
• Supplemented by Good Practices Guides for specific
applications (lab systems, testing, data archiving)

GAMP ® : Good Automated Manufacturing Practice

Order from www.ispe.org

Slide 16
GAMP® : A Risk based approach to GxP
Compliant Laboratory Computerized Systems
Key concepts
• Product and process understanding
– Draw process and data flow
• Lifecycle approach within a quality management system
– From system conception to retirement
• Scalable system lifecycle
– Based on complexity, novelty, system impact on patients
• Science based quality risk assessment
– Focus on critical aspects of system
• Leveraging supplier involvement
– E.g., through documentation (specs), testing, consulting
• Calibration of laboratory systems

• ’ Slide 17
Comparison – GAMP Guide vs. USP 1058
GAMP Lab Guide
• Flexible and scalable lifecycle approach
• Describes 3 systems with different complexity, mainly with
computers connected to equipment in one or the other way,
• Focus on risk assessment for all validation phases
• Uses the term verification
• Very detailed for system validation
USP <1058>
• Fixed lifecycle approach, with flexibility in each phase
• Describes 3 instrument categories, ranging from simple
equipment such as mixers to complex computer systems
• Uses the term qualification
• More like a frame work than details for AIQ

Slide 18
 Instrument&System Categories
GAMP Lab Guide
Simple
Systems
Computerized
Standalone Standalone
Magnetic Stirrers HPLC - Mass
Balances Balances
Vortex Mixers spectrometers
pH meters
Medium
Systems
Computerized
LC-MS

Verification with Full qualification Complex

Visual inspection
specifications Systems
May not require
formal qualification Networked
Systems
USP <1058>

Slide 19
Computer System Validation – GAMP ® Cat 4
l User requirement specifications
Design Qualification l Functional/config. specifications
l Vendor qualification

Configuration design
Configuration l

l Configuration implementation

Installation Qualification l Check arrival as purchased

l Check proper installation of
hardware and software

l Test of configuration specifications

Operational Qualification l Test of functional specifications
l Test of security functions

Performance Qualification l Test for user requirement

specifications
l Preventive maintenance

Slide 20
Recommendations for Implementation
• Start with a concept: e.g., define business needs,
processes, potential solutions
• Make a plan with time table, owners and deliverables
• Write specifications and compare with vendor
specifications, design review for configurable systems
• Conduct risk assessment
• Select and qualify the supplier
• Verify and document installation
• Test for suitable operation
• Check and document ongoing performance
• Write a summary report
• Formally release
• Keep changes under control
Available through
www.labcompliance.com/agilent

Slide 21
 Step 1: Make a Plan
• Background, why will there be a new system
• System description
• References, responsibilities
• Steps/approaches for validation
• Vendor assessment
• IQ, OQ, PQ (
• Change control and revalidation
• Training
• Schedule
• Contents of validation report and
other documents

Slide 22
Validation Plan Template
Purpose of the Plan
Product Description
Validation Strategy
Responsibilities (position)
Supplier Assessment
Risk assessment
Testing Strategies and reporting
DQ
IQ
OQ
PQ
Traceability matrix
Procedures
Approval
Documents and control

Slide 23
Step 2: Define Requirements
• Intended application
• Intended environment
– Computer environment
– Laboratory
• User requirements
– Operating systems
– Networks
– Compatibility with other systems
– Functions to perform applications
– Functions to comply with regulations
(Annex 11, Part11)

Verify with the vendor if requirements are met

Slide 24
Example: RS for e-Audit Trail
Req. ID Requirement Critical Test Test ID
Priority
12.01 Data system should have high high T24
computer generated, time-
stamped audit trail to record
the date and time of
operator entries and actions
that create, modify, or delete
electronic record
12.02 The system should allow high high T25
optional entry of the reason
for a change

Slide 25
Step 3: Qualify the Suppler
1. Purpose: determine the adequacy of the suppliers
quality system
2. Types of assessment
- Preliminary assessment (questionnaire, postal audit)
- Detailed on-site audit (quality system, process,
product)
3. Extent of the assessment depends on
- criticality of the system, complexity
- risk to data integrity associated with use
of the system
- ability to verify system functionality in the lab
4. Can reduce in-house testing through tests done by
the supplier

Slide 26
 Document Vendor Selection
Requirements Results Passed
1) Company □ yes □ no
Experience with the vendor □ yes □ no
Recognition in the market place
2) Quality Assurance
ISO Certification □ yes □ no
Documented software development □ yes □ no
3) Product functions (provide detailed list) □ yes □ no
4) Services and Support
Provide specifications list □ yes □ no
Installation service □ yes □ no
IQ/OQ services □ yes □ no
Phone and onsite support □ yes □ no

Slide 27
Slide 27
 Supplier Contributions for Validation
• Operate product development, manufacturing and
support in a documented quality management system
• Document software development and validation
activities
• Summarize testing activities for hardware and software
• Provide conformity declarations and/or validation
certificates for equipment and software
• Respond to supplier assessment requirements in
timely manner
• Allow and be cooperative with vendor audits
• Allow access to test conditions and results
• Offer IQ/OQ services
• Provide software for system suitability testing

Slide 28
Documents that Should be Provided by
Software Suppliers
 Functional specifications
 Documented evidence of working under a recognized
quality system (ISO 9001 or equivalent)
 Validation certificate or declaration of system validation
 Description of software development and validation
process
 Environmental specifications for facilities
 Site preparation checklist
 Documented evidence of qualifications for personnel that
develop and support computer systems
 Declaration of conformity to specifications for equipment
hardware

Slide 29
Step 4: Perform and Document
Installation Qualification
l Collect supplier’s environmental conditions, operating and working
instructions and maintenance requirements
l Compare systems, as received, with purchase order
l Install of systems according to vendor
specifications
l Make system drawings (e.g., data flow)
l Check documentation for accuracy
and completeness
l Document all components with
asset and serial numbers

Slide 30
 Installation Testing - Examples
System ID ____________ Date installed ___________
Test Objective: Verify acceptable installation
Installer Name ________________ Installer Signature ______________
Start: Log on as system administrator

Test Test Procedure Pass Fail

1 System log-on
2 Load test method and instrument parameters

3 Run well characterized test sample

4 Compare with reference plot
5 Document and sign results
6 Access help file

Tester: I confirm that I have all tests executed as described

Name: ___________ Signature__________ Date_________
Tests passed: yes no Comment: ___________________________

Slide 31
Slide 31
 Conduct Risk Management
• Should be applied throughout the lifecycle of a
computerized system
• Decisions on extent of validation and data integrity
controls should be based on a justified and
documented risk assessment
– Impact on product quality and
patient safety
– Impact on data integrity

Comment from Labcompliance:

Example for high risk: Systems & records supporting batch release, e.g., QC
equipment and data systems, electronic batch record system
Example for low risk: Word processing system to write a validation report

Page 32
Document the System in the Computer
System Inventory
ID/ Description Location Application GxP Risk Contact Time Frame
Asset h,m,l for
Number Validation
RV3212 Chromatogr. G4 Instrument Yes m Bill Hinch Jun-Jul
Data System West1 control, TN 432 2011
data 123
acquisition

PIC/S
• For GxP regulated applications it is essential for the regulated user to
carry out a properly documented ... risk analysis for the various system
options
• The inspector will consider the potential risks, .., as identified and
documented by the regulated user, in order to assess the fitness for
purpose of the particular system(s).

Slide 33
Step 5: Test for Operational Qualification

• Identify critical functions for the computer

systems as defined in functional and
user requirement specifications
• Develop test cases for the functions and
define acceptance criteria
• Perform the tests
• Evaluate results and compare with
acceptance criteria
• Document results

Slide 34
What to Test

• Functions that can be impacted by the user’s

environment
– User configurations
– User customizations
– Hardware configurations, cabling
(communication between computer and
equipment)
• Real critical system functions
• Run well characterized test sample
– Compare test results with acceptance criteria

Slide 35
Why Companies in EU/US Choose
Manufacturers Operational Qualification
Services
Tools for equipment hardware qualification
• Some tests require traceable test tools
• The tools typically need to be calibrated yearly
Qualification of test engineers
• Test engineers must be formally qualified
• Training must be regularly updated and thoroughly documented
• Manufacturer engineer bring qualification certificates along
• Manufacturer engineers can fix problems if OQ does not pass
Documentation
• Vendors provide inspection ready documentation
Compliance
• There are many FDA warning letters based on user’s OQ
• I am not aware of a vendor’s OQ based warning letter

Slide 36
Step 6: Ensure Ongoing
Performance (PQ)
System Testing
• Regular system performance tests
– System suitability testing, QC Samples
– Development, review, approval of SOPs
Maintenance
• Regular disk maintenance
• Regular virus checks
• Environmental control
Regular data back-up
Change control procedures and logs

Slide 37
 Step 7: Implement Change
Control System

• Main reasons for changes: hardware

maintenance and repair and software
upgrades
• Changes must follow a documented
change procedure
• Procedure should require risk analysis and
evaluation if the change may affect the
computerized system's validation status
• Document changes; what, why, who, how
tested?

Slide 38
Step 8: Write the Validation
Report
• Should include brief description of
each major project activity
• Used to review all preceding validation
activities and indicate status of the system prior to
implementation into a production environment
• Deviations from the project plan should be
documented and risk assessment should be
performed

• Approval of the validation report pre-requisite for

release

Slide 39
Validation Phases – 4Q Model
APPROACH FOR EXISTING EQUIPMENT
Define System Use
l Document equipment use
l Document applications
l Document used functions

l Enter all modules and systems in a

Installation Qualification database
l Hardware, Firmware, Software

l Document past tests

Operational Qualification l Test of functional specifications
l Test of performance functions

l System test (system suitability

Performance Qualification testing)
l Preventive maintenance

+ Change Control

Slide 40
 Thank You
I would like to thank
• All attendees for your attention
• Agilent Technologies for invitation and organizatopn

Give feedback and choose any two from over 150 documents
(value: $138) for free: SOPS and/or Validation examples.
GOTO:
www.labcompliance.com/misc/conferences/feedback.aspx
Offer expires on March 10, 2014
For links to Computer System Validation references, please check
www.labcompliance.com/agilent
(Available until March 10, 2014)
Ludwig Huber
Labcompliance Sponsored by
Slide 41