End of Time at U of M - Regrets? (The LIMS)

Volume IIIEntry 34 of 55 in 20177 min read2 comments ↓

Written by Gloria Metrick on July 27, 2017. Published as written. It may not reflect how these systems work today.

In all these posts about the end of my job, some of you might be surprised that I'm only now writing about the LIMS. Me, too. U of M runs the LVS Biobanking solution which I knew before I had an inkling I would work there so I guarantee I'm not passing along any secrets, here. It was easy enough to see from reading people's LinkedIn profiles so they're not keeping it a secret.

LVS - One of the "Big" LIMS?
First of all, there are a handful of LIMS that lead the market share in our industry. In addition, they are meant to handle a variety of situations. To match that, they are likely the most expensive systems, as well, but are meant to handle just about anything. We disagree on whether to compare by sales or by installed base, various lists say different things, but here is what I believe them to be and in alphabetical order so that we don't get caught-up in the details of who beats who: Abbott Informatics StarLIMS, LabVantage Solutions (LVS) LIMS, LabWare LIMS / ELN, Thermo Fisher Scientific (TFS) SampleManager LIMS / LES.

Still, in what I tend to see in the marketplace, I think that the LVS system is probably part of this top tier. In the way the system is built and sold, it definitely seems competitive with these other systems. As for actual market share, as market share goes up-and-down for each product and as other systems float up into the market share for annual sales of systems, I'm just going to leave this aspect alone because it could be a discussion all its own.

Comparing the LVS System - The Markets
Each of these products seems to have markets where all-bets-are-off and customers might select any one of these products to fill the needs of the implementation, based on some overall features, price points, technology, and other factors. However, there are specific markets where customers tend to select one over the other.

For example, my impression is that SampleManager has the largest market share in the energy business. It is my impression that the LabWare system has a larger part of the market share for the clinical work (not "THE clinic" but the clinical laboratory work for the studies). I believe that customers trend toward the LVS system and Thermo Fisher Nautilus for biobanking.

This doesn't mean the other systems can't be used in these areas. However, it might mean that the particular vendor has built a "solution" for this market. That means that there should be something built specifically for this market and a knowledge of how to implement what the market needs. It doesn't always work that way but that is what it's SUPPOSED to mean.

It also doesn't mean there aren't plenty of other applications out there that compete in the market. We just sometimes talk as if the largest market share means a product is the best fit and that is NOT true.

Note: You might wonder this, "What is the difference between a feature and a solution?" My response is this: a feature is built-into the system. You might be given options with this feature, such as dropdown lists and radio buttons that let you "configure" how it will work but you cannot change it. On the other hand, a solution is built on top of a system. It's an initial set of programming and configuration combined to get you started. And that's all it's meant to do is get you started. You still have to do your workflow and compare to what you get. With that said, you can modify it to fit your needs.

For example, if you look at the LabWare Pharma Template, this is a "solution." It's a LOT of LIMSBasic programming and configuration that sits on top of the LabWare software. You can't change the LabWare system, itself, but you can change all this code and configuration in their Pharma template, if you need to. Now, my caution is this - this is specifically meant for a Pharma QC implementation. Each situation probably has a few adjustments they want to make but if you find yourself as a Pharma QC operation making too many major changes to this, you should rethink your motives.

Comparing the Technical Stuff
From the technical side of things, the LVS system has a little in common with both the LabWare system and SampleManager, yet still has some unique things of its own. Each of them addresses differences between their various instances in different ways, for example.

With regard to building the system, the underpinnings of the LVS system resides in a lot of programming that the user has access to. It has a variety of layers that must carefully be tracked and managed to maintain an understanding of what has been changed specifically for your system. This is similar to how SampleManager works. For example, in the LVS system you would create your own area for programming and if you wanted to change something that is core to the system, you wouldn't do it, directly, but would copy it to a new area and, at your own risk, make changes. But you wouldn't change the initial source. Ditto for SampleManager where we keep separate directories of code and copy it to a directory for new or changed code. I won't talk about the gory details regarding why we do it this way or the benefits and risks, just will say this is how you need to do it. Period.

This is as opposed to the LabWare system where the code is managed separately from the base system. When you create LIMSBasic, you're not changing anything native to the system, per se. You don't manage the code with a variety of directories. You might have a variety of directories where you save your LIMSBasic for historical reasons in order to track or distribute it but it's not because you're controlling your build. Caveat: I want to say that you can still totally mess up your LabWare system if you're not careful what you put in your LIMSBasic. Don't get too cavalier with what you do in there and be careful to follow ALL the rules or you'll be sorry (seriously, you think won't but you will and that's coming from 21 years of experience with these products).

When we get to the system administration, I see the LVS system appears to have more commonalities with the LabWare system. Examples escape me, right at this moment, but that has always been my first natural impression from using it.

A few unique aspects to the LVS system over the other two and these are just a few things about the system that, as an implementer, I especially liked.

Instead of just database tables and fields, you basically build entities in the LVS system. These are combinations of database tables and fields that are grouped-together so that they can be used, together. So, for example, the table for sample data has certain fields in it but the entity for the sample might reference yet more fields that are not entirely appropriate to put in the sample table but that are commonly needed when working with samples. In other systems, we handle this more with views but having them initially tied-together is convenient.
The way the web pages are managed is both powerful and you can do quite a lot with them without writing code. There does come a point where you have to give in and write code and you do have to include some SQL queries in some of the web pages to tie things together but their tools for this, while not dead simple to use are something business analysts could be using at some level without waiting for the programmers.
While I did only put together some example dashboards for my group, it was generally easy to do. There were a couple minor gotchas to learn but there's not much to it - you slap things on a dashboard and it's there, more or less.

