Operation Qualification

ולידציה – Operation Qualification – OQ- part 2

Posted on יוני 21, 2015 by אביב צברי

ולידציה – Operation Qualification – OQ- part 2

Protocol Preparation Overview

This article provide overviews of the main test procedures and verification, and their purposes. This OQ procedure is generic, and relevance of the test procedures and verifications provided below depends on the composition of the system under validation

:Note

As mentioned in the previous artcle on OQ Protocol Contents, the final contents of the OQ protocol are tailored according to the type and size of the system under validation. Since this document is generic, it covers test procedures that may not be necessary in small or simple systems

:Where relevant, the OQ procedure may consists of five main test procedures

HMI Screen Test Procedure – intended to verify that the HMI screens provide the graphic design and functionality required for properly monitoring and controlling the environmental conditions in the user's

Parameters Lists Verification – intended to verify that the system parameters lists comply with the values specified in the SSO

: Two types of parameters are checked

Process parameters

Alarm parameters

System Operation Test Procedure – intended to verify that system monitoring and control components are capable of maintaining the user's facility within specified temperature, humidity and pressure levels

System Alarms Test Procedure – intended to verify that when the specified temperature, humidity and pressure levels exceed its specified limits, an alarm message is displayed, and an SMS or e-mail notification is sent to relevant personnel

Test of HMI Compliance with 21 CFR Part 11 – This test is intended to verify that the HMI meets Valtech Cardio's URS regarding 21 CFR Part 11. These : requirements are divided into 5 categories for the sake of clarity

Security

Electronic Records

Audit Trail

HMI Screen Test Procedure

This section includes specific test procedures for all the relevant HMI screens, where each test procedure serves to verify that the specific HMI screen provides the graphic design and functionality required for its intended purpose within the monitoring and controlling functions

Parameters Lists Verification

:This procedure covers the verifications of two types of parameters

Process parameters

Alarm parameters

Process Parameters List Verification

This procedure is intended to verify that:

The system enables to set the default values of the process set-points of each monitored environmental parameter.

The system provides automatically the corresponding low and high limits of these default values. These limit values are listed in below

The system rejects all the SP values that exceed their allowed ranges, as specified in the SSO

Alarm Parameters List Verification

:This procedure is intended to verify that

The system enables to set the default values of the alarm set-points of each monitored environmental parameter

The system provides automatically the corresponding low and high limits of these default values

The system rejects all the SP values that exceed their allowed ranges, as specified in the SSO

System Operation Test Procedure

This procedure is intended to verify that system monitoring and control components are capable of maintaining the user's facility within specified temperature, humidity and pressure levels. For this purpose, it is necessary to temporarily change set-points, in order to activate the control devices

System Alarms Test Procedures

This procedure is intended to verify that, when an environmental parameter value exceeds the specified normal range, the system reacts as specified in the SSO, by providing a specified alarm indication, a relevant e-mail alarm message, and relevant records in the Current Alarms and Historical Alarms screens

Test of HMI Compliance with 21 CFR Part 11

This test is intended to verify that the HMI meets the user's URS regarding 21 CFR Part 11. These requirements are divided into 5 categories for the sake of :clarity

Security

Electronic Records

Audit Trail

ולידציה – Operation Qualification – OQ- part 1

Posted on יוני 17, 2015 by אביב צברי

ולידציה – Operation Qualification – OQ- part 1

Protocol Preparation Overview

The Operation Qualification (OQ) protocol is part of the validation documentation that covers the verification of the proper operation of the system under validation in the user's facility. This OQ protocol is generic, and the system may include a PC with Human/Machine Interface (HMI), a Programmable Logic Controller* (PLC), pressure, temperature and humidity transmitters, and other monitoring and control components designed to maintain the user's facility in proper environmental conditions (temperature, pressure and humidity)

This OQ protocol is intended to verify that the system under validation operates according to the acceptance criteria specified in the Schedule of System Operation (SSO), and also meets the vendor's requirements and the user's specifications. It must be reviewed and approved prior to the OQ performance

