GAMP 5

A Risk-Based
Risk Based Approach to
Compliant GxP
Computerized Systems
Stephen Shields
10 September 2013
ASQ Orange
O
Section
S ti Meeting
M ti Part
P t1

Disclaimer

This presentation is made at the request of ASQ.

The presenter is a full-time employee and stockholder of Allergan, Inc.

The information provided and opinions expressed during this presentation

are those of the presenter and are not the position of and may not be
attributed to Allergan, Inc.

Agenda

Overview
Life Cycle Approach
Life Cycle Phases
Concept
Project
Software Category and Life Cycle Approach

GAMP Document Structure

Drivers for GAMP 5

Purpose
Computerized systems are fit for intended use
Compliant with applicable regulations

Good Manufacturing Practice (GMP)

G d Clinical
Good
Cli i l P
Practice
i (GCP)
Good Laboratory Practice (GLP)
Good Distribution Practice (GDP)
Medical Device Regulations (excluding medical device software)

Provide framework which aims to safeguard patient safety, product quality,

and data integrity, while also delivering business benefit
Framework aims to safeguard patient safety, product quality, and data
i t it while
integrity,
hil also
l d
delivering
li i b
business
i
b
benefit
fit

Main Body Structure

Life cycle approach within a Quality Management System
Life cycle phases:
Concept
Project
P j t
Planning
Specification, Configuration, and Coding
Verification
Reporting and Release
Operation
Retirement

Science based q
quality
y risk management
g
Regulated company activities:
Governance for achieving compliance
System specific activities

Supplier activities
Efficiency improvements

Key Concepts

Computerized System

PIC/S Good Practices for Computerised Systems in Regulated GXP Environments (PI 011)

Typical Computerized Systems

Clinical Trials Data Management

Manufacturing Resource Planning
Laboratory Information Management
Automated Manufacturing Equipment
Automated Laboratory Equipment
Process Control and Process Analysis
Manufacturing Execution
Building Management
Warehousing and Distribution
Blood Processing Management
Adverse Event Reporting (vigilance)
g
Document Management
Track and Trace
10

Life Cycle Approach

11
ASTM E2500-07 Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment,

Life Cycle Phases

12

Concept Phase

Strategic Planning
Need Identification
Business Justification
Compliance Justification
Migration Need
Technical Feasibility
Management Commitment
User Requirement Initiation
Project Initiation

13

Project Phase - Stages

Planning
Specification, Configuration, Coding

Verification
Reporting and Release

Release

Supporting Processes
Risk Management Change & Configuration Management Design Reviews Document Control Traceability

14

Operation Phase - Stages

15

Planning Stage
A clear and complete understanding of User Requirements is needed
Planning should cover all required activities, responsibilities, procedures,
and timelines
Activities should be scaled according to:
system impact on patient safety, product quality, and data integrity (risk assessment)
system complexity and novelty (architecture and categorization of system components)
outcome off supplier
li assessment ((supplier
li capability)
bili )

The approach should be based on product and process

understanding, and relevant regulatory requirements

16

Specification, Configuration, and Coding Stage

The role of specifications is to enable systems to be developed, verified,
and maintained based on the users requirements and risk profile
Any required configuration should be performed in accordance with a
controlled
t ll d and
d repeatable
t bl process
Any required software coding should be performed in accordance with
defined standards.
Configuration management is an intrinsic and vital aspect of controlled
configuration and coding.

17

Verification Stage
Verification confirms that specifications have been met
Verification activities occur throughout the project stages
Design Reviews
Testing
T i

An appropriate test strategy should be developed based on the risk,

complexity, and novelty.
Supplier documentation should be assessed and used if suitable
suitable.
The test strategy should be reviewed and approved by appropriate SMEs
Tests should cover hardware, software, configuration, and acceptance

18

Reporting and Release Stage

At the conclusion of the project, a computerized system validation report
should be produced summarizing the activities performed, any deviations
from the plan, any outstanding and corrective actions, and providing a
statement of fitness for intended use of the system
system.
The system should be accepted for use in the operating environment and
released into that environment in accordance with a controlled and
documented process.
p
Acceptance and release of the system for use in GxP regulated activities
should require the approval of the process owner, system owner, and
quality unit representatives.
Well managed system handover from the project team to the process
owner, system owner, and operational users is a pre-requisite for effectively
maintaining compliance of the system during operation.

19

Supporting Processes

Risk Management
Change and Configuration Management
Design Review
Traceability
Document Management

20

Software Categories
Category 1 Infrastructure Software
Established or commercially available layered software
Infrastructure software tools

Category 3 Non-Configured
Non Configured Products
Commercial-Off-The-Shelf (COTS) system that cannot be configured to conform to business
processes or are configurable but only the default configuration is used.

Category 4 Configured Products

Products provide standard interfaces and functions that enable configuration of user specific
business processes.

Category 5 Custom Applications

These systems or subsystems are developed to meet the specific needs of the regulated
company

21

Typical Life Cycle Approach Category 1

Description
Layered Software

Typical Examples

Operating Systems
Database Engines
Software used to
Middleware
manage the operating Programming Languages
environment
Statistical Packages
Spreadsheet Application
Network Monitoring Tools
Scheduling Tools
Version Control Tools

Typical Approach
Record version number,
verify correct installation
by following approved
installation procedures

22

Typical Life Cycle Approach Category 3

Description

Typical Examples

Run-time parameters
Firmware-base Apps
may be entered and
COTS Software
stored, but the software Instruments
cannot be configured to
suit the business
process.

Typical Approach
Abbreviated life cycle
approach.
URS.
Risk-based approach to
supplier assessment.
Record version number,
verify correct installation.
Risk-based tests against
requirements as dictated by
use.
Procedures in place for
maintaining compliance and
23
fitness for intended use.

Typical Life Cycle Approach Category 3

24

Typical Life Cycle Approach Category 4

Description

Typical Examples

Typical Approach

Software, often very

complex that can be
complex,
configured by the
user to meet the
specific needs of the
users business
process.
Software code is not
altered
altered.

LIMS
Data acquisition
systems
SCADA
ERP
MRPII
Clinical Trial
monitoring
DCS
ADR Reporting
EDMS
BMS
CRM
Spreadsheets
Simple HMIs

Life cycle approach.

Risk-based approach
pp
to supplier
pp
assessment.
Demonstrate supplier has adequate
QMS
Some life cycle documentation retained
only by supplier (e
(e.g.,
g Design Spec)
Record version number, verify correct
installation.
Risk-based testing to demonstrate
application works as designed in a test
environment
Risk-based testing to demonstrate
application works as designed within the
business process
Procedures in place for maintaining
compliance and fitness for intended use
Procedures in place for managing data 25

Typical Life Cycle Approach Category 4

26

Typical Life Cycle Approach Category 5

Description

Typical Examples

Typical Approach

Software custom
designed and coded
to suit the business
process.

Varies, but includes:

Internally and
externally developed
IT applications
Internally and
externally developed
process control
applications
Custom ladder logic
Custom firmware
Spreadsheets
(macro)

Same as for configurable, plus:

More rigorous supplier
assessment, with possible
supplier audit
Possession of full life cycle
documentation (FS, DS,
structural testing, etc.)
Design and source code
review

27

Typical Life Cycle Approach Category 5

28

Questions?
Stephen Shields
WWQA Director
Computerized System Compliance and Quality

All
Allergan,
IInc.
Shields_Stephen@Allergan.com
714-246-5320

29