The problem (or “challenge” to the positive thinkers out there) with laboratory informatics software is that it’s complex and, thus, tends to have complex databases. Customer then become frustrated when they try to get resources to work on these databases because they tend to be so complex that they can’t be easily used by the report writers, statisticians and others who need to get data out of them. What do you do?

Why the ERD Doesn’t Help
Some software vendors have database models to share with their customers to aid them in future efforts (such as writing reports and compiling statistics), others don’t. Even when a software vendor has an ERD (Entity Relationship Diagram), it doesn’t necessarily help the customer, though. Since these databases are so complex and since, in many cases, customers are using such a small percentage of some of these large pieces of software, having an ERD of the standard system, doesn’t help because they’re so big and overwhelming that someone who doesn’t know the system will be overwhelmed.

Thus, this is why projects begin with experts in the system. They don’t use the ERD because they understand what parts of the system to use and how to apply it in a specific situation. For example, when I’m on a project, if a customer is working with manufactured batches of product and are working with the LabWare LIMS, I would normally work with the Lot Management portion of the system, which, in and of itself, does have a number of tables associated with it. Within those tables, there are a multitude of fields, only a handful of which will be used by any particular customer. As I document what I have done in the system, I often mention the tables and fields used. Additionally, I would normally be reviewing this with the customer’s personnel to give them an additional understanding past this documentation so that they can have future discussions on it. Thus, if the customer needs to bring it outside people to write report formats or do statistics in the future, they have two layers of information to guide those people: 1. Documentation; and, 2. People who can intelligently discuss these how these tables and fields are used.

For years and years and years we’ve had this same conversation. These are complex systems. Period. End of story. Start planning for it. Train people on the database while the experts are still on-site. That’s your best hope. Plan ahead. Get people to write documentation. Have your people review it before those experts are gone.

I know I’m repeating myself, but here it is, yet again: these are complex systems, which is why they require highly-paid experts like myself to work on them. Don’t expect to be able to do any more work on them without some kind of documentation on how your system is built (configured, customized, scripted, programmed, etc…).

Don’t wait until the project is done to start thinking about this. If you’re looking at all this after-the-fact, you’ve got a big problem. Your best and only practical solution is to bring an expert back to help you correct this situation.

Gloria Metrick
GeoMetrick Enterprises