Portfolio:Laboratory, Scientific, and Health Informatics Buyer's Guide

Title: Laboratory, Scientific, and Health Informatics Buyer's Guide

Edition: R1 2023 Edition

Author for citation: Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: February 2023

NOTE: This was originally published on LIMSwiki.org and is reproduced here using the same license. This guide has a section with many links to vendor pages, which have not been imported to this wiki.

This buyer's guide is based off the LIMS Buyer's Guide, a former publication of the Laboratory Informatics Institute (LII), the open trade association that was associated with LabLynx, Inc. In late 2013, the LII and LabLynx discontinued publishing a copyrighted version and chose to release future guides to the public domain via this wiki. Per the Creative Commons license and the copyright terms of this site, you are free to copy, adapt, distribute, and transmit this guide as long as you 1. give proper attribution and 2. distribute the work only under the same or a similar license.

1. Introduction

What exactly is a laboratory information management system (LIMS) or laboratory information system (LIS) anyway? Do I need one? What options are available and how do I compare them? Where does a user requirements specification (USR), request for information (RFI), request for proposal (RFP), or request for quotation (RFQ) come into play, and how does it fit into acquiring a laboratory informatics solution? These are questions laboratory professionals typically ponder upon finding themselves charged with the mission of finding software for their lab. It can be a daunting proposition, and there are few at least partially objective references to help with it all. This brief guide exists to, in part, meet that need.

At the core of this buyer's guide are several elements, including valuable information about evaluating, acquiring, and implementing laboratory software that fits your lab's needs. Also included here are laboratory informatics vendors who actually make their pricing partially or fully public, through one means or another. That pricing may be fully transparent and posted on the company website, or it may be a partial representation of the lowest possible price offered, as with those vendors who have a publicly viewable contract with the U.S. General Services Administration (GSA). While in the past vendors have refrained from providing public pricing, a more open information process may have its merits (particularly for potential buyers), though also not without its own set of caveats. The theory—at least on paper—has been that prices should decrease as LIMS become commodities that labs can compare and contrast in a more competitive fashion. However, it remains to be seen if that will ever be the case.

Laboratories are, by their very nature, in the business of producing analytical data and reports, essentially information. Everything else that occurs in the laboratory is largely just a means towards that central goal of producing timely, accurate, and unbiased information. As such, in a very real sense, information management is, by extension, also at the core of any lab. In a world where we use the latest technology for most of our daily tasks and pleasures, why do so many labs still rely on hand-written notes and spreadsheets? Why do labs still spend thousands of dollars on a sophisticated analytical instrument, yet they hesitate when faced with purchasing an information management system? The primary reason has traditionally been the cost associated with acquiring an informatics solution, as well as not having the information technology resources to properly implement it.

Software solutions like LIMS are increasingly becoming commodities, and potential buyers don't need to find the acquisition process as daunting as it used to be. As technology has improved, smaller LIMS companies have emerged, along with affordable cloud-based SaaS options that are flexible and reliable. This means any lab can put their resources where they belong: into its analytical information and its management.

This brief buyer's guide is here to help you take the first steps towards acquiring a laboratory informatics solution. Use these recommendations and vendor profiles to get a feel for what's out there and what makes the most sense. This guide contains information on a little bit of everything, from discovering what a LIMS is to maintaining and supporting that system. Also not that while the LIMS is the stand-out solution among the crowd for laboratories, this guide will also reference other systems like a LIS or electronic laboratory notebook (ELN).

2. How does laboratory software benefit the lab?

Laboratory, scientific, and healthcare informatics solutions can improve laboratory workflows while enhancing safety, quality, and compliance in a number of ways. A LIMS, for example, is often adopted to eliminate manual processes, improve sample management, increase productivity, and improve regulatory conformance. The adoption of LIMS and other such systems to eliminate deficiencies and improve operations is often based in the disadvantages of paper-based processes—particularly in regulatory environments—and their inability at making their contents rapidly findable, searchable, modifiable, and secure.

Even a fragmented mix of paper-based and electronic information sources can be a detriment to the traceability of or rapid accessibility to quality control samples, standard operating procedures (SOPs), calibration data, chain of custody data, and other vital aspects of analytical, sampling, and calibration testing in the lab. A well-implemented LIMS can reduce the silos of data and information, while at the same time make that information and data more secure and readily accessible. Given the demands placed on laboratories—by ISO/IEC 17025 and clients seeking labs certified to that standard, for example—to provide rapid proof of traceable sample movement and relevant quality control data, integrating a LIMS into the laboratory makes sense. The LIMS can act as the central integrator and audit trail for all that laboratory data and information. Because the LIMS improves traceability—including through its automated interfaces with instruments and other data systems—real-time monitoring of supply chain issues, quality control data, instrument use, and more is further enabled, particularly when paired with configurable dashboards and alert mechanisms. By extension, labs can more rapidly act on insights gained from those real-time dashboards.

There is a growing variety of laboratory informatics software providing these and other benefits to labs, allowing them to more rapidly adapt and remain competitive. Arguably, the most common solutions are the LIMS and LIS. The LIMS and LIS are similar, in that they focus on the entire laboratory process and improving the various aspects of it. Traditionally, the LIMS has been used in more non-clinical environments and the LIS in more clinical environments, but that distinction has been fading for well over a decade. These distinctions have blurred even more with the age of modular and platformed software solutions that are able to adapt to most any industry. For now, just know that these systems are a bit more holistic, placing the focus on improving your lab's workflows, which in turn strengthens traceability, analytical outcomes, and—in the case of clinical settings—patient outcomes. Outside of that, there are other more specialized solutions, including:

