What is a Laboratory Information System?

The LIS owns the specimen's life, not just its record

It is tempting to describe an LIS as a database of tests and results. That description survives about ten minutes of contact with a working laboratory. A specimen does not simply exist and then have a result; it is ordered, documented, received, accessioned, labelled, routed, tested, resulted, verified, released, delivered and billed. Each of those is a state, each transition has rules, and each rule has exceptions that somebody currently handles by knowing about them.

A useful LIS models those states explicitly. It knows the difference between a specimen that has been ordered and one that has been received, between a result that exists and a result that has been verified, and between a result that has been released and one that has actually been delivered to the ordering provider. Systems that collapse these distinctions are the ones where staff end up keeping a parallel spreadsheet.

What a modern LIS is expected to cover

• Test catalog and configuration — specimen requirements, result structure, reference ranges, flags, reflex rules and billing codes
• Order and requisition management across every channel orders actually arrive on
• Accessioning, labelling and specimen tracking, including rejection and recollection
• Testing workflow, including routing between in-house testing and reference laboratories
• Result entry, import, verification, release and report generation
• Critical result and amended result workflows with documented handling
• Provider, facility, patient and user management with role-based permissions
• Audit trails at field level, not just at record level
• Interfaces — HL7, APIs and increasingly FHIR-shaped exchange

The test catalog is the spine

If you look at where LIS implementations succeed or fail, an unreasonable share of it traces back to the test catalog. The catalog defines specimen requirements, result structure, reference ranges, flags, reflex logic, routing rules and billing codes. Almost every downstream behaviour is an expression of a decision made in the catalog.

This is why catalog configuration deserves more time than it usually gets during implementation. A catalog that carries its billing codes at the level that actually bills means the claim can be assembled from the order. A catalog where routing between in-house and send-out testing is a rule on the test means nobody has to remember to make that decision specimen by specimen.

Where legacy systems tend to show their age

Older laboratory systems were often built when a laboratory was a mostly self-contained operation with a handful of interfaces. The assumptions embedded in that era show up in specific places: single-tenancy that makes multi-site operation awkward, result models that struggle with panels and interpretive reporting, integration surfaces that assume file drops, and reporting that has to be exported before it can be used.

The other common symptom is a system that does not distinguish between a result being ready and a result having been delivered. When delivery is not part of the record, 'did the provider get it?' becomes an unanswerable question, and client service absorbs the cost.

Questions worth asking of any LIS

• Can the system tell me, right now, where every specimen is and how long it has been there?
• Is release a controlled action with a record of who performed it?
• Is delivery recorded separately from release?
• Does the audit trail show the previous value of a changed field, not just that a change occurred?
• Can billing read the same order record the laboratory ran, or does the data have to be re-entered?
• When an interface message fails, does it queue visibly with a reason, or disappear?
• Can a laboratory group operate several laboratories with data isolation enforced by the platform?

The last question matters more than it appears to. Multi-tenancy retrofitted into a single-tenant system tends to leak, and the leak is other people's patient data.