During a validation exercise, it can be difficult to figure out at what stage the process is at. It can be quite chaotic at times with production supervisors, operators, technicians, validation personnel etc are all vying for their own place in the process. Some time ago, we decided that a useful aid in helping communication during the process is to use a whiteboard to list the activities of the day .

A white board can be an effective way to organise the days activities

For example: Mon 1st February:

Task 1 = Run 1000 placebos through the blister packaging machine to check the formation of the blister pockets.

Task 2 = Run 1000 blister packs through collating machine to check the integrity of the pillow foil.

In this way, mistakes can be eliminated. In one instance during one particular validation exercise, empty blister sheets were run through a machine rather than blisters filled with placebos. About ½ day was lost and needless to say, tempers were beginning to fray!

Validation SOP’s

Another useful tip I have picked up along the way is in the area of writing SOPs from a validation exercise. Those working directly in validation know how difficult it can be to write SOPs from a validation package.

Validation packages can sometimes be composed of hundreds and hundreds of pages of tests and tables of data. Critical information can very easily be omitted from the SOP when writing it. For example, one particular test could be a verification test to ensure that a particular sensor is working correctly. This test may be described perfectly in the validation exercise. However, it could very easily be left out in error from the user SOP, particularly if there is a multitude of other checks than need to be included in the user SOP.

The best way I have found to eliminate this problem is to insert a check at the bottom of each test of the verification process. This check requests that the validation executor indicates whether the test in question should be included in the SOP. It is very easy as a result, upon review of document, to see what should be included in the user SOP.

This has been approached in a different manner by one company where I have worked. In this case, the company used colour for a page in the validation package that was critical to the writing of the user SOP. This practically eliminates the risk of omitting critical items when it comes to writing the user SOP.

Whatever the method of approaching the problem, recognising that there is a risk is half-way to solving it. The risk itself should be identified in the risk analysis which must be performed as part of the validation protocol development.

Author: Stephen Corkery
Title: Validation Specialist
Email: corkerys@eircom.net

It is a common misunderstanding that validation exercises are not the concern of the on-site Qualified Person. This can often be experienced, particularly in larger companies, where the Validation department can be segregated, to some degree, from the Quality Assurance department.

It can easily happen, that once validation exercises are completed, the validation documentation can be forwarded to the QA department for the attention of the QA Manager. In many cases, this may not be the same person as the QP. Thus, a change to the validated status of the process can go ahead without the ‘specific’ attention of the QP.

QP Training Programme

The FDA have noted this in the past, and have come up with a method of eliminating this to some extent. This is done by explicitly requesting that the original manufacturing dossier is part of a QP’s training programme prior to that QP being mentioned on the licence.

This has only partly solved the problem and more specific steps are needed to ensure greater control. The following are some points , which, I believe are critical to ensure that the on-site QP is aware of validation changes.

• Full training for the QP on the manufacturing dossier.
• Full training for the QP on the change controls implemented since the original dossier submission.
• Pre-approval for the change control to be specifically granted by the QP.
• Final approval of the validation documentation to be specifically granted by QP.
• Notification in the batch record that a batch is part of the validation exercise.
• Minutes of meetings concerning validation to be forwarded to the QP.
• Presentation on the status of the validation exercise to be given at regular intervals to the QP by the Validation Department.

Summary

The QP can only make informed decisions relating to GMP, through proper formal channels of communication between the Validation Department and the QP. As a QP, it can be quite infuriating if the full extent of the validation exercise is not fully known from the outset. The approach must be clearly defined in the SOPs of the Validation Department and QA Department.

Good computer and software validation requires planning, verification, testing, traceability, configuration management and many other aspects of good software engineering, that together help to support a final conclusion that software is validated.

Software validation is a part of the design validation for a finished device, but is not separately defined in the Quality System regulation. In practice, software validation activities may occur both during, as well as at the end of the software development life cycle to ensure that all requirements have been fulfilled.

Feel free to contact Premier Validation for all of your software validation requirements

