Computer systems compliance

Computer Systems Compliance
How compliant are your
Computer System
Validation (CSV)
Practices?
Computer System Validation Overview
M. Luqman Ikram
Assistant Manager Validation

M.Luqman Assistant Manager
validation2
SESSION SCHEDULE
References
Regulatory Requirements
Best Practices
Quality Risk Management
Life Cycles
– Computer Systems
– Project Management
– Computer Validation
Simplification
Interactive Discussion

validation3
References
FDA, "General Principles of Software Validation
Guidance," Office of Device Evaluation Center
for Devices and Radiological Health, January
2002.
FDA, "Technical Reference on Software
Development Activities," Reference Materials and
Training Aids for Investigation, July 1987.
GAMP@ 5: A Risk-Based Approach to Compliant
GxP Computerized Systems”, Version 5.0,
ISPE/GAMP Forum, February 2008.

validation4
References
G. Grigonis, E. Subak, and M. Wyrick,
“Validation Key Practices for Computer Used in
Regulated Operations,” Pharmaceutical
Technology, June 1997.
NIST, “Risk Management Guide for Information
Technology Systems,” Special Publication 800-30.
Pharmaceutical Engineering, Vol 21, No. 3,
May/June 2001.
PIC/S Guidance, “Good Practices for Computerised Systems in
Regulated “GxP”Environments”, PI 011-3, September 2007.

validation5
REGULATORY
REQUIREMENTS

validation6
There are no laws to regulate Computer
Systems Validation, but . . .
Guidelines and recommendations used by auditors
in order to understand the validation status of IT
systems
Particularly interesting are
– ICH - International Conference on Harmonization of
Technical Requirements for Registration of Pharmaceuticals
for Human Use
– PIC/S - Pharmaceutical Inspection Cooperation Scheme
– GAMP5 - Good Automated Manufacturing Practices
exporting products to US market
– FDA Guidelines

validation7
Audited Areas
Governance: QMS – Policy – Process – Procedure –
Operating Guideline
Computerized Systems Lifecycle
Document Management System
Datacenter
Back & Recovery
Disaster Recovery
Security
ERES / 21 CFR 11 Compliance

validation8
Inspection Trends
General GMP/GLP/GAMP
Equipment hardware1990
Computer Validation/Excel/Networks
Security/data integrity
Part 11
1999-2002
New Part 11
approach
2004-2006 GMP Basics, OOS, CAPA
1993-1995 Software/Computer System Validation
2008-2011
CSV (Devices) Data
Integrity
(Pharma)

validation9
CGMP Applicability To Hardware and Software, CPG
7132a.11
– Issued October 1984.
– In the absent of explicit regulations addressing
computer systems, the regulations provide the
implicit guidelines necessary to meet
the agency’s expectations.
• Hardware is regarded as equipment.
• Application Software will be regarded as
records.
– Utilized to determine and apply the appropriate
sections of the regulations that address
equipment and records.

validation10
I/O Checking, CPG 7132a.07.
– – Issued September 1982.
– Complements the input/output (I/O) checks referenced in
21 CFR211.68.
– Computers I/Os are to be tested for data accuracy as
part of the computer system validation/qualification and,
after the validation/qualification, as part of the computer
system’s on-going performance evaluation process.
– The verification of outputs also ensures that each
reproduced document uses as input(s) reliable and
accurate data.

validation11
Identification of "Persons" on Batch Production and
Control Records, CPG 7132a.08.
– Issued November 1982.
– "Double Check" issue.
- Can computers perform functions that the GMP regulation require
a person to perform? Yes, if the computer has been qualified and
the qualification documentation is available.
• 211.188(b)(11)
• 211.101(c)
• 211.103 • 211.182

validation12
Identification of “Persons” on Batch
Production and Control Records, CPG
7132a.08 (Cont’d).
– The required double check can be replaced by
an automated single check if it demonstrably
provides at least as much assurance of
correctness.
– Verification by a second individual may not be
necessary when automated equipment is used as
described under 21 CFR 211.68

