Lab Instruments & CDS
Chromatography Data System
This class covers the analytical instruments a regulated laboratory runs — chromatographs, spectrometers, balances, dissolution baths, particle counters — together with the software that acquires, processes, and reports their signals. The chromatography data system is the archetype: it controls the HPLC or GC, acquires the detector signal, integrates peaks, applies the processing method, and produces the result that goes forward to the LIMS. This is where the laboratory's raw data is created, and in most architectures where it stays. Everything downstream — the reportable result, the certificate, the batch decision — is derived from what these systems captured and how it was processed.
What this page does not claim
A system class is not a product. SPEQ describes what a CTMS or a LIMS is; the vendor directory at /tools lists the products that implement one, and a GAMP category is a property of an implementation, not of a class.
What a Lab Instruments & CDS actually is
This class covers the analytical instruments a regulated laboratory runs — chromatographs, spectrometers, balances, dissolution baths, particle counters — together with the software that acquires, processes, and reports their signals. The chromatography data system is the archetype: it controls the HPLC or GC, acquires the detector signal, integrates peaks, applies the processing method, and produces the result that goes forward to the LIMS. This is where the laboratory's raw data is created, and in most architectures where it stays. Everything downstream — the reportable result, the certificate, the batch decision — is derived from what these systems captured and how it was processed.
Qualification of the instrument and validation of the software are one lifecycle seen from two sides. USP <1058> Analytical Instrument Qualification frames the instrument through the 4Q model — design qualification, installation qualification, operational qualification, and performance qualification — and groups instruments by complexity, from simple apparatus needing only conformance checks to computerised systems needing both qualification and software validation. GAMP 5 frames the software. An HPLC with a CDS sits at the intersection: the pump and detector are qualified, the acquisition and processing software is validated, and the analytical procedures run on it are validated under ICH Q2(R2) within the lifecycle ICH Q14 describes.
No system class has produced more data-integrity findings. Chromatographic integration is judgement encoded in software: integration parameters, manual baseline placement, and reprocessing can move a result across a specification limit without any raw data changing. The recurring findings — trial injections, peak shaving, reprocessing until passing, disabled audit trails, orphan data on standalone workstations — are the reason MHRA's 2018 GxP data integrity guidance and PIC/S PI 041-1 devote so much attention to laboratory systems, and the reason audit-trail review of processing activity is now a standing expectation rather than an enhancement.
Architecture drives most of the risk. A networked CDS with central storage, domain authentication, and system-level audit trails is a controllable estate; the isolated instrument workstation — local accounts, local data, software often too old to secure — is where inspectors go looking, because data deleted from a local drive was never anyone's record. The direction of travel is consolidation onto networked platforms, automatic transfer of results to the LIMS, and treating the long-term readability of proprietary raw-data formats as an archiving obligation in its own right: a chromatogram that can no longer be opened has not been retained.
WHERE THE BOUNDARY ACTUALLY SITS
Not the sample's system of record. Sample lifecycle, specifications, and the reportable result live in the LIMS; this class produces and processes the raw data behind that result.
LIMS owns it →Not the process historian. In-line process instrumentation and its time-series data belong to the automation layer; this class is the analytical laboratory's measurement estate.
Historians, SCADA & PLC owns it →Not an archive by default. Raw data retention, backup verification, and the long-term readability of proprietary file formats are obligations that must be engineered, not assumed from the fact that files exist on a disk.
Not where an aberrant result is investigated. Reprocessing history is evidence for the investigation, but the investigation itself is a quality record in the eQMS.
eQMS owns it →WHAT IT HOLDS, AND WHAT CROSSES ITS BOUNDARY
CORE RECORDS
- Raw data files — injection sequences, detector signals, spectra — with their acquisition metadata
- Processing methods, integration parameters, and every manual integration event
- Audit trails covering acquisition, processing, reprocessing, and deletion attempts
- Instrument qualification records — DQ/IQ/OQ/PQ per USP <1058> — and calibration history
- System suitability results for each analytical run
- Processed results and the processing version that produced the value reported to the LIMS
DATA FLOWS OUT
Processed, reviewed results transferred against the sample worklist, with units and significant figures preserved
Aberrant-result and audit-trail-review findings escalated into laboratory investigations and data-integrity events
Historical chromatographic and spectral data supplied as training and monitoring input for anomaly-detection models
HOW THIS CLASS IS USUALLY VALIDATED
- SPEQ synthesis: a CDS is typically approached as GAMP 5 Second Edition (2022) Category 4 configured software running on qualified Category 3 instruments, with USP <1058> carrying the instrument side through the 4Q model. The category belongs to the implementation, not the product, and firmware, acquisition software, and custom processing macros in one estate routinely span categories.
- Integration and processing configuration is the highest-risk element: processing methods, integration events, and who may manually integrate determine whether a result can be moved across a limit, so these controls are verified directly rather than inherited from the supplier.
- Technical controls beat procedural ones where the software offers them — enforced audit trails that users cannot disable, role separation between acquisition and review, and no local administrator rights for analysts.
- The result-transfer interface to the LIMS is validated end to end, because a transformation error between processed result and reportable value defeats the integrity of both systems.
SPEQ synthesis, not a rating. This is SPEQ’s reading of how this system class is commonly approached, offered to help you scope your own work. A GAMP category is a property of a specific implementation, not of a product class, and one deployment routinely spans several. It is not a classification service and does not replace your own documented risk assessment.
- Stage 1 · Reactive
Instruments run as standalone workstations with shared local logins and data on local drives. Results are printed and transcribed; reprocessing leaves no reviewed trace, and what was deleted was never known to exist.
- Stage 2 · Defined
Instruments are qualified on a schedule and key systems have individual accounts with audit trails enabled. But data still lives per workstation, audit trails are reviewed only when a problem surfaces, and integration practice varies by analyst.
- Stage 3 · Controlled
A networked CDS centralises acquisition and storage, manual integration is procedurally bounded and technically logged, audit-trail review of processing activity is scheduled and evidenced, and results transfer to the LIMS without transcription.
- Stage 4 · Predictive
Processing behaviour is analysed as a signal: manual-integration rates, reprocessing frequency, and system-suitability trends are monitored per method and per analyst, and drift triggers method or training action before results are threatened.
- Stage 5 · Adaptive
The instrument estate is managed as a data architecture — harmonised processing policies, automated flagging of atypical processing, raw data feeding trending and modelling downstream, and archiving that guarantees readability across system generations.
SPEQ’s shared five-stage progression, labelled synthesis. It is not the FDA QMM rating scale and not the scored maturity-assessment domains — assess your quality system for those.
WHAT AN INSPECTION PROBES, AND WHERE IT GOES WRONG
INSPECTION SIGNALS
- Manual integration practice — who may do it, how it is justified, and whether reprocessing history shows results walked across a specification limit.
- Orphan data: injections, trial runs, and aborted sequences on local drives that never reached a reported result.
- Whether audit trails on acquisition and processing are enabled, technically protected from the analyst, and actually reviewed against records.
- Instrument qualification currency against USP <1058>, including whether software changes and firmware updates re-triggered assessment.
- Account architecture on standalone workstations — shared logins and analyst administrator rights are findings in themselves.
COMMON RISKS
- Integration parameters tuned per injection to reach a passing result, invisible unless processing history is reviewed.
- Standalone workstations accumulating unmanaged raw data outside backup, retention, and review.
- Qualification treated as installation-time only, with no reassessment after software upgrades, moves, or major repairs.
- Proprietary raw-data formats becoming unreadable as software generations turn over, silently voiding retention.
- Result transfer to the LIMS by manual transcription, reintroducing the error mode the interface was meant to remove.
WHO WORKS IN IT, AND WHERE IT IS SHAPED
ROLES
- Analytical chemist / QC analyst
- CDS administrator
- Instrument qualification engineer / metrology
- Peer reviewer for processing and integration
- CSV analyst
DELIVERY-LIFECYCLE PHASES
[ POSITION IN THE FRAMEWORK ]
6 OF 7 DIMENSIONS · 25 LINKSThe analytical instruments and the data systems that acquire and process their signals — where the laboratory's raw data is born, integrated, and reprocessed; the origin of more data-integrity findings than any other class.
06 · QUALITY MATURITY — LAB INSTRUMENTS & CDS, REACTIVE TO ADAPTIVE
Instruments run as standalone workstations with shared local logins and data on local drives. Results are printed and transcribed; reprocessing leaves no reviewed trace, and what was deleted was never known to exist.
Instruments are qualified on a schedule and key systems have individual accounts with audit trails enabled. But data still lives per workstation, audit trails are reviewed only when a problem surfaces, and integration practice varies by analyst.
A networked CDS centralises acquisition and storage, manual integration is procedurally bounded and technically logged, audit-trail review of processing activity is scheduled and evidenced, and results transfer to the LIMS without transcription.
Processing behaviour is analysed as a signal: manual-integration rates, reprocessing frequency, and system-suitability trends are monitored per method and per analyst, and drift triggers method or training action before results are threatened.
The instrument estate is managed as a data architecture — harmonised processing policies, automated flagging of atypical processing, raw data feeding trending and modelling downstream, and archiving that guarantees readability across system generations.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 9
Derived from the 9 standards SPEQ maps to this subject, across 7 regulatory bodies: FDA, EMA, USP, ISPE, MHRA, PIC/S, ICH.
RECORDS & OBJECTIVE EVIDENCE
- Raw data files — injection sequences, detector signals, spectra — with their acquisition metadata
- Processing methods, integration parameters, and every manual integration event
- Audit trails covering acquisition, processing, reprocessing, and deletion attempts
- Instrument qualification records — DQ/IQ/OQ/PQ per USP <1058> — and calibration history
- System suitability results for each analytical run
COMMON INSPECTION FINDINGS
- Manual integration tuned per injection to reach a passing result, visible only in reprocessing history
- Orphan data — trial injections and aborted sequences on local drives that never reached a reported result
- Audit trails on acquisition and processing disabled, unprotected from the analyst, or never reviewed
- Instrument qualification not reassessed after software upgrades, moves, or major repairs
- Standalone workstations with shared logins and analyst administrator rights
Choosing, validating, and living with Lab Instruments & CDS
FREQUENTLY ASKED
How do USP <1058> qualification and computer system validation fit together?
They are two lenses on one system. USP <1058> Analytical Instrument Qualification addresses the instrument as a measuring device through the 4Q model — design, installation, operational, and performance qualification — scaled by instrument complexity. GAMP 5 and Annex 11 address the software that controls the instrument and processes its data. A dissolution bath with a firmware display may need little beyond qualification and calibration; an HPLC under a CDS needs both instrument qualification and software validation, planned together so neither assumes the other covered the interfaces, the audit trail, or the processing logic.
Why is chromatographic integration such a data-integrity focus?
Because integration is the one place where a result can be legitimately changed after acquisition. Baseline placement, peak-start and peak-end decisions, and reprocessing under a modified method can each move a value by enough to cross a specification limit, without touching the raw signal. That makes manual integration both a scientifically necessary tool and the preferred mechanism of laboratory data falsification. The expected controls are procedural bounds on when manual integration is permitted, technical logging of every integration event, second-person review of processed chromatograms, and periodic audit-trail review looking specifically at reprocessing patterns.
What is orphan data and why do inspectors look for it?
Orphan data is instrument data with no corresponding reported result — trial injections, aborted sequences, samples acquired and never processed, files sitting on a local drive outside any review. It matters because it is the residue of testing into compliance: the failing injection that was rerun until it passed leaves its evidence as orphan data. Inspectors reconcile injection counts against reported results and browse acquisition folders directly. The defence is architectural — networked storage, no local data, sequence-level reconciliation in review — rather than hoping local drives stay clean.
Should raw data live in the CDS or the LIMS?
Raw data stays in the system that created it, and the LIMS holds the reportable result — trying to make either system do both jobs weakens both. The CDS preserves the complete acquisition and processing record, including metadata and audit trails, in its native format; the LIMS receives the processed value through a validated interface and manages it through specification judgement, review, and reporting. What must be engineered is the traceable link between the two: from any reportable value, an inspector should reach the exact injections and processing version behind it without archaeology.