+ All Categories
Home > Documents > Risk_Based Approach to Validation - TPPL 14 10 10

Risk_Based Approach to Validation - TPPL 14 10 10

Date post: 24-Jun-2015
Category:
Upload: milind-jog
View: 134 times
Download: 0 times
Share this document with a friend
Popular Tags:
19
Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology Page 1 of 1 104/105, Kaalika Tower, opp Pratap Cinema, Kolbad Road, Thane (W). 400604. India. Tel: +91-22-25475532 / 5054. www.technolutions.co.in The need for Validation Risks are a constant companion of every activity and decision that we take (or do not take!). Pharma business is no exception. It is the manufacturer‟s responsibility, legal as well as moral, to ensure that the patient receives the products that are safe, effective and easy to use at an affordable cost. Whether we work in production or QC or engineering, our prime or indeed the sole objective is to consistently manufacture products of the required quality at the lowest possible cost to the manufacturer and hence to the patient. Validation is essential for the achievement of this objective. The USFDA defines process validation as “establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes”. Validation and qualification are essentially the same concept. Validation is the documented act of proving that any procedure, process, equipment, material, activity or system actually leads to the expected results. Qualification is the act of planning, carrying out and recording of tests on equipment and systems that form part of the validation process, in order to demonstrate that it will perform as intended. Validation, therefore, refers to the overall concept of validation, including process validation, while qualification refers to the validation part of equipment and systems. In this sense, qualification is part of validation.
Transcript
Page 1: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology Page 1 of 1

104/105, Kaalika Tower, opp Pratap Cinema, Kolbad Road,

Thane (W). 400604. India. Tel: +91-22-25475532 / 5054.

www.technolutions.co.in

The need for Validation

Risks are a constant companion of every activity and decision that we take (or do not take!).

Pharma business is no exception.

It is the manufacturer‟s responsibility, legal as well as moral, to ensure that the patient

receives the products that are safe, effective and easy to use at an affordable cost.

Whether we work in production or QC or engineering, our prime or indeed the sole

objective is to consistently manufacture products of the required quality at the lowest

possible cost to the manufacturer and hence to the patient.

Validation is essential for the achievement of this objective.

The USFDA defines process validation as “establishing documented evidence which

provides a high degree of assurance that a specific process will consistently produce a

product meeting its predetermined specifications and quality attributes”.

Validation and qualification are essentially the same concept. Validation is the documented act of proving that any procedure, process, equipment, material, activity or system actually leads to the expected results. Qualification is the act of planning, carrying out and recording of tests on equipment and systems that form part of the validation process, in order to demonstrate that it will perform as intended. Validation, therefore, refers to the overall concept of validation, including process validation, while qualification refers to the validation part of equipment and systems. In this sense, qualification is part of validation.

Jog
Note
www.tppl.net.in [email protected]
Page 2: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 2 of 2

There are three reasons for validation:

1. Validation is essential for assurance of quality: Validation implies that a process is well understood and is in a state of control. GMPs and validation, two concepts that cannot be separated, are essential to QA

2. It is effective in reducing costs: A validated process is a more efficient process that produces less reworks, rejects and wastage.

3. It is a regulatory requirement: Validation is an integral part of GMPs. Compliance with validation requirements is necessary for obtaining approval to manufacture and to introduce new products

The Validation activities are divided into the following steps,

1) Validation Master Plan (VMP)

2) User Requirement Specification (URS)

3) Risk Assessment (RA)

4) Design Qualification (DQ)

5) Installation Qualification (IQ)

6) Operational Qualification (OQ)

7) Performance Qualification (PQ)

8) Process Validation (PV)

9) Cleaning Validation (CV)

10) Computer Validation (CSV) & Automation Systems

11) Analytical method validation

12) Validation Report (VR)

13) Revalidation (ReV)

A schematic representation of the interrelationships of these components of

Validation Philosophy is given below.

Page 3: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 3 of 3

Page 4: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 4 of 4