• the ELN, which is used in many research and development environments (among others) as a means to securely and collaboratively document experiments and their results;
• the laboratory execution system (LES), which is used in production-based environments to ensure the rigidity of a method and the process' end result;
• the chromatography data system (CDS), which is used to accurately collect, process, and visualize chromatography data; and
• the scientific data management system (SDMS), which is used to collect disparate silos of data and information across the laboratory enterprise and make it more actionable.

While these systems can be found in many types of labs, some tendencies appear. LIMS, LIS, and ELN are top-level solutions that help the lab manage workflows, as well as aggregate and organize data and information, including analytical- and experiment-based results. In service labs, the ELN is less likely to appear. However, in the case of research labs, the ELN may function more top-level, with the LIMS acting as a supplementary system for managing test workflows before associated test results are loaded into the ELN. Support systems like the LES, CDS, and SDMS may also appear, filling specialized roles. The LES will appear in more regulated environments where laboratory procedures must be executed precisely, before then feeding results to a LIMS or ELN. The CDS will appear in labs doing heavy chromatography work, and it too may feed data into a LIMS or ELN. The SDMS appears in contexts where data and information produced by the lab don't fit in the structure of what a LIMS or ELN handles.

3. How do I find the right solution for my needs?

As indicated above, the type of solution you choose is based on your lab type (e.g., service, research, production), the tests predominately run (e.g., chromatography work, requiring a CDS), and the type of data and information generated and stored (e.g., non-standard files, requiring an SDMS). However, finding the right system to fit your labs needs isn't a straightforward process. While your lab may know its regulatory-, workflow-, and standard-driven requirements, perhaps critical personnel don't know much about data management solutions like LIMS, leaving a lab's key stakeholders intimidated by all the options. You'll first need to gauge your lab's informatics needs in order to determine which products are worth investigating further. Of course your lab's analysis requirements, reporting and data sharing constraints, instrument interfacing needs, barcoding and tracking requirements, quality assurance processes, etc. are certainly important factors. But vendors' systems vary in numerous ways, and other important factors exist. Of course, price is one consideration, although value is ultimately more important than a low price. Other important questions that get asked include:

• Should we purchase software licenses or "rent" the software via a subscription-based model?
• Does the software need to be on-site, or is a SaaS hosted option more practical?
• Is a modular or complete system better for us?
• What is the best licensing/rental scheme for us? Should we consider site, named user, concurrent user, or workstation licenses?
• Is the company qualified and trustworthy?
• What functionality is available to help our lab remain compliant with the variety of standards and regulations affecting it?

3.1 Technology considerations

Your laboratory's workflow, instruments, data management requirements, budget, technological expertise, business goals, and risk tolerances will all play a role in deciding what technology to invest in. Your lab will also be interested in how that technology not only helps with workflow requirements but also better assists the lab with meeting the requirements placed upon them by various standards and regulations, as well as management.

As part of this discovery process, many questions may arise. Chief among them may be how to best match the laboratory's goals with one or more informatics solutions. Does the laboratory envision a small investment and modest goals, taking in a slow but steady flow of analytical requests, or does the lab envision expansive growth, expanding into multiple testing domains? If the lab is starting small but is confidently expecting to grow, technological investments early on may want to take into account future technologies that may shape data management and security processes. The lab will also want to account for how potential changes in standards and regulations may affect future expansion and technology needs.

Second, ask what kind of work will the lab be doing, and what regulatory responsibilities will guide hardware and software investment at the lab. If your lab will be conducting extractable and leachable testing, you'll be considering chromatography and spectroscopy instruments and software systems, as well as requirements for retaining analytical results for regulators. Those labs accredited to standards such as ISO/IEC 17025 will have additional needs for instruments and software systems; such labs' data management system will likely need to be sufficiently robust to meet the needs of the standard. For those labs in more regulated spaces, the system will even need to interface to government systems, or at a minimum report in the regulatory body's specific format. These and other considerations will need to be made when choosing hardware and software.

Third, your laboratory's budget is always important. Does the budget allow for on-site hardware and software systems, with the personnel to maintain them? Is it easier to pay up-front or find a vendor willing to work with you on leasing or rental terms? Is their more value to be had from a slightly more expensive system able to provide the functionality that makes regulatory compliance more painless for the lab?

Finally, will the lab have someone on-site or on-call to resolve technology issues, including set-up and maintenance of software systems? If your lab will have little in the way of available tech help locally, you'll want to consider the distribution model you want to use for any installed software, i.e., you may want to consider SaaS solutions. An increasing number of software services are hosted using cloud computing, which when done well is an increasingly reliable option. Having someone else host the software for you typically means the hosting provider will carry a non-trivial portion of responsibility for technology maintenance and security.

Speaking of security, you'll also want to consider the cybersecurity of not only your software solution but also your overall laboratory operations. Does your organization have a cybersecurity plan already in place, or has the decision to make one been postponed? What extra investment is required to ensure your sensitive data is secure? How do your cybersecurity goals compare to the demands of standards like ISO/IEC 17025? Remember that how you rank your cybersecurity preparedness and implement a cybersecurity plan will also guide your technology investment decisions.

3.2 Functionality considerations

