Many laboratory directors from different disciplines have asked this one question regarding LIMS: “Should we buy a LIMS or build our own?†In the early 90s and into the mid-2000s, it was not uncommon for a laboratory to create their own LIMS from scratch rather than using the commercially available options. Upon occasion, those laboratories would purchase an open source code LIMS and then hire programmers to make that LIMS their own.

The commercial laboratory chain I worked for had an IT team that created their own LIMS, and at that time, it was a terrific system that simplified many tasks. However, the LIMS did not eliminate the necessity for each department manager to check the instrument data and pass it along to a data entry group to record the results. While this method was not perfect, the general consensus, especially amongst those with longer laboratory experience, was positive. The LIMS was a tremendous move forward from what it had been a few years back, and to date myself a bit, this new LIMS ran in DOS.

Now, while selling LIMS many years later, I talk to various laboratory directors, managers and IT staff, many of whom have purchased LIMS since having their own custom, internal LIMS drift away into memory. Of course, I also interact with a number of laboratories that are still using internally built LIMS. These still-functioning, custom LIMS vary between simple to extremely complex. One common occurrence is that the custom LIMS is built on old source code and in many cases, multiple codes. Upfront, from an analyst perspective, it functions well. However, behind the scenes, it gives the IT group extremely bad heartburn. As one IT director told me, “There’s more duct tape and glue than actual code at this point!â€

I recently spoke with a laboratory director who told me they would keep their LIMS because no commercial LIMS had what they needed. He began listing key requirements:
Audit trail
Scheduling features
Standard prep log
Etc., etc…
I kept my chuckle to myself and told him he would have a hard time finding a commercially available LIMS that did not have all those functions, along with ten others on his list and a few he had not thought of yet. The last time he had truly looked at a commercially available LIMS was 2006.

Now with the aforementioned conversation in mind, let us consider some factors associated with LIMS and how they compare between an internal LIMS in a laboratory versus commercially available from a LIMS company:

1) An IT staff with competent programmers has to be involved.

Being with a LIMS company, I can attest that good programmers are not easy to come by. Furthermore, finding programmers that understand either the laboratory and/or are good with working alongside chemist are particularly hard to come by. This all boils down to a numbers game as well. A typical large laboratory with an internal team keeping up their LIMS has one to five programmers on staff. On the other hand, even very small LIMS companies generally have a minimum of five to seven programmers at their disposal and small to mid-size LIMS companies usually have at least fifteen and often many more.

2) A better logic may exist.

I will be the first to admit that many good ideas come from our clients. We actively keep lists of ideas that our clients purpose and pooling these ideas is invaluable. This is a true benefit of working with laboratories that have a staff size of two to well over one hundred fifty and extending from commercial, non-profit and government concerns. This roundtable of ideas is simply not something a single laboratory can do.

3) Keeping up with new regulations is tough.

This can be particularly difficult if you work within various states under differing programs. We do what we can to stay on top of upcoming changes and actively attend meetings, but we recognize that we do not catch everything. Again, there is only so much a single laboratory can do. The benefit of a LIMS company working with many clients in multiple states is that clients bring these things to our attention if we miss them. There becomes sort of a critical mass of clients that a vendor must have before most of these changes are known ahead of time.

4) Reporting changes never stop.

One thing that seems to be written in stone regarding reports is that when an agency states they have created a final, revised version to be used for the next five years, it will change in the next two months. Many reports may be generated and modified through simple means within a report generator however some are far more complex, requiring programming on the backend. It is not uncommon for us to have at least two programmers at a time “simply†fixing and/or creating reports. An individual laboratory must handle this situation at their own discretion.

5) Technology is constantly evolving.

With the influx of changes to pre-existing systems and/or new technological advancements, there is a lot to manage. For example, programming languages are in constant flux, so a base code that worked on Windows XP does not necessarily translate to Windows 8. LIMS companies by their very nature have to keep up with these issues as best as possible in order to stay up to date. This is a very large burden for individual laboratories to handle.

A culmination of factors has led many laboratories to re-examine the question of build or buy. Good LIMS systems are available out of the box today, which was not the case ten to fifteen years ago. Additionally, LIMS companies, once established, have many ears to the ground to keep up with regulation and reporting changes as well input from clients to improve any shortcomings. A laboratory already has a full day’s work so why add to it?