Consider the modern life science laboratory. It could be a bioscience screening lab, an antigen production or chemistry lab, a scale-up or formulation lab, it doesn’t matter. When you walk in you will see a pretty standard set of instruments, depending on the type of lab. There will be balances, robots for preparing, diluting and plating out samples, liquid chromatographs, cell counters, imaging machines, stirrers, centrifuges, spectrometers, etc. etc.
Most of them will be connected to the building’s network, by cable or wifi. And there will be a whole raft of PCs, laptops, tablets and touch-screen monitors controlling and managing this motley collection of kit. Also on these PCs will be the master, controlling software at the centre of this orchestra of instruments: the primary conductor – the Laboratory Information Management System or LIMS.
LIMS can go by other names – e.g. LIS or LES – but regardless of the acronym, these systems are all looking to achieve the same thing. A LIMS is, in essence, an informatics system to log in, schedule, monitor and track samples and materials, along with the (meta)data associated with them, through a lab-based process, from beginning to end. A LIMS also allows querying, searching and reporting (i.e. data exploitation), but at heart it choreographs samples around a lab and through a process, and captures a myriad of data along the way.
Conceptually the LIMS-instrument set-up is the same as the classical computing server-client architecture, where the LIMS is analogous to the server and the instruments are the clients. Server-based computing architecture has undergone massive disruption over the last 10 to 15 years culminating in Cloud-based computing and the growth of peer-to-peer (P2P) architectures.[1, 2]
As far back as 2003, McIntosh and Yau[3] proposed a P2P architecture for lab automation consisting of “peer instrument servers, an XML communication layer, and an open control center. Each instrument peer can control, be controlled by, and communicate information to other instrument peers to fulfill the automation task.” There was no need for the LIMS. One of the critical components to make such a P2P lab work was a suitable standard protocol to enable the instruments to communicate. Theirs was based on “XML-RPC, a lightweight communication standard built atop HTTP.” Unfortunately this standard did not at that time achieve wider acceptance, so the P2P lab approach did not take off.
It was this lack of globally accepted communication standards allowing the huge variety of lab instruments to talk to one another directly rather than through a central system, the LIMS, that has held back the wider acceptance of the P2P lab. This has allowed the LIMS to remain in its position of dominance. Now, however, the growing acceptance of such open communication standards as ANIML[4] , SILA[5], ODATA[6] and Allotrope[7] as well as concepts such as the Internet of Things (IoT)[8] have, I believe, made the position of LIMS and the LIMS-instrument architecture ripe for change.
The time has come for LIMS to be disrupted and toppled.
Bring on the Internet of Laboratory Instruments (#IoLT)!
References
- http://www.techrepublic.com/article/understanding-the-differences-between-client-server-and-peer-to-peer-networks/
- http://spectrum.ieee.org/computing/networks/escape-from-the-data-center-the-promise-of-peertopeer-cloud-computing):-
- McIntosh R. et al, A flexible and robust peer-to-peer architecture with XML-based open communication for Laboratory Automation Elsevier press J. Lab. Autom 8 2003 38–45
- https://www.animl.org/
- http://www.sila-standard.org/
- http://www.odata.org/
- http://www.allotrope.org/
- https://en.wikipedia.org/wiki/Internet_of_Things