Friday, January 22, 2016

Can your LIMS handle Excel-like calculations?

When it comes to doing the same things over and over again, you need to make sure that even the simplest of keystrokes are necessary. If any steps prove to be unnecessary, and therefore avoidable, then it makes sense to do just that.

Steps that are not vital need to be nipped in the bud.

Question: What can you do if your LIMS program doesn't allow you to save these minor steps?

Answer: You can't do a thing about it!

When it comes to the nitty gritty things, like analyte calculations, doesn't it make sense to keep things simple?

Usually lab analysts find it easy to use Excel based formulas, since it is what they are used to. However, most LIMS programs that use a SQL Server backend may use calculations that are based on the underlying query language of SQL Server, known as T-SQL.

Now, since SQL Server and MS Excel are both Microsoft products, you would think that they would agree on the language of calculations (formulas in Excel) but there are a few times when this is not the case. it is important to know when they disagree.

One example is a very common formula in Excel which is the formula for calculating averages. Excel's formula language varies from the T-SQL function language in SQL Server.


Excel:

                                 AVERAGE()


SQL Server:

                                AVG()


So you can see that there are a few differences. The list of differences is not that difficult to learn.
Not every large one-size-fits-all LIMS package necessarily means that it is the easiest LIMS to set up. You also have to consider how easy it will be for both you and your staff to use on a daily basis.

Probably the two most difficult things in a LIMS program are the QC modules and the calculations. When you put those two items together, you really need to have the app be as intuitive as possible, otherwise you will be shopping for Prozac.

Another related issue goes way back to VB 6. VB 6 and SQL Server, again, both Microsoft products, did not evaluate "is numeric" the same way. If someone entered just a period for a result (Why would they? I've seen it happen a bunch of times.) one of the apps (VB/SQL Server would evaluate the value as numeric, whereas the other one would not. This created a nightmarish situation for us. 

The good news is that our Lablite LIMS program has a lot of the code written in the database in Stored Procedures, so the issue was easy to fix.

Make sure that you are getting a LIMS that is configurable.

Also, make sure that the entire program is not compiled. This make it impossible to customize. The more code that is not compiled (for the sake of this article) such as SQL Server stored procedures, the more flexibility you will enjoy. 

A LIMS can be a huge investment. Don't you want to reap huge dividends?




No comments:

Post a Comment