LII:A Science Student's Guide to Laboratory Informatics - Revision history

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

2024-03-29T16:17:35Z

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

← Older revision		Revision as of 16:17, 29 March 2024
Line 257:		Line 257:
	That same facility is available through an IDS, but only for the devices that the IDS is connected to, e.g., chromatographs, spectrometers, etc. In addition to that function, IDSs support instrumental data collection, analysis, and reporting. They can also be linked to LIMS and ELNs by electronically receiving worklists and then electronically sending the results back, thus avoiding the need for entering the data manually.		That same facility is available through an IDS, but only for the devices that the IDS is connected to, e.g., chromatographs, spectrometers, etc. In addition to that function, IDSs support instrumental data collection, analysis, and reporting. They can also be linked to LIMS and ELNs by electronically receiving worklists and then electronically sending the results back, thus avoiding the need for entering the data manually.

	The LES is also an aid to the laboratory, ensuring that laboratory methods and procedures are carried out correctly, with documented support for each step in the method. They can be seen as a quasi-automation system, except instead of automation hardware doing the work, the laboratorian is doing it, guided step-by-step by strict adherence to the method as embedded in software. The problem that this type of system, originally styled as an “electronic laboratory notebook” by Velquest Inc. (later purchased by [[Accelrys, Inc.\|Accelrys]]) was to ensure that there was documented evidence that every step in a lab procedure was properly carried out by qualified personnel, using calibrated/maintained instruments, current reagents, with all data electronically captured with potential links to LIMS or other systems. That system would provide bullet-proof support for data and information generated by procedures in regulated environments. That in turn means that the data/information produced is reliable and can stand up to challenges.		The LES is also an aid to the laboratory, ensuring that laboratory methods and procedures are carried out correctly, with documented support for each step in the method. They can be seen as a quasi-automation system, except instead of automation hardware doing the work, the laboratorian is doing it, guided step-by-step by strict adherence to the method as embedded in software. The problem that this type of system, originally styled as an “electronic laboratory notebook” by Velquest Inc. (later purchased by [[Vendor:Accelrys, Inc.\|Accelrys]]) was to ensure that there was documented evidence that every step in a lab procedure was properly carried out by qualified personnel, using calibrated/maintained instruments, current reagents, with all data electronically captured with potential links to LIMS or other systems. That system would provide bullet-proof support for data and information generated by procedures in regulated environments. That in turn means that the data/information produced is reliable and can stand up to challenges.

	Implementations of LES have ranged from stand-alone applications that linked to LIMS, ELNs, and SDMS, to programmable components of LIMS and ELNs. Instead of having a stand-alone framework to implement an LES, as with Velquest's product, embedded systems provide a scripting (i.e., programming by the user) facility within a LIMS that has access to the entire LIMS database, avoiding the need to interface two products. That embedded facility put a lot of pressure on the programmer to properly design, test, and validate each procedure in an isolated structure, separate from the active LIMS so that programming errors didn’t compromise the integrity of the database. Note: procedure execution in stand-alone systems requires validation as well.		Implementations of LES have ranged from stand-alone applications that linked to LIMS, ELNs, and SDMS, to programmable components of LIMS and ELNs. Instead of having a stand-alone framework to implement an LES, as with Velquest's product, embedded systems provide a scripting (i.e., programming by the user) facility within a LIMS that has access to the entire LIMS database, avoiding the need to interface two products. That embedded facility put a lot of pressure on the programmer to properly design, test, and validate each procedure in an isolated structure, separate from the active LIMS so that programming errors didn’t compromise the integrity of the database. Note: procedure execution in stand-alone systems requires validation as well.

Shawndouglas: LIMS FAQ to Q&A

2024-02-23T22:57:22Z

LIMS FAQ to Q&A

