{"ID":96683,"post_author":"9412100","post_date":"2021-04-29 15:40:49","post_date_gmt":"0000-00-00 00:00:00","post_content":"","post_title":"LIMSjournal - Spring 2021","post_excerpt":"","post_status":"draft","comment_status":"closed","ping_status":"closed","post_password":"","post_name":"","to_ping":"","pinged":"","post_modified":"2021-04-29 15:40:49","post_modified_gmt":"2021-04-29 19:40:49","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.limsforum.com\/?post_type=ebook&p=96683","menu_order":0,"post_type":"ebook","post_mime_type":"","comment_count":"0","filter":"","_ebook_metadata":{"enabled":"on","private":"0","guid":"766BF62D-0C62-4CB6-B9AB-37C5BB29F7B1","title":"LIMSjournal - Spring 2021","subtitle":"Volume 7, Issue 1","cover_theme":"nico_7","cover_image":"https:\/\/www.limsforum.com\/wp-content\/plugins\/rdp-ebook-builder\/pl\/cover.php?cover_style=nico_7&subtitle=Volume+7%2C+Issue+1&editor=Shawn+Douglas&title=LIMSjournal+-+Spring+2021&title_image=https%3A%2F%2Fs3.limsforum.com%2Fwww.limsforum.com%2Fwp-content%2Fuploads%2FFig8_Liscouski_LabTechPlanMan20.png&publisher=LabLynx+Press","editor":"Shawn Douglas","publisher":"LabLynx Press","author_id":"26","image_url":"","items":{"e0147011cc1eb892e1a35e821657a6d9_type":"article","e0147011cc1eb892e1a35e821657a6d9_title":"Considerations in the automation of laboratory procedures (Liscouski 2021)","e0147011cc1eb892e1a35e821657a6d9_url":"https:\/\/www.limswiki.org\/index.php\/LII:Considerations_in_the_Automation_of_Laboratory_Procedures","e0147011cc1eb892e1a35e821657a6d9_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Considerations in the Automation of Laboratory Procedures\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\tTitle: Considerations in the Automation of Laboratory Procedures\nAuthor for citation: Joe Liscouski, with editorial modifications by Shawn Douglas\nLicense for content: Creative Commons Attribution 4.0 International\nPublication date: January 2021\n\nContents\n\n1 Introduction \n2 How does this discussion relate to previous work? \n\n2.1 Before we get too far into this... \n\n\n3 Transitioning from typical lab operations to automated systems \n\n3.1 What will happen to people\u2019s jobs as a result of automation? \n3.2 What is the role of AI and ML in automation? \n3.3 Where do we find the resources to carry out automation projects\/programs? \n3.4 What equipment would we need for automated processes, and will it be different that what we currently have? \n3.5 What role does a LES play in laboratory automation? \n\n3.5.1 What does this have to do with automation? \n\n\n3.6 How do we go about planning for automation? \n\n3.6.1 Justification, expectations, and goals \n3.6.2 Analyzing the process \n3.6.3 Scheduling automation projects \n3.6.4 Budgeting \n\n\n\n\n4 Build, buy, or cooperate? \n5 Project planning \n6 Conclusions (so far) \n7 Abbreviations, acronyms, and initialisms \n8 Footnotes \n9 About the author \n10 References \n\n\n\nIntroduction \nScientists have been dealing with the issue of laboratory automation for decades, and during that time the meaning of those words has expanded from the basics of connecting an instrument to a computer, to the possibility of a fully integrated informatics infrastructure beginning with sample preparation and continuing on to the laboratory information management system (LIMS), electronic laboratory notebook (ELN), and beyond. Throughout this evolution there has been one underlying concern: how do we go about doing this?\nThe answer to that question has changed from a focus on hardware and programming, to today\u2019s need for a lab-wide informatics strategy. We\u2019ve moved from the bits and bytes of assembly language programming to managing terabytes of files and data structures.\nThe high-end of the problem\u2014the large informatics database systems\u2014has received significant industry-wide attention in the last decade. The stuff on the lab bench, while the target of a lot of individual products, has been less organized and more experimental. Failed or incompletely met promises have to yield to planned successes. How we do it needs to change. This document is about the considerations required when making that change. The haphazard \"let's try this\" method has to give way to more engineered solutions and a realistic appraisal of the human issues, as well as the underlying technology management and planning.\nWhy is this important? Whether you are conducting intense laboratory experiments to produce data and information or making chocolate chip cookies in the kitchen, two things remain important: productivity and the quality of the products. In either case, if the productivity isn\u2019t high enough, you won\u2019t be able to justify your work; if the quality isn\u2019t there, no one will want what you produce. Conducting laboratory work and making cookies have a lot in common. Your laboratories exist to answer questions. What happens if I do this? What is the purity of this material? What is the structure of this compound? The field of laboratories asking these questions is extensive, basically covering the entire array of lab bench and scientific work, including chemistry, life sciences, physics, and electronics labs. The more efficiently we answer those questions, the more likely it will be that these labs will continue operating and, that you\u2019ll achieve the goals your organization has set. At some point, it comes down to performance against goals and the return on the investment organizations make in lab operations.\nIn addition to product quality and productivity, there are a number of other points that favor automation over manual implementations of lab processes. They include:\n\n lower costs per test;\n better control over expenditures;\n a stronger basis for better workflow planning;\n reproducibility;\n predictably; and\n tighter adherence to procedures, i.e., consistency.\nLists similar to the one above can be found in justifications for lab automation, and cookie production, without further comment. It\u2019s just assumed that everyone agrees and that the reasoning is obvious. Since we are going to use those items to justify the cost and effort that goes into automation, we should take a closer look at them.\nLets begin with reproducibility, predictability, and consistency, very similar concerns that reflect automation\u2019s ability to produce the same product with the desired characteristics over and over. For data and information, that means that the same analysis on the same materials will yield the same results, that all the steps are documented and that the process is under control. The variability that creeps into the execution of a process by people is eliminated. That variability in human labor can result from the quality of training, equipment setup and calibration, readings from analog devices (e.g., meters, pipette meniscus, charts, etc.), there is a long list of potential issues.\nConcerns with reproducibility, predictability, and consistency are common to production environments, general lab work, manufacturing, and even food service. There are several pizza restaurants in our area using one of two methods of making the pies. Both start the preparation the same way, spreading dough and adding cheese and toppings, but the differences are in how they are cooked. Once method uses standard ovens (e.g., gas, wood, or electric heating); the pizza goes in, the cook watches it, and then removes it when the cooking is completed. This leads to a lot of variability in the product, some a function of the cook\u2019s attention, some depending on requests for over or under cooking the crust. Some is based on \"have it your way\" customization. The second method uses a metal conveyor belt to move the pie through an oven. The oven temperature is set as is the speed of the belt, and as long as the settings are the same, you get a reproducible, consistent product order after order. It\u2019s a matter of priorities. Manual verses automated. Consistent product quality verses how the cook feels that day. In the end, reducing variability and being able to demonstrate consistent, accurate, results gives people confidence in your product.\nLower costs per test, better control over expenditures, and better workflow planning also benefit from automation. Automated processes are more cost-efficient since the sample throughput is higher and the labor cost is reduced. The cost per test and the material usage is predictable since variability in components used in testing is reduced or eliminated, and workflow planning is improved since the time per test is known, work can be better scheduled. Additionally, process scale-up should be easier if there is a high demand for particular procedures. However there is a lot of work that has to be considered before automation is realizable, and that is where this discussion is headed.\n\nHow does this discussion relate to previous work? \nThis work follows on the heels of two previous works:\n\n Computerized Systems in the Modern Laboratory: A Practical Guide (2015): This book presents the range of informatics technologies, their relationship to each other, and the role they play in laboratory work. It differentiates a LIMS from an ELN and scientific data management system (SDMS) for example, contrasting their use and how they would function in different lab working environments. In addition, it covers topics such as support and regulatory issues.\n A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work (2018): This webinar series complements the above text. It begins by introducing the major topics in informatics (e.g., LIMS, ELN, etc.) and then discusses their use from a strategic viewpoint. Where and how do you start planning? What is your return on investment? What should get implemented first, and then what are my options? The series then moves on to developing an information management strategy for the lab, taking into account budgets, support, ease of implementation, and the nature of your lab\u2019s work.\nThe material in this write-up picks up where the last part of the webinar series ends. The last session covers lab processes, amd this picks up that thread and goes into more depth concerning a basic issue: how do you move from manual methods to automated systems?\nProductivity has always been an issue in laboratory work. Until the 1950s, a lab had little choice but to add more people if more work needed to be done. Since then, new technologies have afforded wider options, including new instrument technologies. The execution of the work was still done by people, but the tools were better. Now we have other options. We just have to figure out when, if, and how to use them.\n\nBefore we get too far into this... \nWith elements such as productivity, return on investment (ROI), data quality, and data integrity as driving factors in this work, you shouldn\u2019t be surprised if a lot of the material reads like a discussion of manufacturing methodologies; we\u2019ve already seen some examples. We are talking about scientific work, but the same things that drive the elements noted in labs have very close parallels in product manufacturing. The work we are describing here will be referenced as \"scientific manufacturing,\" manufacturing or production in support of scientific programs.[a]\nThe key points of a productivity conversation in both lab and material production environments are almost exact overlays, the only significant difference is that the results of the efforts are data and information in one case, and a physical item you might sell in the other. Product quality and integrity are valued considerations in both. For scientists, this may require an adjustment to their perspectives when dealing with automation. On the plus side, the lessons learned in product manufacturing can be applied to lab bench work, making the path to implementation a bit easier while providing a framework for understanding what a successful automation effort looks like. People with backgrounds in product manufacturing can be a useful resource in the lab, with a bit of an adjustment in perspective on their part.\n\nTransitioning from typical lab operations to automated systems \nTransitioning a lab from its current state of operations to one that incorporates automation can raise a number of questions, and people\u2019s anxiety levels. There are several questions that should be considered to set expectations for automated systems and how they will impact jobs and the introduction of new technologies. They include:\n\n What will happen to people\u2019s jobs as a result of automation?\n What is the role of artificial intelligence (AI) and machine learning (ML) in automation?\n Where do we find the resources to carry out automation projects\/programs?\n What equipment would we need for automated processes, and will it be different that what we currently have?\n What role does a laboratory execution system (LES) play in laboratory automation?\n How do we go about planning for automation?\nWhat will happen to people\u2019s jobs as a result of automation? \nStories are appearing in print, online, and in television news reporting about the potential for automation to replace human effort in the labor force. It seems like it is an all-or-none situation, either people will continue working in their occupations or automation (e.g., mechanical, software, AI, etc.) will replace them. The storyline is people are expensive and automated work can be less costly in the long run. If commercial manufacturing is a guide, automation is a preferred option from both a productivity and an ROI perspective. In order to make the productivity gains from automation similar to those seen in commercial manufacturing, there are some basic requirements and conditions that have to be met:\n\n The process has to be well documented and understood, down to the execution of each step without variation, while error detection and recovery have to be designed in.\n The process has to remain static and be expected to continue over enough execution cycles to make it economically attractive to design, build, and maintain.\n Automation-compatible equipment has to be available. Custom-built components are going to be expensive and could represent a barrier to successful implementation.\n There has to be a driving need to justify the cost of automation; economics, the volume of work that has to be addressed, working with hazardous materials, and lack of educated workers are just a few of the factors that would need to be considered.\nThere are places in laboratory work where production-scale automation has been successfully implemented; life sciences applications for processes based on microplate technologies are one example. When we look at the broad scope of lab work across disciplines, most lab processes don\u2019t lend themselves to that level of automation, at least not yet. We\u2019ll get into this in more detail later. But that brings us back to the starting point: what happens to people's jobs?\nIn the early stages of manufacturing automation, as well as fields such as mining where work was labor intensive and repetitive, people did lose jobs when new methods of production were introduced. That shift from a human workforce to automated task execution is expanding as system designers probe markets from retail to transportation.[1] Lower skilled occupations gave way first, and we find ourselves facing automation efforts that are moving up the skills ladder, most recently is the potential for automated driving, a technology that has yet to be fully embraced but is moving in that direction. The problem that leaves us with is providing displaced workers with a means of employment that gives them at least a living income, and the purpose, dignity, and self-worth that they\u2019d like to have. This is going to require significant education, and people are going to have to come to grips with the realization that education never stops.\nDue to the push for increased productivity, lab work has seen some similar developments in automation. The development of automated pipettes, titration stations, auto-injectors, computer-assisted instrumentation, and automation built to support microplate technologies represent just a few places where specific tasks have been addressed. However these developments haven\u2019t moved people out of the workplace as has happened in manufacturing, mining, etc. In some cases they\u2019ve changed the work, replacing repetitive time-consuming tasks with equipment that allows lab personnel to take on different tasks. In other cases the technology addresses work that couldn\u2019t be performed in a cost-effective manner with human effort; without automation, that work might just not be feasible due to the volume of work (whose delivery might be limited by the availability of the right people, equipment, and facilities) or the need to work with hazardous materials. Automation may prevent the need for hiring new people while giving those currently working more challenging tasks.\nAs noted in the previous paragraph, much of the automation in lab work is at the task level: equipment designed to carry out a specific function such as Karl-Fisher titrations. Some equipment designed around microplate formats can function at both the task level and as part of user-integrated robotics system. This gives the planner useful options about the introduction of automation that makes it easier for personnel to get accustomed to automation before moving into scientific manufacturing.\nOverall, laboratory people shouldn\u2019t be loosing their jobs as a result of lab automation, but they do have to be open to changes in their jobs, and that could require an investment in their education. Take someone whose current job is to carry out a lab procedure, someone who understands all aspects of the work, including troubleshooting equipment, reagents, and any special problems that may crop up. Someone else may have developed the procedure, but that person is the expert in its execution.\nFirst of all you need these experts to help plan and test the automated systems if you decide to create that project. These would also be the best people to educate as automated systems managers; they know how the process is supposed to work and should be in a position to detect problems. If it crashes, you\u2019ll need someone who can cover the work while problems are be addressed. Secondly, if lab personnel get the idea that they are watching their replacement being installed, they may leave before the automated systems are ready. In the event of a delay, you\u2019ll have a backlog and no one to handle it.\nBeyond that, people will be freed from the routine of carrying out processes and be able to address work that had been put on a back burner until it could be addressed. As we move toward automated systems, jobs will change by expansion to accommodate typical lab work, as well as the management, planning, maintenance, and evolution of laboratory automation and computing.\nAutomation in lab work is not an \"all or none\" situation. Processes can be structured so that the routine work is done by systems, and the analyst can spend time reviewing the results, looking for anomalies and interesting patterns, while being able to make decisions about the need for and nature of follow-on efforts.\n\nWhat is the role of AI and ML in automation? \nWhen we discuss automation, what we are referencing now is basic robotics and programming. AI may, and likely will, play a role in the work, but first we have to get the foundations right before we consider the next step; we need to put in the human intelligence first. Part of the issue with AI is that we don\u2019t know what it is.\nScience fiction aside, many of today's applications of AI have a limited role in lab work today. Here are some examples:\n\n Having a system that can bring up all relevant information on a research question\u2014a sort of super Google\u2014or a variation of IBM\u2019s Watson could have significant benefits.\n Analyzing complex data or large volumes of data could be beneficial, e.g., the analysis of radio astronomy data to find fast radio bursts (FRB). After discovering 21 FRB signals upon analyzing five hours of data, researchers at Green Bank Telescope used AI to analyze 400 terabytes of older data and detected another 100.[2]\n \"[A] team at Glasgow University has paired a machine-learning system with a robot that can run and analyze its own chemical reaction. The result is a system that can figure out every reaction that's possible from a given set of starting materials.\"[3]\n HelixAI is using Amazon's Alexa as a digital assitant for laboratory work.[4]\nNote that the points above are research-based applications, not routine production environments where regulatory issues are important. While there are research applications that might be more forgiving of AI systems because the results are evaluated by human intelligence, and problematic results can be made subject to further verification, data entry systems such as voice entry have to be carefully tested and the results of that data entry verified and shown to be correct.\nPharma IQ continues to publish material on advanced topics in laboratory informatics, including articles on how labs are benefiting from new technologies[5] and survey reports such as AI 2020: The Future of Drug Discovery. In that report they note[6]:\n\n \"94% of pharma professionals expect that intelligent technologies will have a noticeable impact on the pharmaceutical industry over the next two years.\"\n \"Almost one fifth of pharma professionals believe that we are on the cusp of a revolution.\"\n \"Intelligent automation and predictive analytics are expected to have the most significant impact on the industry.\"\n \"However, a lack of understanding and awareness about the benefits of AI-led technologies remain a hindrance to their implementation.\"\nNote that these are expectations, not a reflection of current reality. That same report makes comments about the impact of AI on headcount disruption, asking, \"Do you expect intelligent enterprise technologies[b] to significantly cut and\/or create jobs in pharma through 2020?\" Among the responses, 47 percent said they expected those technologies to do both, 40 percent said it will create new job opportunities, and 13 percent said there will be no dramatic change, with zero percent saying they expected solely job losses.[6]\nWhile there are high levels of expectations and hopes for results, we need to approach the idea of AI in labs with some caution. We read about examples based on machine learning (ML), for example using computer systems to recognize cats in photos, to recognized faces in a crowd, etc. We don\u2019t know how they accomplish their tasks, and we can\u2019t analyze their algorithms and decision-making. That leaves us with testing in quality, which at best is an uncertain process with qualified results (it has worked so far). One problem with testing AI systems based on ML is that they are going to continually evolve, so testing may affect the ML processes by providing a bias. It may also cause continued, redundant testing, because something we thought was evaluated was changed by the \u201cexperiences\u201d the AI based it\u2019s learning on. As one example, could the AI modify the science through process changes without our knowing because it didn\u2019t understand the science or the goals of the work?\nAI is a black box with ever-changing contents. That shouldn\u2019t be taken as a condemnation of AI in the lab, but rather as a challenge to human intelligence in evaluating, proving, and applying the technology. That application includes defining the operating boundaries of an AI system. Rather than creating a master AI for a complete process, we may elect to divide the AI\u2019s area of operation into multiple, independent segments, with segment integration occurring in later stages once we are confident in their ability to work and show clear evidence of systems stability. In all of this we need to remember that our goal is the production of high-quality data and information in a controlled, predictable environment, not gee-wiz technology. One place where AI (or clever programming) could be of use is in better workflow planning, which takes into account current workloads and assignments, factors in the inevitable panic-level testing need, and, perhaps in a QC\/production environment, anticipates changes in analysis requirements based on changes in production operations.\nThroughout this section I've treated \u201cAI\u201d as \u201cartificial intelligence,\u201d its common meaning. There may be a better way of looking at it for lab use as, noted in this excerpt from the October 2018 issue of Wired magazine[7]:\n\nAugmented intelligence. Not \u201cartificial,\u201d but how Doug Engelbart[c] envisioned our relationship with computer: AI doesn\u2019t replace humans. It offers idiot-savant assistants that enable us to become the best humans we can be.\nAugmented intelligence (AuI) is a better term for what we might experience in lab work, at least in the near future. It suggests something that is both more realistic and attainable, with the synergism that would make it, and automation, attractive to lab management and personnel\u2014a tool they can work with and improve lab operations that doesn\u2019t carry the specter of something going on that they don\u2019t understand or control. OPUS\/SEARCH from Bruker might be just such an entry in this category.[8] AuI may serve as a first-pass filter for large data sets\u2014as noted in the radio astronomy and chemistry examples noted earlier\u2014reducing those sets of data and information to smaller collections that human intelligence can\/should evaluate. However, that does put a burden on the AuI to avoid excessive false positives or negatives, something that can be adjusted over time.\nBeyond that there is the possibility of more cooperative work between people and AuI systems. An article in Scientific American titled \u201cMy Boss the Robot\u201d[9] describes the advantage of a human-robot team, with the robot doing the heavy work and the human\u2014under the robots guidance\u2014doing work he was more adept at, verses a team of experts with the same task. The task, welding a Humvee frame, was competed by the human machine pair in 10 hours at a cost of $1,150; the team of experts took 89 hours and a cost of $7,075. That might translate into terms of laboratory work by having a robot do routine, highly repetitive tasks and the analyst overseeing the operation and doing higher-level analysis of the results.\nCertainly, AI\/AuI is going to change over time as programming and software technology becomes more sophisticated and capable; today\u2019s example of AuI might be seen as tomorrow\u2019s clever software. However, a lot depends on the experience of the user.\nThere is something important to ask about laboratory technology development, and AI in particular: is the direction of development going to be the result of someone\u2019s innovation that people look at and embrace, or will it be the result of a deliberate choice of lab people saying \u201cthis is where we need to go, build systems that will get us there\u201d? The difference is important, and lab managers and personnel need to be in control of the planning and implementation of systems.\n\nWhere do we find the resources to carry out automation projects\/programs? \nGiven the potential scope of work, you may need people with skills in programming, robotics, instrumentation, and possibly mechanical or electrical engineering if off-the-shelf components aren\u2019t available. The biggest need is for people who can do the planning and optimization that is needed as you move from manual to semi- or fully-automated systems, particularly specialists in process engineering who can organize and plan the work, including the process controls and provision for statistical process control.\nWe need to develop people who are well versed in laboratory work and the technologies that can be applied to that work, as assets in laboratory automation development and planning. In the past, this role has been filled with lab personnel having an interest in the subject, IT people willing to extend their responsibilities, and\/or outside consultants. A 2017 report by Salesforce Research states \"77% of IT leaders believe IT functions as an extension\/partner of business units rather than as a separate function.\"[10] The report makes no mention of laboratory work or manufacturing aside from those being functions within businesses surveyed. Unless a particular effort is made, IT personnel rarely have the backgrounds needed to meet the needs of lab work. In many cases, they will try and fit lab needs into software they are already familiar with, rather then extend their backgrounds into new computational environments. Office and pure database applications are easily handled, but when we get to the lab bench, it's another matter entirely.\nThe field is getting complex enough that we need people whose responsibilities span both science and technology. This subject is discussed in the webinar series A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work, Part 5 \"Supporting Laboratory Systems.\"\n\nWhat equipment would we need for automated processes, and will it be different that what we currently have? \nThis is an interesting issue and it directly addresses the commitment labs have to automation, particularly robotics. In the early days of lab automation when Zymark (Zymate and Benchmate), Perkin Elmer, and Hewlett Packard (ORCA) were the major players in the market, the robot had to adapt to equipment that was designed for human use: standard laboratory equipment. They did that through special modifications and the use of different grippers to handle test tubes, beakers, and flasks. While some companies wanted to test the use of robotics in the lab, they didn\u2019t want to invest in equipment that could only be used with robots; they wanted lab workers to pick up where the robots left off in case the robots didn\u2019t work.\nSince then, equipment has evolved to support automation more directly. In some cases it is a device (e.g., a balance, pH meter, etc.) that has front panel human operator capability and rear connectors for computer communications. Liquid handling systems have seen the most advancement through the adoption of microplate formats and equipment designed to work with them. However, the key point is standardization of the sample containers. Vials and microplates lend themselves to a variety of automation devices, from sample processing to auto-injectors\/samplers. The issue is getting the samples into those formats.\nOne point that labs, in any scientific discipline, have to come to grips with is the commitment to automation. That commitment isn\u2019t going to be done on a lab-wide basis, but on a procedure-by-procedure basis. Full automation may not be appropriate for all lab work, whereas partial automation may be a better choice, and in some cases no automation may be required (we\u2019ll get into that later). The point that needs to be addressed is the choice of equipment. In most cases, equipment is designed for use by people, with options for automation and electronic communications. However, if you want to maximize throughput, you may have to follow examples from manufacturing and commit to equipment that is only used by automation. That will mean a redesign of the equipment, a shared risk for both the vendors and the users. The upside to this is that equipment can be specifically designed for a task, be more efficient, have the links needed for integration, use less material, and, more likely, take up less space. One example is the microplate, allowing for tens, hundreds, or thousands (depending on the plate used) of sample cells in a small space. What used to take many cubic feet of space as test tubes (the precursor to using microplates) is now a couple of cubic inches, using much less material and working space. Note, however, that while microplates are used by lab personnel, their use in automated systems provides greater efficiency and productivity.\nThe idea of equipment used only in an automated process isn\u2019t new. The development and commercialization of segmented flow analyzers\u2014initially by Technicon in the form of the AutoAnalyzers for general use, and the SMA (Sequential Multiple Analyzer) and SMAC (Sequential Multiple Analyzer with Computer) in clinical markets\u2014improved a lab's ability to process samples. These systems were phased out with new equipment that consumed less material. Products like these are being provided by Seal Analytical[11] for environmental work and Bran+Luebbe (a division of SPX Process Equipment in Germany).[12]\nThe issue in committing to automated equipment is that vendors and users will have to agree on equipment specifications and use them within procedures. One place this has been done successfully is in clinical chemistry labs. What other industry workflows could benefit? Do the vendors lead or do the users drive the issue? Vendors need to be convinced that there is a viable market for product before making an investment, and users need to be equally convinced that they will succeed in applying those products. In short, procedures that are important to a particular industry have to be identified, and both users and vendors have to come together to develop automated procedure and equipment specifications for products. This has been done successfully in clinical chemistry markets to the extent that equipment is marketed for use as validated for particular procedures.\n\nWhat role does a LES play in laboratory automation? \nBefore ELNs settled into their current role in laboratory work, the initial implementations differed considerably from what we have now. LabTech Notebook was released in 1986 (discontinued in 2004) to provide communications between computers and devices that used RS-232 serial communications. In the early 2000s SmartLab from Velquest was the first commercial product to carry the \"electronic laboratory notebook\" identifier. That product became a stand-alone entry in the laboratory execution system (LES) market; since its release, the same conceptual functionality has been incorporated into LIMS and ELNs that fit the more current expectation for an ELN.\nAt it\u2019s core, LES are scripted test procedures that an analyst would follow to carry out a laboratory method, essentially functioning as the programmed execution of a lab process. Each step in a process is described, followed exactly, and provision is made within the script for data collection. In addition, the LES can\/will (depending on the implementation; \"can\" in the case of SmartLab) check to see if the analyst is qualified to carry out the work and that the equipment and reagents are current, calibrated, and suitable for use. The systems can also have access to help files that an analyst can reference if there are questions about how to carry out a step or resolve issues. Beyond that, the software had the ability to work with lab instruments and automatically acquire data either through direct interfaces (e.g., balances, pH meters, etc.) or through parsing PDF files of instrument reports.\nThere are two reasons that these systems are attractive. First, they provide for a rigorous execution of a process with each step being logged as it is done. Second, that log provides a regulatory inspector with documented evidence that the work was done properly, making it easier for the lab to meet any regulatory burden.\nSince the initial development of SmartLab, that product has changed ownership and is currently in the hands of Dassault Syst\u00e8mes as part of the BIOVIA product line. As noted above, LIMS and ELN vendors have incorporated similar functionality into their products. Using those features requires \u201cscripting\u201d (in reality, software development), but it does allow the ability to access the database structures within those products. The SmartLab software needed programmed interfaces to other vendors' LIMS and ELNs to gain access to the same information.\n\nWhat does this have to do with automation? \nWhen we think about automated systems, particularly full-automation with robotic support, it is a programmed process from start to finish. The samples are introduced at the start, and the process continues until the final data\/information is reported and stored. These can be large scale systems using microplate formats, including tape-based systems from Douglas Scientific[13], programmable autosamplers such as those from Agilent[14], or systems built around robotics arms from a variety of vendors that move samples from one station to another.\nBoth LES and the automation noted in the previous paragraph have the following point in common: there is a strict process that must be followed, with no provision for variation. The difference is that in one case that process is implemented completely through the use of computers, as well as electronic and mechanical equipment. In the other case, the process is being carried out by lab personnel using computers, as well as electronic and mechanical lab equipment. In essence, people take the place of mechanical robots, which conjures up all kinds of images going back to the 1927 film Metropolis.[d] Though the LES represents a step toward more sophisticated automation, both methods still require:\n\n programming, including \u201cscripting\u201d (the LES methods are a script that has to be followed);\n validated, proven processes; and\n qualified staff, though the qualifications differ. (In both cases they have to be fully qualified to carry out the process in question. However in the full automation case, they will require more education on running, managing, and troubleshooting the systems.)\nIn the case of full automation, there has to be sufficient justification for the automation of the process, including sufficient sample processing. The LES-human implementation can be run for a single sample if needed, and the operating personnel can be trained on multiple procedures, switching tasks as needed. Electro-mechanical automation would require a change in programming, verification that the system is operating properly, and may require equipment re-configuration. Which method is better for a particular lab depends on trade-offs between sample load, throughput requirements, cost, and flexibility. People are adaptable, easily moving between tasks, whereas equipment has to be adapted to a task.\n\nHow do we go about planning for automation? \nThere are three forms of automation to be considered:\n\n No automation \u2013 Instead, the lab relies on lab personnel to carry out all steps of a procedure.\n Partial automation \u2013 Automated equipment is used to carry out steps in a procedure. Given the current state of laboratory systems, this is the most prevalent since most lab equipment has computer components in them to facilitate their use.\n Full automation - The entire process is automated. The definition of \u201centire\u201d is open to each labs interpretation and may vary from one process to another. For example, some samples may need some handing before they are suitable for use in a procedure. That might be a selection process from a freezer, grinding materials prior to a solvent extraction, and so on, representing cases where the equipment available isn\u2019t suitable for automated equipment interaction. One goal is to minimize this effort since it can put a limit on the productivity of the entire process. This is also an area where negotiation between the lab and the sample submitter can be useful. Take plastic pellets for example, which often need to be ground into a course powder before they can be analyzed; having the submitter provide them in this form will reduce the time and cost of the analysis. Standardizing on the sample container can also facilitate the analysis (having the lab provide the submitter with standard sample vials using barcodes or RFID chips can streamline the process).\nOne common point that these three forms share is a well-described method (procedure, process) that needs to be addressed. That method should be fully developed, tested, and validated. This is the reference point for evaluating any form of automation (Figure 1).\n\r\n\n\n\n\n\n\n\n\n\n\n Figure 1. Items to be considered in automating systems\n\n\n\nThe documentation for the chosen method should include the bulleted list of items from Figure 1, as they describe the science aspects of the method. The last four points are important. The method should be validated since the manual procedure is a reference point for determining if the automated system is producing useful results. The reproducibility metric offers a means of evaluating at least one expected improvement in an automated system; you\u2019d expect less variability in the results. This requires a set of reference sample materials that can be repeatedly evaluated to compare the manual and automated systems, and to periodically test the methods in use to ensure that there aren\u2019t any trends developing that would compromise the method\u2019s use. Basically, this amounts to statistical quality control on the processes.\nThe next step is to decide what improvements you are looking for in an automated system: increased throughput, lower cost of operation, the ability to off-load human work, reduced variability, etc. In short, what are your goals?\nThat brings us to the matter of project planning. We\u2019re not going to go into a lot of depth in this piece about project planning, as there are a number of references[e] on the subject, including material produced by the former Institute for Laboratory Automation.[f] There are some aspects of the subject that we do need to touch on, however, and they include:\n\n justifying the project and setting expectations and goals;\n analyzing the process;\n scheduling automation projects; and\n budgeting.\nJustification, expectations, and goals \nBasically why are you doing this, what do you expect to gain? What arguments are you going to use to justify the work and expense involved in the project? How will you determine if the project is successful?\nFundamentally, automation efforts are about productivity and the bulleted items noted in the introduction of this piece, repeated below with additional commentary:\n\n Lower costs per test, and better control over expenditure: These can result from a reduction in labor and materials costs, including more predictable and consistent reagent usage per test.\n Stronger basis for better workflow planning: Informatics systems can provide better management over workloads and resource allocation, while key performance indicators can show where bottlenecks are occurring or if samples are taking too long to process. These can be triggers for procedure automation to improve throughput.\n Reproducibility: The test results from automated procedures can be expected to be more reproducible by eliminating the variability that is typical of steps executed by people. Small variation in dispensing reagents, for example, could be eliminated.\n Predictability: The time to completion for a given test is more predictable in automated programs; once the process starts it keeps going without interruptions that can be found in human centered activities\n Tighter adherence to procedures: Automated procedures have no choice but to be consistent in procedure execution; that is what programming and automation is about.\nOf these, which are important to your project? If you achieved these goals, what would it mean to your labs operations and the organization as a whole; this is part of the justification for carrying out the projects.\nAs noted earlier, there are several things to consider in order to justify a project. First, there has to be a growing need that supports a procedures automation, one that can\u2019t be satisfied by other means that could include adding people, equipment, and lab space, or outsourcing the work (with the added burden of insuring data quality and integrity, and integrating that work with the lab\u2019s data\/information). Second, the cost of the project must be balanced by it\u2019s benefits. This includes any savings in cost, people (not reducing headcount, but avoiding new hires), material, and equipment, as well as the improvement of timeliness of results and overall lab operations. Third, when considering project justification, the automated process\u2019s useful lifetime has to be long enough to justify the development work. And finally, the process has to be stable so that you aren\u2019t in a constant re-development situation (this differs from periodic upgrades and performance improvements, EVOP in manufacturing terms). One common point of failure in projects is changes in underlying procedures; if the basic process model changes, you are trying to hit a moving target. That ruins schedules and causes budgets to inflate.\nThis may seem like a lot of things to think about for something that could be as simple as perhaps moving from manual pipettes to automatic units, but that just means the total effort to do the work will be small. However it is still important since it impacts data quality and integrity, and your ability to defend your results should they be challenged. And, by the way, the issue of automated pipettes isn\u2019t simple; there is a lot to consider in properly specifying and using these products.[g]\n\nAnalyzing the process \nAssuming that you have a well-described, thoroughly tested and validated procedure, that process has to be analyzed for optimization and suitability for automation. This is an end-to-end evaluation, not just a examination of isolated steps. This is an important point. Looking at a single step without taking into account the rest of the process may improve that portion of the process but have consequences elsewhere.\nTake a common example: working in a testing environment where samples are being submitted by outside groups (Figure 2).\n\r\n\n\n\n\n\n\n\n\n\n\n Figure 2. Lab sample processing, initial data entry through results\n\n\n\nMost LIMS will permit sample submitters (with appropriate permissions) to enter the sample description information directly into the LIMS, reducing some of the clerical burden. Standardizing on sample containers, with barcodes, reduces the effort and cost in some aspects of sample handling. A barcode scanner could be used to scan samples as they arrive into the lab, letting the system know that they are ready to be tested.\nThat brings us to an evaluation of the process as a whole, as well as an examination of the individual steps in the procedure. As shown in Figure 1, automation can be done in one of two ways: automating the full process or automating individual steps. Your choice depends on several factors, not the least of which is your comfort level and confidence in adopting automation as a strategy for increasing productivity. For some, concentrating on improvements in individual steps is an attractive approach. The cost and risk may be lower and if a problem occurs you can always backup to a fully manual implementation until they are resolved.\nCare does have to be taken in choosing which steps to improve. From one perspective, you\u2019d want to do the step-wise implementation of automation as close to the end of the process as possible. The problem with doing it earlier is that you may create a backup in later stages of the process. Optimizing step 2, for example, doesn\u2019t do you much good if step 3 is overloaded and requires more people, or additional (possibly unplanned) automation to relieve a bottleneck there. In short, before you automate or improve a given step, you need to be sure that downstream processing can absorb the increase in materials flow. In addition, optimizing all the individual steps, one at time, doesn\u2019t necessarily add up to a well-designed full system automation. The transition between steps may not be as effective or efficient if the system were evaluated as a whole. If the end of the process is carried out by commercial instrumentation, the ability to absorb more work is easier since most of these systems are automated with computer data acquisition and processing, and many have auto-samplers available to accumulate samples that can be processed automatically. Some of those auto-samplers have built in robotics for common sample handling functions. If the workload builds, additional instruments can pick up the load, and equipment such as Baytek International\u2019s TurboTube[15] can accumulate sample vials in a common system and route them to individual instruments for processing.\nAnother consideration for partial automation is where the process is headed in the future. If the need for the process persists over a long period of time, will you eventually get to the point of needing to redo the automation to an integrated stream? If so, is it better to take the plunge early on instead of continually expending resources to upgrade it?\nOther considerations include the ability to re-purpose equipment. If a process isn\u2019t used full-time (a justification for partial automation) the same components may be used in improving other processes. Ideally, if you go the full-process automation route, you\u2019ll have sufficient sample throughput to keep it running for an extended period of time, and not have to start and stop the system as samples accumulate. A smoothly running slower automation process is better than a faster system that lies idle for significant periods of time, particularly since startup and shutdown procedures may diminish the operational cost savings in both equipment use and people\u2019s time.\nAll these points become part of both the technical justification and budget requirements.\nAnalyzing the process: Simulation and modeling\nSimulation and modeling have been part of science and engineering for decades, supported by ever-increasing powerful computing hardware and software. Continuous systems simulations have shown us the details of how machinery works, how chemical reactions occur, and how chromatographic systems and other instrumentation behaves.[16] There is another aspect to modeling and simulation that is appropriate here.\nDiscrete-events simulation (DES) is used to model and understand processes in business and manufacturing applications, evaluating the interactions between service providers and customers, for example. One application of DES is to determine the best way to distribute incoming customers to a limited number of servers, taking into account that not all customers have the same needs; some will tie up a service provider a lot longer than others, as represented by the classic bank teller line problem. That is one question that discrete systems can analyze. This form of simulation and modeling is appropriate to event-driven processes where the action is focused on discrete steps (like materials moving from one workstation to another) rather than as a continuous function of time (most naturally occurring systems fall into this category, e.g., heat flow and models using differential equations).\nThe processes in your lab can be described and analyzed via DES systems.[17][18][19] Those laboratory procedures are a sequence of steps, each having a precursor, variable duration, and following step until the end of the process is reached; this is basically the same as a manufacturing operation where modeling and simulation have been used successfully for decades. DES can be used to evaluate those processes and ask questions that can guide you on the best paths to take in applying automation technologies and solving productivity or throughput problems. For example:\n\n What happens if we tighten up the variability in a particular step; how will that affect the rest of the system?\n What happens at the extremes of the variability in process steps; does it create a situation where samples pile up?\n How much of a workload can the process handle before one step becomes saturated with work and the entire system backs up?\n Can you introduce an alternate path to process those samples and avoid problems (e.g., if samples are held for too long in one stage, do they deteriorate)?\n Can the output of several parallel slower procedures be merged into a feed stream for a common instrumental technique?\nIn complex procedures some steps may be sensitive to small delays, and DES can help test and uncover them. Note that setting up these models will require the collection of a lot of data about the processes and their timing, so this is not something to be taken casually.\nPrevious research[16][17][18][19] suggests only a few ideas where simulation can be effective, including one where an entire labs operation\u2019s was evaluated. Models that extensive can be used to not only look at procedures, but also the introduction of informatics systems. This may appear to be a significant undertaking, and it can be depending on the complexity of the lab processes. However, simple processes can be initially modeled on spreadsheets to see if more significant effort is justified. Operations research, of which DES is a part, has been usefully applied in production operations to increase throughput and improve ROI. It might be successfully applied to some routine production oriented lab work.\nMost lab processes are linear in their execution, one step following another, with the potential for loop-backs should problems be recognized with samples, reagents (e.g., being out-of-date, doesn\u2019t look right, need to obtain new materials), or equipment (e.g., not functioning properly, out of calibration, busy due to other work). On one level, the modeling of a manually implemented process should appear to be simple: each step takes a certain amount of time. If you add up the times, you have a picture of the process execution through time. However, the reality is quite different if you take into account problems (and their resolution) that can occur in each of those steps. The data collection used to model the procedure can change how that picture looks and your ability to improve it. By monitoring the process over a number of iterations, you can find out how much variation there is in the execution time for each step and whether or not the variation is a normal distribution or skewed (e.g., if one step is skewed, how does it impact others?).\nQuestions to ask about potential problems that could occur at each step include:\n\n How often do problems with reagents occur and how much of a delay does that create?\n Is instrumentation always in calibration (do you know?), are there operational problems with devices and their control systems (what are the ramifications?), are procedures delayed due to equipment being in use by someone else, and how long does it take to make changeovers in operating conditions?\n What happens to the samples; do they degrade over time? What impact does this have on the accuracy of results and their reproducibility?\n How often are workflows interrupted by the need to deal with high-priority samples, and what effect does it have on the processing of other samples?\nJust the collection of data can suggest useful improvements before there are any considerations for automation, and perhaps negating the need for it. The answer to a lab\u2019s productivity might be as simple as adding another instrument if that is a bottleneck. It might also suggest that an underutilized device might be more productive if sample preparation for different procedures workflows were organized differently. Underutilization might be a consequence of the amount of time needed to prepare the equipment for service: doing so for one sample might be disproportionately time consuming (and expensive) and cause other samples to wait until there were enough of them to justify the preparation. It could also suggest that some lab processes should be outsourced to groups that have a more consistent sample flow and turn-around time (TAT) for that technique. Some of these points are illustrated in Figures 3a and 3b below.\n\r\n\n\n\n\n\n\n\n\n\n\n Figure 3a. Simplified process views versus some modeling considerations. Note that the total procedure execution time is affected by the variability in each step, plus equipment and material availability delays; these can change from one day to the next in manual implementations.\n\n\n\n\n\n\n\n\n\n\n\n\n Figure 3b. The execution times of each step include the variable execution times of potential issues that can occur in each stage. Note that because each factor has a different distribution curve, the total execution time has a much wider variability than the individual factors.\n\n\n\nHow does the simulation system work? Once you have all the data set up, the simulation runs thousands of times using random number generators to pick out variables in execution times for each component in each step. For example, if there is a one-in-ten chance a piece of equipment will be in use when needed, 10% of the runs will show that with each one picking a delay time based on the input delay distribution function. With a large number of runs, you can see where delays exist and how they impact the overall processes behavior. You can also adjust the factors (what happens if equipment delays are cut in half) and see the effect of doing that. By testing the system, you can make better judgments on how to apply your resources.\nSome of the issues that surface may be things that lab personnel know about and just deal with. It isn\u2019t until the problems are looked at that the impact on operations are fully realized and addressed. Modeling and simulation may appear to be overkill for lab process automation, something reserved for large- scale production projects. The physical size of the project is not the key factor, it is the complexity of the system that matters and the potential for optimization.\nOne benefit of a well-structured simulation of lab processes is that it would provide a solid basis for making recommendations for project approval and budgeting. The most significant element in modeling and simulation is the initial data collection, asking lab personnel to record the time it takes to carry out steps. This isn\u2019t likely to be popular if they don\u2019t understand why it is being done and what the benefits will be to them and the lab; accurate information is essential. This is another case where \u201cbad data is worse than no data.\u201d\nGuidleines for process automation\nThere are two types of guidelines that will be of interest to those conducting automation work: those that help you figure out what to do and how to do it, and those that must be met to satisfy regulatory requirements (both those evaluated by internal or external groups or organizations).\nThe first is going to depend on the nature of the science and automation being done to support it. Equipment vendor community support groups can be of assistance. Additionally, professional groups like the Pharmaceutical Research and Manufacturers of America (PhRMA), International Society for Pharmaceutical Engineering (ISPE), and Parenteral Drug Association (PDA) in the pharmaceutical and biotechnology industrues, with similar organizations in other industries and other countries. This may seem like a large jump from laboratory work, but it is appropriate when we consider the ramification of full-process automation. You are essentially developing a manufacturing operation on a lab bench, and the same concerns that large-scale production have also apply here; you have to ensure that the process is maintained and in control. The same is true of manual or semi-automated lab work, but it is more critical in fully-automated systems because of the potential high volume of results that can be produced.\nThe second set is going to consist of regulatory guidelines from groups appropriate to your industry: the Food and Drug Administration (FDA), Environmental Protection Agency (EPA), and International Organization for Standardization (ISO), as well as international groups (e.g., GAMP, GALP) etc. The interesting point is that we are looking at a potentially complete automation scheme for a procedure; does that come under manufacturing or laboratory? The likelihood is that laboratory guidelines will apply since the work is being done within the lab's footprint; however, there are things that can be learned from their manufacturing counterparts that may assist in project management and documentation. One interesting consideration is what happens when fully automated testing, such as on-line analyzers, becomes integrated with both the lab and production or process control data\/information streams. Which regulatory guidelines apply? It may come down to who is responsible for managing and supporting those systems.\n\nScheduling automation projects \nThere are two parts to the schedule issue: how long is it going to take to compete the project (dependent on the process and people), and when do you start? The second point will be addressed here.\nThe timing of an automated process coming online is important. If it comes on too soon, there may not be enough work to justify it\u2019s use, and startup\/shutdown procedures may create more work than the system saves. If it comes too late, people will be frustrated with a heavy workload while the system that was supposed to provide relief is under development. \nIn Figure 4, the blue line represents the growing need for sample\/material processing using a given laboratory procedure. Ideally, you\u2019d like the automated version to be available when that blue line crosses the \u201cautomation needed on-line\u201d level of processing requirements; this the point where the current (manual?) implementation can no longer meet the demands of sample throughput requirements.\n\r\n\n\n\n\n\n\n\n\n\n\n Figure 4. Timing the development of an automated system\n\n\n\nThose throughput limits are something you are going to have to evaluate and measure on a regular basis and use to make adjustments to the planning process (accelerating or slowing it as appropriate). How fast is the demand growing and at what point will your current methods be overwhelmed? Hiring more people is one option, but then the lab's operating expenses increase due to the cost of people, equipment, and lab space.\nOnce we have an idea of when something has to be working, we can begin the process of planning; note: the planning can begin at any point, it would be good to get the preliminaries done as soon as a manual process is finalized so that you have an idea of what you\u2019ll be getting into. Those preliminaries include looking at equipment that might be used (keeping track of its development), training requirements, developer resources, and implementation strategies, all of which would be updated as new information becomes available. The \u201cwe\u2019ll-get-to-it-when-we-need-it\u201d approach is just going to create a lot of stress and frustration.\nYou need to put together a first-pass project plan so that you can detail what you know, and more importantly what you don\u2019t know. The goal is to have enough information, updated as noted above, so that you can determine if an automated solution is feasible, make an informed initial choice between full and partial automation, and have a timeline for implementation. Any time estimate is going to be subject to change as you gather information and refine your implementation approach. The point of the timeline is to figure out how long the yellow box in Figure 4 is because that is going to tell you how much time you have to get the plan together and working; it is a matter of setting priorities and recognizing what they are. The time between now and the start of the yellow box is what you have to work with for planning and evaluating plans, and any decisions that are needed before you begin, including corporate project management requirements and approvals.\nThose plans have to include time for validation and the evaluation of the new implementation against the standard implementation. Does it work? Do we know how to use and maintain it? And are people educated in its use? Is there documentation for the project?\n\nBudgeting \nAt some point, all the material above and following this section comes down to budgeting: how much will it cost to implement a program and is it worth it? Of the two points, the latter is the one that is most important. How do you go about that? (Note: Some of this material is also covered in the webinar series A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work in the section on ROI.)\nWhat a lot of this comes down to is explaining and justifying the choices you\u2019ve made in your project proposal. We\u2019re not going to go into a lot of depth, but just note some of the key issues:\n\n Did you choose full or partial automation for your process?\n What drove that choice? If in your view it would be less expensive than the full automation of a process, how long will it be until the next upgrade is needed to another stage?\n How independent are the potential, sequential implementation efforts that may be undertaken in the future? Will there be a need to connect them, and if so, how will the incremental costs compare to just doing it once and getting it over with?\nThere is a tendency in lab work to treat problems and the products that might be used to address them in isolation. You see the need for a LIMS or ELN, or an instrument data system, and the focus is on those issues. Effective decisions have to consider both the immediate and longer-term aspects of a problem. If you want to get access to a LIMS, have you considered how it will affect other aspects of lab work such as connecting instrument to it?\nThe same holds true for partial automation as a solution to a lab process productivity problem. While you are addressing a particular step, should you be looking at the potential for synergism by addressing other concerns. Modeling and simulations of processes can help resolve that issue.\nHave you factored in the cost of support and education? The support issue needs to address the needs of lab personnel in managing the equipment and the options for vendor support, as well as the impact on IT groups. Note that the IT group will require access to vendor support, as well as being educated on their role in any project work.\nWhat happens if you don\u2019t automate? One way to justify the cost of a project is to help people understand what the lab\u2019s operations will be like without it. Will more people, equipment, space, or added shifts be needed? At what cost? What would the impact be on those who need the results and how would it affect their programs?\n\nBuild, buy, or cooperate? \nIn this write up and some of the referenced materials, we\u2019ve noted several times the benefits that clinical labs have gained through automation, although crediting it all to the use of automation alone isn\u2019t fair. What the clinical laboratory industry did was recognize that there was a need for the use of automation to solve problems with the operational costs of running labs, and recognition that they could benefit further by coming together and cooperatively addressing lab operational problems.\nIt\u2019s that latter point that made the difference and resulted in standardized communications, and purpose-built commercial equipment that could be used to implement automation in their labs. They also had common sample types, common procedures, and data processing. That same commonality applies to segments of industrial and academic lab work. Take life sciences as an example. Where possible, that industry has standardized on micro-plates for sample processing. The result is a wide selection of instruments and robotics built around that sample-holding format that greatly improves lab economics and throughput. While it isn\u2019t the answer to everything, it\u2019s a good answer to a lot of things.\nIf your industry segment came together and recognized that you used common procedures, how would you benefit by creating a common approach to automation instead of each lab doing it on their own? It would open the development of common products or product variations from vendors and relieve the need for each lab developing its own answer to the need. The result could be more effective and easily supportable solutions.\n\nProject planning \nOnce you\u2019ve decided on the project you are going to undertake, the next stage is looking at the steps needed to manage your project (Figure 5).\n\r\n\n\n\n\n\n\n\n\n\n\n Figure 5. Steps in a laboratory automation project. This diagram is modeled after the GAMP V for systems validation.\n\n\n\nThe planning begins with the method description from Figure 1, which describes the science behind the project and the specification of how the automation is expected to be put into effect: as full-process automation, a specific step, or steps in the process. The provider of those documents is considered the \u201ccustomer\u201d and is consistent with GAMP V nomenclature (Figure 6); that consistency is important due to the need for system-wide validation protocols.\n\r\n\n\n\n\n\n\n\n\n\n\n Figure 6. GAMP V model for showing customer and supplier roles in specifying and evaluating project components for computer hardware and software.\n\n\n\nFrom there the \u201csupplier\u201d (e.g., internal development group, consultant, IT services, etc.) responds with a functional specification that is reviewed by the customer. The \u201canalysis, prototyping, and evaluation\u201d step, represented in the third box of Figure 5, is not the same as the process analysis noted earlier in this piece. The earlier section was to help you determine what work needed to be done and documented in the user requirements specification. The analysis and associated tasks here are specific to the implementation of this project. The colored arrows refer to the diagram in Figure 7. That process defines the equipment needed, dependencies, and options\/technologies for automation implementations, including robotics, instrument design requirements, pre-built automation (e.g., titrators, etc.) and any custom components. The documentation and specifications are part of the validation protocol.\n\r\n\n\n\n\n\n\n\n\n\n\n Figure 7. Defining dependencies and qualification of equipment\n\n\n\nThe prototyping function is an important part of the overall process. It is rare that someone will look at a project and come up with a working solution on the first pass. There is always tinkering and modifications that occur as you move from a blank slate to a working system. You make notes along the way about what should be done differently in the final product, and places where improvements or adjustments are needed. These all become part of the input to the system design specification that will be reviewed and approved by the customer and supplier. The prototype can be considered a proof of concept or a demonstration of what will occur in the finished product. Remember also that prototypes would not have to be validated since they wouldn\u2019t be used in a production environment; they are simply a test bed used prior to the development of a production system.\nThe component design specifications are the refined requirement for elements that will be used in the final design. Those refinements could point to updated models of components or equipment used, modifications needed, or recommendations for products with capabilities other than those used in the prototype.\nThe boxes on the left side of Figure 5 are documents that go into increasing depth as the system is designed and specified. The details in those items will vary with the extent of the project. The right side of the diagram is a series of increasingly sophisticated testing and evaluation against steps in the right side, culminating in the final demonstration that the system works, has been validated, and is accepted by the customer. It also means that lab and support personnel are educated in their roles.\n\nConclusions (so far) \n\u201cLaboratory automation\u201d has to give way to \u201claboratory automation engineering.\u201d From the initial need to the completion of the validation process, we have to plan, design, and implement successful systems on a routine basis. Just as the manufacturing industries transitioned from cottage industries to production lines and then to integrated production-information systems, the execution of laboratory science has to tread a similar path if the demands for laboratory results are going to be met in a financially responsible manner. The science is fundamental; however, we need to pay attention now to efficient execution.\n\nAbbreviations, acronyms, and initialisms \nAI: Artificial intelligence\nAuI: Augmented intelligence\nDES: Discrete-events simulation\nELN: Electronic laboratory notebook\nEPA: Environmental Protection Agency\nFDA: Food and Drug Administration\nFRB: Fast radio bursts\nGALP: Good automated laboratory practices\nGAMP: Good automated manufacturing practice\nISO: International Organization for Standardization\nLES: Laboratory execution system\nLIMS: Laboratory information management system\nML: Machine learning\nROI: Return on investment\nSDMS: Scientific data management system\nTAT: Turn-around time\n\r\n\n\nFootnotes \n\n\n\u2191 The term \"scientific manufacturing\" was first mentioned to the author by Mr. Alberto Correia, then of Cambridge Biomedical, Boston, MA. \n\n\u2191 Intelligent enterprise technologies referenced in the report include robotic process automation, machine learning, artificial intelligence, the internet Of things, predictive analysis, and cognitive computing. \n\n\u2191 Doug Engelbart found the field of human-computer interaction and is credited with the invention of the computer mouse, and the \u201cMother of All Demos\u201d in 1968. \n\n\u2191 See Metropolis (1927 film) on Wikipedia. \n\n\u2191 See for example https:\/\/www.projectmanager.com\/project-planning; the simplest thing to do it put \u201cproject planning\u201d in a search engine and browse the results for something interesting. \n\n\u2191 See for example https:\/\/theinformationdrivenlaboratory.wordpress.com\/category\/resources\/; note that any references to the ILA should be ignored as the original site is gone, with the domain name perhaps having been leased by another organization that has no affiliation with the original Institute for Laboratory Automation. \n\n\u2191 As a starting point, view the Artel, Inc. site as one source. Also, John Bradshaw gave an informative presentation on \u201cThe Importance of Liquid Handling Details and Their Impact on your Assays\u201d at the 2012 European Lab Automation Conference, Hamburg, Germany. \n\n\nAbout the author \nInitially educated as a chemist, author Joe Liscouski (joe dot liscouski at gmail dot com) is an experienced laboratory automation\/computing professional with over forty years of experience in the field, including the design and development of automation systems (both custom and commercial systems), LIMS, robotics and data interchange standards. He also consults on the use of computing in laboratory work. He has held symposia on validation and presented technical material and short courses on laboratory automation and computing in the U.S., Europe, and Japan. He has worked\/consulted in pharmaceutical, biotech, polymer, medical, and government laboratories. His current work centers on working with companies to establish planning programs for lab systems, developing effective support groups, and helping people with the application of automation and information technologies in research and quality control environments.\n\nReferences \n\n\n\u2191 Frey, C.B.; Osborne, M.A. (17 September 2013). \"The Future of Employment: How Susceptible Are Jobs to Computerisation?\" (PDF). Oxford Martin School, University of Oxford. https:\/\/www.oxfordmartin.ox.ac.uk\/downloads\/academic\/The_Future_of_Employment.pdf . Retrieved 04 February 2021 .   \n\n\u2191 Hsu, J. (24 September 2018). \"Is it aliens? Scientists detect more mysterious radio signals from distant galaxy\". NBC News MACH. https:\/\/www.nbcnews.com\/mach\/science\/it-aliens-scientists-detect-more-mysterious-radio-signals-distant-galaxy-ncna912586 . Retrieved 04 February 2021 .   \n\n\u2191 Timmer, J. (18 July 2018). \"AI plus a chemistry robot finds all the reactions that will work\". Ars Technica. https:\/\/arstechnica.com\/science\/2018\/07\/ai-plus-a-chemistry-robot-finds-all-the-reactions-that-will-work\/5\/ . Retrieved 04 February 2021 .   \n\n\u2191 \"HelixAI - Voice Powered Digital Laboratory Assistants for Scientific Laboratories\". HelixAI. http:\/\/www.askhelix.io\/ . Retrieved 04 February 2021 .   \n\n\u2191 PharmaIQ News (20 August 2018). \"Automation, IoT and the future of smarter research environments\". PharmaIQ. https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/news\/automation-iot-and-the-future-of-smarter-research-environments . Retrieved 04 February 2021 .   \n\n\u2191 6.0 6.1 PharmaIQ (14 November 2017). \"The Future of Drug Discovery: AI 2020\". PharmaIQ. https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/whitepapers\/the-future-of-drug-discovery-ai-2020 . Retrieved 04 February 2021 .   \n\n\u2191 Rossetto, L. (2018). \"Fight the Dour\". Wired (October): 826\u20137. https:\/\/www.magzter.com\/stories\/Science\/WIRED\/Fight-The-Dour .   \n\n\u2191 \"OPUS Package: SEARCH & IDENT\". Bruker Corporation. https:\/\/www.bruker.com\/en\/products-and-solutions\/infrared-and-raman\/opus-spectroscopy-software\/search-identify.html . Retrieved 04 February 2021 .   \n\n\u2191 Bourne, D. (2013). \"My Boss the Robot\". Scientific American 308 (5): 38\u201341. doi:10.1038\/scientificamerican0513-38. PMID 23627215.   \n\n\u2191 SalesForce Research (2017). \"Second Annual State of IT\" (PDF). SalesForce. https:\/\/a.sfdcstatic.com\/content\/dam\/www\/ocms\/assets\/pdf\/misc\/2017-state-of-it-report-salesforce.pdf . Retrieved 04 February 2021 .   \n\n\u2191 \"Seal Analytical - Products\". Seal Analytical. https:\/\/seal-analytical.com\/Products\/tabid\/55\/language\/en-US\/Default.aspx . Retrieved 04 February 2021 .   \n\n\u2191 \"Bran+Luebbe\". SPX FLOW, Inc. https:\/\/www.spxflow.com\/bran-luebbe\/ . Retrieved 04 February 2021 .   \n\n\u2191 \"Array Tape Advanced Consumable\". Douglas Scientific. https:\/\/www.douglasscientific.com\/Products\/ArrayTape.aspx . Retrieved 04 February 2021 .   \n\n\u2191 \"Agilent 1200 Series Standard and Preparative Autosamplers - User Manual\" (PDF). Agilent Technologies. November 2008. https:\/\/www.agilent.com\/cs\/library\/usermanuals\/Public\/G1329-90012_StandPrepSamplers_ebook.pdf . Retrieved 04 February 2021 .   \n\n\u2191 \"iPRO Interface - Products\". Baytek International, Inc. https:\/\/www.baytekinternational.com\/products\/ipro-interface\/89-products . Retrieved 05 February 2021 .   \n\n\u2191 16.0 16.1 Joyce, J. (2018). \"Computer Modeling and Simulation\". Lab Manager (9): 32\u201335. https:\/\/www.labmanager.com\/laboratory-technology\/computer-modeling-and-simulation-1826 .   \n\n\u2191 17.0 17.1 Costigliola, A.; Ata\u00edde, F.A.P.; Vieira, S.M. et al. (2017). \"Simulation Model of a Quality Control Laboratory in Pharmaceutical Industry\". IFAC-PapersOnLine 50 (1): 9014-9019. doi:10.1016\/j.ifacol.2017.08.1582.   \n\n\u2191 18.0 18.1 Meng, L.; Liu, R.; Essick, C. et al. (2013). \"Improving Medical Laboratory Operations via Discrete-event Simulation\". Proceedings of the 2013 INFORMS Healthcare Conference. https:\/\/www.researchgate.net\/publication\/263238201_Improving_Medical_Laboratory_Operations_via_Discrete-event_Simulation .   \n\n\u2191 19.0 19.1 \"Application of discrete-event simulation in health care clinics: A survey\". Journal of the Operational Research Society 50: 109\u201323. 1999. doi:10.1057\/palgrave.jors.2600669.   \n\n\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Considerations_in_the_Automation_of_Laboratory_Procedures\">https:\/\/www.limswiki.org\/index.php\/LII:Considerations_in_the_Automation_of_Laboratory_Procedures<\/a>\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \n\t\n\t\n\t\r\n\n\t\r\n\n \n\t\n\t\r\n\n\t\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 18 February 2021, at 19:46.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 888 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n\n","e0147011cc1eb892e1a35e821657a6d9_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Considerations_in_the_Automation_of_Laboratory_Procedures skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Considerations in the Automation of Laboratory Procedures<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><p><b>Title<\/b>: <i>Considerations in the Automation of Laboratory Procedures<\/i>\n<\/p><p><b>Author for citation<\/b>: Joe Liscouski, with editorial modifications by Shawn Douglas\n<\/p><p><b>License for content<\/b>: <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/creativecommons.org\/licenses\/by\/4.0\/\" target=\"_blank\">Creative Commons Attribution 4.0 International<\/a>\n<\/p><p><b>Publication date<\/b>: January 2021\n<\/p>\n\n\n<h2><span class=\"mw-headline\" id=\"Introduction\">Introduction<\/span><\/h2>\n<p>Scientists have been dealing with the issue of <a href=\"https:\/\/www.limswiki.org\/index.php\/Laboratory_automation\" title=\"Laboratory automation\" class=\"wiki-link\" data-key=\"0061880849aeaca05f8aa27ae171f331\">laboratory automation<\/a> for decades, and during that time the meaning of those words has expanded from the basics of connecting an instrument to a computer, to the possibility of a fully integrated <a href=\"https:\/\/www.limswiki.org\/index.php\/Informatics_(academic_field)\" title=\"Informatics (academic field)\" class=\"wiki-link\" data-key=\"0391318826a5d9f9a1a1bcc88394739f\">informatics<\/a> infrastructure beginning with <a href=\"https:\/\/www.limswiki.org\/index.php\/Sample_(material)\" title=\"Sample (material)\" class=\"wiki-link\" data-key=\"7f8cd41a077a88d02370c02a3ba3d9d6\">sample<\/a> preparation and continuing on to the <a href=\"https:\/\/www.limswiki.org\/index.php\/Laboratory_information_management_system\" title=\"Laboratory information management system\" class=\"wiki-link\" data-key=\"8ff56a51d34c9b1806fcebdcde634d00\">laboratory information management system<\/a> (LIMS), <a href=\"https:\/\/www.limswiki.org\/index.php\/Electronic_laboratory_notebook\" title=\"Electronic laboratory notebook\" class=\"wiki-link\" data-key=\"a9fbbd5e0807980106763fab31f1e72f\">electronic laboratory notebook<\/a> (ELN), and beyond. Throughout this evolution there has been one underlying concern: how do we go about doing this?\n<\/p><p>The answer to that question has changed from a focus on hardware and programming, to today\u2019s need for a lab-wide informatics strategy. We\u2019ve moved from the bits and bytes of assembly language programming to managing terabytes of files and data structures.\n<\/p><p>The high-end of the problem\u2014the large informatics database systems\u2014has received significant industry-wide attention in the last decade. The stuff on the lab bench, while the target of a lot of individual products, has been less organized and more experimental. Failed or incompletely met promises have to yield to planned successes. How we do it needs to change. This document is about the considerations required when making that change. The haphazard \"let's try this\" method has to give way to more engineered solutions and a realistic appraisal of the human issues, as well as the underlying technology management and planning.\n<\/p><p>Why is this important? Whether you are conducting intense laboratory experiments to produce data and <a href=\"https:\/\/www.limswiki.org\/index.php\/Information\" title=\"Information\" class=\"wiki-link\" data-key=\"6300a14d9c2776dcca0999b5ed940e7d\">information<\/a> or making chocolate chip cookies in the kitchen, two things remain important: productivity and the quality of the products. In either case, if the productivity isn\u2019t high enough, you won\u2019t be able to justify your work; if the quality isn\u2019t there, no one will want what you produce. Conducting laboratory work and making cookies have a lot in common. Your laboratories exist to answer questions. What happens if I do this? What is the purity of this material? What is the structure of this compound? The field of laboratories asking these questions is extensive, basically covering the entire array of lab bench and scientific work, including chemistry, life sciences, physics, and electronics labs. The more efficiently we answer those questions, the more likely it will be that these labs will continue operating and, that you\u2019ll achieve the goals your organization has set. At some point, it comes down to performance against goals and the return on the investment organizations make in lab operations.\n<\/p><p>In addition to product quality and productivity, there are a number of other points that favor automation over manual implementations of lab processes. They include:\n<\/p>\n<ul><li> lower costs per test;<\/li>\n<li> better control over expenditures;<\/li>\n<li> a stronger basis for better <a href=\"https:\/\/www.limswiki.org\/index.php\/Workflow\" title=\"Workflow\" class=\"wiki-link\" data-key=\"92bd8748272e20d891008dcb8243e8a8\">workflow<\/a> planning;<\/li>\n<li> reproducibility;<\/li>\n<li> predictably; and<\/li>\n<li> tighter adherence to procedures, i.e., consistency.<\/li><\/ul>\n<p>Lists similar to the one above can be found in justifications for lab automation, and cookie production, without further comment. It\u2019s just assumed that everyone agrees and that the reasoning is obvious. Since we are going to use those items to justify the cost and effort that goes into automation, we should take a closer look at them.\n<\/p><p>Lets begin with reproducibility, predictability, and consistency, very similar concerns that reflect automation\u2019s ability to produce the same product with the desired characteristics over and over. For data and information, that means that the same analysis on the same materials will yield the same results, that all the steps are documented and that the process is under control. The variability that creeps into the execution of a process by people is eliminated. That variability in human labor can result from the quality of training, equipment setup and calibration, readings from analog devices (e.g., meters, pipette meniscus, charts, etc.), there is a long list of potential issues.\n<\/p><p>Concerns with reproducibility, predictability, and consistency are common to production environments, general lab work, manufacturing, and even food service. There are several pizza restaurants in our area using one of two methods of making the pies. Both start the preparation the same way, spreading dough and adding cheese and toppings, but the differences are in how they are cooked. Once method uses standard ovens (e.g., gas, wood, or electric heating); the pizza goes in, the cook watches it, and then removes it when the cooking is completed. This leads to a lot of variability in the product, some a function of the cook\u2019s attention, some depending on requests for over or under cooking the crust. Some is based on \"have it your way\" customization. The second method uses a metal conveyor belt to move the pie through an oven. The oven temperature is set as is the speed of the belt, and as long as the settings are the same, you get a reproducible, consistent product order after order. It\u2019s a matter of priorities. Manual verses automated. Consistent product quality verses how the cook feels that day. In the end, reducing variability and being able to demonstrate consistent, accurate, results gives people confidence in your product.\n<\/p><p>Lower costs per test, better control over expenditures, and better workflow planning also benefit from automation. Automated processes are more cost-efficient since the sample throughput is higher and the labor cost is reduced. The cost per test and the material usage is predictable since variability in components used in testing is reduced or eliminated, and workflow planning is improved since the time per test is known, work can be better scheduled. Additionally, process scale-up should be easier if there is a high demand for particular procedures. However there is a lot of work that has to be considered before automation is realizable, and that is where this discussion is headed.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"How_does_this_discussion_relate_to_previous_work.3F\">How does this discussion relate to previous work?<\/span><\/h2>\n<p>This work follows on the heels of two previous works:\n<\/p>\n<ul><li> <i><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.pda.org\/bookstore\/product-detail\/2684-computerized-systems-in-modern-lab\" target=\"_blank\">Computerized Systems in the Modern Laboratory: A Practical Guide<\/a><\/i> (2015): This book presents the range of informatics technologies, their relationship to each other, and the role they play in laboratory work. It differentiates a LIMS from an ELN and <a href=\"https:\/\/www.limswiki.org\/index.php\/Scientific_data_management_system\" title=\"Scientific data management system\" class=\"wiki-link\" data-key=\"9f38d322b743f578fef487b6f3d7c253\">scientific data management system<\/a> (SDMS) for example, contrasting their use and how they would function in different lab working environments. In addition, it covers topics such as support and regulatory issues.<\/li><\/ul>\n<ul><li> <i><a href=\"https:\/\/www.limswiki.org\/index.php\/LII:A_Guide_for_Management:_Successfully_Applying_Laboratory_Systems_to_Your_Organization%27s_Work\" title=\"LII:A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work\" class=\"wiki-link\" data-key=\"00b300565027cb0518bcb0410d6df360\">A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work<\/a><\/i> (2018): This webinar series complements the above text. It begins by introducing the major topics in informatics (e.g., LIMS, ELN, etc.) and then discusses their use from a strategic viewpoint. Where and how do you start planning? What is your return on investment? What should get implemented first, and then what are my options? The series then moves on to developing an <a href=\"https:\/\/www.limswiki.org\/index.php\/Information_management\" title=\"Information management\" class=\"wiki-link\" data-key=\"f8672d270c0750a858ed940158ca0a73\">information management<\/a> strategy for the lab, taking into account budgets, support, ease of implementation, and the nature of your lab\u2019s work.<\/li><\/ul>\n<p>The material in this write-up picks up where the last part of the webinar series ends. The last session covers lab processes, amd this picks up that thread and goes into more depth concerning a basic issue: how do you move from manual methods to automated systems?\n<\/p><p>Productivity has always been an issue in laboratory work. Until the 1950s, a lab had little choice but to add more people if more work needed to be done. Since then, new technologies have afforded wider options, including new instrument technologies. The execution of the work was still done by people, but the tools were better. Now we have other options. We just have to figure out when, if, and how to use them.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Before_we_get_too_far_into_this...\">Before we get too far into this...<\/span><\/h3>\n<p>With elements such as productivity, return on investment (ROI), <a href=\"https:\/\/www.limswiki.org\/index.php\/Data_quality\" title=\"Data quality\" class=\"wiki-link\" data-key=\"7fe43b05eae4dfa9b5c0547cc8cfcceb\">data quality<\/a>, and <a href=\"https:\/\/www.limswiki.org\/index.php\/Data_integrity\" title=\"Data integrity\" class=\"wiki-link\" data-key=\"382a9bb77ee3e36bb3b37c79ed813167\">data integrity<\/a> as driving factors in this work, you shouldn\u2019t be surprised if a lot of the material reads like a discussion of manufacturing methodologies; we\u2019ve already seen some examples. We are talking about scientific work, but the same things that drive the elements noted in labs have very close parallels in product manufacturing. The work we are describing here will be referenced as \"scientific manufacturing,\" manufacturing or production in support of scientific programs.<sup id=\"rdp-ebb-cite_ref-1\" class=\"reference\"><a href=\"#cite_note-1\">[a]<\/a><\/sup>\n<\/p><p>The key points of a productivity conversation in both lab and material production environments are almost exact overlays, the only significant difference is that the results of the efforts are data and information in one case, and a physical item you might sell in the other. Product quality and integrity are valued considerations in both. For scientists, this may require an adjustment to their perspectives when dealing with automation. On the plus side, the lessons learned in product manufacturing can be applied to lab bench work, making the path to implementation a bit easier while providing a framework for understanding what a successful automation effort looks like. People with backgrounds in product manufacturing can be a useful resource in the lab, with a bit of an adjustment in perspective on their part.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Transitioning_from_typical_lab_operations_to_automated_systems\">Transitioning from typical lab operations to automated systems<\/span><\/h2>\n<p>Transitioning a lab from its current state of operations to one that incorporates automation can raise a number of questions, and people\u2019s anxiety levels. There are several questions that should be considered to set expectations for automated systems and how they will impact jobs and the introduction of new technologies. They include:\n<\/p>\n<ul><li> What will happen to people\u2019s jobs as a result of automation?<\/li>\n<li> What is the role of <a href=\"https:\/\/www.limswiki.org\/index.php\/Artificial_intelligence\" title=\"Artificial intelligence\" class=\"wiki-link\" data-key=\"0c45a597361ca47e1cd8112af676276e\">artificial intelligence<\/a> (AI) and <a href=\"https:\/\/www.limswiki.org\/index.php\/Machine_learning\" title=\"Machine learning\" class=\"wiki-link\" data-key=\"79aab39cfa124c958cd1dbcab3dde122\">machine learning<\/a> (ML) in automation?<\/li>\n<li> Where do we find the resources to carry out automation projects\/programs?<\/li>\n<li> What equipment would we need for automated processes, and will it be different that what we currently have?<\/li>\n<li> What role does a <a href=\"https:\/\/www.limswiki.org\/index.php\/Laboratory_execution_system\" title=\"Laboratory execution system\" class=\"wiki-link\" data-key=\"774bdcab852f4d09565f0486bfafc26a\">laboratory execution system<\/a> (LES) play in laboratory automation?<\/li>\n<li> How do we go about planning for automation?<\/li><\/ul>\n<h3><span class=\"mw-headline\" id=\"What_will_happen_to_people.E2.80.99s_jobs_as_a_result_of_automation.3F\">What will happen to people\u2019s jobs as a result of automation?<\/span><\/h3>\n<p>Stories are appearing in print, online, and in television news reporting about the potential for automation to replace human effort in the labor force. It seems like it is an all-or-none situation, either people will continue working in their occupations or automation (e.g., mechanical, software, AI, etc.) will replace them. The storyline is people are expensive and automated work can be less costly in the long run. If commercial manufacturing is a guide, automation is a preferred option from both a productivity and an ROI perspective. In order to make the productivity gains from automation similar to those seen in commercial manufacturing, there are some basic requirements and conditions that have to be met:\n<\/p>\n<ul><li> The process has to be well documented and understood, down to the execution of each step without variation, while error detection and recovery have to be designed in.<\/li>\n<li> The process has to remain static and be expected to continue over enough execution cycles to make it economically attractive to design, build, and maintain.<\/li>\n<li> Automation-compatible equipment has to be available. Custom-built components are going to be expensive and could represent a barrier to successful implementation.<\/li>\n<li> There has to be a driving need to justify the cost of automation; economics, the volume of work that has to be addressed, working with hazardous materials, and lack of educated workers are just a few of the factors that would need to be considered.<\/li><\/ul>\n<p>There are places in laboratory work where production-scale automation has been successfully implemented; life sciences applications for processes based on microplate technologies are one example. When we look at the broad scope of lab work across disciplines, most lab processes don\u2019t lend themselves to that level of automation, at least not yet. We\u2019ll get into this in more detail later. But that brings us back to the starting point: what happens to people's jobs?\n<\/p><p>In the early stages of manufacturing automation, as well as fields such as mining where work was labor intensive and repetitive, people did lose jobs when new methods of production were introduced. That shift from a human workforce to automated task execution is expanding as system designers probe markets from retail to transportation.<sup id=\"rdp-ebb-cite_ref-FreyTheFuture13_2-0\" class=\"reference\"><a href=\"#cite_note-FreyTheFuture13-2\">[1]<\/a><\/sup> Lower skilled occupations gave way first, and we find ourselves facing automation efforts that are moving up the skills ladder, most recently is the potential for automated driving, a technology that has yet to be fully embraced but is moving in that direction. The problem that leaves us with is providing displaced workers with a means of employment that gives them at least a living income, and the purpose, dignity, and self-worth that they\u2019d like to have. This is going to require significant education, and people are going to have to come to grips with the realization that education never stops.\n<\/p><p>Due to the push for increased productivity, lab work has seen some similar developments in automation. The development of automated pipettes, titration stations, auto-injectors, computer-assisted instrumentation, and automation built to support microplate technologies represent just a few places where specific tasks have been addressed. However these developments haven\u2019t moved people out of the workplace as has happened in manufacturing, mining, etc. In some cases they\u2019ve changed the work, replacing repetitive time-consuming tasks with equipment that allows lab personnel to take on different tasks. In other cases the technology addresses work that couldn\u2019t be performed in a cost-effective manner with human effort; without automation, that work might just not be feasible due to the volume of work (whose delivery might be limited by the availability of the right people, equipment, and facilities) or the need to work with hazardous materials. Automation may prevent the need for hiring new people while giving those currently working more challenging tasks.\n<\/p><p>As noted in the previous paragraph, much of the automation in lab work is at the task level: equipment designed to carry out a specific function such as Karl-Fisher titrations. Some equipment designed around microplate formats can function at both the task level and as part of user-integrated robotics system. This gives the planner useful options about the introduction of automation that makes it easier for personnel to get accustomed to automation before moving into scientific manufacturing.\n<\/p><p>Overall, laboratory people shouldn\u2019t be loosing their jobs as a result of lab automation, but they do have to be open to changes in their jobs, and that could require an investment in their education. Take someone whose current job is to carry out a lab procedure, someone who understands all aspects of the work, including troubleshooting equipment, reagents, and any special problems that may crop up. Someone else may have developed the procedure, but that person is the expert in its execution.\n<\/p><p>First of all you need these experts to help plan and test the automated systems if you decide to create that project. These would also be the best people to educate as automated systems managers; they know how the process is supposed to work and should be in a position to detect problems. If it crashes, you\u2019ll need someone who can cover the work while problems are be addressed. Secondly, if lab personnel get the idea that they are watching their replacement being installed, they may leave before the automated systems are ready. In the event of a delay, you\u2019ll have a backlog and no one to handle it.\n<\/p><p>Beyond that, people will be freed from the routine of carrying out processes and be able to address work that had been put on a back burner until it could be addressed. As we move toward automated systems, jobs will change by expansion to accommodate typical lab work, as well as the management, planning, maintenance, and evolution of laboratory automation and computing.\n<\/p><p>Automation in lab work is not an \"all or none\" situation. Processes can be structured so that the routine work is done by systems, and the analyst can spend time reviewing the results, looking for anomalies and interesting patterns, while being able to make decisions about the need for and nature of follow-on efforts.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"What_is_the_role_of_AI_and_ML_in_automation.3F\">What is the role of AI and ML in automation?<\/span><\/h3>\n<p>When we discuss automation, what we are referencing now is basic robotics and programming. AI may, and likely will, play a role in the work, but first we have to get the foundations right before we consider the next step; we need to put in the human intelligence first. Part of the issue with AI is that we don\u2019t know what it is.\n<\/p><p>Science fiction aside, many of today's applications of AI have a limited role in lab work today. Here are some examples:\n<\/p>\n<ul><li> Having a system that can bring up all relevant information on a research question\u2014a sort of super Google\u2014or a variation of IBM\u2019s Watson could have significant benefits.<\/li>\n<li> Analyzing complex data or large volumes of data could be beneficial, e.g., the analysis of radio astronomy data to find fast radio bursts (FRB). After discovering 21 FRB signals upon analyzing five hours of data, researchers at Green Bank Telescope used AI to analyze 400 terabytes of older data and detected another 100.<sup id=\"rdp-ebb-cite_ref-HsuIsIt18_3-0\" class=\"reference\"><a href=\"#cite_note-HsuIsIt18-3\">[2]<\/a><\/sup><\/li>\n<li> \"[A] team at Glasgow University has paired a machine-learning system with a robot that can run and analyze its own chemical reaction. The result is a system that can figure out every reaction that's possible from a given set of starting materials.\"<sup id=\"rdp-ebb-cite_ref-TimmerAIPlus18_4-0\" class=\"reference\"><a href=\"#cite_note-TimmerAIPlus18-4\">[3]<\/a><\/sup><\/li>\n<li> HelixAI is using Amazon's Alexa as a digital assitant for laboratory work.<sup id=\"rdp-ebb-cite_ref-HelixAIHome_5-0\" class=\"reference\"><a href=\"#cite_note-HelixAIHome-5\">[4]<\/a><\/sup><\/li><\/ul>\n<p>Note that the points above are research-based applications, not routine production environments where regulatory issues are important. While there are research applications that might be more forgiving of AI systems because the results are evaluated by human intelligence, and problematic results can be made subject to further verification, data entry systems such as voice entry have to be carefully tested and the results of that data entry verified and shown to be correct.\n<\/p><p>Pharma IQ continues to publish material on advanced topics in laboratory informatics, including articles on how labs are benefiting from new technologies<sup id=\"rdp-ebb-cite_ref-PharmaIQNewsAutom18_6-0\" class=\"reference\"><a href=\"#cite_note-PharmaIQNewsAutom18-6\">[5]<\/a><\/sup> and survey reports such as <i>AI 2020: The Future of Drug Discovery<\/i>. In that report they note<sup id=\"rdp-ebb-cite_ref-PharmaIQTheFuture17_7-0\" class=\"reference\"><a href=\"#cite_note-PharmaIQTheFuture17-7\">[6]<\/a><\/sup>:\n<\/p>\n<ul><li> \"94% of pharma professionals expect that intelligent technologies will have a noticeable impact on the pharmaceutical industry over the next two years.\"<\/li>\n<li> \"Almost one fifth of pharma professionals believe that we are on the cusp of a revolution.\"<\/li>\n<li> \"Intelligent automation and predictive analytics are expected to have the most significant impact on the industry.\"<\/li>\n<li> \"However, a lack of understanding and awareness about the benefits of AI-led technologies remain a hindrance to their implementation.\"<\/li><\/ul>\n<p>Note that these are expectations, not a reflection of current reality. That same report makes comments about the impact of AI on headcount disruption, asking, \"Do you expect intelligent enterprise technologies<sup id=\"rdp-ebb-cite_ref-8\" class=\"reference\"><a href=\"#cite_note-8\">[b]<\/a><\/sup> to significantly cut and\/or create jobs in pharma through 2020?\" Among the responses, 47 percent said they expected those technologies to do both, 40 percent said it will create new job opportunities, and 13 percent said there will be no dramatic change, with zero percent saying they expected solely job losses.<sup id=\"rdp-ebb-cite_ref-PharmaIQTheFuture17_7-1\" class=\"reference\"><a href=\"#cite_note-PharmaIQTheFuture17-7\">[6]<\/a><\/sup>\n<\/p><p>While there are high levels of expectations and hopes for results, we need to approach the idea of AI in labs with some caution. We read about examples based on machine learning (ML), for example using computer systems to recognize cats in photos, to recognized faces in a crowd, etc. We don\u2019t know how they accomplish their tasks, and we can\u2019t analyze their algorithms and decision-making. That leaves us with testing in quality, which at best is an uncertain process with qualified results (it has worked so far). One problem with testing AI systems based on ML is that they are going to continually evolve, so testing may affect the ML processes by providing a bias. It may also cause continued, redundant testing, because something we thought was evaluated was changed by the \u201cexperiences\u201d the AI based it\u2019s learning on. As one example, could the AI modify the science through process changes without our knowing because it didn\u2019t understand the science or the goals of the work?\n<\/p><p>AI is a black box with ever-changing contents. That shouldn\u2019t be taken as a condemnation of AI in the lab, but rather as a challenge to human intelligence in evaluating, proving, and applying the technology. That application includes defining the operating boundaries of an AI system. Rather than creating a master AI for a complete process, we may elect to divide the AI\u2019s area of operation into multiple, independent segments, with segment integration occurring in later stages once we are confident in their ability to work and show clear evidence of systems stability. In all of this we need to remember that our goal is the production of high-quality data and information in a controlled, predictable environment, not gee-wiz technology. One place where AI (or clever programming) could be of use is in better workflow planning, which takes into account current workloads and assignments, factors in the inevitable panic-level testing need, and, perhaps in a QC\/production environment, anticipates changes in analysis requirements based on changes in production operations.\n<\/p><p>Throughout this section I've treated \u201cAI\u201d as \u201cartificial intelligence,\u201d its common meaning. There may be a better way of looking at it for lab use as, noted in this excerpt from the October 2018 issue of Wired magazine<sup id=\"rdp-ebb-cite_ref-RossettoFight18_9-0\" class=\"reference\"><a href=\"#cite_note-RossettoFight18-9\">[7]<\/a><\/sup>:\n<\/p>\n<blockquote>Augmented intelligence. Not \u201cartificial,\u201d but how Doug Engelbart<sup id=\"rdp-ebb-cite_ref-10\" class=\"reference\"><a href=\"#cite_note-10\">[c]<\/a><\/sup> envisioned our relationship with computer: AI doesn\u2019t replace humans. It offers idiot-savant assistants that enable us to become the best humans we can be.<\/blockquote>\n<p>Augmented intelligence (AuI) is a better term for what we might experience in lab work, at least in the near future. It suggests something that is both more realistic and attainable, with the synergism that would make it, and automation, attractive to lab management and personnel\u2014a tool they can work with and improve lab operations that doesn\u2019t carry the specter of something going on that they don\u2019t understand or control. OPUS\/SEARCH from Bruker might be just such an entry in this category.<sup id=\"rdp-ebb-cite_ref-BrukerOPUS_11-0\" class=\"reference\"><a href=\"#cite_note-BrukerOPUS-11\">[8]<\/a><\/sup> AuI may serve as a first-pass filter for large data sets\u2014as noted in the radio astronomy and chemistry examples noted earlier\u2014reducing those sets of data and information to smaller collections that human intelligence can\/should evaluate. However, that does put a burden on the AuI to avoid excessive false positives or negatives, something that can be adjusted over time.\n<\/p><p>Beyond that there is the possibility of more cooperative work between people and AuI systems. An article in <i>Scientific American<\/i> titled \u201cMy Boss the Robot\u201d<sup id=\"rdp-ebb-cite_ref-BourneMyBoss13_12-0\" class=\"reference\"><a href=\"#cite_note-BourneMyBoss13-12\">[9]<\/a><\/sup> describes the advantage of a human-robot team, with the robot doing the heavy work and the human\u2014under the robots guidance\u2014doing work he was more adept at, verses a team of experts with the same task. The task, welding a Humvee frame, was competed by the human machine pair in 10 hours at a cost of $1,150; the team of experts took 89 hours and a cost of $7,075. That might translate into terms of laboratory work by having a robot do routine, highly repetitive tasks and the analyst overseeing the operation and doing higher-level analysis of the results.\n<\/p><p>Certainly, AI\/AuI is going to change over time as programming and software technology becomes more sophisticated and capable; today\u2019s example of AuI might be seen as tomorrow\u2019s clever software. However, a lot depends on the experience of the user.\n<\/p><p>There is something important to ask about laboratory technology development, and AI in particular: is the direction of development going to be the result of someone\u2019s innovation that people look at and embrace, or will it be the result of a deliberate choice of lab people saying \u201cthis is where we need to go, build systems that will get us there\u201d? The difference is important, and lab managers and personnel need to be in control of the planning and implementation of systems.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Where_do_we_find_the_resources_to_carry_out_automation_projects.2Fprograms.3F\">Where do we find the resources to carry out automation projects\/programs?<\/span><\/h3>\n<p>Given the potential scope of work, you may need people with skills in programming, robotics, instrumentation, and possibly mechanical or electrical engineering if off-the-shelf components aren\u2019t available. The biggest need is for people who can do the planning and optimization that is needed as you move from manual to semi- or fully-automated systems, particularly specialists in process engineering who can organize and plan the work, including the process controls and provision for statistical process control.\n<\/p><p>We need to develop people who are well versed in laboratory work and the technologies that can be applied to that work, as assets in laboratory automation development and planning. In the past, this role has been filled with lab personnel having an interest in the subject, IT people willing to extend their responsibilities, and\/or outside consultants. A 2017 report by Salesforce Research states \"77% of IT leaders believe IT functions as an extension\/partner of business units rather than as a separate function.\"<sup id=\"rdp-ebb-cite_ref-SalesForceSecondAnn17_13-0\" class=\"reference\"><a href=\"#cite_note-SalesForceSecondAnn17-13\">[10]<\/a><\/sup> The report makes no mention of laboratory work or manufacturing aside from those being functions within businesses surveyed. Unless a particular effort is made, IT personnel rarely have the backgrounds needed to meet the needs of lab work. In many cases, they will try and fit lab needs into software they are already familiar with, rather then extend their backgrounds into new computational environments. Office and pure database applications are easily handled, but when we get to the lab bench, it's another matter entirely.\n<\/p><p>The field is getting complex enough that we need people whose responsibilities span both science and technology. This subject is discussed in the webinar series <i><a href=\"https:\/\/www.limswiki.org\/index.php\/LII:A_Guide_for_Management:_Successfully_Applying_Laboratory_Systems_to_Your_Organization%27s_Work\" title=\"LII:A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work\" class=\"wiki-link\" data-key=\"00b300565027cb0518bcb0410d6df360\">A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work<\/a><\/i>, Part 5 \"Supporting Laboratory Systems.\"\n<\/p>\n<h3><span class=\"mw-headline\" id=\"What_equipment_would_we_need_for_automated_processes.2C_and_will_it_be_different_that_what_we_currently_have.3F\">What equipment would we need for automated processes, and will it be different that what we currently have?<\/span><\/h3>\n<p>This is an interesting issue and it directly addresses the commitment labs have to automation, particularly robotics. In the early days of lab automation when Zymark (Zymate and Benchmate), <a href=\"https:\/\/www.limswiki.org\/index.php\/PerkinElmer_Inc.\" title=\"PerkinElmer Inc.\" class=\"wiki-link\" data-key=\"dabda40785b60866d056709e611512f8\">Perkin Elmer<\/a>, and Hewlett Packard (ORCA) were the major players in the market, the robot had to adapt to equipment that was designed for human use: standard laboratory equipment. They did that through special modifications and the use of different grippers to handle test tubes, beakers, and flasks. While some companies wanted to test the use of robotics in the lab, they didn\u2019t want to invest in equipment that could only be used with robots; they wanted lab workers to pick up where the robots left off in case the robots didn\u2019t work.\n<\/p><p>Since then, equipment has evolved to support automation more directly. In some cases it is a device (e.g., a balance, pH meter, etc.) that has front panel human operator capability and rear connectors for computer communications. Liquid handling systems have seen the most advancement through the adoption of microplate formats and equipment designed to work with them. However, the key point is standardization of the sample containers. Vials and microplates lend themselves to a variety of automation devices, from sample processing to auto-injectors\/samplers. The issue is getting the samples into those formats.\n<\/p><p>One point that labs, in any scientific discipline, have to come to grips with is the commitment to automation. That commitment isn\u2019t going to be done on a lab-wide basis, but on a procedure-by-procedure basis. Full automation may not be appropriate for all lab work, whereas partial automation may be a better choice, and in some cases no automation may be required (we\u2019ll get into that later). The point that needs to be addressed is the choice of equipment. In most cases, equipment is designed for use by people, with options for automation and electronic communications. However, if you want to maximize throughput, you may have to follow examples from manufacturing and commit to equipment that is only used by automation. That will mean a redesign of the equipment, a shared risk for both the vendors and the users. The upside to this is that equipment can be specifically designed for a task, be more efficient, have the links needed for integration, use less material, and, more likely, take up less space. One example is the microplate, allowing for tens, hundreds, or thousands (depending on the plate used) of sample cells in a small space. What used to take many cubic feet of space as test tubes (the precursor to using microplates) is now a couple of cubic inches, using much less material and working space. Note, however, that while microplates are used by lab personnel, their use in automated systems provides greater efficiency and productivity.\n<\/p><p>The idea of equipment used only in an automated process isn\u2019t new. The development and commercialization of segmented flow analyzers\u2014initially by Technicon in the form of the AutoAnalyzers for general use, and the SMA (Sequential Multiple Analyzer) and SMAC (Sequential Multiple Analyzer with Computer) in clinical markets\u2014improved a lab's ability to process samples. These systems were phased out with new equipment that consumed less material. Products like these are being provided by Seal Analytical<sup id=\"rdp-ebb-cite_ref-SealAnal_14-0\" class=\"reference\"><a href=\"#cite_note-SealAnal-14\">[11]<\/a><\/sup> for environmental work and Bran+Luebbe (a division of SPX Process Equipment in Germany).<sup id=\"rdp-ebb-cite_ref-BranLuebbe_15-0\" class=\"reference\"><a href=\"#cite_note-BranLuebbe-15\">[12]<\/a><\/sup>\n<\/p><p>The issue in committing to automated equipment is that vendors and users will have to agree on equipment specifications and use them within procedures. One place this has been done successfully is in clinical chemistry labs. What other industry workflows could benefit? Do the vendors lead or do the users drive the issue? Vendors need to be convinced that there is a viable market for product before making an investment, and users need to be equally convinced that they will succeed in applying those products. In short, procedures that are important to a particular industry have to be identified, and both users and vendors have to come together to develop automated procedure and equipment specifications for products. This has been done successfully in clinical chemistry markets to the extent that equipment is marketed for use as validated for particular procedures.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"What_role_does_a_LES_play_in_laboratory_automation.3F\">What role does a LES play in laboratory automation?<\/span><\/h3>\n<p>Before ELNs settled into their current role in laboratory work, the initial implementations differed considerably from what we have now. LabTech Notebook was released in 1986 (discontinued in 2004) to provide communications between computers and devices that used RS-232 serial communications. In the early 2000s SmartLab from Velquest was the first commercial product to carry the \"electronic laboratory notebook\" identifier. That product became a stand-alone entry in the laboratory execution system (LES) market; since its release, the same conceptual functionality has been incorporated into LIMS and ELNs that fit the more current expectation for an ELN.\n<\/p><p>At it\u2019s core, LES are scripted test procedures that an analyst would follow to carry out a laboratory method, essentially functioning as the programmed execution of a lab process. Each step in a process is described, followed exactly, and provision is made within the script for data collection. In addition, the LES can\/will (depending on the implementation; \"can\" in the case of SmartLab) check to see if the analyst is qualified to carry out the work and that the equipment and reagents are current, calibrated, and suitable for use. The systems can also have access to help files that an analyst can reference if there are questions about how to carry out a step or resolve issues. Beyond that, the software had the ability to work with lab instruments and automatically acquire data either through direct interfaces (e.g., balances, pH meters, etc.) or through parsing PDF files of instrument reports.\n<\/p><p>There are two reasons that these systems are attractive. First, they provide for a rigorous execution of a process with each step being logged as it is done. Second, that log provides a regulatory inspector with documented evidence that the work was done properly, making it easier for the lab to meet any regulatory burden.\n<\/p><p>Since the initial development of SmartLab, that product has changed ownership and is currently in the hands of <a href=\"https:\/\/www.limswiki.org\/index.php\/Dassault_Syst%C3%A8mes_SA\" title=\"Dassault Syst\u00e8mes SA\" class=\"wiki-link\" data-key=\"1be69bd73e35bc3db0c3229284bf9416\">Dassault Syst\u00e8mes<\/a> as part of the BIOVIA product line. As noted above, LIMS and ELN vendors have incorporated similar functionality into their products. Using those features requires \u201cscripting\u201d (in reality, software development), but it does allow the ability to access the database structures within those products. The SmartLab software needed programmed interfaces to other vendors' LIMS and ELNs to gain access to the same information.\n<\/p>\n<h4><span class=\"mw-headline\" id=\"What_does_this_have_to_do_with_automation.3F\">What does this have to do with automation?<\/span><\/h4>\n<p>When we think about automated systems, particularly full-automation with robotic support, it is a programmed process from start to finish. The samples are introduced at the start, and the process continues until the final data\/information is reported and stored. These can be large scale systems using microplate formats, including tape-based systems from Douglas Scientific<sup id=\"rdp-ebb-cite_ref-DouglasScientificArrayTape_16-0\" class=\"reference\"><a href=\"#cite_note-DouglasScientificArrayTape-16\">[13]<\/a><\/sup>, programmable autosamplers such as those from <a href=\"https:\/\/www.limswiki.org\/index.php\/Agilent_Technologies,_Inc.\" title=\"Agilent Technologies, Inc.\" class=\"wiki-link\" data-key=\"dcea1a676a012bcbe3af9562dd17f8a0\">Agilent<\/a><sup id=\"rdp-ebb-cite_ref-Agilent1200Series_17-0\" class=\"reference\"><a href=\"#cite_note-Agilent1200Series-17\">[14]<\/a><\/sup>, or systems built around robotics arms from a variety of vendors that move samples from one station to another.\n<\/p><p>Both LES and the automation noted in the previous paragraph have the following point in common: there is a strict process that must be followed, with no provision for variation. The difference is that in one case that process is implemented completely through the use of computers, as well as electronic and mechanical equipment. In the other case, the process is being carried out by lab personnel using computers, as well as electronic and mechanical lab equipment. In essence, people take the place of mechanical robots, which conjures up all kinds of images going back to the 1927 film <i>Metropolis<\/i>.<sup id=\"rdp-ebb-cite_ref-18\" class=\"reference\"><a href=\"#cite_note-18\">[d]<\/a><\/sup> Though the LES represents a step toward more sophisticated automation, both methods still require:\n<\/p>\n<ul><li> programming, including \u201cscripting\u201d (the LES methods are a script that has to be followed);<\/li>\n<li> validated, proven processes; and<\/li>\n<li> qualified staff, though the qualifications differ. (In both cases they have to be fully qualified to carry out the process in question. However in the full automation case, they will require more education on running, managing, and troubleshooting the systems.)<\/li><\/ul>\n<p>In the case of full automation, there has to be sufficient justification for the automation of the process, including sufficient sample processing. The LES-human implementation can be run for a single sample if needed, and the operating personnel can be trained on multiple procedures, switching tasks as needed. Electro-mechanical automation would require a change in programming, verification that the system is operating properly, and may require equipment re-configuration. Which method is better for a particular lab depends on trade-offs between sample load, throughput requirements, cost, and flexibility. People are adaptable, easily moving between tasks, whereas equipment has to be adapted to a task.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"How_do_we_go_about_planning_for_automation.3F\">How do we go about planning for automation?<\/span><\/h3>\n<p>There are three forms of automation to be considered:\n<\/p>\n<ol><li> No automation \u2013 Instead, the lab relies on lab personnel to carry out all steps of a procedure.<\/li>\n<li> Partial automation \u2013 Automated equipment is used to carry out steps in a procedure. Given the current state of laboratory systems, this is the most prevalent since most lab equipment has computer components in them to facilitate their use.<\/li>\n<li> Full automation - The entire process is automated. The definition of \u201centire\u201d is open to each labs interpretation and may vary from one process to another. For example, some samples may need some handing before they are suitable for use in a procedure. That might be a selection process from a freezer, grinding materials prior to a solvent extraction, and so on, representing cases where the equipment available isn\u2019t suitable for automated equipment interaction. One goal is to minimize this effort since it can put a limit on the productivity of the entire process. This is also an area where negotiation between the lab and the sample submitter can be useful. Take plastic pellets for example, which often need to be ground into a course powder before they can be analyzed; having the submitter provide them in this form will reduce the time and cost of the analysis. Standardizing on the sample container can also facilitate the analysis (having the lab provide the submitter with standard sample vials using barcodes or RFID chips can streamline the process).<\/li><\/ol>\n<p>One common point that these three forms share is a well-described method (procedure, process) that needs to be addressed. That method should be fully developed, tested, and validated. This is the reference point for evaluating any form of automation (Figure 1).\n<\/p><p><br \/>\n<a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig1_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"684c380f41ae1fa9a0e3ed8844cc8c6d\"><img alt=\"Fig1 Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/3\/31\/Fig1_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 1.<\/b> Items to be considered in automating systems<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p>The documentation for the chosen method should include the bulleted list of items from Figure 1, as they describe the science aspects of the method. The last four points are important. The method should be validated since the manual procedure is a reference point for determining if the automated system is producing useful results. The reproducibility metric offers a means of evaluating at least one expected improvement in an automated system; you\u2019d expect less variability in the results. This requires a set of reference sample materials that can be repeatedly evaluated to compare the manual and automated systems, and to periodically test the methods in use to ensure that there aren\u2019t any trends developing that would compromise the method\u2019s use. Basically, this amounts to statistical quality control on the processes.\n<\/p><p>The next step is to decide what improvements you are looking for in an automated system: increased throughput, lower cost of operation, the ability to off-load human work, reduced variability, etc. In short, what are your goals?\n<\/p><p>That brings us to the matter of project planning. We\u2019re not going to go into a lot of depth in this piece about project planning, as there are a number of references<sup id=\"rdp-ebb-cite_ref-19\" class=\"reference\"><a href=\"#cite_note-19\">[e]<\/a><\/sup> on the subject, including material produced by the former Institute for Laboratory Automation.<sup id=\"rdp-ebb-cite_ref-20\" class=\"reference\"><a href=\"#cite_note-20\">[f]<\/a><\/sup> There are some aspects of the subject that we do need to touch on, however, and they include:\n<\/p>\n<ul><li> justifying the project and setting expectations and goals;<\/li>\n<li> analyzing the process;<\/li>\n<li> scheduling automation projects; and<\/li>\n<li> budgeting.<\/li><\/ul>\n<h4><span class=\"mw-headline\" id=\"Justification.2C_expectations.2C_and_goals\">Justification, expectations, and goals<\/span><\/h4>\n<p>Basically why are you doing this, what do you expect to gain? What arguments are you going to use to justify the work and expense involved in the project? How will you determine if the project is successful?\n<\/p><p>Fundamentally, automation efforts are about productivity and the bulleted items noted in the introduction of this piece, repeated below with additional commentary:\n<\/p>\n<ul><li> Lower costs per test, and better control over expenditure: These can result from a reduction in labor and materials costs, including more predictable and consistent reagent usage per test.<\/li>\n<li> Stronger basis for better workflow planning: Informatics systems can provide better management over workloads and resource allocation, while key performance indicators can show where bottlenecks are occurring or if samples are taking too long to process. These can be triggers for procedure automation to improve throughput.<\/li>\n<li> Reproducibility: The test results from automated procedures can be expected to be more reproducible by eliminating the variability that is typical of steps executed by people. Small variation in dispensing reagents, for example, could be eliminated.<\/li>\n<li> Predictability: The time to completion for a given test is more predictable in automated programs; once the process starts it keeps going without interruptions that can be found in human centered activities<\/li>\n<li> Tighter adherence to procedures: Automated procedures have no choice but to be consistent in procedure execution; that is what programming and automation is about.<\/li><\/ul>\n<p>Of these, which are important to your project? If you achieved these goals, what would it mean to your labs operations and the organization as a whole; this is part of the justification for carrying out the projects.\n<\/p><p>As noted earlier, there are several things to consider in order to justify a project. First, there has to be a growing need that supports a procedures automation, one that can\u2019t be satisfied by other means that could include adding people, equipment, and lab space, or outsourcing the work (with the added burden of insuring data quality and integrity, and integrating that work with the lab\u2019s data\/information). Second, the cost of the project must be balanced by it\u2019s benefits. This includes any savings in cost, people (not reducing headcount, but avoiding new hires), material, and equipment, as well as the improvement of timeliness of results and overall lab operations. Third, when considering project justification, the automated process\u2019s useful lifetime has to be long enough to justify the development work. And finally, the process has to be stable so that you aren\u2019t in a constant re-development situation (this differs from periodic upgrades and performance improvements, EVOP in manufacturing terms). One common point of failure in projects is changes in underlying procedures; if the basic process model changes, you are trying to hit a moving target. That ruins schedules and causes budgets to inflate.\n<\/p><p>This may seem like a lot of things to think about for something that could be as simple as perhaps moving from manual pipettes to automatic units, but that just means the total effort to do the work will be small. However it is still important since it impacts data quality and integrity, and your ability to defend your results should they be challenged. And, by the way, the issue of automated pipettes isn\u2019t simple; there is a lot to consider in properly specifying and using these products.<sup id=\"rdp-ebb-cite_ref-21\" class=\"reference\"><a href=\"#cite_note-21\">[g]<\/a><\/sup>\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Analyzing_the_process\">Analyzing the process<\/span><\/h4>\n<p>Assuming that you have a well-described, thoroughly tested and validated procedure, that process has to be analyzed for optimization and suitability for automation. This is an end-to-end evaluation, not just a examination of isolated steps. This is an important point. Looking at a single step without taking into account the rest of the process may improve that portion of the process but have consequences elsewhere.\n<\/p><p>Take a common example: working in a testing environment where samples are being submitted by outside groups (Figure 2).\n<\/p><p><br \/>\n<a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig2_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"e1944129f376f676452d5befa53e5a78\"><img alt=\"Fig2 Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/d\/d2\/Fig2_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 2.<\/b> Lab sample processing, initial data entry through results<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p>Most LIMS will permit sample submitters (with appropriate permissions) to enter the sample description information directly into the LIMS, reducing some of the clerical burden. Standardizing on sample containers, with barcodes, reduces the effort and cost in some aspects of sample handling. A barcode scanner could be used to scan samples as they arrive into the lab, letting the system know that they are ready to be tested.\n<\/p><p>That brings us to an evaluation of the process as a whole, as well as an examination of the individual steps in the procedure. As shown in Figure 1, automation can be done in one of two ways: automating the full process or automating individual steps. Your choice depends on several factors, not the least of which is your comfort level and confidence in adopting automation as a strategy for increasing productivity. For some, concentrating on improvements in individual steps is an attractive approach. The cost and risk may be lower and if a problem occurs you can always backup to a fully manual implementation until they are resolved.\n<\/p><p>Care does have to be taken in choosing which steps to improve. From one perspective, you\u2019d want to do the step-wise implementation of automation as close to the end of the process as possible. The problem with doing it earlier is that you may create a backup in later stages of the process. Optimizing step 2, for example, doesn\u2019t do you much good if step 3 is overloaded and requires more people, or additional (possibly unplanned) automation to relieve a bottleneck there. In short, before you automate or improve a given step, you need to be sure that downstream processing can absorb the increase in materials flow. In addition, optimizing all the individual steps, one at time, doesn\u2019t necessarily add up to a well-designed full system automation. The transition between steps may not be as effective or efficient if the system were evaluated as a whole. If the end of the process is carried out by commercial instrumentation, the ability to absorb more work is easier since most of these systems are automated with computer data acquisition and processing, and many have auto-samplers available to accumulate samples that can be processed automatically. Some of those auto-samplers have built in robotics for common sample handling functions. If the workload builds, additional instruments can pick up the load, and equipment such as <a href=\"https:\/\/www.limswiki.org\/index.php\/Baytek_International,_Inc.\" title=\"Baytek International, Inc.\" class=\"wiki-link\" data-key=\"92bd2781da39f29dfafa73d5f07fd530\">Baytek International\u2019s<\/a> TurboTube<sup id=\"rdp-ebb-cite_ref-BaytekiPRO_22-0\" class=\"reference\"><a href=\"#cite_note-BaytekiPRO-22\">[15]<\/a><\/sup> can accumulate sample vials in a common system and route them to individual instruments for processing.\n<\/p><p>Another consideration for partial automation is where the process is headed in the future. If the need for the process persists over a long period of time, will you eventually get to the point of needing to redo the automation to an integrated stream? If so, is it better to take the plunge early on instead of continually expending resources to upgrade it?\n<\/p><p>Other considerations include the ability to re-purpose equipment. If a process isn\u2019t used full-time (a justification for partial automation) the same components may be used in improving other processes. Ideally, if you go the full-process automation route, you\u2019ll have sufficient sample throughput to keep it running for an extended period of time, and not have to start and stop the system as samples accumulate. A smoothly running slower automation process is better than a faster system that lies idle for significant periods of time, particularly since startup and shutdown procedures may diminish the operational cost savings in both equipment use and people\u2019s time.\n<\/p><p>All these points become part of both the technical justification and budget requirements.\n<\/p><p><b>Analyzing the process: Simulation and modeling<\/b>\n<\/p><p>Simulation and modeling have been part of science and engineering for decades, supported by ever-increasing powerful computing hardware and software. Continuous systems simulations have shown us the details of how machinery works, how chemical reactions occur, and how chromatographic systems and other instrumentation behaves.<sup id=\"rdp-ebb-cite_ref-JoyceComputer18_23-0\" class=\"reference\"><a href=\"#cite_note-JoyceComputer18-23\">[16]<\/a><\/sup> There is another aspect to modeling and simulation that is appropriate here.\n<\/p><p>Discrete-events simulation (DES) is used to model and understand processes in business and manufacturing applications, evaluating the interactions between service providers and customers, for example. One application of DES is to determine the best way to distribute incoming customers to a limited number of servers, taking into account that not all customers have the same needs; some will tie up a service provider a lot longer than others, as represented by the classic bank teller line problem. That is one question that discrete systems can analyze. This form of simulation and modeling is appropriate to event-driven processes where the action is focused on discrete steps (like materials moving from one workstation to another) rather than as a continuous function of time (most naturally occurring systems fall into this category, e.g., heat flow and models using differential equations).\n<\/p><p>The processes in your lab can be described and analyzed via DES systems.<sup id=\"rdp-ebb-cite_ref-CostigliolaSimul17_24-0\" class=\"reference\"><a href=\"#cite_note-CostigliolaSimul17-24\">[17]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-MengImprov13_25-0\" class=\"reference\"><a href=\"#cite_note-MengImprov13-25\">[18]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-JunApplic99_26-0\" class=\"reference\"><a href=\"#cite_note-JunApplic99-26\">[19]<\/a><\/sup> Those laboratory procedures are a sequence of steps, each having a precursor, variable duration, and following step until the end of the process is reached; this is basically the same as a manufacturing operation where modeling and simulation have been used successfully for decades. DES can be used to evaluate those processes and ask questions that can guide you on the best paths to take in applying automation technologies and solving productivity or throughput problems. For example:\n<\/p>\n<ul><li> What happens if we tighten up the variability in a particular step; how will that affect the rest of the system?<\/li>\n<li> What happens at the extremes of the variability in process steps; does it create a situation where samples pile up?<\/li>\n<li> How much of a workload can the process handle before one step becomes saturated with work and the entire system backs up?<\/li>\n<li> Can you introduce an alternate path to process those samples and avoid problems (e.g., if samples are held for too long in one stage, do they deteriorate)?<\/li>\n<li> Can the output of several parallel slower procedures be merged into a feed stream for a common instrumental technique?<\/li><\/ul>\n<p>In complex procedures some steps may be sensitive to small delays, and DES can help test and uncover them. Note that setting up these models will require the collection of a lot of data about the processes and their timing, so this is not something to be taken casually.\n<\/p><p>Previous research<sup id=\"rdp-ebb-cite_ref-JoyceComputer18_23-1\" class=\"reference\"><a href=\"#cite_note-JoyceComputer18-23\">[16]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-CostigliolaSimul17_24-1\" class=\"reference\"><a href=\"#cite_note-CostigliolaSimul17-24\">[17]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-MengImprov13_25-1\" class=\"reference\"><a href=\"#cite_note-MengImprov13-25\">[18]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-JunApplic99_26-1\" class=\"reference\"><a href=\"#cite_note-JunApplic99-26\">[19]<\/a><\/sup> suggests only a few ideas where simulation can be effective, including one where an entire labs operation\u2019s was evaluated. Models that extensive can be used to not only look at procedures, but also the introduction of informatics systems. This may appear to be a significant undertaking, and it can be depending on the complexity of the lab processes. However, simple processes can be initially modeled on spreadsheets to see if more significant effort is justified. Operations research, of which DES is a part, has been usefully applied in production operations to increase throughput and improve ROI. It might be successfully applied to some routine production oriented lab work.\n<\/p><p>Most lab processes are linear in their execution, one step following another, with the potential for loop-backs should problems be recognized with samples, reagents (e.g., being out-of-date, doesn\u2019t look right, need to obtain new materials), or equipment (e.g., not functioning properly, out of calibration, busy due to other work). On one level, the modeling of a manually implemented process should appear to be simple: each step takes a certain amount of time. If you add up the times, you have a picture of the process execution through time. However, the reality is quite different if you take into account problems (and their resolution) that can occur in each of those steps. The data collection used to model the procedure can change how that picture looks and your ability to improve it. By monitoring the process over a number of iterations, you can find out how much variation there is in the execution time for each step and whether or not the variation is a normal distribution or skewed (e.g., if one step is skewed, how does it impact others?).\n<\/p><p>Questions to ask about potential problems that could occur at each step include:\n<\/p>\n<ul><li> How often do problems with reagents occur and how much of a delay does that create?<\/li>\n<li> Is instrumentation always in calibration (do you know?), are there operational problems with devices and their control systems (what are the ramifications?), are procedures delayed due to equipment being in use by someone else, and how long does it take to make changeovers in operating conditions?<\/li>\n<li> What happens to the samples; do they degrade over time? What impact does this have on the accuracy of results and their reproducibility?<\/li>\n<li> How often are workflows interrupted by the need to deal with high-priority samples, and what effect does it have on the processing of other samples?<\/li><\/ul>\n<p>Just the collection of data can suggest useful improvements before there are any considerations for automation, and perhaps negating the need for it. The answer to a lab\u2019s productivity might be as simple as adding another instrument if that is a bottleneck. It might also suggest that an underutilized device might be more productive if sample preparation for different procedures workflows were organized differently. Underutilization might be a consequence of the amount of time needed to prepare the equipment for service: doing so for one sample might be disproportionately time consuming (and expensive) and cause other samples to wait until there were enough of them to justify the preparation. It could also suggest that some lab processes should be outsourced to groups that have a more consistent sample flow and turn-around time (TAT) for that technique. Some of these points are illustrated in Figures 3a and 3b below.\n<\/p><p><br \/>\n<a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig3a_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"b54669998fa4961ccecbfd829e32d89d\"><img alt=\"Fig3a Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/a\/af\/Fig3a_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 3a.<\/b> Simplified process views versus some modeling considerations. Note that the total procedure execution time is affected by the variability in each step, plus equipment and material availability delays; these can change from one day to the next in manual implementations.<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p><a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig3b_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"dd6e3ce511391ee3f325577fdb4f9ca8\"><img alt=\"Fig3b Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/e\/eb\/Fig3b_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 3b.<\/b> The execution times of each step include the variable execution times of potential issues that can occur in each stage. Note that because each factor has a different distribution curve, the total execution time has a much wider variability than the individual factors.<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p>How does the simulation system work? Once you have all the data set up, the simulation runs thousands of times using random number generators to pick out variables in execution times for each component in each step. For example, if there is a one-in-ten chance a piece of equipment will be in use when needed, 10% of the runs will show that with each one picking a delay time based on the input delay distribution function. With a large number of runs, you can see where delays exist and how they impact the overall processes behavior. You can also adjust the factors (what happens if equipment delays are cut in half) and see the effect of doing that. By testing the system, you can make better judgments on how to apply your resources.\n<\/p><p>Some of the issues that surface may be things that lab personnel know about and just deal with. It isn\u2019t until the problems are looked at that the impact on operations are fully realized and addressed. Modeling and simulation may appear to be overkill for lab process automation, something reserved for large- scale production projects. The physical size of the project is not the key factor, it is the complexity of the system that matters and the potential for optimization.\n<\/p><p>One benefit of a well-structured simulation of lab processes is that it would provide a solid basis for making recommendations for project approval and budgeting. The most significant element in modeling and simulation is the initial data collection, asking lab personnel to record the time it takes to carry out steps. This isn\u2019t likely to be popular if they don\u2019t understand why it is being done and what the benefits will be to them and the lab; accurate information is essential. This is another case where \u201cbad data is worse than no data.\u201d\n<\/p><p><b>Guidleines for process automation<\/b>\n<\/p><p>There are two types of guidelines that will be of interest to those conducting automation work: those that help you figure out what to do and how to do it, and those that must be met to satisfy regulatory requirements (both those evaluated by internal or external groups or organizations).\n<\/p><p>The first is going to depend on the nature of the science and automation being done to support it. Equipment vendor community support groups can be of assistance. Additionally, professional groups like the Pharmaceutical Research and Manufacturers of America (PhRMA), International Society for Pharmaceutical Engineering (ISPE), and Parenteral Drug Association (PDA) in the pharmaceutical and biotechnology industrues, with similar organizations in other industries and other countries. This may seem like a large jump from laboratory work, but it is appropriate when we consider the ramification of full-process automation. You are essentially developing a manufacturing operation on a lab bench, and the same concerns that large-scale production have also apply here; you have to ensure that the process is maintained and in control. The same is true of manual or semi-automated lab work, but it is more critical in fully-automated systems because of the potential high volume of results that can be produced.\n<\/p><p>The second set is going to consist of regulatory guidelines from groups appropriate to your industry: the <a href=\"https:\/\/www.limswiki.org\/index.php\/Food_and_Drug_Administration\" title=\"Food and Drug Administration\" class=\"wiki-link\" data-key=\"e2be8927071ac419c0929f7aa1ede7fe\">Food and Drug Administration<\/a> (FDA), <a href=\"https:\/\/www.limswiki.org\/index.php\/United_States_Environmental_Protection_Agency\" title=\"United States Environmental Protection Agency\" class=\"wiki-link\" data-key=\"877b052e12328aa52f6f7c3f2d56f99a\">Environmental Protection Agency<\/a> (EPA), and <a href=\"https:\/\/www.limswiki.org\/index.php\/International_Organization_for_Standardization\" title=\"International Organization for Standardization\" class=\"wiki-link\" data-key=\"116defc5d89c8a55f5b7c1be0790b442\">International Organization for Standardization<\/a> (ISO), as well as international groups (e.g., <a href=\"https:\/\/www.limswiki.org\/index.php\/Good_Automated_Manufacturing_Practice\" title=\"Good Automated Manufacturing Practice\" class=\"wiki-link\" data-key=\"a0f3d9c5bc4e330dbaec137fbe7f5dbb\">GAMP<\/a>, <a href=\"https:\/\/www.limswiki.org\/index.php\/Good_Automated_Laboratory_Practices\" title=\"Good Automated Laboratory Practices\" class=\"wiki-link\" data-key=\"bef4ea1fa3e792ccf7471f9f09b804e6\">GALP<\/a>) etc. The interesting point is that we are looking at a potentially complete automation scheme for a procedure; does that come under manufacturing or laboratory? The likelihood is that laboratory guidelines will apply since the work is being done within the lab's footprint; however, there are things that can be learned from their manufacturing counterparts that may assist in project management and documentation. One interesting consideration is what happens when fully automated testing, such as on-line analyzers, becomes integrated with both the lab and production or process control data\/information streams. Which regulatory guidelines apply? It may come down to who is responsible for managing and supporting those systems.\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Scheduling_automation_projects\">Scheduling automation projects<\/span><\/h4>\n<p>There are two parts to the schedule issue: how long is it going to take to compete the project (dependent on the process and people), and when do you start? The second point will be addressed here.\n<\/p><p>The timing of an automated process coming online is important. If it comes on too soon, there may not be enough work to justify it\u2019s use, and startup\/shutdown procedures may create more work than the system saves. If it comes too late, people will be frustrated with a heavy workload while the system that was supposed to provide relief is under development. \n<\/p><p>In Figure 4, the blue line represents the growing need for sample\/material processing using a given laboratory procedure. Ideally, you\u2019d like the automated version to be available when that blue line crosses the \u201cautomation needed on-line\u201d level of processing requirements; this the point where the current (manual?) implementation can no longer meet the demands of sample throughput requirements.\n<\/p><p><br \/>\n<a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig4_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"a92c905b5cb118443f1fe9176f6b38f5\"><img alt=\"Fig4 Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/a\/a8\/Fig4_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 4.<\/b> Timing the development of an automated system<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p>Those throughput limits are something you are going to have to evaluate and measure on a regular basis and use to make adjustments to the planning process (accelerating or slowing it as appropriate). How fast is the demand growing and at what point will your current methods be overwhelmed? Hiring more people is one option, but then the lab's operating expenses increase due to the cost of people, equipment, and lab space.\n<\/p><p>Once we have an idea of when something has to be working, we can begin the process of planning; note: the planning can begin at any point, it would be good to get the preliminaries done as soon as a manual process is finalized so that you have an idea of what you\u2019ll be getting into. Those preliminaries include looking at equipment that might be used (keeping track of its development), training requirements, developer resources, and implementation strategies, all of which would be updated as new information becomes available. The \u201cwe\u2019ll-get-to-it-when-we-need-it\u201d approach is just going to create a lot of stress and frustration.\n<\/p><p>You need to put together a first-pass project plan so that you can detail what you know, and more importantly what you don\u2019t know. The goal is to have enough information, updated as noted above, so that you can determine if an automated solution is feasible, make an informed initial choice between full and partial automation, and have a timeline for implementation. Any time estimate is going to be subject to change as you gather information and refine your implementation approach. The point of the timeline is to figure out how long the yellow box in Figure 4 is because that is going to tell you how much time you have to get the plan together and working; it is a matter of setting priorities and recognizing what they are. The time between now and the start of the yellow box is what you have to work with for planning and evaluating plans, and any decisions that are needed before you begin, including corporate project management requirements and approvals.\n<\/p><p>Those plans have to include time for validation and the evaluation of the new implementation against the standard implementation. Does it work? Do we know how to use and maintain it? And are people educated in its use? Is there documentation for the project?\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Budgeting\">Budgeting<\/span><\/h4>\n<p>At some point, all the material above and following this section comes down to budgeting: how much will it cost to implement a program and is it worth it? Of the two points, the latter is the one that is most important. How do you go about that? (Note: Some of this material is also covered in the webinar series <i><a href=\"https:\/\/www.limswiki.org\/index.php\/LII:A_Guide_for_Management:_Successfully_Applying_Laboratory_Systems_to_Your_Organization%27s_Work\" title=\"LII:A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work\" class=\"wiki-link\" data-key=\"00b300565027cb0518bcb0410d6df360\">A Guide for Management: Successfully Applying Laboratory Systems to Your Organization's Work<\/a><\/i> in the section on ROI.)\n<\/p><p>What a lot of this comes down to is explaining and justifying the choices you\u2019ve made in your project proposal. We\u2019re not going to go into a lot of depth, but just note some of the key issues:\n<\/p>\n<ul><li> Did you choose full or partial automation for your process?<\/li>\n<li> What drove that choice? If in your view it would be less expensive than the full automation of a process, how long will it be until the next upgrade is needed to another stage?<\/li>\n<li> How independent are the potential, sequential implementation efforts that may be undertaken in the future? Will there be a need to connect them, and if so, how will the incremental costs compare to just doing it once and getting it over with?<\/li><\/ul>\n<p>There is a tendency in lab work to treat problems and the products that might be used to address them in isolation. You see the need for a LIMS or ELN, or an instrument data system, and the focus is on those issues. Effective decisions have to consider both the immediate and longer-term aspects of a problem. If you want to get access to a LIMS, have you considered how it will affect other aspects of lab work such as connecting instrument to it?\n<\/p><p>The same holds true for partial automation as a solution to a lab process productivity problem. While you are addressing a particular step, should you be looking at the potential for synergism by addressing other concerns. Modeling and simulations of processes can help resolve that issue.\n<\/p><p>Have you factored in the cost of support and education? The support issue needs to address the needs of lab personnel in managing the equipment and the options for vendor support, as well as the impact on IT groups. Note that the IT group will require access to vendor support, as well as being educated on their role in any project work.\n<\/p><p>What happens if you don\u2019t automate? One way to justify the cost of a project is to help people understand what the lab\u2019s operations will be like without it. Will more people, equipment, space, or added shifts be needed? At what cost? What would the impact be on those who need the results and how would it affect their programs?\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Build.2C_buy.2C_or_cooperate.3F\">Build, buy, or cooperate?<\/span><\/h2>\n<p>In this write up and some of the referenced materials, we\u2019ve noted several times the benefits that clinical labs have gained through automation, although crediting it all to the use of automation alone isn\u2019t fair. What the clinical laboratory industry did was recognize that there was a need for the use of automation to solve problems with the operational costs of running labs, and recognition that they could benefit further by coming together and cooperatively addressing lab operational problems.\n<\/p><p>It\u2019s that latter point that made the difference and resulted in standardized communications, and purpose-built commercial equipment that could be used to implement automation in their labs. They also had common sample types, common procedures, and data processing. That same commonality applies to segments of industrial and academic lab work. Take life sciences as an example. Where possible, that industry has standardized on micro-plates for sample processing. The result is a wide selection of instruments and robotics built around that sample-holding format that greatly improves lab economics and throughput. While it isn\u2019t the answer to everything, it\u2019s a good answer to a lot of things.\n<\/p><p>If your industry segment came together and recognized that you used common procedures, how would you benefit by creating a common approach to automation instead of each lab doing it on their own? It would open the development of common products or product variations from vendors and relieve the need for each lab developing its own answer to the need. The result could be more effective and easily supportable solutions.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Project_planning\">Project planning<\/span><\/h2>\n<p>Once you\u2019ve decided on the project you are going to undertake, the next stage is looking at the steps needed to manage your project (Figure 5).\n<\/p><p><br \/>\n<a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig5_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"63b05e9703977e362222fe94d673287c\"><img alt=\"Fig5 Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/4\/4d\/Fig5_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 5.<\/b> Steps in a laboratory automation project. This diagram is modeled after the GAMP V for systems validation.<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p>The planning begins with the method description from Figure 1, which describes the science behind the project and the specification of how the automation is expected to be put into effect: as full-process automation, a specific step, or steps in the process. The provider of those documents is considered the \u201ccustomer\u201d and is consistent with GAMP V nomenclature (Figure 6); that consistency is important due to the need for system-wide validation protocols.\n<\/p><p><br \/>\n<a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig6_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"71f06c8346c550b519af5eb78dccb441\"><img alt=\"Fig6 Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/a\/a2\/Fig6_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 6.<\/b> GAMP V model for showing customer and supplier roles in specifying and evaluating project components for computer hardware and software.<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p>From there the \u201csupplier\u201d (e.g., internal development group, consultant, IT services, etc.) responds with a functional specification that is reviewed by the customer. The \u201canalysis, prototyping, and evaluation\u201d step, represented in the third box of Figure 5, is not the same as the process analysis noted earlier in this piece. The earlier section was to help you determine what work needed to be done and documented in the user requirements specification. The analysis and associated tasks here are specific to the implementation of this project. The colored arrows refer to the diagram in Figure 7. That process defines the equipment needed, dependencies, and options\/technologies for automation implementations, including robotics, instrument design requirements, pre-built automation (e.g., titrators, etc.) and any custom components. The documentation and specifications are part of the validation protocol.\n<\/p><p><br \/>\n<a href=\"https:\/\/www.limswiki.org\/index.php\/File:Fig6_Liscouski_ConsidAutoLabProc21.png\" class=\"image wiki-link\" data-key=\"71f06c8346c550b519af5eb78dccb441\"><img alt=\"Fig6 Liscouski ConsidAutoLabProc21.png\" src=\"https:\/\/s3.limswiki.org\/www.limswiki.org\/images\/a\/a2\/Fig6_Liscouski_ConsidAutoLabProc21.png\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a>\n<\/p>\n<div style=\"clear:both;\"><\/div>\n<table style=\"\">\n<tr>\n<td style=\"vertical-align:top;\">\n<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\" style=\"\">\n\n<tr>\n<td style=\"background-color:white; padding-left:10px; padding-right:10px;\"> <blockquote><b>Figure 7.<\/b> Defining dependencies and qualification of equipment<\/blockquote>\n<\/td><\/tr>\n<\/table>\n<\/td><\/tr><\/table>\n<p>The prototyping function is an important part of the overall process. It is rare that someone will look at a project and come up with a working solution on the first pass. There is always tinkering and modifications that occur as you move from a blank slate to a working system. You make notes along the way about what should be done differently in the final product, and places where improvements or adjustments are needed. These all become part of the input to the system design specification that will be reviewed and approved by the customer and supplier. The prototype can be considered a proof of concept or a demonstration of what will occur in the finished product. Remember also that prototypes would not have to be validated since they wouldn\u2019t be used in a production environment; they are simply a test bed used prior to the development of a production system.\n<\/p><p>The component design specifications are the refined requirement for elements that will be used in the final design. Those refinements could point to updated models of components or equipment used, modifications needed, or recommendations for products with capabilities other than those used in the prototype.\n<\/p><p>The boxes on the left side of Figure 5 are documents that go into increasing depth as the system is designed and specified. The details in those items will vary with the extent of the project. The right side of the diagram is a series of increasingly sophisticated testing and evaluation against steps in the right side, culminating in the final demonstration that the system works, has been validated, and is accepted by the customer. It also means that lab and support personnel are educated in their roles.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Conclusions_.28so_far.29\">Conclusions (so far)<\/span><\/h2>\n<p>\u201cLaboratory automation\u201d has to give way to \u201claboratory automation engineering.\u201d From the initial need to the completion of the validation process, we have to plan, design, and implement successful systems on a routine basis. Just as the manufacturing industries transitioned from cottage industries to production lines and then to integrated production-information systems, the execution of laboratory science has to tread a similar path if the demands for laboratory results are going to be met in a financially responsible manner. The science is fundamental; however, we need to pay attention now to efficient execution.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Abbreviations.2C_acronyms.2C_and_initialisms\">Abbreviations, acronyms, and initialisms<\/span><\/h2>\n<p><b>AI<\/b>: Artificial intelligence\n<\/p><p><b>AuI<\/b>: Augmented intelligence\n<\/p><p><b>DES<\/b>: Discrete-events simulation\n<\/p><p><b>ELN<\/b>: Electronic laboratory notebook\n<\/p><p><b>EPA<\/b>: Environmental Protection Agency\n<\/p><p><b>FDA<\/b>: Food and Drug Administration\n<\/p><p><b>FRB<\/b>: Fast radio bursts\n<\/p><p><b>GALP<\/b>: Good automated laboratory practices\n<\/p><p><b>GAMP<\/b>: Good automated manufacturing practice\n<\/p><p><b>ISO<\/b>: International Organization for Standardization\n<\/p><p><b>LES<\/b>: Laboratory execution system\n<\/p><p><b>LIMS<\/b>: Laboratory information management system\n<\/p><p><b>ML<\/b>: Machine learning\n<\/p><p><b>ROI<\/b>: Return on investment\n<\/p><p><b>SDMS<\/b>: Scientific data management system\n<\/p><p><b>TAT<\/b>: Turn-around time\n<\/p><p><br \/>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Footnotes\">Footnotes<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: lower-alpha;\">\n<ol class=\"references\">\n<li id=\"cite_note-1\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-1\">\u2191<\/a><\/span> <span class=\"reference-text\">The term \"scientific manufacturing\" was first mentioned to the author by Mr. Alberto Correia, then of Cambridge Biomedical, Boston, MA.<\/span>\n<\/li>\n<li id=\"cite_note-8\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-8\">\u2191<\/a><\/span> <span class=\"reference-text\">Intelligent enterprise technologies referenced in the report include robotic process automation, machine learning, artificial intelligence, the internet Of things, predictive analysis, and cognitive computing.<\/span>\n<\/li>\n<li id=\"cite_note-10\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-10\">\u2191<\/a><\/span> <span class=\"reference-text\"><a rel=\"nofollow\" class=\"external text wiki-link\" href=\"https:\/\/en.wikipedia.org\/wiki\/Douglas_Engelbart\" data-key=\"91bc4cc7c8f10296b73c8689f9f470bb\">Doug Engelbart<\/a> found the field of human-computer interaction and is credited with the invention of the computer mouse, and the \u201cMother of All Demos\u201d in 1968.<\/span>\n<\/li>\n<li id=\"cite_note-18\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-18\">\u2191<\/a><\/span> <span class=\"reference-text\">See <a href=\"https:\/\/en.wikipedia.org\/wiki\/Metropolis_(1927_film)\" class=\"extiw wiki-link\" title=\"wikipedia:Metropolis (1927 film)\" data-key=\"0e4d0869e79f689fae15419230e0e902\"><i>Metropolis<\/i> (1927 film)<\/a> on Wikipedia.<\/span>\n<\/li>\n<li id=\"cite_note-19\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-19\">\u2191<\/a><\/span> <span class=\"reference-text\">See for example <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.projectmanager.com\/project-planning\" target=\"_blank\">https:\/\/www.projectmanager.com\/project-planning<\/a>; the simplest thing to do it put \u201cproject planning\u201d in a search engine and browse the results for something interesting.<\/span>\n<\/li>\n<li id=\"cite_note-20\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-20\">\u2191<\/a><\/span> <span class=\"reference-text\">See for example <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/theinformationdrivenlaboratory.wordpress.com\/category\/resources\/\" target=\"_blank\">https:\/\/theinformationdrivenlaboratory.wordpress.com\/category\/resources\/<\/a>; note that any references to the ILA should be ignored as the original site is gone, with the domain name perhaps having been leased by another organization that has no affiliation with the original Institute for Laboratory Automation.<\/span>\n<\/li>\n<li id=\"cite_note-21\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-21\">\u2191<\/a><\/span> <span class=\"reference-text\">As a starting point, view the <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.artel.co\/\" target=\"_blank\">Artel, Inc. site<\/a> as one source. Also, John Bradshaw gave an <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.artel.co\/learning_center\/2589\/\" target=\"_blank\">informative presentation<\/a> on \u201cThe Importance of Liquid Handling Details and Their Impact on your Assays\u201d at the 2012 European Lab Automation Conference, Hamburg, Germany.<\/span>\n<\/li>\n<\/ol><\/div>\n<h2><span class=\"mw-headline\" id=\"About_the_author\">About the author<\/span><\/h2>\n<p>Initially educated as a chemist, author Joe Liscouski (joe dot liscouski at gmail dot com) is an experienced laboratory automation\/computing professional with over forty years of experience in the field, including the design and development of automation systems (both custom and commercial systems), LIMS, robotics and data interchange standards. He also consults on the use of computing in laboratory work. He has held symposia on validation and presented technical material and short courses on laboratory automation and computing in the U.S., Europe, and Japan. He has worked\/consulted in pharmaceutical, biotech, polymer, medical, and government laboratories. His current work centers on working with companies to establish planning programs for lab systems, developing effective support groups, and helping people with the application of automation and information technologies in research and quality control environments.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist references-column-width\" style=\"-moz-column-width: 30em; -webkit-column-width: 30em; column-width: 30em; list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-FreyTheFuture13-2\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-FreyTheFuture13_2-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Frey, C.B.; Osborne, M.A. (17 September 2013). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.oxfordmartin.ox.ac.uk\/downloads\/academic\/The_Future_of_Employment.pdf\" target=\"_blank\">\"The Future of Employment: How Susceptible Are Jobs to Computerisation?\"<\/a> (PDF). Oxford Martin School, University of Oxford<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.oxfordmartin.ox.ac.uk\/downloads\/academic\/The_Future_of_Employment.pdf\" target=\"_blank\">https:\/\/www.oxfordmartin.ox.ac.uk\/downloads\/academic\/The_Future_of_Employment.pdf<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=The+Future+of+Employment%3A+How+Susceptible+Are+Jobs+to+Computerisation%3F&rft.atitle=&rft.aulast=Frey%2C+C.B.%3B+Osborne%2C+M.A.&rft.au=Frey%2C+C.B.%3B+Osborne%2C+M.A.&rft.date=17+September+2013&rft.pub=Oxford+Martin+School%2C+University+of+Oxford&rft_id=https%3A%2F%2Fwww.oxfordmartin.ox.ac.uk%2Fdownloads%2Facademic%2FThe_Future_of_Employment.pdf&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-HsuIsIt18-3\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-HsuIsIt18_3-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Hsu, J. (24 September 2018). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.nbcnews.com\/mach\/science\/it-aliens-scientists-detect-more-mysterious-radio-signals-distant-galaxy-ncna912586\" target=\"_blank\">\"Is it aliens? Scientists detect more mysterious radio signals from distant galaxy\"<\/a>. <i>NBC News MACH<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.nbcnews.com\/mach\/science\/it-aliens-scientists-detect-more-mysterious-radio-signals-distant-galaxy-ncna912586\" target=\"_blank\">https:\/\/www.nbcnews.com\/mach\/science\/it-aliens-scientists-detect-more-mysterious-radio-signals-distant-galaxy-ncna912586<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Is+it+aliens%3F+Scientists+detect+more+mysterious+radio+signals+from+distant+galaxy&rft.atitle=NBC+News+MACH&rft.aulast=Hsu%2C+J.&rft.au=Hsu%2C+J.&rft.date=24+September+2018&rft_id=https%3A%2F%2Fwww.nbcnews.com%2Fmach%2Fscience%2Fit-aliens-scientists-detect-more-mysterious-radio-signals-distant-galaxy-ncna912586&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-TimmerAIPlus18-4\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-TimmerAIPlus18_4-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Timmer, J. (18 July 2018). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/arstechnica.com\/science\/2018\/07\/ai-plus-a-chemistry-robot-finds-all-the-reactions-that-will-work\/5\/\" target=\"_blank\">\"AI plus a chemistry robot finds all the reactions that will work\"<\/a>. <i>Ars Technica<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/arstechnica.com\/science\/2018\/07\/ai-plus-a-chemistry-robot-finds-all-the-reactions-that-will-work\/5\/\" target=\"_blank\">https:\/\/arstechnica.com\/science\/2018\/07\/ai-plus-a-chemistry-robot-finds-all-the-reactions-that-will-work\/5\/<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=AI+plus+a+chemistry+robot+finds+all+the+reactions+that+will+work&rft.atitle=Ars+Technica&rft.aulast=Timmer%2C+J.&rft.au=Timmer%2C+J.&rft.date=18+July+2018&rft_id=https%3A%2F%2Farstechnica.com%2Fscience%2F2018%2F07%2Fai-plus-a-chemistry-robot-finds-all-the-reactions-that-will-work%2F5%2F&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-HelixAIHome-5\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-HelixAIHome_5-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.askhelix.io\/\" target=\"_blank\">\"HelixAI - Voice Powered Digital Laboratory Assistants for Scientific Laboratories\"<\/a>. HelixAI<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.askhelix.io\/\" target=\"_blank\">http:\/\/www.askhelix.io\/<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=HelixAI+-+Voice+Powered+Digital+Laboratory+Assistants+for+Scientific+Laboratories&rft.atitle=&rft.pub=HelixAI&rft_id=http%3A%2F%2Fwww.askhelix.io%2F&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-PharmaIQNewsAutom18-6\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-PharmaIQNewsAutom18_6-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">PharmaIQ News (20 August 2018). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/news\/automation-iot-and-the-future-of-smarter-research-environments\" target=\"_blank\">\"Automation, IoT and the future of smarter research environments\"<\/a>. <i>PharmaIQ<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/news\/automation-iot-and-the-future-of-smarter-research-environments\" target=\"_blank\">https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/news\/automation-iot-and-the-future-of-smarter-research-environments<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Automation%2C+IoT+and+the+future+of+smarter+research+environments&rft.atitle=PharmaIQ&rft.aulast=PharmaIQ+News&rft.au=PharmaIQ+News&rft.date=20+August+2018&rft_id=https%3A%2F%2Fwww.pharma-iq.com%2Fpre-clinical-discovery-and-development%2Fnews%2Fautomation-iot-and-the-future-of-smarter-research-environments&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-PharmaIQTheFuture17-7\"><span class=\"mw-cite-backlink\">\u2191 <sup><a href=\"#cite_ref-PharmaIQTheFuture17_7-0\">6.0<\/a><\/sup> <sup><a href=\"#cite_ref-PharmaIQTheFuture17_7-1\">6.1<\/a><\/sup><\/span> <span class=\"reference-text\"><span class=\"citation web\">PharmaIQ (14 November 2017). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/whitepapers\/the-future-of-drug-discovery-ai-2020\" target=\"_blank\">\"The Future of Drug Discovery: AI 2020\"<\/a>. PharmaIQ<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/whitepapers\/the-future-of-drug-discovery-ai-2020\" target=\"_blank\">https:\/\/www.pharma-iq.com\/pre-clinical-discovery-and-development\/whitepapers\/the-future-of-drug-discovery-ai-2020<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=The+Future+of+Drug+Discovery%3A+AI+2020&rft.atitle=&rft.aulast=PharmaIQ&rft.au=PharmaIQ&rft.date=14+November+2017&rft.pub=PharmaIQ&rft_id=https%3A%2F%2Fwww.pharma-iq.com%2Fpre-clinical-discovery-and-development%2Fwhitepapers%2Fthe-future-of-drug-discovery-ai-2020&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-RossettoFight18-9\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-RossettoFight18_9-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation Journal\">Rossetto, L. (2018). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.magzter.com\/stories\/Science\/WIRED\/Fight-The-Dour\" target=\"_blank\">\"Fight the Dour\"<\/a>. <i>Wired<\/i> (October): 826\u20137<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.magzter.com\/stories\/Science\/WIRED\/Fight-The-Dour\" target=\"_blank\">https:\/\/www.magzter.com\/stories\/Science\/WIRED\/Fight-The-Dour<\/a><\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Fight+the+Dour&rft.jtitle=Wired&rft.aulast=Rossetto%2C+L.&rft.au=Rossetto%2C+L.&rft.date=2018&rft.issue=October&rft.pages=826%E2%80%937&rft_id=https%3A%2F%2Fwww.magzter.com%2Fstories%2FScience%2FWIRED%2FFight-The-Dour&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-BrukerOPUS-11\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-BrukerOPUS_11-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.bruker.com\/en\/products-and-solutions\/infrared-and-raman\/opus-spectroscopy-software\/search-identify.html\" target=\"_blank\">\"OPUS Package: SEARCH & IDENT\"<\/a>. Bruker Corporation<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.bruker.com\/en\/products-and-solutions\/infrared-and-raman\/opus-spectroscopy-software\/search-identify.html\" target=\"_blank\">https:\/\/www.bruker.com\/en\/products-and-solutions\/infrared-and-raman\/opus-spectroscopy-software\/search-identify.html<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=OPUS+Package%3A+SEARCH+%26+IDENT&rft.atitle=&rft.pub=Bruker+Corporation&rft_id=https%3A%2F%2Fwww.bruker.com%2Fen%2Fproducts-and-solutions%2Finfrared-and-raman%2Fopus-spectroscopy-software%2Fsearch-identify.html&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-BourneMyBoss13-12\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-BourneMyBoss13_12-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation Journal\">Bourne, D. (2013). \"My Boss the Robot\". <i>Scientific American<\/i> <b>308<\/b> (5): 38\u201341. <a rel=\"nofollow\" class=\"external text wiki-link\" href=\"http:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" data-key=\"ae6d69c760ab710abc2dd89f3937d2f4\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"http:\/\/dx.doi.org\/10.1038%2Fscientificamerican0513-38\" target=\"_blank\">10.1038\/scientificamerican0513-38<\/a>. <a rel=\"nofollow\" class=\"external text wiki-link\" href=\"http:\/\/en.wikipedia.org\/wiki\/PubMed_Identifier\" data-key=\"1d34e999f13d8801964a6b3e9d7b4e30\">PMID<\/a> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.ncbi.nlm.nih.gov\/pubmed\/23627215\" target=\"_blank\">23627215<\/a>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=My+Boss+the+Robot&rft.jtitle=Scientific+American&rft.aulast=Bourne%2C+D.&rft.au=Bourne%2C+D.&rft.date=2013&rft.volume=308&rft.issue=5&rft.pages=38%E2%80%9341&rft_id=info:doi\/10.1038%2Fscientificamerican0513-38&rft_id=info:pmid\/23627215&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-SalesForceSecondAnn17-13\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-SalesForceSecondAnn17_13-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">SalesForce Research (2017). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/a.sfdcstatic.com\/content\/dam\/www\/ocms\/assets\/pdf\/misc\/2017-state-of-it-report-salesforce.pdf\" target=\"_blank\">\"Second Annual State of IT\"<\/a> (PDF). SalesForce<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/a.sfdcstatic.com\/content\/dam\/www\/ocms\/assets\/pdf\/misc\/2017-state-of-it-report-salesforce.pdf\" target=\"_blank\">https:\/\/a.sfdcstatic.com\/content\/dam\/www\/ocms\/assets\/pdf\/misc\/2017-state-of-it-report-salesforce.pdf<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Second+Annual+State+of+IT&rft.atitle=&rft.aulast=SalesForce+Research&rft.au=SalesForce+Research&rft.date=2017&rft.pub=SalesForce&rft_id=https%3A%2F%2Fa.sfdcstatic.com%2Fcontent%2Fdam%2Fwww%2Focms%2Fassets%2Fpdf%2Fmisc%2F2017-state-of-it-report-salesforce.pdf&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-SealAnal-14\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-SealAnal_14-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/seal-analytical.com\/Products\/tabid\/55\/language\/en-US\/Default.aspx\" target=\"_blank\">\"Seal Analytical - Products\"<\/a>. Seal Analytical<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/seal-analytical.com\/Products\/tabid\/55\/language\/en-US\/Default.aspx\" target=\"_blank\">https:\/\/seal-analytical.com\/Products\/tabid\/55\/language\/en-US\/Default.aspx<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Seal+Analytical+-+Products&rft.atitle=&rft.pub=Seal+Analytical&rft_id=https%3A%2F%2Fseal-analytical.com%2FProducts%2Ftabid%2F55%2Flanguage%2Fen-US%2FDefault.aspx&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-BranLuebbe-15\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-BranLuebbe_15-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.spxflow.com\/bran-luebbe\/\" target=\"_blank\">\"Bran+Luebbe\"<\/a>. SPX FLOW, Inc<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.spxflow.com\/bran-luebbe\/\" target=\"_blank\">https:\/\/www.spxflow.com\/bran-luebbe\/<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Bran%2BLuebbe&rft.atitle=&rft.pub=SPX+FLOW%2C+Inc&rft_id=https%3A%2F%2Fwww.spxflow.com%2Fbran-luebbe%2F&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-DouglasScientificArrayTape-16\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-DouglasScientificArrayTape_16-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.douglasscientific.com\/Products\/ArrayTape.aspx\" target=\"_blank\">\"Array Tape Advanced Consumable\"<\/a>. Douglas Scientific<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.douglasscientific.com\/Products\/ArrayTape.aspx\" target=\"_blank\">https:\/\/www.douglasscientific.com\/Products\/ArrayTape.aspx<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Array+Tape+Advanced+Consumable&rft.atitle=&rft.pub=Douglas+Scientific&rft_id=https%3A%2F%2Fwww.douglasscientific.com%2FProducts%2FArrayTape.aspx&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-Agilent1200Series-17\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-Agilent1200Series_17-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.agilent.com\/cs\/library\/usermanuals\/Public\/G1329-90012_StandPrepSamplers_ebook.pdf\" target=\"_blank\">\"Agilent 1200 Series Standard and Preparative Autosamplers - User Manual\"<\/a> (PDF). Agilent Technologies. November 2008<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.agilent.com\/cs\/library\/usermanuals\/Public\/G1329-90012_StandPrepSamplers_ebook.pdf\" target=\"_blank\">https:\/\/www.agilent.com\/cs\/library\/usermanuals\/Public\/G1329-90012_StandPrepSamplers_ebook.pdf<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 04 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Agilent+1200+Series+Standard+and+Preparative+Autosamplers+-+User+Manual&rft.atitle=&rft.date=November+2008&rft.pub=Agilent+Technologies&rft_id=https%3A%2F%2Fwww.agilent.com%2Fcs%2Flibrary%2Fusermanuals%2FPublic%2FG1329-90012_StandPrepSamplers_ebook.pdf&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-BaytekiPRO-22\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-BaytekiPRO_22-0\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.baytekinternational.com\/products\/ipro-interface\/89-products\" target=\"_blank\">\"iPRO Interface - Products\"<\/a>. Baytek International, Inc<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.baytekinternational.com\/products\/ipro-interface\/89-products\" target=\"_blank\">https:\/\/www.baytekinternational.com\/products\/ipro-interface\/89-products<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 05 February 2021<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=iPRO+Interface+-+Products&rft.atitle=&rft.pub=Baytek+International%2C+Inc&rft_id=https%3A%2F%2Fwww.baytekinternational.com%2Fproducts%2Fipro-interface%2F89-products&rfr_id=info:sid\/en.wikipedia.org:LII:Considerations_in_the_Automation_of_Laboratory_Procedures\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-JoyceComputer18-23\"><
