Computer System Validation

This presentation is compiled by “ Drug Regulations” a
non profit organization which provides free online
resource to the Pharmaceutical Professional.
Visit http://www.drugregulations.org for latest
information from the world of Pharmaceuticals.

1/9/2014

1

This presentation is compiled from freely
available resources like the websites of FDA,
EMA, WHO.
 “Drug Regulations” is a non profit
organization which provides free online
 Visit http://www.drugregulations.org for
latest information from the world of
Pharmaceuticals.


Drug Regulations : Online
Resource for Latest Information

1/9/2014

2



This presentation describes approaches for software validation used
to automate laboratory research procedures, consolidate data

collection

and

analysis

and/or

run

sophisticated

QC

or

manufacturing operations.


Several approaches to software validation exist and may be
appropriate for a specific project.



The scope of any validation effort depends upon a number of factors



Origin of the software (custom vs. off-the-shelf) and





Size and complexity of the software,
Whether the functions are critical or non-critical in nature.

By effectively planning the process, validation time and resources
can be reduced while meeting regulatory requirements.
Drug Regulations : Online Resource for Latest
Information
1/9/2014

3



When equipment breaks, there are typically obvious and immediate
symptoms. Catastrophic results can often be avoided



Computer system defects can typically be very difficult to recognise
and severe problems may result without being detected until well
after the problem started



Drug companies, the airline industry, public utilities, nuclear power
plants and other industries where quality is critical have seen very
expensive consequences from improper computer system operation



Many of these consequences cost far more than the cost of
Computer Validation
Information
1/9/2014

4



Significant increase in the use of computer-

related systems in the Life Sciences industries.


These systems must satisfy cGMP requirements



Legitimate questions have been raised

concerning the scope and methods which should
be employed in validations.

Information
1/9/2014

5



Responsibility of the end-user to assure that

systems

used

are

in

compliance

with

applicable regulations.


Many users rely too heavily upon vendorsupplied information and test data to support
their system validation.

Information
1/9/2014

6



The extent of testing and the type of documentation

required to support validation is unclear


Difficult to delineate vendor and user responsibilities
when validating vendor-supplied systems.



Validation of computer-related systems is often
complex, and any number of alternate approaches
can be utilized.

Information
1/9/2014

7

In general, a combination of hardware, software,
people, documents, inputs, processing, and outputs
working together

Inputs

Software

Hardware

Controlling System
Controlled process

outputs

Equipment
Operating Procedures &
Documentation
People and Training

Information

• MRP/ERP system?

• LIMS system?
• Laboratory Instruments (e.g. Chromatography)?
• Automated manufacturing or packaging equipment?

• IT systems, including those supporting network and
infrastructure?
• Spreadsheets or databases?

Information
1/9/2014

9



FDA approach is based on three main elements: (Guidance)
◦ Part 11 will be interpreted narrowly

◦ Fewer records subject to part 11
◦ For those records that remain subject to part 11, FDA intends to exercise
enforcement discretion with regard to part 11 requirements for
 Validation
 Audit trails

 Record retention
 Record copying


Systems that were operational before the effective date of part
11 (also known as legacy systems)
◦ FDA will enforce all predicate rule requirements, including predicate rule
record and recordkeeping requirements.
Information
1/9/2014

10



FDA's exercise of enforcement discretion as

described in this guidance is limited to specified
part 11 requirements


FDA intends to enforce all other provisions of

part 11 including, but not limited to, certain
controls for closed systems in § 11.10.
◦ For example, FDA intends to enforce provisions related

to the following controls and requirements:
Information
1/9/2014

11

◦ Limiting system access to authorized individuals

◦ Use of operational system checks
◦ Use of authority checks
◦ Use of device checks

◦ Determination that persons who develop, maintain,
or use electronic systems have the education,
training, and experience to perform their assigned

tasks
Information
1/9/2014

12

◦ Appropriate controls over systems documentation

◦ Controls

for

open

systems

corresponding

to

controls for closed systems bulleted above (§
11.30)

◦ Requirements related to electronic signatures
 (e.g., §§ 11.50, 11.70, 11.100, 11.200, and 11.300)

Information
1/9/2014

13

◦ FDA intends to exercise enforcement discretion

regarding

specific

part

11

requirements

for