Now consider your facility. Try to calculate the scope of the validation activity and the time frame and the resources available. Now try to put a plan for implementation. Also remember that it is a legal requirement.

You all shall agree that it now looks much bigger a job than anticipated (and hoped).

When faced with this situation, people tackle it in a number of ways:

1. Validate everything (the classic “Carpet Bombing approach”).

2. Validate nothing (not many of this type exist, hopefully)

3. Validate what seems important.

4. Validate scientifically and systematically.

The people who belong to the group 4 above shall be our role models.

The „Risk Assessment‟ process should start with questioning and finding answers to1:

Does this system require validation?

If yes, how much?

What aspects of the system or process are critical to product and patient safety?

What aspects of the system or process are critical to business?

The questioning is important because it is impractical to completely test every aspect of the system. We should therefore find out and focus our efforts on the critical areas.

Risk Analysis (RA) as a tool

Risk Analyses like Failure Mode and Effects Analysis (FMEA) have been carried out in the

industry in the field of safety engineering.

For a long time, such analyses were only used in high-risk industries (aerospace, nuclear

engineering, etc.).

As the benefits of RA became apparent, pharma industry started thinking, could RA be put to

use in the Pharma industry for the Validation activity?

USFDA thought so and in September 2004, published “Pharmaceutical CGMPs for the Twenty-First Century—A Risk-Based Approach”.

But even before that, in March 2001, the ISPE published the “Pharmaceutical Engineering Guides for New and Renovated Facilities: Volume 5 – Commissioning and Qualification”2.

The USFDA had actively cooperated with ISPE in the development of this guide and virtually endorsed the guide.

Page 5: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 5 of 5

The goal of the RA should be elimination of duplication of effort and costly practices of:

Repeating qualification steps during process validation

Qualifying systems that require only commissioning

Generating insufficient or excessive documentation

Excessively long project schedules and

Delays which can result in product supply interruptions or delayed product launches

The basic philosophy2 should be:

1. Good Engineering Practice (GEP) makes a significant contribution to meeting the regulatory demands.

2. GEP is a satisfactory approach for “Indirect” and “No Impact” systems.

3. For systems having a “Direct Impact” on product quality, supplementary Qualification Practices (in addition to GEP and commissioning) are required to fully address the pharma industry demands.

The methodology used in this baseline guide is “Qualitative” and not “Quantitative” in nature.

In 2001 ISPE also published “GAMP guide for Validation of Automated Systems (GAMP4)”.

This guide described the “Risk Assessment” process in great detail. This was a “semi quantitative” method.

We have followed the same philosophy in the RA process but what we have tried new is further simplification of the RA process and full quantitation of the process.

The model we have created is easy to understand and easy to use for all the stake holders. This results in rapid and unbiased processing of the data by the stake holders and because the decision making is embedded in the system, personal bias in decisions is removed.

Before we embark on the process, let us categorise systems based on their impact on product quality2.

1. A “Direct Impact” (DI) system has a direct impact on product quality. Such systems are commissioned in line with GEP and in addition, are subjected to Qualification Practices.

2. An “Indirect Impact” (IDI) system does not have a direct impact on product quality, but supports a “Direct Impact” system. Such systems are designed and commissioned following GEP only.

(The potable water system has no direct impact on product quality. However, it provides input to the Purified Water system, a “Direct Impact” system. It is therefore an “Indirect Impact” system. The performance of the potable water system has a potential to affect the performance of the Purified Water system and hence the interfaces between these two systems need to be carefully assessed.)

It is important to ensure that the DI systems could detect or prevent a product quality threatening problem with an “Indirect Impact” system linked to it.

3. A “No Impact” (NI) system will not have any impact, either directly or indirectly, on product quality. Such systems are designed and commissioned following GEP only.

Page 6: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 6 of 6

Security Cabin

No Impact Systems

Fire Fighting System

ETP

Gardening

Chilled water

Cooled Water

Soft Water

Plant Steam

