Blogs, News & Events

What is the Ideal LIMS for Your Lab?

By Joe Liscouski | May 21, 2022

When it comes down to picking the products you’re going to use to help organize and streamline your lab’s operation, you can be faced with a bewildering array of options that range from well-known to little-known vendors, with investments that can be significant or “free”.  Is one of those the ideal choice for your lab?  This article will help you move to the best decision for both your immediate and future needs.

This is the fourth entry in this series, the previous articles have looked at:

  • what Laboratory Information Management Systems (LIMS), Scientific Data Management Systems (SDMS), Laboratory Execution Systems/Functions (LES), and Electronic Lab Notebooks (ELN) are[1],
  • compared two different methods of implementing a LIMS (on-premise vs the cloud)[2], and
  • reviewed how a LIMS works and can improve your lab’s operations[3].

That background should give you a good understanding of what the laboratory informatics landscape looks like.  What we want to look at now is how to apply the earlier material to your lab, and what you need to think about to make the right choice in product selection.  This is important because the LIMS is going to become the operational hub of your lab’s work.

The fact that you are considering a LIMS tells us something important about your lab: it has a heavy emphasis on testing to support research, manufacturing/production, or it’s a contract lab because at its core test management and sample tracking are the central topics a LIMS addresses.  Your lab informatics needs may not end there, and that brings us to the first step in looking for that ideal solution Note: the ideal solution for your lab might not be the same as the ideal solution for other labs, it all depends on your needs.

Needs Analysis

 There are several major categories of laboratory informatics systems, let’s briefly review them and how they might complement a LIMS:

The last line in the table – instrumental data collection – is one element that separates a LIMS from similar database solutions that might be implemented in an Enterprise Resource Planning system.  It is a key factor in realizing the productivity gains that LIMS promises because support for those facilities is designed into the product.  Among the items you should be concerned about are:

  • The support the LIMS vendor and the instrument vendor provide in the data/information transfer process. Instruments with full computers and data processing are likely to have interfaces to connect to LIMS.
  • Instruments that have rudimentary data processing may use command/response protocols over USB, serial ASCII (older equipment), WiFi, or ethernet as a means of communications connections. The actual programming of the data collection and transfer is up to the user.  The instrument manufacturer provides general capabilities, it’s up to you to decide how you’re going to use it.

Those two bullets have to become part of the user requirements for both instruments and informatics systems.  Ideally, you want both the instrument vendor and the LIMS vendor to say “yes, we’ve worked with that device before”, or “we know how to connect it”.

If any of those informatics systems in the table above look like they might be appropriate for your lab’s work, then part of your needs analysis has to include an evaluation of their capabilities and requirements plus the ability to interconnect those components into a working, functional, integrated whole – the informatics architecture.  You may not acquire all of the components at one time, but planning for their eventual integration should be done early in the process to avoid the “we should have thought of that” frustration.  Phased implementations can work well if all of the phases are planned for at the beginning of the project.

The needs analysis portion of the planning process is the foundation of a successful product selection and implementation.  It is also much more detailed than can be covered in a short article.  For a more thorough description please consult the ASTM E1578-18 “Standard Guide for Laboratory Informatics[4]” and ASTM E1578-06 “Standard Guide for Laboratory Information Management Systems (LIMS)[5]”.  ASTM E1578-18 largely supersedes E1578-06, but the latter has some useful information that is specific to LIMS.  Both contain checklists of features and functions found in informatics products that are useful in deciding what you need for your lab.

Unless your lab is a duplication – point-for-point, device-for-device – of another it is unlikely that two labs will have the same user requirements; they may be very similar but the differences can be significant.  User requirements should include an:

  • Overall architecture description,
  • Where instruments are and how they will be connected to the LIMS,
  • The choice between on-premise and cloud implementations,
  • Is the LIMS scalable and flexible; will it grow and adapt to your needs as they evolve?
  • Whether the base product will be supporting one or more labs. This may be a consideration if you are looking to reduce overall costs.  Does the product allow the base system to be shared between different instances of lab work? If not how will you keep the workflows separated and protect privacy?
  • Security – does the system provide sufficient security to prevent unwarranted intrusion? Can third parties be given limited access to the system for billing (accounting departments), providing test results (outside testing labs), or viewing results pertinent to their projects (researchers)?
  • Who is going to be responsible for the system and its administration?
  • What training will the administrator and users need?
  • How will the operational features and privileges of the LIMS be assigned to different users? Can the first screen the user sees be customized to reflect their role in the lab?

The user requirements also serve another function: they provide the basis for developing a validation plan for the system.  Every system requires validation – documented proof that the systems work and does what it is supposed to do.  The user requirements are the definition of “what it is supposed to do”.

The Role of the Vendor

Our encounters with vendors in our daily lives can range from no contact when we buy products off the shelf, to interesting when we purchase/lease a car or truck.  In most cases the products we buy are fixed functions: they are designed to do certain things and those capabilities don’t change.  That’s not the case with software in the category of laboratory informatics – and why we need a good working relationship with software/hardware vendors.  The primary reason is that software systems are not fixed-function products, but rather a collection of products working together any of which can change.  The basic stack of products consists of:

  • The underlying hardware (processor(s), storage, communications, etc.) plus backup systems including power,
  • The operating system,
  • Database software, and,
  • Informatics application software – LIMS in this discussion.