validation of computerized systems (§ 11.10(a) and
corresponding requirements in § 11.30).

Information
1/9/2014

14

◦ Take into account the impact the systems have on

ability to meet predicate rule requirements.
◦ Consider the impact those systems might have on
the accuracy, reliability, integrity, availability, and

authenticity of required records and signatures.
◦ Even if there is no predicate rule requirement to
validate a system, in some instances it may still be

important to validate the system.
Information
1/9/2014

15

◦ Base validation approach on
 A justified and documented risk assessment
 A determination of the potential of the system to affect
product quality and safety, and record integrity.

◦ Validation would not be important for a word
processor used only to generate SOPs.

Information
1/9/2014

16



Audit Trails
◦ Enforcement discretion related to computer-generated, timestamped audit trails (§ 11.10 (e), (k)(2) and any corresponding
requirement in §11.30).
◦ Also comply with all applicable predicate rule requirements

related to documentation
 Date (e.g., § 58.130(e))
 Time, or sequencing of events
 Requirements for ensuring that changes to records do not obscure

previous entries
Information
1/9/2014

17



Audit Trails
◦ Have them even if there are no predicate rule
requirements
 (for date, time, or sequence of events)

◦ Alternatively

have

other

physical,

logical,

or

procedural security measures in place.

Information
1/9/2014

18



Audit Trails
◦ Base your decision on
 The need to comply with predicate rule requirements
 A justified and documented risk assessment

 A determination of the potential effect on product
quality and safety and record integrity

Information
1/9/2014

19



Audit Trails
◦ Apply appropriate controls based on such an
assessment.
◦ Audit trails appropriate when records are
 Created
 Modified
 Deleted

Information
1/9/2014

20



Legacy Systems
◦ FDA to exercise enforcement discretion for systems
that otherwise were operational prior to August 20,
1997
◦ FDA not to take enforcement action if all the
following criteria are met for a specific system:

Information
1/9/2014

21



Legacy Systems …..contd
◦ The system was operational before the effective date.
◦ The system met all applicable predicate rule requirements before
the effective date.
◦ The

system

currently

meets

all

applicable

predicate

rule

requirements.
◦ You have documented evidence and justification that the system is
fit for its intended use (including having an acceptable level of
record security and integrity, if applicable).

Information
1/9/2014

22



Applies to all forms of computerised systems used as part of a
GMP regulated activities.



A computerised system is a set of software and hardware
components which together fulfil certain functionalities.



The application should be validated;



IT infrastructure should be qualified.



Where a computerised system replaces a manual operation, there
should be no resultant decrease in product quality, process
control or quality assurance.



There should be no increase in the overall risk of the process.

Information
1/9/2014

23



Validation
◦ Documentation and reports should
 Cover life cycle.
 Include change control

 Deviations during validation process

◦ Justify

standards,

protocols,

acceptance

criteria, procedures and records based on their risk

assessment.
Information
1/9/2014

24



Validation
◦ List all relevant systems and their GMP functionality
◦ For critical systems prepare
 System description
 Physical and logical arrangements
 Data flows
 Interfaces with other systems or processes
 Hardware and software pre-requisites

 Security measures
Information
1/9/2014

25



Validation
◦ Prepare user requirements Specifications
 Describe the required functions
 Base it on documented risk assessment and GMP

impact
 Make it traceable throughout the life-cycle

Information
1/9/2014

26



Validation
◦ Ensure that the system has been

developed in

accordance with Q M S
◦ Assess the supplier appropriately

◦ Ensure formal assessment and reporting of quality
& performance measures of bespoke or customised
computerised systems for life cycle.

Information
1/9/2014

27



Validation
◦ Demonstrate evidence of appropriate test methods
and test scenarios
 System (process) parameter limits

 Data limits
 Error handling

◦ Document adequacy of Automated testing tools and

test environments.
Information
1/9/2014

28



Validation
◦ If data are transferred to another data format or
system, validation should include checks that data
are not altered in value and/or meaning during this

migration process.

Information
1/9/2014

29

New Computer System

Existing Computer System

Def inesy stem
Function Structure

Def ine Sof tware

Def inesy stem
Function Structure

Design/Specif y
hardware
Qualif y Sy stem

Dev elop
Sof tware

I ns t all hardware

Rev iew operating
experience

