Over decades, many different types of software have been developed to facilitate the scientific research and testing processes that occur in all different types of laboratory settings. The resulting technology landscape is a cluster of acronyms and abbreviations that causes a lot of confusion amongst those trying to determine what will best support their specific needs.
In this article we hope to provide some helpful guidance by explaining what each of an ELN, a LIMS, and a LIS do, the environments they’re best suited for, and shed light on the current state of laboratory informatics technology.
Understanding The Historical Context
Let’s start by outlining what each system does with some historical context into the laboratory environments they were originally designed for.
What Is An ELN?
Spelled out, ELN stands for Electronic Lab Notebook and was literally derived from the idea of scientists documenting their experiments by hand in notebooks. They serve the earliest stages of research and development where scientists need to organize and document their experiments in an unstructured way that facilitates free flowing thinking and ongoing discovery. Information can be entered in a variety of ways, such as free text, diagrams, attached files, manual data entry.
What Is A LIMS?
When sample volumes increase and tests become not only more structured, but also more complex, laboratories begin to outgrow ELNs, paper forms, and spreadsheets and require a LIMS, or a Laboratory Information Management System. They are designed to manage the testing portion of a laboratory at scale, not only tracking everything that happens, but expediting throughput with automation while guarding against errors with built-in logic and alert mechanisms.
What Is A LIS?
LISs, or Laboratory Information Systems, have the most structure of the three categories we’re discussing today.
This isn’t surprising as these systems were developed for a clinical healthcare laboratory setting to handle the intake of samples from patients for straightforward tests with strict SOPs. They must be able to handle, and protect, personal information and enforce processes in compliance with regulations. They are patient-centric and their primary functions are to interface with the EHR (Electronic Health Record system), receive orders, create patient records, request the test run, and return the diagnostic report to whomever ordered it. They sometimes interface with the LIMS that manages the actual testing.
So, as you can see, each of these systems were originally developed with a specific purpose in mind and serve it very well.
Navigating The Complexities Ahead
Consider that a laboratory can evolve from its original experimental research and development phase all the way through to a clinical setting. They’ll need some iteration of each of these systems at different stages. So after happily moving along using discrete solutions for different laboratory functions for decades, in or around 2017 the industry came to the sudden realization that labs would be better served by vendors that could cover these different use cases with a single system.
Three things started happening:
- Mergers and acquisitions between different laboratory informatics vendors
- Point solutions developing functionality for adjacent use cases
- A reimagining of the way laboratory informatics systems are designed so they serve current AND future needs
Many have and will continue to go M&As route as it is a quick way to add rich functionality to a product offering. Customers will indeed benefit from more comprehensive capabilities from a single vendor but may have to deal with separate products that aren’t yet completely integrated.
In cases where a company decides to build functionality into its point solution for adjacent use cases, they’re often years, even decades behind leaders in the space and functionality is limited by software architectural choices made over their history.
And in both of these situations, the systems in question were built on rigid data models that require heavy development work to customize if and when the lab and/or its assays require changes to its processes or workflows as it evolves.
Some, like Semaphore, creators of Labbit, took a different approach. After over a decade implementing and maintaining LIMS for complex, high-throughput laboratories, Semaphore understood that one of the main reasons existing systems struggled to adapt and grow with a lab was the underlying infrastructure they employed. For example, most systems require that labs understand upfront what data must be captured – an impossibility for early research, and a hindrance for any lab that expects to iterate and deploy new versions of their tests down the road.
Instead of being built on top of rigid legacy systems, Labbit reimagined the entire infrastructure and applied knowledge graph database technology that allows for more flexible configuration and ongoing adaptation. Because objects and their relationships can be continuously added and changed in graph databases, it’s a much simpler, faster process adapting these systems as the laboratory evolves, including adding and removing structure as needed.
Whatever type of lab you’re running, if you’re trying to decide what informatics system you need, think not only about what you need now, but how those needs might change in the future, and invest in a system that can easily evolve with your science.
