Standard Operating Procedure
Title: Impact Assessment for Computerised Systems
Department Validation/Technical Services Document no VAL-045
Prepared by: Date: Supersedes:
Checked by: Date: Date Issued:
Approved by: Date: Review Date:
Document Owner
Validation Manager
Affected Parties
All Validation, Technical Service, Operations, Quality Assurance, Engineering and Project staffs involved in
validation projects.
Purpose
The purpose of this guideline is to provide a method of assessing and determining the validation
requirements for computerised systems and controllers.
The SOP identifies the typical qualification activities required for those systems having a Direct or Indirect
impact on product/process quality and data integrity, should the system fail or malfunction. These activities
are in addition to Good Engineering Practice (GEP), which is appropriate for all systems, and is also outlined.
Scope
Computer validation, as with other types of validation, is to be performed to avoid any intolerable risk to
product quality (including integrity of stored GxP data), customer safety and to maximise business benefits
from the particular system.
Impact Assessment should be applied to new projects, change requests and re-validations of Computerised
Systems.
Impact Assessment is the process by which Computerised System Items are identified and evaluated.
Impact Assessment will guide the level of validation that is required for the task at hand. All validation
requirements will be detailed or attached to the Validation Plan or Change Request forms and approved by
the validation or change request committee respectively.
The extent of validation to be performed will reflect the novelty or complexity of an Item (i.e. whether it is a
standard Item in wide-use, or a purpose-built development with no history) and its GxP Impact (i.e. Direct,
Indirect or None). From these factors, a risk profile can be developed. This allows the project team to
provide an objective approach to support the validation requirements.
Definition
Business The Business System Owner is the Manager of the functional department using a
System Owner Computerised System.
Computerised A grouping of Items that interact electronically (with one or more members of the group).
System The group may also be one stand-alone device. Also see System Boundary.
Firmware Software on a silicon chip.
Functional Testing that compares the expected output of a function with the actual output of that
Testing function when a known input is provided. Test cases include normal and abnormal inputs.
This method only qualifies the particular function tested.
Function An aspect of the internal operation of the Item (which is listed on the Impact Assessment
form and rated for GxP Impact).
This is not an approved copy unless stamped in red
File Location: Date Printed: Page 1 of 18
Standard Operating Procedure
Title: Impact Assessment for Computerised Systems
6. Documenting the Impact Assessment Process ................................ ................................ ........ 9
7. Validation Requirements ................................ ................................ ................................ ........ 10
7.1. Standard Requirements ................................ ................................ ................................ ................ 10
7.2. Examples Justifying a Non-standard Approach................................ ................................ .............. 12
8. Qualification ................................ ................................ ................................ ........................... 13
8.1. Good Engineering Practices................................ ................................ ................................ ..........13
8.2. Structural Verification ................................ ................................ ................................ .................... 13
8.3. Functional Verification................................ ................................ ................................ ................... 14
8.4. Vendor Audit Report................................ ................................ ................................ ...................... 14
8.5. Test Environment Operations................................ ................................ ................................ ........15
9. Impact Assessment Process Overview ................................ ................................ .................. 15
10. Typical Product Quality Characteristics ................................ ................................ .................. 16
11. Impact Assessments for Record Types ................................ ................................ .................. 17
12. Summery of Changes ................................ ................................ ................................ ............ 18
Procedure
1. Responsibility
The Business System Owner, Change-Control Coordinator or Project Coordinator is responsible for
carrying out Impact Assessments during new projects, Change Requests and re-validations of
computerised systems.
It is also the responsibility of the Business System Owner or project coordinator to have relevant
representatives from Engineering, IS and Quality Assurance (Validation) review (or input to) this
Impact Assessment.
2. System Identification
A Computerised System usually includes multiple Items that interact electronically, but it may be a
single Item acting in isolation. The Master Inventory Item in the Computerised System is identified,
based empirically on the seniority of its controlling function and its direct electronic contact with the
majority of related Items within the Computerised System. It is usually a PLC if available.
The system boundary is defined by listing all of the related items of the system on the Impact
Assessment form (Form 705) for the Master Inventory Item.
Below are a few examples of computerised systems.
Solution Preparation PLC Autoclave Controller
Process Monitoring System (i.e. SCADA) Laboratory Computerised System (i.e. HPLC)
Purified Water System PLC HVAC Controller
This is not an approved copy unless stamped in red
File Location: Date Printed: Page 3 of 18
Standard Operating Procedure
Title: Impact Assessment for Computerised Systems
4. Complexity Assessment (GAMP Categorisation)
All Items can be categorised into one of following five categories. The GAMP category reflects the
degree of novelty or complexity of an Item and will influence which validation activities are
applicable.
4.1. Category 1 Operating Systems (Compilers and System Configuration Files)
Specific validation of commercially available operating systems (and compilers), which are
established in the market, is not required. The validation of the application software running
on the operating system is considered to validate the operating system. Operating systems
rely on system configuration files that can impact on system performance and data usage
and therefore should be recorded.
Typical examples: Windows NT and Unix
4.2. Category 2 Firmware (Standard Instruments, Micro controllers, Smart
Instrumentation)
This category is essentially hardware with onboard firmware that cannot be programmed by
users but can be configured to set up a run-time environment and process parameters.
Custom firmware should be considered Category 5.
Typical examples: Printer, Barcode Reader, Check Weigher.
4.3. Category 3 Standard Software Packages (Commercial Off-The-Shelf or COTS)
COTS packages are items that are exposed to high volume use in the marketplace, such
that validation of the package itself is not required. COTS packages are not configured to
define the business or manufacturing process, apart from establishing the run-time
environment (e.g. network and printer connections). Process parameters may be input into
the application. Supplier audits may be needed for highly critical or complex applications or
where experience with the application is limited.
Typical examples: Excel, Word (documents, used as word processors),
Artwork Generation packages,
Statistical Analysis packages,
and Diagnostic tools,
4.4. Category 4 Configurable Software Packages
These packages are also widely-used but provide the ability for significant tailoring of
functionality to suit the specific requirements of a business or process. The package
provides a number of standard modules, functions and interfaces which can be tuned,
selected or assembled as required. The standard elements being configured would each
typically contain significant operational depth and their configuration would be a high-level
activity. (Some packages permit the development of fully customised modules. These
developments should be managed as Category 5.) Category 4 packages normally require a
vendor audit to be performed for critical and complex operations with emphasis on design
qualification of the package (documented evidence of a quality approach to system
development and structural testing). The outcome of the audit may dictate the testing
approach required at the user site, and this should form the basis of a validation rationale.
Typical examples: SCADA,
Building Management System
Unsophisticated Excel spreadsheets, e.g. Particulates results, Cleaning
criteria, Bio-burden graphs.
Autoclave Control System (as-standard from Original Equipment
Manufacturer but utilising a configuration file of cycles)
Filter Integrity Test System
This is not an approved copy unless stamped in red
File Location: Date Printed: Page 6 of 18
Standard Operating Procedure
Title: Impact Assessment for Computerised Systems
to lower levels should be assessed on the basis of their GAMP rating however their
interaction with higher levels within the Item must also be considered.
Note that the Data level has no GAMP rating. If this level however, has a GMP role it may
determine the overall Impact of the system (i.e. Direct). Examples of ratings for various
types of records are shown in Section 11. Data layers with GMP Impact require control
measures to preserve their documentation attributes (i.e. accuracy, authenticity, availability
and integrity). These control measures should be recorded on the Impact Assessment form
and included in the Validation Plan.
5. Overall Risk-Profile Classification
Combine the Impact rating and GAMP category to determine a Validation strategy (C number):
Impact Assessment (Criticality)
No Impact Indirect Impact Direct Impact
on GXP Functions on GXP Functions on GXP Functions
No impact on the Items that may affect the Items that have a direct
performance or performance or operation of effect on the
operation of GxP other Items which have performance or
GAMP Category Functions Direct Impact on GxP operation of GxP
(Complexity) Functions Functions
1. Operating
systems C1 Validation: C1 Validation: C1 Validation:
Record Version & Record Version & GEP Record Version & GEP
GEP Functional Functional Functional
2. Firmware
(Instruments C1 Validation: C1 Validation: C2 Validation:
and controllers) Record Version & Record Version & GEP Record Configuration
GEP Functional Functional and Version No & GEP
Functional
3. Standard
packages C1 Validation: C2 Validation: C3 Validation:
Record Version & Record Configuration and Minimal Functional
GEP Functional Version No & GEP
Functional
4. Configurable
packages C2 Validation: C3 Validation: C4 Validation:
Record Configuration Minimal Functional Some Functional
and Version No &
GEP Functional Minimal Structural
5. Custom-built
C3 Validation: C4 Validation: C5 Validation:
Minimal Functional Some Functional Extensive
Minimal Structural Functional
Extensive Structural
This is not an approved copy unless stamped in red
File Location: Date Printed: Page 8 of 18
Standard Operating Procedure
Title: Impact Assessment for Computerised Systems
ASSESSMENT COMPUTER VALIDATION REQUIREMENTS
Installation Qualification
Record name of operating system
List Software Version No.
List of Hardware
Configuration Setting - record version
Verification of source code availability
Review / Verification of Supplier Testing (includes Module Testing and
Software Integration Testing).
Structural Testing - Extensive (Source code inspection).
Acceptance Testing (e.g. FAT, SAT) and commissioning should be performed,
in line with Good Engineering Practices.
Operation Qualification Validation
Hardware Testing
Functional Testing (Extensive)
Performance Qualification Validation
Final User Testing
Validation Report
7.2. Examples Justifying a Non-standard Approach
On occasions the Validation strategy might vary from that in the above table. Variations may
be justified by business requirements or in response to risk. Some examples include:
Custom-built Firmware. Where purpose-built firmware is used it is more appropriate to treat
this at a higher GAMP level (eg GAMP 5).
Customised Alterations. Where an existing program is modified the overall rating would
likely be GAMP 5. The standard approach for this rating (e.g. Extensive Functional,
Extensive Structural) need not necessarily apply to the entire program. Rather, this higher
level of validation attention should be focused on the sections being altered and their
interface with the remaining program. The unaffected areas of software may be treated
according to the rating it would have received without the customisation. Such an approach
relies on the changes being well constrained and the original program being well described.
Copies of Customised Software. Where customised code is re-used it may be possible to
refer to some previous test results without repeating these tests. For this to be appropriate
the requirements of the original and new systems must be highly similar. Typically, the need
for test duplication varies with the level of detail being assessed; low-level tests (i.e. sub-
routine functions) are less likely to require repetition than high-level tests (i.e. overall system
operation). Similarly, modules that are commonly-used within a program do not require
detailed testing with all input and output combinations.
Supplier Quality Systems. Where a Vendor Audit demonstrates that a supplier has a well-
developed Quality System, the extent of confirmatory testing required to be generated by
the site can be reduced. Tests recorded on protocols developed by suppliers do not require
copying to site formats (so long as the content is appropriate). Conversely, where there is
reason to be concerned about the assurance provided by a supplier, additional testing and
input by the site may be necessary. For maximum benefit, any extra involvement from the
site should be provided as early as possible within the Development Lifecycle.
Other Compliance Requirements. Where assurance of software performance is required for
other reasons (e.g. compliance with EHS regulations) additional testing might be
considered. Such testing may utilise the formats and structures of Validation protocols, as
appropriate.
This is not an approved copy unless stamped in red
File Location: Date Printed: Page 12 of 18
Standard Operating Procedure
Title: Impact Assessment for Computerised Systems
10. Typical Product Quality Characteristics
Examples only
Quality Attribute Tablet / Solid Dose Product Sterile Liquid Product
Identity Correct label Correct label
Correct packaging material Correct packaging material
Correct packaging components Correct packaging components
Correct Batch & Expiry details Correct Batch & Expiry details
Readable Batch & Expiry details Readable Batch & Expiry details
Correct patient information Correct patient information
Safety Reject segregation Reject segregation
Package security & integrity Package security & integrity
Stable product Stable product
Container closure integrity
Efficacy Availability (Disintegration / Strength / Concentration
dissolution)
Correct dose Correct dose
Physical integrity
Purity Chemical purity Chemical purity
Sterility
Apyrogenicity
Low particle count
Biological purity
Evidence Batch Records Batch Records
In-process testing In-process testing
Materials Specifications Materials Specifications
Laboratory Test Results Laboratory Test Results
Pack appearance (some markets) Pack appearance (some markets)
Traceable product components Traceable product components
Process stability Process stability
Process Instructions Process Instructions
Operating Procedures (some) Operating Procedures (some)
Product Distribution Records Product Distribution Records
This is not an approved copy unless stamped in red
File Location: Date Printed: Page 16 of 18
Standard Operating Procedure
Title: Impact Assessment for Computerised Systems
Type of Record Impact Comment / Justification
Monitoring records Direct, The Impact of these records depends on the criticality of
Indirect, parameters being monitored. For example, microbiological
No Impact and environmental performance could be Direct Impact (for a
sterile area) or Indirect Impact (for secondary packaging and
warehouse areas); while building management records of
office environments are of No Impact. Management reports on
the progress of validation, internal audits or other
investigations are of No Impact.
Planning documents Indirect, This document type can have different impacts. Some
No Impact schedules (e.g. cleaning, calibration, or maintenance) are of
interest to inspectors as evidence of GMP compliance. These
can have Indirect Impact as absence of such plans may
increase the risk of companies not having the GMP required
results. Other plans for management information, such as
project plans, have No Impact.
QA Audits, Direct, QA investigations, required by GMP to assess / improve an
Investigations Indirect organisations Quality Management System, usually do not
(including Deviations) affect single product quality decisions and are Indirect Impact.
However, an investigation (e.g. into an Out-Of-Specification)
used in a batch release decision has Direct Impact.
Quality Control Direct These records are used for critical release decisions
Analysis results
Patient Records Indirect Traceability of Clinical Trial data.
Regulatory Direct Sets product performance criteria and manufacturing
Submissions standards.
Standard Operating Direct, The criticality of SOPs depends on the nature of the SOP
Procedures (SOPs) Indirect, concerned. For example, SOPs that govern the validation of
No Impact computerised systems should not be considered as critical as
SOPs that govern Quality Control operations (including final
batch release). The criticality of a set of SOPs should be the
same as the most critical GMP records they manage.
Training / personnel Direct, While these records (and definitions of roles and
records. Indirect responsibilities) are GMP requirements most have limited
impact on product quality. Critical decisions typically follow
SOPs and involve more than one responsible person. Some
specific training qualifications have Direct Impact on batch
release - eg Sterile Operator, Authorised Person.
Validation documents Indirect Examples include Validation Plan, Protocols, Results and
Reports. While the correct function of equipment and systems
has immediate potential to create harmful product, GMPs
require Quality Control checks before product release.
12. Summery of Changes
Version # Revision History
VAL-045 New
End of Procedure
This is not an approved copy unless stamped in red
File Location: Date Printed: Page 18 of 18