Technology aside, the lab will also want to consider the functionality of the various laboratory informatics solutions offered by vendors. Some laboratorians may already be familiar with the LIMS or ELN and understand what it is capable of doing for the lab. However, others may have little familiarity with such systems and have only vague concepts of how they function. Either way, it's useful for the lab to gain a clearer understanding of what such solutions can do. There are several ways to go about this, from reading through examples of user requirements documents to participating in demonstrations of software from various vendors. In fact, both methods remain useful, and a standard approach to acquisition will usually include both. In the end, the question for any prospective vendor to answer is "how can your solution meet our laboratory's requirements?" This is where functionality comes in.

The follow sections will look at functionality considerations first by introducing the user requirements specification (URS) as a means of learning more about system functionality. From there we'll look specifically at a LIMS and what its core and ancillary features look like, before finally re-addressing the URS from the perspective of how it can be implemented to full effect.

3.2.1 The user requirements specification as a functionality guide

A specification is "a detailed precise presentation of something or of a plan or proposal for something." This concept of a specification as a presentation is critical to the laboratory seeking to find laboratory informatics software that fulfills their needs; they "present" their use case with the help of a requirements specification, and the vendor "presents" their ability (or inability) to comply through documentation and demonstration. However, even the most seasoned of presenters at conferences and the like still require quality preparation before the presentation. Similarly, your lab has work to do beforehand. This is where initial specification research comes into play for the lab.

Your lab's requirements specification document will eventually be a critical component for effectively selecting a laboratory informatics solution. For those labs with limited knowledge of what such a solution is capable of doing, building a URS can be especially useful. There are numerous ways to approach the overall development of a URS. But why re-invent the wheel when others have already gone down that road? Sure, you could search for examples of such documents on the internet and customize them to your needs, or you and your team could brainstorm how a laboratory informatics solution should help your lab accomplish its goals. Importantly, your lab could also turn to a mature URS like LIMSpec 2022.

LIMSpec is a robust laboratory informatics requirements specification document that has evolved significantly over the years, and any lab can turn to LIMSpec to better visualize what the critical requirements of a LIMS (or other laboratory informatics solution) are. With the current version of LIMSpec having at its core standards such as ASTM E1578-18 Standard Guide for Laboratory Informatics and ISO/IEC 17025 General requirements for the competence of testing and calibration laboratories, the LIMSpec makes for a durable URS that, when used to acquire an informatics solution, can better help a laboratory choose appropriate functionality based upon current standards, regulations, guidance, and more.

LIMSpec is divided into five distinct sections, with numerous subsections in each. These sections and subsections should be able to address most any requirement you have for your system. Of course, if something isn't covered by LIMSpec, you can always add additional requirements. More importantly, if you have little concept of what functionality systems such as a LIMS or SDMS should have, reviewing this URS can give you a leg up, as can participating in vendor demonstrations. Of course, the base LIMSpec can be used to develop your lab's custom URS to present to potential vendors. (More on that in a bit.)

3.2.2 Core functions and features

While laboratory, scientific, and clinical informatics vendors may provide a similar core set of functionality in their solutions, there's still a lot of room for variance. Some vendors may try to make a one-size-fits-all solution, while others may focus on certain specialties or uses. In the end, despite the different approaches, a certain set of core functionality becomes apparent. This guide will focus on the LIMS/LIS and its functionality. You should expect the following functionality to be demonstrated in a mature and professional LIMS/LIS offering:

Test, experiment, and entity management

• sample/specimen log-in and management, with support for unique IDs
• batching support
• barcode and RFID support
• sample/specimen tracking
• pre-defined and configurable industry-specific test and method management
• pre-defined and configurable industry-specific workflows
• clinical decision support (for clinical)
• event and instrument scheduling
• templates, forms, and data fields that are configurable
• analytical tools, including data visualization, trend analysis, and data mining features
• data import and export
• robust query tools
• document and image management, with support for unique document numbers
• project and experiment management
• case management (for clinical and forensic)
• supplier/vendor/customer/patient management
• storage management and monitoring

Quality, security, and compliance

• quality assurance / quality control mechanisms
• changed, amended, or re-issued report management
• data normalization and validation
• results review and approval
• trend and control charting for statistical analysis and measurement of uncertainty
• version control
• user qualification, performance, and training management
• audit trails and chain of custody support
• configurable and granular role-based security
• configurable system access and use (with log-in requirements, account usage rules, account locking, etc.)
• electronic signature support
• configurable alarms and alerts
• data encryption and secure communication protocols
• data archiving and retention support
• configurable data backups
• environmental monitoring and control
• incident and non-conformance notification, tracking, and management
• instrument lock-out

Operations management and reporting

• configurable dashboards
• customizable rich-text reporting, with multiple supported output formats
• custom and industry-specific reporting, including certificates of analysis (CoAs)
• synoptic reporting (for clinical)
• industry-compliant labeling
• email integration
• internal messaging system
• revenue management
• instrument interfacing and data management
• instrument calibration and maintenance tracking
• inventory and reagent management
• third-party software and database interfacing
• data import and export
• mobile device support
• voice recognition capability
• results portal for external parties
• integrated (or online) system help
• configurable language

3.2.3 Additional useful features

The following features are examples of additional LIMS/LIS functionality beyond the core functions a laboratory may seek (it is not meant to be a complete list):

