Validation is a concept that has been evolving continuously since its first formal appearance in United States in 1978. The concept of validation has expanded through the years to encompass a wide range of activities which should take place at the conclusion of product development and at the beginning of commercial production. Validation is confirmation by examination and provision of objective evidence that the particular requirements for a specified intended use are fulfilled.

We all love validation!

Objective Measures

Validation is the overall expression for a sequence of activities in order to demonstrate and document that a specific product can be reliably manufactured by the designed process, usually, depending on the complexity of today’s pharmaceutical products, the manufacturer must ensure. Quality cannot be adequately assured merely by in-process and finished product inspection or testing so the firms should employ objective measures (e.g. validation) wherever feasible and meaningful to achieve adequate assurance.

Today we have different definitions of validation, which are as follows-

• Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality characteristics.
• The collection and evaluation of data, from the process design stage throughout production, which establishes scientific evidence that a process is capable of consistently delivering quality products.
• Validation is a process by which a procedure is evaluated to determine its efficacy and reliability for forensic casework analysis.

Why Validation is Important

The principles – Quality, Safety and Effectiveness must be designed and built in to the product, quality cannot be inspected or tested in the finished products and each step of the manufacturing process must be controlled to maximize the probability that the finished product meets all quality and design specifications. Now let me explain the specific importance of the validation – it is the concept detailed in quality guidelines of Product Lifecycle and with the help of which we can do the following:

• Determine the process parameters and necessary controls.
• To confirm the process design as capable of reproducible commercial manufacturing.
• Risk/Worst Case assessment. What is Worst Case? It is a set of conditions encompassing upper and lower limits and circumstances, including those within standard operating procedures, which pose the greatest change of process or product failure when compared to the ideal conditions.
• To provide ongoing assurance that the process remains in a state of control during routine production through quality procedures and continuous improvement initiatives.
• Quantitatively determine the variability of a process and its control.
• The variability within and between batches can be evaluated to determine the inner and intra-batch variability.
• Greater scrutiny of the process performance for development and deployment of process controls.
• Scientific study performed prior to implementing a change to a process can support the implementation of a change without revalidation.
• Safeguard and process against sources of variation which may not have been identified during the original process development.
• The most compelling reason to optimize and validate pharmaceutical productions and supporting processes and cost reduction.
• Control point in the context of preventive maintenance.
• Investigate deviations if any from established parameters.

Conclusion

Validation allows us to focus on our everyday business operations of making and selling quality products that also comply with regulatory requirements such as the FDA, Schedule M, etc. The industry which has adopted a lifecycle approach to the product development, validation and modern risk analysis tools can control critical process parameters. The companies can create a new standard of industry best practice by embracing the ability of validation practices which will lead in technological revolution.

Author

Rajkumar P. Patil
Sr. Production Officer
Mobile No. +919945642935
Mail ID. patilraj05@gmail.com

So your company has purchased a laser welder for production and you have been chosen to validate it. Where do you begin and what do you include? Below is a simple example for a seam or butt weld application.

Installation Qualification

The IQ must challenge the operation of the equipment to ensure it works as the manufacturer claims. Below are 3 key items to include in your report:

Motion test – To laser weld a seam or butt joint you must have a motion system to deliver the laser energy along a path. A verification of the motion system must be performed to verify speed, incremental movements, and adherence to the path.

Laser Welder Validation

Cover gas flow – Oxygen is detrimental to any weld bead and therefore you must supply an inert cover gas to the weld area to displace the surrounding atmosphere. A verification (or calibration) of the cover gas delivery mechanism must be performed to verify the flow rate and ensure it remains consistent over time.

Laser energy – Laser energy is the greatest contributor to weld penetration and you should understand how consistent the energy is over its range and how it varies from shot to shot. It is also important to understand the relationship between the displayed output and what is measured with an external measurement device. There will be some degree of error and it should be noted in the IQ.

Operational Qualification

Once the IQ is completed, the research and development phase can start. This is where you will determine your inputs and outputs, specifications and tolerances, and establish the basis of your operational qualification. By definition the OQ will test the limits of all welding and part interactions to ensure the end product meets your requirements. But before you assemble a huge multivariable DOE, ensure that any process inputs that can be controlled are controlled. The fewer variables you have the fewer samples you’ll need to make and the fewer tests you’ll need to perform. Below are a few key items, inputs and outputs, to include in your OQ. Make sure you produce enough parts to satisfy your confidence requirements.

