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

  • User Requirements Specification — Getting the Sequence Right.

    User Requirements Specification — Getting the Sequence Right.

    Most of us have written a URS with a system already in mind. The vendor had been shortlisted, sometimes already selected, and the document was drafted to formalise what had already been decided. The result is a URS that describes a product rather than defines a need. It cannot be used to challenge whether the selected system is fit for purpose, because that question was never genuinely open.

    This is the most common URS failure in the industry. Not vague language. Not missing signatures. The sequence. A URS written after vendor selection is not a requirements document. It is a justification; those of us who have reviewed enough of them know the difference.

    What the Regulators and ISPE Expect

    The ISPE definition is precise: the URS states what the system must do, not how it should do it. Every major GxP framework shares one expectation underneath the differing language: document what you need before you build it, and prove you did.

    The Annex 11 makes this more explicit than before. URS traceability to testing is no longer implied — it is mandatory. Risk management must be embedded from URS through to system retirement. The one-time IQ/OQ/PQ followed by silence is no longer a defensible position.

    What the URS Must Cover

    Every requirement in it must be verifiable — specific enough that someone can design a test, run it, and return a clear pass or fail. If it cannot be tested, it does not belong.

    The URS must cover, at a minimum:

    • Functional capabilities — calculations, safety functions, access controls, audit trails, and output formats
    • Data handling — data definitions, valid ranges, integrity controls, backup, and archiving
    • Technical performance — capacity, failover behaviour, and disaster recovery
    • Interfaces — with users, other systems, and equipment
    • Environmental and power conditions — the physical operating environment in which the system must function
    • Alarm requirements — including explicit identification of critical alarms
    • System automation — with clearly defined boundaries between systems
    • Data integrity requires its own attention. The URS must define what the system needs to do to satisfy ALCOA+ principles — data that is Attributable, Legible, Contemporaneous, Original, and Accurate, and beyond that, Complete, Consistent, Enduring, and Available. These are not abstract ideals. Each one translates directly into a testable requirement — audit trails, user access controls, timestamps, backup provisions, and data storage conditions.
    • Every requirement should state its category — Quality, Business, or HSE — and its source, whether a CQA, a CPP, a regulatory requirement, a risk assessment output, or an engineering standard. We must explicitly identify quality-critical requirements and write them with precision.

    Finally, not every requirement carries the same weight. Separating mandatory from beneficial and nice-to-haves keeps the qualification effort focused where it actually matters.

    What a GMP-Grade Requirement Looks Like

    The gap between a weak requirement and a defensible one is not technical knowledge. It is discipline, specificity, and process ownership.

    Weak Requirement GMP-Grade Requirement
    The system shall monitor temperature.The system shall continuously monitor storage temperature within 2°C–8°C(CPP), trigger a GMP-critical alarm within 60 seconds of exceedance, and maintain a tamper-proof audit trail per 21 CFR Part 11.
    The system should print labels correctly.The system shall restrict label reprints to QA-authorised personnel with an electronic signature, reason code, and a full audit trail of all print events and template changes.

    A requirement that cannot be tested has no place in a qualification programme.

    Five Failure Modes That Destroy URS Credibility

    These are not theoretical. They are the patterns behind real audit observations, 483s, and warning letters.

    1. Vague, untestable language. Robust, appropriate, user-friendly — these are not requirements. If a test cannot be written for it, it does not belong in the document.
    2. Vendor Brochure Transcription. A URS sourced from supplier documentation belongs to their sales cycle, not your process. Auditors notice immediately.
    3. No CQAs or CPPs identification. You cannot build a credible risk assessment on a document that fails to identify what is critical.
    4. URS Written Post-Selection. A URS written after vendor selection is not a requirements document. It is a justification.
    5. Never Updated After Go-Live. If your team has not updated the document to reflect the current validated state, it is a liability.

    Each of these patterns is recoverable before qualification begins. After a deviation occurs, they become the gap that an investigation cannot close.

    Conclusion

    A URS is only as useful as the process understanding behind it. Written early, classified correctly, and maintained through every system change — it is the document that gives every qualification activity its purpose. Written late, vaguely, or not at all — it is the gap an investigation will eventually fall into.

    Sindu K

    June 15, 2026
    Uncategorized
    ALCOA+, GMP validation, GxP Compliance, Pharmaceutical Validation, QMS, Quality Assurance, Regulatory compliance, User Requirement Specification

  • Who is actually Responsible for the URS?

    Who is actually Responsible for the URS?

    Synopsis:

    Before purchasing an equipment, software or instrument, regulatory requirement mandates that one documents what is expected of the proposed acquisition. While it may be tempting to rely on vendors for this, as they understand their product, they do not understand the business requirements. That is why the User Requirement Specification (URS) must be authored by the team responsible for this new acquisition. This article explains why a user-driven URS ensures the acquired entity genuinely matches user needs, moving it from basic functionality to real-world fit

    It All Starts with a Need

    Picture this. You have been asked to put together a URS for a new equipment/software/instrument.  If this requirement was identical or similar to one that you have purchased in the past, that makes your task easier.  But what if this is a brand-new requirement.  Where do you start? 

    Appendix D5 from the ISPE GAMP 5 guidance document says it the best when it states that each user requirement should be specific, measurable, achievable, realistic, and testable.   It is also a good practice to prioritize the requirements, typically in two or three levels: (mandatory (high), beneficial (medium), and nice-to-have (low)) Or (mandatory (high) and nice-to-have (low)).

    The Easy Way

    As a vendor, we very often get asked to provide a draft URS that the regulated company then uses as a basis to draft the requirement.  Is this the right approach?  It sounds logical, right? After all, vendors are experts in the products they sell. But here’s the catch — they are experts in their product, not your business process.

    Sometimes we receive a URS that lists a specific brand or model, even including specifications unique to that brand. This is not the intended purpose of a user requirement, which should describe what is the needed functionally, not prescribe a particular vendor or solution.  When this happens, it limits the scope of solutions, undermines competitive assessment, and can introduce bias or compliance risks. Such requirements do not reflect true user needs but rather pre-select a solution, making it harder to compare alternatives and potentially exclude options that better meet functional requirements. GAMP 5 guidelines recommend describing functional needs in clear, objective terms, avoiding references to specific suppliers unless it is absolutely necessary to do so for business reasons

      Understanding the Roles the RACI way

      How do we decide the roles of various stakeholders.  A RACI Matrix, a simple chart that outlines who does what, breaks down the roles:

      Responsible:  Team/end users responsible for the business process.  The end users or process owners are usually responsible for drafting the URS since they know the operational needs best.

      Accountable: Manager(s) responsible for the business process.  Oversees URS creation and ensures it meets desired goals

      Consulted:

      • Other departments to provide their input/expertise as the acquired product may influence their workflows
      • IT team for software/IT hardware requirements to provide input on technical feasibility and rollout implications
      • CSV team for software to include regulatory requirements
      • Vendor – provide input and give technical advice. 
      • Informed-Vendors so as to put together a function requirement specification. 

      What do the Regulators Say?

      The FDA, the EMA and others, have made their stance clear: every system must be “fit for its intended use.”  That phrase — fit for intended use — is powerful. It means the system should perform exactly as needed for your specific products and processes.

      And who defines that intended use? Not the vendor — you do.

      According to the FDA’s General Principles of Software Validation and EMA’s Annex 11 on Computerised Systems, the responsibility for defining and confirming suitability lies with the regulated user organisation for computerised systems.  But that principle doesn’t stop there. Under broader GMP guidance, such as Annex 15 on Qualification and Validation, the manufacturers are responsible for ensuring equipment is suitable for its intended purpose and for defining its requirements in a User Requirements Specification (URS) or functional specification.

      In short, the user determines what’s needed; the vendor shows how their product meets those needs.

      Why Ownership Matters?

      When the customer owns the URS, everything aligns. The equipment fits its real operational needs, and the system passes regulatory scrutiny because it was built for its true purpose. And most importantly, it saves time, money, and frustration down the road.

      When vendors take over the URS, it might seem faster, but it’s like letting someone else write your recipe — you’ll never get the exact flavour you wanted.

      ravi

      November 9, 2025
      Uncategorized
      Equipment Qualification, GMP Compliance, Pharmaceutical Validation, Quality Assurance, URS, User Requirement Specification

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