• audit management
• clinical research support
• complaint management
• customer relationship management
• electronic laboratory notebook support
• ERP and accounting interfaces
• inventory reconciliation
• invoicing and quotation support
• product specification management
• project management
• recipe management
• reflex testing support
• safety tracking and compliance
• single sign-on support
• stability testing management

3.3 System flexibility

Before selecting a solution, your laboratory should also have internal discussions about how diversified its offered services are, as well as what the future may bring to the lab. If, for example, your lab is currently configured for one type of testing, does your existing laboratory informatics system—or the ones you may be considering—have the flexibility to add other types of testing, protocols, and workflows? Will you be doing the footwork to add them, or will the vendor of your system support you in that effort? If you're a start-up, will your lab be focusing solely on a specific type of testing and expand into other types of analytical work later, or will your test menu need to be much broader right from the start? In most of these cases, you'll desire software that is flexible enough to allow for not only running the specific tests you need now, but also sufficiently expandable for any future testing services your lab may conduct in the mid- and long-term. Having the ability to create and customize sample registration screens, test protocols, labels, reports, specification limit sets, measurement units, and substrates/matrices while being able to interface with practically most any instrument and software system required will go a long way towards making your expanding test menu and workflows integrates as smoothly as possible.

Such a system will typically be marketed as being highly user-configurable, giving labs a relatively painless means to adapt to rapid changes in test volume and type over time. However, once you've internally addressed current and anticipated future growth, your lab will want to learn what explicitly makes any given vendor's system user-configurable. How easy is it to configure the system to new tests? Add custom reports? What knowledge or skills will be required of your lab in order to make the necessary changes, i.e., will your staff require programming skills, or are the administrator and advanced user functions robust enough to make changes without hard-coding? These and other such questions should be fully addressed by the vendor in order to set your mind at ease towards a system's stated flexibility. Ultimately, you want the system to be flexible enough to change with the laboratory—and industry—itself, while minimizing overall costs and reducing the time required to make any necessary modifications.

3.4 Regulatory compliance considerations

When considering their laboratory informatics solutions, labs will also want to take regulatory- and standard-based compliance into consideration. In regards to regulatory compliance in particular, it may be helpful to approach the topic from the standpoint of adopting standards. Consider first that the risks and consequences of performing a task poorly drives regulation and, more preferably, standardization, which in turn moves the "goalposts" of quality and security among organizations. In the case of regulations, those organization that get caught not conforming to the necessary regulations tend to suffer negative consequences, providing some incentive for them to improve organizational processes and procedures.

One of the downsides of regulations is that they can at times be "imprecise" or "disconnected" from what actually occurs within the organization and its information systems. Rather than focusing heavily on regulatory conformance, well-designed standards may, when adopted, provide a clearer path of opportunity for organizations to improve their operational culture and outcomes, particularly since standards are usually developed with a broader consensus of interested individuals with expertise in a given field. In turn, the organizations that adopt well-designed standards (e.g., ISO/IEC 17025) likely have a better chance of conforming to the regulations they must, and they'll likely have more interest in maintaining and improving the goalposts of quality and security in the lab.

Additionally, reputable software developers of laboratory informatics software will not only adopt their own industry standards for software development but also understand how regulations, standards, and LIMS requirements intersect. Given that understanding, the developed software should meet regulations and standards, help the laboratory comply with its regulations and standards, and be of reliably good quality.

If you're a potential buyer of a laboratory informatics solution, it may be that you know a bit about your laboratory's workflow and have at least a remedial understanding of how certain regulations and standards influence how that workflow is conducted, but you're not entirely informed about all the details of how a LIMS can help your lab better conform. Turning to a URS such as LIMSpec—which was developed around laboratory regulations and standards, including ISO/IEC 17025—and reviewing the various statements contained within may be necessary to help further inform you. Additionally, as you investigate various informatics options, you can then use the requirements in the URS as a base for your laboratory's own requirements list. Using the categories and their subdivisions, you can then add those requirements that are unique to your laboratory and industry that are not sufficiently covered by the base URS. As you review the various options available to you and narrow down your search, your own list of requirements can be used as both as a personal checklist and as a requirements list you hand over to the vendor you query. And since your URS is based off the standards and regulations affecting your lab, you can feel more confident in your acquisition and its integration into your laboratory workflow.

3.5 Putting a URS to work for your lab

As stated prior, building a URS specific to your lab can easily start by examining an existing URS like LIMSpec, which covers most functionality a laboratory could need out of their informatics solution. However, LIMSpec is extensive in what it covers. During the initial research put towards your URS, know that you likely don't want to send a full, comprehensive URS to vendors, at least not in the initial discovery stages. Most vendors appreciate a more inviting approach that doesn't initially overwhelm. Early on, you're better off to go with a limited yet practical set of requirements carefully chosen because they matter to you and your laboratory the most. If your laboratory is a food and beverage lab, support for molecular biology workflows, stability studies, and production management could be critical. In the case of a lab seeking a solution to help them better comply with ISO/IEC 17025, the lab might want to focus on requirements related to complying with the standard.

However you choose to approach URS development and presentation, you'll likely want to wait until after participating in several vendors' software demonstrations before even considering your URS to be complete. The demo offers a unique and valuable opportunity to see in-person how data and information is added, edited, deleted, tracked, and protected within the context of the application; you can ask about how a function works and see it right then and there. Equally, it is an excellent time to compare notes with the vendor, particularly in regard to requirements your lab deems being critical. You can ask the vendor in real-time to answer questions about how a specific task is achieved, or how the system addresses specialized needs, and the vendor can ask you about your lab's system and workflow requirements and how you best envision them being implemented in the system.

