My experience is automation in the field of nucleic acid purification and reaction set-up for direct DNA and RNA analysis. However, I see no reason why similar algorithms cannot be applied to other applications requiring complex data manipulation. In the past, it would have been more economical to avoid designing complex protocols for liquid handling, but trends towards using PCR, (Polymerase Chain Reaction) for diagnosis and identification have made it a necessity. My projects include work for forensic science, drug discovery, diagnostics in Health Protection Laboratories, bird flu and foot'n'mouth.
The diagram shows a typical workflow for a system which would isolate nucleic acid from specimens, provide liquid handling and return assay results to LIMS. The grey area is the reason for labour intensive customisation which soon becomes out-dated and then too costly to upgrade in the future, (unless, of course, a simple solution is provided which is labour intensive at runtime). After eight years of providing the same thing; during these past two years I have been developing a standardised approach with a second level of flexibility. This second level provides a utility for creating templates of varying degrees of complexity, allowing for assays to be added without costly re-programming.
After extensive discussions with my French colleagues, I must withdraw my belief that this second level should be programmed in LIMS. It was pointed out to me that a system, such as one for a national health service, would only be concerned with personal data relevant to the patient and not information required to run an instrument; and I have to agree. On the other hand, I still stand by my belief that this second level does not belong in the liquid handling software, as many different liquid handling systems may well benefit from this second level of programming. Essentially, this is a tool which allows design of a PCR based method specific to a particular laboratory to be transported to automation. In which case, this is an add-on which could be carried by companies providing Laboratory Information Management Systems, or a separate module supplied directly as an integration tool. To include it in any one liquid handling system would be a particular waste of the time taken to develop it.
When working with a project, my aim is to eliminate any data entry during runtime, supply graphics for ease of use, and minimize user interactions. Ultimately, try to develop a system which does not require complicated training, and eliminate potential errors. Generally, an instrument will have specific software for operation, hopefully with some possibility of importing and exporting data. Fortunately, I work with a system that supports external applications and 'plug-ins', so it is possible to compliment the software for data transfer and sometimes instrument control. There are also scheduling packages available which are designed for instrument control. Overlord is an example of this, and can be used to seamlessly automate a complete process, controlling each integrated instrument and all data transfer. Details can be found at: PAA Ltd. (Process Automation & Analysis). Such a company may well customise a process to the same level of flexibility and may already have modules which would do the same thing.
This is a personal website, and as an employee with my company am not able to promote by name, or identify myself with them by name under guidelines given for official marketing activities. Also, I will not be able to provide details of projects undertaken with them.