Laboratory automation and laboratory informatics Building a Smart Laboratory 2012


to have, as far as it practicable, electronic ways of working and effective and efficient hand-offs and transfers between applications and organisational units. Tere are three basic operating principles


of the smart laboratory that should be used to redesign or optimise the laboratory processes.[1]


Tese are:


1. Capture data at the point of origin: If you are going to work electronically, then data must be electronic from first principles. However, there are a wide range of data types that include observational data (e.g., odour, colour, size), instrument data (e.g., pH, LC, UV, NMR, etc.), and computer data (e.g., manipulation or calculation of previous data). Te principle of integration must be balanced with the business reality of cost-effective interfacing – what are the data volumes and number of samples coupled with the frequency of the instrument use?


2. Eliminate transcription error checks: Never re-type data, and design simple electronic workflows to transfer data and information seamlessly between systems. Tis requires automatic checks to ensure that data is transferred and manipulated correctly. Where appropriate, implement security and audit trails for data integrity and only have networked systems for effective data and information sharing.


3. Know where the data will go: Design data locations before implementing any part of the laboratory automation or informatics environment. Te fundamental information required is the volume of data generated by the instrumentation and where the data will be stored, i.e. in an archive system, with the individual data systems or on a networked drive? Te corollary is that security of the data and backup are of paramount importance in this electronic environment. In addition, file-naming conventions are essential to ensuring that all data is uniquely identified, either manually or automatically. If required, any archive and restore processes must be designed and tested so that they are reliable and robust. Te key message when designing electronic workflows is to ensure that once data is acquired it is not printed out or transcribed again, but transferred electronically between systems using validated routines. In addition, if working electronically there will be total reliance on the IT infrastructure and support systems, which need to be robust:


8


• Network cabling must not have a single point of failure. Cables, switches and routers need at least two routes;


• Sufficient network bandwidth (capacity) to handle laboratory data. Are your files 50kB CDS files or 1GB high-resolution NMR files? Tis needs to be designed into the network;


• Computer hardware, especially servers and data storage devices, must be resilient and fault tolerant: dual power supplies, dual network and redundant disk storage;


• Power backup in case of breaks in electrical supplies, not only in the computer room, but the communication cupboards for switches and routers to prevent loss of data in transit;


• Backup and recovery systems to ensure data are not lost.


An overview of laboratory informatics


Te broad relationships that exist in laboratory computing are represented in Figure 2. Although the exact terminology may vary from organisation to organisation, generally speaking, research and/or development programmes generate projects or studies. Tese generate experiments, which generate measurements, which in turn generate data. Te triangle represents the different layers of abstraction that exist in R&D information flows. Tese are almost always handled by different systems. Above the experimental layer is the


‘management’ context that is handled by traditional IT tools used elsewhere in the enterprise. Cross discipline collaboration tends to happen around the experiment layer. Below that is an increasing specialisation of data types and tools where only a few systems are deployed across workgroups. Te lower three layers in the diagram


represent the broad scope of laboratory informatics, embracing laboratory instrument systems, scientific data management systems (SDMS), laboratory execution systems (LES), laboratory information management systems (LIMS) and electronic laboratory notebooks (ELN). Overall, there has been a trend towards


convergence in the informatics market place. Te consequence of convergence is somewhat confusing for potential customers since the term ELN is used in a very liberal sense. In fact, it is inherently ambiguous since the ‘electronic notebook’ is always expected to do far more than the ‘paper notebook’ and the additional functionality will be dependent on the type of laboratory in which it is deployed. Most of the confusion is related to the analytical and QA market segments where the differences between ELNs, LIMS and SDMS are becoming less clear. Te following identifies the core differences: ELN: Experiment-centric. An authoring


tool that handles unstructured data and offers generic and specific functionality to support different scientific disciplines. Supports IP protection, knowledge re-use, productivity and collaboration. LES: Procedure or experiment-centric. Basically able to handle structured data


Fig. 2: Information Structure


Programmes Document Management


Projects


Project Management Experiments


Laboratory Notebook


Interpreted/Processed Data SDM/LIMS


Raw Data Laboratory Instrumentation


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36