Change

Change
Control
Control
Wolfgang Schumacher
Roche Pharmaceuticals, Basel
Training Course
Computerized System Validation in the Pharmaceutical Industry
Istanbul, 16-17 January 2003
Agenda
Agenda
Change Control
Definitions
Guidelines
Configuration management
Responsibilities
Planned/unplanned changes
Classification
Sources of changes
Example/Annex:
Template "Change request form ABC Pharma"
System Development Life Cycle
System Development Life Cycle
(Generic Approach) (Generic Approach)
Detailed
specs.
Specification Design Config./Implem. Qualification
Operation
User
Requirements,
Functional Spec.
IQ, OQ, PQ
Maintenance,
Requalification
Change Control,
Periodic Review
Validation
Planning
FAT
SAT
Change
Change
Management
Management
Attributes
Attributes
Responsibility of system owner together with the
end-user
No universal procedure
More than one procedure may be appropriate
Organization
Infrastructure
Component being changed
Position in life cycle
Change request typically initiated by user
Reasons for Planned System Changes
Reasons for Planned System Changes
Hardware
Software
Release update
Bug fixes
IT Infrastructure
Network
Server
PCs
Personnel
Supplier
Change
Change
Management
Management
Regulations
Regulations
/
/
Guidelines
Guidelines
".....change control measures can apply to
equipment, standard operating procedures,
manufacturing instructions, environmental conditions,
or any other aspects of the process system that has an
effect on ist state of control, and therefore on the state
of validation."
Proposed Rules, 21 CFR parts 210 and 211, May 3,
1996
Configuration
Configuration
Management
Management
Definition ANSI/IEEE
Definition ANSI/IEEE
"A formal engineering discipline that provides methods
and tools to identify and control software, hardware
and related documentation throughout its development
and use."
Standards
IEEE 828: Software configuration management plans
IEEE 1042: Software configuration management
Change
Change
Management
Management
Regulations
Regulations
/
/
Guidelines
Guidelines
USA
CFR GMP sections 210 and 211
PDA Technical Report No. 18
Europe
EU GMP Guide, Annex 11
GAMP Guide
Requirements of the
Requirements of the
FDA
FDA
Most recent statement of the FDA (CDRH) in:
General Principles of Software Validation
Published in the Federal Register on 11 January 2002
(Docket No. 97D-0282)
Provides guidance to medical device manufacturers and
FDA staff
Only applicable for Medical Devices, but considerable
influence on other sections
CDRH: Center for Devices and Radiological Health
General Requirement
General Requirement
All configuration items shall be clearly defined every time
All configuration items are subject to change control after
their release for use
All changes have to be documented in a formal way
PIC/S Guidance PI 011 PIC/S Guidance PI 011- -1 Good Practices for 1 Good Practices for
Computerized Systems in Regulated GxP Computerized Systems in Regulated GxP
Environments, Environments, Draft January Draft January 2002 2002
Changes are mentioned in chapters
17. Change Management
18. Change Control and Error Report System
20. Data Changes - Audit Trail/Critical Data Entry
GAMP 4
GAMP 4
Changes are mentioned in
Configuration Management
Guideline Project Change Control, Annex M8
Change Control during system operation
Guideline Operational Change Control, Annex O4
Periodic Review
Guideline Periodic Review, Annex O1
GAMP: Good Automated Manufacturing Practice
The
The
Change Control
Change Control
Phases
Phases
Change request (User)
Evaluation, decision (System Owner)
Evaluation of realization (IT/Service Provider)
Definition of validation activities, priorization, risk
assessment (System Owner, IT, QA)
Implementation (IT/Service Provider)
Change review (QA)
Release of computerized system (System Owner)
Changes
Changes
-
-
Roles & Responsibilities
Roles & Responsibilities
System Owner
Approval and release for realization
Release of system after completion
QA
Review/Approval of CC request
Risk evaluation
Review of entire documentation
Review/Release of systems after completion
Business
CC request
Preparation of risk assessment
Testing
Generation of documentation
Classification of
Classification of
Changes
Changes
Example:
Major Change
A change to a validated computerized system that,
in the opinion of change-control reviewers,
necessitates substantial efforts to implement the
change and return the system to a validated status.
Minor Change
A change to a validated computerized system that,
in the opinion of change-control reviewers, requires
a relatively small effort to implement the change and
return the process to a validated status.
Change
Change
Management
Management
Sources of Change
Sources of Change
Software
Software failures: bugs/defects
Enhancements
New version(s) of operating system
New version(s) of layered software
New version(s) of application(s)
Program temporary fixes: patches
Change
Change
Management
Management
Sources of Change
Sources of Change
Hardware
Computer
Failures: disk, memory, power supply, etc.
Controlled processes: sensors, etc.
Firmware
Updated Hardware
New components, boards
Additional Hardware
New periphericals
Expanded use
Change
Change
Management
Management
Sources of Change
Sources of Change
Network
Hardware, software, security
Other uses
People
New people, new procedures, errors
Vendors
New software, hardware, etc.
Unplanned System Changes
Unplanned System Changes
Characteristics
Short or no advance warning period
Require
immediate evaluation
immediate solution for the problem
temporary quarantaine of the system
Problem: Documentation must be generated
retrospectively
Change
Change
Management
Management
Repetitive Change
Repetitive Change
Time-driven but periodic
Part of preventative maintenance
Replacement of parts
Re-calibration
Require verification
Traceability of Changes
Traceability of Changes
Ensure traceability by
assigning clear attributes, e.g.
system name, version No.
requester
reason for change (benefit of change)
running number of change request
optional: cost
status of realization
approval of change and release of system with signatures
documentation on CC form
if CC form is an electronic document, then 21CFR Part 11
is fully applicable
Traceability
Traceability
Traceability of requirements must be ensured by e.g.
Traceability Matrix
Database
Tools (e.g. Telelogic DOORS)
Implementation and documentation in the software (code)
itself
On
On
-
-
going evaluation
going evaluation
Once a process is validated, it must be maintained in
the validated state by a number of procedures that
assure that the process remains in the state-of-control.
There should be written procedures for:
Security of data generated (including back-up)
Access control (including password change)
Emergency recovery
Change Control
Personnel Training
Change
Change
Management
Management
Change Control/Change Management implies the
control of change and not the computer-related
system
Configuration Management
Automatic capture and storage of component
relationship for computer-related system
Build history of component relationship
Change
Change
Management
Management
Attributes
Attributes
Change management
Characteristics
Implementation
Recording of change
Periodic evaluation Sign-off
Change
Change
Management
Management
Documentation
Documentation
Document
How? Who? Review? Approvals?
Possible documents affected:
SOPs
Problem report/incident log
Change request including course of action
Qualification activities
Change report
Changes in
Changes in
Complex Systems
Complex Systems
(Example:
(Example:
SAP)
SAP)
Change Frequency Effort
Release change rare very high
Bug fixes, support packs frequent medium - high
New functionalities frequent low - medium
New authorizations frequent very low
New core data very frequent very low
New hardware rare low - medium
All changes have to be tested on the integration system which is
operated in parallel (synonym: validation- or QA-system).
Changes
Changes
during
during
System Development
System Development
Prior to operation
often in the IQ/OQ Phase
What has to be done?
new system specification necessary
update of documentation
Freezing of System
Freezing of System
Design
Design
When does the Change Control Process start during
system development?
Design Freeze
Agreement among all involved parties that no further
changes to a design document, system, or system
software will be made without the use of change
control procedures. The purpose of a design freeze is to
prevent coding, testing, or qualification of an evolving
system or its software and to ensure that the
qualification program is directly tied to the as-build-
system.
System
System
Log
Log
Books
Books
Capture execution of day to day activities
concerning operation of the system
Act as a historical reference of changes
considered "minor" and not requiring
comprehensive change control
documentation
Can capture small "glitches" not
documented elsewhere
Baseline
Baseline
Definition
Definition
of the
of the
FDA (1995)
FDA (1995)
"A specification or product that has been formally
reviewed and agreed upon, that serves as the basis for
further development, and that can be changed only
through formal change control procedures."
The
The
Baseline
Baseline
Concept
Concept
The Baseline is freezing the current status of the
system
All Configuration elements are working together
Baselines should be generated
with new releases
at important milestones/Changes
The Change Management starts with the (new)
Baseline
Change
Change
Management
Management
Cost
Cost
of Change
of Change
Should be part of the Change Control SOP and
request formate and include evaluation of
Indirect costs
Savings of the change
Return on investment
Alternatives existing (instead of change)