Let's say you did not want to buy a LIMS and you've rummaged around online for an open source system that looked something like what you wanted but had no luck. Your only option left is to start from scratch. Your initiative immediately inherits several deficits:
- A) Sample creation, status lifecycle, and storage will have to be written from scratch
- B) Application management issues -- session management/concurrency management will have to be written from scratch
- C) Architectural features like module interfacing, etc. will have to be conceptualized/written from scratch
You have to build this stuff in or ignore it completely when you elect to start from scratch and do it yourself. This is a bit like building a car from scratch -- you have to build the un-fun stuff like the chassis and drivetrain parts. No one is going to see that stuff so in all likelihood the do-it-yourselfer is going to skimp in these areas and focus in on the engine and the overall look (body) and main cabin of the vehicle.
This lifecycle is actually what happens with lots of DIY LIMS projects --the internals are skipped and the entire design originates with the GUI. You can see this from the code where lots of the LIMS functionality and business logic gets hammered into GUIs when they should be completely separate. For instance, there should be several ways to log a sample into the system. If you bury all of the sample login logic behind a form you will have to call the form in order to log in a sample even if an interface between your system and another is actually trying to accomplish this task.
If we take a page from modern car makers we can figure out a decent path toward success. Remember how U.S. domestic cars used to be? Everything was done in-house and the end result was that U.S. cars were cheaply made and prone to have serious defects. (I owned a used Saturn once for about a week -- I've never seen a car with more problems.) Nowadays U.S. cars are 'constructed' from parts sourced from around the world. The end result is that the cars work better.
LIMS can be similar. Currently we buy a commercial LIMS and 'build on top of it' meaning we either customize or configure it. Trying to follow this path with open source LIMS projects is difficult because they lack the comprehensive infrastructure to be useful for anything not originally conceived (the genomics LIMS just doesn't work for the health care lab). What if, instead, we 'constructed' a LIMS from parts found around the world?
One last point -- some open source LIMS are built on top of other systems in order to provide some, or all, of the features previously mentioned. The Bika LIMS is built on top of a content management system called Plone to provide the needed infrastructure. The problem with this approach is that there is a lot of extraneous stuff in there that doesn't have anything to do with LIMS -- it is CMS code. When you grab a different system and build on top
of it you inherit its development/maintenance lifecycle so when bug fixes/patches/etc. come out for the underlying system you have to put them into your LIMS even though they provide you with no benefit whatsoever. Also, the learning curve is increased since you have to understand the underlying system simply, if for no other reason, to avoid messing it up when performing customization, configuration, or day to day maintenance.
What we need are toolkits built purely for LIMS that can be plugged into one another for easy system construction.Go Back
Citation: Food for Thought: What if we Constructed LIMS?. (2013). Retrieved Mon May 1 02:09:39 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1374248472