Laser Weld Inputs

Focal length – Determine your optimal focal length and lock this variable in place. Set up all welding processes and fixtures to use the same focal range so this parameter never needs adjustment. This will reduce focal related welding issues and reduce the number of interactions in your DOE.

Cover gas flow limit – More is not always better. Chose a cover gas flow that works and lock this variable in place. Design your process such that all welds use the same flow so you do not have to adjust it for individual processes.

Laser Energy limits – The R&D phase will have established your energy requirements and now you must make OQ samples with low and high energy and multiple operators to show that welds made across the range meet the product requirements.

Laser Offset – You will never consistently weld on seam and therefore you must understand the effect of laser offset. Make OQ samples at min and max offset (as established in the R&D phase) and combine with laser energy to produce worst and best case samples. Offset and energy are key players in weld penetration and both must be challenged in the OQ.

Measurable Outputs

Weld Penetration – Weld penetration is a key output for monitoring weld strength and hermeticity. This is a must-do destructive measurement as it is critical to ensure your weld stays within the specification established in the R&D phase.

Hardness – Hardness is a key output for monitoring weld brittleness, potential contamination, and overall weld quality. This is a must-do destructive measurement as it is critical to ensure your weld stays within the specification established in the R&D phase.

Colour – Colour on and around the weld bead should be visually monitored as it is an indicator of contamination and/or process variance. Judging colour against past welds or industry standard colour palates may not give you a definitive answer as to the weld’s quality, but if the colour resembles previous welds it helps establish a degree of confidence in process consistency without the added costs of destructive measurements.

Performance Qualification

Once the OQ has been successfully completed, repeat the tests for the PQ using nominal values with multiple operators. Make sure you produce enough parts to satisfy your confidence requirements. The PQ should mimic the intended production process.

Process Control and Production Monitoring

Now that your testing is done and your validation complete, how will you guarantee long term process quality? Choose to monitor your process inputs and weld outputs at a frequency that is statistically significant but be careful of costs! The destructive weld tests can be expensive and those costs can add up quickly.

Welding can be a difficult and often puzzling process but it is always fun to conquer. Follow these basic rules and you will create a stable welding process that will give you long term confidence.

Author

Glen Farrell
B.Tech, A.Sc.T, ASQ SSGB, CC
website: www.eaglepicher.com

Gregor Library Inc. launched its Gregor Library today, the premier online research tool for industry professionals impacted by FDA oversight. The library contains an extensive collection of authentic FDA documents, which have been previously inaccessible to the public without a formal FOIA (Freedom of Information Act) request. Our document collection is easily searchable and accessible to everyone. All of our guests are provided with complimentary access to our library and are encouraged to browse our vast collection of documents. In addition, our guests enjoy the privilege of viewing, downloading or emailing the first page of every document in our library, FREE.

Assist with Documents

To assist with research, each document is accompanied with a corresponding CFR (Code of Federal Regulations) mini-guide for quick access to relevant citations and regulation language.

Our subscribing members are granted access to full-text versions of our library documents and are able to view, search within, email and download a document in its entirety.

Any Document, Any Time!

Presently, our system contains the following document types from this non-exclusive list: Establishment Inspection Reports, 483 Citations, Warning Letters, Company Responses, Exhibits, Investigator Notes, FDA correspondence letters, Inspection Summary Reports, New Drug Applications, Investigational New Drug Studies, Pre Market Approvals, 510k
Applications, Complaints, Recalls.

Single Users License Available

Single user and enterprise licensing is available.

If you have any questions, please contact us 1.800.285.9184 or visit us at www.gregorlibrary.com

The purpose of warehouse mapping studies is to analyse temperature and humidity distribution, to evaluate storage conditions and identify critical zones inside the warehouse. This article intends to be a quick guide for warehouse mapping studies.

Overall Approach

Even with controlled environment inside the warehouse, the exterior weather conditions may influence the overall storage temperature and relative humidity. Because it has many costs to monitor many points continuously, particularly in big areas, the best approach is to perform this study at the worst case conditions, meaning two complementary studies performed respectively at winter and summer time. With these two studies, the critical zones can be identified to be monitored continuously.

Top Tips - How to validate your warehouse