Again, be careful about falling for the temptation of presenting a full URS or other specification document to the vendor during the demonstration. You'll want to wait until after participating in several software demonstrations to consider presenting your full specification document to the vendor, and that's assuming that you've grown enamored with their solution. By waiting to finalize your lab's URS until after the demos, a common error is avoided: too often labs think the first thing they must do is create a requirements list, then sit back and let the informatics vendors tell them how they meet it. Remember that even though most labs thoroughly understand their processes, those labs likely don't have as strong a grasp on the informatics portion of their processes and workflows. Participating in a demo before finalizing your list of specified requirements—or having only a minimal yet flexible requirements list during the demo—is a great way to later crosscheck the software features you have seen demonstrated to your lab's processes and any initial requirements specification you've made. After all, how can you effectively require specific functions of your laboratory informatics software if you don't fully know what such a system is capable of? After the demonstrations, you may end up adding several requirements to your final specifications document, which you later pass on to your potential vendors of choice for final confirmation.

In some cases, rather than approaching vendors, a lab may want to take a different exploratory route by issuing a request for information (RFI) or something similar. An RFI is an ideal means for learning more about a potential solution and how it can solve your problems, or for when you're not even sure how to solve your problem yet. However, like when approaching a vendor directly, the RFI should not be unduly long and tedious to complete for prospective vendors; it should be concise, direct, and honest. This means not only presenting a clear and humble vision of your own organization and its goals, but also asking just the right amount of questions to allow potential vendors to demonstrate their expertise and provide a clearer picture of who they are. Some take a technical approach to an RFI, using dense language and complicated spreadsheets for fact finding. However, as previously noted, you will want to limit the specified requirements in your RFI to those carefully chosen because they matter to you and your lab the most.

Remember, an RFI is not meant to answer all of your questions. The RFI is meant as a means to help narrow down your search to a few quality candidates offering functionality that meets your needs, while also learning more about each other. Once the pool of potential software vendors is narrowed down, and you then participate in their demonstrations, you then can broadly add more requirements to the original collection of critical requirements from the RFI to ensure those vendors can meet all or most of your needs. That said, be cognizant that there may be no vendor that can meet each and every need of your lab. Your lab will have to make important decisions about which requirements are non-negotiable and which are more flexible. The vendors you engage with may be able to provide realistic advice in this regard, based upon your lab's requirements and their past experience with labs. As such, those vendors with real-world experience meeting the needs of laboratories like yours may have a strong leg up on other vendors.

Ultimately, your URS may look similar to LIMSpec, or it may have a slightly different format. Many prospective buyers will develop a requirement specification in Microsoft Excel, but that has a few minor disadvantages. Regardless of format, you'll want to give plenty of space for vendors to submit a response to each requirement. With a more complete URS in hand, and your vendor list narrowed down to a few possibilities, you're ready to submit the full URS to those vendors. Other considerations come into play afterwards, depending how those vendors' respond to you URS. How well did the vendors respond to your laboratory's unique set of needs? Were there critical areas that one vendor could address with their off-the-shelf solution but another vendor would have to address with custom coding? Did any of the vendors meet your budget expectations? Have you followed up on any references and customer experiences the vendors provided to you?

4. What other considerations should I make, and how much will it cost?

Hopefully, once all the due diligence is done, and with a little luck, you've found a vendor that fits your technology and functionality needs, even if a few minor compromises had to be made along the way. However, there's obviously more than technology and system functionality to consider! What are some implementation considerations? How is the vendor's solution offered: in the cloud or locally? What kind of licensing is used? What are the specifics of the maintenance, warranty, and support plans? And of course, what sort of cost (perhaps better to think of it in terms of "investment") is involved? This next section addresses these questions and more.

4.1 Implementation

If you've ever worked through a system implementation with a vendor, it was hopefully a smooth process. However, there are plenty of horror stories out there, highlighting the need of the laboratory to discuss in detail how a potential vendor will handle installation, validation, and training for the informatics solution. Does the vendor truly understand the industry and your needs? Does the vendor assign a project manager who will work with you, from planning to go-live and beyond? Can they offer you references of other labs that have gone through implementation so you can compare notes with those labs? How much attention does the potential vendor give to related issues such as data integrity of migrated data? Do they have the means to properly handle your legacy data? And are they able to work with your schedule, even if it means implementing software at off-peak work hours?

As you finally get down to the ultimate decision on which vendor to work with, you may wish to start setting up an implementation checklist as part of your early project planning. Do you receive a help desk account as part of the implementation process, and if so, what information is included? If not, you'll need to keep track of specific details such as business associate agreement (BAA), sales agreement, scope documents, welcome letters, documentation, and approved staff who can utilize the vendor's support. You'll likely need to share other configuration details with the vendor, including time zone requirements, DNS and URL requirements, up-time monitors, and administrative account requirements. Finally, you'll want to ensure you and the vendor are on the same page concerning any additional customization, integration, and system validation requirements, ensuring the roll-out period is pain-free and efficient.

4.1.1 Internal and external integrations

