One is organised around a patient and the other around a sample, and the two produce different tables, different permissions and different reports. Buying the wrong one is usually discovered at the first accreditation assessment.
Two acronyms, one letter apart, sold into overlapping markets by vendors who use them interchangeably in their own marketing. The distinction is real, it is not about features, and getting it wrong is usually discovered at an accreditation assessment rather than during a demonstration.
The short version: a LIS is organised around a patient, and a LIMS is organised around a sample. Everything else follows from that sentence, including which tables you build and which questions your system can answer cheaply.
The two nouns#
Ask either kind of system a question and notice what it needs to know first.
A laboratory information system asks who the patient is. Its central record is a person with a history: previous results, a reference interval that depends on their age and sex, a clinician who ordered the test and will act on the answer. A result means something in the context of that person, and a value with no patient attached is not a result at all — it is a measurement.
A laboratory information management system asks what the sample is. Its central record is a material with a provenance: where it came from, what was done to it, which batch it belongs to, which specification it is being tested against. A person may not be involved anywhere. Water, soil, a drug substance, a food product and a manufacturing intermediate are all samples with no patient.
This is not a difference in emphasis. It is a difference in which table everything else has a foreign key to. Once you have chosen, the choice is expensive to reverse, because it is the shape of every query you will ever write.
What the data model actually looks like#
In a clinical LIS the spine is patient → order → specimen → test → result → report. A patient is one record for a person, not one per visit, and that is the point: their haemoglobin from eighteen months ago sits on the same spine as today’s. An order can require three tubes; one tube can serve four tests. A result is versioned rather than overwritten, because somebody may already have acted on the previous value.
In a LIMS the spine is sample → aliquot → test → specification → batch → certificate. Aliquoting is first-class in a way it rarely is in a LIS, because a single sample is routinely split across tests, laboratories and storage conditions. The comparison a result is judged against is a specification with limits, not a reference interval that resolves per person.
- A LIS needs demographics, consent, and a clinician relationship. A LIMS usually needs none of the three.
- A LIMS needs stability studies, batch genealogy and specification versioning. A LIS usually needs none of those.
- Both need custody, both need audit, and both need a result to be versioned rather than edited.
Reference intervals against specifications#
This is the clearest place the two diverge, and it is worth being concrete.
A clinical reference interval is a lookup with predicates. Haemoglobin for an adult female who is not pregnant is a different band from the same analyte in a six-year-old, and both differ again in pregnancy. The interval is resolved at result time from the patient’s own attributes, and the resolved numbers are stored on the result, so that the value still reads correctly years later when the laboratory’s own limits have moved.
A LIMS specification is a versioned document. A batch is tested against the specification in force when it was released, and that specification has an identity, an approver and an effective date. The question "which limits applied" has a documentary answer rather than a computed one.
Building the first on top of the second gives you a system that cannot express "female, 12 to 17 years". Building the second on top of the first gives you a system that cannot tell an auditor which revision of the specification was in force. Neither is a small gap.
Permissions follow the noun#
Because a LIS is organised around a person, its access control is organised around that person too. A patient can see their own results. A clinician sees a patient’s results because a relationship exists — an order they placed, an episode of care, or a grant the patient gave. The interesting permission questions are all of the form "who may see whose".
A LIMS has no patient, so its access control is organised around the work: a department, a project, a client, a study. The interesting questions are of the form "who may release a batch", and the sensitive material is commercial rather than personal.
That difference is why a LIMS retrofitted into clinical use tends to fail its first privacy review. Not because it is careless, but because it was never asked the question its access model has no place to record.
The regulatory surfaces are different too#
Clinical laboratories answer to accreditation bodies and health-privacy law: the traceability of a result to a person, who touched it, whether it was released by somebody competent to release it, and whether the patient’s data was handled lawfully.
Non-clinical laboratories answer to a different set, frequently including good manufacturing practice and electronic-records rules that focus on the integrity of the record itself: that it was created contemporaneously, attributed, legible, original and accurate, and that any change to it is signed and reasoned.
These overlap substantially in what they ask software to do — audit everything, version rather than overwrite, prove who did what — and differ substantially in what they ask you to document. A system built for one can usually be made to satisfy the other technically, and rarely has the paperwork.
The workflows diverge before the first result#
Long before anything is measured, the two systems are already doing different work.
A clinical laboratory’s day starts with reception and phlebotomy: a person arrives or is visited, is identified, is bled, and their tubes are labelled at the point of collection because a tube labelled later is a tube that might be labelled wrong. The chain of custody starts with a human interaction and every link after it is an event with an actor and a time. Rejection is part of the workflow, not an exception to it — haemolysed, insufficient, wrong tube, clotted, and each rejection has a reason code the ordering clinician will see.
A management laboratory’s day starts with receipt of material against a request: a container arrives from a client or a production line, is logged, and is split into aliquots destined for different tests, storage conditions and sometimes different sites. Custody matters just as much, but nobody was bled, nothing needs a wristband checked, and there is no clinician waiting to be told that the sample must be recollected from a person who has gone home.
Recollection is the tell. A system that cannot express "this specimen is unusable and the patient must come back" was not built for a clinical laboratory, however good its sample tracking is.
What comes out at the end#
The output of a clinical laboratory is a report about a person, addressed to a clinician, and it is a clinical document. It carries the patient’s identity, the resolved intervals, the abnormal flags, an interpretive comment where one applies, and the name of whoever released it. It is delivered to an electronic health record, a portal, or occasionally a fax machine, and once delivered it cannot be withdrawn — a correction is a new version that supersedes it and says so.
The output of a management laboratory is a certificate of analysis about a batch, addressed to a client or a quality function. It carries the specification it was judged against, the methods used, the results with their uncertainties, and a conformance statement. It is a commercial and regulatory document, and its audience is an organisation rather than a person.
Both are signed. Both are versioned. But one of them can harm somebody if it is wrong and late, and that asymmetry shows up everywhere in a clinical system — in the critical-value escalation path, in the refusal to let a result skip validation, and in the rule that release is the line after which everything is a new version rather than an edit.
Where the line genuinely blurs#
It would be tidier if the distinction were clean. It is not, and pretending otherwise is how people end up buying the wrong thing on good advice.
- Anatomical pathology and molecular laboratories are clinical, patient-centred, and run workflows that look exactly like a LIMS: blocks, slides, plates, runs and batches, with aliquoting and provenance everywhere.
- Public-health and screening laboratories process enormous numbers of samples where the patient is a record in a registry rather than a person in front of a clinician, and the work is batch-shaped.
- Veterinary laboratories have a patient who is not a person, an owner who is, and a data-protection story belonging to neither.
- Research laboratories inside hospitals hold human material with consent constraints and no clinical result at all.
In each of these the honest answer is that you need the clinical spine and the sample spine at once, and that the difference between the two products is which one you got for free.
How to decide, in one question#
Ask what a result means when you remove the patient from it.
If the answer is "nothing — it is a measurement of a person and it is interpreted against their own history and their own reference interval", you need a LIS, and a LIMS will make you build the patient spine yourself, badly, in the second year.
If the answer is "it still means something — it is a property of a material judged against a specification", you need a LIMS, and a LIS will make you fake a patient for every sample, which is exactly as bad as it sounds.
LabFlow is a LIS. It is organised around a patient, its reference intervals resolve per person, and its access model is built for "who may see whose". It is not a configurable platform for regulated non-clinical work, and the comparison with sample-centric platforms says so directly rather than claiming the middle ground.