Raindrops With LIMS, ELN and Other Acronyms Within the Raindrops

Do you sometimes feel as if it’s raining acronyms? You see LIMS, LIS, ELN, LES, SDMS, MES and such and you start to think it’s never-ending? Well, you’re not alone.

When It’s Raining Acronyms, Make GeoMetrick Enterprises Your Umbrella

Not only can we help you but we’ll give you the first important tip, right now:

A man sitting with a blue background behind him; he looks overwhelmed or frustrated.

Stop Reading the Acronyms!

Don’t let the multitude of acronyms get to you. Even for the experts, they’re not as meaningful as you would think. Instead, look at your requirements and start by understanding what you need.

Click Here to Contact Us For More Help

LIMS ELN LES LIS: Theoretical Definitions

This is a brief guide of what the main acronyms (LIMS, ELN, LES, LIS) are “supposed” to mean:

LIMS

LIMS stands for Laboratory Information Management System. A LIMS traditionally manages samples in the laboratory. It usually interfaces with instrumentation and instrument software, handles calculations, and provides at least basic workflow management of the samples, tests and results that the laboratory is working with.

ELN

ELN stands for Electronic Laboratory Notebook. Where a LIMS is sample-based, an ELN is experiment-based. An ELN is not supposed to merely be a replacement of a paper notebook but is supposed to provide more features and better processes. It is supposed to make it easier to store and search information. It is supposed to make it easier to manage the process of making sure all steps are included. For example, if tests are supposed to be peer-reviewed, the ELN is supposed to verify that this step isn’t missed.

LES

LES stands for Laboratory Execution System. It is a system meant to enforce strict rules. For example, when a lab is doing quality control testing and has strict procedures, this type of system is supposed to extremely minimize mistakes in the process.

LIS

LIS stands for Laboratory Information System. Now, if you’re new to this, you wonder what the difference between a LIMS and a LIS is, aren’t you? Well, it’s more than the fact that the latter is missing the “M.” A LIS is supposed to be a patient-based system. It’s supposed to support the clinical lab. Now, this is where it gets tricky – you will often see LIMS systems being used to support clinical labs. In addition, the term “clinical” can be tricky because it sometimes means “clinical study” and other times “the clinic” as in “the medical clinic where the patient has their testing performed.”

Did You Understand All That? Meanwhile, Let’s Continue

Those are the theoretical definitions of LIMS, ELN, LES and LIS. These are not always the definitions you find in the marketplace. As such, if you’re hearing from a vendor about a LIMS, for example, and think the LIMS they’re describing doesn’t sound as if it match this description, you’re not misunderstanding the situation.

First of all, if you go to a software vendor and tell them, “I want to buy a LIMS,” then some will call what they have a LIMS and try to sell it to you. Others will relabel their software based on the market they want to sell it to. If they’re selling to the clinical market, they might call their system a “clinical system” or a “LIS” but when selling to another market, might call their product a “LIMS.”

The other issue is that we don’t happen to agree on the terms. Some people claim that an ELN refers only to systems that would be used as a laboratory notebook for research purposes. Another example is that there appears to be some people who randomly use the terms LIMS and LIS, interchangeably.

Even where the labels seem to match, various systems are oriented toward different markets. An ELN meant for biology isn’t the same as one meant for chemistry. A LIMS sold for pharmaceutical use might have different features (and cost model) than a LIMS sold to the consumer products industries.

What Do You Do, Now?

If you now wonder what you do if this is so confusing, just remember what we first told you, which is to stop reading the acronyms. But past that, here is what you need to do:

  • Gather your Requirements.
  • Prioritize your Requirements.
  • Determine which requirements are actually going to be given to the software vendors. There might be some that, in the end, don’t quite seem appropriate to include.

That list looks short but you must have already figured out that it’s a lot of work. However, making at least one good pass at this usually gets you to the point where you have a better idea what you need. When you know what you need, you can then discuss your needs with the software vendors.

Overwhelmed?

Right about now, some of you reading this are feeling overwhelmed. LIMS, ELN, LES – they seem to blend together. This is a lot of work to undertake. At this point, you wonder how to get started. There are three basic choices:

You Start the Process

Get all the right people together, start setting up meetings, and move forward on this task. Involve all stakeholders. Work in a manner where you maximize buy-in.

Have Someone Else Do the Process

Gather the list of people to include in the process and what their role is. Get together basic information, such as the number of labs to include and which ones they are. Give this to someone else and have them do the process.

Click Here to Contact Us For More Help

Get Help With the Process

Regardless what you do, you always have to get the list of people together to give to an outside person and do that part of the work. However, you can talk to the outside person about how you can split the rest of the work.

Click Here to Contact Us For More Help

Requirements Tip

When you write your requirements, remember this – they’re not just about process features. Don’t forget to include other requirements, such as regulatory, operating system, database brand, or other non-functional requirements, as well.

LIMS ELN LES : Next Steps

Once you’ve gathered your requirements and start talking to the software vendors, you’ll begin to have a better idea what you need and what’s available.

Here’s what you need to do:

  • Make a list of software vendors you think might be potential providers.
  • Start contacting these vendors asking some basic and high-level questions.
  • Keep track of which ones aren’t suitable and which ones are worth pursuing.
  • While you’re doing this, turn your requirements into an RFP/RFQ (Request for Proposal/Request for Quote).
  • Send this RFP/RFQ to whomever is left. Only send it to those you’re serious about. This is because you neither want to waste the software vendor’s time on this to create it nor yours and your team’s to read it.
  • You will want to read each of these and respond back. You might have more questions about the responses you get. In addition, some vendors will respond in a manner that indicates that they didn’t understand your question. Some will actually have more questions about your intent.
Creating an RFP/RFQ

How It Differs From Requirements

Your RFP/RFQ isn’t just a copy of your requirements. You will take the requirements and possibly reorganize them. In addition, the statements will be turned into quesitons. Some of those questions need to be open-ended (e.g., what version of Oracle does your system run on; give an example of how a sample would be logged, using your system); others, a simple “yes or no” (e.g., can your system run on Oracle 12.0?).

Creating an RFP/RFQ

More Tips

It’s common to put the RFP/RFQ questions into a spreadsheet. It’s common to also include a cover letter. Include some information about your company and the labs to be included. Give a deadline and, depending on the size of your document, make it generous. Think about the holidays and other events that could interfere, such as industry conferences (which the software vendors will probably attend). We usually give software vendors a month. If a vendor can’t respond in that timeframe and they have a good reason, they will usually contact you to explain.

LIMS ELN LES : Demos

Finally, the exciting part – the demos. Now, everyone on your team has an idea what to look for. You will only ask two or three vendors to give a demo. Ideally, you should be able to narrow this to two vendors but, if it seems really close, try to keep it at three.

Otherwise, they all start to blend together. Plus, it’s a lot of work. There are many reasons why you want to keep the number low. At this point, you’ve seen screenshots of the products and know quite a lot about them. Now, it’s time to be able to see it all in action.

A demo doesn’t always have to require the software vendor be on-site, by the way. So, keep that in-mind. If you have a strong internet service, your software vendor could potentially give your demo via some tool such as WebEx. If your service isn’t strong, though, you won’t want to do it that. Another option is to ask ahead of attending a conference you and the vendor will attend about setting up a time to get a demo, there.

Iteration

If you get to the end of the process and haven’t selected anything, don’t get too frustrated. You’re not alone.

When you get stuck in the process, repeat some of the steps. If you find there are requirements that are confusing to all software vendors, you can rewrite them. If you find you don’t have enough vendors on your list, go out and find more. As with most processes, iteration is the alternative to a dead process.