Price, access, reliability, and more must be considered

Before you can start deciding on which LIMS to get, you first have to determine what type of LIMS you want. By type, I am referring to whether you obtain a classic LIMS, where you license the software from the vendor and install it on a server in your facility, or you select a system that is provided to you as a service.

In the latter case, there are a pair of sub options as well. You can go with a provider that basically sets up a classic LIMS, with the exception that you access it over the Internet. This type of system is frequently referred to as a hosted LIMS or an application service provider¹(ASP) LIMS. Alternately, you can go with a supplier that provides software as a service (SaaS)^2,3 access to a LIMS. A hosted service can be running on a standard server hosted at the supplier’s data center or as a service in the cloud. A LIMS provided as a SaaS typically runs in the cloud. The difference can be confusing at first, particularly as salespeople frequently misuse the technical terms. For example, many people refer to any service provided from outside their firewalls as being in the cloud. However, the National Technical Information Service (NTIS) has a much more stringent definition.

Under the NTIS definition,⁴ a cloud computing offering must meet the following requirements; otherwise, you are running just a hosted service.

• On-demand self-service
• Broad network access
• Resource pooling
• Rapid elasticity
• Measured service

So, other than semantics, what’s the difference and why does it matter? The difference is that with an ASP, you are basically getting a classic LIMS, just with someone else handling the maintenance. With SaaS you get much more. Because of the resource pooling and rapid elasticity of the cloud, as your system demands change, whether in memory, storage, or processing power, the cloud adjusts to provide it. The only way to change the resources available on a hosted server is to physically swap out the server. In general, the SaaS system is also more redundant. If a particular server were to crash, processing would be taken over by another node.

Another difference is that a hosted LIMS is dedicated to your application, so only your group can use it. The corollary to this is that for other organizations using a LIMS, the vendor would need to configure another server dedicated to each organization, with all the setup and configuration work that implies. On the other hand, to qualify as a SaaS under the NTIS definition, an instance of the application must be multitenant.⁵ This means that many different groups of users might be running on a single instance of the system. The advantage of having many different groups running on the same instance of the application is that the vendor has to install, configure and maintain only a single instance of the application, greatly reducing their cost and the cost they pass on to you. You will also find that due to the elasticity of the cloud, you pay only for the resources you use. If you occasionally need significantly more memory or processing power, the cloud expands to match the need, so you don’t have to constantly pay for the maximum resources that you might potentially use.

While these definitions might sound esoteric, it is important that you understand them so that when a vendor talks about their system, you will know whether they are using the terms properly, because the implications of what the system will be able to do hinges on the accurate use of the terms. You must be the guardian ensuring that the terms are used correctly on any purchase orders, as I can guarantee that the majority of people in the typical purchasing department won’t know!

NIST graphical representation of cloud technology showing how it all fits together.So what are the different implications for running a LIMS on a local server, as an ASP or as a SaaS? Let’s start with one that might be a showstopper. With either of the two latter options, your data is normally moving outside your physical control and you must rely on the service provider to protect it. Assuming that standard security practices are applied, the risk of any data exposure is small, but to some organizations, anything that adds an inherent risk is unacceptable. Only you, or the people you report to, can make this decision. However, there is an alternative to keep in mind. Depending on the provider, some will set up a private cloud⁶ or hosted server within your facility. This may still inject a small increased risk of exposure, but it is much smaller than sending the data past your firewall.

The next factor is how important constant access to the LIMS is to your operation. If it’s down for more than a few minutes, do you have to shut down operations? How about for hours or days? Determining which system results in the lowest risk of an outage is more difficult to determine than you might think, as it depends on how well people in different departments are following best practices. At first you might think that remote systems would be riskier, as everyone has heard stories of construction crews digging up fiber optic data lines. But consider that a well-designed system would have redundant data lines connecting your facility to the vendor’s data centers, ideally using totally different paths and providers. Even with internal servers you can face this risk if you encounter a power failure or a critical network switch dies. Are all required switches and servers plugged into uninterruptible power supplies? And don’t forget that a data line can be cut as easily inside your facility as it can be outside.

