For work, I am supposed to be an 'Instrument Service Specialist'. So following my job description, I should fix robotic systems, give support, training and other such things. In reality, I seem to spend all my awake hours witing applications to bridge the sadly lacking void between Laboratory Management Systems and Instrumentation. In particular, making it possible to set up complicated multiple assays in the field of direct nucleic acid testing in a user friendly way. In the last two years, I have finished projects for forensic science, pharmaceuticals, bird flu, and the most complicated, for a Health Protection Laboratory.
An automated laboratory process is only as good as its ease of use.
In this day and age, the system should not only carry out the physical tasks but should also control the complicated data management. In many cases this may be so, but in the field of direct nucleic assay testing this is sadly lacking. The difficulty is in the complexity of setting up multiple assays for increasing numbers of samples and tracking results throughout. How will the user run the system? Do they spend hours typing in data and plate layouts for 96 or 384 well plates or is the system automated to require just a few decisions?
Click here to see a simplification my last 6 months work.
In truth it is a complete management system, where most processes have there own set of two to three complicated flow diagrams. The plate layout utility with the associated process saves time spent on selecting well positions at runtime and developing a new protocol for each layout is no longer necessary.
So if an organisation has LIMS (Laboratory Information Management System) or consults with a company providing their system, why is it necessary to develop a second mini-management system to complement this? The main reason is the grey area of the plate layout for complicated assays. Should the responsibility for the plate layout be in LIMS, user or instrument process? In my opinion, this should ideally be with LIMS; and this is born out by the necessity to compliment the instrument software with external scripts or macros. It is time for it to be incorporated into the correct part of the process which should be LIMS.
Looks easy enough; but what about multiple assays on one plate, number of samples, which sample is where and with what assay? All needed for the real time instrument to return to LIMS. The liquid handler can import, track and export this information, but the software is not generally efficient enough or designed for programming complicated functions.
It is essential for all those involved with developing the complete process to make it as easy as possible. This would normally include lab managers, LIMS developers and the application specialist for the main instruments. If the system is difficult to use or not user friendly this will lead to more support/service calls and a difficult customer relationship. In the worse case, after time, the instrument will be put aside for an alternative solution. Either way, this is not an acceptable outcome for customer or supplier. During my visits to laboratories over the years, I have seen many robotic systems collecting dust, seen people leave organisations due to a perceived error of judgement in buying a system, and even seen suppliers removing a competitors system to replace them with their own. In most of the cases I would suggest that it was because the system was not set up for the users needs. It has become apparent that even if the needs of the laboratories have been explained, the amount of work involved in developing the system is to great.
After ten years of supporting robotic systems, and more so in the last five years spen integrating data tracking with LIMS, I am of the opinion that successful integrations are dependent on at least one person having a good understanding of how the user will use the system from sample to result. The unfortunate thing is that those involved with the initial discussions do not have the technical knowledge or experience to cover the potential of a system; or they do not comprehend the how much work involved. The latter, from personal experience leads to the poor applications specialist spending excessive hours developing the system. If this type of functionality was incorporated into the management system, setting up the whole process would be so much easier.