Verif y Sof tware

Qualif y hardware

Test Indiv idual
Modules (Computer
Sy stem)

Data

Integrate
ComputerizedSy stem

Dataanaly sis

Test Integrated
modules
(Computerized
Sy stem)

Validation
Acceptance

Demonstratetotal
sy stem operation
(Computer-Related
Sy stem)

Ongoings y s t em ev aluat ion

Change

Conduct sy stem
testing (if needed)

F ileD oc um ent at ion

1/9/2014

30



Users play a key validation role in:
 Starting the process for new or existing systems

 Performing some major steps (e.g. Requirements)
 Writing and following operating procedure
 Maintaining the validated state while in use


Developers play a key role in many steps including:
 Design, coding, testing, changes, support



Support groups (IT, IR, SCS, Infrastructure):
 Maintain proper network environment
 Troubleshooting and maintenance

 Desktop and infrastructure control

Information
1/9/2014

31



QA and Validation
Author some major documents
Approve major documents that others write
Provide advice, training, auditing



Senior management for each group decides:
Which systems to buy or build
How much resource to make available

What risks are acceptable
Information
1/9/2014

32

Incorporate multi-functional participation



◦

Management Information Systems

◦

Developers

◦

Vendors

◦

Consultants

◦

Software QA

◦

Executive Management

Information
1/9/2014

33

Responsibilities



◦

Definition

◦

Planning

◦

Risk Assessment

◦

Evaluation of intended use

◦

Execution

◦

Documentation

◦

Review

◦

Approval

Information
1/9/2014

34



Have a combination of skill sets in the team



Include individuals who are experienced with
◦

Regulations

◦

Validation approaches

◦

Systems

◦

Processes

◦

Intended users

Information
1/9/2014

35

The level of documentation required depends on



◦

Complexity and intended use of the system;

◦

Origin of the software/system (vendor supplied or
developed internally).

◦

Examples

of

documentation

required

to

support

validation:

Information
1/9/2014

36



Validation SOPs and Policies



Project Management Plan



Validation Plan



Traceability Analysis



Risk (Hazard) Management



System Topology and



Specification and Documents

Plan


Computerized System Design

Installation Summaries

Configuration Management



Plan

Validation Protocols / Test

Case Procedures



Change Management Plan



IQ/OQ/PQ Reports



System Test Plans



Validation Reports



Computer-Related System
Requirements Specification

Information
1/9/2014

37

1. PLAN
Validation Activities

4. DESIGN & REVIEW
5. CONSTRUCT & TEST

2. DEFINE

6. INTEGRATE/INSTALL

Requirements

7. QUALIFY
8. EVALUATE

3. SELECT

Computerized System

Vendors

Information



Write and approve validation policies



Write specific SOPs for validation of Computer Systems



Develop protocols



Review test data



Write summary reports to assure the validation objectives are met



Use validation Project Plan to


Identify the systems to be included



Procedures to be followed



Timeline for a specific validation project
Information
1/9/2014

39

 Project resources and budget requirements


Validation Project Plan for
 Single system,
 Combination of systems

 Entire facility.


Establish specific responsibilities



Establish expectations for each validation

activity
Information
1/9/2014

40

 Create a document of high level goals of validation

 Specify

“what”

at

a

high

level

should

be

accomplished by the CSV
 Review available documentation
 Conduct interviews with users
 Map existing processes

Information
1/9/2014

41

 Initial focus on
 Functionality
 Operational and performance parameters
 Overall objectives for the validation effort

 Specify the requirement in detail to support testing
that requirement and defining acceptance criteria.
 Trace back protocols to each requirement
 via a Traceability Matrix
Information
1/9/2014

42

 Requirements traceable to Functional Specifications

and testing
 Unambiguous, clear, concise
 Testable and measurable

 Typically written and approved by end-user
 Basis for system acceptance testing
 Should be approved before the design review

Information
1/9/2014

43

 The highest level design document responding

directly to the User Requirements Specification
 All system inputs, outputs, and interfaces
 All functions and performance requirements

 Error definition and handling
 Ranges, limits, defaults
 Safety considerations

Information
1/9/2014

44

 Internal development group or an outside company.
 Consider vendor‟s ability to provide a system which can