Compressed Air Indirect Impact Systems (The design and use of these systems may affect their impact)

Purified Water System

Direct Impact Systems

Autoclave

Tunnel Steriliser

Process Area HVAC

WFI System

Pure Steam Generator

N2 Generator System

Critical Component: A component within a system whose operation, contact, data, control,

alarm, or failure may have a direct impact on the quality of the product.

With these tools in hand, let us now embark on the process of Risk Assessment (RA).

The Risk Assessment Process

Before we start the RA process, we should identify the systems that impact quality so that

our resources are allocated and used effectively. This exercise is called System Impact

Assessment (SIA) Exercise.

System level Impact Assessment. This will divide the identified systems in to DI, IDI and

NI groups.

Page 7: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 7 of 7

Remember that we have decided to do this exercise scientifically and systematically. The

results are open to scrutiny by the auditors and must be able stand up to it.

I know that an old hand performing this exercise shall intuitively „know‟ the categorization

for a number of systems without going through the formalities. But by definition, validation

is “… documented evidence…” and hence we have to document the decision making

process with the rationale behind it.

So here is how we shall proceed:

1. Identify systems. A system is an organization of engineering components that have a

defined operational function (e.g. piping, instrumentation, equipment, facilities,

computer hardware/ software etc).

Make a „comprehensive‟ list of all the systems without any bias (remember the

adage, “Not Guilty” [or “Guilty”, based on your inclination, I want to be „Unbiased‟

here] unless proved otherwise).

Clearly define the scope of each system. e.g.

Chilled Water system

Clean Steam

WFI

HVAC to process areas

Effluent Treatment Plant (ETP)

Tablet presses

Autoclave

Fire Protection

Once defined, these systems should form the basis of a project referencing system or

be integrated within it.

2. Define the system boundaries. A System Boundary is a limit drawn around a system

to logically define what is, and is not, included in the system.

The method for SIA is illustrated below graphically2.

Page 8: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 8 of 8

Ask the following six questions to the system. If the answer is yes for even one question, it is

a DI system.

1. Does the system have a direct contact with the product (air quality, Material of

Construction-MoC)?

2. Does the system provide or produce an in-process material or an ingredient /

excipient or solvent, which forms a part of the final product formulation (e.g.

Purified Water, WFI, N2 Generating System)?

3. Is the system used in cleaning or sterilizing or depyrogenation (e.g. DHS, Autoclave,

Tunnel Sterilizer, Clean Steam Generator)?

4. Does the system preserve product status (e.g. N2)?

5. Does the system produce data which is used to accept or reject product (e.g.

electronic batch recording system, or critical process parameter chart recorder)?

6. Is the system a process control system (e.g. PLC, Supervisory Control And Data

Acquisition - SCADA or distributed control system - DCS) that may affect product

quality and for which there is no system for independent verification of control

system performance in place.

Page 9: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 9 of 9

If answers to all the six questions are “NO”, ask the 7th question:

7. Is the system connected to a Direct Impact System?

If answer is “NO” it is a No Impact (NI) system.

If the answer is “Yes” it is an Indirect Impact (IDI) system.

It is strongly recommended, even should be made mandatory by the Validation Steering

Committee (VSC) that this exercise is performed jointly by all the stake holders. It may take

several sittings but the decision on each system must be arrived at jointly and

simultaneously.

Note also that there could be an element of variation of interpretation of answers to a

particular question and there could be disagreements. There shall be debates and long

arguments especially in the initial stages when stake holders are getting a grip on the

methodology. This should be encouraged as brainstormings shall also be a learning process

especially for the juniors in the committee.

At the end of this exercise, about 20-30% systems may get eliminated from the validation

scope altogether.

Risk Assessment (RA) exercise

We propose a two stage model.

Stage 1: Component level Criticality Assessment for the DI systems. This will divide the

components in to two groups - components critical to quality and components not critical to

quality.

For the IDI systems, only those components of the system that are part of the „indirect‟

portion of the IDI system are assessed and categorised similarly.