OQ Protocol Contents

The OQ protocol is structured in a relatively standard fashion, with predetermined chapters and sections, where the final contents are tailored according to the type and size of the system under validation

:The chapters and sections of an OQ protocol are

Documents Verification – procedure intended to verify that all the documents required for performing the OQ procedure are approved and available

OQ Test Procedures – this is the main part of the protocol, and provides the description of the test procedures and the result tables for filling and approving the test results

: Note

As the final contents of the OQ protocol are tailored according to the type and size of the system under validation, and this document is generic, it covers test procedures that may not be necessary in small or simple systems

Documents Verification

:This procedure is intended to verify that all the documents required for performing the OQ procedure are approved and available. These documents are

Functional Requirements Specification (FRS)

Installation Qualification (IQ) Protocol

Piping and Instrumentation Drawing – P&ID

Input/Output (I/O) List

Schedule of System Operation (SSO)

OQ Test Procedures

This chapter contains all the test procedures or verification required to verify the system under validation is properly installed and can be properly operated according to the supplier's requirements and user's specifications

:Each test procedure or verification must include the same contents

Purpose or Objective

Procedure or Method

Acceptance Criteria

Test Results

*Here are some examples of the PLCs used by smartlogic: 6XV1830-0EH10, 6ES7131-4BF00-0AA0,6ES7193-4CA40-0AA0,6ES7134-4GD00-0AB0,6ES7193-4CA40-0AA0, 6ES7138-4CA01-0AA0,6ES7193-4CC20-0AA0, 6ES7590-1AB60-0AA0, 6ES7511-1AK00-0AB0, 6ES7954-8LP01-0AA0,6ES7155-6AU00-0BN0

ולידציה – GAMP – Test Example – part 3

Posted on יוני 8, 2015 by אביב צברי

Good Automated Manufacturing Practice (GAMP) – Test Example

Testing Process Automation Systems

This article cover the third part of our Good Automated Manufacturing Practice (GAMP) test example. This part will cover the typical test phases for Factory Acceptance Test – FAT, Site Acceptance Test – SAT / Installation Qualification – IQ, Operation Qualification – OQ and Performance Qualification – PQ

Typical Test Phases – GAMP – Test Example

Typical test phases for a complex process automation system. This example assumes that the system is configured by a Supplier and delivered to site after a FAT. Test system can also be configured by the system integrator or by the User. In this case, the same coverage is required, but the test phasing and location may be different.

The User and Supplier should work together to develop an overall approach to testing that reflects the risk assessment output and ensures adequate test coverage of the functionality, whilst avoiding unnecessary repeated tests.

Factory Acceptance Test – FAT

Done at the Supplier's premises after Supplier's integration testing, and before the system is released for delivery to the User's site

The required coverage should reflect the relative risk priority associated with the system element under test. This coverage can increase if problem are found within the initial sample.

In determining the required coverage, the User needs to base decisions on the risk assessment output taking into account both the potential effect on product quality and safety resulting from the process, and the intrinsic risk likelihood associated with the method of implementation.

Before performing risk assessment to decide on the required coverage, the User should review the supplier's internal tests to confirm that they are adequately documented.

Site Acceptance Test – SAT / Installation Qualification – IQ

Done at the User's premises after installation of the system on site

:The required coverage should include

Checking that the full system, including HW, SW backups, and documentation has been delivered to site in a condition suitable to its intended purpose

Checking that the site environment suits the specification of the installed equipment: temperature, humidity, pressure, dust, vibration, interference, etc

Checking that the system has been correctly installed.

Demonstration the system still operates as it was when accepted during the FAT, typically by re-recording system components and versions, and by re-repeating a small sample of FATs on site

Testing any elements which could be adequately tested in the FAT environment, typically interfaces to other equipment, networks, etc

Re-testing, following remedial action on any element subject to conditional release at the end of the FAT