The LIMS layer that connects the lab you already have.
Most labs do not need another system of record — they need the ones they have to talk to each other. CMS Life Sciences connects to your LIMS, ELN, and instruments through the same governed platform that runs your samples, extends them where they stop, and holds the record itself where nothing does.
Three ways in — and none of them is a rip-and-replace.
Where LIMS and sample management overlap is genuinely fuzzy, and every lab draws the line somewhere different. Rather than argue about the category, we support all three positions on it.
Connect to the LIMS you run
Attach your existing LIMS as a data connection, keep it as the system of record, and gain a governed layer across it and everything it does not reach.
Extend it where it stops
Your LIMS holds results but not chain-of-custody, or custody but not instrument telemetry. The gaps are where the spreadsheets live. Build the missing surface here instead, over the same governed data.
Be the record where there is none
Plenty of labs run parts of the operation with no LIMS at all. Study configuration, sample records, and an immutable audit trail are already here — start with the gap, not with a migration.
What the LIMS layer does — and how far it is built.
An honest read. Some of this is shipped and running in the application today; the analytical core is deliberately later, because connectivity and governance are what make it worth building on.
Vendor & LIMS field mapping
Map any vendor's or LIMS's export layout onto canonical fields as administrator configuration — adding a second LIMS is a config change, not a release. Non-canonical targets are refused at the write path, so a mapping that would silently do nothing cannot be saved.
Study & method configuration
Entry model, governance tier, retention policy, LIMS target, and role assignments are configured per study, so the same platform behaves differently for a clinical trial and a discovery programme without a fork.
Instrument & device data aggregation
Centrifuges, freezers, balances, readers, and mass spectrometers stream into one governed store instead of one export folder per instrument — the crossover between LIMS and sample management that nobody currently owns.
Connection & instrument health
A live view of which feeds are online, connecting, or silent, with queued-record counts. The dashboard surface is shipped; sourcing it from platform connection heartbeats rather than the domain store is in progress.
Assays, worklists & result entry
Test ordering, worklist assignment, result capture, and specification-limit checking against the sample records already in the platform. Roadmap — sequenced after connectivity, not before it.
Result review, release & reporting
Two-stage review, out-of-specification handling, electronic release, and certificate generation, on the same reason-for-change and audit machinery the sample lifecycle already uses. Roadmap.
Every instrument arrives one of two ways.
There is no third pattern to learn. An instrument or system either gets polled on a schedule, or it pushes to your workspace as things happen — and the table below is what is actually in production use, not a wish list.
| Instrument or system | Pattern | Status |
|---|---|---|
| LIMS / ELN REST endpoint | Pull — API node | Available |
| LIMS SQL view or export drop | Pull — API node | Available |
| HTTP instrument push | Push — Connection node | Available |
| MQTT — bench and benchtop devices | Push | Available |
| AMQP — brokered instrument fleets | Push | Available |
| WebSocket — live run streams | Push | Available |
| Azure IoT Hub — managed device fleets | Push | Available |
| OPC UA — lab automation & analysers | Push | Roadmap |
| SCADA — facility and utility systems | Push | Roadmap |
OPC UA and SCADA are the two protocols most lab automation speaks natively, and both are roadmap rather than shipped. Until they land, those systems connect through their REST, file, or broker interfaces — which is how most of them are integrated in practice anyway.
What every platform capability does for your LIMS.
CMS Life Sciences is built on Open Industrial. Rather than list the platform's capabilities and leave you to guess at the relevance, here is the entire published capability set with what each one is actually for in a LIMS context.
Workspaces & provisioning
AvailableA governed workspace provisioned on sign-up — no installation, no server build — with your team invited into it under their own roles.
Read the docsA LIMS workspace is provisioned at sign-up with no install and no server build, so the first instrument mapping can happen the same day the project starts — not after an infrastructure ticket.
Deployment options
AvailableEvaluation, Fully-Managed, or Bring-Your-Own-Cloud — three tiers with an identical compliance, audit, and access model.
Read the docsRun it as an evaluation sandbox against sample data, fully managed by us, or entirely inside your own cloud tenant when instrument output and result records cannot leave your infrastructure. The compliance model is identical in all three.
Granularity of control
AvailableDrafts, commits, undo/redo, proposals, and forks — configuration is versioned like a document, so nothing is permanent until someone says so.
Read the docsA re-mapped instrument channel, a changed specification limit, or a new study configuration is a draft until someone commits it — with undo, redo, and a readable change history. That is what a LIMS change control asks for, produced as a by-product of making the change.
API & connection nodes
AvailableTwo integration patterns: an API node that polls a system on a schedule, or a Connection node that receives events as they happen.
Read the docsEvery instrument and every incumbent system attaches as one of two node types: poll a LIMS SQL view or REST endpoint on a schedule, or receive balance, centrifuge, freezer, and reader output as it happens over MQTT, AMQP, WebSocket, HTTP, or IoT Hub.
Cold, warm & hot data
AvailableDownload the history, query what is flowing now, or subscribe to a live stream and a configuration change feed.
Read the docsCold pulls the run history a method validation needs. Warm queries results while they are still flowing — specification checks, out-of-trend detection, plate-level QC. Hot streams a run live to the bench screen while the instrument is still running it.
Custom nodes & extensibility
In progressA pluggable node model behind every connection, query, and dashboard. First-party node types today; customer self-service authoring is roadmap.
Read the docsAn analyser or an internal LIMS that fits no standard node gets a purpose-built one on the same pluggable model your other flows already run on, so it is a first-class citizen rather than a bolt-on. Our team builds those today; self-service node authoring is roadmap.
Azi, the AI operator
AvailableA workspace-aware assistant with context on your real connections and flows. It drafts proposals for review and never mutates anything directly.
Read the docsAsk which assays are trending out of specification, which instruments went quiet overnight, or how a vendor's new export maps onto your fields — in plain language. Azi drafts the query or the mapping change as a proposal for a person to approve.
MCP server
AvailableAny MCP-native model can read, query, and propose. There is no accept tool — proposals only ever land through a person in the workspace UI.
Read the docsClaude, GPT, Copilot, or your own models can list instrument connections, run result queries, pull cold exports, and draft configuration changes over MCP — and cannot accept one. No accept tool exists; a person lands every change in the workspace UI.
Roles & access administration
AvailableNamed access rights, bundled into custom configurations, assigned to people — with Viewer/Editor/Admin as the starting default, not the ceiling.
Read the docsAn analyst who enters results but cannot release them. A QA auditor who can export the audit trail and nothing else. An instrument feed that writes samples but has no right to read the evidence of its own writing. Built from named rights, not a fixed permission grid.
Audit trail & data integrity
AvailableEvery governed mutation produces its own compliance evidence structurally — attributable, timestamped, append-only, and mapped to an ALCOA+ principle.
Read the docsThe data-integrity spine a LIMS is inspected on, produced structurally rather than assembled afterwards: a governed change is an attributable, timestamped, append-only event carrying its reason for change and its ALCOA+ principle. That machinery covers mapping and configuration changes today, and is what result and QC data will land on when they are built.
System upgrades
RoadmapThe planned linked-environment model — promote a change from testing through staging into production on your own change-control steps.
Read the docsPlanned: promote a validated method, mapping, or study configuration from a testing environment through staging into production along your own change-control steps, rather than editing production and documenting it afterwards.
Validation data & custom reporting
RoadmapAudit-trail export today, with broader validation-data downloads and custom compliance reporting planned.
Read the docsAudit-trail export is live today and already covers instrument and mapping events. Broader validation-data downloads and custom compliance reports built on result and QC data are planned.
LIMS data with the integrity story already answered.
- Every result, correction, and mapping change attributable to a person and a timestamp
- Reason-for-change captured on the mutation, not reconstructed afterwards
- Append-only audit trail, each event tagged with the ALCOA+ principle it satisfies
- Instrument feeds hold a write role with no right to read the audit trail — the pairing an inspector questions
- Configuration changes reviewable as drafts and proposals before they are ever live
What is built, and what is not.
The same honest ledger published across the site, filtered to this area. The full matrix lives on the Sample Management page.
- Vendor / LIMS layout mapping as configurationAvailable
a new vendor or LIMS export layout is admin config, not a code change; non-canonical targets are refused at the write path
- Instrument & device data aggregationRoadmap
- Live connection & instrument healthIn progress
the dashboard surface is live; sourcing it from platform connection heartbeats rather than the domain store is still to do
- Assay / test ordering & worklistsRoadmap
- Result entry & specification-limit checkingRoadmap
- Result review, release & certificate reportingRoadmap
Connect your instruments to the record they belong to.
We will map your real LIMS, ELN, and instrument landscape and show you where the governed layer goes.