Validation Protocol Execution Tips – Top 10

So you’ve finally reached the stage where you are now free to execute your validation protocol after months of development, review and approval. It would be a real shame at this stage if the execution went horribly wrong and the protocol was strewn with errors and deviations….after all this hard work this is what you will be judged on so it’s critical that you take the execution aspect very seriously.

Below are my top 10 tips to help you achieve execution success!

Tip 1: Develop the Protocol from Approved Design Specifications

Ensure that the protocol has been written from an approved design document. There’s no point in developing tests from an unapproved FS (Functional Specification) or DS (Design Specification) if the design is going to change. Your protocol needs to reflect what is in your approved design document.

This is especially significant when developing software validation test scripts, for equipment qualification the tests may come from approved OQ and PQ protocols that are not linked to requirements….the we’ve always done it this way approach!

Tip 2: Test Objectives Clearly Defined

The tests should be written in a manner where the objectives are clearly defined and each test is unambiguous. Having well defined requirements will assist with this but if you don’t you should make every effort possible to craft each test step in a manner that is easy to understand.

Remember if may not always be you who are executing the script you developed so keep that in mind throughout the development process.

Tip 3: Sufficient Space in the Protocol

If you are not executing your protocol electronically then you are using the traditional paper approach of handwriting on the paper print-out. If this is the case make sure that you leave sufficient space in the expected result columns to add sufficient test results.

There is nothing more frustrating for the reviews to have to use a magnifying glass to see what you have written.

Tip 4: Tester needs to have Testing Knowledge

Has the person who is developing the test script prior experience with this type of work? Testing is a skill and is one that is often overlooked. Great testers don’t just test the obvious functions they think outside the box and ensure other angles aside from the intended use are covered.

Tip 5: Time to Dry Run

It may not always to be possible to dry run your test script before the official execution but good project managers will factor in dry run executions as part of the project timelines. It’s amazing what you will find wrong with your script if you take the time to dry run it before official execution.

This may seem like extra work at the time but it will save you a huge amount of work overall. Treat the dry run as a real run, document all of your test results like you would the real run (You’ll be surprised what you find!)

Tip 6: Make Sure the QA Review is not just a Formatting Review

Does the QA person pre-approving your protocol really understand what they are reviewing? I have seen it time and time again where the QA review turns into a formatting review where you get the document back with only formatting changes. If that is the case either your protocol is perfect (which is never the case) or the QA person is not technical enough to really understand what is been tested.

For example if you are testing for Part 11 compliance does the QA person know what that means?

Tip 7: Execute in the Morning

This may seem like an obvious tip but try and schedule your execution times in the morning when you are fresh and not rushing to get home. Give yourself sufficient time to execute, this isn’t a speed test you need to take a quality driven approach to your executions.

Tip 8: Remember to Read the Pre-Requisite Section Carefully

Ensure that all of the pre-requisites have been performed before execution. Many protocols have a pre-requisite section where set-up data needs to be configured before the actual testing can commence.

There is little point in rushing through the protocol only to find out mid-way through the test that you forget to input the set-up data that allows you to execute the test.

Tip 9: Easily Accessible Deviations Forms

Deviations are part and parcel of any validation execution, its human nature to make mistakes and making mistakes with validation protocols is no different. Whether they come from the actual or expected results or from not executing a test correctly it is good practice to have a bundle of deviation forms at hand to populate at the time the deviation occurred.

This will ensure that you remember exactly what the issues were instead of trying to recall later.

Tip 10: Attach Test Evidence Correctly

Usually test evidence needs to be generated to support validation executions, from print-outs of equipment pressure and temperatures to screen-shots of software applications. Ensure that each additional print-out or attachment is numbered correctly and also references the protocol number.

You need to be able to pass the drop test!

0
shares

  • davidj

    Good article, although I would say that you dont always have the luxury of starting the protocol when it is convenient for you. I have found that when performing OQ and PQ on plant, you will need trained operatives available (as you wont be allowed to work on the equipment unspervised) and you have to work around them and not the other way round! I have had to execute protocols at the end of the working day, and I know people who have had to work during the night, as it was the only time operators were available!

    Would also say that for point 5, you would have the protocol reviewed and approved anyway under GMP. You must NEVER use any unapproved qualification documents!

    A tip:
    When working on a GMP plant ensure that you have been sufficiently trained to be allowed on plant without supervision (ie gowning procedures) as that can be a real pain if operators are busy and cant spare the time to escort and supervise you. Are you fully trained in the company’s procedures for writing and executing protocols, and deviations? If not – forget doing any validation work!

  • Muzaffer

    It is a very nice article, as it reminds me actually the things we got during execution. We should do the dry run as real run and must be reviewed by any one else.

  • rama

    Very nice article . definately useful for the validation perfromers .

  • matt

    Very practical advise – especially tips 2,5,8 and 10.

    Thanks

  • john saenz

    One often forgetten point, but in my opinion important point is ORGANIZATION…that is create a binder or package to pre define what you are to collect in the field…i.e. cal certs, screen shots, software back ups, test results sections….often during execution, there is not enough time to ensure that the correct screen shots, or data sheets are collected or data sheets are are fully completed, or BI request / Lab request paperwork is not completed,
    Organize the binder…it will amke for a much easier report closure session
    john saenz

  • Koushik Rajaram

    It is a very nice article, informative and concise. Would you mind to publish/share information about how to prepare equipment qualification and process validation protocols and what are the guidelines which we need to refer to before preparing such a protocol and report.

  • shital y

    Pls review this site:http://www.hc-sc.gc.ca/dhp-mps/compli-conform/gmp-bpf/validation/gui_29-eng.php and references listed below it may help.
    Moreover , koushik as you have not specified for what type process validation eg. dosage form its hard to guide you further.