Finally
What I should stress about the LVS system that it has in common with the other two is that they are called "Big" LIMS for another reason. They require a level of maintenance above what other systems would need. You need serious database administrators for these systems, should have people around with strong SQL query knowledge, and you will need some hardcore experienced programmers unless you intend to keep shelling out money to consultants to do it. You will need processes in place to maintain these that you will build because you will have your own unique combination of servers, databases and such.

Also, having just finished an upgrade from LVS V6 to V8, I could have written great deal about the types of differences you'll see, upgrade challenges and such. But here is where you have to hire me for my services. I don't mind giving a few tips, here-and-there, but this is where I see some opportunities for consulting work. As such, if you're about to go from V6 or V7 to V8 and you want someone around who can help make the transition smoother, please give me a shout.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/

Gloria MetrickAuthor

There are certain requirements that customers ask for that help narrow the search down. For example, if someone wants an ELN that is hosted by the vendor is the cloud, or if they want a LIMS specifically for a Drug Metabolism lab, or possibly only will consider an LES that runs on SQL Server - these are all requirements that will narrow-down the list.

But with that, as you said, there's still limited knowledge. As systems get smaller and smaller it becomes more and more difficult to find out what kind of reputation they have of implementing on-time and that sort of thing.

While I have had some of the big systems and the medium-sized systems in one selection, or medium-sized systems and smaller systems - one group usually emerges. Customers have specific budgets and needs and they're usually not served well by going too far outside the more appropriate group.

Let me give a couple examples:
1. A customer might include one of the biggest systems because they're so impressive in the list of things that can be done with them but, when compared with other systems of a MUCH different price range, a customer will usually decide that, while they'd love to buy the bigger system, it just doesn't make sense for what they need it for nor do they have the money to buy it, let alone maintain it long-term. Buying too big a system bites you when you start paying for annual maintenance and in the types of people you have to hire to maintain it.
2. A customer might include somewhat smaller systems because they're having a difficult time justifying the money for the larger systems. When they start comparing them, though, they realize there is something missing in the somewhat smaller system that they believe they do have to have. Sometimes, it has nothing to do with features but possibly experience in a specific industry - there are all types of these requirements that can make a difference. Plus, buying too small a system comes back to bite you when you grow and have sometimes purchased a system that possibly doesn't have the right features for where your growth is.

In the end, and while it might be nice in some ways to compare systems using the ASTM specifications, that is only one part of how customers buy systems. A lot of it comes down to the sales demo. If the sales rep isn't good, the best system can get tossed right out the selection process.

The conversation

2 comments from 1 person, July 27 to July 28, 2017. Gloria replied once.

July 27, 2017
John H. Jones
I wonder how you compare Lims vendors and products without first hand knowledge of the systems you are comparing. There is very little public information available and comparing one to another is many times like comparing apples and beef. The big LIMS serve the big budget market and the rest serve, well... The rest of the market. So making comparisons is not very relevant in that scenario. Comparing the big price Lims to each other is valid.

It would be nice to have an objective detailed comparison of those lims using the astm lims specification as the functional requirements guide. Problem is the vendors aren't putting that information out publicly. This does keep the comparisons hidden but the market seems to be served ok anyway.
1. July 28, 2017
  Gloria MetrickAuthor
  There are certain requirements that customers ask for that help narrow the search down. For example, if someone wants an ELN that is hosted by the vendor is the cloud, or if they want a LIMS specifically for a Drug Metabolism lab, or possibly only will consider an LES that runs on SQL Server - these are all requirements that will narrow-down the list.
  
  But with that, as you said, there's still limited knowledge. As systems get smaller and smaller it becomes more and more difficult to find out what kind of reputation they have of implementing on-time and that sort of thing.
  
  While I have had some of the big systems and the medium-sized systems in one selection, or medium-sized systems and smaller systems - one group usually emerges. Customers have specific budgets and needs and they're usually not served well by going too far outside the more appropriate group.
  
  Let me give a couple examples:
  1. A customer might include one of the biggest systems because they're so impressive in the list of things that can be done with them but, when compared with other systems of a MUCH different price range, a customer will usually decide that, while they'd love to buy the bigger system, it just doesn't make sense for what they need it for nor do they have the money to buy it, let alone maintain it long-term. Buying too big a system bites you when you start paying for annual maintenance and in the types of people you have to hire to maintain it.
  2. A customer might include somewhat smaller systems because they're having a difficult time justifying the money for the larger systems. When they start comparing them, though, they realize there is something missing in the somewhat smaller system that they believe they do have to have. Sometimes, it has nothing to do with features but possibly experience in a specific industry - there are all types of these requirements that can make a difference. Plus, buying too small a system comes back to bite you when you grow and have sometimes purchased a system that possibly doesn't have the right features for where your growth is.
  
  In the end, and while it might be nice in some ways to compare systems using the ASTM specifications, that is only one part of how customers buy systems. A lot of it comes down to the sales demo. If the sales rep isn't good, the best system can get tossed right out the selection process.

Comments are closed. This conversation is from 2017. Ask us to remove a comment

The conversation

Working on the same problem in your lab?