First steps, start by collecting all necessary data about the warehouse: drawings, dimensions, HVAC plans, walls and ceiling materials, and storage organization. This will be extremely useful to choose the location of your dataloggers and prepare the protocol. The protocol should describe the procedures to be followed, including the number of dataloggers to be used and respective locations, the study duration, data acquisition intervals, data processing methods and acceptance criteria. Make sure you have enough dataloggers and that the sensors are calibrated.

Dataloggers location

You should set the number of dataloggers to use according to the warehouse volume. Try to use as many as possible to ensure a good distribution, but take into account that you will also have much data to analyse afterwards. Make sure you cover all storage areas, and all storage levels, including top levels. Locations near outside doors, walls and ceilings may be more sensitive to exterior conditions. To ensure a good distribution of the sensors, you can for example divide the warehouse into smaller equal sections. Put a sensor in the outside to record exterior conditions during the study.

Mappings

Use the same protocol for both winter and summer studies, with the same datalogger locations, data acquisition intervals and study duration. The study should be long enough to show any possible daily trends, so it should be not less than 3 days. Program the dataloggers to acquire data every 10-15 minutes (also the smaller data acquisition interval, the more data you have to analyse).

Data processing

For each location calculate the maximum, minimum, average, standard deviation and mean kinetic temperature. Usually the software associated to your dataloggers does these calculations for you. It is useful to make a plot with all locations results to see any overall trends. You will also see if there are any differences between lower and top locations. With this data is now possible to identify any critical areas, hot or cold spots, and analyse if any changes are needed.

Reports

Attach to the reports drawings with your dataloggers locations, all obtained results and calibration certificates. After performing both winter and summer studies, write a summary report compiling the main results and conclusions from both studies.

Author

Cristiana Pedrosa
Validation Specialist
Generis

Related Reading

Check out other interesting topics on Warehouse Qualification:

• Storage Qualification
• Warehouse GMP (HVAC) specs
• Warehouse temperature & humidity validation
• Temperature Mappings

A lot of companies don’t like to validate spreadsheets, some say it can’t be done. Is this just a myth?

If you’ve got some data to compare or look for missing entries why do it manually? Because a human is more efficient than a computer? Right? Wrong, checking lists is boring – no one wants to do it, that is why there are always mistakes.

By qualifying a spreadsheet to do this job you are taking a lesser risk, yes a lesser risk in failing to achieve the correct results consistently. The computer can check continuously and not make a mistake, always being consistent; even if it was wrong, it would be consistently wrong making it better than a human being. Consistent mistakes can be consistently rectified!

Is it worth the effort to validate your spreadsheets

Evolvement of Computerised Systems

So, what’s the risk in qualifying a spreadsheet? None, some people might not like it [validating spreadsheets] but it’s probably one of the simplist processes to actually validate. In this ever changing industry, one thing is for sure – the use and evolvement of computerised systems and equipment has never been so high. With MES systems becoming more and more popular, more equipment is emerging with the capability to export to a spreadsheet – even software for the likes of scales and pH meters with Ethernet ports or serial ports can facilitate exporting data into spreadsheet formats.

Data is just data

The truth is, by exporting something to a spreadsheet a whole new world of opportunities will appear. Data is just data, plain and simple. It’s pretty useless and almost everything has a load of it. Information on the other hand is: USEFUL DATA; it is informative and valuable. Can you see where this is going? Yes, get your data into a spreadsheet, validate the process, do some ‘magic’ and some validation and hey presto.

The QA department won’t accept this I hear you calling – present this: What level of confidence does their system have for manual entries and checks (that probably aren’t audited)? Do it anyway and demonstrate your efforts. So far, we haven’t failed with our QA departments.

Improve and Enhance

Post validation you will have information that will support your validation activities and your business systems and process in general (including QA) – this will actually provide for a basis of making improvements and enhancements. Once the barriers are down, do it again on another system and before you can say 2011 – you’re exploiting all of your data, becoming a more mature, information-rich site who actually uses their data, sorry information properly and naturally. If you’re as organic as using your immediate spreadsheets as proper tools as you are organic in you’re gardening at home, you’ll be both healthy and informed, as well as efficent and healthy living in the digital age!

So how do you Validate the Spreadsheet?

So, now you’ve bought into this process I hear you asking: “So how do we validate the spreadsheets then?”.