Stage 2: Evaluate the quality critical components for the risk to product quality. Identify all

the possible failure modes associated with the component. Evaluate the impact of each

failure mode product quality to arrive at the level of validation effort deserved by it. Identify

the proper stage of the qualification at which the failure mode would be most appropriately

addressed.

At the end of this very comprehensive and systematic exercise you shall have your

qualification matrix ready.

Page 10: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 10 of 10

If this exercise is performed in time, it will also tell the VSC and the management about the

scope of validation, it‟s approximate time lines and the resources required at various stages

of the project.

Stage 1: Component Criticality Assessment Process (CCA):

The components within the DI and IDI systems should be assessed for their criticality to

product quality.

Before you start this exercise you should have with you the Design Specification (DS) and

Functional Specification (FS) and the Piping and Instrumentation Diagrams (P & ID) of the

equipment / system from the concerned vendor.

With the help of these documents, prepare a complete and unbiased list of all the

components of the DI system.

Take the help of the experienced project / maintenance engineers or the vendor to

understand the “Contact” interpretation.

Ask the following seven questions to each component. If the answer is yes for even one

question, it is a critical component.

1. Is the component used to demonstrate compliance with the registered process (e.g.

Chart recorder of stability chamber, temp recorder of steriliser etc.)?

2. Does normal operation or control of the component have a direct effect on product

quality (e. g. RPM of a homogeniser)?

3. Does the failure or alarm of the component have a direct effect on product quality or

efficacy (e.g. Temperature controller or indicator)?

4. Is the info from this component recorded as part of the batch record, lot release data,

or other GMP related documentation (e.g. Temp. or pH indicator , online check

weigher, online particle analyser etc.)?

5. Does the component have direct contact with product or product components (e.g.

pH meter probe, Pressure gauge, Tamping pin, Punches, Dies, Manufacturing vessel,

Syringes/pumps, silicone tubes etc.)?

6. Does the component control critical process elements that may affect product quality,

without independent verification of the control system performance (e.g. PLC)?

7. Is the component used to create or preserve a critical status of a system (e.g.

cryogenic storage system, Temp / RH controlled area for product storage.)?

Page 11: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 11 of 11

Stage 2: System Specific Risk Assessment

Qualification requirements are based on the criticality of the system functions to

product safety, identity, strength, purity and quality (SISPQ). These requirements are

next determined in a system specific risk assessment. The risk assessment can also be

extended to develop the qualifications matrix.

The system specific risk assessment is based on the system‟s Functional and Detailed

Design Specification.

The assessment lists each critical function, identified during the CCA, from the

functional specification. Each function or subsystem is determined to be critical,

major, minor, or cosmetic in affecting product quality, strength, identity, purity, and

efficacy.

Each function or subsystem or component is assessed for specific risks. Team

members determine the specific risks during a formal review of the system.

The system / component function is assessed for:

The probable type of failure(s) (Failure Modes)

The probability a failure would be detected

The impact on the quality from the function failing

The likelihood the function would fail

Each of these is determined assuming the “addressed via” is not in place i.e.

assuming that there is no solution to the problem.

Validation requirements are then determined by evaluating these levels and

combining them to determine a risk classification and the risk priority.

The validation method is determined by combining the assessment for the function

being evaluated with the risk priority. Risk Priority is determined from the Risk

Classification and the Probability of Detection. The team evaluates the design to

determine the probability of detection of the failure of the function. Risk

Classification is determined from the Risk Likelihood and the Customer Risk. The

Risk Likelihood and Customer risk are determined from the team‟s application of

established criteria to the design and function of the system.

Page 12: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 12 of 12

STEP 1

Evaluate the Risk Classification

For a GMP risk, the Risk Likelihood (frequency with which a failure occurs or can occur) is

of great importance. The more frequently a failure occurs, the higher is the risk. The

numerical values from 1 to 3 ascend with increasing likelihood.

Criteria for Evaluating Risk Classification

Risk Likelihood

Likelihood Numerical

