Understanding the basics of automation validation

If you are new to the pharmaceutical industry, or any other FDA-regulated industry, and are interested in learning more about validation as it pertains to automated systems, this article will serve as a high-level introduction to the basic concepts and standard requirements. Regardless of role, having a basic understanding of the concepts and typical documentation, will allow engineers to better appreciate the effort involved in ensuring compliance. Becoming familiar with the basic terminology will also help with conversations you may have with counterparts directly responsible for these items.

With over 40 years of experience supporting clients within the pharmaceutical, life sciences, and food and beverage industries, Matrix has been involved with the design and implementation of automated systems that are subject to FDA oversight, thus requiring varying levels of validation testing. As such, we have applied that knowledge to provide a list of common acronyms, identify applicable standards, and share details around typical documentation.

Acronyms

The following table includes a list of commonly used acronyms within the regulated industries.

Applicable standards

Not only does the FDA require certain guidelines be followed, ISPE has a technical subcommittee that has outlined a set of guidelines for manufacturers and users of automation systems in the pharma industry. The more widely recognized guidelines and standards are described below.

21 CFR Part 11. This particular FDA regulation is a popular ‘buzz word’ within the industry. It specifically pertains to electronic records and electronic signatures. Electronic records must be reproducible and non-modifiable, while electronic signatures must be associated with two uniquely identifiable traits, with the most common being a unique username and secure password.

Manufacturers that choose to create and maintain electronic records and utilize electronic signatures, rather than printing paper records and handwriting signatures must implement controls for the software and systems involved in processing the electronic data. This includes the necessary design documentation, validation testing, and audit logging and review.

GAMP 5. ISPE released a formal publication with the intent of providing guidance for ensuring compliance of computerized systems within a regulated environment. The latest installment, GAMP 5, provides a risk-based approach to compliant computerized systems. In simple terms, the document provides guidance on the entire lifecycle of an automation system; from design through development and validation testing.

Documentation examples

This section describes the various types of documentation that is common within the regulated industries, particularly within pharma. Most end-users will have standard templates for each type of document. In some cases, Matrix has provided these documents using our own templates.

User requirements specification. This document is typically generated by the end-user, as it captures their specific user requirements at a high-level. Oftentimes, the system integrator will support generation by providing content related to the technical aspects; however, the end-user maintains ownership of the document. This document then becomes the basis for the subsequent design documentation. An example requirement would be that ‘the system must restrict access to authorized personnel’.

Functional specification. To elaborate on the URS example, the FS would then describe what types of security groups must be configured and what their assigned privileges are.

Hardware design specification. The purpose is to capture the system hardware specifications. It will list all hardware components, including part numbers.

Software design specification. The purpose is to capture the specific details needed to achieve the requirements specified in the FS. It will include enough detail to allow the system to be configured. To elaborate on the URS and FS example, the SDS would then document the configuration settings required to setup the specific security groups.

Validation plan. The purpose of this document is to establish a testing strategy needed to validate the system. The plan outlines which deliverables are required, the corresponding source documentation (design docs and site procedures), and defines roles and responsibilities for the preparation and completion of the deliverables to meet end-user standards and FDA regulations.

Installation qualification. The purpose of an IQ is to verify that the system was installed and configured in accordance with the design documentation. This document is typically generated by the validation team with support from the automation team. The common thought is that you should be able to generate a protocol exclusively from the design documentation; however, it’s usually best to consult the automation team to ensure all aspects of the system are tested appropriately.

Standard items to test as part of the IQ include the following:

• Supporting documentation is available
• Hardware meets the minimum specified requirements
• Software and versions are installed per specifications
• Software configuration
• Backup configuration
• Security configuration
• Licensing management configuration

Operational Qualification. The purpose of an OQ is to verify that the system operates in accordance with the design documentation. This document is typically generated by the validation team with support from the automation team.

Standard items to test as part of the OQ include the following:

• Backup and restore functionality
• Connectivity and communications
• Security functionality
• Operational functionality
• Report generation and accuracy
• Licensing management

Performance qualification (PQ). The purpose of a PQ is to verify that the system performs as expected under normal real-world conditions, and also confirms that the necessary operational procedures are in place. This document is typically generated by the end-user; however, in some instances they might request support from the validation team to draft the protocol while they provide input. Since the design documentation doesn’t normally include process performance requirements, the information needed for this protocol would come from end-user-owned documentation and procedures.

Summary reports. The summary reports are generated following completion of each protocol. The purpose is to summarize the results of the testing that was performed, including any discrepancies that occurred and their corrective action. Each protocol typically has its own dedicated summary report.

The summary reports will be reviewed and approved by the end-user. Approval of the final summary report indicates that the system is ready for its intended use.

Requirements traceability matrix. This document is typically generated in conjunction with protocol generation. The purpose is to correlate the system requirements, as defined in the URS and design documentation, with their corresponding testing within the validation protocols. Since all system requirements have to be fully tested, this document provides assurance that nothing was missed.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.