Whenever someone talks about building a custom LIMS, I insist they not take that route. However, there might be situations where that’s feasible. In any case, there are a number of issues to consider.
What Brought the Custom LIMS Topic Up
I’m thinking about custom LIMS, ELN, LES and LIS because they do occasionally come up in conversation. Even with the multitude of products available on the market and in many price ranges, these systems can be quite expensive. In addition, with all the money spent on services to get them to do all that they need to do to be worthwhile, they still can cost a small fortune.
A few years ago, I was speaking with a small research startup. The manager said to me, “But isn’t a LIMS just workflow?” My response gave examples on how it was workflow plus a lot more. In the end, though, the manager said his company had already spent money on a workflow tool and were going to just use that to build their own LIMS.
Workflow Tools Continue to Add Features
One warning I give to anyone who has any kind of tool they think will make building their own custom LIMS easy is that you’ll have to build everything that a commercial system already has built for you. You have to build sample login, auditing, security – you have to do it all.
Yet, with that, more workflow tools are including some of this. They won’t have sample management, for example, but some of them already offer many security layers and options. I took a free trial of one that even included features such as record auditing.
So, there are many things that you would have had to build that are now included. Once, again, though, they’re only the general-purpose items not the lab-specific ones.
Workflow Tools Not Trivial to Learn
In any case, I took a one-month free trial of a workflow tool. By the way, none of these tools are free, either. So, some of them aren’t going to be a cheap as you think they will.
But I started working on the tool to see what it would take just to build some truly basic features. And it’s about like working with the proprietary LIMS tools. It’s a lot of work to learn the tool and all the features that it offers. So, it’s not as if you just jump in and create something. The time it takes has the same steep learning curve as any other proprietary tool. That’s what these workflow tools are – proprietery tools.. With GeoMetrick Enterprises being the experts in the LabWare LIMS, let’s use that as an example. You might think it’s hard to learn LabWare LIMS Basic. However, it’s still hard to learn the workflow tools. That’s especially true of those tools powerful-enough to provide all the features you’ll probably need.
In addition, since you’re building your own LIMS, it’s not as if there’s a user group of people to ask about your specific application. You might find people who can help you when you get stuck with the tool, itself. But you probably won’t find anyone who can necessarily advise you on how best to build sample login, for example.
More on Why They’re Not Easy to Learn
I’ve previously told the story about a platform I wanted to build a LIMS into. It was a situation where I saw a potential pre-existing market of people that would be likely to buy the specific LIMS if it were run on the platform I wanted to build onto. The platform vendor was offering incentives to get people to build on their platform. They were giving all types of resources to make it happen. There were all sorts of free accounts for developers and other access.
Yet, in the end, I was never able to quite get everything necessary to make it all happen. The platform vendor didn’t put enough thought into making available all the necessary tools and I gave up on it. I don’t know if they ever succeeded. However, I got to a point where I decided I’d spent enough time on it and moved onto something else. So, if you see something that looks truly promising, you have to take the time to get all the pieces together. In some cases, it might not be possible. If you have users waiting on you to provide something to them, that non-delivery becomes a huge problem.
This is a special case, of course. However, the point I’m trying to make is this – just because something looks like it will be right for the job doesn’t mean you’ll be able to get all the parts to properly work together.
Some Positive News for Workflow Tools
Now that I’ve given you all my negatives, let me give some positive thoughts about them.
If your company has a workflow tool that it’s purchased and supports, it might not be a bad idea to use it. Let’s suppose that you already need to take the time to learn it and develop expertise in it. In that case, it’s not the worst idea to evaluate it as a possible platform for something like a LIMS, ELN or LES.
Granted, it’s still not going to be easy. I’m not trivializing the amount of work it will take. However, if you’re already using it as an alternative, I’m just saying it wouldn’t hurt to consider it.
Instead of Custom LIMS, Custom LIMS Add-Ons
On the other hand, as I just stated, it would still be quite a lot of work to build your own system. There’s a lot more to it than you realize until you get into it.
But that’s not as true for the add-ons. For example, we get into theoretical discussions about what exactly “belongs” in our systems. So, does instrument maintenance belong in LIMS, we ask? If it’s being managed by lab people, then it does; otherwise, buy metrology software and leave those people alone.
As another example, what about scheduling? We do a lot of work to schedule work and people in something like a LIMS, sometimes interfacing it to outside software such as the corporate calendar system. But does all this programming belong in the LIMS?
The Example of Scheduling
Let’s take any big LIMS and since we’re the experts on the LabWare LIMS / ELN, let’s use that as an example. This system does have ways to mark holidays and schedule events to happen. However, that’s not a replacement for the corporate calendar system. Most companies use their corporate calendar system to mark each site’s holidays, each person’s days off, meeting blocks, and other items that effect scheduling. You can’t replace the corporate calendar system with a LIMS.
As an alternative, we might interface with the corporate calendar system. Then, we would write quite a lot of code to interpret its data. Alternately, we might write some other huge amount of code to use the holiday calendar and other options to determine how we will schedule work. Then, as we schedule it, we probably create folders to push it into the LabWare LIMS. We would then rebuild the folders each day based on priorities, amount of work to do, open resources, trained resources, instruments available, and some other variety of factors.
Here’s the question: should we do all this work in the LIMS or should we do it, elsewhere? There are many factors that contribute to the design of these new add-ons. Creating this add-on design has to do with resources, schedules, money, technology, and yet other factors.
Custom LIMS Add-Ons: How To Decide
Often, our determination on where to build add-ons is based basically on two things:
- Who will use it and where will they use it? If the person using it is external and has no LIMS access, we’re less likely to try to write the code in the LIMS than if the person is internal and already a LIMS user.
- Who is available to develop this? If we have a LabWare LIMS developer, we are more likely to build the solution in the LIMS than if we don’t. If we have someone on the other side, someone with corporate calendar expertise, for example, we’re more likely to use that person to build the solution than if we don’t.
So, for example, there are times customers come to me and ask me to build all varieties of items that seem only marginally related to LIMS work but, since I’m there and since it is at least somewhat related, they ask me to do the work. And they ask me to do it because they don’t know if they can get another resource. If they look for someone else, they might not find someone else – they risk not getting it done.
With that, there are times when I’ll write all code in LIMS Basic (if we’re using a LabWare LIMS / ELN). Sometimes, we’ll use a combination of tools. It’s common to use the LabWare product along with Northwest Analytical tools, since there’s an interface. Other times, we’re combining the system with less common tools.
In other cases, I’ll build something that doesn’t directly access the LIMS, at all, just the database. I also warn that doing this circumvents system security. However, if you know what you’re doing and you mitigate the issues, properly, there are many ways to make this work. Just as one example, you can build database views that are specific to the purpose of linking with the outside tool, giving the other system only access to this view. That’s a simple example, but it gives you an idea how to get started.
Custom LIMS Add-Ons: Entirely Outside
The other task I put on my “to do” list was to look further into creating my own LIMS with tools such as Microsoft Flow, Power BI (Business Insights) and PowerApps. This was an academic exercise. I didn’t plan to actually build-out an entire application. I merely wanted to find out how difficult it would be.
For me, because I work all the time with LIMS databases, mainly SQL Server and Oracle, building some initial tables with a lot of fields took 10-15 minutes. Adding some data, another 10-15 minutes.
But, similar to all the other tools, these tools have a learning curve and, in fact, the application portion was quite slow. I knew it wouldn’t be a good idea to build myself a LIMS, but I did learn something.
If you know these tools and have them, they could be truly useful for building certain add-ons. So, actually, it wasn’t that hard to use Power BI to link with my tables to create some business intelligence. But I also noticed that PowerApps and Microsoft Flow have many pre-built links and app models.
So, if I were looking at building a scheduling application or an app for a tablet or phone, I would seriously consider these tools if I had access to them for the project.
SDLC, Validation and Support
Now, with all this said, remember that you still have to follow the SDLC (Software Development Life Cycle) and worry about issues such as testing. If you’re regulated, you still have to do the validation. Even if you push a bunch of blocks together, you need to verify you’ve mapped the correct process. And I think you know it’s not as easy as just doing a bunch of drag-and-drop, so you get the idea that there are a lot of triggers and other things that have to be checked. As such, even if you found a great workflow tool that made it easy to build your dream custom LIMS, you still have to write scripts and do the testing.
The other issue is that, whether or not the person building the system is a LIMS expert, you have to find a way to support them. You can’t just ask the LIMS team to build a LIMS view in the database and just hand it to some outside person to build an application. You do need to be able to answer their questions about whatever data and access you give them. There will always be questions.
In addition, this support has to be maintained for the life of the outside piece of the system. If you change the LIMS, you have to consider whether outside systems depend on it and need change, as well. That’s no different than if you’d built the add-ons right into the LIMS, but you just have to keep track of it all.
Finally
Using workflow tools, Microsoft building tools, or anything else isn’t the solution to getting a LIMS, ELN, LES or LIS in place. Building a custom LIMS is a huge amount of work. Especially since the person building it won’t be a system expert. There are all types of things they won’t think to add that you really are going to need. So, the entire effort tends to look a lot easier than it is. And, in that, buying a system isn’t as expensive as you might think when you do a true comparison to the cost of the tools and the work you’ll have to do to use them.
On the other hand, there might be situations where it’s practical. In addition, in the case of building add-ons, there are some that probably are best built outside the system.