Laboratories acquire data management software for many reasons, including improving accuracy and quality, saving time, increasing productivity, and adding capabilities. One way of doing all of those activities is to integrate or interface your systems, databases, and instruments so that human error is greatly reduced or eliminated, workflows are automated and sped up, and each component's capabilities are brought into play in the most efficient and effective ways possible. As such, you'll want to inquire with the vendor about its solution's hardware and software integration capabilities. Is it designed to interface with every laboratory instrument or software that can output any readable electronic file? Or are integrations limited to certain instruments and systems? How does it connect, i.e., what protocols does the software depend on to connect with other systems? Does the system allow a user to map their own file imports and exports? Can system processes be set to detect new instances of file outputs at regular intervals? Ask these and other questions to make sure the vendor clearly describes what internal and external integrations are supported with their application.

In many cases, a vendor's LIMS solution will have instrument integration capability built into the software, but occasionally such interfaces are separate from the main software. Today's instrument interfaces are generally built on standardized communication protocols such as RS-232, RS-422, IEEE-488 (GPIB), USB, Ethernet, and more. The LIMS that can support such instrument integrations is increasingly vital to the ISO/IEC 17025 laboratory. Such labs may also want their laboratory informatics solution to be able to communicate with other software and databases. This is often done using application programming interfaces (APIs) that depend on web services implementation protocols such as REST and SOAP. These messaging protocols actually allow for the creation of an API that receives communication requests and sends responses between two software systems. A more practical example is wanting your laboratory informatics solution to communicate with an enterprise resource planning (ERP) application or a QMS. Perhaps rather than housing quality management documents exclusively in the LIMS, the lab has had a dedicated electronic QMS for years, and they'd like to be able to interface that with the LIMS. APIs and communication protocols make this happen.

4.2 MSW, updates, and other contracted services

The maintenance, support, and warranty (MSW) offered with the vendor's solution is almost as important as the solution itself. The laboratory informatics solution you acquire is more than than the software you operate: it's mission-critical and deserves having a reliable and responsive team with the necessary resources to ensure it remains operational. Downtime can negatively affect both immediate customer satisfaction and your reputation. As such, it's imperative you ask the vendor about the details of its MSW, making sure you understand what is and isn't covered, as well as how much it will cost (discussed in the next section). Cost-wise, industry norms are anywhere from 15% to 25% of either the license fee or total contract, levied annually to provide this coverage. Alternatively, it may simply be included with your subscription. The MSW will include a specified number of support and maintenance hours or guarantees. The actual warranty should be unlimited for as long as the MSW or subscription is kept current.

Maintenance includes any and all work necessary to keep your system working as designed. It should include updates, patches, or fixes, and most if not all upgrades. (Note, however, a major upgrade to a totally new edition may not be covered, but it may come at a negotiable, significantly lower cost.) The support aspect of MSW generally consists of a specified number of hours dedicated more to helping you with the operation of the system rather than "fixing" anything. Support includes guidance on training, password or login support, and more. Finally, with any professional application you also expect to have a warranty. The warranty should cover anything that doesn't work that otherwise should for the designated period of time. That includes any standard features and functions, as well as any additional ones that were delivered and signed off on, and any other work performed by the vendor or its representatives. However, a typical warranty does not cover anything that was working fine, but upon being manipulated in a way beyond normal operation the functionality ceased. In these cases, you'll probably have to pay to get it fixed.

Beyond the MSW, additional updates and services related to the system may also be required. No matter how well it is pre-configured, any professional laboratory informatics solution will require some amount of standard setup to reflect your particular lab. This includes adding lab branding and demographics for reports and certificates; entering users, their roles, and access permissions; adding and/or modifying tests and workflows; renaming fields; adding or hiding fields; setting up a web portal; and implementing interfaces. Equally indispensable is proper training for both users and administrators. And of course you may later find that you would like additional features or functions. These and other services may prove particularly useful to the laboratory with little in the way of IT and systems expertise. As such, the vendor may provide one or more of the following as a billable service for the laboratory:

• initial implementation meeting (e.g., initial planning, identify delta, set schedule)
• project management
• requirements gathering and documentation
• initial setup
• user and administrator training
• configuration and customization
• interface development and implementation
• custom screen and field development
• custom functionality development
• custom reports and labels
• custom triggers and alerts
• validation or acceptance testing (to a third-party standard or certification, or to agreed manufacturer specs)

4.3 Cost considerations

First, you'll want to be clear on what will be included in the sales agreement. Whether through an estimate or statement of work (SOW), it is important it includes exactly what is expected, being as specific as possible, since this will be the entire contractual obligation for both you the buyer and them the vendor. Note that line items may differ slightly from system to system, according to what features and functions are included by default with each vendor's solution and which, if any, are additional. Also keep in mind that any hourly amount in the the estimate or SOW is usually a best estimate; however, if sufficient attention to detailed requirements has been given, then it should be quite accurate, and in fact the final cost may even be below the quoted cost if you prioritize your own obligations so that the vendor's hours are used sparingly and efficiently.

The estimate or SOW should optimally include:

• licensing or subscription rates;
• required core items to meet federal, state, and local regulations;
• additional optional items and totals; and
• required services (implementation, maintenance and support, optional add-ons).

There are two primary ways to price a laboratory informatics solution: a one-time license fee or a subscription rate (cloud-hosted SaaS). If you have your own dedicated IT department and staff, you may prefer the former (although many system administrators are just as happy to let it be hosted elsewhere rather than add to their workload). Otherwise, a SaaS subscription may well be the better and more cost-effective way to go (since the primary IT cost is simply internet access). This item will be part of your up-front cost and, in the case of subscription, it will also figure into your first year and ongoing costs; otherwise only associated MSW will figure in. Typically, your first year's subscription costs will be due at signing. More often, the vendor may require three months or even the first year up front, so be prepared to factor that into up-front costs. However, it still is almost always less expensive at the outset (and over time, if you factor in IT costs and annual MSW) than paying for a license fee.

