Computer systems compliance

Computer Systems Compliance

How compliant are yourComputer System Validation (CSV) Practices?

Computer System Validation Overview

M. Luqman Ikram Assistant Manager Validation

M.Luqman Assistant Manager validation 2

SESSION SCHEDULE

ReferencesRegulatory RequirementsBest PracticesQuality Risk ManagementLife Cycles

– Computer Systems– Project Management– Computer Validation

SimplificationInteractive Discussion


References

FDA, "General Principles of Software ValidationGuidance," Office of Device Evaluation Centerfor Devices and Radiological Health, January2002.

FDA, "Technical Reference on SoftwareDevelopment Activities," Reference Materials andTraining Aids for Investigation, July 1987.

GAMP@ 5: A Risk-Based Approach to CompliantGxP Computerized Systems”, Version 5.0,ISPE/GAMP Forum, February 2008.


References

G. Grigonis, E. Subak, and M. Wyrick,“Validation Key Practices for Computer Used inRegulated Operations,” PharmaceuticalTechnology, June 1997.

NIST, “Risk Management Guide for InformationTechnology 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.


REGULATORYREQUIREMENTS


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 systemsParticularly 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


Audited Areas

Governance: QMS – Policy – Process – Procedure –Operating GuidelineComputerized Systems LifecycleDocument Management SystemDatacenterBack & RecoveryDisaster RecoverySecurityERES / 21 CFR 11 Compliance


Inspection TrendsGeneral GMP/GLP/GAMP

Equipment hardware 1990

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)


Regulatory Requirements

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.



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.



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 requirea 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



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



Source Code for Process Control Application Programs, CPG7132a.15.

– Issued April 1987.– Source code may be part of the master production and controlrecords. Refer to CPG 7132a.11.– Structural testing shall be performed to assure that processspecifications, conditions, sequencing, decision criteria, andformulas have been properly incorporated.– Detect and remove dead code.



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


Drugs and Biologics, 21 CFR 211.68,EU Annexure 11

REGULATORYREQUIREMENTS



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.



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.


Best Practices

GUIDANCE


Today’s Operating Environment

-In the regulatory context, computer systems are integrated into the operating environment. The operating environment may includethe process or operation being controlled or monitored by the computer system, the procedural controls, process-related documentation, and the people.


System Life Cycle

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


Description of Key Practices Model


Description of Key Practices Model



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



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.



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.



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.


Quality Risk Management

GUIDANCE


What Is a Risk-Based Approach?

Many interpretations, many alternativesHow 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?


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 systemCategorize 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


Value of a Risk-Based Approach

Provides FocusSupports Priority Setting

–Between processes, systems, functionsSupports Resource Allocation


Risk Management – A Dynamic Process

RiskIdentification

Risk Assessment

Risk Analysis

Risk Evaluation

Risk Control

Identify possible risk events

Estimate the level of risk

Determine acceptability of the risk

Implementprotective measures


Risk Management Plan

Analysis techniquesEstimate likelihood of each riskEstimate severity of each riskPropose risk reduction and remediation techniquesImplement and assess effectivenessVerification or validation activities that will demonstrate riskreduction


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


Processes Level

Examine your processesUnderstand each process and how the results are usedWhich ones are the most critical?

– To patient safety– To product efficacy & quality– To the business– To approval of your product


Systems Level

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


Functions Level

Not all functions of a specific system are critical to the overall operation of the systemWhat 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?


Micro Level - Data Transfer to BIMS

SpreadsheetFile

Merge Data File

Manipulateto Match

BIMSFormat

ASCII File


Risk Analysis

Objective examination of risks to determine quantitative and qualitative attributes of each risk and the overall riskDetermine intended use/intended purposeIdentify known or foreseeable hazardsEstimate risks for each hazard


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


Results

Dealt with critical systems and issuesAllocated scarce resources wiselyMinimized …

– public health risk– regulatory risk– business risk

Documented is Defended


Integration with SLC


Integration with SLC


Life Cycles

GUIDANCE


System Development Life Cycle

SDLC adapted to different system acquisition strategies and software development models. It is focused on software engineering key practices.


Project Life Cycle


Computer Systems Validation Life Cycle



SIMPLIFICATION


Pre-commissioning


Commissioning


Post-commissioning


Health & Medicine

Computer systems compliance