Summary:
In a GxP environment, the software to be acquired should be fit for use. In order to meet the user requirements, one buys software that can be used as-is, with configuration, or custom-developed. To ensure the appropriate documents are included in the qualification package, it is essential to identify the relevant qualification documents for each scenario. This article explores how the software classifications, defined in GAMP 5, aid in determining the necessary qualification documentation for software in Categories 3, 4, and 5.
Defining Software Qualification Requirements:
When a pharmaceutical company, be it a manufacturer or a CRO, purchases software for use in a GxP environment, they must create a clear and detailed User Requirement Specification (URS) that outlines their needs. In response to the URS, the software vendor(s) submit a Functional Specification (FS) that describes how their software will address the user requirements. All URS requirements must be tested and proven through qualification. A Traceability Matrix (TM) is a document that maps each specific requirement within the URS to corresponding testing scripts.
Every software qualification workflow requires a URS, FS, and TM to ensure that each requirement is properly addressed, tested, and fulfilled. The other documents in the qualification package depend on the category the software falls under per GAMP 5.
Category 3 consists of Commercial Off-the-Shelf Software (COTS) that is used as-is; for instance, Microsoft Excel (without macros), or statistical tools like JMP and Minitab. The qualification objective for such software is to ensure proper installation and expected performance. For software installed on a computer or server, Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) must be completed. For Software as a Solution (SaaS) applications, since the software is pre-installed on the cloud, a simplified IQ may be conducted together with a full OQ to comprise an IOQ, and a PQ test is performed.
Category 4 encompasses software that is configured without changing the code. Examples include Laboratory Information Management Systems (LIMS) or Manufacturing Execution Systems (MES), where modifications can be made to templates, forms, or workflows without changing the main software. Another example is an Excel sheet that has been configured for a specific use without macros or Visual Basic code. In addition to the qualification documents specified for Category 3 software, configured systems require a Configuration Specification (CS) to document the changes or settings that have been made.
Category 5 includes software developed from scratch or that has undergone code modifications. One example is an Excel sheet that has macros, scripts, or Visual Basic code added. These systems are unique to a company and may be developed in-house or by an external vendor. Testing for Category 5 is more detailed, involving unit, integration, and full system testing to ensure that all components function as intended. This is critical, as even minor code changes can impact performance. The same documents that are required for Category 4 are also required for Category 5. Additionally, a Design Specification (DS) is needed to explain the software construction, since the logic has been modified or custom-developed.
Conclusion:
Identifying a software’s category under GAMP 5 is not always clear. One does not decide on the basis of the software name; rather, it depends on its usage. The same software can potentially belong to any of the three categories—category 3 if used as-is, category 4 if configuration is required, or category 5 if custom coding is required. Higher the category classification, more extensive is the documentation and testing requirements.