A Proposed Standard for the Documentation Used to Support Validation, Part 2

Back to A Proposed Standard for the Documentation Used to Support Validation, Part 1

Specification, Design, and Testing
As stated above, qualification documents should reference original specifications which define what must be tested. Figure 2 shows how the three main test documents (IQ, OQ, and PQ) can be linked to the three basic levels of specification (User Requirements Specification, functional specifications, and design specifications) of the equipment or system under development. A brief description of each specification document is given below. Figure 2 may be found in Section 7, Overview of Validation, of the GAMP Supplier Guide.

The Life Cycle Concept
The "life-cycle concept" is defined by the Pharmaceutical Manufacturers Association Computer Systems Validation Committee (PMA CSVC) as "an approach to computer system development that begins with identification of the customer's requirements, continues through design, integration, qualification, customer validation, control and maintenance, and ends only when commercial use of the system is discontinued." The "life-cycle" development concept applies well to any system which must be validated, computer or otherwise.

Figure 3, below, provides a "life-cycle" development framework which shows how both validation and development activities fit into this concept. It also provides an indication of which development activities fit with particular validation activities. Figure 3 is a modification of a GAMP diagram. The original diagram was modified to reflect the differences between packaged systems with PLC controllers and "stand-alone" computer systems. The original version of the diagram may be found in Section 7, Overview of Validation, of the GAMP Supplier Guide.

The "Life-Cycle" Model
Figure 4 shows the JETT Consortium's interpretation of the "life-cycle" model for packaged equipment with embedded software. A GAMP diagram was modified to provide a more detailed reference to the mechanical components and the part that they play in the design and test specifications. The original version of this diagram may be found in Section 8.3.1, Life-cycle Model, of the GAMP Supplier Guide.

Customer Responsibilities
Each Customer using the GAMP methodology will have a defined policy regarding system validation. For each system, the policy may be summarized by the following activities. These activities are the responsibility of the Customer (though the Supplier may be able, and, in some instances, required, to facilitate them).

• Identify the system -- each system which is critical to current GMPs must be identified and assessed.
• Produce a Validation Plan.
  
• Produce a User Requirements Specification.
• Audit and select a Supplier.
  
• Review and approve the Functional Specification and the design specifications -- the Customer must review and approve the Functional Specification and the design specifications produced by the Supplier.
• Monitor the development of the system -- the Customer must retain overall control of progress and must have the ability to review that progress against a plan (the Quality and Project Plan or equivalent).
• Review and approve the test specifications -- the system will only be accepted by the Customer upon the completion of a formal program of testing which will be approved by the Customer in advance.
• Produce the Validation Report.
  
• Maintain the system.

Supplier Responsibilities
Although the responsibility for validation lies with the Customer, the Supplier will, or may have, considerable involvement in some of the activities described above. Customers, therefore, believe that cooperation with the Supplier is vital to assist the process of validation. Those activities in which the Supplier will be involved include:

• producing the Quality and Project Plan and submitting it to the Customer for review and approval before the system is designed.
• producing the Functional and Design Specification and submitting it to the Customer for review and approval before the system is constructed.
• producing the Test Specifications and submitting them to the Customer for review and approval before the system is tested.
• assisting the Customer with system maintenance, change control, and security as appropriate.

Summary and Conclusions
The JETT Consortium, originally known as the Joint Equipment Transition Team, was formed in response to a perceived need to standardize validation documentation and, thus, to improve the documentation deliverables provided by Suppliers of new equipment. It was determined that, in order to do this, Customer/Supplier relationships would have to be improved and that this would require a joint effort by both Suppliers and Customers.

It was believed that this could best be accomplished through the use of an existing standard, such as the GAMP methodology, in which the Supplier's and the Customer's responsibilities are well defined. To that end, the JETT Consortium has proposed a methodology of prospective validation (as opposed to retrospective validation), which includes a standard "documentation package," based on the GAMP methodology to be included with purchases of new equipment.

The proposed standard "documentation package" includes the following documents:

• A Validation Plan, produced by the Customer, which defines the activities, procedures, and responsibilities for establishing the performance adequacy of the system.
• A User Requirements Specification, produced by the Customer, which defines, clearly and concisely, what the Customer wants the system to do and states any constraints and regulatory and documentation requirements.
• A Quality and Project Plan, produced by the Supplier, which addresses the Customer's concerns about the Supplier's Quality Management System and establishes an overall "plan of attack" for that specific project.
• A Functional and Design Specification, produced by the Supplier, which include the functional specifications, the software design specifications, the electrical hardware design specifications, and the mechanical components design specifications.

The functional specifications are a description of the system or equipment to be supplied in terms of the functions that it will perform. They are also the controlling specification against which the system will be tested and, therefore, the basis of the System Acceptance Test

The software design specifications are a complete definition of the software functions in sufficient detail that the software can be coded. They are also the controlling specification against which the software will be tested and, therefore, the basis for the Software Acceptance Test (discussed below).

• The electrical hardware design specifications are a complete definition of the control system hardware in sufficient detail to enable it to be built. They are also the controlling specification against which the control system hardware will be tested and, therefore, the basis for the Electrical Hardware Acceptance Test (discussed below).
• The mechanical components design specifications are a complete definition of the mechanical components which are not part of the control system in sufficient detail to enable the system to be built. They are also the controlling specification against which the mechanical components tested and, therefore, the basis for the Mechanical Components Acceptance Test (discussed below).
• A Software Acceptance Test Specification, produced by the Supplier and part of the factory acceptance testing, which defines the test procedures and acceptance criteria for the software. The JETT Consortium recommends that, whenever practical, the Software Acceptance Test procedures are performed using the system itself as the "test bench."
• An Electrical Hardware Acceptance Test Specification, produced by the Supplier and part of the factory acceptance testing, which defines the test procedures and acceptance criteria for the control system hardware.
• A Mechanical Components Acceptance Test Specification, produced by the Supplier and part of the factory acceptance testing, which defines the test procedures and acceptance criteria for the mechanical components.
• A System Acceptance Test Specification, produced by the Supplier and part of the factory acceptance testing, which defines the test procedures and acceptance criteria for entire system.

Opinions, suggestions, and recommendations may be forwarded to:

The JETT Consortium, Mitch Cook, Documentation Engineer, c/o The Paul Mueller Company, Inc., P.O. Box 828, Springfield, MO 65801-0828. Tel.: 800-683-5537, ext. 580.