Another factor relating to LIMS access is the reliability of the server that the application is running on. If you go with an internal server, do you have it configured with a hot backup so that in the event of a failure of the primary server, operation of the LIMS automatically falls over to the backup? Have you tested that it works? If you don’t have a hot backup, do you have a backup server that you’ll just need to power up? These same questions hold true for a hosted server. If this is important to you, this should be included in your service level agreement (SLA) with the vendor, not just assumed. With a SaaS system, because the resources are pooled and shared, the system should be much more resistant to the failure of an individual processing node. In the event that an instance of the application goes down, the SaaS architecture makes it much easier to configure the operation to fail over to another instance. Yes, there have been events that have shut down full computing centers, but these are rare. For highly critical systems, you would not only have multiple instances of the application running, but you also would have them running in geographically different data centers to minimize your risk. Again, this is a detail that would need to be addressed in your SLA with the vendor; don’t just assume this is what they do.

A related question is how your data backups are performed. With a local server, that responsibility falls to you. Have you confirmed that they are being backed up? I’ve encountered systems where everyone is certain that backups are being performed, only to discover when you start asking questions that they aren’t. Policy might be to do it, but systems sometimes fall through the cracks. Even if your data is being backed up, have you periodically verified that you can restore those backups? If your data is being backed up, are your IT services willing to restore the backed-up files? Believe it or not, I’ve encountered commercial IT groups that refused to retrieve a set of files from their backup tapes, saying that they use the tapes only when they have to restore a whole server. Hosted services and SaaS generally have the advantage that you can place the burden of performing backups on someone else, though that needs to be included in the SLA just to minimize any misunderstandings.

Another question to deal with is whether interfacing analytical instrumentation is supported. This is not just a productivity-enhancing feature but also can significantly reduce the occurrence of transcription errors. Do you need any special hardware, and does this vary with the system type? Even if the stand-alone systems directly support instrument interfacing, you need to confirm whether the hosted or SaaS provider systems do. A drawback of a SaaS LIMS is that commonly it is much more difficult to customize the application beyond the vendor’s supported configuration options.

I’m afraid that this article doesn’t answer the question of which system type to select, but it should provide you with the questions to consider so that you can make that decision. While you will frequently hear that SaaS systems are much cheaper than local installations, there are some caveats. Most analyses that I’ve encountered indicate that for price, a SaaS LIMS will usually be cheaper for small to midsize organizations and it becomes cheaper to have on-site servers for large organizations. Keep in mind that price is not everything.7 Dealing with some internal IT groups can be very frustrating, and it might be worth the difference in price to work with someone else.

Good luck with your selection.

References

1. J. Bishop, Cloud or Not: SaaS or Not, High. Ed CIO. (2011). http://blog.thehigheredcio.com/2011/02/27/cloud-saas/  (accessed March 16, 2015).

2. D. Singleton, What is SaaS? 10 Frequently Asked Questions About Software as a Service, The Software Advice Blog, Softw. Advice. (2011). http://blog.softwareadvice.com/articles/enterprise/saas-faqs-1072811/ (accessed February 25, 2015).

3. B. Hayduk, Primer on SaaS – 2015 | Health- Tech, Jazd Health Care. (2009). http://www.jazdhealthcare.com/healthtech/research/TOMOS-Software-LLC.htm?content-SetId=132945&parentPageType=3&category-Path=Lab-Management%2FLaboratory-Software%2FSaaS-LIMS   (accessed February 25, 2015).

4. P. Mell, T. Grance, SP 800-145; The NIST Definition of Cloud Computing, (2011). http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf  (accessed March 10, 2015).

5. S. Kajeepeta, Multitenancy in the cloud: Why it matters, Computerworld. (2010). http://www.computerworld.com/article/2517005/data-center/multi-tenancy-in-the-cloud--whyit-matters.html (accessed March 16, 2015).

6. J. Wesselius, Private Cloud, What Is It and Why Do You Need It?, Simple Talk. (2014). https://www.simple-talk.com/cloud/development/private-cloud,-what-is-it-and-why-do-youneed-it/ (accessed March 16, 2015).

7. V. P. Lemmon, Y. Jia, Y. Shi, S. Douglas Holbrook, J. L. Bixby, W. Buchser, Challenges in Small Screening Laboratories: Implementing an On-Demand Laboratory Information Management System, Comb. Chem. High Throughput Screen. 14 (2011) 742-748. doi:10.2174/138620711796957161.