Good computer system validation requires planning, verification, testing, traceability, configuration management and many other aspects of good software engineering, that together help to support a final conclusion that software is validated.

Computer system validation is a part of the design validation for a finished device, but is not separately defined in the Quality System regulation. In practice, computer system validation activities may occur both during, as well as at the end of the software development life cycle to ensure that all requirements have been fulfilled.

Please feel free to contact Premier Validation with any computer system validation queries you may have.

When validating computer systems and applications an array of screenshots and other such supporting documentation is frequently used. All too often, supporting information is simply stored in a database and is easily accessible, which means that the information can be extracted by use of an SQL query and presented in a user-friendly format with a reporting tool.

Documented Query

Obviously, from a quality perspective a documented assurance that the SQL is extracting the correct information consistently must be in place or in other words the SQL must be qualified. This is not a daunting process, this means that a test script must be assembled that utilises a documented query and that the results are verified; the supporting evidence attached to the test script, the testing can be carried out on a set of data that is not exhaustive and returning 1000s of rows of data, just something simple whose results can be confirmed to be correct and complete.

Reporting Tool

Once the SQL query has been produced to extract the required data, the SQL can be used as a data source in a reporting tool such as Crystal Reports and then the fields of data organised in a user-friendly (easy-on-the-eye). The SQL is executed as part of the report and voila, a nice easy-to-read set of well presented data.

When writing the SQL query, ensure that the query is structured as specifically as possible – writing a query to extract too much detail (e.g SELECT * FROM tblSales) when only a specific amount is required can impose what is sometimes as substantial strain on the system being queried, if this is a production system then the outcome can be disastrous.

Filters

In addition, reporting tools offer allsorts of various forms of filtering and sorting data – be careful not to leave filters in place in the reporting tool – this can cause the correct results to look truncated however this is something that would be usually be detected by whoever generates the report.

If these reports are to be used on an on-going basis, it makes sense to have a controlling SOP for the process of generating the reports – this is also highly recommended when dealing with cGMP systems.

Summary

In summary, SQL is an ideal data source for report tools to create many time-saving, valuable reports. Care should be taken not to place an unnecessary load on a production system. A controlling SOP should be in place to instruct the user on the initialisation and execution of the report in order to eliminate any user applied filters that are left over from the previous run of the report.

Author: Mark Richardson
Title: Networks and Infrastructure Expert
Company: Premier Validation
Email: mark.richardson@premiervalidation.com

So you have a validation protocol to execute and you want it to run smoothly without raising too many deviations and discrepancies (if possible). What is the best approach to take and what are the main things you need to look out for.

How to execute a validation script successfully

Here are my top 10 tips:

1. 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.
2. The person who is developing the protocol needs to understand what needs to be tested.
3. Ensure that you have sufficient time before you run the protocol to dry run it.
4. 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!)
5. If you have time, get an independent person to review your protocol, they will spot things you will never see.
6. Start the execution at the start of your day when you are fresh, not at the end when you are rushing and want to go home.
7. Ensure that all of the prerequisites have been performed before execution
8. Have deviation and discrepancy forms at hand to write them up as you go along (You will forget the details if you don’t)
9. Understand what is the difference between a deviation or a discrepancy (Or whatever terminology your company uses)
10. Attach any evidence you deem important

Having performed numerous protocol executions over the years, you’ll be amazed what you’ll forget to do, so it’s advisable to have your own checklist of items before you proceed.

Please add your own tips

In the comments section below please add any top tips you may have from your own experiences.

Looking for help with a project?

If you would like more advice on protocol executions or if you would like help with any upcoming projects please feel free to contact askaboutvalidation.com with your queries or contact Premier Validation.

This article will present a simple method for validating MS Excel spreadsheets for GXP use. The goal of our validation strategy is to provide better testing and documentation of individual spreadsheets in less time. Once we establish this methodology, we can rapidly apply it to many spreadsheets to reach compliance faster.

Scope

