Myths of LIMS - Debunked (Part 2)

Myth 5: Any LIMS we implement will just become outdated and hinder the laboratory operation

This myth is partially true.  There are several examples of commercial LIMS offerings that have forced clients to re-implement their configuration to install a major new release. This often occurs with major technology changes, such as moving from a desktop application to a web interface. Where organizations have implemented an in-house developed system, and as outlined in Part 1 of this blog series, resources may not be available to keep either the LIMS application or the underlying technology updated.

Autoscribe’s Matrix Gemini LIMS solution has been designed to allow you to upgrade without losing your configuration, system parameters, or your data. Clients upgrade through major releases and move from the desktop to the web application for instance, without requiring major configuration effort. It is a unique feature of Matrix Gemini that also allows it to grow and adapt as your processes change. The built-in Matrix Configuration Tools allow every screen, field, and menu to be modified using a graphical editor, without needing software coding skills. All configuration is stored separately to, and does not change, the software code, allowing software to be updated without affecting the configuration. Configuration changes appear instantly in both desktop and web applications without any additional effort.

Myth 6: All LIMS are configurable

Since every lab is different, even in the same industry, we often hear that all vendors say that their LIMS is configurable. The truth is buried in much more murky water. The term configurable is used by many vendors.

• Some imply that setting up tests, users, submitters, and other meta data is configuration. It is not. This is merely an administrative function within the LIMS.
• Others use scripting, or other programming languages (such as LimsBasic, C#, or Java) and imply this is configurable software. However, the approach of using typical software programming tools to create required functionality is really customization and has the added disadvantage of easily falling into GAMP Category 5 and therefore impacting the validation of the initial solution and subsequent upgrades. Changes using coding methods like this may not be automatically incorporated into a user’s system when it is upgraded and therefore require additional work as part of the upgrade to reintroduce it. There is also the possibility that the new version of the software may interfere with the correct functioning of the non-standard code requiring additional testing and validation.

The configuration process used by Autoscribe during the implementation and updating of Matrix Gemini LIMS uses the Matrix Configuration Tools. They do not require programming expertise and therefore the cost and the speed of implementation are less than with customization. All changes are separate from the underlying code and do not impact it, and vice versa. This makes upgrading the core system simpler and has much less impact on validation and re-validation. In addition, all changes are version controlled and can be rolled back if required. Configurations are also only released for general use once they have been approved. Will all this be the case for a customized solution? Users can be trained in the configuration tools, allowing clients more independence in making configuration changes themselves, if they want to. The configuration tools are used on real Matrix Gemini screens, so any changes can be seen and checked immediately. Compare this to writing lines of code and then checking to see whether the correct result has been achieved.

Is the above true of systems that rely on customization. One simple test to see whether a system is genuinely configurable, or if it relies on customization, is to ask the vendor if they support the changes, you may make and if this is part of the standard support agreement, included at no extra cost. So confident are we in our configuration approach that we support all customer developed, or modified, configurations as part of our standard support agreement at no additional cost.

Myth 7: If the lab implements a LIMS, I will lose my job

Laboratory staff sometimes worry that a LIMS will remove the need for their role. This is because LIMS are often initially justified by efficiency gains and cost savings. Often this comes down to estimating how many Full Time Equivalents (FTEs) of time will be saved by implementing a LIMS and automating lab processes. Taking an over-simplified approach like this can lead to the fear that time saved in processes such as automating sample receipt, result entry, calculations, review, and approval of results, and creating certificates of analysis will just result in cuts to staffing levels in the lab.

Over and over again we have seen that cutting staff is rarely, if ever, the end result of a successful LIMS implementation. The reality is that efficiency gains allow the laboratory staff to better use their key skills, training, and ability to innovate while the organization improves its performance, quality, and throughput.

Myth 8: We can't afford a LIMS

The question here should really be can you afford not to have a LIMS. Busy laboratories are often so occupied shuffling paper, validating results and creating certificates of analysis that they tend to miss the obvious. Customer case studies show that keeping data electronically and using the power of software to create certificates of analysis, management reports, self-service client portals, and so much more allow resources to be utilized more efficiently.

Use the ‘Justify the Purchase of a LIMS’ white paper to identify the benefits of implementing a LIMS. The time saved, the improved use of inventory, the reduction in human error and re-work can all show the advantages of a LIMS. This makes it easier to create a compelling business case for your LIMS.

Autoscribe also offers subscription-based pricing, so you can pay an annual fee rather than an up-front cost for user licenses. This operational expenditure might be easier to justify than capital expenditure, so It’s an option you might want to consider.

Summary

Not all LIMS are the same, so how do you create a short list of possible systems. Chief amongst the questions you should be asking are how is this solution configured? Can it be configured by customers? Are customer configurations supported by the vendor helpdesk? Not all labs are the same, indeed every lab is different! Use compare and contrast techniques to uncover the facts and debunk any myths you hear, both from vendors and internal staff. Applying a critical approach will stand you in good stead.