validation13
Source Code for Process Control Application Programs,
CPG7132a.15.
– Issued April 1987.
– Source code may be part of the master production and control
records. Refer to CPG 7132a.11.
– Structural testing shall be performed to assure that process
specifications, conditions, sequencing, decision criteria, and
formulas have been properly incorporated.
– Detect and remove dead code.

validation14
Vendor Responsibility, CPG7132a.12.
– Issued January 1985.
– The user is responsible for the suitability of computer
systems used in manufacture, processing or holding of a
medical device.
– The vendor may also be liable under the FD&A Act.

validation15
Drugs and Biologics, 21 CFR 211.68,
EU Annexure 11
REGULATORY
REQUIREMENTS

validation16
Current good manufacturing practices (cGMP)
applicable to computer systems are:
– Computer systems can be used to perform operations covered by
the drugs GMP regulation. These computer systems require a written
validation process.
– Computers systems documentation and validation documentation
shall be maintained.
– There must be procedural controls for managing changes to
infrastructure and application software, including documentation.
– Computer systems electronic records must be controlled including
records retention, backup, and security.

validation17
Current good manufacturing practices (cGMP) applicable to
computer systems are (Cont’d):
– Based on the complexity and reliability of computer systems there must
be procedural controls and technologies to ensure the accuracy and
security of computer systems I/Os electronic records and data.
– Computer systems must have adequate controls to prevent
unauthorized access or changes to data, inadvertent erasures, or loss.
– There must be written procedural controls describing the maintenance
of the computer system, including an on-going performance evaluation
and periodic reviews.

validation18
Best Practices
GUIDANC
E

validation19
Today’s Operating Environment
-In the regulatory context, computer systems are integrated into
the operating environment. The operating environment may include
the process or operation being controlled or monitored by the
computer system, the procedural controls, process-related
documentation, and the people.

validation20
System Life
Cycle
SLC adapted to different system acquisition strategies and software
development models. It is focused on software engineering key
practices.

validation21
Description of Key Practices Model

validation22
Description of Key Practices Model

validation23

validation24
Best Practices Guidance
ISO/IEC 12207
– Information Technology—Software Life-Cycle Processes
– This standard describes the major component processes of a
complete software life cycle, their interfaces with one another, and the
high-level relations that govern their interactions. This standard covers
the life cycle of software from conceptualization of ideas through
retirement. ISO/IEC 12207 describes the following lifecycle processes:
• Primary Processes: Acquisition, Supply, Development,
Operation, and Maintenance.
• Supporting Processes: Documentation, Configuration
Management, Quality Assurance, Verification Validation, Joint
Review, Audit, and Change Control.
• Organization Processes: Management, Infrastructure,
Improvement, and Training

validation25
ISO/IEC 12119
– Information Technology – Software Packages
Quality requirements and testing
– This standard is applicable to software packages.
Examples are text processors, spread-sheets, data
base programs, graphics packages, programs for
technical or scientific functions, and utility programs.

validation26
IEEE Std 15288-2008
– Systems and Software Engineering— System Life Cycle
Processes
– This standard establishes a common process framework for
describing the life cycle of man-made systems. It defines a set
of processes and associated terminology for the full life cycle,
including conception, development, production, utilization,
support and retirement. This standard also supports the
definition, control, assessment, and improvement of these
processes. These processes can be applied concurrently,
iteratively, and recursively to a system and its elements
throughout the life cycle of a system.
– Revision of ISO/IEC 15288-2004.

validation27
ISO/IEC 16085:2006
– Systems and Software Engineering -- Life Cycle Processes
-- Risk management--
– It defines a process for the management of risk in the
life cycle. It can be added to the existing set of
system and software life cycle processes
defined by ISO/IEC 15288 and ISO/IEC 12207,
or it can be used independently.