Well, that depends on the level of complexity of the sheet and what record will actually constitute the GxP data. If you have a simple spreadsheet and you are using a few basic formulae to do a calculation or a count, a basic test will suffice and this can hang-off an existing validation plan; an existing SOP or Work Instruction (WI) can detail the operation to facilitate on going consistency.

An example of such usage would be an export from some lab equipment to a spreadsheet to perform basic analysis on the set of data, in this case it would be usual for the master GxP data to reside within LIMS, MES or a Production Batch Record, therefore the basic level of validation would permit the printout to be used to support GxP activities whilst the actual raw data is held in another, already-validated system.

Computer Systems Validation

I have more than basic formulae in my spreadsheet (Yes, I heard you when I was explaining the above). In this case lets assume a VBA macro is used in conjunction with some input data on a spreadsheet. This brings us into the realm of computer systems validation, but don’t be scared! This means that the SDLC must be followed (to an extent). A risk based approach is now required (GAMP5 considers this to be at level 5).

Remember that duplication of effort doesn’t yield many business benefits (if any), nor does quality generally benefit either. Most organisations facilitate the scaling of the suite of validation documents in order to suit the job-in-hand. Would it really be beneficial to have a URS, FDS, Test Plan, etc PLUS all of the associated reports for a small(ish) validation effort when all of the same people are required to sign-off anyway?

Create a New Specification

At this juncture I would recommend creating a new specification to outline the user, business and functional requirements to the spreadsheet validation effort, in addition, update the validation plan for the originating functional area or project to include the spreadsheet validation and outline the test plan and qualification deliverables (e.g. IQ/OQ – these can be scaled into a single IOQ document) and make reference to the SOP or WI that will control the operation of the spreadsheet. Be sure to include backward and forward traceability between all of the documents (e.g. the specification should reference the VP and vice-versa).

Conclusion

I’ve written this article, and reading back through it makes me sound like I’m making this subject-matter sound very simple. To an extent it is, but this is an overview and the level of ease depends on the source data, what you’re going to do with it, the support of your manager and hopefully a forward-thinking QA department. The basic steps are:

1) Identify the GxP data – is this going to be the spreadsheet or another system (manual or electronic, it doesn’t matter).

2) Take a risk-based approach to ascertain the level of complexity of the sheet. This will yield several outcomes ranging from full-validation, source code review, and new documents to a few simple tweaks and a test hanging-off an existing structure.

3) Documents. Don’t forget that these can be scaled to reflect the size of the job; there is no reason why this can’t involve the amalgamation of documents to better support the effort.

And for my last trick…

And finally, we’re in a position where the SDLC has been fulfilled, the spreadsheet has been designed, implemented, tested – it is validated and the validation is managed via the VP, your colleagues haven’t been mad because they had to sign a million documents when you only needed a couple of new ones and a couple of updates to existing documents.

What next, execute the tests write, issue and approve the reports then you’re in compliance and ready to use these spreadsheets in GxP activites.

Whilst performing this initial spreadsheet validation effort a model has been created that will permit you to keep on validating different spreadsheet applications with various data sources, the same rules apply, but as with everything else – the more you do, the easier it gets.

Buy Our Spreadsheet Validation Template

If you would like an easy to use template in order to validate your spreadsheets more efficiency, simply click the button below to purchase your copy now.

Author

Mark Richardson
Network and Infrastructure Expert
Premier Infrastructure
www.premierinfrastructure.com
www.askaboutvalidation.com
mark.richardson@premiervalidation.com

Related Reading

Check out other interesting topics about Spreadsheet Validation:

• Excel and Audit Trails
• Spreadsheets for the Estimation of MACO
• Spreadsheet Validation Checklist
• is Validation Required for all Excel Spreadsheet

Software patches are issued periodically by virtually every (major) software producer on the planet. From Microsoft to Apple; Adobe to Corel. Patching is required to fix faults, increase functionality and generally just iron out faults or correct things that could be better, nevermind security!

Software patches and validated systems

Security

Security is the most critical area of computing nowadays and being secure is the most important business requirement out there. Patches are released to enhance security / “patch” a vulnerability or to deliver a bug fix or enhancement; this is basically a situation such that patches are either reactive or proactive.

Patches

Reactive patches are plugging holes that have been exploited by hackers or “cyber terrorists” – some new trojan has found yet another back door that will cripple your business. React now and install the new patch! Microsoft have released it so it’s absolutely necessary. Is this really the case? No it is not.

