Computer system validation and qualification in gmp.pdf

for validation

1. COMPUTER SYSTEM
VALIDATION (CSV)
in
cGMP ENVIRONMENT

2. Overview
Computer System General Requirements and
Validation Documentation
Password Policy
User Management Policies
Audit Trail Review Mechanisms

3. What is a Computerised System
A computerized system collectively controls the
performance of one or more automated processes and/or
functions. It includes computer hardware, software,
peripheral devices, networks and documentation.

4. Means confirmation by examination and provision of
objective evidence that computer system specifications
conform to user needs and intended uses and that all
requirements can be consistently fulfilled
The purpose of validation of a computerized system is
to ensure an acceptable degree of documented
evidence that establishes confidence in the accuracy,
reliability and consistency in performance of the system
in accordance with predetermined specifications
Computerized system validation should ensure that all
necessary technical and procedural controls are
implemented ensuring compliance with good
documentation practices for electronic data generated by
the system
.................WHO GUIDELINES ON VALIDATION – APPENDIX 5 VALIDATION OF COMPUTERIZED SYSTEMS



What is Computerised Systems Validation

5. Why CSV Validation
Validation of Computerized system is required as per various
regulatory agencies regulations:

21 CFR Sec. 211.68 - Automatic, mechanical, and electronic equipment
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
ICH Q7 – Sec. 12: Validation
EU Annex 11: Computerized Systems Should be validated; IT
infrastructure should be qualified
PIC/S - Good practices for computerized systems in regulated “GxP”
environments
WHO Guidelines on validation – Appendix 5 : Validation of
computerized systems 3

6. Why CSV Validation
Provides evidence that the system functions to meet its intended
purpose
System bugs that may arise later can be rectified in a controlled
way so as to not impact the current functioning of the system
Computer systems, especially software components , cannot be
tested in the same way as a physical product/ equipment,
because:
Software is different, all software programs contain errors. How it is
used will determine whether the errors become visible or not
Software application complexity can mean that we could not test all
permutation of inputs and scenarios
Therefore end line testing (Vendor Testing) cannot be relied upon its
own to ensure product quality

7. How to Validate Computer Systems
Follow the Computer system validation master plan
Contact Corporate Informatics team for assistance
Follow the SOPs
Follow V-Model as mentioned in CSVMP
V-Model phases may be broadly grouped into two
categories
Development ( Plan, Design/Build, Validate)
Maintenance

8. How to Validate Computer Systems

9. Documents Requirements of CSV
Validation plan
Initial Risk assessment
Vendor Audit
URS, FS and SDS
Functional risk assessment
IQ.OQ.PQ
Traceability Matrix
Validation Summary Reports (IQ, OQ, PQ)
Maintenance : SOPs
Training Records

10. To ensure authenticity and integrity, All
software controlled instruments should have

1.Prevent access to unauthorized users
2.Define privileges as per job functions /
hierarchies (PRM)
3.Data should be traceable (Audit Trail)
4.Protect the data from environmental hazards
(Disaster Recovery)
5.Protect from cyber attacks (Anti virus)
6.Implement the backup procedure

13. Key Principles of Validation
Establish quality management system
Establish documents management and their control
Establish configuration and change management strategy
Develop validation and qualification plans (VP/QP)
Establish user requirements (URS) and intended uses
Establish traceability across requirements, design docs and testing
Determine acceptance criteria and develop protocols
Validation summary reports of IQ, OQ and PQ

14. Quality Infrastructure
Quality Framework : Quality Policy and SOPs
Trainings
Project execution approach
System Design
Operation and Maintenance

15. Software Validation Flow Chart
Typical Software Validation Flow Chart
User Requirement
Specification
Initial Risk Assessment
Requirement
Traceability
Matrix
Validation Plan
Vendor Assessment
Functional/System
Specification
(Software/Hardware)
Functional
Risk Assessment
Functional/System Design Specification
System configuration specification
Module/ Unit testing
Source code review
Configuration freeze notification
Installation Qualification Protocol and Report
Draft SOP Prepare
Operational Qualification Protocol and Report
Final SOPs and Training
Performance Qualification Protocol and Report
Validation summary report
System Release or Rollout