In addition to the two types of software pricing, there are also sub-types. Generally these are based on the number of users (or, in some cases, "nodes," which are simply any entities that access the informatics system, including other systems, instruments, etc.). How these are counted can vary.

• Named users: This method bases pricing on the actual individual users of the system, even if they only log in sporadically. Users may not use each other's logins (this is a no-no regardless of pricing structure, for good laboratory practice and other regulatory reasons).
• Concurrent users: This bases pricing on the maximum number of users who will be logged in at any given time. You can define an unlimited number of named users in the system, each with their own login credentials. However, only the number of concurrent users specified in the license or subscription may be logged in at any one time. For example, you may have 10 staff, but due to work processes, shifts, etc., only up to six might ever be logged in simultaneously. Whereas this would require a named user license for 10, it would only require a concurrent user license for six.
• Unlimited users: In the case of very large labs (typically 30 to 50 potential users and up), the license or subscription may simply be a flat fee that allows any number of users.

The line items in the estimate or SOW should reflect these nuances, as well as whether the listed costs are monthly or annual (for subscription services), hourly (typically for support and training), or a fixed one-time cost. Additionally, be cautious with fixed costs, as they typically represent one of two possible scenarios:

1. Final fixed cost: In this case, the cost has been figured by the vendor so as to cover their worst-case hourly labor total. If a line item (e.g., an interface) is not "worst case," then you are overpaying.
2. "Expandable" fixed cost: This is as bad as final fixed cost, and maybe even worse because it's almost a case of "bait-and-switch," popping up as a surprise. The initial "fixed cost" number is low, and additional hourly services are needed to actually deliver the item. This will have been provided for somewhere in the small print.

The bottom line is that everything in a laboratory informatics solution is really either licensing or hourly services. Just be careful if they are portrayed as anything else.

It is important to be clear which category each line item falls under when figuring costs: up-front (due upon signing), annual, or ongoing (e.g., SaaS subscription). It is useful to clearly lay out each and compute initial costs, as well as first-year and subsequent years' costs. For example, your initial obligation may be as little as your first year's subscription plus the first 40 hours of services. Different vendors have different policies, however, and you may be required to pay for your first full year's subscription and all services, or some other combination. Normally, though, any instrument interface or other service charges aren't due until they are implemented, which may be a few weeks or even a month down the road. This may depend on your budget, complexity of the SOW, and urgency. Your first year's expenses will include everything, including initial license fees; all setup and training; any interfaces and additional configurations or customization; and first annual MSW. (If this isn't included in the SaaS subscription, then it usually commences on full system delivery). Afterwards, your subscription and MSW will be the only ongoing expenses (included as one in this example), unless you choose to have additional interfaces or other services performed at any time.

5. Commercial vendors with public pricing

Among many other functions, LIMSwiki hosts information about commercial LIMS vendors (that can be found on the internet) and their offerings. Sometimes public-facing pricing can be found for those vendors, and it's added to the vendor record. The following tables represent those vendors who make publicly available some form of pricing information that can thusly be cited. Should it be discovered that a vendor removed pricing, no longer makes it public (including putting it behind a registration wall), or had a public-facing contract with pricing expire (as with the GSA), it will be removed from these vendor listings. See the description for each table for further details.

5.1 Website and submitted pricing

These vendors either post most of their pricing information for their solutions on their website or have submitted their pricing to the wiki admin directly. In all cases, be sure to contact the vendor to verify pricing, as it may change with little notice. Vendors are sorted by number of public videos demonstrating how their products work.

