PHARMA LAB · PL-01-002

HPLC/UHPLC URS: Requirements, Modules and Software

Turn QC needs into verifiable HPLC/UHPLC requirements: a twelve-row matrix, five rewritten requests and a practical route from intended use to approval.

Generic liquid chromatography system beside blank planning cards, sample vials and a capped column on a laboratory bench.

An HPLC/UHPLC URS should explain what the laboratory needs to achieve and how fulfilment will be demonstrated. Start with methods, samples, workload and data handling; then connect those needs to instrument modules, software, installation and support. A copied catalogue range or a statement that software is “compliant” is insufficient. A useful requirement identifies a result or function, the conditions under which it matters, the evidence needed and the person who will accept it. Numerical criteria must come from the laboratory’s intended use and applicable requirements, not from this article.

This article proposes a GuideGxP working approach for pharmaceutical QC. The examples are planning examples, not approved requirements or a qualification protocol. EU GMP references concern the applicable human-medicines context; assess requirements separately for other jurisdictions and activities. URS means User Requirements Specification.

Start with intended use

Describe the work before describing the equipment. List approved methods and versions, analytes, matrices, concentration ranges, solvents, columns, injection volumes and detectors. Identify routine release, stability and development activities separately. Mark the methods that must continue unchanged and those for which a controlled transfer is planned. A proposed instrument may cover the nominal operating range yet require a configuration that changes method behaviour.

Measure workload as complete sequences and time to an accepted result. Include blanks, standards, equilibration, washing, preparation, review and interruptions. Distinguish a present requirement from an expansion preference and give the forecast a basis. “More samples” does not establish how many sample positions, which cooling capability or how much data storage is needed.

Keep three statements separate: the user requirement is the needed outcome; the technical solution is how a proposal will achieve it; the supplier specification is a declared capability under stated test conditions. A design constraint can be justified, for example compatibility with an existing controlled data environment, but it needs a rationale. Annex 15 makes the URS a lifecycle reference, rather than a purchasing document discarded after delivery. [1]

Define requirements for the modules

Pumping and mixing. Connect flow range, composition delivery and pressure capability to the actual method portfolio. Ask which solvent compositions, temperatures and configurations support the proposed performance. Include gradient behaviour where method continuity depends on it. Do not turn the maximum pump pressure into a universal operating setpoint or prescribe a mixing design without an analytical reason.

Sampling and injection. Define usable injection volumes, sample containers, available sample quantity, temperature needs and sequence duration. Link carryover control to the concentration range and analytical decision. A response-repeatability claim does not, by itself, demonstrate delivered-volume accuracy or acceptable carryover for your samples. Identify the sample and wash conditions used for any demonstration.

Column compartment and detector. Specify column formats and connections, the temperature conditions needed by the methods and how temperature performance will be assessed. Select detection capabilities from analytes and reporting needs: wavelength range, acquisition of relevant narrow peaks or other technology-specific functions. A specification obtained with one cell or acquisition setting may not describe another configuration. Record necessary accessories explicitly; an omitted cell or connection can change the useful system.

Set performance requirements and acceptance criteria

For each critical characteristic, identify the required operating interval, representative conditions and conditions that challenge the intended use. Choose test points and acceptance criteria before execution, with a documented basis. Method knowledge, applicable compendial requirements, measurement uncertainty and justified manufacturer information can play different roles; none supplies one automatic tolerance for every HPLC system.

For example, “flow suitable for the approved method set” needs a defined method inventory, relevant liquids and operating conditions, a comparison approach and a justified decision rule. A catalogue specification measured under different conditions is supporting information, not evidence that the intended application has passed. If essential knowledge is missing, record an open decision, an owner and a closure date before procurement commitment or the relevant approval gate.

Separate module performance from the analytical result. A detector test and an application demonstration answer different questions. ICH Q14 supports linking analytical procedure development to intended performance; it is not a purchase specification or an instrument certification. The qualification plan will translate the approved requirements into appropriate tests without making every requirement an identical OQ test. [2]

Specify software, records and interfaces

Define the boundary of the chromatography data system (CDS): instrument control, acquisition, processing, calculations, review, reporting, storage and connections to other systems. Name the process owner and system owner. Identify records that must remain available, including raw data, methods, sequence information, relevant metadata and processing history. A PDF result alone may not preserve the records needed to reconstruct the analysis.

