I see plenty of articles and webinars with helpful advice on acquiring the ideal laboratory instrument, LIMS, robot etc. The clear majority of these are published by vendors. Therefore, such articles tend to have a slant that emphasises their own products strengths and gloss over or ignore the weaknesses whilst totally ignoring alternative options from other vendors. Firstly, I am not against this. Companies have marketing challenges and a good 'how to' article is a great way to get a message out. As I go on with this article I might name drop some companies or products. This does not imply any association on my part with any companies mentioned and no promotion fees are being received.
Understanding what you mean regarding automation
The term 'automation' covers a vast array of opportunities to:
and all the benefits that are recognised by automation implementation.
What is important is to have a clear mindset on what process or processes you want to automate. This should be data driven (Process analysis) and based upon real data. By real data I mean the direct testimony and metrics from the people performing the tasks.... not, I repeat NOT! A lone managers opinion of how a process is carried out. You have been warned, this is the very first point that causes problems in automation acquisition. It is essential to getting the correct system and getting user buy in.
Automation can be many things:
The step from a cuvette reader to a microplate reader for example.
Acquiring a bulk reagent dispenser (Thermo, Fritz Gyger, Formulatrix etc) to speed up and remove repetitive pipetting tasks.
Adding stacking systems to individual instruments to remove the need for manual feed.
Larger liquid handling workstations (Agilent, Tecan, Hamilton etc) for complex liquid handling.
Integrated systems coupling liquid handling, reagent dispensing and signal detection (HighRes, PAA, Brooks Life sciences, Labman etc.)
Informatics, automated data capture and processing, barcode tracking.
Automated sample storage and retrieval
From a small instrument implementation to large scale bespoke integrations.
Understanding resource capabilities
When making the first steps in Lab automation it is important that you analyse the skill set of your group. Do you have a 'tech savvy' member who can take a project on? Project management and delivery of an acquisition/implementation can be a very involved process when done properly. Consider losing at least 0.3 - 0.5 of an FTE to this process. Prioritisation is key. Remember that incorrect prioritisation can have drastic & long-term impacts upon the whole operation if it leads to mistakes. Not to mention a large capital outlay. If you are struggling to find a team member that fits the bill you can reach out to organisations such as the Automated Laboratory Network (or your friendly neighbourhood automation consultant). Plenty of suppliers offer scoping however not many will scope anything beyond the design and delivery of their own systems.
Scoping the solution and the dreaded URS! (User requirements specification)
This is often the hardest part of the process. Describing the solution. Once you have a machine that performs a task normally performed by a human it is important to review (in detail) the exact process that the human does. For example, pay attention to the little idiosyncrasies that lab operatives have (a tap down of a microplate here and there. Swirling a reagent bottle periodically. If ignored, these steps can be the difference between success and failure of an assay on automation.
Investigate the timings for process steps. Most automation systems are not faster than an individual user. A single robot arm installation, despite the cost still has one less arm than nearly all scientists. Imagine running your experiments using only one hand to get a feel for potential throughput limitations.
Also consider reagent storage and stability. A stacking system can run for hours, but can the reagent/assay stability support that length of time?
Challenge dogma - this can be difficult as scientist can almost become superstitious regarding their processes (Assay must be done on a Tuesday, cells grow better if you sing to them, that sort of thing). If a requirement seems over the top, perform a test.
A good URS does not need pages and pages of company description, background and context. Most suppliers will scan that at best. What is most important is:
A description of the problem/opportunity
Glossary of terms - to ensure that you are all using the correct interpretations of acronyms and requirements
Detailed description of the requirements
Process maps - Physical and data
A prioritised list of physical and data deliverables
A prioritised set of acceptance criteria
Fully understand the differences between Critical (Needs) versus Optional (Wants) versus Optimistic (nice to haves). Suppliers operating to a budget will always be faced with a balancing act as budgets are often under pressure. The more insight you can give to suppliers, the more harmonious and successful the project.
Remember that even if you are just considering buying an instrument there are often multiple vendors who can supply a solution. A good URS will help you to narrow down your choice of vendor. When analysed against a URS your original view of which product is best can often change. Also you can sometimes determine why a more costly solution gives you more of the nice to haves.
Also, at this point ensure that scoping time is spent upon enabling activities, lab design, adjacencies and material flow. These can be costly but not fall in the remit of an automation vendor to remedy. Take the time to liaise with building/facilities managers. Automation takes up space and extensive lab modifications are often needed these can be:
Removal of benching
Moving other lab systems
Space for bulk plasticware storage
Lay down areas for associated processes (Plate loading, reagent prep, Unloading)
Addition of extra services (Water supply, Purified water, Data coms, Gasses, Compressed Air etc.)
Delivery routes for the system during on site build.
Also consider the existing lab processes that will not go on the automation. Are they affected?
As soon as a machine starts doing a person’s job a whole new raft of safety measures come in. CE standards and international safety standards are not always a given. Consider guarding and always ask for declarations of conformity. Also note that increases in throughput leads to increases in reagent volumes and waste so a review of COSHH assessments is essential. If in the UK, ensure that a PUWER assessment is carried out post-delivery. Once handed over ensure that a thorough risk assessment is also required. If your company has a health and safety adviser I would recommend that they sit on the project team.
Functional Specification (bespoke systems)
Vendors respond to a URS with a functional specification or sometimes called and SDS (System/Software design specification). The functional specification (FS/SDS) defines precisely what will be delivered by the vendor and it incumbent upon the customer to review this for compliance with the requirements laid out in the URS. If signed off the FS represents the contractual deliverables by the vendor. If requirements are changed post sign off this can represent a change in scope and will add to the project costs. Expect your negotiation skills to be pushed during this time and rigour during this stage of the project is essential in both getting exactly what you want and keeping costs on track.
This can be a quiet time for a customer and a mad time for a vendor. Avoid over reporting (vendor) and requesting too many progress updates (customer). Build timelines are normally quite precise with systems but issues can arise. A good vendor will notify you of issues in good time. I would suggest a weekly update and at least 1 site visit prior to the acceptance testing as getting an understanding of how a system is built can give good insight into its utilisation, maintenance and aid in future trouble shooting.
Acceptance Testing (bespoke systems)
There are two stages to acceptance testing in bespoke automation systems. Factory acceptance and Site acceptance. The factory acceptance stage is mostly to fundamentally confirm that the system meets the requirements laid out in the FS/SDS....not the URS as the URS is superseded by the FS/SDS at this point. If you spot issues relating to URS compliance during the SAT, then you are relying upon the vendors generosity to resolve or be prepared to spend more. The factory acceptance test (FAT) generally focusses on physical and data handling processes without using biological or biochemical reagents. This is primarily due to limitations in chemical handling facilities in engineering areas. If liquid handling is fundamental to the process, consider simple dye/gravimetric testing rather than more complex methodologies. Remember that an integrator is not liable for the quality of output of the instruments integrated unless failures can be directly attributed to the integration. If free-issuing instruments for integration, ensure that quality testing has been done before supplying to ensure that performance has been baselined. Expect one and possibly two FAT visits and remember the more complex the system, the longer the FAT. Sometimes a pre-FAT visit can remove the need for more than one. Ensure that a reliability stress test is at least one of the tests. Some can be performed before the formal FAT with confirmation carried out at FAT as a good system will contain logs that can be reviewed.
After delivery a SAT should be carried out to confirm that the system has been delivered and constructed correctly. A SAT is usually a repeat of the FAT but additional tests can be agreed to test functions that could not be tested at the workshop, an example of which is Data handling, which can be tested in connection with site systems rather than emulated environments so this can be challenging if not scoped accurately.
Documentation for the FAT and SAT is produced by the vendor although it is incumbent on the customer to review and ensure that the testing methods prove the testable statements in the FS/SDS.
Upon completion of the SAT the system is finally considered delivered and is handed over to the customer.
After reviewing the skills of your staff ensure that the automation has an 'owner' or responsible person. Ideally this is someone tech savvy who is close to the action and has been part of the project from its conception. This helps ensure that the owner is invested in its delivery and success. If there is reluctance to champion the system, then there is a danger it could become underutilised and under supported. Ensure that user training is accompanied by expert user training (for the owner) including fault diagnosis. This is an excellent development opportunity for a lab user but should not be considered a role that can be done 'in their spare time'. Dedicate at least 20% of their time for this role in the short term (1st year). Assays and processes run manually can require some modification when placed on automation. Usually because the acquisition of automation goes hand in glove with an increase in capacity. Therefore, consider reagent storage, stability, change in the fluid path for reagents (peristaltic pump vs pipette tip). These factors require support from the 'owner' to new users and processes coming to the system and can lead to negative opinions of the system and lower user buy-in. Early adopters of any new system go through a lot of effort validating a system and in regulated environments an OQ (Operational Qualification) process is often required that governs validation, training and roll out.
Following this guide will not guarantee success but hopefully will help avoid a few pitfalls. If you require more detailed help and support in your project, you are welcome to contact me via the contacts page.