---

One of our ongoing problems in the LIMS world is that we have a multitude of words and concepts that all sound the same but mean different things to different people, thus causing a great deal of confusion at implementation time. Helping a laboratory to determine which tools and structures to use within their LIMS for the best implementation is a challenge when relying on these terms. Since we can't expect everyone to know how the terms map to their new LIMS product, it is useful to gather information without using these terms.

A Sample is Not a Sample
Most people who have done a LIMS implementation seem to agree that a sample is not a sample. For example, most LIMS products have "samples" but these entities are not necessarily the same as what a particular laboratory calls a "sample."

Whatever the laboratory refers to as a "sample" then, might become something else within the LIMS. It might actually become a "sample" in LIMS, but it might also become an aliquot, a pull, or a subsample. Of course, aliquots, pulls, and subsamples are often referred to as "samples" within a LIMS, as they typically all have the same or similar structure, as well as following the sample lifecycle.

Some people chant, "om." I chant, "A sample is not a sample." There, I just can't say it enough times. "A sample is not a sample. A sample is not a sample."

A Test is Not a Method
Whatever a particular LIMS calls its tests, whether they're actually called "tests," "methods" or "analyses," they are not truly methods. Often, they are a representation of the information stored with regard to the method, and sometimes a copy of the method, itself. With that said, it is useful to remember that a "test" is not a "method" and the implementation will be easier. Furthermore, different companies have different ways to track their method versions. Within a LIMS, versioning doesn't tend to translate to that tracking system.

List of Work to Do
Each LIMS product seems to have its own name for the list of work put together for a person or instrument to run. They are called things like "batch," "worksheet," or "worklist," to give a few examples. During implementations of LIMS, I have found that none of these words necessarily means anything to the people working in the lab. Additionally, some LIMS products have so many ways to organize the list of work to be done that I no longer use the actual names of the tools because it often confuses the person in the lab. Instead, I ask them how they organize their work to figure out what work to do or what to load onto particular instruments.

When I come to a customer's site to begin requirements gathering, programming, project management, or whatever task they have hired me to do, I find that the people who will be involved with the project have usually been to their product's training class. However, their training gives them only the basics with which to begin. In many cases, it is my job to help them learn to apply these things. The way to do so is to talk generally about the different tools that might look like they all do the same thing. Another way around this is to pick a fairly general purpose tool and get everyone to really learn that well before venturing on to the other tools the system provides. Once employees are adept at a particular tool, its name and purpose will stick better in their memories.

Confused?
If I've confused you more, don't worry. The article isn't a lesson on how these words and concepts translate. The purpose here, is to make you vigilant to terminology issues that you will face and to help you look for those mismatches before your project gets too far into its implementation.

---

---