Home Industries Services Products Events Contact Rovisys
Pharmaceutical Home Design Documentation Commissioning Validation Integration Training - Validation Batch controls Electronic Batch Records MES Experience Project Experience Latest Trade Show Validation Automation Brochure (Adobe Acrobat PDF 300KB)

John Turk, Director Pharmaceuticals
330.995.8218


The RoviSys Company
1455 Danner Drive
Aurora OH 44202
330.562.8600

Southeast Office
2521 Schieffelin Rd.
Apex NC 27502
919.387.1200

Validation

When it comes to validation, there is no winging it. To create documented verification that a process will produce per the predefined specification, you have to know how to execute fully validatable designs.

You have to know in advance that what you describe will function as detailed. And there are plenty of details to cover. Validation impacts practically every area and phase of an automation project for pharmaceutical and biotechnology companies.

In executing large- and smaller-scale projects for some of the world’s leading pharmaceutical and biotechnology companies during the last decade, we’ve became validation savvy. We work with your validation requirements and staff to produce the validatable systems, descriptions and documents you need to move your project forward.

And as the requirements call for the creation of significant amounts of documentation, it also helps to know how early steps can make ongoing validation documentation easier to execute.

We base the engineering effort required to create validation protocols and documents on the GAMP guidelines, our validation experience and the clients’ method for validation. These documents incorporate the requirement, design, implementation and test and verification phases. The documents that make up these phases will ensure validation compliance of the completed system implementation. They include:

RoviSys’ complete validation services include:

  • Verification and qualification documentation
  • Verification and qualification execution

Qualification of product

User Requirement Specification (URS)

The URS defines what the system is supposed to do as determined by the user. It defines the functions to be carried out, the data on which the system will operate and the operating environment. The URS also defines any non-functional requirements including constraints such as time and costs and what deliverables are to be supplied. The emphasis is on the required functions and not the method of implementing those functions.

RoviSys can provide support in creating these documents by meeting with the customer and understanding your needs and wants. From these meetings, RoviSys will create a GAMP compliant URS document suitable for the user to distribute for peer review and ultimately for bid packages.

Quality and Project Plan

This document provides direction and focus for execution of the project. Per the GAMP 4.0 guidelines, this document defines how RoviSys will meet the user quality requirements. It defines the project activities to be performed, timing, who will perform each activity, the control mechanisms to be used and the deliverable items.

This document helps define how all the documentation requirements for the project will be met and leveraged from task to task. For example, possibly using the design specification for the bases of the field acceptance test protocol will be resolved in this document.

Using the RoviSys holistic project methodology along with the customer requirements and the guidelines from GAMP 4.0, the Quality and Project Plan provides a detailed roadmap of the project methodology and execution.

Functional Specification (FS)

The functional specification defines what the system will do based on the URS. The importance of the FS cannot be understated. It is the basis for design for the entire system and drives the focus for the design specification.

Part of the FS will include a traceability matrix, used to confirm all of the requirements specified in the URS have been met. Included in this matrix will be a brief description of the URS requirement along with the resolution of the FS. A traceability matrix is shown below:

URS Section

URS Section Description

FS Section

FS Section Description

Checked By

2.2

All interface connections between networks must provide redundancy to preserve data integrity.

3.1

A clustered server architecture will be utilized to ensure no single point of failure exists.

RK

4.1

Historical data must be retrievable on-line for 8-years.

2.2

The PI Server will include a 500 G-Byte hard disk to store 10,000 points for 8-years on-line.

JAT

Design Specification (DS)

The design specification provides a technical description of how functionality described in the FS will be implemented. This document will be the leading document used by project engineers to implement the control strategies. Details on alarms, interlocks, control modules, regulatory control and batch control are defined using tables and flow diagrams. Traceability between the FS and DS may be in the form of the traceability matrix described above or via a template that matches the FS and DS documents.

Test Protocols

Three specific areas of testing are required to demonstrate implemented design conforms to the requirements of the FS and DS. Test protocols require thoroughly testing the software structurally and functionally with sign-offs and expected results.

These tests include the following:

  • Development Testing–This testing is done by RoviSys without a customer witness to help discover and fix any errors before the FAT. Typically, the test document to be used for the FAT is used in this testing to make sure the system is ready for customer review.
  • Field Acceptance Testing–The FAT is typically completed at RoviSys with all the I/O simulated. This form of testing will ensure the software complies with the requirements. If the FAT is performed at a skid vendor’s site where the equipment is available, the testing will include instrumentation with less process simulation. Many times the items tested at FAT undisturbed for shipping to the site will not require SAT.
  • Site Acceptance Testing–The SAT is usually the first time when the software interacts with all the equipment. Typically the SAT repeats the FAT. Once again the test documents will require sign-offs and expected results.

Qualification

RoviSys writes and executes qualification protocols. Qualification activities formally verify the suitability of the system for use in the user’s facility. The qualification process is made up of the following components:

  • Installation Qualification-The IQ will formally verify the software is properly loaded, hardware installed correctly, instrumentation installed and calibrated correctly and basic system functions operate on power-up.
  • Operational Qualification-The purpose of the OQ is to demonstrate conformance to the FS by testing under normal operating conditions and abnormal conditions as required.
  • Performance Qualification–The PQ demonstrates system requirements have been met and the system is capable of performing the activities according to the URS while operating in its specified operating environment.