They have probably not tested it with your DeltaV or LIMS system – how will the patch affect your business? What if it mandates a new .NET framework that your propriertry application software can’t understand?

Reaction is risk in the world of patching the minimum risk is losing performance – the greater risk is losing production and/or reputation.

Development System

Where possible, make sure you have a test or development system to implement patch installation prior to commitment to the real thing, give them a [documented] few days and then install them (under change control whilst observing risk management procedures) – don’t let a problem be a disaster and consider that if you already have a secure system you might not be at risk of the risk.

Whether the patch is required or not, it should be assessed to determine whether the business will benefit from the application of the patch, or whether a risk situation is imminent. If necessary a formal risk assessment should be carried out with robust mitigation options on the table.

Change Management

Regardless of the urgency of the situation, a change management process should be used that includes a roll-back plan as well as a reasonable level of testing (in accordance with the risk category). Does the patch have to be applied to the production system first?

Or is there a smaller area that can be used, e.g. a development system or just a subset of the overall set of computers that will require the patch? In any case, release the patch slowly whilst testing continuously to make sure the change control details not only how to do the installation, but also how to revert back and make sure that the systems can be reinstated to the post-patch condition.

Conclusion

Finally, make sure someone else has approved the change – in writing. If you’re in a non-controlled area then try and make a change logbook or something just so it is evident what has been done, when and by whom; not only are you covering your own back and not being liable to bringing a plant down, you are in a position to recover another error by using the logbook as a tool, e.g a shiftworker is told to make a change that fails a few days later (even dodgy patches are released to the market) – you are back in work and you can revert the change by looking at the change log and then following the rollback plan in the change control pack.

Author

Mark Richardson
Network and Infrastructure Expert
Premier Infrastructure
www.premierinfrastructure.com
www.askaboutvalidation.com
mark.richardson@premiervalidation.com

Related Reading

Check out other interesting topics from Mark:

• Validating SaaS Applications
• Software Patch Management and Releases
• Evaluating Software for GMP Criticality
• Question on Open Source Software Tools (CVS Bugzilla)

Good Documentation Practices (GDP) simplified – seriously. You’ll will be amazed and relieved to know there really is an easy way to learn about Good Documentation Practices or brush up on your previous knowledge.

Step by step guide

This step-by-step guide is perfect if you’re either new to regulated environments, or just want an easy to understand refresher guide. You’ll be able to take your GDP skills and use them in any regulated environment.

You’ll be able to take your GDP skills and use them in any regulated environment.

GDP is an essential tool if you are working in any regulated environment and this beautifully constructed training course will bring you up to speed very quickly.

Click here to find out more and purchase you copy now!

How many of you grimace when you see the appointment in your diary for a risk analysis review meeting? Have we forgotten how useful this should really be? Are we also afraid to take risks? Without some risk, we cant push the boundaries out.

4 Steps to Risk Analysis

Why has this happened and more importantly, what can we do about it. Risk analysis should be equivalent to putting on a bullet proof jacket in combat – it is there for our protection and conducted properly adds real value to our projects. The reason why we should utilise it to remove or reduce the risks which threaten our project success.

So what framework do we have for Risk Analysis and Management?

I am suggesting that we take a 4 Step Process and apply it always and from the very outset (feasibility) of our project. The 4 steps are:

1. Risk Identification
2. Risk Analysis
3. Risk Response Plan
4. Risk Monitoring and Control

So let’s start at the beginning

You have just taken over on a new project and are busy, busy, busy. You believe that the key is to get the scope nailed down, the team built and the funding secured – we will take a look at risks later on – they are not really that important, because this is essentially the same as a project we did last year, but bigger and with more aggressive delivery dates.

That is a lot of assumption – if they are all TRUE, then you are in the clear; if any of them are FALSE, then you are ignoring potentially fatal risks – russian roulette comes to mind.

Apart from that, risk identification is going to influence how (and possibly what) you choose to execute the project and will also possibly influence your calculation of required contingency requirements.

So let’s start with “Risk Identification”.

In order to address this properly we need to define “What” the activity is and “How” we will execute it.

Let’s start with the WHAT
The key objective of this stage is to capture any risk/problems which might occur during the delivery of the project objectives which may impact our chances of success.