Describe user roles and the actions each role may perform. Include how access is granted, changed and withdrawn, how relevant changes are recorded and reviewed, and how records remain readable. For audit trails, specify the relevant events and review workflow according to risk and applicable requirements. Ask for a demonstration using the proposed configuration, not a generic compliance slide. Annex 11 addresses lifecycle traceability, data controls and responsibilities; purchasing a product does not discharge the laboratory’s obligations. [3]

Turn “backup available” into a recovery requirement: which records, who operates the backup, what loss and recovery constraints are acceptable, and how restoration will be demonstrated. For an interface, define identifiers, units, status, error handling and reconciliation. A successful connection does not prove that a result retains its meaning after transfer. This is the URS boundary; detailed CDS architecture and validation belong in the corresponding controlled project documents.

Plan installation and routine operation

Check the proposed bench footprint, load, access for maintenance and surrounding environment against the actual room. Define power and network prerequisites, ventilation and solvent/waste arrangements through the site’s safety assessment and equipment instructions. Do not assume every LC configuration needs the same gas supply, extraction or utility. Identify who supplies each prerequisite and how readiness will be confirmed before installation.

Include solvent compatibility, safe containment, waste capacity and access to isolations. Pressure, electricity, heat and solvent hazards require controlled procedures and competent personnel; a URS should never demand bypassing protective functions to meet throughput. For training, specify the roles and tasks to be covered and how readiness for independent work will be demonstrated. Attendance at a presentation alone is not the same as demonstrated capability.

Request a maintainable configuration: identify routine tasks, permitted user interventions, specialist support, essential consumables and spare parts. Clarify whether accessories, reference materials, qualification support and initial training are included in the quote. Record dependencies on laboratory staff, IT, facilities and external support so that delivery of a crate is not mistaken for operational readiness.

Compare documentation, support and quotations

Ask each bidder to respond against the same requirement IDs, with the offered configuration and evidence reference. Useful response categories are fulfilled, fulfilled subject to a stated condition, not fulfilled and evidence pending. Treat them as claims to assess. A qualification package can be a deliverable, but its suitability, coverage and unresolved gaps still require laboratory review.

Specify the document set and usable format: module and software identification, installation requirements, manuals, configuration records, test results, relevant reference certificates and service records. Establish which software versions, licences and interfaces are included. Ask how support withdrawal, replacement parts and upgrades will be communicated, and distinguish a response-time commitment from a guaranteed repair time.

Compare total implementation scope before comparing price. One quotation may exclude network work, method transfer, additional training, data migration or repeat visits. Record exclusions alongside costs, owners and deadlines. A signed supplier declaration is not a substitute for evidence of a critical capability. Chapter 6 places laboratory controls and records within the quality system; the precise purchasing matrix below is a GuideGxP recommendation. [4]

Trace, review and approve the URS

Give each requirement a stable ID, a reason and a criticality assessment. Link it to the proposed configuration, verification activity, evidence and acceptance decision. Separate mandatory conditions from preferences; do not let a favourable weighted score cancel an unmet mandatory requirement. Assign QC, quality, IT, safety and procurement responsibilities according to the site’s organisation.

The following original matrix illustrates twelve requirement families. Each row needs refinement into individual, unambiguous statements where necessary. “Define” identifies a decision for the project team, not permission to leave acceptance criteria open when the relevant test starts. The roles are examples, not a universal approval hierarchy.

IDUse / riskVerifiable statementCriterion to defineVerificationEvidenceOwner
U01Method continuitySupport the approved method inventory in the offered configurationMethods, permitted changes, required outcomesDocument review and application comparisonConfiguration and comparison recordsQC
U02Flow-dependent resultsDeliver the required flow under specified liquid and operating conditionsInterval, deviation, repeatability and decision ruleReference comparisonOriginal readings and calculationsQC / metrology
U03Gradient compatibilitySupport the gradient profiles selected for the method setProfiles and relevant mixing/delay characteristicsConfiguration review and appropriate testSettings and test reportQC
U04Sample availability and contaminationInject the required samples using compatible containers and wash conditionsVolumes, repeatability and carryover impactRepresentative sample sequencePreparation and sequence dataQC
U05Temperature-sensitive workMaintain required column and sample conditionsLocations, interval, stability and applicable limitsAppropriate reference measurementReference status and temperature recordsQC / metrology
U06Detection of relevant peaksAcquire the signals needed for the selected proceduresTechnology-specific range and performanceDetector and application checksAcquisition settings and resultsQC
U07Unauthorised changesRestrict actions according to approved user rolesRole/action matrix and relevant event recordsPositive and negative role testsAccess and event evidenceSystem owner / quality
U08Loss of analytical recordsRestore complete usable records after an agreed recovery scenarioRecord scope, recovery time and acceptable lossControlled restore exerciseRecovered records and reconciliationIT / process owner
U09Interface errorsTransfer results with preserved identity, value, units and statusMappings, errors and reconciliation rulesInterface challenge testsSource/target comparison and error logIT / QC
U10Unsafe or unsuitable installationOperate in the approved site arrangementSpace, utilities, environment and safety prerequisitesSite-readiness reviewApproved layout and readiness recordFacilities / safety
U11Uncontrolled downtimeProvide the agreed maintenance and support deliverablesTasks, response commitments, parts and exclusionsContract and service reviewService scope and responsibilitiesEquipment owner / procurement
U12Unverifiable acceptanceDeliver the agreed configuration, evidence package and role-based trainingDocument list, formats and competence evidenceHandover reviewDelivery register and acceptance recordQC / quality