be validated
 Selection Criteria
 Technical competency
 Qualified to supply
 Support for the proposed system
 Knowledge of validation requirements
 Experience in providing systems for cGMP applications
Information
1/9/2014

45

 Type of software being evaluated
 Type hardware being evaluated

 For off-the-shelf software and standard hardware
 History of customer satisfaction is of importance

 For custom developed systems
 Vendor‟s Quality Assurance System

Information
1/9/2014

46

Primary Responsibility
for Specification

Primary Responsibility
for Testing
Testing of the URS

More User involvement for custom
systems, less for packaged
Supplier

Functional
Specification

Performance
Qualification

Testing of the
Functional Specification

Design
Specification

Testing of the

Operation
Qualification

Installation
Qualification

Design Specification

Build System

Design
Specification

Unit Testing

Requirement Specification

System Testing

Information

User
More Supplier involvement for custom
systems, less for packaged

User Requirements
Specification

User

Supplier

 Computerized System Design Specification
 Document or a collection of documents
 Describes clearly and completely
 How the computerized system will Operate
 Satisfy Computer-Related System Requirements
Specification
 Both normal and abnormal operating conditions
 Information about the interfaces between the

computerized system and its operating environment
Information
1/9/2014

48

 Applies to both the computer system and the controlled
function/process
 joint responsibility of the vendor and user.
 Interfaces between the computerized system and its
operating environment.

 The Design Specification can not be developed until
the vendors and the specific hardware and software
have been selected.
Information
1/9/2014

49

 Defines how the system should meet the
requirements, including…
 Architecture AND interfaces
 All functions
 Data processing and integrity
 Security
 Backup, archive, and restoration
 disaster recovery

 Data definition
Information
1/9/2014

50

 Activity performed to verify that all deliverables

from Requirements and Design Phases are
produced and…
 are clear and concise

 are complete, current, and traceable
 electronic record and signatures addressed
 are testable

 show system fit for purpose
Information
1/9/2014

51

 Complete Design Review before starting

 Perform in accordance with written Programming
Standards
 Programming Standards should define appropriate
rules for writing source code (e.g. dead code,
structure, naming)

Information
1/9/2014

52

 The computerized system may be constructed by
developing custom software and hardware for the
application - or purchasing established products - or a
combination of both.

 From a validation perspective, custom developed
software and hardware require the greatest amount of
testing since they have never been proven effective.

Information
1/9/2014

53

 Three categories of software can be defined:
 System software
 Configurable software
 Application specific software

Information
1/9/2014

54

GAMP Classification
No

GAMP 4

GAMP 5

1

Operating Systems

Infrastructure Software

2

Firmware

No longer used

3

Standard Software Packages

Non configured Products

4

Configurable Software
Packages

Configured Products

5

Custom (bespoke) Software

Custom Applications

Information
1/9/2014

55

 These categories are not intended to be rigid but

they allow distinctions to be made so that
validation approaches are appropriate.

Information
1/9/2014

56

 Efficient Environment
 Defined processes
 Assigned responsibilities
 Planned audits

 Structured reviews
 Management controls

Information
1/9/2014

57

 Should be completed before formal testing

 Verify code complies with Programming Standards
 Check to ensure all pre-defined system
specifications are addressed
 Check for coding errors

Information
1/9/2014

58

„White Box‟ *
●

Unit Testing/Structural Testing

●

Low level

out

in

„Black Box‟ *
●

System & Acceptance testing

●

Functional Testing

●

Higher level
in

out

Manual Calculation

Information

 Define and justify the how the system will be

tested and how much
 Address how tests are traceable to specifications
 Testing approach should address
 Normal operation
 Entire design range, boundaries, stress
 Failure modes, including power failure

 Should be approved before testing starts
Information
1/9/2014

60

 Lists the test objective

 Traceable to specifications
 Lists test pre-requisites
 Reproducible test steps
 Clear acceptance criteria

Information
1/9/2014

61

 Record all raw data and derived results
 Ticks, „ok‟, „yes/no‟, „Pass/Fail‟ or similar are not valid
results
 Record a „Pass/Fail‟ conclusion of whether results met

acceptance criteria
 Signature and date of test performer
 Signature and date of test result approver

 References to incident log for failures
Information
1/9/2014

62

 Used to…
 Collate test result documentation
 Conclude each phase of testing
 Authorise subsequent testing phases

 Summarises the testing outcome, addresses test
