I recently wrote about the LabWare and the SampleManager systems but the last “big” system I started to learn was the Labvantage (LVS) system. Here are some thoughts to pass along to those of you thinking that that might be your next big adventure.
The Really Different Stuff
There are some things that are really different in the LVS system from the other two systems.
The most important is that way the web pages are created doesn’t seem comparable to the other two systems. I found it easy-to-learn and powerful but it’s one area you would focus on if you’re just coming to this system because it just looks nothing like what we do with the other two systems. I think the hardest thing to remember when learning to work with these web pages, is the concept of the “nodes” and how to figure out whether you’re using a custom node or not. If you don’t know what I’m talking about, you’ll have to learn all about it when you start working with these, but it’s part of the way the system knows which pages to show. It has to do with security.
The manner in which the system menus are setup is quite different from the other systems, although this didn’t seem that difficult to learn. I’m just saying that, once you figure out where this all sits, it’s not that hard to handle. However, as with the web pages, these also have the concept of changing security at various levels, and it’s just enough different than the LabWare and the SampleManager systems that you’ll want to sit back a moment and learn how the levels work before making real-life changes.
Also quite different is how to build the workflows and dashboards. It’s neither better nor worse, in my opinion, just mechanically very different between the three. And don’t forget to switch to Admin mode in the LVS system or the dashboard won’t be changed for real. It’s just a habit to get into when you’re building dashboards.
Some Things The Same
In all these systems, you have to understand which changes go live as soon as they are made and which ones require something else to happen. In the LVS system, you have to learn which changes you make require you asking people to logout and back in or which ones require you to restart the application server.
Also, it has the concept of role-based security, much like the other two systems, but with some options that are a bit different. But, overall, if you understand role-based security as an overall concept, you should be able to grasp the details of this.
Also similar to the other two systems is that you can find ways to create a personal system so that you can try things out and learn without affecting everyone else. As with the other two systems, you have to know what you’re doing to do this and you hopefully have someone around who has already done this for you so that you can jump right in. If not, don’t start with this, and that’s my tip for all these systems that, unless you know what you’re doing, don’t start by thinking you’re creating a separate system because you have to learn where the pieces and links are at, first.
High-Level Comparison to LabWare LIMS / ELN
The first thing I noticed is that the basics of the LVS system most reminded me of the LabWare LIMS. The way the role-based-security is setup, the way the system is generally administered – it all vaguely seemed a bit like the LabWare system. As such, if you’re switching from working with the LabWare system to the LVS system, you’ll find a lot that seems similar.
The other part that I immediately recognized were the log files. Just as some of the LabWare LIMS log files might seem cryptic and unhelpful but sometimes have important information in them, the same is true of the LVS log files. In fact, if you’re moving your system around, these log files will easily help you determine whether you have missing fields, for example, because you’ll see the SQL statements in the log files will produce error messages indicating that. And, like the LabWare SQL statement logs, where you’ll see additional commands added for security, the LVS SQL statements do the same. So, you can see how your statement is actually running when security is applied to it.
However, the programming you do with the LVS system is quite different than for the LabWare system. You’re using Java and Javascript (and a bit of Groovy) rather than something like LIMSBasic. If you’re merely putting a bit of code in fields to grab other data, as we do in the LabWare fields, where it’s just a snippet of code, then you’re going to learn a little Groovy and it will be pretty easy. But if you’re doing real programming, rather than the proprietary LIMS Basic, which is a lot easier to learn, you’ll be using the real-life Java and/or Javascript languages. However, as usual, the issue is to learn where to put it all, not just learning the languages.
And there’s another big difference – the places where the triggers are at are entirely different than the LabWare system. If you open up a web page in the LVS system and look at some of the pre or post Javascript, it does follow a similar concept to some of the LabWare triggers, but by no means are they a one-to-one match. Once you see that some triggers are on the pages and then you find the other places to look in the system, it will go a lot faster for you, but initially figuring this out is the first hurdle.
High-Level Comparison to SampleManager LIMS / LES
If you’re using VGL to do major programming, you’ll be in for a jolt to learn Java and/or Javascript (it depends what you’re doing) but if you’re using C#, it shouldn’t be that much of a stretch for you. While programmers have specific preferences based on a variety of factors, let’s face it – you use what the system uses and you just live with it – it doesn’t matter which one is “better” but in which one is the system standard (more or less).
The other significant similarity is that almost the entire system can be modified. If you have a serious understanding and method for administration and build of these systems, you can understand that you will manage the two systems in approximately the same manner. The tools and programming languages will look somewhat different, but the overall strategy is the same.
As in both systems, you don’t just go in and start changing the base code. You have structures for this, schemes to follow, SOPs, you follow naming conventions, you keep the base copies safe and you do some versioning. If you don’t know what I’m talking about then you shouldn’t be touching any of this.
Another significant likeness is that they both build the database structure for you based on something else. In SampleManager, you build the scripts that do this. In the LVS system, you build this within the system and then rebuild it.
LinkedIn and LVS
Not long ago, I did mention that I was losing some interest in LinkedIn and its ability to help me do my job. And, for the LVS system, just as with all the big ones, it seems there’s a pretty dead LinkedIn group out there. But here’s the catch – join it, anyway. I joined it and was severely disappointed.
Here’s the catch, though – I also found out that there are no customer discussion groups the way there are for the LabWare or SampleManager systems. I realized the only way to start discussions on the LVS system was to find other like-minded people in the world to share information with, especially with regard to the V8 upgrade that I was then working on, where it was new to a lot of people in the world, not just my group and where I was the first person in my group to be asking the questions on why things worked differently and/or were broken as we worked on our upgrade. In order to get things fixed in the upgrade, I had to find resources beyond just the support desk. In addition, my group was using the biobanking solution and it was a huge challenge to find people who intimately knew that solution, as opposed to merely knowing the standard system.
By search LinkedIn for “labvantage LIMS” and “lvs LIMS” I found mainly LVS employees. But by looking at who belonged to that discussion group, I found mainly customers and I found people who had good information to share and could have real discussions with me on things I wanted to investigate doing.
Now, if you look at my LinkedIn profile, you will see I no longer belong to that group. I got my use out of it, basically, then eventually left it when there were no longer real discussions going on. But I would seriously recommend joining and looking around at what’s in there. You can always unjoin, later.
Finally
If you’re already working with Java or Javascript and know a standard LIMS workflow, this system might not be a big jump for you to learn. But the hurdle to learn this system is greater because of the fact that you don’t have discussions groups.
Just in the past few days, I was watching some discussions come into my InBox (not for the LVS system, obviously) and, despite not necessarily being ones I was participating in, they kind of stuck in my mind that, some day, I might want to come back and read them in more detail if I was going to pursue some of what the people in the discussion were doing. And it’s just nice to know I can go read the archives if I really had to AND could come back and ask my own questions if I had to. It seems like a nice luxury to have and I appreciate it where it’s available. Where it’s not available, I will just have to be relentless about finding the information any way I can in order to get the work done, and that’s just what we all end up doing when we have to.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/