For a PLC Qualification template to be compliant with FDA requirements; a chain of protocols and documentation must be established. In this chain of documentation the User Requirements specification (URS) is probably the single most important document to get "right". Since most documents, post the URS, will either fully, or partially, base their contents on the URS, it is essential that this document clearly, concisely and in a manner that is testable, specifies the exact requirements of the end user. It is also essential that these exact testable requirements remain attributable through the development of the Functional Specification (FS) and the Design Specification (DS) to the actual lines or groups of lines of code that enable them.
The Validation Master Plan (VMP), must be specific about this and all cGMP requirements, and instruct all personnel involved in the PLC Qualification template processes program, of the importance of maintaining this traceability through the Installation Qualification (IQ) - Operational Qualification (OQ) - Performance Qualification (PQ).
Traceabilty of URS functionality, to lines of code is an essential element in PLC Qualification Template (PQT). Once this traceability is establish future maintenance and modification of software is made much simpler and more manageable.
The guide-lines laid out in Good Automated Manufacturing Practices (GAMP 5), for the PLC Qualification template processes used in automated systems including automatic PLC validation template processes for manufacturing equipment, control systems, automated laboratory systems, manufacturing execution systems and computers running laboratory database systems; are generalized and none specific. Such guidelines are a useful when it comes to scoping your PLC Qualification activities. However it must be remembered at all times that the 'GAMP' series of publications are all collective ideas garnered from around the industry and at times, does try to be all things; to all people.
These discrepancies can; at times, mean certain sections appear to contradict other sections. On a recent project, when a group was set up to extrapolate a validation Risk Assessment (VRA) document from within GAMP 5 deliberations, they found they could not agree and four weeks later; they were still divided. Unable to reconcile their company's requirements with the alternative strategies given in the GAMP series of publications. It bodes well to never forget that GAMP 5 is a guide from the end users point of view. The actual legal requirements come from the regulators, and obviously takes precedence. Validation Online's computer and PLC Qualification template start with the development of a detailed three layer URS and progress through the VMP - IQ - OQ - PQ. Each of these documents are interactive fully detailed and simple to use. Each are preceded with an SOP which guides the user through all phases of protocol generation completion.
The verification that the end users requirements as detailed in the URS have been fully satisfied, is paramount to the equipment being correctly qualified. Often this is hard to verify since the traceability from URS functionality to the actual hardware or software utilized is lost in the various specification designations that range from the functional specification to the design specification to code requirements. However unless the effort is made to maintain this traceability, computer validation processes is easily flawed and future maintenance and or modifications can become extremely problematic.
The Validation Master Plan - VMP, must be specific about this requirement and instruct all personnel involved in the qualification program, of the importance of maintaining this traceability.
This testing verifies the execution flow of software, including decision paths, inputs and outputs, It also involves creating test cases, test vectors, oracles, and executing the software against these tests known values. The results are then compared with these expected or known values for correct behavior of the software. Because the number of execution paths and conditions increases exponentially with the number of lines of code, testing for all possible execution traces and conditions for the software is impossible.
Code inspections and testing can reduce coding errors; however, experience has shown that the process needs to be complemented with various other methods. One such method is static analysis. This somewhat new method largely automates the software verification process. The technique attempts to identify errors in the code, but does not necessarily prove their absence. Static analysis is extensively used to identify potential and actual defects in source code.
A code verification solution that includes abstract interpretation can be instrumental in assuring software safety and a good quality process. It is a sound verification process that enables the achievement of high integrity in embedded devices. Regulatory bodies such as the pharmaceutical regulators.
There is no regulatory requirement to re-validate a process as long as that process operates in a state of GMP control and no changes have been made to the process or output product, the process does not have to be revalidated. Whether the process is operating in a state of control is determined by analyzing day-to-day process control data and any finished device testing data for conformance with specifications and for variability.
When equipment is moved to a new location, installation and operation should be re-qualified. By comparing data from the original installation and operation qualification (IQ and OQ,) and the re-qualification, the manufacturer can determine whether there have been any changes in equipment performance as a result of the move. Changes in equipment performance should be evaluated to determine whether it is necessary to revalidate the process.
Part 820.75 of the regulation requires that validated processes be monitored and controlled so that when changes or process deviations occur, a manufacturer will know to review and evaluate the process and perform revalidation when appropriate. 21 CFR 820.75(c ) requires you to have documented procedures in place for evaluating; when revalidation is required.
Recent research has highlighted that in the pharmaceutical and bio-medical industry, thirty two percent of all equipment procurement is unsatisfactory. The major problem has been identified as companies not specifying in sufficient detail and or accuracy, what their actual needs are. The lack of a fully detailed company approved User Requirements Specification (URS), leads to many companies having to resort to otherwise un-necessary and costly retrospective actions in modifying the equipment or producing unspecified documentation or engineering drawings, post procurement. These extraneous GMP requirements often cost more than the equipment.
News for Today
This validation online combination protocol has been specifically designed to verify that all aspects of your spreadsheet conform to best practice and that the spreadsheet layout ensures consistent and accurate use and results. The tests and inspections normally authored in separate protocols have been assembled in one protocol which is divided into three sections. This protocol enables you to verify that your developed spreadsheet application is GMP compliant, thus avoiding 483s and warning letters. You can now validate your application with minimal documentation. Equipment Validation Protocol, validation online protocol template.