LII:Directions in Laboratory Systems: One Person's Perspective - Revision history

Shawndouglas: Text replacement - "\[\[PerkinElmer Inc.(.*)" to "[[Vendor:PerkinElmer Inc.$1"

2024-03-28T01:40:26Z

Text replacement - "\[\[PerkinElmer Inc.(.*)" to "[[Vendor:PerkinElmer Inc.$1"

← Older revision		Revision as of 01:40, 28 March 2024
Line 606:		Line 606:

	===1.2 The beginning of laboratory informatics systems===		===1.2 The beginning of laboratory informatics systems===
	In the early 1970s, [[PerkinElmer Inc.\|PerkinElmer]] described its instrument supporting computers as “data stations.” Then they announced the “laboratory information management system” or "LIMS," and the next level of informatics hit the lab market. However, “laboratory information management system” was a problematic name for a product that did sample and test tracking. The customers thought it would take into account all of a lab's information, including personnel records, scheduling, budgets, documents, anything that “information” could be attached to, ultimately promising more than it could deliver. It took some time, but eventually something like that happened. From a marketing standpoint, it got people’s attention.		In the early 1970s, [[Vendor:PerkinElmer Inc.\|PerkinElmer]] described its instrument supporting computers as “data stations.” Then they announced the “laboratory information management system” or "LIMS," and the next level of informatics hit the lab market. However, “laboratory information management system” was a problematic name for a product that did sample and test tracking. The customers thought it would take into account all of a lab's information, including personnel records, scheduling, budgets, documents, anything that “information” could be attached to, ultimately promising more than it could deliver. It took some time, but eventually something like that happened. From a marketing standpoint, it got people’s attention.

	Several other vendors, consulting companies, startups, and computer vendors began LIMS development projects (computer vendors felt that database systems were their turf). This was viewed as a strategic offering: the testing lab's operations would revolve around the LIMS, and that gave the LIMS vendor whose product was chosen a strong marketing position in that company.		Several other vendors, consulting companies, startups, and computer vendors began LIMS development projects (computer vendors felt that database systems were their turf). This was viewed as a strategic offering: the testing lab's operations would revolve around the LIMS, and that gave the LIMS vendor whose product was chosen a strong marketing position in that company.

Shawndouglas: Cats

2022-02-09T19:44:35Z

Cats

← Older revision		Revision as of 19:44, 9 February 2022
Line 755:		Line 755:
	==References==		==References==
	{{Reflist\|colwidth=30em}}		{{Reflist\|colwidth=30em}}

			<!---Place all category tags here-->
			[[Category:LII:Guides, white papers, and other publications]]

Shawndouglas: /* It can make routine work easier and more productive, reducing costs and improving ROI */ Table 2 fix

2021-11-18T16:45:29Z

It can make routine work easier and more productive, reducing costs and improving ROI: Table 2 fix

