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.
2
Agenda
Overview
Life Cycle Approach
Life Cycle Phases
Concept
Project
Software Category and Life Cycle Approach
3
GAMP Document Structure
4
Drivers for GAMP 5
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
6
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 7
Key Concepts
8
Computerized System
PIC/S Good Practices for Computerised Systems in Regulated “GXP” Environments’ (PI 011) 9
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)
Document Management
g
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 Verification
Specification, Configuration, Coding Reporting and Release
Release
Supporting Processes 14
Risk Management – Change & Configuration Management – Design Reviews – Document Control – Traceability
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 user’s 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 Typical Examples Typical Approach
Layered Software • Operating Systems Record version number,
• Database Engines verify correct installation
Software used to • Middleware by following approved
manage the operating • Programming
ProgrammingLanguages
Languages installation procedures
environment • Statistical Packages
• Spreadsheet Application
• Network Monitoring Tools
• Scheduling Tools
• Version Control Tools
22
Typical Life Cycle Approach – Category 3
Description Typical Examples Typical Approach
Run-time parameters • Firmware-base Apps • Abbreviated life cycle
may be entered and • COTS Software approach.
stored, but the software • Instruments • URS.
cannot be configured to • Risk-based
Risk-based approach to
suit the business supplier assessment.
process. • Record version number,
verify correct installation.
• Risk-based tests against
requirements as dictated by
use.
• Procedures in place for
maintaining compliance and
fitness for intended use. 23
Typical Life Cycle Approach – Category 3
24
Typical Life Cycle Approach – Category 4
Description Typical Examples Typical Approach
Software, often very • LIMS • Life cycle approach.
• Risk-based app
pproach to supplier
pp
complex that can be
complex, • Data
Dataacquisition
acquisition assessment.
configured by the systems • Demonstrate supplier has adequate
user to meet the • SCADA QMS
specific needs of the • ERP • Some life cycle documentation retained
only by supplier (e
(e.g.,
g Design Spec)
user’s business • MRPII • Record version number, verify correct
process. • Clinical Trial installation.
Software code is not monitoring • Risk-based testing to demonstrate
application works as designed in a test
altered
altered. • DCS
DCS environment
• ADR Reporting • Risk-based testing to demonstrate
• EDMS application works as designed within the
• BMS business process
• Procedures in place for maintaining
• CRM compliance and fitness for intended use
• Spreadsheets • Procedures in place for managing data25
• Simple HMIs
Typical Life Cycle Approach – Category 4
26
Typical Life Cycle Approach – Category 5
Description Typical Examples Typical Approach
Software custom Varies, but includes: Same as for configurable, plus:
designed and coded • Internally
Internallyand
and • More
Morerigorous
rigoroussupplier
supplier
to suit the business externally developed assessment, with possible
process. IT applications supplier audit
• Internally and • Possession of full life cycle
externally developed documentation (FS, DS,
process control structural testing, etc.)
applications • Design and source code
• Custom
Customladder
ladderlogic
logic review
• Custom firmware
• Spreadsheets
(macro)
27
Typical Life Cycle Approach – Category 5
28
Questions?
Stephen Shields
WWQA Director
Computerized System Compliance and Quality
All
Allergan, IInc.
Shields_Stephen@[Link]
714-246-5320
29