The HOW is a little bit more detailed
Here we will need to have some brainstorming sessions with the client and key technical resources so that we can evaluate the type of things that might happen, how likely they are to happen and finally, what the impact of such an event would be.
So let’s take a look at a framework that would allow us to analyze and manage the risks for our project from the outset – let’s call it the Kevlar Jacket Approach.

Step 1 – Risk Identification

As stated above, to aid in identifying the risk, we first need to identify the right people to aid us in this – technical experts, customer, project manager. Once we have identified the right team, we then need to conduct the risk analysis – here we need to use a mix of:

1. One on one meetings
2. Brainstorming meetings
3. Review of previous project risk and issue registers

Risk Identification

During these activities we need to capture key information to allow us to analyze, respond and manage these risk. During the identification step, make sure that you capture the following:

1. Give each risk a unique identifier – a simple number from 1 to n.
2. A risk description which is sufficiently detailed enough for anyone reading the risk register to understand the risk or ask intelligent questions of the person who identified the risk.
3. A risk indicator – i.e. any event which might be an early warning sign of the risk occurring, or may trigger a sequence of events that if not controlled properly would lead to the risk occurring.
4. Categorise the risks into specific buckets – e.g. Safety, technical, commercial etc..
5. Record who identified the risk, on what date
6. Record during what activity was it captured – e.g. brainstorming session, 1 on 1 interview – this will be useful for analysis across projects and will help you continuously improve your risk analysis process.

So that then covers the information you need to capture once you have identified a specific risk. The next step is to analyse it and get a detailed understanding of what its occurrence would mean.

Step 2 – Risk Analysis

Once you have identified a risk you need to analyze it – you need to once again ensure that you have all the right people present to conduct this in a meaningful way.

Risk Analysis

The key activities here are:

1. Get an understanding of the impact to the project/business if the risk did in fact materialise – this will require key input from the customer and the technical experts.
2. Rank this in terms of significance, using a scoring system of 1 to 5, where 0 = none, 1 = low and 5 = very high – make sure that this is discussed in detail and there is a reasoned basis for the score.
3. Gain an understanding of the probability of this event occurring and rank this in terms of probability, using a scoring system of 1 to 5, where 0 = none, 1 = low and 5 = very high – make sure that this is discussed in detail and there is a reasoned basis for the score.
4. Now calculate a Risk Score = Significance x Probability
5. Colour code the risk based on score – define Red, Yellow and Green bands e.g. 0-5 = Green, 6-12 = Yellow, >12 = Red.

Now we have some useful information to go forward with – the next step is to build a plan to either reduce the impact or eliminate the opportunity for it to occur. We are now in the realm of managing our risks and we must build a risk response plan – our next step.

Step 3 – Risk Response Plan

Here we start to look at how we manage the risk we have identified – we have 4 main strategies that we can use, and we are going to call the them 4 T’s.

Risk Response

The 4 T’s

1. Terminate (often referred to as Avoidance)
2. Transfer
3. Treat (oftener referred to as Mitigate)
4. Tolerate

So, let’s look at each of these individually.

Terminate is where specific steps are taken to ensure that the risk is eliminated (avoided) or that the impact it had is prevented.

Transfer is where the risk is passed to another party; the weakness with this is that the risk does not go away, it’s just causes someone else a problem.

Treat is where by taking certain actions immediately, the risks can be reduced.

Tolerate is what it says and the reason we tolerate them is that despite the fact that we cant do much to reduce or eliminate them, the benefits of taking them far outweigh the penalties/cost.

Step 4 – Risk Monitoring and Control

This is the routine part and requires the project manager to be diligent and monitor the status of the risk, the residual score by reassessing the risk at critical junctures and the risk state – is it static increasing or declining. This is a key activity and depending on the trend and significance may require a renewed effort by the project team to ensure that identified risks are dealt with appropriately.

Risk Monitoring

Finally, the housekeeping. Put all of this information in one central location – A risk register. Make sure that all key stakeholders are informed on this and agree with your plan of action.

Would love to hear your comments and am delighted to answer any questions you might have.

Author

William Lacey
Freelance Project Director
www.projectcoach.com
LinkedIn Profile

What should a test protocol contain? What is the typical content of a test protocol? Before any test execution takes place there are a number of checks you must do before entering into the world of test execution. “Fail to prepare, prepare to fail” no truer words can be spoken in relation to protocol execution.

How many times have you seen executed protocols with deviation after deviation or observation after
observation?