This article will attempt to cover the most common examples of spreadsheet validation activities that we find. We will attempt to cover special or very complicated examples whenever possible, but it should be understood that anything not explicitly covered in this article can be added as needed to fit your existing validation requirements or for special cases. A good example is any spreadsheet that uses or is used with custom automation. We have validated spreadsheets that contained hundreds of formulas and custom macros, but did not require any user intervention at all because they were created, populated with data and saved entirely by external code. In this case, the focus of the validation was on validating formulas and macros, but security testing was limited to proving that users could not intercept or interrupt the operation at any time.

Are your spreadsheets in compliance, avoid a 483!

Assumptions

We are not going to make any assumptions about the existing SDLC (Software Development Life Cycle) that may be currently in use, any material presented here can be adapted to meet your existing standards and practices.
We are also going to assume that the spreadsheet that need validation has already been written, as this is what we find in the overwhelming majority of the cases presented to us.

Approach

The basics of our approach are as follows:

• We define our basic documentation practices and methodology in a single document, the Spreadsheet Validation Master Plan. This document can be referred to for all individual spreadsheet validation projects, and will not need to be reviewed or approved for each validation effort.
• We define the requirements for each sheet or chart in the workbook, then focus our testing on verifying these requirements.
• A heavy emphasis is placed on defining and testing formulas, and also on the security for each sheet by limiting the parts of each sheet that the users are allowed to edit.

Methodology

To keep things simple, we define how we enter information into the requirements and design specification documents, then describe how we go about testing the spreadsheet in the test protocols. Keep in mind that input cells may be defined as one single cell or as a range of cells.

Requirements Specification

The requirements specification should include all the requirements that your spreadsheet must accomplish. This document should be kept simple and relatively non-technical so that anyone who reads the document will understand that the requirements are.

Starting with a common validation template:

• List all sheets and charts in the workbook
• What users should be allowed to enter into the sheet. These are your input cells. You may find it helpful here and for later use to label each input cell, or they can be labeled in the design specification document.
• What formulas or calculations exist on the sheet.
• What cells represent the output or final calculation of the sheet. This may also refer to a chart.
• For each chart, define properties like the title, axis labels and units, and the datasets used to create the chart.

Design Specification

Now that you have defined your requirements for each sheet, you can create the detailed software design specification document. The purpose of this document is to describe how the requirements have been implemented. This document should include enough information so that a developer could create the entire software project based on the information contained within this document and from reading the requirements specification
We like to break each sheet into four sections: Inputs, Processing, Outputs and Security.

Inputs

Document the cells users are expected to enter or update data. In an automated system, you can also define the source or the input data or instructions. If any validation rules are used to enforce proper data entry, these should be documented here as well.

Processing

Processing is mostly about documenting the formulas that are used on the sheet. Any custom macros or code is also documented here.
The majority of errors that we find when validating sheets is in the formulas. The best way we have found to catch these errors is to define each formula using the actual names of the variables represented as input cells.

For example, it may be easy to document that the range of cells F10:F20 contains the formula “=(A10*$C$5)/($D$5*B10). However, it is difficult to verify if this formula is correct. We recommend writing the formulas out like this:

• Cell $C$5: Volume (V)
• Cell $D$5: Ideal Gas Constant (R)
• Cells A10:A20 Pressure (P)
• Cells B10:B20 Temperature (T)
• F10:F20 Final Result (moles of gas, n)
• n=(PV)/(RT)

This is the easiest and most effective way we have found to verify that formulas are correct / to catch errors in formulas.

The other kind of processing is the validation of macros and code that is used in the spreadsheet. Here, the design specification is a good place to copy the code and annotate as needed to describe the purpose of each macro or function.

Note: If you have good coding standards and user proper headers and comments in your code, this step may be already done for you.

Outputs

Outputs usually fall under one of the following three main categories:

1. The cell or range of cells that contain the final result of all previous calculations
2. Charts – many times these are printed and saved with external reports
3. Data that is copied into a final result sheet or exported to a separate file or database.

Security

