This document provides an overview of validation requirements for computerized systems used in manufacturing processes. It discusses validating both hardware and software, including system specifications, functional specifications, security, backups, and revalidation. The key aspects to consider include location, maintenance, inputs, outputs, limits, documentation, consistency, and functionality under worst-case conditions.
Facility Qualification & Consideration of Validation Aspects
GMP Computer Systems Validation Guide
1. Supplementary Training Modules on
Good Manufacturing Practice
Validation
WHO Technical Report Series,
No. 937, 2006. Annex 4.
Validation | Slide 1 of 31 August 2006
2. Validation
Part 1. General overview on qualification and validation
Part 2. Qualification of HVAC and water systems
Part 3. Cleaning validation
Part 4. Analytical method validation
Part 5. Computerized system validation
Part 6. Qualification of systems and equipment
Part 7. Non sterile product process validation
Validation | Slide 2 of 31 August 2006
3. Supplementary Training Modules on
Good Manufacturing Practice
Computerized systems validation
Part 5
WHO Technical Report Series,
No. 937, 2006. Annex 4. Appendix 5
Validation | Slide 3 of 31 August 2006
4. Validation
Objectives
To discuss validation of computerized systems including:
System specifications
Functional specifications
Security
Back-ups
Validation:
– Hardware
– Software
Validation | Slide 4 of 31 August 2006
5. Validation
General
Validated - level appropriate
– or their use and application.
Production and quality control.
Computer systems used in planning, specification,
programming, testing, commissioning, document operation,
monitoring and modifying.
Validation: Evidence and confidence
– intended use, accuracy, consistency and reliability.
1.1 – 1.3
Validation | Slide 5 of 31 August 2006
6. Validation
General (2)
Both the system specifications and functional
specifications should be validated.
Periodic (or continuous) evaluation should be performed
after the initial validation.
1.4 – 1.5
Validation | Slide 6 of 31 August 2006
7. Validation
Written procedures for:
– performance monitoring, change control, programme and
data security, calibration and maintenance, personnel
training, emergency recovery and periodic re-evaluation
During validation, consider:
– networks
– manual back-ups
– input/output checks
– process documentation, monitoring
– alarms, and
– shutdown recovery
1.6 – 1.7
Validation | Slide 7 of 31 August 2006
8. Validation
System specification (Control document)
In place, stating:
– objectives of a proposed computer system
– the data to be entered and stored
– the flow of data
– how it interacts with other systems and procedures
– the information to be produced
– the limits of any variable
– the operating programme and test programme
(Examples of each document produced by the programme
should be included) 2.1
Validation | Slide 8 of 31 August 2006
9. Validation
System specification (Control document) (2)
System elements that need to be considered in computer
validation include:
– hardware (equipment)
– software (procedures)
– people (users)
2.2
Validation | Slide 9 of 31 August 2006
10. Validation
Functional specification (Performance specification)
Provide instructions for:
– testing, operating, and maintaining the system
– names of the person(s) (development and operation)
When using computer systems, consideration:
– location
– power supply
(Fluctuations in the electrical supply can influence computer
systems and power supply failure can result in loss of
memory).
– temperature
3.1 – 3.2
– magnetic disturbances
Validation | Slide 10 of 31 August 2006
11. Validation
Functional specification (Performance specification) (2)
GMP requirements for computer systems:
Verification and revalidation
– After a suitable period of running a new system
– Independently reviewed and compared with the system
specification and functional specification
Change control
– Alterations made in accordance with a defined procedure
– Provision for checking, approving and implementing the
change
Checks
– Data checked periodically
– Confirm accurate and reliable transfer 3.2 – 3.3
Validation | Slide 11 of 31 August 2006
12. Validation
Security
Production as well as in quality control
Data entered or amended - authorized persons
Security systems to prevent unauthorized entry or manipulation
of data
SOPs for entering data, changing or amending incorrect entries
and creating back-ups
Security procedures in writing
4.1 – 4.3
Validation | Slide 12 of 31 August 2006
13. Validation
(continued)
Traceability is of particular importance
Audit trail:
– identify the persons who made entries
– identify the persons who made changes
– identify the persons who released material
– identify the persons who performed other critical steps in
production or control
4.4
Validation | Slide 13 of 31 August 2006
14. Validation
(continued)
Entry of critical data by an authorized person
Independent verification and release for use by a second
authorized person
– e.g. for entry of a master processing formula.
SOPs for certain systems or processes validated
– e.g. action in case of system failure or breakdown
including disaster recovery procedure in the event of a
breakdown
4.5 – 4.6
Validation | Slide 14 of 31 August 2006
15. Validation
Back-ups
Regular back-ups of all files and data
– Secure storage (prevent intentional or accidental damage)
Validation
Validation process should include:
– Planning
– Validation policy
– Project plan and SOPs
5.1 – 6.1
Validation | Slide 15 of 31 August 2006
16. Validation
Validation (2)
Define computer-related systems and vendors
Vendor and product evaluated
System designed and constructed
– Consider types, testing and quality assurance of the
software
Extent of qualification depends on complexity of the system
6.2
Validation | Slide 16 of 31 August 2006
17. Validation
Validation (3)
Qualification includes:
Installation
Evaluation of the system
Performance
Change control, maintenance and calibration, security,
contingency planning, SOPs, training, performance monitoring
and periodic re-evaluation
6.3
Validation | Slide 17 of 31 August 2006
18. Validation
Validation of hardware
Appropriate tests and challenges to the hardware
No influence of static, dust, power-feed voltage fluctuations and
electromagnetic interference
Hardware is considered to be equipment
– focus on location, maintenance and calibration as part of
the qualification
7.1.1 – 7.1.2
Validation | Slide 18 of 31 August 2006
19. Validation
Validation of hardware (2)
It should prove:
Appropriate capacity
Operational limits
– e.g. memory, connector ports, input ports
Performance under worst-case conditions
– e.g. long hours, temperature extremes
Reproducibility/consistency
– e.g. by performing at least three runs under different
conditions
7.1.3
Validation | Slide 19 of 31 August 2006
20. Validation
Validation of hardware (3)
Written qualification protocols; results in qualification reports
kept
Revalidation – in case of significant changes
Validation may be performed by the vendor – but ultimate
responsibility remains with the company
If records kept by supplier, manufacturer still has to have
sufficient records to allow assessment of the adequacy of the
validation
A mere certification of suitability from the vendor, for example,
will be inadequate
7.1.4 – 7.1.7
Validation | Slide 20 of 31 August 2006
21. Validation
Summary: Validation requirements for Hardware (See table 1 in notes)
Input Output
devices devices
Peripheral Hardware types Signal converter
devices
Central
Distribution Processing
system Unit
Validation | Slide 21 of 31 August 2006
22. Validation
Summary: Validation requirements for Hardware (See Table 1 in notes)
: Location
, environment
distances
Key aspects Signal
Maintenance To consider conversion
Command I/O operation
overrides
Validation | Slide 22 of 31 August 2006
23. Validation
Summary: Validation requirements for Hardware (See Table 1 in notes)
Revalidation Function
Consistency
and Validation Limits
documentation
Reproducibility Worst case
Validation | Slide 23 of 31 August 2006
24. Validation
Validation of Software
Software:
is the term used to describe the complete set of programmes
used by a computer, and which should be listed in a menu
Records are considered as software
Focus should be placed on:
– accuracy, security, access, retention of records, review,
double checks, documentation and accuracy of
reproduction
7.2.1 – 7.2.2
Validation | Slide 24 of 31 August 2006
25. Validation
Key computer programmes to be identified:
– language, name, function (purpose of the programme)
– input (determine inputs), output (determine outputs)
– fixed set point (process variable that cannot be changed by
the operator), variable set point (entered by the operator)
– edits (reject input/output that does not conform to limits and
minimize errors, e.g. four- or five-character number entry),
input manipulation (and equations) and programme
overrides (e.g. to stop a mixer before time)
Identification of authorized personnel
– to write, alter or have access to programmes 7.2.3 – 7.2.4
Validation | Slide 25 of 31 August 2006
26. Validation
Validation of Software (2)
Points to be considered may include:
– Consistency in performance: Within pre-established limits)
– Function: Matching the assigned operational function (e.g.
generate batch documentation, different batches of
material used in a batch listed)
– Worst case: Validation under different conditions (e.g.
speed, data volume, frequency)
– Repeats: Sufficient number of times (e.g. replicate data
entries)
– Documentation: Protocols and reports
– Revalidation: In case of significant changes made 7.2.5
Validation | Slide 26 of 31 August 2006
27. Validation
Summary: Validation requirements for Software (See Table 1 in notes)
Application Machine
language language
Level
High level Assembly
language language
Validation | Slide 27 of 31 August 2006
28. Validation
Summary: Validation requirements for Software (See Table 1 in notes)
Programme Language
overrides
, Edits Software ,Name
input identification function
manipulation
Fixed and ,Input
Variable output
Set points
Validation | Slide 28 of 31 August 2006
30. Validation
Summary: Validation requirements for Software (See Table 1 in notes)
Function
Documentation
Validation
Worst case
Revalidation
Repeats
Validation | Slide 30 of 31 August 2006
31. Validation
Group session
Validation | Slide 31 of 31 August 2006
Editor's Notes
दिसंबर 4, 2012 In this supplementary training module, we will be looking at the recommendations by WHO, on Validation and qualification. The module consists of 7 parts: Part 1. General overview on qualification and validation Part 2. Qualification of HVAC and water systems Part 3. Cleaning validation Part 4. Analytical method validation Part 5. Computerized system validation Part 6. Qualification of systems and equipment Part 7. Non sterile product process validation Each part deals with a specific topic, and each part can be presented in about one to one and a half hours time. Presenters should know the topics and add practical examples to the texts taken from the WHO guideline.
दिसंबर 4, 2012
दिसंबर 4, 2012
दिसंबर 4, 2012
दिसंबर 4, 2012 1. General 1.1 Computer systems should be validated at the level appropriate for their use and application. This is of importance in production as well as in quality control. 1.2 The use of a computer system includes different stages. These are planning, specifi cation, programming, testing, commissioning, document operation, monitoring and modifying. 1.3 The purpose of validation of a computer system is to ensure an acceptable degree of evidence (documented, raw data), confi dence (dependability and thorough, rigorous achievement of predetermined specifi cations), intended use, accuracy, consistency and reliability.
दिसंबर 4, 2012 1.4 Both the system specifications and functional specifications should be validated. 1.5 Periodic (or continuous) evaluation should be performed after the initial validation.
दिसंबर 4, 2012 1.6 There should be written procedures for performance monitoring, change control, programme and data security, calibration and maintenance, personnel training, emergency recovery and periodic re-evaluation. 1.7 Aspects of computerized operations that should be considered during validation include: — networks — manual back-ups — input/output checks — process documentation — monitoring — alarms — shutdown recovery.
दिसंबर 4, 2012 2. System specification 2.1 There should be a control document or system specification. The control document should state the objectives of a proposed computer system, the data to be entered and stored, the flow of data, how it interacts with other systems and procedures, the information to be produced, the limits of any variable and the operating programme and test programme. (Examples of each document produced by the programme should be included.)
दिसंबर 4, 2012 2.2 System elements that need to be considered in computer validation include hardware (equipment), software (procedures) and people (users).
दिसंबर 4, 2012 3. Functional specification 3.1 A functional or performance specifi cation should provide instructions for testing, operating, and maintaining the system, as well as names of the person(s) responsible for its development and operation. 3.2 The following general aspects should be kept in mind when using computer systems: — location — power supply — temperature, and — magnetic disturbances. Fluctuations in the electrical supply can infl uence computer systems and power supply failure can result in loss of memory.
दिसंबर 4, 2012 3.2 The following general aspects should be kept in mind when using computer systems: — location — power supply — temperature, and — magnetic disturbances. Fluctuations in the electrical supply can infl uence computer systems and power supply failure can result in loss of memory. 3.3 The following general good manufacturing practice (GMP) requirements are applicable to computer systems. • Verifi cation and revalidation. After a suitable period of running a new system it should be independently reviewed and compared with the system specifi cation and functional specifi cation. • Change control. Alterations should only be made in accordance with a defi ned procedure which should include provision for checking, approving and implementing the change. • Checks. Data should be checked periodically to confi rm that they have been accurately and reliably transferred.
दिसंबर 4, 2012 4. Security 4.1 This is of importance in production as well as in quality control. 4.2 Data should be entered or amended only by persons authorized to do so. Suitable security systems should be in place to prevent unauthorized entry or manipulation of data. The activity of entering data, changing or amending incorrect entries and creating back-ups should all be done in accordance with written, approved standard operating procedures (SOPs). 4.3 The security procedures should be in writing. Security should also extend to devices used to store programmes, such as tapes, disks and magnetic strip cards. Access to these devices should be controlled.
दिसंबर 4, 2012 4.4 Traceability is of particular importance and it should be able to identify the persons who made entries/changes, released material, or performed other critical steps in manufacture or control.
दिसंबर 4, 2012 4.5 The entry of critical data into a computer by an authorized person (e.g. entry of a master processing formula) requires an independent verifi - cation and release for use by a second authorized person. 4.6 SOPs should be validated for certain systems or processes, e.g. the procedures to be followed if the system fails or breaks down should be de- fi ned and tested. Alternative arrangements should be made by the validation team, and a disaster recovery procedure should be available for the systems that need to be operated in the event of a breakdown.
दिसंबर 4, 2012 5. Back-ups 5.1 Regular back-ups of all fi les and data should be made and stored in a secure location to prevent intentional or accidental damage. 6. Validation 6.1 Planning, which should include the validation policy, project plan and SOPs, is one of the steps in the validation process.
दिसंबर 4, 2012 6.2 The computer-related systems and vendors should be defi ned and the vendor and product should be evaluated. The system should be designed and constructed, taking into consideration the types, testing and quality assurance of the software. 6.3 After installation of the system it should be qualifi ed. The extent of the qualifi cation should depend on the complexity of the system. The system should be evaluated and performance qualifi cation, change control, maintenance and calibration, security, contingency planning, SOPs, training, performance monitoring and periodic re-evaluation should be addressed.
दिसंबर 4, 2012 6.3 After installation of the system it should be qualified. The extent of the qualifi cation should depend on the complexity of the system. The system should be evaluated and performance qualifi cation, change control, maintenance and calibration, security, contingency planning, SOPs, training, performance monitoring and periodic re-evaluation should be addressed.
दिसंबर 4, 2012 7.1 Hardware 7.1.1 As part of the validation process appropriate tests and challenges to the hardware should be performed. 7.1.2 Static, dust, power-feed voltage fl uctuations and electromagnetic interference could infl uence the system. The extent of validation should depend on the complexity of the system. Hardware is considered to be equipment, and the focus should be on location, maintenance and calibration of hardware, as well as on validation/qualifi cation.
दिसंबर 4, 2012 7.1.3 The validation/qualifi cation of the hardware should prove: • that the capacity of the hardware matches its assigned function (e.g. foreign language);
दिसंबर 4, 2012 7.1.4 The validation should be done in accordance with written qualifi cation protocols and the results should be recorded in the qualifi cation reports. 7.1.5 Revalidation should be performed when signifi cant changes are made. 7.1.6 Much of the hardware validation may be performed by the computer vendor. However, the ultimate responsibility for the suitability of equipment used remains with the company. 7.1.7 Hardware validation data and protocols should be kept by the company. When validation information is produced by an outside fi rm, e.g. computer vendor, the records maintained by the company need not include all of the voluminous test data; however, such records should be suffi ciently complete (including general results and protocols) to allow the company to assess the adequacy of the validation. A mere certifi cation of suitability from the vendor, for example, will be inadequate.
दिसंबर 4, 2012
दिसंबर 4, 2012
दिसंबर 4, 2012
दिसंबर 4, 2012 7.2 Software 7.2.1 Software is the term used to describe the complete set of programmes used by a computer, and which should be listed in a menu. 7.2.2 Records are considered as software; focus is placed on accuracy, security, access, retention of records, review, double checks, documentation and accuracy of reproduction.
दिसंबर 4, 2012 7.2.3 The company should identify the following key computer programmes: language, name, function (purpose of the programme), input (determine inputs), output (determine outputs), fi xed set point (process variable that cannot be changed by the operator), variable set point (entered by the operator), edits (reject input/output that does not conform to limits and minimize errors, e.g. four- or fi ve-character number entry), input manipulation (and equations) and programme overrides (e.g. to stop a mixer before time). 7.2.4 The personnel who have the ability and/or are authorized to write, alter or have access to programmes should be identifi ed.
दिसंबर 4, 2012 7.2.5 Software validation should provide assurance that computer programmes (especially those that control manufacturing and processing) will consistently perform as they are supposed to, within pre-established limits. When planning the validation, the following points should be considered. • Function: does the programme match the assigned operational function (e.g. generate batch documentation, different batches of material used in a batch listed)? • Worst case: perform validation under different conditions (e.g. speed, data volume, frequency). • Repeats: suffi cient number of times (replicate data entries). • Documentation: protocols and reports. • Revalidation: needed when signifi cant changes are made.