← Older revision		Revision as of 22:57, 23 February 2024
Line 170:		Line 170:
	*'''American Association for Laboratory Accreditation (A2LA)''': This includes guidelines and accreditation requirements that labs must adhere to as part of accrediting to a particular standard. This includes standards like the [[ISO 9000]] family of standards and [[ISO/IEC 17025]]. The ISO 9000 family is a set of five QMS standards that help organizations ensure that they meet customer and other stakeholder needs within statutory and regulatory requirements related to a product or service. ISO/IEC 17025 ''General requirements for the competence of testing and calibration laboratories'' is the primary standard used by testing and calibration laboratories, and there are special technology considerations to be made when complying. (See ''[[LII:LIMS Selection Guide for ISO/IEC 17025 Laboratories\|LIMS Selection Guide for ISO/IEC 17025 Laboratories]]'' for more on this topic.) In most countries, ISO/IEC 17025 is the standard for which most labs must hold accreditation to be deemed technically competent.		*'''American Association for Laboratory Accreditation (A2LA)''': This includes guidelines and accreditation requirements that labs must adhere to as part of accrediting to a particular standard. This includes standards like the [[ISO 9000]] family of standards and [[ISO/IEC 17025]]. The ISO 9000 family is a set of five QMS standards that help organizations ensure that they meet customer and other stakeholder needs within statutory and regulatory requirements related to a product or service. ISO/IEC 17025 ''General requirements for the competence of testing and calibration laboratories'' is the primary standard used by testing and calibration laboratories, and there are special technology considerations to be made when complying. (See ''[[LII:LIMS Selection Guide for ISO/IEC 17025 Laboratories\|LIMS Selection Guide for ISO/IEC 17025 Laboratories]]'' for more on this topic.) In most countries, ISO/IEC 17025 is the standard for which most labs must hold accreditation to be deemed technically competent.

	A comment should be made about the interplay of regulations, standards, and guidelines. The difference between regulations and standards is that regulations have the law to support their enforcement.<ref name="PankoninReg21">{{cite web \|url=https://www.aem.org/news/regulations-vs-standards-clearing-up-the-confusion \|title=Regulations vs. Standards: Clearing up the Confusion \|author=Pankonin, M. \|publisher=Association of Equipment Manufacturers \|date=27 May 2021 \|accessdate=17 November 2023}}</ref> Standards are consensus agreements that companies, industries, and associations use to define “best practices.” Guidelines are proposed standards of organizational behavior that may or may not eventually become regulations. The FDA regulations for example, began as guidelines, underwent discussion and modification, and eventually became regulations under 21 CFR Part 11. For a more nuanced discussion in one particular lab-related area, materials science, see ''[[LIMS ~~FAQ~~:What standards and regulations affect a materials testing laboratory?\|What standards and regulations affect a materials testing laboratory?]]''.		A comment should be made about the interplay of regulations, standards, and guidelines. The difference between regulations and standards is that regulations have the law to support their enforcement.<ref name="PankoninReg21">{{cite web \|url=https://www.aem.org/news/regulations-vs-standards-clearing-up-the-confusion \|title=Regulations vs. Standards: Clearing up the Confusion \|author=Pankonin, M. \|publisher=Association of Equipment Manufacturers \|date=27 May 2021 \|accessdate=17 November 2023}}</ref> Standards are consensus agreements that companies, industries, and associations use to define “best practices.” Guidelines are proposed standards of organizational behavior that may or may not eventually become regulations. The FDA regulations for example, began as guidelines, underwent discussion and modification, and eventually became regulations under 21 CFR Part 11. For a more nuanced discussion in one particular lab-related area, materials science, see ''[[LIMS Q&A:What standards and regulations affect a materials testing laboratory?\|What standards and regulations affect a materials testing laboratory?]]''.

	===Meeting the needs of data governance, data integrity, and regulatory compliance===		===Meeting the needs of data governance, data integrity, and regulatory compliance===

Shawndouglas: Cat

2024-01-04T15:45:37Z

Cat

← Older revision		Revision as of 15:45, 4 January 2024
Line 468:		Line 468:

	<!---Place all category tags here-->		<!---Place all category tags here-->
	[[Category:LII:Guides, white papers, and other publications\|A Science Student's Guide to Laboratory Informatics]]		[[Category:LII:Guides, white papers, and other publications\|Science Student's Guide to Laboratory Informatics]]

Shawndouglas: About the author

2023-11-18T14:34:32Z

About the author

← Older revision		Revision as of 14:34, 18 November 2023
Line 460:		Line 460:
	==In closing...==		==In closing...==
	The purpose of this document is to give the student a high-level overview of the purpose and use of the major informatics systems that are commonly used in industrial research and service laboratories. This is an active area of development, with new products and platforms being released annually, usually around major conferences. The links included are starting points to increasing the depth of the material.		The purpose of this document is to give the student a high-level overview of the purpose and use of the major informatics systems that are commonly used in industrial research and service laboratories. This is an active area of development, with new products and platforms being released annually, usually around major conferences. The links included are starting points to increasing the depth of the material.

			==About the author==
			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.

	==References==		==References==

Shawndouglas: /* Systems development: tinkering vs. engineering */

2023-11-18T01:30:48Z

Systems development: tinkering vs. engineering

← Older revision		Revision as of 01:30, 18 November 2023
Line 447:		Line 447:
	AI offers a great deal of potential benefits to laboratory work, something marketers are going to exploit to attract more customers. Product offerings need to be viewed skeptically as supposed benefits may be less than promised, or not as fully tested as needed. Unlike dealing with spelling checkers that consistently make improper word substitutions, AI-generated errors in data analysis are dangerous because they may go undetected.		AI offers a great deal of potential benefits to laboratory work, something marketers are going to exploit to attract more customers. Product offerings need to be viewed skeptically as supposed benefits may be less than promised, or not as fully tested as needed. Unlike dealing with spelling checkers that consistently make improper word substitutions, AI-generated errors in data analysis are dangerous because they may go undetected.

	==Systems development: ~~tinkering~~ vs. engineering==		==Systems development: Tinkering vs. engineering==
	One common practice in laboratory work, particularly in research, is modifying equipment or creating new configurations of equipment and instruments to get work done. That same thought pattern often extends to software development; components such as spreadsheets, compilers, database systems, and so on are common parts of laboratory computer systems. Many people include programming as part of their list of skills. That can lead to the development of special purpose software to solve issues in data handling and analysis.		One common practice in laboratory work, particularly in research, is modifying equipment or creating new configurations of equipment and instruments to get work done. That same thought pattern often extends to software development; components such as spreadsheets, compilers, database systems, and so on are common parts of laboratory computer systems. Many people include programming as part of their list of skills. That can lead to the development of special purpose software to solve issues in data handling and analysis.

Shawndouglas: Finished updates.

2023-11-18T01:25:48Z

Finished updates.

← Older revision		Revision as of 01:25, 18 November 2023
Line 6:		Line 6:

	'''Publication date''': November 2023		'''Publication date''': November 2023

	~~{{ombox~~
	~~\| type = notice~~
	~~\| image = [[Image:Emblem-important-yellow.svg\|40px]]~~
	~~\| style = width: 500px;~~
	~~\| text = This article should be considered a work in progress and incomplete. Consider this article incomplete until this notice is removed.~~
	}}

	==Introduction==		==Introduction==
Line 266:		Line 259:
	The LES is also an aid to the laboratory, ensuring that laboratory methods and procedures are carried out correctly, with documented support for each step in the method. They can be seen as a quasi-automation system, except instead of automation hardware doing the work, the laboratorian is doing it, guided step-by-step by strict adherence to the method as embedded in software. The problem that this type of system, originally styled as an “electronic laboratory notebook” by Velquest Inc. (later purchased by [[Accelrys, Inc.\|Accelrys]]) was to ensure that there was documented evidence that every step in a lab procedure was properly carried out by qualified personnel, using calibrated/maintained instruments, current reagents, with all data electronically captured with potential links to LIMS or other systems. That system would provide bullet-proof support for data and information generated by procedures in regulated environments. That in turn means that the data/information produced is reliable and can stand up to challenges.		The LES is also an aid to the laboratory, ensuring that laboratory methods and procedures are carried out correctly, with documented support for each step in the method. They can be seen as a quasi-automation system, except instead of automation hardware doing the work, the laboratorian is doing it, guided step-by-step by strict adherence to the method as embedded in software. The problem that this type of system, originally styled as an “electronic laboratory notebook” by Velquest Inc. (later purchased by [[Accelrys, Inc.\|Accelrys]]) was to ensure that there was documented evidence that every step in a lab procedure was properly carried out by qualified personnel, using calibrated/maintained instruments, current reagents, with all data electronically captured with potential links to LIMS or other systems. That system would provide bullet-proof support for data and information generated by procedures in regulated environments. That in turn means that the data/information produced is reliable and can stand up to challenges.

	Implementations of LES have ranged from stand-alone applications that linked to LIMS, ELNs, and SDMS, to programmable components of LIMS and ELNs. Instead of having a stand-alone framework to implement an LES as with Velquest's product, embedded systems provide a scripting (i.e., programming by the user) facility within a LIMS that has access to the entire LIMS database, avoiding the need to interface two products. That embedded facility put a lot of pressure on the programmer to properly design, test, and validate each procedure in an isolated structure, separate from the active LIMS so that programming errors didn’t compromise the integrity of the database. Note: procedure execution in stand-alone systems requires validation as well.		Implementations of LES have ranged from stand-alone applications that linked to LIMS, ELNs, and SDMS, to programmable components of LIMS and ELNs. Instead of having a stand-alone framework to implement an LES, as with Velquest's product, embedded systems provide a scripting (i.e., programming by the user) facility within a LIMS that has access to the entire LIMS database, avoiding the need to interface two products. That embedded facility put a lot of pressure on the programmer to properly design, test, and validate each procedure in an isolated structure, separate from the active LIMS so that programming errors didn’t compromise the integrity of the database. Note: procedure execution in stand-alone systems requires validation as well.

	As for the IDS, instrument vendors of the late 1960s explored the benefits of connecting laboratory instruments to computer systems to see what could be gained from that combination. One problem they wanted to address was the handling of the large volumes of data that instruments produced. At that time, analog instrument output was often recorded on chart paper, and a single sample through a chromatograph might be recorded on a chart that was one or more feet long. A day’s work generated a lot of paper that had to be evaluated manually, which proved time-consuming and labor-intensive. Vendors have since successfully developed computer-instrument combinations that automatically transform the instrument's analog output to a digital format, and then store and process that data to produce useful information (results), eliminating the manual effort and making labs more cost-effective in the process. This was the first step in instrument automation; the user was still required to introduce the sample into the device. The second step solved that problem in many instances through the creation of automatic samplers that moved the samples into position for analysis. This includes auto-injectors, flow-through cells, and other autosamplers, depending on the analytical technique.		As for the IDS, instrument vendors of the late 1960s explored the benefits of connecting laboratory instruments to computer systems to see what could be gained from that combination. One problem they wanted to address was the handling of the large volumes of data that instruments produced. At that time, analog instrument output was often recorded on chart paper, and a single sample through a chromatograph might be recorded on a chart that was one or more feet long. A day’s work generated a lot of paper that had to be evaluated manually, which proved time-consuming and labor-intensive. Vendors have since successfully developed computer-instrument combinations that automatically transform the instrument's analog output to a digital format, and then store and process that data to produce useful information (results), eliminating the manual effort and making labs more cost-effective in the process. This was the first step in instrument automation; the user was still required to introduce the sample into the device. The second step solved that problem in many instances through the creation of automatic samplers that moved the samples into position for analysis. This includes auto-injectors, flow-through cells, and other autosamplers, depending on the analytical technique.
Line 455:		Line 448:

	==Systems development: tinkering vs. engineering==		==Systems development: tinkering vs. engineering==
			One common practice in laboratory work, particularly in research, is modifying equipment or creating new configurations of equipment and instruments to get work done. That same thought pattern often extends to software development; components such as spreadsheets, compilers, database systems, and so on are common parts of laboratory computer systems. Many people include programming as part of their list of skills. That can lead to the development of special purpose software to solve issues in data handling and analysis.

			That activity in an industrial lab is potentially problematic. Organizations have controls over what software development is permitted so that organizational security isn’t compromised and that the development activities do not create problems with organizational or regulatory requirements and guidelines.

			If a need for software develops, there are recognized processes for defining, implementing, and validating those projects. One of the best-known in laboratory science comes from ISPE's GAMP guidelines.<ref name="ISPEWhatIsGAMP" /> There is also a discussion of the methodology in ''[[LII:Considerations in the Automation of Laboratory Procedures\|Considerations in the Automation of Laboratory Procedures]]''.

			The development process begins with a “needs analysis” that describes why the project is being undertaken and what it is supposed to accomplish, along with the benefits of doing it. That is followed by a user-requirements document that has to be agreed upon before the project begins. Once that is done, a prototype system(s) can be developed that will give you a chance to explore different options for development, project requirements, etc., that will form the basis of a design specification for the development of the actual project (whereupon the prototype is scrapped). At this point, the rest of the GAMP process is followed through the completion of the project. The end result is a proven, working, documented system that can be relied upon (based on evidence) to work and be supported. If changes are needed, the backup documentation is there to support that work.

			This is an engineering approach to systems development. Those systems may result in software, a sample preparation process, or the implementation of an automated test method. It is needed to ensure that things work, and if the developer is no longer available, the project can still be used, supported, modified, etc., as needed. The organizations investment is protected, the data and information produced can be supported and treated as reliable, and all guidelines and regulations are being met.

			==In closing...==
			The purpose of this document is to give the student a high-level overview of the purpose and use of the major informatics systems that are commonly used in industrial research and service laboratories. This is an active area of development, with new products and platforms being released annually, usually around major conferences. The links included are starting points to increasing the depth of the material.

	==References==		==References==

Shawndouglas: Saving and adding more.

2023-11-18T01:14:59Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2023-11-18T00:25:03Z

Saving and adding more.

← Older revision		Revision as of 00:25, 18 November 2023
Line 256:		Line 256:

	====Supporting tiers of software====		====Supporting tiers of software====
			There are limits to what a vendor can or wants to include in their products. The more functionality, the higher the cost to the customer, and the more complex the support issue becomes. One of those areas is data storage.

			The results storage in LIMS is usually limited to sets of numerical values or alphanumeric strings, e.g., the color of something. Those results are often based on the analysis of larger data files from instruments, images, or other sources, files too large to be accommodated within a LIMS. That problem was solved in at least two ways: the creation of the SDMS and IDS. From the standpoint of data files, both have some elements in common, though IDSs are more limited.

			The SDMS acts as a large file cabinet, where different types of materials can be put into them—images, charts, scanned documents, data files, etc.—and then be referenced by the LIMS or ELN. The results sit in LIMS or ELN, and supporting information is linked to the results in the SDMS. That keeps the LIMS and ELN databases easier to structure while still supporting the lab's needs to manage large files from a variety of sources and formats.

			That same facility is available through an IDS, but only for the devices that the IDS is connected to, e.g., chromatographs, spectrometers, etc. In addition to that function, IDSs support instrumental data collection, analysis, and reporting. They can also be linked to LIMS and ELNs by electronically receiving worklists and then electronically sending the results back, thus avoiding the need for entering the data manually.

			The LES is also an aid to the laboratory, ensuring that laboratory methods and procedures are carried out correctly, with documented support for each step in the method. They can be seen as a quasi-automation system, except instead of automation hardware doing the work, the laboratorian is doing it, guided step-by-step by strict adherence to the method as embedded in software. The problem that this type of system, originally styled as an “electronic laboratory notebook” by Velquest Inc. (later purchased by [[Accelrys, Inc.\|Accelrys]]) was to ensure that there was documented evidence that every step in a lab procedure was properly carried out by qualified personnel, using calibrated/maintained instruments, current reagents, with all data electronically captured with potential links to LIMS or other systems. That system would provide bullet-proof support for data and information generated by procedures in regulated environments. That in turn means that the data/information produced is reliable and can stand up to challenges.

			Implementations of LES have ranged from stand-alone applications that linked to LIMS, ELNs, and SDMS, to programmable components of LIMS and ELNs. Instead of having a stand-alone framework to implement an LES as with Velquest's product, embedded systems provide a scripting (i.e., programming by the user) facility within a LIMS that has access to the entire LIMS database, avoiding the need to interface two products. That embedded facility put a lot of pressure on the programmer to properly design, test, and validate each procedure in an isolated structure, separate from the active LIMS so that programming errors didn’t compromise the integrity of the database. Note: procedure execution in stand-alone systems requires validation as well.

			As for the IDS, instrument vendors of the late 1960s explored the benefits of connecting laboratory instruments to computer systems to see what could be gained from that combination. One problem they wanted to address was the handling of the large volumes of data that instruments produced. At that time, analog instrument output was often recorded on chart paper, and a single sample through a chromatograph might be recorded on a chart that was one or more feet long. A day’s work generated a lot of paper that had to be evaluated manually, which proved time-consuming and labor-intensive. Vendors have since successfully developed computer-instrument combinations that automatically transform the instrument's analog output to a digital format, and then store and process that data to produce useful information (results), eliminating the manual effort and making labs more cost-effective in the process. This was the first step in instrument automation; the user was still required to introduce the sample into the device. The second step solved that problem in many instances through the creation of automatic samplers that moved the samples into position for analysis. This includes auto-injectors, flow-through cells, and other autosamplers, depending on the analytical technique.

			Autosamplers have ranged from devices that used a syringe to take a portion of a sample from a vial and inject it into the instrument, to systems that would carry out some sample preparation tasks and then inject the sample<ref name="Agilent7693A">{{cite web \|url=https://www.agilent.com/en/video/7693a-video \|title=7693A Automated Liquid Sampler - Video \|publisher=Agilent Technologies, Inc \|accessdate=17 November 2023}}</ref>, to pneumatic tube-based systems<ref name="BaytekTT">{{cite web \|url=https://www.baytekinternational.com/products/turbotube \|title=TurboTube for Baytek LIMS software \|publisher=Baytek International \|accessdate=17 November 2023}}</ref> that would bring vials from a central holding area, inject the sample and then return the sample to holding, where it would be available for further work or disposal.

			The key to all this was the IDS computer and its programming that coordinated all these activities, acquired the data, and then processed it. Life was good as long as human intelligence evaluated the results, looked for anomalies, and took remedial action where needed. For a more detailed discussion of this subject please see ''[[LII:Notes on Instrument Data Systems\|Notes on Instrument Data Systems]]''.

			The instrument data system took us a long way toward an automated laboratory, but there was still some major hurdles to cross, including sample preparation, sample storage management, and systems integration. While much progress has been made, there is a lot more work to do.

			==Getting work done quickly and at a low cost==

Shawndouglas: Saving and adding more.

2023-11-18T00:00:03Z

Saving and adding more.

← Older revision		Revision as of 00:00, 18 November 2023
Line 218:		Line 218:
	\|}		\|}
	\|}		\|}

			====Spreadsheet software====
			Spreadsheets have benefited many applications that need easy-to-produce calculation and database systems for home, office, and administrative work. The word "laboratory" doesn't appear in that sentence because of the demands for data integrity in laboratory applications. Spreadsheet applications are easy to produce for calculations, graphs, etc. Their ease of use and openness to undocumented modifications make them a poor choice for routine calculations. They're attractive because of their simplicity of use and inherent power, but they prove inappropriate for their lack of controls over editing, lack of audit trails, etc. If you need a routine calculation package, it should be done according to standard software development guidelines. One major drawback is the difficulty of validating a spreadsheet, instituting controls, and ensuring that the scripting hasn’t been tampered with. Spreadsheets don't accommodate any of those requirements; spreadsheets are tools, and the applications need to be built. Purpose-built laboratory database systems such as LIMS, on the other hand, are much better equipped to handle those issues.

			Some have turned to developing "spreadsheet-based LIMS." This type of project development requires a formal software development effort; it's not just building a spreadsheet and populating it with data and formulas. Current industrial lab operations are subject to corporate and regulatory guidelines, and violating them can have serious repercussions, including shutting down the lab or production facility. Software development requires documentation, user requirement documents, design documents, user manuals, and materials to support the software. What looks like a fun project may become a significant part of your work. This impacts the cost factor; the development and support costs of a spreadsheet-based LIMS may occupy your entire time.

			Performance is another matter. Spreadsheet systems typically allow a single user at a time. They don't have the underlying database management support needed for simultaneous multi-user operations. This is one reason spreadsheet implementations give way to replacements with LIMS in industrial labs.

			For more on the topic of transitioning from paper to spreadsheets to LIMS, see the article "Improving Lab Systems: From Paper to Spreadsheets to LIMS."<ref name="LiscouskiImproving22">{{cite web \|url=https://www.lablynx.com/wp-content/uploads/2023/03/Improving-Lab-Systems-From-Paper-to-Spreadsheets-to-LIMS.pdf \|format=PDF \|title=Improving Lab Systems: From Paper to Spreadsheets to LIMS \|author=Liscouski, J. \|publisher=LabLynx, Inc \|date=April 2022 \|accessdate=17 November 2023}}</ref> This article will be helpful to you in considering a direction for laboratory informatics development and planning, describing the strengths and weaknesses of different approaches. It also contains references to regulatory compliance documents on the use of spreadsheets.

			====LIMS and ELN====
			The commercial software market has evaluated the needs of research and service laboratory operations and developed software specifically designed to address those points. LIMS was designed to meet the requirements of service laboratories such as QC testing, contract testing, analytical lab, and similar groups. The important item is not the name of the lab but its operational characteristics—the processes used—as described earlier. The same software systems could easily be at home in a research lab that conducts a lot of routine testing on samples. If the lab has sets of samples, it needs to keep track of testing, generating worklists, and reporting results on a continuing basis; a LIMS may well be appropriate for their work. It is designed for a highly structured operational environment as described earlier.

			ELNs are useful in an operational environment that is less structured, whose needs and direction may change and whose data storage and analysis requirements are more fluid. That is usually in labs designated as "research," but not exclusively. For example, an analytical lab doing method development could use an ELN to support that work.

			Both LIMS and ELNs are “top tier” levels of software. LIMS may be subordinate to an ELN in a research lab whose work includes routine testing. Functionality in the "Needs" list that is not part of the products (functionality is determined by the vendor, usually with customer input) can be supplied by offerings from third-party vendors. Those can consist of applications that can be linked to the LIMS and ELN, or be completely independent products.

			Table 2 describes characteristics of LIMS and ELN.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="70%"
			\|-
			\| colspan="2" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 2.''' Characteristics of LIMS and ELN
			\|-
			! style="padding-left:10px; padding-right:10px;" \|LIMS
			! style="padding-left:10px; padding-right:10px;" \|ELN
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|• LIMS has a well-defined database structure and the software components to work with it and support its underlying processes.<br />
			• It is purpose-built to manage sample logins, sample tracking, results entry, results tracking, reporting, etc. These comprise its core functionality.<br />
			• In addition, LIMS may include instrument maintenance databases, trend analysis, inventory, personnel records, etc.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|• ELNs have modules that can be organized to support projects and manage data according the research process used in that lab's work.<br />
			• Some ELNs, at the vendors discretion, will contain graphics modules, inventory modules, and links to third-party applications such as reaction databases, molecular modeling, and statistical analysis.
			\|-
			\|}
			\|}

			====Supporting tiers of software====


	==References==		==References==

Shawndouglas: Saving and adding more.

2023-11-17T23:31:46Z

Saving and adding more.

← Older revision		Revision as of 23:31, 17 November 2023
Line 169:		Line 169:
	This all culminates down to this: if you you produce data and information, do it through a proven (or even standardized) methodology; how else can you trust the results?		This all culminates down to this: if you you produce data and information, do it through a proven (or even standardized) methodology; how else can you trust the results?

	Sources for regulations affecting laboratories include:		Sources for regulations and guidelines affecting laboratories include:

	* '''FDA''': This includes [[21 CFR Part 11]] of the U.S. Code of Federal Regulations, which helps ensure security, integrity, and confidentially of electronic records.<ref name="CFR21_11">{{cite web \|url=https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 \|title=21 CFR Part 11 Electronic Records; Electronic Signatures \|work=Code of Federal Regulations \|publisher=National Archives \|date=11 November 2023 \|accessdate=17 November 2023}}</ref>		* '''FDA''': This includes [[21 CFR Part 11]] of the U.S. Code of Federal Regulations, which helps ensure security, integrity, and confidentially of electronic records.<ref name="CFR21_11">{{cite web \|url=https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 \|title=21 CFR Part 11 Electronic Records; Electronic Signatures \|work=Code of Federal Regulations \|publisher=National Archives \|date=11 November 2023 \|accessdate=17 November 2023}}</ref>
	* '''EPA''': This includes 40 CFR Part 792 on ~~Good Laboratory Practice Standards~~<ref name="CFR40_792">{{cite web \|url=https://www.ecfr.gov/current/title-40/chapter-I/subchapter-R/part-792 \|title=40 CFR Part 792 Good Laboratory Practice Standards \|work=Code of Federal Regulations \|publisher=National Archives \|date=15 November 2023 \|accessdate=17 November 2023}}</ref>		* '''EPA''': This includes 40 CFR Part 792 on good laboratory practice<ref name="CFR40_792">{{cite web \|url=https://www.ecfr.gov/current/title-40/chapter-I/subchapter-R/part-792 \|title=40 CFR Part 792 Good Laboratory Practice Standards \|work=Code of Federal Regulations \|publisher=National Archives \|date=15 November 2023 \|accessdate=17 November 2023}}</ref>
			* '''[[Centers for Medicare and Medicaid Services]] (CMS)''': This includes 42 CFR Part 493 on laboratory requirements for complying with the [[Clinical Laboratory Improvement Amendments]] (CLIA)<ref name="CFR42_493">{{cite web \|url=https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-G/part-493 \|title=42 CFR Part 493 Laboratory Requirements \|work=Code of Federal Regulations \|publisher=National Archives \|date=13 November 2023 \|accessdate=17 November 2023}}</ref>
			* '''International Society for Pharmaceutical Engineering (ISPE)''': This includes their work on [[Good Automated Manufacturing Practice]] (GAMP) guidance<ref name="ISPEWhatIsGAMP">{{cite web \|url=https://ispe.org/initiatives/regulatory/what-gamp \|title=What is GAMP? \|publisher=International Society for Pharmaceutical Engineering \|date=2023 \|accessdate=17 November 2023}}</ref>
			* '''American Association for Laboratory Accreditation (A2LA)''': This includes guidelines and accreditation requirements that labs must adhere to as part of accrediting to a particular standard. This includes standards like the [[ISO 9000]] family of standards and [[ISO/IEC 17025]]. The ISO 9000 family is a set of five QMS standards that help organizations ensure that they meet customer and other stakeholder needs within statutory and regulatory requirements related to a product or service. ISO/IEC 17025 ''General requirements for the competence of testing and calibration laboratories'' is the primary standard used by testing and calibration laboratories, and there are special technology considerations to be made when complying. (See ''[[LII:LIMS Selection Guide for ISO/IEC 17025 Laboratories\|LIMS Selection Guide for ISO/IEC 17025 Laboratories]]'' for more on this topic.) In most countries, ISO/IEC 17025 is the standard for which most labs must hold accreditation to be deemed technically competent.

			A comment should be made about the interplay of regulations, standards, and guidelines. The difference between regulations and standards is that regulations have the law to support their enforcement.<ref name="PankoninReg21">{{cite web \|url=https://www.aem.org/news/regulations-vs-standards-clearing-up-the-confusion \|title=Regulations vs. Standards: Clearing up the Confusion \|author=Pankonin, M. \|publisher=Association of Equipment Manufacturers \|date=27 May 2021 \|accessdate=17 November 2023}}</ref> Standards are consensus agreements that companies, industries, and associations use to define “best practices.” Guidelines are proposed standards of organizational behavior that may or may not eventually become regulations. The FDA regulations for example, began as guidelines, underwent discussion and modification, and eventually became regulations under 21 CFR Part 11. For a more nuanced discussion in one particular lab-related area, materials science, see ''[[LIMS FAQ:What standards and regulations affect a materials testing laboratory?\|What standards and regulations affect a materials testing laboratory?]]''.

			===Meeting the needs of data governance, data integrity, and regulatory compliance===
			Data governance, data integrity, and regulatory compliance are, to an extent, laboratory cultural issues. Your organization has to instill practices that contribute to meeting the requirements. Informatics tools can provide the means for executing the tasks to meet those needs. Still, first, it is a personnel consideration.

			The modern lab essentially has four ways of meeting those needs:

			* Paper-based record systems using forms and laboratory notebooks;
			* Spreadsheet software;
			* LIMS; and
			* ELN.

			''[[LII:The Application of Informatics to Scientific Work: Laboratory Informatics for Newbies\|The Application of Informatics to Scientific Work: Laboratory Informatics for Newbies]]'' addresses these four ways in detail, but we'll briefly discuss these points further here.

			Systems like LIMS, [[laboratory information system]]s (LIS), ELN, and LES can assist a lab in meeting regulatory requirements, standards, and guidelines by providing tools to meet enforcement requirements. For example, one common requirement is the need to provide an [[audit trail]] for data and information. (We'll discuss that in more detail later.) While the four product classes noted have audit trails built in, efforts to build a sample tracking system in a spreadsheet often do not have that capability as it would be difficult to implement. Beyond that, the original LES as envisioned by Velquest was intended to provide documented proof that a lab procedure was properly executed by qualified personnel, with qualified equipment and reagents, and documentation for all steps followed along with collected data and information. This again was designed to meet the expectations for a well-run lab.

			====Paper-based systems====
			Paper-based systems were once all we had, and they could adequately deal with all of the issues noted as they existed up to the early 1970s. Then, the demands of lab operations and growing regulatory compliance at the end of that decade developed a need for better tools. Compliance with laboratory practices depended on the organization’s enforcement. Enforcement failures led to the development of a formal, enforced regulatory program.

			The structure of lab operations changes due to the increasing availability of electronic data capture; having measurements in electronic form made them easier to work with if you had the systems in place to do so. Paper-based systems didn't lend themselves to that. You had to write results down on paper, and in order to later use those results you had to copy them to other documents or re-enter them into a program. In many cases, it was all people could afford, but that was a false economy as the cost of computer-based systems saved considerable time and effort. Electronic systems also afforded lab personnel a wider range of data analysis options, yielding more comprehensive work.

			Word processors represent one useful step up from paper-based systems, but word processors lack some of the flexibility of paper. Another drawback is ensuring compliance with regulations and guidelines. Since everything can be edited, an external mechanism has to be used to sign and witness entries. One possible workaround is to print off each day's work and have that signed. However, that simply inherits the problems with managing paper and makes audit trails difficult.

			An audit trail is a tool for keeping track of changes to data and information. People make mistakes, something changes, and an entry in a notebook or electronic system has to be corrected or updated. In the laboratory environment, you can't simply erase something or change an entry. Regulatory compliance, organizational guidelines, and data integrity requirements prevent that, which is part of the reason that entries have to be in ink to detect alterations. Changes are made in paper notebooks by lightly crossing out the old data (it still has to be readable), writing the updated information, noting the date and time of the change, why the change was made, and having the new entry signed and witnessed. That process acts as an audit trail, ensuring that results aren’t improperly altered. Paper-based systems require this voluntarily and should be enforced at the organizational level. Electronic laboratory systems do this as part of their design.

			Table 1 examines the pros and cons of using a paper-based system in the laboratory.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="100%"
			\|-
			\| colspan="2" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 1.''' The pros and cons of using a paper-based system in the laboratory
			\|-
			! style="padding-left:10px; padding-right:10px;" \|Pros
			! style="padding-left:10px; padding-right:10px;" \|Cons
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|• Low cost<br />• Easily transportable<br />• No power required<br />• Built-in backup copies<br />• High level of flexibility (writing, drawing, charts, etc.)<br />• Signature block for author/witness
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|• May be difficult to read<br />• Easily damaged, destroyed<br />• No/limited loss prevention<br />• Manual searches<br />• Data/information must be copied to be used<br />• Difficult to integrate with other users data<br />• High cost of use, everything is manual<br />• Audit practices are manual and either self or organizationally enforced
			\|-
			\|}
			\|}

	==References==		==References==