Vendor Pricing Has cloud or SaaS offering? # of demo videos LIMS? LIS? ELN? CDS and/or SDMS? Additional notes Research Innovations Limited Link Yes 90+ No No Yes No LabKey Corporation Link Yes 86 Yes No Yes Yes Biomatters Ltd. Link No 68 Yes No No No Creliant Software Pvt. Ltd. Link Yes 60 No Yes No No Vendor:LabArchives, LLC Link Yes 56 No No Yes No All but Enterprise pricing listed. Labii, Inc. Link Yes 56 Yes No Yes No Product is combination LIMS and ELN SLCLAB Informática SL Link Yes 38 Yes Yes No No Labstep Ltd. Link Yes 28 No No Yes No Terra Systems OÜ Link No 17 No Yes No No Pricing only available for MiniLIS, not other products. MEDEORA GmbH Link Yes 16 Yes No No No HealthScion Technologies Pvt. Ltd. Link Yes 15 Yes No No No LIMS is part of a larger overall platform. LabLynx, Inc. Link Yes 15 Yes Yes Yes Yes Pricing supplied directly by company. Labforward GmbH Link Yes 14 No No Yes No Mestrelab Research S.L. Link Yes 14 No No Yes No Autoscribe Informatics, Inc. Link Yes 13 Yes No No No Pricing supplied directly by company. CloudLIMS.com, LLC Link Yes 11 Yes No No No AgileBio Link No 9 Yes No Yes No INTEGRIS LIMS GmbH Link No 9 Yes No No No Pricing available for "Small lab solution"; videos in German Aiderbotics Corporation Link No 7 No No Yes No WebPathLab, Inc. Link Yes 6 No Yes No No Pay-per-report pricing made public Forney, LP Link Yes 4 Yes No No No Vendor:LabSmart Healthcare Technologies Link Yes 4 No Yes No No Simploud Limited Link No 4 Yes No No No Mci IT Pty. Ltd. Link Yes 3 Yes No No No The Edge Software Consultancy Ltd. Link Yes 3 Yes No Yes No Third Wave Analytics, Inc. Link Yes 3 Yes No No No BioInfoRx, Inc. Link Yes 2 Yes No No No Biomed Systems Ltd. Link Yes 2 Yes No No No LIMS available with ELN as add-on. Broughton Software Ltd. Link Yes 2 Yes No No No Pricing supplied directly by company. ML Consulting Technologies, LLC Link Yes 2 Yes No No No Free quality control LIMS for small laboratories Revol Software Solutions, LLC Link Yes 2 Yes No No No AINZ Corp. Link Yes 1 Yes No No No Former product was PharmWare. Blaze Systems Corporation Link No 1 Yes No No No Pricing supplied directly by company. Bureau Conseils et Services SCRL Link Yes 1 Yes No No No Starting prices listed Bytewize AB Link Yes 1 Yes No No No Pricing only available for O3 LimsXpress. TeselaGen Biotechnology, Inc. Link Yes 1 Yes No No No Pricing only available for Community and Starter editions. Vendor:Apex HealthWare, LLC Link Yes 0 No Yes No No Pricing only available for cloud-based POL version. BiochemLab Solutions Link No 0 No No Yes No Free ad-based and paid ad-free versions of ELN exist. ChemBytes Link No 0 No No Yes No Its successor to its free basic Espresso ELN will be Phoenix ELN, yet to be released as free, open-source software. Dorays Technologies Pvt. Ltd. Link Yes 0 No Yes No No General LIMS, Inc. Link No 0 Yes No No No Genetic Technologies, Inc. Link No 0 Yes No No No J Street Technology, Inc. Link No 0 Yes No No No LabLite, LLC Link No 0 Yes No No No Pricing supplied directly by company. Labstudio (Pty) Ltd. Link Yes 0 Yes No No No Microcline Projects Link Yes 0 Yes No No No Minerva Data Link Yes 0 No Yes No No Progeny Genetics, LLC Link Yes 0 Yes No No No Wolfe Information Systems, Inc. Link No 0 Yes No No No

5.2 Free, minimally featured version, but no other public pricing

These vendors provide minimal pricing information, stating they have a free, minimally featured version of their software but not revealing any other pricing information for other versions of the same software. These are usually vendors offering a tiered solution, with the lowest tier being the free tier. Vendors are sorted by number of public videos demonstrating how their products work.

Vendor Pricing Has cloud or SaaS offering? # of demo videos LIMS? LIS? ELN? CDS and/or SDMS? Additional notes Benchling, Inc. Link Yes 36 No No Yes No Academic pricing is free, but rest of pricing was removed. LabSpace, LLC Link Yes 0 No No Yes No Academic pricing is free, but rest of pricing was removed.

5.3 GSA pricing

These are vendors who have a publically viewable contract with the U.S. General Services Administration (GSA), and that contract displays prices for their solutions. As these are GSA prices, be aware they represent the lowest possible negotiated price. These prices aren't available to any entity outside of the Federal Government, and thus prices for non-government entities will be higher. If anything, they represent the lowest possible negotiated price. Vendors are sorted by number of public videos demonstrating how their products work.

Vendor Pricing Has cloud or SaaS offering? # of demo videos LIMS? LIS? ELN? CDS and/or SDMS? Additional notes Waters Corporation Link No 33 Yes No Yes Yes LabLynx, Inc. Link Yes 15 Yes Yes Yes Yes STARLIMS Corporation Link Yes 8 Yes No Yes Yes LabVantage Solutions, Inc. Link Yes 6 Yes No Yes No LabWare, Inc. Link Yes 6 Yes Yes Yes No Promium, LLC Link Yes 2 Yes No No No Xybion Corporation Link Yes 2 Yes No No No Bentley Systems, Inc. Link No 0 Yes No No No JusticeTrax, Inc. Link No 0 Yes No No No

6. Additional resources and help

6.1 LIMSforum

Formerly a LinkedIn-associated group, LIMSforum is a web portal for those interested in laboratory, scientific, and health informatics.

6.2 LIMSpec

LIMSpec is a user requirements specification built upon more than 100 regulatory, standard-based, and guideline-based resources, with ASTM E1578-18 Standard Guide for Laboratory Informatics and its own requirements list chief among them. LIMSpec borrows from that requirements checklist and then adds more to it from a wide variety of sources. An attempt has been made to find the most relevant regulations, standards, and guidance that shape how a compliant laboratory informatics system is developed and maintained.

6.3 LIMSwiki guides and research

A variety of laboratory, scientific, and clinical informatics research materials have been posted to LIMSwiki over the years.

6.4 LIMSwiki Q&A articles

A relatively new endeavor called "LIMS Q&A" has been started on LIMSwiki. The general idea is to take one question related to an industry, lab type, standard, etc. and concisely answer it, in brief.

6.5 LIMSwiki informatics resource portal

The informatics resource portal here at LIMSwiki features a collection of as many useful online scientific and health informatics-related materials and research tools as possible, including books, journals, blogs, web portals, education programs, conferences, and more.