Value assigned

Criterion Examples

Low 1

Occurrence could happen but not likely, probably once in 10,000 transactions.

Malfunction of a Differential Pressure (DP) gauge

Medium 2

Occurrence would not be unlikely, probably once in 1,000 transactions.

Controller failure, blown fuse

High 3

Is expected to occur, probably once in 100 transactions.

Machine jam, system fault, other typical production scenarios

Page 13: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 13 of 13

Customer Risk (internal/external) (Failure severity)

The severity of a failure is fundamental for its assessment. The severity is determined by the

implications of the failure. If, for example, a patient is harmed as a result of a failure, the

severity must be classified as high. On the other hand, if only a review of the technical

system is required, the severity is to be classified as low. The numerical values from 1 to 3

ascend with increasing severity.

Magnitude Numerical

Value assigned

Criterion

Low 1

The failure has no or slight impact on the technical operations, but no impact on the product quality. Customer would not notice effect in quality characteristics or attributes.

Medium 2 Slight deviations in the product specifications can occur requiring moderate measures (e.g. higher monitoring frequency in final testing and / or additional testing, etc.).

High 3

Significant deviations in the product quality can occur

requiring extensive measures (e.g. rejection of a batch, recall of

products, etc.).

Deviations can occur that might cause injury to consumers.

Risk Classification Risk Likelihood

(Business Impact) Customer Risk

(internal/external) Low Medium High

Low 1 (Level 1) 1 (Level 1) 2 (Level 2)

Medium 1 (Level 1) 2 (Level 2) 3 (Level 3)

High 2 (Level 2) 3 (Level 3) 3 (Level 3)

Page 14: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 14 of 14

STEP 2

Evaluate the Risk Priority

Probability of Detection

To determine the GMP risk, it is important to know if a failure, if it occurred, will be

detected or if it will only be noticed once it has reached the customer.

The easier it is to detect the failure, the lower is the risk. Therefore, the numerical value falls

from 3 to 1 the higher the probability of detection. D = 1 is thus a value that can only be

achieved if a fully automatic, 100% control is integrated in the production sequence. D = 3

means that a failure is not detected.

Magnitude Numerical

Value assigned

Criterion

High 1

100 % automatic control, coupled with an alarm system.

Operating failure that is almost certainly noticed or evident in the subsequent operations.

100% control, different analysis mechanisms, e.g. monitoring

of process parameters with alarm.

Obvious failure that is very probably detected in the subsequent operations.

Medium 2

Failure or fault would likely be detected.

Frequent in-process control or continuous monitoring required

/ available.

Easy to recognise failure, which is controlled.

Low 3

Defect characteristic that is difficult to recognise.

The failure or fault cannot be detected or is not routinely checked.

Page 15: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 15 of 15

Criteria for Evaluating System Specific Risks

Risk Priority Probability of Detection

Risk Classification High Medium Low

1 1 (Low Priority) 1 (Low Priority) 2 (Medium Priority)

2 1 (Low Priority) 2 (Medium Priority) 3 (High Priority)

3 2 (Medium Priority) 3 (High Priority) 3 (High Priority)

STEP 3

Assign a Validation Method

Measures to eliminate failures

Define measures to be implemented for the estimated Risk Priority i.e., define a failure

prevention program. Below are some examples of such measures:

* Introduction of specific tests in the appropriate qualification stage.

* Introduction of an additional quality check

* Changes to the facility to completely prevent certain failures

* Introduction of an additional check / control point in the context of preventative

maintenance

If you consider the above-mentioned examples of measures, one of the results of a detailed

RA could be a complete list of all necessary tests at different qualification stages.

That means this information is arrived at and is available at a very early stage and the course

of the project or the necessary resources can be planned more accurately.

In addition, time-consuming agreements with vendors at a later time are largely avoided

which, according to our experience, have a very hard impact on the project if the necessary

tests have not been defined at such an early stage.

Page 16: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 16 of 16

Criteria for Evaluating Functions