failures

Information
1/9/2014

63

 Unit Testing
 Focuses verification effort on the smallest unit of software
design – the software component or module

 Integration Testing
 “If they all work individually, why do you doubt that they‟ll work
when we put them together?”
 The problem is “putting them together” – interfacing

 Data may be lost
 One module can have an inadvertent, adverse effect on
another; sub-function when combined
 Global data structure can present problems

Information
1/9/2014

64



Regression Testing
 Each time a new module is added as part of integration
testing, the software changes
 New data flow paths are established
 New I/O and control logic is invoked
 Regression testing is the re-execution of some subset of tests
that have already been conducted to ensure that changes have
not propagated unintended side effects

Information
1/9/2014

65



Smoke testing
 An integration testing
 Software components that have been translated into code are
integrated into a “build” – data files, libraries, reusable modules,
and engineered components that are required to implement one
or more product
 The intent of testing here is to uncover show stoppers – errors
that have the highest likelihood of throwing the software project
behind schedule
 The build is integrated with other builds and the entire product is
smoke tested daily
Information
1/9/2014

66



Unit Testing





An encapsulated class is the focus of unit testing

Operations within the class are, however, the smallest unit

Integration Testing


Thread based testing



Integrates a set of classes required to respond to one input or event for the
system



Used based testing


Begins the construction of the system by testing independent classes – use
very few if any server classes



Testing dependent classes – which use independent classes

Information
1/9/2014

67



Integration Testing
 Cluster Testing
 A cluster of collaborating classes (determined by
examining the CRC) to uncover errors in
collaboration

Information
1/9/2014

68

 Proper integration, installation and commissioning

of a computerized system is essential to the
successful qualification of the system.
 A packaged system may be integrated at the
vendors site
 More complex systems may be integrated at the

users site
Information
1/9/2014

69

 Data Load
 Operational and Support Plans (e.g.
SOP, training, service contracts, security, support
processes)

 Specify procedures employed in the Validation Plan.
 Specify responsibility for all tasks in the Validation Plan.
 Demonstrate proper installation of hardware & software

in Installation Qualification (IQ)
Information
1/9/2014

70

 Qualification is a procedure of testing and collecting data
to provide a high level of assurance that a computerized
system operates in accordance with the system
specification.
 Write & approve protocols in advance

 Protocols should specify the following
 Goals of testing
 Test methods
 Acceptance criteria
 Who is responsible for testing
Information
1/9/2014

71

 IQ (Installation Qualification) verifies that all aspects of
installing hardware and software meet specifications
and that user manuals, SOP‟s and backup procedures
are in place.

 OQ (Operational Qualification) verifies that the system
operates throughout its anticipated ranges according to
its specifications and identifies all important

parameters.
Information
1/9/2014

72

 PQ (Performance Qualification) verifies that a

system performs its intended function in
accordance with its specifications.
 Testing is completed on the entire system while
operating in its normal environment.

Information
1/9/2014

73

 In order to assure that the system remains in a validated state,
Performance Monitoring is required to continually test a system‟s
performance in executing defined processes:


Periodic calibration and maintenance



Continuous monitoring of critical parameters



Confirmation of security measures



Provisions for contingency planning, disaster recovery and personnel
training

 Change Control procedures must be established to keep a CRS in
a validated state during planned and unplanned changes.

Information
1/9/2014

74

Summary: Validation requirements for Software

Programme
overrides

Edits,
input
manipulation

Language

Name,
function

Software
identification

Fixed and
Variable
Set points

Input,
output

Information


Key aspects

Software
development

Software
security

Information


Function

Worst case

Documentation

Validation

Revalidation
Repeats

Information



This presentation was compiled from freely
available resources like the websites of FDA,
EMA, WHO.
 “Drug Regulations” is a non profit
organization which provides free online
 Visit http://www.drugregulations.org for
latest information from the world of
Pharmaceuticals.
Drug Regulations : Online
Resource for Latest Information

1/9/2014

78

Computer System Validation

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Computer System Validation

Similar a Computer System Validation (20)

Más de GMP EDUCATION : Not for Profit Organization

Más de GMP EDUCATION : Not for Profit Organization (20)

Último

Último (20)

Computer System Validation