16. The User Requirements
A Key CSV document , also called “The root document”
Required in the requirements definition phase
Helping the user groups to write short , concise , testable
and traceable requirements will reduce the
guesswork and help fast track the testing approach
Developing the traceability matrix throughout the
project lifecycle focuses testing and reduces project
closeout time at the end of the project.

17. Requirements are Complete
Not the HOW
The MES shall communicate with the PLC/SCADA in a hosted
environment using TCPIP Communication protocol
BUT the WHAT
The MES shall have the capability to communicate with the
PLC/SCADA
Not Recommended :
Requirement only states WHAT happens on power fail
Recommended :
Requirements states WHAT happens on power Fail & Power
restore

18. ATTRIBUTE : Unambiguous
Requirements shouldn’t be written in more than one way

Not Recommended
1.User shall be able to upload documents of maximum size of 2 MB
2.User shall be able to upload the Legacy (Scanned) documents of
size maximum 20 MB

Recommended
1.Maximum file size for files upload is as follows :
a. 20 MB for Legacy/ Scanned documents
b. 2 MB for the rest of the document types

19. Elements of a well written URS
Requirements must specify the “what” and not the “how”
Requirements are complete
Requirements are unambiguous
Requirements are testable
Requirements are traceable

20. Requirements are traceable –A typical URS
For purposes of traceability, requirements should be
uniquely numbered and not bulleted

Not Recommended :
Maximum file size for files upload is as follows :
•20 MB for Legacy/ Scanned documents
•2 MB for the rest of the document types

Recommended :
1.0 Maximum file size for files upload is as follows
1.1 20 MB for Legacy/ Scanned documents
1.2 2 MB for the rest of the document types

21. Installation Qualification
Purpose
Scope
Reference
System Description
Identification of Test Participants
Execution procedure
Pre-requisites
Test scripts
•Verification of system documentation
•Verification of installation of hardware and software components
Discrepancy Handling
Summary and conclusion
Document History
Approvals

22. Operation Qualification
Purpose
Scope
Reference
System Description
Identification of Test Participants
Execution procedure
Pre-requisites
Test scripts
•Verification of system functionality (positive and negative testing)
•Verification of workflow scenarios
•Verification of access rights and privileges
•Verification of audit trail
•Verification of data backup and restore
Continued…

23. Operation Qualification
•21 CFR Part 11 verification
•Verification Disaster recovery procedure
•Verification of BCP procedure
•Verification of draft SOPs (Administration, operation etc.)
•Verification of trainings
Discrepancy Handling
Summary and conclusion
Document History
Approvals

24. Performance Qualification
Purpose
Scope
Reference
System Description
Identification of Test Participants
Execution procedure
Pre-requisites
Test scripts
•Verification of effective SOPs
•Verification of system functionality in actual scenario by end users
Discrepancy Handling
Summary and conclusion
Document History
Approvals

25. SOPS for CSV
Validation (CSVMP)
Vendor Audit
Document management
Change Control (QMS)
Training
Access security
User management
Audit Trail review
Periodic Review
Backup Restore
Data Archival
Maintenance phase SOPs

28. What is a VMP
Blueprint document for validation of systems and software

Cornerstone for validation

Provides the framework for :

How validation is performed and documented
How issues are managed
How to control and asses changes
How to maintain system in a validated state.

29. Validation Approach as per Software type
SOFTWARE
CATEGORY
DESCRIPTION
TYPICAL
EXAMPLES
VALIDATION APPROACH
1
Infrastructure
Software
Established or
commercially
available layered
software
Applications are
developed to run
under the control
of this kind of
software.
Operating
Systems
Database
Managers
Programming
Languages
Middleware
Ladder Logic
Network
Monitoring
Tools
Document the version
number and
configuration details
as part of
infrastructure
qualification; verify
that the system is
installed correctly as
per approved or
prescribed installation
procedures.

30. Validation Approach as per Software type
SOFTWARE
CATEGORY
DESCRIPTION
TYPICAL
EXAMPLES
VALIDATION APPROACH
3
Non-configured or
Commercial off-the-
shelf (COTS) Systems
Ready-made Computer
system or standard
software package where
no customization or
configuration has been
done or possible to be
done
Computer
controlled
spectrophotomete
rs
Firmware based
applications
Laboratory
instrument
software with no
configuration
required
Reduced system
validation life-cycle
approach
URS
Validation plan
Supplier Assessment
Initial Risk assessment
Functional and Hardware
specification
Installation Qualification
Operation Qualification
SOPs
Performance
Qualification
Validation summary
report
Data Backup procedure