Similar articles:

The Difference Between Prospective, Concurrent and Retrospective Validation

Unless you’re starting a new company you will need to plan on a variety of approaches.

Prospective validation occurs before the system is used in production, concurrent validation occurs simultaneously with production, and retrospective validation occurs after production use has occurred.

In this article we will discuss all three and also discuss the role the master validation plan (MVP) performs for each one.

1. Prospective Validation

Prospective validation is establishing documented evidence, prior to process implementation, that a system performs as is intended, based on pre-planned protocols.

This is the preferred approach.

Production is not started until all validation activities are completed.

The MVP need not go into much detail about this approach since it’s the standard method, however, prospective validation follows a step wise process illustrated here.

The process commences with the development of a Validation Plan and then passes through the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed which are followed by a final report.

After which the instrument or equipment will be subject to preventative maintenance and requalification on a routine basis.

Periodic Basis

On a periodic basis all instrumentation and equipment should be reviewed. This review is intended to identify any gaps which may have developed between the time it was last qualified and current requirements.

If any gaps are identified a remediation plan will be developed and the process will start again.

The MVP

The MVP may need to describe what is done with product produced during prospective validation. Typically, it is either scrapped or marked not for use or sale.

The product may be suitable for additional engineering testing or demonstrations, but appropriate efforts need to be made to ensure this product does not enter the supply chain.

Ideally, all validation is done prospectively; i.e., the system is validated before use. However, there are cases and conditions which may prevent this.

2. Concurrent Validation

Concurrent validation is used to establish documented evidence that a facility and process will perform as they are intended, based on information generated during actual use of the process.

In exceptional circumstances (for example, in a case of immediate and urgent public health need) validation may need to be conducted in parallel with routine production. The MVP needs to define how product is managed throughout the process.

Typically, the product batches are quarantined until they can be demonstrated (QC analysis) to meet specifications.

The Right Decision?

The decision to perform concurrent validation should not be made in a vacuum. All stakeholders including management, Quality Assurance and the government regulatory agencies should all agree that concurrent validation is an acceptable approach for the system under consideration.

As always the principal requirement is patient safety is not compromised. The rationale to conduct concurrent validation should be documented along with the agreement to do so by all the stakeholders. This can be part of the Validation Plan or documented as a deviation.

The Process

The concurrent validation process is identical to that of prospective validation. The process starts with the development of a Validation Plan, followed by the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed, ending with a final report.

Again, routine preventative maintenance, requalification and periodic review are performed.

3. Retrospective Validation

Retrospective validation is validating a system that has been operating for some time. There are various schools of thought on how to approach retrospective validation. Some may feel that a full-blown validation is required to assure the system is functioning properly.

Others may feel that since the system has been in use, presumably without issues, validation is not necessary and a memo to file justifying why validation is not necessary may be issued.

Doing a full validation may not be required, since you already have proof that the system functions as required – at least in the situations in which production was conducted. Doing nothing, though, is a risk.

It’s likely that the controls haven’t been challenged so there may be some hidden flaws that haven’t been identified that could lead to non-conforming product, hazardous operating conditions, extended delays, etc.

Historical Data

Historical data can certainly be used to support validation. For example, if there is detailed and statistically-significant evidence that production runs are well controlled you could rationalize and justify not doing full validation.

During retrospective validation, it’s advisable that existing product be quarantined, and production put on hold until validation is complete.

As an exception, producing product as part of the validation exercise would follow concurrent validation. This may not be practical since product may have already been distributed, but caution is advised for the reasons outlined.

General Process

The general process for retrospective validation follows the same process as for prospective and concurrent validation except DQ is seldom performed, as the system has already been in use for some time.

Instead a survey and review of available information is performed. This normally occurs before the validation plan is created.

The MVP should also provide guidance on managing inventory during retrospective validation.

One Major Issue

One potential major problem that can occur with retrospective validation the determination of what action should be taken if an issue is found with the system during retrospective validation?

As with everything else, a risk-based decision is warranted. This could be anything from product recall, to customer notifications, to just documenting the justification of the decision why nothing was done.

Again, the MVP should provide guidance on dealing with situations concerning out of specification conditions revealed during retrospective validation, which should also definitely include involving regulatory support.

12
shares

Similar articles:

International Conference on Harmonization (ICH) in a Nutshell [Video]

The ICH is a common project of regulatory authorities and representatives of pharmaceutical industries in EU, Japan and the US.

Its mission is to discuss issues related to approval and marketing authorization of new medicinal products in these three regions.

Namely, the six parties involved are the:

  • European Commission
  • The European Federation of Pharmaceutical Industry Associations
  • The Japanese Ministry of Health and Welfare
  • The Japanese Pharmaceutical Manufacturers Association
  • The US FDA
  • The US Pharmaceutical Manufacturers Association

In addition to these principals, there are three observers representing non-ICH countries:

  • World Health Organisation (WHO)
  • The European Free Trade Association (EFTA)
  • Health Canada

Primary Objective

The primary objective of ICH is to harmonize regulatory requirements related to quality, safety and efficacy of medicinal products and to support mutual recognitions between the three regulatory authorities.

Exchange of Data

Mutual recognitions are based on the exchange of data and assessment reports which are intended to eliminate duplicative testing and inspection procedures, and thus decrease costs of, and speed up, the introduction of new medicinal products to the markets.

cGMP – Cases from History and the Regulations

If you would like to learn more about the regulations governing the GMP’s click here.

9
shares

TOP

Similar articles: