LabWare and Other LIMS Database Structures

As I occasionally like to do, I’m writing this post based on a search phrase that someone used to find my blog. The phrase that inspired me, today, is: “labware lims tables”

Database Mapping and Understanding
If you’re looking at the structure of one of the larger laboratory informatics solutions, whether it’s the LabWare LIMS or other similar-size products, you’ve noticed that the database is so overwhelmingly large that there’s no possible way to understand what the usage of the tables and fields by merely looking at them – that you need more help than that.

First of all, there’s no-one that will understand every single table and field to explain it all to you, regardless how expert they are. And that person would probably be explaining it to you based on the “standard” system but if you’re looking at your own company’s database, that isn’t what you really need. — you need someone to explain how your company has implemented the system and how your system is using the tables and fields.

Documentation and Knowledge Transfer
This is where documentation and specific implementation knowledge come in. This is just another reason why companies don’t want to let one or a group of consultants come breezing in to implement quickly and then just leave without sharing that knowledge with the internal people (more than one internal person, by the way).

Training and Expertise
The other alternative to learn these database is to get some training and then to develop an expertise. Training merely points you in the right direction and then the learning part might take some time. Some companies have ERDs (Entity Relationship Diagrams) that they can provide, but that’s still usually just a starting point with regard to the main, unimplemented product.

When all else fails, people like me who are system experts are sometimes asked to come figure out how a system works so that it can be changed. So, you’ve paid once to get your process figured-out and to get it implemented. Now, to add insult to injury, you have to pay yet again to have someone else figure it out. The best you can do if you don’t feel you can do it on your own is to both find someone with the right expertise to do so, but also to make it clear that you want to minimize the cost. What I mean is this – if you want the person to totally reengineer your system so that you can document the entire thing, this is much more costly than if you want them to determine merely how a certain piece of the system works in order to change it. Make sure you’re clear with the person which meets your intentions. Plus, this second time around, get some documentation from the person who does this work rather than possibly paying for it all maybe a third time in the future.

Back to the LabWare LIMS and Others
Once again, some of these systems are massive. Imagine they have something like 100 tables and some tables like the sample table might have 100 fields to them. Also, because they are meant to be flexible systems, they could be taking many different paths with the database. However, the possibilities tend to be somewhat limited. If a system is “properly” implemented, there are certain most likely paths we experts know to look for. When we see certain “evidence” that the implementation varied from these most appropriate paths, we then know to start looking in other places and have suspicions about where those places would be.

While I feel sympathy for customers who find themselves in these situations, it’s not that uncommon and I find it a good use of my expertise to figure out what an implementation looks like behind the scenes in the database for systems like the LabWare LIMS. Just on the days when I think I’ve really seen every strange thing I could see in these systems, I run into yet another “interesting” (I’m trying to be kind, here) combination of implementation strategies.

We can blame a lot of things for this. Sometimes, it’s because the person implementing was neither experienced-enough to know the right path to take AND that they weren’t sufficiently guided in their task, since junior people should be expected to need some guidance by those people that have sent them to the customer’s project. Other times, I can guess that the implementer was acting out of desperation, not finding the right combination of tactics, and needing to find a way to “just make it all work.”

Before we start to blame third parties, foreign people or outsourcing, I can tell you that these problems exist regardless who is doing the implementation. We can look to the software vendors and large services vendors as much as the cut-rate implementers. Quality comes not from marketing ourselves cleverly or lots of reassuring words but from quality-induced actions and there’s no way to see those actions until someone is working on your implementation unless you’re really clever about the way you do your interviewing.

Gloria Metrick
GeoMetrick Enterprises

Leave a Reply

Your email address will not be published. Required fields are marked *