31. Validation Approach as per Software type
SOFTWARE
CATEGORY
DESCRIPTION TYPICAL EXAMPLES
VALIDATION
APPROACH
4
Commercial off-the-
shelf (COTS) Systems
(Hybrid)
These are ready-made
computer systems or
standard software
package which are
configured to suit the
workflow requirements
of the user.
LIMS, Track-
wise,
SCADA, HMI
SAP
Clinical Trial
Monitoring,
DCS, EDMS,
BMS,
Spread-sheets
Full system validation life-cycle
approach
URS, Supplier Assessment,
Initial risk assessment
Hardware specifications
Functional requirements
specifications
System configuration
specifications
Functional risk assessment
Installation Qualification
Operation Qualification
SOPs
User trainings
Performance Qualification
Requirement traceability matrix
Validation summary report
System release certificate
Data Backup procedure

32. Validation Approach as per Software type
SOFTWARE
CATEGORY
DESCRIPTION TYPICAL EXAMPLES
VALIDATION
APPROACH
5
Custom-Built
Applications (In-house
/ Customized)
Custom-Built is a type of
software that is
developed an individual
organization .
Such systems may either
be developed by an in-
house programming
team or by an external
vendor but these kinds of
software are tailor-made
only for a particular
organization's specific
requirements.
System developed for
specific use as per user
requirements.
ZyIMS


Full system validation life-cycle approach
plus more rigorous supplier assessment with
possible onsite supplier audit
URS, Supplier Assessment, Initial risk
assessment
Hardware specifications
Functional requirements specifications
System configuration specifications
System design specifications
Source code review
Functional risk assessment
Module/ Unit testing at vendor site during
software development
Configuration freeze notification
Installation Qualification
Operation Qualification
SOPs
User trainings
Performance Qualification
Requirement traceability matrix
Validation summary report
System release certificate
Data Backup procedure

33. Test Environments
Complexity and size determines size and number of environments
Typically 3 environments for large applications

34. Re-Validation

38. Gap Assessments and Validation of Legacy system
Legacy Computerized Systems – PIC/s
•These are regarded as systems that have been established and
in use for some considerable time. For a variety of reasons, they
may be generally characterized by lack of adequate GMP
compliance related documentation and records pertaining to the
development and commissioning stage of the system.
Additionally, because of their age there may be no records of a
formal approach to validation of the system. (PIC/s)

Regulatory requirements for Legacy system – (PIC/s)
•Defined requirements (URS)
•System description, or equivalent (FS, DS)
•Verification evidence that the system has been qualified and
accepted and that GxP requirements are met (IQ, OQ, PQ)

43. Insure IT Infrastructure is qualified
IT SOPs are implemented
GAP assessments for legacy systems is carried out and
mitigation plans ready
Software and IT systems inventory is available
All GxP software have independent Administrators
No Generic IDs present in system
Administrator JD is available
User training records and privilege right matrix are available
Etc….

46. PASSWORD POLICY
The administrator authorizes access for a user by creating a user
account.
All users are identified by having a unique user-ID and a secret
password before being able to gain access to system
Account should lock after a certain number of failed login attempts
Auto logout from system when idle
Password policies requirements are:
A defined length of passwords to be kept
Password should be complex
Users should be able to change their own passwords at any time
Password should have a defined expiry duration
When the user log on for the first time, the system should ask to
change the password.

47. User Controls
Desktop policies to be activated on the computer system to control
access to the software by users
Password control
Date and time locking
Restriction for file/folder creation, cut, copy, paste and deletion.
No access to the window explorer and internet explorer
Locking of software / computer after predetermined time when idle.
Disable USB, CD and floppy drive
Hide local drives
Restrict access to Control panel in the computer
Restrict access to Network neighborhood
Restrict access to My Documents
Restrict access to Run option etc.
Restrict access to local administrator
Etc…..

48. USER MANAGEMENT SYSTEM IN QC
SOFTWARES

49. USER MANAGEMENT SYSTEM IN QC
SOFTWARES

50. USER MANAGEMENT SYSTEM IN QC
SOFTWARES

51. Typical Audit Trail review

52. Shashank Pandey
[email protected]