Assessment

Numerica

l Value

assigned

Criteria

Critical 3 1. Directly or indirectly affects product quality, identity, purity, strength, or efficacy.

2. Failure of the function or system would result in customer harm.

3. Usually the main function of the system

4. Direct or likely regulatory impact

5. Requires several layers of risk mitigation, designed into the system, in process checks, release testing or in standard operating procedures.

6. Operator safety would be in jeopardy if failure occurred

7. Customer complaints likely if function fails

Major 2 1. Failure of function causes system to fail or leads to significant production downtime

2. Failure of function results in product hold, significant amount of lost units, added inspection, etc

3. Failure of function has a potential to have a regulatory impact

4. The failure has a potential to cause customer harm

5. Operator safety would be a major concern, if failure occurred

6. Potential customer complaints if the function fails

Minor 1 1. Failure in extreme circumstances could cause customer harm

2. If failed, would result in occasional lost units

3. Unlikely possibility of regulatory impact

4. Operator safety would be of a minor concern, if failure occurred

5. Downtime would be negligible when failure occurs

6. Customer complaints would be unlikely

Page 17: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 17 of 17

Assessment

Numerica

l Value

assigned

Criteria

Cosmetic /

Operator

Enhancement

0.5 1. Adds cosmetic value only to product or system

2. Unlikely or no regulatory impact

3. Failure could in no way cause customer harm

4. Function helps operator job, function could be performed manually

5. Customer complaints could not be attributed to the functions failure

6. Minimal safety concern if equipment or system was misused

Validation Method

Validation Method

Risk Priority

System/Function Assessment

Low Priority Medium Priority High Priority

Cosmetic /

Operator

Enhancement

Minimal Verification Minimal Verification Verify Directly or

Indirectly

Minor Minimal Verification Verify Directly or

Indirectly Verify Directly

Major Verify Directly or

Indirectly Verify Directly

Verify Directly and Risk Mitigation

Critical Verify Directly Verify Directly and

Risk Mitigation Verify Directly and

Risk Mitigation

Page 18: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 18 of 18

Verify Directly and do Risk Mitigation – A specific test must reside in the protocol including verification test or evaluation of risk mitigation

Verify Directly – A specific test must reside in the protocol

Verify Directly or Indirectly – A specific test or an indirect verification, must reside in the protocol. Indirect verification may include verification of the system working i.e. the function must be documented as working.

Minimal Verification – Verification requires inspection, visual verification, testing, documentation, or other simplified means.

Risk Mitigation Strategies:

(Mitigation : The action of lessening in severity or intensity)

1. Modification of the process or system design elements to mitigate the risk.

Modify process design, e.g. introduce additional verification checks within the system design (software design).

Introduce external procedures, e.g. double checking (manual/ instrumental).

Modify product / system design

2. Modify project strategies

Revisit project structure and makeup, e.g. induct experienced staff, provide risk specific training.

3. Modify validation approach

Increase scope and / or level of testing applied during the various stages of the validation process.

Develop specialized testing designed to detect the failure.

4. Eliminate Risk:

Avoidance: The risks are so high that the system needs to be abandoned.

Page 19: Risk_Based Approach to Validation - TPPL 14 10 10

Risk Assessment and the Validation Process: A Risk Based Approach Quantitative evaluation methodology

Page 19 of 19

We have used this methodology coupled with our in-house software that we have successfully used to perform and record these activities over the last two years and have used it in the field also.

It has been our experience that it has reduced the subjectivity factor from the assessments, has increased buy in by the stake holders, has enhanced the confidence level of both the user and the auditors and at the same time has introduced a fun element in the exercise.

We would welcome comments and suggestions from our readers on the usability and suitability of this model.

Bibliography:

1. GAMP guide for validation of automated systems (GAMP4), December 2001.

2. Pharmaceutical Engineering Guides for New and Renovated Facilities: Volume 5 – Commissioning and Qualification, First Edition, March 2001.

==================================================== End of File


Recommended