This section can be a short statement, i.e. “All non-input cells should be locked to prevent changes.” You can also include additional security settings if you are using either custom code or a third party add-on to implement multiple levels of security to control who can edit certain cells, run a macro or function, etc.

Test Protocols

The testing of any spreadsheet should prove that the requirements were properly implemented according the design specifications.

Installation Qualification (IQ) testing is usually limited to making sure the file is in a location where users can access the file, unless the workbook is part of a larger automation project. Operational Qualification (OQ) testing is mostly about verifying formulas, macros, and also to test the security of each sheet to verify that all non-input cells are locked to prevent changes. The IQ and OQ can be combined into a single IOQ protocol as needed.

To start generating our test cases, Once again, we like to break testing down into Inputs, Processing, and Outputs, but security testing is easier to test in separate test cases.

Process & Output Testing

These are usually easier to combine when writing test cases. Once again, FOCUS ON TESTING THE FORMULAS!

• Are formulas correct? There are several methods for verifying and testing formulas
• Continue testing until all input cells have had data entered on changed, and that result has been verified. The key point is to look for formulas that are incorrect or charts that are not using the correct or complete set of data, or are pointing to the wrong columns of data.
• Macros can be tested by entering a range of data and comparing the results with a hand calculator, or by visual inspection that the function performed as expected.
• Charts can be tested by a combination of visual inspection or verification of the properties, including the dataset used as the basis for the charts.

Security Testing

The type and amount of security testing that you can do for spreadsheets is largely based on how security has been implemented. At a bare minimum, you should test that users are limited to entering data into the defined input cells only, and that they do not have the ability to alter any other part of the spreadsheet. Failure to do this can compromise the integrity of the validation effort and of any data or information generated by the workbook.

Conclusion

This methodology will result in a User/Functional Requirements Specification, a Software Design Specification, and an IOQ Protocol ready for approval and execution. Any deviations found during testing can be handled according to existing validation practices, and a summary report that shows that all the activities specified in the Validation Master Plan or SOP can be generated.

About the Author

Tyson Mew is President of Ofni Systems, a regulatory compliance consulting, software and validation firm for FDA-regulated companies. They are the creators of the ExcelSafe software for adding full Part 11 compliance to Excel Spreadsheets, and also the FastVal Validation software for automating the generation and execution of many popular types of software application, including Excel spreadsheets. For more information, visit www.Ofnisystems.com.

Excel Complete – Validate your spreadsheets today!

If you would like to get a free quote on any spreadsheet validation project please feel free to contact us directly or view Excel Complete here.

The most extensive, searchable web-based validation and CGXP compliance database available, myCGXP currently comprises over 28,000 individual extracts from approximately 1,800 documents … and it’s growing every day.

myCGXP Validation Database

Stacked with the FDA and EU regulations and directives, FDA, EU and ICH guidance documents and FDA Warning Letters, myCGXP will soon also contain FDA Establishment Inspection Reports and links to PIC/S documents.

Cost Effective

myCGXP will save you countless hours of painfully digging through the ever-increasing library of regulatory documentation for validation and CGXP compliance information.

Free Trial

To register for a free, unconditional 2-week trial, simply follow this link www.mycgxp.com to the web site or enter www.mycgxp.com into your web browser, click on the red ‘register for a free trial’ button and follow the instructions.

Purchase a 12-month subscription during your free trial period and it will cost you only £299, which is a £156 saving on the normal price of £450.

If you would like to see a brochure first, you can download a PDF version by clicking the following link http://www.mycgxp.com/ProductInformation/mycgxp_product_brochure.pdf.

Please leave comments below.

Contact Details

Kieran Sides
Marketing Manager
Validation in Partnership Limited
34 Chester Road
Macclesfield
Cheshire
SK11 8DG
UK

Tel: +44 (0)1625 660880 (office reception)
Fax: +44 (0)1625 660881
e-mail: Kieran.Sides@vipltd.co.uk
Web: www.vipltd.co.uk

