Walk into a typical regulated lab and watch a sample journey. The analyst pulls a vial off a shelf, runs HPLC, prints the chromatogram, scans the printout, opens an Excel sheet, types in the result, takes a screenshot of the chromatogram, drags it into the COA template in Word, exports a PDF, emails the PDF to QA, and waits for approval.
Twelve steps. Nine opportunities to make a mistake. Three different document formats. Two different identity systems. Zero connected data.
A connected lab does the same workflow with the analyst doing one thing — running the sample — and the rest of the steps happening as data flowing between systems that already trust each other. Here’s what that actually looks like, and what it takes to get there.
The four systems every lab eventually needs
1. Instruments
HPLCs, GCs, balances, dissolution baths, IR spectrometers. Each one produces raw data in a vendor-specific format. The connected-lab job: ingest those formats into a single normalized data model. Either via vendor APIs, OPC UA, AnIML, file-watchers, or a smart middleware layer (e.g. SDC).
2. LIMS (Laboratory Information Management System)
The system of record for samples, tests, results, statuses and approvals. When you ask the lab “where is sample 2024-001247?” the LIMS is the single source of truth. Everything else is downstream of it.
3. ELN (Electronic Lab Notebook)
Where methods, raw observations, and unstructured science live. The LIMS knows what was tested; the ELN knows how it was tested. The two systems should reference each other — result in LIMS → method version in ELN, sample in LIMS → notebook entry in ELN.
4. Reports / regulatory output
Certificates of analysis, stability reports, deviation reports, regulatory submission packages. These should be generated from LIMS + ELN data on demand — not hand- assembled in Word.
The data-layer principle
The single most important architectural decision: one identity and one audit trail across all four systems. Same user, same role, same login, same audit trail when they touch any system. SSO + SCIM make this practical; everything else flows from there.
The anti-pattern: four systems with four user databases, four password policies, four audit trails. The auditor asks “who changed this result?” and the answer is “let me check four logs.”
Practical integration patterns
- Pull, not push. Have LIMS pull from instruments via vendor API or file-watch rather than asking instrument software to push to LIMS. Pull is more robust, auditable, and recoverable from failures.
- Idempotent ingestion. A re-ingested chromatogram should never create duplicate result records. Use a content hash + foreign key to dedupe.
- Bidirectional sample IDs. The instrument knows the sample by its barcode; the LIMS knows it by its sample ID. The mapping table is its own first-class entity, audit-tracked.
- Methods as immutable records.When an analyst runs a sample with method v3, that result is forever tied to v3 — not to whatever the current version is.
The case for one vendor (and the case against)
Big vendors (LabWare, STARLIMS, etc.) sell a suite that covers all four systems. Pros: integration mostly works out of the box. Cons: licensing costs, slow product evolution, vendor lock-in for a decade.
Specialized vendors give you a best-in-class LIMS + best-in-class ELN + best-in-class instrument middleware. Pros: better individual products, faster product evolution. Cons: you own the integration layer.
Our preference: a modern LIMS that exposes good APIs + Slack/email/webhook integrations with whatever ELN you already use. Integration is a one-time cost; vendor lock-in is a forever cost.
How we approach this
Our pharma product suite (LIMS Pulse + Calibration + Stability + Inventory) shares one schema, one identity layer and one audit trail. ELN integration is via bi-directional webhooks; instrument ingestion via vendor APIs and file-watchers. One login, one audit trail, four products.
Takeaways
- Connected lab = one identity + one audit trail across all four systems.
- Instruments, LIMS, ELN, reports. Four roles; one data model.
- Pull from instruments; don’t ask them to push.
- Methods, sample IDs, and audit trails are immutable records, not editable fields.
- Vendor lock-in costs more than integration work over five years.