validation28
Quality Risk
Management
GUIDANCE

validation29
What Is a Risk-Based Approach?
Many interpretations, many alternatives
How granular does the risk-based process need to be?
Is it a method to differentiate one system from another?
Differentiate one process from another?
Differentiate specific functions within one system?

validation30
Goals of a Risk-Based Approach
Establish a mechanism that will provide a
documented standard approach to justify the
prioritization and the risk strategies that will be
employed for each system
Categorize and prioritize the universe of systems
that are impacted by the regulatory requirements
within the organization, department, unit, etc.
Develop specific risk reduction/remediation
strategies based on a documented analysis of the
system and the process that is supported

validation31
Value of a Risk-Based Approach
Provides Focus
Supports Priority Setting
–Between processes, systems, functions
Supports Resource Allocation

validation32
Risk Management – A Dynamic Process
Risk
Identification
Risk Assessment
Risk Analysis
Risk Evaluation
Risk Control
Identify possible risk events
Estimate the level of risk
Determine acceptability of the risk
Implement
protective
measures

validation33
Risk Management Plan
Analysis techniques
Estimate likelihood of each risk
Estimate severity of each risk
Propose risk reduction and remediation techniques
Implement and assess effectiveness
Verification or validation activities that will demonstrate risk
reduction

validation34
Risk Management – Three-Level
Approach
Process – What processes to remediate and control?
– Risks from critical processes
– e.g. clinical data management
System – What systems to remediate and control?
– Risk from entire system supporting a critical process
– e.g. Laboratory data management system
Function – What functions require controls?
– Risk from specific functions that a system performs
–pieces and parts of systems need to be treated differently
– e.g. clinical data entry
Higher risk/complexity = deeper drill-down

validation35
Processes Level
Examine your processes
Understand each process and how the results are used
Which ones are the most critical?
– To patient safety
– To product efficacy & quality
– To the business
– To approval of your product

validation36
Systems Level
Not all systems support critical pieces of the overall process
Must understand all the parts and pieces that make up the
process
What systems touch the critical processes and how do they do
it?
Is data created, deleted, changed?
What would happen if the data was incorrect?

validation37
Functions Level
Not all functions of a specific system are critical to the overall
operation of the system
What are the functions that are used by the systems that are
involved in the critical steps?
How are they used and what effect do they have on the records
that the system contains?
Which ones are critical to the system and therefore to the
process?

validation38
Micro Level - Data Transfer to
BIMS
Spreadsheet
File
Merge Data File
Manipulate
to Match
BIMS
Format
ASCII File

validation39
Risk Analysis
Objective examination of risks to determine
quantitative and qualitative attributes of each
risk and the overall risk
Determine intended use/intended purpose
Identify known or foreseeable hazards
Estimate risks for each hazard

validation40
Risk Management Report
• Description of analysis techniques used
• Estimated likelihood of each risk and how it was
estimated
•Estimated severity of each risk and how it was
categorized Risk reduction and remediation techniques
implemented and assessment of effectiveness
•Verification and validation activities that demonstrated
risk reduction controls

validation41
Results
Dealt with critical systems and issues
Allocated scarce resources wisely
Minimized …
– public health risk
– regulatory risk
– business risk
Documented is Defended

validation42
Integration with SLC

validation43
Integration with SLC

validation44
Life Cycles
GUIDANCE

validation45
System
Development
Life Cycle
SDLC adapted to different system acquisition strategies and software
development models. It is focused on software engineering key
practices.

validation46
Project Life Cycle

validation47
Computer Systems Validation Life Cycle

validation48

validation49
SIMPLIFICATION

validation50
Pre-commissioning

validation51
Commissioning

validation52
Post-commissioning

validation53

Computer systems compliance

In this document

More Related Content

What's hot

Viewers also liked

Similar to Computer systems compliance

Recently uploaded

Computer systems compliance