E-Learning Guru is an E-Learning solution provider based in Ireland but offering global solutions. The solutions we offer are professional, affordable off the shelf content, customised content design and Learning Management System (LMS) deployment services. We aim to leverage learning and training resources in your organisation to maximise their return.

E-Learning modules

We use up to date media development tools and methodologies, but in a manner to keep it simple, so our clients can maintain lessons once developed. We create e-lessons for all industrial and service sectors, covering a variety of topics. The e-lessons are cost effective and can include some or all of the following:

• Power point presentations with voice over
• Integrated Video and animations
• Interactive training simulations
• On line certification
• Demonstration presentations
• Interactive quizs

Mission Statement

E-Learning Guru has experience in the development of Blended Learning programs, the production of E-learning Course Material and implementation Learning Management Systems for Training. The company has a Team, which comprises Instructional Designers, Multimedia Developers, translators and IT experts. The team will develop E-learning in a simple manner that your company can use and maintain once delivered.

To provide cost-effective e-learning solutions to time poor trainers while enhancing return on training by 30-40% over conventional methods

Why Us

There are a number of reasons why you should work with us these include:

• The team has over 15 year experience in regulated industries.
• The team has a variety of experts to meet our customer’s needs and expectations.
• The team is supported externally and in touch with the latest E-Learning technologies.
• A proven track record of quality work.
• Our service is cost effective, so you can get more from your training budget.

The services we can deliver:

• Transfer of power point presentations into E-Learning format.
• Transfer of company VCR/DVD’s into E-Learning.
• Creation of customised lessons using your internal experts, photos and video of the process.
• Media-based animations of process and procedures.
• Interactive software simulations.
• Randomised questions in a graded quiz.
• SCORM compliant lessons.

Premier Validation

We are please to announce our recent partnership with Premier Validation and AskaboutValidation. This partnership will allow both companies to deliver high quality validation and quality e-learning modules to the Life Science market.

Contact Details

Millmount Enterprise Centre,
Drogheda,
Co. Louth.

Phone: 00 353 (0) 76 6224848
Fax: 00 353 (0) 1 6904136

Web: www.elearningguru.ie
Email: info@elearningguru.ie

For a major (top 10) multinational manufacturer and supplier of standard, configured and customised equipment systems to the pharmaceutical and biopharmaceutical industries, ViP SCRIBE has just reduced the time taken to generate a complete system life-cycle testing and verification documentation pack from 6 hours to 15 minutes. This will save the company hundreds of thousands of dollars a year … every year!

In the life of an equipment system, testing and verification documentation (protocols, record sheets and reports) will be required at some or all of the following stages:

• Specification (Functional Design and Test Specifications)
• Assembly/System Build
• Factory Acceptance
• On-site Installation
• Commissioning
• Site Acceptance
• Installation Qualification
• Operation Qualification
• Ongoing Servicing
• Requalification
• Decommissioning/retirement

Life-Cycle Document Deliverables

Once the manufacturer and customer have agreed the equipment and life-cycle document deliverables, ViP SCRIBE can generate the complete testing and verification document set in no more than 15 minutes. The user-friendly interface makes it simple to assign the equipment configuration, the operating parameter set-points and tolerances, the verification checks and tests, and the document style (company’s own or the customer’s) to the selected documents.

The minimal user involvement means there are no transcription errors, and the speed of generation means each protocol, and associated record sheets, can stay in the system until just before they need to be reviewed and approved for execution. This ensures that all last minute changes can be accommodated and there are no document inaccuracies to cause deviations.

If you are an equipment manufacturer wanting to make similar cost-savings, contact Kieran Sides using any of the means below to arrange for a ViP SCRIBE demonstration.

Contact Details

Kieran Sides
Marketing Manager
Validation in Partnership Limited
34 Chester Road
Macclesfield
Cheshire
SK11 8DG
UK

Tel: +44 (0)1625 660880 (office reception)
Fax: +44 (0)1625 660881
e-mail: Kieran.Sides@vipltd.co.uk
Web: www.vipltd.co.uk