Five vague requests rewritten

Simulated planning case. A QC team receives a draft containing the following five claims. The exercise below does not invent acceptance values; it identifies the missing decisions and a way to make the requirement testable.

  1. “An accurate instrument.” Replace it with a requirement for the relevant measurand or performance: for example delivered flow under defined conditions. Collect the method interval, reference capability and analytical consequences of deviation. Define the comparison, uncertainty treatment and acceptance criterion; response repeatability alone does not settle accuracy.
  2. “Compliant software.” Replace the label with specified role restrictions, complete records, relevant audit-trail functions and review/recovery workflows. Collect the data-flow map and applicable obligations. Demonstrate configured functions and assign procedural responsibilities. There is no universal product certificate that makes the laboratory GMP compliant.
  3. “High throughput.” Specify the required workload completed within the agreed operating window, including controls, preparation and review constraints. Collect actual sequence durations and sample stability. Test a representative schedule; vial capacity or a short single injection is insufficient evidence.
  4. “Compatible with our methods.” Identify the approved method list and permitted changes. Collect existing configurations, gradient characteristics, detectors and critical separations. Agree a representative comparison and the change-control route; the same column connector is not proof of analytical equivalence.
  5. “Easy maintenance and good support.” Specify accessible routine tasks, required training, service coverage and the response arrangement. Collect failure history, permissible downtime and parts needs. Review the proposed maintenance workflow and contractual exclusions, not just an assurance of “excellent service”.

Approval checklist

  • Is each critical requirement tied to intended use and a responsible owner?
  • Are criteria and verification conditions defined before the relevant approval or test?
  • Does the quoted configuration cover modules, software, accessories and interfaces?
  • Are gaps, exclusions and open decisions visible, with actions and deadlines?
  • Can the evidence be retrieved by requirement ID, including unsuccessful tests?
  • Are changes version-controlled, reviewed for impact and approved by the authorised roles?

When an offer does not meet a requirement, decide whether to reject it, obtain a justified alternative or revise the requirement through controlled review. Do not silently rewrite the URS to match the purchased equipment. Preserve the previous version and explain what changed in intended use or evidence. A requirement remains useful after purchase when it supports qualification, changes and eventual replacement.

Can a supplier write the URS?

A supplier can help identify constraints and provide technical information. The laboratory still needs to own the intended use, assess the proposed wording and approve its requirements. A catalogue copied onto a controlled form does not perform that assessment.

Does every requirement need an instrument test?

No. Some are verified by inspection, document review, a software scenario or a service agreement. Match the evidence to the claim and its risk. A contract can establish a support commitment; it cannot demonstrate chromatographic performance.

Sources and scope

Checked on 28 September 2026. The matrix and worked examples are GuideGxP planning recommendations. No universal performance limits or product certification are asserted. The full applicable USP 〈1058〉 chapter was not accessible; no detailed clause is attributed to it.

  1. European Commission — EU GMP Annex 15, Qualification and Validation (2015), §§2–4. Current document listed in EudraLex; apply according to scope and risk.
  2. FDA — ICH Q14, Analytical Procedure Development (March 2024). Final guidance for analytical procedures, not hardware certification.
  3. European Commission — EU GMP Annex 11, Computerised Systems (2011), §§1–12. Relevant lifecycle, responsibility, record and access provisions.
  4. European Commission — EU GMP Chapter 6, Quality Control (2014), §§6.6–6.7, 6.15–6.16. Laboratory records and analytical control in the applicable GMP context.
Technical content for informed decisions; it does not replace the approved procedure, applicable requirements or the instrument manual.

Continue exploring