That doesn’t include the connections to instruments and other applications.

One role the vendor should provide is maintenance support; “should” because not all vendors do.  To support their product, a vendor will have to determine the impact of any change on the last three bullets immediately above.  They usually don’t become concerned with hardware unless the operating system or database software requires hardware upgrades to keep running.

Once the impact of the software changes has been evaluated, the vendor will determine what corrective action has to be taken and advise you on what to do.  This is where close cooperation between the vendor and the IT group becomes important.  IT groups may have a policy of automatically upgrading operating systems.  In some cases, the update to the OS may have no impact, and that works, in another case, it can cause the system to shut down because of a conflict between the OS changes and the software layers above it, including instrument system’s connections.  The vendor’s advisories will let you know what steps to take and will provide software updates as needed.

Unlike fixed-function products, LIMS are dynamic systems.  Functionality can change by adding features, correcting flaws, and responding to user requests for new/updated features.  All of this requires a vendor who understands how your lab works and is responsive to changes, either user requests or system upgrades.

Another facet of vendor support is the availability of consulting support.  There may be something you want to add to the LIMS and aren’t sure of the best way to implement it.  That is something the vendor can assist you with.  They have contact with many labs and could have seen the same issue elsewhere; that experience can save you time, and money, and may prevent you from going in a problematic direction.  If you don’t have people to carry out the work, they may have people available to support you or references that they have experience with, that know their system.

The vendor should also be able to provide you with training, from the user & administrative levels, to support and how and where to make modifications.

Can the vendor assist you with meeting regulatory compliance requirements?  The vendor cannot offer you a regulatory compliant system, that is a combination of user requirements, documentation, and validation; a combination that makes your system unique.   Regulatory compliance is something the implementation team has to accomplish.  However, the vendor’s experience can provide you with guidance on how to conduct a compliance program with their systems.

The relationship between you and the LIMS vendor is not the typical buyer/seller arrangement.  It is a partnership.  The LIMS is going to be the central focus of your testing lab and its operations for years to come; that includes expansion of your lab, a wider range of testing, new equipment to connect, and the need to access other databases not supplied by the LIMS vendor as well as other factors.  Here are some points to consider when evaluating a vendor:

  • Is the LIMS vendor you’re considering able to meet those requirements in addition to supporting and maintenance /upgrade / consulting services?
  • Do they have a team that understands lab operations or are they narrowly focused on one product leaving the rest of the support needs to you?
  • Do they have the staff to accommodate your needs as their organization grows?
  • Will you be working with the same set of people over time, those who have built a history of experience with you, or is every encounter a new one?
  • Do they understand the requirements of your industry and any specific guidelines/regulations that apply?
  • Do you feel that the vendor is willing to work with you to make your efforts successful? There are limits to what they can do since “success” depends upon an honest appraisal of your requirements and providing internal resources to meet the demands of the project.  The vendor has to function within the bounds of their product and service offerings, however, they can draw on their experience to guide you in making good decisions and point to resources that can help you become successful.

Other Considerations

There is growing interest and emphasis on Data Integrity across industries.  While those under the FDA’s purview get the most press, that issue cuts across all lab environments.  The reason is simple: people are making decisions based on lab data/information which should be beyond reproach.  How does the LIMS support your lab’s/company’s efforts in this regard?

Laboratory databases aren’t immune to problems.  The database grows in size and complexity as material accumulates year after year, and sometimes people can forget that they are subject to flaws and breakdowns (errors within the system or underlying components).  Not the least of which is hardware failures.  What provision does the vendor provide to protect against data loss?  The most common is a backup facility.  How does it work? How can you demonstrate data recovery? Note: making backups is one step, but the process isn’t complete until you can demonstrate that the informatics database can be rebuilt successfully from that backup.

The factors mentioned in this note are points that need to be addressed with each product you’re considering.  You are paying for a product and related services, do they hold up to your requirements?  You may be considering a “free” software package, look again at the points above, will you be committing your lab’s most valuable products to a package that meets your needs realistically or just getting by with an initially low-cost option that can become expensive when support is needed?  Often management will look at outside expenditures as an important factor in making a buying decision, trying to keep the initial investment as low as possible.  The real concern should be the total cost of ownership: the initial purchase price, personnel investment, training (vendor-supplied or learn on your own), and support.

For example, what is the cost of downtime and reduced productivity if a problem develops or the implementation is delayed because of a lack of support?   Our earlier example of an operating system is a good illustration: if the OS upgrade prevents the system from operating properly who is responsible for fixing it? If the vendor doesn’t provide support, it’s you or your IT team.  It may involve outside consultants assisting you and you will bear the cost.  The most cost-effective solution usually isn’t the lowest initial price, but the one with the overall lower cost of ownership and high level of availability.

The ideal LIMS for your laboratory meets your current needs and has room to expand as your lab does.  That is done not just through your resources but through a partnership with a vendor that can work with you today and in the future.

—————————————————————————————————————————————————

[1] https://www.lablynx.com/news-events/what-is-a-lims-eln/

[2] https://lnkd.in/da5-4xrt

[3] https://lnkd.in/d8zGVQZa

[4] https://www.astm.org/e1578-18.html

[5] https://www.astm.org/e1578-06.html