Protocol Execution Tips

Can this be prevented or do you have to have executed protocols with mark ups everywhere on the document. Its one thing to have a clean protocol with no deviations or mark ups (rarely happens and would raise suspicion with the FDA) but its quite the opposite to have a protocol littered with mark ups everywhere to the point where someone has to ask the question “Has this been given a dry run”.

The article below details some great tips before entering the dreaded execution step of your validation project.

Test Protocol – Are you prepared for testing?

What should a test protocol contain? What is the typical content of a test protocol?
Below is a checklist of typical headings that should be found in any test protocol.

• Introduction
• Purpose
• Scope
• Rational
• Roles and Responsibilities
• Team
• Validation Responsibilities
• Test Team Responsibilities
• Location of Testing
• Testing Requirements
• Hardware Requirements
• Software Requirements
• Documentation Requirements
• Test Execution
• Order of Testing
• Acceptance Criteria and Observed Results
• Hand Written Data
• Recording of Test Results
• Corrections
• Incident Recording and Management
• Fault/Deviation Reporting
• Observation Reporting
• Outcome of Test Documentation
• Change Control
• Document Changes
• Glossary
• Definition
• Abbreviations
• Associated Documents
• International Standards
• International Guidelines

Test Specifications

The test specification contains the test instructions, test acceptance criteria and results for the items under test. It is very important to read the test specification carefully before entering into any test execution. Time spent dry running or becoming more familiar with exactly what you have to do will be time well spent.

An entire dry run (time permitting) should always be performed on any test script before official execution.

Design Specifications (Typically applies to Software Testing)

The design specification contains the design information for the module/application under test and is the document from which the Test Specification is written.

There is typically one design specification per Test Specification but occasionally there will be the situation where one Test Specification will refer to multiple design specifications.

Make sure that you have a copy of the required design specification(s) before commencing test. You need to record the revision of this document in the Test Specification before testing and you will need to refer to it during testing.

Fault and Observation Forms

These forms are critical to any test process as they will record the details and resolutions for any incidents noted during testing. One form is completed for each incident noted and this is referenced in the test specification. Make sure that on the test protocol that any reference to a fault or observation form is clear, and they are included in the attachment listing section.

Test Report

This is the summary document that reports the findings of the Test Phase. The test report is an important document in the sense that an auditor should be able to see quite clearly from the report how successful the test phase was for the particular module/equipment/application in question.

Completing the Test Documentation

There is one simple rule in relation to test documentation:

If it’s not written down then it didn’t happen

Signature Log

Before commencing test, all testers, witnesses and reviewers are required to sign the Signature Log which is included in the test protocol, usually located at the back of the document.

Test Specification

Read the test specification carefully; understand exactly what you are testing. Check to ensure the pre-requisite steps make sense and are performed correctly before launching into test mode. Read the test step instructions carefully.

Test Results

Fill in the acceptance criteria sections correctly, if the acceptance criteria asks for a PASS/FAIL response then write down either PASS or FAIL no other acceptance criteria is allowed.

The tester must sign and date at the bottom of each page.
Witness must sign and date at the bottom of each page.

Completing the PASS/FAIL column

If the results match the expected result then mark as pass. If the results do not match the expected result then mark as fail and reference the corresponding observation/deviation number. If the test section does not apply to the test step then mark this section as N/A and give a brief explanation of why this particular step does not apply.

Attachment List

The following is a guideline detailing how to handle attachments associated with your test protocol.
Each attachment associated with the protocol must have the following information.

• Test Reference
• Test Section
• Attachment Number
• Page No _ of _
• Initial and Date
• Complete the table in the attachment list section of the test specification to list all Test Attachments

Result of Test Specifications

If all tests were passed without incident, then mark clearly on the protocol passed.
If any test failed and faults or observations were raised, state whether the faults or observations are closed or resolved, if resolved mark as pass.

Mark the overall test protocol as passed if all the faults and observations have been closed out, if not indicate that observations or deviations are still open.

Common Testing Mistakes Associated with Software Validation

Test Script Generation Errors

• Writing the tests based on the system and not on the specifications
• Inadequate security testing
• Using the “Shotgun Pattern to Testing”
• The test system doesn’t match the production system
• Non-compliant ordering of tests
• Not doing adequate pre-test setup
• Not ensuring test step repeatability
• Inadequate field verification
• Poor selection of test data
• Not testing the error handling capabilities
• Not handling calculation verifications correctly
• Not testing for known problems
• Insufficient audit trail testing
• Insufficient depth of testing
• Insufficient stress testing
• Writing test scripts for functions that are not used

