Skip to content
PQMS
  • Homepage
  • Products
  • About Us
  • Blog
  • Contact us
Login
Book demo
  • Instrument Classification: Why One Qualification Strategy Doesn’t Fit Every Instrument

    Instrument Classification: Why One Qualification Strategy Doesn’t Fit Every Instrument

    Every pharmaceutical QC lab relies on a diverse range of analytical instruments, from simple glassware to sophisticated analytical systems that incorporate sophisticated electronics and even a configurable software. As new instruments are procured, a fundamental question arises: Does this instrument require qualification? And if qualification is needed, what level of rigour is appropriate? Clearly, a pipette and an HPLC system demand very different approaches. Making this determination consistently each time an instrument is acquired requires a structured framework.  USP General Chapter <1058> “Analytical Instrument and System Qualification” addresses this need through a risk-based framework for Analytical Instrument Qualification (AIQ), ensuring qualification effort is proportionate to the instrument’s intended use, functionality, and analytical system complexity.

    From Function to Classification

    A typical laboratory contains a diverse mix of equipment: simple apparatus without measurement capability, instruments incorporating firmware and sophisticated electronics, and computerised systems connected to software or wider software platforms. This diversity leads naturally to the next question: How should they be classified?

    USP <1058> groups analytical instruments into three broad categories based on measurement capability and how complex the instrument is.  This tiered structure forms the foundation of a risk-based approach that avoids both over-qualifying simple equipment and under-qualifying complex systems — a balance that has become increasingly important as regulatory scrutiny around data integrity and analytical lifecycle management intensifies.

    A Closer Look at the Categories

    Each of the three groups, listed below, reflect a different level of effort required to demonstrate that an instrument is fit for its intended purpose.

    • Group A — standard laboratory apparatus without measurement capability and therefore the need to calibrate them. Basic functionality can be verified through visual inspection.

    Examples:  Glass beakers, volumetric flasks, magnetic stirrers, and vortex mixers.

    • Group B — Instruments that generate measurements or equipment that control experimental conditions thereby having an influence on analytical results.

    Examples:  Analytical balance, pH meter, laboratory oven, and thermometer.

    • Group C — computerised analytical systems where hardware and software together generate, process, calculate, store, or report analytical data. These systems require the highest level of qualification due to their functionality and complexity.

    Examples:  HPLC system with chromatography data system (CDS),

    The three groups represent the top level of the USP <1058> classification framework. USP <1058> further subdivides them into eight subcategories, enabling qualification activities to be matched more precisely to an instrument’s functionality and intended use. 

    The verification workload does not scale in a single leap from Group A to Group B to Group C – it escalates gradually across the subcategories.   Recognising these nuances allows laboratories to right-size their approach: minimal for A1/A2, structured and calibration-driven for B1, enhanced with calculation checks for B2, and further reinforced with method and configuration controls for B3.  For Group C, qualification effort expands further because these systems incorporate software, and their qualification fundamentals should align with GAMP 5 principles for computerised system validation — applying full 4Qs qualification for C1 with fixed vendor software, extending to configuration management for C2, and expanding again for C3 to include full software lifecycle documentation, custom code assessment, and interface testing. This graded approach ensures that verification effort remains proportionate to the risk each instrument poses to data quality.  The sections below explain the verification workload for each subcategory in turn.

      Sub-category Keyword Example Activity List
    A1No Metrological functionMagnetic stirrer (without temperature control) and vortex mixerVerification only.  Verification activity is limited to: A short, risk-based justification stating why no qualification is required.Confirming the equipment is present, correctly installed, and identified (asset tag, location).Visual observation that it operates as intended (e.g., the stirrer spins, the vortex mixes).Retaining the supplier documentation or operating manual.   No calibration, no performance testing, and no periodic requalification typically required.
    A2No user calibrationSieves and volumetric glasswareVerification only.  These items may have defined specifications (e.g., certified mesh size, Class A tolerance) but they are not calibrated by the user. Verification typically includes: A short, risk-based justification stating why no qualification is required.Installation/receipt check and asset identification.Visual confirmation of fitness for use and absence of damage.Retention of manufacturer certificates confirming compliance with compendial specifications.   Differs from A1 in that the specification is verified against supplier provided conformance document(s).
    B1Firmware-controlledAnalytical balance and pH meterVendor-supplied qualification package, typically covering FS,  IQ and OQ.Verification of the User Requirement Specification (URS) through executed IQ, OQ, and PQ.Routine calibration against traceable standards, with documented procedures and records.Periodic performance verification (e.g., daily balance checks, buffer verification for pH meters).Change control and requalification for firmware updates.
    B2In-built calculationsTOC Analyser and density meterAll B1 activities plus: Verification of built-in calculations against known reference materials or manually calculated values. OQ to challenge computational logic. Documented evidence that calculation algorithms are appropriate for intended use.
    B3User-defined routinesFTIR with custom methods and Gas Chromatography All B1 and B2 activities plus: Verification of user-defined methods through method-specific challenge testing. Documented control of method creation, review, approval, and version management.
    C1Non configurable  softwareStand-alone chromatography data system (CDS) with standard templatesVendor-supplied qualification package, typically covering IQ and OQ, aligned with GAMP 5 Category 3.Routine calibration and maintenance of hardware components against traceable standards, with documented procedures and records.Verification of the URS through executed IQ, OQ, and PQChange control and requalification for software patches and version upgrades.
    C2Configurable softwareELN with configurable templatesVendor-supplied qualification package, typically covering IQ and OQ, aligned with GAMP 5 Category 4.  Activities apart from that noted for C1 include:Documented Configuration Specification (CS) covering all user-configured elements (templates, workflows, user roles, calculations).  
    C3Custom softwareLIMS integrated with SAP and custom calculationsVendor-supplied qualification package, typically covering IQ and OQ, aligned with GAMP 5 Category 5.  Activities include:Software development lifecycle definition Documented Design Qualification (DQ)Source code review, structural testing, or thorough supplier assessment for custom-developed code.Comprehensive testing of custom calculations, workflows, and interfaces (e.g., SAP, LIMS, ERP integrations).

    As instrument functionality and analytical system complexity increase, so does the level of  documented activities needed to demonstrate fitness for intended use.

    Conclusion

    Instrument classification is the starting point for determining qualification effort. Rather than applying a uniform qualification strategy across all laboratory instruments, USP <1058> encourages a proportionate approach based on instrument characteristics, intended use, and system complexity. By matching the qualification package to the instrument’s role, laboratories can focus effort where it adds value while maintaining confidence that analytical systems are fit for their intended use.

    Reference:

    1. USP–NF General Chapter <1058> Analytical Instrument and System Qualification. USP–NF, official 1 June 2026.

    Sindu K

    August 1, 2026
    Uncategorized
    digital transformation, GAMP 5, group a, group b, group c, GxP Compliance, instrument classification, instrumnet qualification, pharmaceutical, Pharmaceutical Validation, User Requirement Specification
  • Demystifying GAMP 5 Software Classification: Understanding Categories 3, 4 and 5

    Demystifying GAMP 5 Software Classification: Understanding Categories 3, 4 and 5
    Demystifying GAMP 5 Software Classifications

    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.

    ravi

    November 5, 2025
    Uncategorized
    Computer System Validation, GAMP 5, GxP Compliance, Pharmaceutical Validation, Software Categories, Software Classification

Powering Quality from Lab to Label © 2025, Quascenta Pte. Ltd.