← Older revision		Revision as of 16:45, 18 November 2021
Line 232:		Line 232:
	{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="100%"		{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="100%"
	\|-		\|-
	\| colspan="4" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 2.''' Productivity of labor-processing area<br /> <br />FTE = Full-time equivalent; TLA = Total laboratory		\| colspan="4" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 2.''' Productivity of labor-processing area<br /> <br />FTE = Full-time equivalent; TLA = Total laboratory automation
	\|-		\|-
	! style="padding-left:10px; padding-right:10px;" \|Ratio		! style="padding-left:10px; padding-right:10px;" \|Ratio

Shawndouglas: Tweak

2021-11-17T23:40:49Z

Tweak

← Older revision		Revision as of 23:40, 17 November 2021
Line 684:		Line 684:
	The combination of robotics and microplates also worked well in biotechnology because of the prevalence of liquid samples; this point can not be stressed enough. We are good at working with fluids, including measuring amounts, transferring them, dispensing them, and so on. Solids can be a problem because of cross-contamination if equipment isn’t cleaned, if the solid is tacky, if the particle size isn’t right for the equipment, if it has a tendency to roll, and so on. Solids also have the potential for problems with homogeneity. (You can get layering in liquids, but that can be solved in “two shakes.”)		The combination of robotics and microplates also worked well in biotechnology because of the prevalence of liquid samples; this point can not be stressed enough. We are good at working with fluids, including measuring amounts, transferring them, dispensing them, and so on. Solids can be a problem because of cross-contamination if equipment isn’t cleaned, if the solid is tacky, if the particle size isn’t right for the equipment, if it has a tendency to roll, and so on. Solids also have the potential for problems with homogeneity. (You can get layering in liquids, but that can be solved in “two shakes.”)

	====Two approaches to sample processing with robotics====		====1.3.1 Two approaches to sample processing with robotics====
	Broadly speaking, there are two approaches to sample processing with robotics: batching and sample-at-a-time runs. The microplate is an example of batch processing. Each tray is handled (dilution, sealing, reading, etc.) at a station, and you don’t have an opportunity to evaluate the results until the analysis for a tray is completed and reported. Other methods such as ICP, mass spectrometry, chromatography, etc. that use auto-injectors can behave in a similar fashion, or be evaluated on a sample-at-a-time basis. It depends on how the process is planned and implemented, and at what stage the results are evaluated.		Broadly speaking, there are two approaches to sample processing with robotics: batching and sample-at-a-time runs. The microplate is an example of batch processing. Each tray is handled (dilution, sealing, reading, etc.) at a station, and you don’t have an opportunity to evaluate the results until the analysis for a tray is completed and reported. Other methods such as ICP, mass spectrometry, chromatography, etc. that use auto-injectors can behave in a similar fashion, or be evaluated on a sample-at-a-time basis. It depends on how the process is planned and implemented, and at what stage the results are evaluated.

Line 698:		Line 698:
	In short, you have to have control of your samples and be able to ensure their integrity.		In short, you have to have control of your samples and be able to ensure their integrity.

	====The nature of incoming samples====		====1.4.1 The nature of incoming samples====
	Considerations about the nature of incoming samples don’t get as much press as they deserve. For example, if you are in quality control, the nature of your incoming samples is going to be consistent and determined by the production process. In fact, sample preparation is likely to be integrated with the test procedure’s automation. If the samples are fluids, the impact on an automation process may be small compared to working with solids. One complicating factor with fluids is the need to remove extraneous material so that downstream problems aren’t created. That removal may be accomplished by filtering, settling, centrifugal separation, batch centrifugation, or other means depending on the amount of material and its composition.		Considerations about the nature of incoming samples don’t get as much press as they deserve. For example, if you are in quality control, the nature of your incoming samples is going to be consistent and determined by the production process. In fact, sample preparation is likely to be integrated with the test procedure’s automation. If the samples are fluids, the impact on an automation process may be small compared to working with solids. One complicating factor with fluids is the need to remove extraneous material so that downstream problems aren’t created. That removal may be accomplished by filtering, settling, centrifugal separation, batch centrifugation, or other means depending on the amount of material and its composition.

Shawndouglas: Finished adding rest of content.

2021-11-17T23:39:17Z

Finished adding rest of content.

Show changes

Shawndouglas: Saving and adding more.

2021-11-17T22:38:50Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2021-11-17T21:52:49Z

Saving and adding more.

← Older revision		Revision as of 21:52, 17 November 2021
Line 647:		Line 647:

	===1.3 Electro-mechanical robotics===		===1.3 Electro-mechanical robotics===
			During the 1970s and 80s, vendors noted the amount of time spent doing repetitive tasks at the lab bench. This resulted in two different approaches to product development:

			* Dedicated-function robotics: The development of auto-samplers, auto-titrators, and similar devices that were used to carry out a specific task
			* General-purpose robotics: The development of an elaborate kit the use user had to assemble to robotically complete a task; not too different from a computer programming language: the
			components are there, you just have to organize them to make something useful happen

			Although each of these approaches was potentially useful, they each presented the user community with different sets of problems.

			The dedicated-function robotics device generally worked well; that wasn’t the issue. The problem arose when they had to connect to other components and instruments. The use of an auto-sampler, for example, required the user to adjust their sample preparation so that the material to be analyzed wound up in the appropriate sample vials. This may have required adjusting the procedure to accommodate a different set of mechanics than they were used to, e.g., sealing the vials or choosing the proper vial for an application. Auto-samplers feed samples into instruments so there is a matter of setting up control signals for proper coordination with instruments and instrument data systems.

			Other devices such as auto-titrators required a reservoir of samples (in the proper vial formats), and the vials had to be organized so that an analysis on sample ID456 was in fact that sample and that the order didn’t get mixed up. The data output could also be a problem. The default for many vendors was a spreadsheet-compatible file, though it was up to the user to make sense of it and integrate it into the workflow. This was probably the best compromise available until more formalized data interchange and communications standards became available. The vendor had no idea how a particular device was going to fit into a procedure's workflow or what was going to happen to the data further downstream, so a CSV file format as a solution was simple, flexible, and easy to work with. It also meant more work on the user's part on the integration front, representing another place where changes may have to be made if a device is replaced in the future.

			With the dedicated-function device, which could be as simple as a balance (the process of reading a force exerted on a sensor and converted to a weight is an automated process), we have potentially isolated elements of automation that are either interconnected by programming or someone reading data and re-entering it. However, there is no “plug-and-go” capability.

			As for the general-purpose robotics device, they could be broken down into two categories: those that were successful in the broad marketplace and those that weren't. In the 1980s, three vendors were competing for attention in the laboratory robotics market: Zymark, Hewlett-Packard, and PerkinElmer. Each of their general-purpose systems had a moveable arm that could grip items and be programmed to carry out lab procedures. Yet they faced a daunting task: the process of gripping items was problematic. The robot didn’t work with just one gripper or "hand"; it required multiple interchangeable hands that had to be swapped depending on the next sequence of actions and what items had to be grasped. Those items were typically things designed for human use, including flasks, test tubes, and a variety of other equipment. This problem was non-trivial, a result of having the robot work with equipment designed for humans so that the lab didn’t have to buy duplicate components, which would have raised problems of cost, and the ability to carry on work if the robot didn’t function. Another issue with the grippers and their holders was that they took up space. The Zymark system for example had a central robotic arm that could reach items within the shell of a hemispherical volume; grippers took up space that could be used by other devices. Some people were successful in building systems, but not enough to make the products economically viable. In many respects, the core robotics technologies should have been successful, but the peripheral devices were not up to the necessary operational levels; good for humans, lacking for automation.

Shawndouglas: Saving and adding more.

2021-11-17T21:22:49Z

Saving and adding more.

← Older revision		Revision as of 21:22, 17 November 2021
Line 606:		Line 606:

	===1.2 The beginning of laboratory informatics systems===		===1.2 The beginning of laboratory informatics systems===
			In the early 1970s, [[PerkinElmer Inc.\|PerkinElmer]] described its instrument supporting computers as “data stations.” Then they announced the “laboratory information management system” or "LIMS," and the next level of informatics hit the lab market. However, “laboratory information management system” was a problematic name for a product that did sample and test tracking. The customers thought it would take into account all of a lab's information, including personnel records, scheduling, budgets, documents, anything that “information” could be attached to, ultimately promising more than it could deliver. It took some time, but eventually something like that happened. From a marketing standpoint, it got people’s attention.

			Several other vendors, consulting companies, startups, and computer vendors began LIMS development projects (computer vendors felt that database systems were their turf). This was viewed as a strategic offering: the testing lab's operations would revolve around the LIMS, and that gave the LIMS vendor whose product was chosen a strong marketing position in that company.

			The introduction of the LIMS eventually opened the door to other informatics applications. The major classes and functions of said applications are show in Figure A3.


			[[File:FigA3 Liscouski DirectLabSysOnePerPersp21.png\|640px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="640px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure A3.''' The starting point for major classes of lab informatics systems and the lab functions they addressed</blockquote>
			\|-
			\|}
			\|}

			Missing from the chart are user-developer tools like LabView from National Instruments that enabled users to develop data acquisition and control applications via a graphical user interface.

			The term “electronic laboratory notebook” or "ELN" has had an interesting history. It’s been applied to at least three types of software before its most current iteration. Laboratory Technologies, Inc. first created LABTECH Notebook, a PC-based software package designed to assist users with the communication between a computer and its lab instruments via RS-232 connections. Then there was Wolfram's Mathematica software, an electronic notebook for advanced mathematics. And finally there was Velquest's SmartLAB, an ELN for conducting analyzes and recording information from laboratory procedures, becoming the first [[laboratory execution system]] (LES).

			Figure A3 showed a nice clean, somewhat idealized, starting point for the introduction of lab informatics. That didn’t last long. Vendors saw what their competition was doing and the opportunities to expand their products' capabilities (and market acceptance). What were clean, neat, functionality silos became more complex products to attract the attention of scientists and laboratorians (Figure A4).


			[[File:FigA4 Liscouski DirectLabSysOnePerPersp21.png\|700px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="700px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure A4.''' Lab informatics capability expansion</blockquote>
			\|-
			\|}
			\|}

			These expanded capabilities meant that a single vendor solution could address more of a lab’s needs, simplifying support, installation, and so on through the use of a singular software package. It did, however, make product and vendor selection more of a challenge; you really had to know what you needed. It also raised questions of cross-product compatibility: what instruments connected easily to what LIMS, ELN, or SDMS? If it wasn’t easy, what did you do? Third-party intermediate systems were eventually developed that translated instrument communications similarly in the way database systems did.

			While all this was going on in the expanding digital laboratory space, people still had things to do on the lab bench.

			===1.3 Electro-mechanical robotics===

Shawndouglas: Saving and adding more.

2021-11-17T20:50:52Z

Saving and adding more.

← Older revision		Revision as of 20:50, 17 November 2021
Line 537:		Line 537:
	==The creation of a "center for laboratory systems engineering"==		==The creation of a "center for laboratory systems engineering"==
	'''Key point''': ''Throughout this piece, the need for education has been a consistent theme. Developing and using the technologies in lab work, both scientific and informatics-related, will require people who know what they are doing, specifically educated to carry out the work noted above. We also need a means of pulling things together so that there is a centralized resource to start a learning process and continue development from there.''		'''Key point''': ''Throughout this piece, the need for education has been a consistent theme. Developing and using the technologies in lab work, both scientific and informatics-related, will require people who know what they are doing, specifically educated to carry out the work noted above. We also need a means of pulling things together so that there is a centralized resource to start a learning process and continue development from there.''

			Let's propose a "center for laboratory system engineering." This center would firstly prepare people to be effective planners, designers, implementers, supporters, and users of laboratory informatics and automation systems in scientific applications. Additionally, the center would ideally drive innovation and provide assistance to scientific personnel and IT groups seeking to apply and manage such laboratory technologies.

			Those goals would be accomplished by:

			* Developing and delivering courses for LSEs, lab personnel, and IT support (These courses would cover technical science topics as well as skills in working with people, conflict resolution, and communications. They would be presented both in-person and online or on-demand to reach a broad audience; an intensive summer course with hands-on experience should also be considered.)
			* Creating an LSE certification program
			* Carrying out research on the application of informatics, robotics, and computer-assisted data collection and processing
			* Documenting the best practices for an LSE
			* Aggregating and publishing material on the roles and requirements of the LSE

			Ideally, this center would be part of a university setting so that it could interact with both science and computer science departments, contribute to their programs, and in turn gain from that association.

			==Appendix 1: A very brief historical note==
			It would be useful to understand how we arrived at our current state in regards to informatics and automation in science. That will make it easier to understand what we need to do to make advancements. There is one key point to take away from this: in the history of lab automation, products weren’t developed according to a grand plan{{Efn\|See the discussion on clinical chemistry in the main text.}} but rather to meet perceived needs and opportunities. Thought processes in this vein have likely included:

			* “Here’s a problem that needs to be solved.”
			* “If I can figure out how to do X, then I can accomplish Y.”
			* “There’s a business opportunity in building product concept X, which will help people do Y and Z."

			Sometimes these ideas were voiced by lab personnel, but most of the time they were the result of someone seeing a problem or opportunity and taking the initiative to address it.

			===1.1 Collecting data from instruments===
			In the late 1960s and early 1970s, instrument companies recognized that connecting a computer to the analog output of an instrument would help lab personnel capture and process data. The form that this product development took depended on how the developer saw the problem. We’re going to look at chromatography{{Efn\|If you’re not familiar with the method, Wikipedia's [[chromatography]] page is a good starting point.}} as an example for several reasons: it received the most attention for automation, it’s a data rich technique that took considerable manual effort to analyze, and it was and still is one of the most popular instrumental techniques in chemical labs. The product solutions provided by the vendor reflected the technology available and their view of the problem that needed to be solved.

			The analysis (Figure A1) depends on recognizing and quantifying a series of peaks, each of which represents the amount of a component in a mixture of materials. The size of the peak (measured by area "better" or height with respect to a baseline) helps quantify the amount, and the time it takes the peak to appear can be used to help identify the component.


			[[File:FigA1 Liscouski DirectLabSysOnePerPersp21.png\|560px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="560px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure A1.''' Illustration of peaks from chromatograph. Source: public domain</blockquote>
			\|-
			\|}
			\|}

			Reference standards are prepared and run along with the samples. The peak response of the standards and their corresponding concentrations are used to draw a calibration curve, and the samples are quantified by comparing peak sizes against that curve (Figure A2).


			[[File:FigA2 Liscouski DirectLabSysOnePerPersp21.png\|560px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="560px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure A2.''' Samples are quantified by comparison to a calibration curve</blockquote>
			\|-
			\|}
			\|}

			The solutions reflected both the user’s input and the vendor's observations, plus being too close to the problem and not seeing the whole picture. In that same timeframe, computing was expensive and you had to have a lot of processing done to justify the costs. Otherwise you dropped down to microprocessors and scaled back the size of the problem you could tackle. The microprocessor of choice was the Intel 4004, which was superseded by the Intel 8008 in 1972.

			With computing, the chromatographer could detect peaks and quantify the peak height and area, later printing the results on a strip of paper. This was a big help to the chromatographer since determining peak size, and area in particular, was a major hassle. Prior to computerized methods, chromatographers were using:

			* mechanical integrators built into the strip chart recorder (that recorded the chromatograph output), which were hard to read and didn’t provide for baseline corrections (critical for accurate results);
			* a planimeter, which was time-comsuming and demanded careful attention;
			* a cut-and-weigh method, where the chromatographer literally cut our a copy of the peak and weighed it on a balance, cutting out a reference area, and comparing it to a calibration chart constructed from a similar procedure; and
			* a method that had the chromatographer counting the boxes the peak enclosed on the chart paper, which was not very accurate, though better than peak height in some cases.

			Having the quantified peaks printed on a piece of paper meant that the analyst could move quickly to drawing the calibration curve and evaluating the results. However, from the standpoint of being a laborious, time-consuming task, this is only a piece of the problem (a major one, but only a part). Some users connected the output of the integrators (RS-232 serial ASCII) to minicomputers, transferred the integrator information, and completed the analytical process in the larger machines. Several integrators could be connected to a mini-computer so the cost per instrument was reduced. This was a step toward a better solution, but only a step.

			Computer vendors wanted to participate in the same market, but the cost of minicomputers put them at a disadvantage unless they could come at it from a different perspective. They looked at the entire data processing problem, including the points mentioned above, plus getting the computer to compute the calibration curve, complete the analysis, print out a report, and store the report and the data for later retrieval (integrators didn’t have that capability). They could also store the raw digitized instrument output for later analysis and display. The cost per instrument dropped when computer vendors began connecting multiple instruments to one system, some from different labs. Nelson Analytical used a local-to-the-instrument box for data collection and control and then forwarded those information packets to a central system for processing. This bigger-picture view of the problem greatly reduced the workload on the analyst. As computing costs dropped and the power of microchips increased, several different approaches emerged from different vendors that had varied perspectives on computing. Most took the big-picture view but worked on a one-instrument-one-computer-station approach, which benefited small labs since they didn’t have to invest in a minicomputer.

			The low-cost of microprocessors more readily allowed digital systems to join the lab, to the point where almost every lab device had a computer chip in it (“digital” was a strong marketing point). Now that we had lots of digital data sources, what was the lab going to do with them?

			===1.2 The beginning of laboratory informatics systems===

Shawndouglas: Saving and adding more.

2021-11-17T19:53:17Z

Saving and adding more.

← Older revision		Revision as of 19:53, 17 November 2021
Line 503:		Line 503:

	In another application (anecdotal reporting from a course on plastics manufacturing)—calendering{{Efn\|Wikipedia [[wikipedia:Calender\|says this]] of calendering: "A calender is a series of hard pressure rollers used to finish or smooth a sheet of material such as paper, textiles, or plastics. Calender rolls are also used to form some types of plastic films and to apply coatings."}} of plastic coated paper—the production operator would strike the laminated paper with a slender bamboo rod and listen to the sound it made to determine the product quality. According to the course instructor, he was adept at this, and no other test could replace this in-process procedure.		In another application (anecdotal reporting from a course on plastics manufacturing)—calendering{{Efn\|Wikipedia [[wikipedia:Calender\|says this]] of calendering: "A calender is a series of hard pressure rollers used to finish or smooth a sheet of material such as paper, textiles, or plastics. Calender rolls are also used to form some types of plastic films and to apply coatings."}} of plastic coated paper—the production operator would strike the laminated paper with a slender bamboo rod and listen to the sound it made to determine the product quality. According to the course instructor, he was adept at this, and no other test could replace this in-process procedure.

			As such, it's clear not all "quality" testing went on in the laboratory.

			====Normal QC testing====
			Traditionally, QC lab operations became separate from production, partly because of the physical conditions needed to conduct the work, and partly to avoid bias in the results. The conclusion: it was important that the reporting lines of communication be separate and independent from production. QC labs would, and do, perform testing on incoming materials to certify them suitable for use and produced products to see if they met product specifications, as well as perform in-process testing. They would also certify products as qualified for shipment, acting as an unbiased evaluator of product quality.

			Quality tests were manually implemented until the early 1960s. Then we saw the advent of in-process instrumentation and process chromatographs by Fisher Controls and Mine Safety Apparatus, for example. While the instruments themselves were on the production floor, their management and analysis was under the control of the QC lab, at least in the facility I worked in. The instruments' maintenance, calibration, peak measurements, and sample calculations were all done by lab personnel. Since that time, we’ve seen a continued growth in in-line testing for production processes. That said, what’s the logical conclusion of increasing automation?

			====A thought experiment====
			Lets posit that we have a production process whose raw materials are fluids and the end product is a fluid. We’d be concerned with certifying in-coming raw materials as suitable for use, while monitoring the production process for product composition and potential contaminants. The end product would have to be certified for shipment.

			If all the testing were chromatographic with in-process instruments and a [[chromatography data system]] (CDS), and/or in-line spectrophotometric and other in-line or in-process tests, with the results becoming part of the process control system (sample IDs would be a hash of sensor type-location-timestamp), what would the role of the QC lab become? Assuring that the equipment was running properly and regularly calibrated, with periodic verification of test results (off-line testing) is one set of possibilities. Is this a desirable developmental direction? We need to look at the benefits and issues that result from this design.

			'''Benefits''':
			* It provides an integrated system where all process sensor and test result data are immediately available to management. This allows them to detect issues faster and provide a more timely response (better process control), reducing down time and off-spec product. If we want to enter the world of science fiction, we can even imagine a combination AI-[[machine learning]] solution providing closed loop process monitoring and control.
			* It signifies a potential cost reduction resulting from smaller labs and lower personnel costs.

			'''Issues''':
			* There's a loss of independent product evaluation. Basically, you are trusting the system to honestly monitor, report, and reject off-spec, incoming, and outgoing material. In the movie version, this is where the sound track becomes ominous. This loss of independent checking may reduce customer confidence in product quality.
			* The veracity of statistical process control and correction may suffer.
			* System validation could be challenging as the production process has to be validated, each sensor and instrument data system has to be validated, and the integrated system has to be validated, including the statistical process control.

			Assuming a system were built, how far are we willing to trust automated systems to function without external oversight? The control room would still be populated with people managing the process and exerting a higher level of scrutiny, but you are still trusting the designers of the system to do very sophisticated work, not only in process design but also integrating testing as part of the effort. Ideally you’d want the CDS and other instrument data processing equipment in the control room, where it is more easily used and maintained, than on the process floor. The role of the QC lab would then change to that of an overarching quality manager of the entire system, ensuring that equipment functioned properly, testing was accurate, the process and testing were operating within control limits, and the data logs were correct.

			Some organizations may be past this point, while for others this may be interesting, bordering on science fiction. The point of this thought experiment is to see what could happen and where your comfort level is with it. How much control do you want to give an automated system and how much do you want to retain? What are the consequences of not providing sufficient oversight? How much bad product could be made?

			Also note that this isn’t an all-or-nothing proposition; give it some room to work, see what happens, and if everything is good, give it more. Just build in a big red button that allows you to reboot and revert to manual operations; in other words, don't self-destruct, just remove some critical controls. A lot depends on the nature of the finished product. If the end product is something critical (e.g., a [[medical device]] or therapeutic), you’ll want to be cautious about phasing in automated control systems.

			All that said, two additional points should be made. First, be willing to play with the ideas. Turn it into a science fiction project (“sci fi” is just a playground for "what ifs"), remove it from reality enough that people can look at it from different perspectives and see what might work and what might not. Then let people play with those ideas; you might learn something. What are all the things that could go right, and what could go wrong (and what can you do about it)? You probably won't have to worry about alien robots, but malware interference is certainly a factor, as is a network air-gap. There is always the possibility of someone causing a problem; the question of course is how do you detect it and correct it. Second, be willing to model the system. There are a number of modeling packages ideal for this purpose. You can model the behavior and see how different control methods react.

			(While this thought experiment used a process involving fluids only, as they are relatively easy to work with, its worth noting that solid materials become more of an issue, complicating the automation process [see Appendix 1, section 1.4 of this guide]. In some cases sample preparation for testing may be too cumbersome for automation. This would shift the automated-manual testing balance more toward the latter in those cases, introducing delays and disrupting the timing of results to process control.)

			==The creation of a "center for laboratory systems engineering"==
			'''Key point''': ''Throughout this piece, the need for education has been a consistent theme. Developing and using the technologies in lab work, both scientific and informatics-related, will require people who know what they are doing, specifically educated to carry out the work noted above. We also need a means of pulling things together so that there is a centralized resource to start a learning process and continue development from there.''



	==Abbreviations, acronyms, and initialisms==		==Abbreviations, acronyms, and initialisms==

			'''CDS''': Chromatography data system

	'''ELN''': Electronic laboratory notebook		'''ELN''': Electronic laboratory notebook