Test Script Generation Errors

• Not training your testers in good documentation practices
• Assigning testers that just don’t care
• Tester error as a result of unfamiliarity with the tests
• Relying on inexperienced test script writers

Execution Mistakes

• No pre-execution approval of tests
• Poor organization
• Mandatory order of execution not followed
• Preprinting and replacing lost of damaged pages
• Not explaining mistakes or errors thoroughly
• Not allowing for ad-hoc testing
• Not retaining the entire report on huge printouts
• Not writing up a deviation
• Deviation records not complete
• Changing a FAIL to a PASS
• Showing insufficient deviations to support comprehensive testing
• Not closing out deviations
• Not having adequate sign offs of deviations
• Not creating a deviation log book
• Individuals writing and executing the validation protocols are not identified or trained
• Uncontrolled changes to approved test scripts
• Not archiving off the validation database before and after validation
• Original validation documentation can’t be located

So you just bought a new stability chamber for your facilities. Usually you can buy also the initial qualification from the vendor, or choose to do it internally by your validation team.

The purpose of this article is to describe a simple approach for stability chambers qualification.

Overall Approach

Qualify a Stability Chamber the easy way

The basics of all qualifications are here applied. IQ/ OQ and PQ are therefore performed prior to use. To begin, you should establish the operation conditions (temperature and relative humidity), and prepare IQ/OQ/PQ protocols based on the pre established user requirements specifications. The acceptance criteria for the tests and mappings should be clear on the protocols.

Installation Qualification

The first step is to check the correct positioning of the chamber and then check if the chamber and all components are correctly installed, and also the presence of documentation. Documentation usually includes user’s manual, certificates and SOPs. Utilities can be verified at this phase: electrical feeding, water (pressure, pumps, filters and connections) and exhaust. If the chamber has a control panel/ system, this can be checked too: buttons and commands, screens, etc. Finally check for all components part of critical systems: measuring and control, ventilation, heating and cooling, safety. All associate connections should be properly done.

Operation Qualification

At this phase we start by testing all individual functions of the stability chamber, including switches and controls, alarms, doors, etc. Check the sensors calibration if this was not covered on IQ. The final OQ test is to perform a thermal/humidity mapping of the chamber for the established set point. At this point the mapping is performed with empty chamber and for a determined period of time (not less than 24 hours).

Mappings

The purpose of this study is to assure that temperature and humidity are evenly distributed inside the chamber and that the established acceptance criteria are met at any point of the chamber.

Use at least ten sensors evenly distributed inside the chamber. For example on the chamber’s corners and at the centre, or 3 sensors on each shelf, depending on the size of the chamber. If you use thermocouples for temperature, assure that the chamber is prepared for it, or in case you pass them through the door, that the door is perfectly closed. The easiest is to use wireless probes, with the only disadvantage is that you will only see the results at the end of the study, instead of doing it online.

Program the sensors to acquire data for example every 5 minutes. Wait for temperature and humidity stabilization for a while and let it run for the established time.

Door Opening Study

At the end of the study, and before removing the sensors, perform a door opening study. This can be achieved for example by opening the door for a certain short time, and keep recording temperature and humidity at a short range (every 10 seconds for example). Once you close the door let it stabilize again. We usually perform 3 door opening trials and at the end we calculate the chamber’s average recovery time.

Performance Qualification

For performance Qualification we only perform a full load thermal/humidity mapping, using the same configuration for the sensors as in the empty chamber study. The minimum study time now is 24 hours. Again at the end of the study we perform door opening trials and calculate the average recovery time.
Requalification

Performance qualification is done on an annual basis, using the same sensors location and for the same time. You can use the same protocol or a SOP describing the method for mapping. After each requalification it is recommended to compare the results with the previous qualifications to see if the chamber is maintaining its performance. If you eventually intend to change your temperature or humidity set points, both empty chamber and full load studies should be performed again using the new set point.

Author

Cristiana Pedrosa
Validation Specialist
Generis

Related Reading

Check out other interesting topics about stability chambers:

• Heat Penetration test – Steam sterilizer
• Stability Chamber
• RH Measurement System