E13.15 - Analytical Data

SIGNIFICANCE AND USE
4.1 This practice permits an analyst to compare the performance of an NMR spectrometer for a particular test on any given day with the instrument's prior performance for that test. The practice can also provide sufficient quantitative performance information for problem diagnosis and solving. If complete information about how a test is carried out is supplied and sufficient replicates are collected to substantiate statistical relevance, the tests in this practice can be used to establish the setting and meeting of relevant performance specifications. This practice is not necessarily meant for the comparison of different instruments with each other, even if the instruments are of the same type and model. This practice is not meant for the comparison of the performance of different instruments operated under conditions differing from those specified for a particular test.
SCOPE
1.1 This practice covers procedures for measuring and reporting the performance of Fourier-transform nuclear magnetic resonance spectrometers (FT-NMRs) using liquid samples.  
1.2 This practice is not directly applicable to FT-NMR spectrometers outfitted to measure gaseous, anisotropically structured liquid, semi-solid, or solid samples; those set up to work with flowing sample streams; or those used to make hyperpolarization measurements.  
1.3 This practice was expressly developed for FT-NMR spectrometers operating with proton resonance frequencies between 200 MHz and 1200 MHz.  
1.4 This practice is not directly applicable to continuous wave (scanning) NMR spectrometers.  
1.5 This practice is not directly applicable to instruments using single-sideband detection.  
1.6 Units—The values stated in SI units are to be regarded as the standard. No other units of measurement are included in this standard.  
1.7 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety, health, and environmental practices and determine the applicability of regulatory limitations prior to use.  
1.8 This international standard was developed in accordance with internationally recognized principles on standardization established in the Decision on Principles for the Development of International Standards, Guides and Recommendations issued by the World Trade Organization Technical Barriers to Trade (TBT) Committee.

SIGNIFICANCE AND USE
6.1 General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the libraries in compiled binary form as part of a vendor’s application.  
6.1.1 Some vendors found that compilation using the huge memory model under Microsoft Windows on MS-DOS was needed because of an array pointer passing its boundary. Many vendors chose to write a conversion program as a stand-alone DOS application, whereby the conversion program used only text-mode screen I/O. Some vendors are now using it in their MS-Windows applications.  
6.1.2 Developers setting out to write a program to convert their data files to the Chromatographic Data Protocol should use the NetCDF utilities ncgen and ncdump. Applying the ncgen utility to the CHROMSTD.CDL template will generate the skeletal code needed to create the NetCDF file. The programmer can then modify the code to create a program that reads the netDCF file from another vendor. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation of the data files, and examine it to ensure the data is being correctly put into the file.  
6.2 Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point coprocessor and Microsoft Windows options.  
6.2.1 The protocol contain some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0 compiler manual should be consulted for the exact meaning of the compiler and linker options.  
6.2.2 The VMS and SunOS compilation instructions are in directories for those operatin...
SCOPE
1.1 This guide covers the implementation of the Chromatographic Data Protocol in analytical software applications. Implementation of this protocol requires:  
1.1.1 Specification E1947, which contains the full set of data definitions. The chromatographic data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation, so that implementations can change as technology evolves. The protocol is implemented in stages, to speed its acceptance through actual use.  
1.1.2 Specification E1947 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of chromatographic tests.  
1.2 The Analytical Information Categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.  
1.3 The NetCDF Data Interchange System is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.  
1.4 The Common Data Language (CDL) Template for Chromatography is a language specification of the chromatography dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.  
1.5 This international standard was developed in accordance with internationally recogn...

ABSTRACT
This specification covers an analytical data interchange protocol for chromatographic data representation and a software vehicle to affect the transfer of chromatographic data between instrument data systems. This protocol, which is designed to benefit users of analytical instruments and increase laboratory productivity and efficiency, provides a standardized format for the creation of raw data files or results files in the ".cdf" extension. The contents of the file include typical header in formation like instrument, column, detector, and operator description followed by raw or processed data, or both. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol. The end purpose of this protocol is intended to (1) transfer data between various vendors' instrument systems, (2) provide LIMS communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and ( 5) archive analytical data, or a combination thereof.
SCOPE
1.1 This specification covers a standardized format for chromatographic data representation and a software vehicle to effect the transfer of chromatographic data between instrument data systems. This specification provides protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.  
1.2 The protocol in this specification provides a standardized format for the creation of raw data files or results files. This standard format has the extension “.cdf” (derived from NetCDF). The contents of the file include typical header information like instrument, column, detector, and operator description followed by raw or processed data, or both. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol.  
1.3 The software transfer vehicle used for the protocol in this specification is NetCDF, which was developed by the Unidata Program and is funded by the Division of Atmospheric Sciences of the National Science Foundation.2  
1.4 The protocol in this specification is intended to (1) transfer data between various vendors' instrument systems, (2) provide LIMS communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof. The protocol is a consistent, vendor independent data format that facilitates the analytical data interchange for these activities.  
1.5 The protocol consists of:  
1.5.1 This specification on chromatographic data, which gives the full definitions for each one of the generic chromatographic data elements used in implementation of the protocol. It defines the analytical information categories, which are a convenient way for sorting analytical data elements to make them easier to standardize.  
1.5.2 Guide E1948 on chromatographic data, which gives the full details on how to implement the content of the protocol using the public-domain NetCDF data interchange system. It includes a brief introduction to using NetCDF. It is intended for software implementors, not those wanting to understand the definitions of data in a chromatographic dataset.  
1.5.3 NetCDF User’s Guide.  
1.6 This international standard was developed in accordance with internationally recognized principles on standardization established in the Decision on Principles for the Development of International Standards, Guides and Recommendations issued by the World Trade Organization Technical Barriers to Trade (TBT) Committee.

SIGNIFICANCE AND USE
4.1 Relevance—This guide is intended to educate the intended audience on many aspects of laboratory informatics. Specifically, the guide may:  
4.1.1 Help educate new users of laboratory informatics;  
4.1.2 Help educate general audiences in laboratories and other organizations that use laboratory informatics;  
4.1.3 Help educate instrument manufactures and producers of other commonly interfaced systems;  
4.1.4 Provide standard terminology that can be used by laboratory informatics vendors and end users;  
4.1.5 Establish a minimum set of requirements for primary laboratory informatics functions;  
4.1.6 Provide guidance on the tasks performed and documentation created in the specification, evaluation, cost justification, implementation, project management, training, and documentation of laboratory informatics; and  
4.1.7 Provide high-level guidance for the integration of laboratory informatics and other software tools.  
4.2 How to be Used—This guide is intended to be used by all stakeholders involved in any aspect of laboratory informatics implementation, use, or maintenance.  
4.2.1 It is intended to be used throughout the laboratory informatics life cycle by individuals or groups responsible for laboratory informatics implementation and use, including specification, build/configuration, validation, use, upgrades, and retirement/decommissioning.  
4.2.2 This guide also provides an example of a laboratory informatics functional requirements checklist that can be used to guide the purchase, upgrade, or development of a laboratory informatics system.
SCOPE
1.1 This guide helps describe the laboratory informatics landscape and covers issues commonly encountered at all stages in the life cycle of laboratory informatics from inception to retirement. It explains the evolution of laboratory informatics tools used in today’s laboratories such as laboratory information management systems (LIMS), laboratory execution systems (LES), laboratory information systems (LIS), electronic laboratory notebooks (ELN), scientific data management systems (SDMS), and chromatography data systems (CDS). It also covers the relationship (interactions) between these tools and the external systems in a given organization. The guide discusses supporting laboratory informatics tools and a wide variety of the issues commonly encountered at different stages in the life cycle. The subsections that follow describe the scope of this document in specific areas.  
1.2 High-Level Purpose—The purpose of this guide includes: (1) educating new users on laboratory informatics tools; (2) providing a standard terminology that can be used by different vendors and end users; (3) establishing minimum requirements for laboratory informatics; (4) providing guidance for the specification, evaluation, cost justification, implementation, project management, training, and documentation of the systems; and (5) providing a functional requirements checklist for laboratory informatics systems that can be adopted within the laboratory and integrated with existing systems.  
1.3 Laboratory Informatics Definition—Laboratory informatics is the specialized application of information technology aimed at optimizing laboratory operations. It is a collection of informatics tools utilized within laboratory environments to collect, store, process, analyze, report, and archive data and information from the laboratory and its supporting processes. Laboratory informatics includes the effective use of critical data management systems, the electronic delivery of results to customers, and the use and integration of supporting systems (for example, training and policy management). Examples of primary laboratory informatics tools include laboratory information management systems (LIMS), laboratory execution systems (LES), laboratory information systems (LIS), electronic laboratory notebooks (ELN), scientific data management systems (SDMS), and chromat...

ABSTRACT
This specification covers an analytical data interchange protocol for mass spectrometric data representation and a software vehicle to affect the transfer of mass spectrometric data between instrument data systems. This specification does not provide for the storage of data acquired simultaneous to and integrated with the mass spectrometric data, but on other detectors. The protocol, which is designed to benefit users of analytical instruments and increase laboratory productivity and efficiency, provides a standardized format for the creation of raw data files, library spectrum files or results files. This file, which has a ".cdf" extension, contains typical header information like instrument, sample, and acquisition method description, followed by raw, library, or processed data. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol. This protocol is intended to perform the following functions: (1) transfer data between various vendors' instrument systems; (2) provide Laboratory Information Management Systems (LIMS) communications; (3) link data to document processing applications; (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof.
SCOPE
1.1 This specification covers a standardized format for mass spectrometric data representation and a software vehicle to effect the transfer of mass spectrometric data between instrument data systems. This specification provides a protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.  
1.2 The protocol in this specification provides a standardized format for the creation of raw data files, library spectrum files or results files. This standard format has the extension “.cdf” (derived from NetCDF). The contents of the file include typical header information like instrument, sample, and acquisition method description, followed by raw, library or processed data. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol.  
1.3 This specification does not provide for the storage of data acquired simultaneous to and integrated with the mass spectrometric data, but on other detectors; for example attached to the mass spectrometer's liquid or gas chromatographic system. Related Specification E1947 and Guide E1948 describe the storage of 2-dimensional chromatographic data.  
1.4 The software transfer vehicle used for the protocol in this specification is NetCDF, which was developed by the Unidata Program and is funded by the Division of Atmospheric Sciences of the National Science Foundation.2  
1.5 The protocol in this specification is intended to (1) transfer data between various vendors' instrument systems, (2) provide Laboratory Information Management Systems (LIMS) communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof. The protocol is a consistent, vendor independent data format that facilitates the analytical data interchange for these activities.  
1.6 The protocol consists of:  
1.6.1 This specification on mass spectrometric data, which gives the full definitions for each one of the generic mass spectrometric data elements used in implementation of the protocol. It defines the analytical information categories, which are a convenient way for sorting analytical data elements to make them easier to standardize.  
1.6.2 Guide E2078 on mass spectrometric data, which gives the full details on how to implement the content of the protocol using the public-domain NetCDF data interchange system. It includes a brief introduction to using NetCDF and describes an API (Application Programming Interface) that is intended to be incorporated into application programs to read or write NetCDF files. I...

SIGNIFICANCE AND USE
7.1 General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the libraries in compiled binary form as part of a vendor's application.  
7.1.1 Developers setting out to write a program to convert their data files to the Mass Spectrometric Data Protocol should consider using the NetCDF utilities ncgen and ncdump. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation of the data file, and examine it to ensure the data are being correctly put into the file.  
7.2 Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point coprocessor and Microsoft Windows options.  
7.2.1 The protocol kit contains some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0 compiler manual should be consulted for the exact meaning of the compiler and linker options.  
7.2.2 The VMS and SunOS compilation instructions are in directories for those operating systems.  
7.3 NetCDF Library Build Order—The NetCDF libraries must be built in a specific order. The correct order to build the NetCDF directories is:
UTIL  
XDR  
SRC  
NCDUMP  
NCGEN  
NCTEST  
7.3.1 The UTIL and XDR makefiles work as distributed using NMAKE with Microsoft C V6.0.
SCOPE
1.1 This guide covers the implementation of the Mass Spectrometric Data Protocol in analytical software applications. Implementation of this protocol requires:  
1.1.1 Specification E2077, which contains the full set of data definitions. The mass spectrometric data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation so that implementations can change as technology evolves. The protocol is implemented in categories to speed its acceptance through actual use.  
1.1.2 Specification E2077 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of mass spectrometric tests.  
1.2 The analytical information categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.  
1.3 The network common data format (NetCDF) data interchange system is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.  
1.4 The common data language (CDL) template for mass spectrometry is a language specification of the mass spectrometry dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

SIGNIFICANCE AND USE
4.1 This practice permits an analyst to compare the performance of an NMR spectrometer for a particular test on any given day with the instrument's prior performance for that test. The practice can also provide sufficient quantitative performance information for problem diagnosis and solving. If complete information about how a test is carried out is supplied and sufficient replicates are collected to substantiate statistical relevance, the tests in this practice can be used to establish the setting and meeting of relevant performance specifications. This practice is not necessarily meant for the comparison of different instruments with each other, even if the instruments are of the same type and model. This practice is not meant for the comparison of the performance of different instruments operated under conditions differing from those specified for a particular test.
SCOPE
1.1 This practice covers procedures for measuring and reporting the performance of Fourier-transform nuclear magnetic resonance spectrometers (FT-NMRs) using liquid samples.  
1.2 This practice is not directly applicable to FT-NMR spectrometers outfitted to measure gaseous, anisotropically structured liquid, semi-solid, or solid samples; those set up to work with flowing sample streams; or those used to make hyperpolarization measurements.  
1.3 This practice was expressly developed for FT-NMR spectrometers operating with proton resonance frequencies between 200 and 1200 MHz.  
1.4 This practice is not directly applicable to continuous wave (scanning) NMR spectrometers.  
1.5 This practice is not directly applicable to instruments using single-sideband detection.  
1.6 Units—The values stated in SI units are to be regarded as the standard. No other units of measurement are included in this standard.  
1.7 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory limitations prior to use.

SIGNIFICANCE AND USE
6.1 General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the libraries in compiled binary form as part of a vendor's application.  
6.1.1 Some vendors found that compilation using the huge memory model under Microsoft Windows on MS-DOS was needed because of an array pointer passing its boundary. Many vendors chose to write a conversion program as a stand-alone DOS application, whereby the conversion program used only text-mode screen I/O. Some vendors are now using it in their MS-Windows applications.  
6.1.2 Developers setting out to write a program to convert their data files to the Chromatographic Data Protocol should use the NetCDF utilities ncgen and ncdump. Applying the ncgen utility to the CHROMSTD.CDL template will generate the skeletal code needed to create the NetCDF file. The programmer can then modify the code to create a program that reads the netDCF file from another vendor. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation of the data files, and examine it to ensure the data is being correctly put into the file.  
6.2 Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point coprocessor and Microsoft Windows options.  
6.2.1 The protocol contain some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0 compiler manual should be consulted for the exact meaning of the compiler and linker options.  
6.2.2 The VMS and SunOS compilation instructions are in directories for those operatin...
SCOPE
1.1 This guide covers the implementation of the Chromatographic Data Protocol in analytical software applications. Implementation of this protocol requires:  
1.1.1 Specification E1947, which contains the full set of data definitions. The chromatographic data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation, so that implementations can change as technology evolves. The protocol is implemented in stages, to speed its acceptance through actual use.  
1.1.2 Specification E1947 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of chromatographic tests.  
1.2 The Analytical Information Categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.  
1.3 The NetCDF Data Interchange System is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.  
1.4 The Common Data Language (CDL) Template for Chromatography is a language specification of the chromatography dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

ABSTRACT
This specification covers an analytical data interchange protocol for chromatographic data representation and a software vehicle to affect the transfer of chromatographic data between instrument data systems. This protocol, which is designed to benefit users of analytical instruments and increase laboratory productivity and efficiency, provides a standardized format for the creation of raw data files or results files in the ".cdf" extension. The contents of the file include typical header in formation like instrument, column, detector, and operator description followed by raw or processed data, or both. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol. The end purpose of this protocol is intended to (1) transfer data between various vendors' instrument systems, (2) provide LIMS communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and ( 5) archive analytical data, or a combination thereof.
SCOPE
1.1 This specification covers a standardized format for chromatographic data representation and a software vehicle to effect the transfer of chromatographic data between instrument data systems. This specification provides protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.  
1.2 The protocol in this specification provides a standardized format for the creation of raw data files or results files. This standard format has the extension “.cdf” (derived from NetCDF). The contents of the file include typical header information like instrument, column, detector, and operator description followed by raw or processed data, or both. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol.  
1.3 The software transfer vehicle used for the protocol in this specification is NetCDF, which was developed by the Unidata Program and is funded by the Division of Atmospheric Sciences of the National Science Foundation.2  
1.4 The protocol in this specification is intended to (1) transfer data between various vendors' instrument systems, (2) provide LIMS communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof. The protocol is a consistent, vendor independent data format that facilitates the analytical data interchange for these activities.  
1.5 The protocol consists of:  
1.5.1 This specification on chromatographic data, which gives the full definitions for each one of the generic chromatographic data elements used in implementation of the protocol. It defines the analytical information categories, which are a convenient way for sorting analytical data elements to make them easier to standardize.  
1.5.2 Guide E1948 on chromatographic data, which gives the full details on how to implement the content of the protocol using the public-domain NetCDF data interchange system. It includes a brief introduction to using NetCDF. It is intended for software implementors, not those wanting to understand the definitions of data in a chromatographic dataset.  
1.5.3 NetCDF User’s Guide.

SIGNIFICANCE AND USE
4.1 This practice permits an analyst to compare the performance of an NMR spectrometer for a particular test on any given day with the instrument's prior performance for that test. The practice can also provide sufficient quantitative performance information for problem diagnosis and solving. If complete information about how a test is carried out is supplied and sufficient replicates are collected to substantiate statistical relevance, the tests in this practice can be used to establish the setting and meeting of relevant performance specifications. This practice is not necessarily meant for the comparison of different instruments with each other, even if the instruments are of the same type and model. This practice is not meant for the comparison of the performance of different instruments operated under conditions differing from those specified for a particular test.
SCOPE
1.1 This practice covers procedures for measuring and reporting the performance of Fourier-transform nuclear magnetic resonance spectrometers (FT-NMRs) using liquid samples.  
1.2 This practice is not directly applicable to FT-NMR spectrometers outfitted to measure gaseous, anisotropically structured liquid, semi-solid, or solid samples; those set up to work with flowing sample streams; or those used to make hyperpolarization measurements.  
1.3 This practice was expressly developed for FT-NMR spectrometers operating with proton resonance frequencies between 200 and 1200 MHz.  
1.4 This practice is not directly applicable to continuous wave (scanning) NMR spectrometers.  
1.5 This practice is not directly applicable to instruments using single-sideband detection.  
1.6 Units—The values stated in SI units are to be regarded as the standard. No other units of measurement are included in this standard.  
1.7 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory limitations prior to use.

SIGNIFICANCE AND USE
4.1 Relevance—This guide is intended to educate those in the intended audience on many aspects of laboratory informatics. Specifically, the guide may:  
4.1.1 Help educate new users of laboratory informatics;  
4.1.2 Help educate general audiences in laboratories and other organizations that use laboratory informatics;  
4.1.3 Help educate instrument manufactures and producers of other commonly interfaced systems;  
4.1.4 Provide standard terminology that can be used by laboratory informatics vendors and end users;  
4.1.5 Establish a minimum set of requirements for primary laboratory informatics functions;  
4.1.6 Provide guidance on the tasks performed and documentation created in the specification, evaluation, cost justification, implementation, project management, training, and documentation of laboratory informatics; and  
4.1.7 Provide high-level guidance for the integration of laboratory informatics.  
4.2 How Used—This guide is intended to be used by all stakeholders involved in any aspect of laboratory informatics implementation, use or maintenance.  
4.2.1 It is intended to be used throughout the laboratory informatics life cycle by individuals or groups responsible for laboratory informatics including specification, build/configuration, validation, use, upgrades, retirement/decommissioning.  
4.2.2 It is also intended to provide an example of a laboratory informatics functions checklist.
SCOPE
1.1 This guide helps describe the laboratory informatics landscape and covers issues commonly encountered at all stages in the life cycle of laboratory informatics from inception to retirement. It explains the evolution of laboratory informatics tools used in today’s laboratories such as Laboratory Information Management Systems (LIMS), Electronic Laboratory Notebooks (ELN), Scientific Data Management Systems (SDMS), and Chromatography Data Systems (CDS). It also covers the relationship (interactions) between these tools and the external systems in a given organization. The guide discusses supporting laboratory informatics tools and a wide variety of the issues commonly encountered at different stages in the life cycle. The sub-sections that follow describe details of scope of this document in specific areas.  
1.2 High-Level Purpose—The purpose of this guide includes: (1) helping educate new users of laboratory informatics tools, (2) provide a standard terminology that can be used by different vendors and end users, (3) establish minimum requirements for laboratory informatics, (4) provide guidance for the specification, evaluation, cost justification, implementation, project management, training, and documentation of the systems, and (5) provide function checklist examples for laboratory informatics systems that can be adopted within the laboratory and integrated with the existing systems.  
1.3 Laboratory Informatics Definition—Laboratory informatics is the specialized application of information technology aimed at optimizing laboratory operations. It is a collection of informatics tools utilized within laboratory environments to collect, store, process, analyze, report, and archive data and information from the laboratory and supporting processes. Laboratory informatics includes the integration of systems, the electronic delivery of results to customers, and the supporting systems including training and policies. Examples of laboratory informatics include: Laboratory Information Management Systems (LIMS), Electronic Laboratory Notebooks (ELNs), Chromatography Data Systems (CDS), and Scientific Data Management Systems (SDMS).Note 1—Laboratory informatics scope encompasses multiple technical solutions or systems. The division between these system categories continues to soften as functionality continues to be added to each of them. LIMS were originally created to address the laboratories’ need to manage laboratory operations and data, provide traceability for all laboratory sam...

SIGNIFICANCE AND USE
General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the libraries in compiled binary form as part of a vendor's application.
Developers setting out to write a program to convert their data files to the Mass Spectrometric Data Protocol should consider using the NetCDF utilities ncgen and ncdump. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation of the data file, and examine it to ensure the data are being correctly put into the file.
Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point coprocessor and Microsoft Windows options.
The protocol kit contains some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0 compiler manual should be consulted for the exact meaning of the compiler and linker options.
The VMS and SunOS compilation instructions are in directories for those operating systems.
NetCDF Library Build Order—The NetCDF libraries must be built in a specific order. The correct order to build the NetCDF directories is:
UTIL XDR SRC NCDUMP NCGEN NCTEST
The UTIL and XDR makefiles work as distributed using NMAKE with Microsoft C V6.0.
SCOPE
1.1 This guide covers the implementation of the Mass Spectrometric Data Protocol in analytical software applications. Implementation of this protocol requires:
1.1.1 Specification E2077, which contains the full set of data definitions. The mass spectrometric data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation so that implementations can change as technology evolves. The protocol is implemented in categories to speed its acceptance through actual use.
1.1.2 Specification E2077 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of mass spectrometric tests.
1.2 The analytical information categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.
1.3 The network common data format (NetCDF) data interchange system is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.
1.4 The common data language (CDL) template for mass spectrometry is a language specification of the mass spectrometry dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

ABSTRACT
This specification covers an analytical data interchange protocol for mass spectrometric data representation and a software vehicle to affect the transfer of mass spectrometric data between instrument data systems. This specification does not provide for the storage of data acquired simultaneous to and integrated with the mass spectrometric data, but on other detectors. The protocol, which is designed to benefit users of analytical instruments and increase laboratory productivity and efficiency, provides a standardized format for the creation of raw data files, library spectrum files or results files. This file, which has a ".cdf" extension, contains typical header information like instrument, sample, and acquisition method description, followed by raw, library, or processed data. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol. This protocol is intended to perform the following functions: (1) transfer data between various vendors' instrument systems; (2) provide Laboratory Information Management Systems (LIMS) communications; (3) link data to document processing applications; (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof.
SCOPE
1.1 This specification covers a standardized format for mass spectrometric data representation and a software vehicle to effect the transfer of mass spectrometric data between instrument data systems. This specification provides a protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.
1.2 The protocol in this specification provides a standardized format for the creation of raw data files, library spectrum files or results files. This standard format has the extension “.cdf” (derived from NetCDF). The contents of the file include typical header information like instrument, sample, and acquisition method description, followed by raw, library or processed data. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol.
1.3 This specification does not provide for the storage of data acquired simultaneous to and integrated with the mass spectrometric data, but on other detectors; for example attached to the mass spectrometer's liquid or gas chromatographic system. Related Specification E1947 and Guide 1948E1948 describe the storage of 2-dimensional chromatographic data.
1.4 The software transfer vehicle used for the protocol in this specification is NetCDF, which was developed by the Unidata Program and is funded by the Division of Atmospheric Sciences of the National Science Foundation.  
1.5 The protocol in this specification is intended to (1) transfer data between various vendors' instrument systems, (2) provide Laboratory Information Management Systems (LIMS) communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof. The protocol is a consistent, vendor independent data format that facilitates the analytical data interchange for these activities.
1.6 The protocol consists of:
1.6.1 This specification on mass spectrometric data, which gives the full definitions for each one of the generic mass spectrometric data elements used in implementation of the protocol. It defines the analytical information categories, which are a convenient way for sorting analytical data elements to make them easier to standardize.  
1.6.2 Guide E2078 on mass spectrometric data, which gives the full details on how to implement the content of the protocol using the public-domain NetCDF data interchange system. It includes a brief introduction to using NetCDF and describes an API (Application Programming Interface) that is intended to be incorporated into application programs to read or write NetCDF files. It ...

SIGNIFICANCE AND USE
General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the libraries in compiled binary form as part of a vendor's application.
Some vendors found that compilation using the huge memory model under Microsoft Windows on MS-DOS was needed because of an array pointer passing its boundary. Many vendors chose to write a conversion program as a stand-alone DOS application, whereby the conversion program used only text-mode screen I/O. Some vendors are now using it in their MS-Windows applications.  
Developers setting out to write a program to convert their data files to the Chromatographic Data Protocol should use the NetCDF utilities ncgen and ncdump. Applying the ncgen utility to the CHROMSTD.CDL template will generate the skeletal code needed to create the NetCDF file. The programmer can then modify the code to create a program that reads the netDCF file from another vendor. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation of the data files, and examine it to ensure the data is being correctly put into the file.
Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point coprocessor and Microsoft Windows options.
The protocol contain some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0 compiler manual should be consulted for the exact meaning of the compiler and linker options.  
The VMS and SunOS compilation instructions are in directories for those operating systems.
SCOPE
1.1 This guide covers the implementation of the Chromatographic Data Protocol in analytical software applications. Implementation of this protocol requires:
1.1.1 Specification E1947, which contains the full set of data definitions. The chromatographic data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation, so that implementations can change as technology evolves. The protocol is implemented in stages, to speed its acceptance through actual use.
1.1.2 Specification E1947 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of chromatographic tests.
1.2 The Analytical Information Categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.
1.3 The NetCDF Data Interchange System is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.
1.4 The Common Data Language (CDL) Template for Chromatography is a language specification of the chromatography dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

ABSTRACT
This specification covers an analytical data interchange protocol for chromatographic data representation and a software vehicle to affect the transfer of chromatographic data between instrument data systems. This protocol, which is designed to benefit users of analytical instruments and increase laboratory productivity and efficiency, provides a standardized format for the creation of raw data files or results files in the ".cdf" extension. The contents of the file include typical header in formation like instrument, column, detector, and operator description followed by raw or processed data, or both. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol. The end purpose of this protocol is intended to (1) transfer data between various vendors' instrument systems, (2) provide LIMS communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and ( 5) archive analytical data, or a combination thereof.
SCOPE
1.1 This specification covers a standardized format for chromatographic data representation and a software vehicle to effect the transfer of chromatographic data between instrument data systems. This specification provides protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.
1.2 The protocol in this specification provides a standardized format for the creation of raw data files or results files. This standard format has the extension “.cdf” (derived from NetCDF). The contents of the file include typical header information like instrument, column, detector, and operator description followed by raw or processed data, or both. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol.
1.3 The software transfer vehicle used for the protocol in this specification is NetCDF, which was developed by the Unidata Program and is funded by the Division of Atmospheric Sciences of the National Science Foundation.  
1.4 The protocol in this specification is intended to (1) transfer data between various vendors' instrument systems, (2) provide LIMS communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and ( 5) archive analytical data, or a combination thereof. The protocol is a consistent, vendor independent data format that facilitates the analytical data interchange for these activities.
1.5 The protocol consists of:
1.5.1 This specification on chromatographic data, which gives the full definitions for each one of the generic chromatographic data elements used in implementation of the protocol. It defines the analytical information categories, which are a convenient way for sorting analytical data elements to make them easier to standardize.
1.5.2 Guide E1948 on chromatographic data, which gives the full details on how to implement the content of the protocol using the public-domain NetCDF data interchange system. It includes a brief introduction to using NetCDF. It is intended for software implementors, not those wanting to understand the definitions of data in a chromatographic dataset.
1.5.3 NetCDF User's Guide .

SIGNIFICANCE AND USE
Relevance—This guide is intended to educate those in the intended audience on many aspects of LIMS. Specifically, the guide may:
4.1.1 Help educate new users of LIMS;
4.1.2 Help educate general audiences in laboratories and other organizations that use LIMS;
4.1.3 Help educate instrument manufactures and producers of other commonly interfaced systems;
4.1.4 Provide standard terminology that can be used by LIMS vendors and end users;
4.1.5 Establish a minimum set of requirements for primary LIMS functions;
4.1.6 Provide guidance on the tasks performed and documentation created in the specification, evaluation, cost justification, implementation, project management, training, and documentation of LIMS; and
4.1.7 Provide high-level guidance for the integration of LIMS with the most commonly integrated systems such as laboratory instruments, CDS, ERP, ELN, SDMS and so forth.
How Used—This guide is intended to be used by all stakeholders involved in any aspect of LIMS implementation or maintenance.
4.2.1 It is intended to be used throughout the LIMS life cycle by individuals or groups responsible for LIMS including specification, build/configuration, validation, use, upgrades, retirement/decommissioning.
4.2.2 It is also intended to provide an example of a LIMS function checklist.
SCOPE
1.1 This guide covers issues commonly encountered at all stages in the life cycle of Laboratory Information Management Systems from inception to retirement. The sub-sections that follow describe details of scope of this document in specific areas.
1.2 High Level PurposeThe purpose of this guide includes: (1) help educate new users of Laboratory Information Management Systems (LIMS), (2) provide standard terminology that can be used by LIMS vendors and end users, (3) establish minimum requirements for primary LIMS functions, (4) provide guidance for the specification, evaluation, cost justification, implementation, project management, training, and documentation, and (5) provide an example of a LIMS function checklist.
1.3 LIMS DefinitionThe term Laboratory Information Management Systems (LIMS) describes the class of computer systems designed to manage laboratory information.
1.4 Laboratory CategoriesThe spectrum of laboratories that employ LIMS is wide spread. The following break down provides an overview of the laboratory categories that use LIMS as well as examples of laboratories in each category.
1.4.1 General Laboratories
Standards (ASTM, IEEE, ISO), and
Government (EPA, FDA, JPL, NASA, NRC, USDA, FERC).
1.4.2 Environmental
Environmental Monitoring.
1.4.3 Life Science Laboratories
Biotechnology,
Diagnostic,
Healthcare Medical,
Devices, and
Pharmaceuticals Vet/Animal.
1.4.4 Heavy Industry Laboratories
Energy Resources,
Manufacturing Construction,
Materials Chemicals, and
Transportation Shipping.
1.4.5 Food Beverage Laboratories
Agriculture,
Beverages,
Food, and
Food Service Hospitality.
1.4.6 Public Sector Laboratories
Law Enforcement,
State Local Government,
Education, and
Public Utilities (Water, Electric, Waste Treatment).
1.4.7 Laboratory Size
This guide covers topics regarding LIMS for a range of laboratory sizes ranging from small with simple requirements to large multi-site/global laboratories with complex requirements. Although the guide addresses complex issues that impact primarily large LIMS implementations, laboratories of all sizes will find this guide useful. The implementation times and recommendations listed in this guide are directed at medium and large laboratories.
1.5 IntegrationIntegration between LIMS and other external systems (document management, chromatography data systems, laboratory instruments, spectroscopic data systems, Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES), Corrective Action and Preventative Action (CAPA), Electronic Laboratory Notebooks (ELNs) and data archive) provides significant business...

SIGNIFICANCE AND USE
General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the libraries in compiled binary form as part of a vendor’application.
7.1.1 Developers setting out to write a program to convert their data files to the Mass Spectrometric Data Protocol should consider using the NetCDF utilities ncgen and ncdump. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation of the data file, and examine it to ensure the data are being correctly put into the file.
Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point coprocessor and Microsoft Windows options.
7.2.1 The protocol kit contains some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0 compiler manual should be consulted for the exact meaning of the compiler and linker options.
7.2.2 The VMS and SunOS compilation instructions are in directories for those operating systems.
NetCDF Library Build Order—The NetCDF libraries must be built in a specific order. The correct order to build the NetCDF directories is:
UTIL XDR SRC NCDUMP NCGEN NCTEST
7.3.1 The UTIL and XDR makefiles work as distributed using NMAKE with Microsoft C V6.0.
SCOPE
1.1 This guide covers the implementation of the Mass Spectrometric Data Protocol in analytical software applications. Implementation of this protocol requires:
1.1.1 Specification E 2077, which contains the full set of data definitions. The mass spectrometric data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation so that implementations can change as technology evolves. The protocol is implemented in categories to speed its acceptance through actual use.
1.1.2 Specification E 2077 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of mass spectrometric tests.
1.2 The analytical information categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.
1.3 The network common data format (NetCDF) data interchange system is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.
1.4 The common data language (CDL) template for mass spectrometry is a language specification of the mass spectrometry dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

ABSTRACT
This specification covers an analytical data interchange protocol for mass spectrometric data representation and a software vehicle to affect the transfer of mass spectrometric data between instrument data systems. This specification does not provide for the storage of data acquired simultaneous to and integrated with the mass spectrometric data, but on other detectors. The protocol, which is designed to benefit users of analytical instruments and increase laboratory productivity and efficiency, provides a standardized format for the creation of raw data files, library spectrum files or results files. This file, which has a ".cdf" extension, contains typical header information like instrument, sample, and acquisition method description, followed by raw, library, or processed data. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol. This protocol is intended to perform the following functions: (1) transfer data between various vendors' instrument systems; (2) provide Laboratory Information Management Systems (LIMS) communications; (3) link data to document processing applications; (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof.
SCOPE
1.1 This specification covers a standardized format for mass spectrometric data representation and a software vehicle to effect the transfer of mass spectrometric data between instrument data systems. This specification provides a protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.
1.2 The protocol in this specification provides a standardized format for the creation of raw data files, library spectrum files or results files. This standard format has the extension ".cdf" (derived from NetCDF). The contents of the file include typical header information like instrument, sample, and acquisition method description, followed by raw, library or processed data. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol.
1.3 This specification does not provide for the storage of data acquired simultaneous to and integrated with the mass spectrometric data, but on other detectors; for example attached to the mass spectrometer's liquid or gas chromatographic system. Related Specification E 1947 and Guide 1948 describe the storage of 2-dimensional chromatographic data.
1.4 The software transfer vehicle used for the protocol in this specification is NetCDF, which was developed by the Unidata Program and is funded by the Division of Atmospheric Sciences of the National Science Foundation.
1.5 The protocol in this specification is intended to (1) transfer data between various vendors' instrument systems, (2) provide Laboratory Information Management Systems (LIMS) communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof. The protocol is a consistent, vendor independent data format that facilitates the analytical data interchange for these activities.
1.6 The protocol consists of:
1.6.1 This specification on mass spectrometric data, which gives the full definitions for each one of the generic mass spectrometric data elements used in implementation of the protocol. It defines the analytical information categories, which are a convenient way for sorting analytical data elements to make them easier to standardize.
1.6.2 Guide E 2078 on mass spectrometric data, which gives the full details on how to implement the content of the protocol using the public-domain NetCDF data interchange system. It includes a brief introduction to using NetCDF and describes an API (Application Programming Interface) that is intended to be incorporated into application programs to read or write NetCDF files. It is intended...

ABSTRACT
This practice elaborates on the different types, definition of basic operational terms, conventions, referencing procedures and substances, and terms and recommended means for signal-to-noise ratio determination and data presentation in the area of high-resolution nuclear magnetic resonance (NMR) spectroscopy. Some of the basic definitions apply to wide-line NMR or to NMR of metals, but this practice is generally not intended to cover these latter areas of NMR. Also, this version does not include definitions pertaining to double resonance, nor to rotating frame experiments.
SCOPE
1.1 This standard contains definitions of basic terms, conventions, and recommended practices for data presentation in the area of high-resolution NMR spectroscopy. Some of the basic definitions apply to wide-line NMR or to NMR of metals, but in general it is not intended to cover these latter areas of NMR in this standard. This version does not include definitions pertaining to double resonance nor to rotating frame experiments.

ABSTRACT
This specification covers an analytical data interchange protocol for chromatographic data representation and a software vehicle to affect the transfer of chromatographic data between instrument data systems. This protocol, which is designed to benefit users of analytical instruments and increase laboratory productivity and efficiency, provides a standardized format for the creation of raw data files or results files in the ".cdf" extension. The contents of the file include typical header in formation like instrument, column, detector, and operator description followed by raw or processed data, or both. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol. The end purpose of this protocol is intended to (1) transfer data between various vendors' instrument systems, (2) provide LIMS communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and ( 5) archive analytical data, or a combination thereof.
SCOPE
1.1 This specification covers a standardized format for chromatographic data representation and a software vehicle to effect the transfer of chromatographic data between instrument data systems. This specification provides protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.

SCOPE
1.1 This guide covers the implementation of the Chromatographic Data Protocol in analytical software applications. Implementation of this protocol requires:
1.1.1 Specification E 1947, which contains the full set of data definitions. The chromatographic data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation, so that implementations can change as technology evolves. The protocol is implemented in stages, to speed its acceptance through actual use.
1.1.2 Specification E 1947 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of chromatographic tests.
1.2 The Analytical Information Categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.
1.3 The NetCDF Data Interchange System is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.
1.4 The Common Data Language (CDL) Template for Chromatography is a language specification of the chromatography dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

SCOPE
1.1 This guide covers the implementation of the Mass Spectrometric Data Protocol in analytical software applications. Implementation of this protocol requires:
1.1.1 Specification E 2077, which contains the full set of data definitions. The mass spectrometric data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation so that implementations can change as technology evolves. The protocol is implemented in categories to speed its acceptance through actual use.
1.1.2 Specification E 2077 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of mass spectrometric tests.
1.2 The analytical information categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.
1.3 The network common data format (NetCDF) data interchange system is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.
1.4 The common data language (CDL) template for mass spectrometry is a language specification of the mass spectrometry dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

SCOPE
1.1 This specification covers a standardized format for mass spectrometric data representation and a software vehicle to effect the transfer of mass spectrometric data between instrument data systems. This specification provides a protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.
1.2 The protocol in this specification provides a standardized format for the creation of raw data files, library spectrum files or results files. This standard format has the extension ".cdf" (derived from NetCDF). The contents of the file include typical header information like instrument, sample, and acquisition method description, followed by raw, library or processed data. Once data have been written or converted to this protocol, they can be read and processed by software packages that support the protocol.
1.3 This specification does not provide for the storage of data acquired simultaneous to and integrated with the mass spectrometric data, but on other detectors; for example attached to the mass spectrometer's liquid or gas chromatographic system. Related Specification E 1947 and Guide 1948 describe the storage of 2-dimensional chromatographic data.
1.4 The software transfer vehicle used for the protocol in this specification is NetCDF, which was developed by the Unidata Program and is funded by the Division of Atmospheric Sciences of the National Science Foundation.
1.5 The protocol in this specification is intended to (1) transfer data between various vendors' instrument systems, (2) provide Laboratory Information Management Systems (LIMS) communications, (3) link data to document processing applications, (4) link data to spreadsheet applications, and (5) archive analytical data, or a combination thereof. The protocol is a consistent, vendor independent data format that facilitates the analytical data interchange for these activities.
1.6 The protocol consists of:
1.6.1 This specification on mass spectrometric data, which gives the full definitions for each one of the generic mass spectrometric data elements used in implementation of the protocol. It defines the analytical information categories, which are a convenient way for sorting analytical data elements to make them easier to standardize.
1.6.2 Guide E 2078 on mass spectrometric data, which gives the full details on how to implement the content of the protocol using the public-domain NetCDF data interchange system. It includes a brief introduction to using NetCDF and describes an API (Application Programming Interface) that is intended to be incorporated into application programs to read or write NetCDF files. It is intended for software implementors, not those wanting to understand the definitions of data in a mass spectrometric dataset.
1.6.3 NetCDF Users Guide.

SCOPE
1.1 This guide describes an approach to the validation process for a Laboratory Information Management System (LIMS).
1.2 This guide is for validation of a commercial LIMS purchased from a vendor. The procedures may apply to other types of systems, but this guide makes no claim to address all issues for other types of systems. Further, in-house developed LIMS, that is, those developed by internal or external programmers specifically for an organization, can utilize this guide. It should be noted that there are a number of related software development issues that this guide does not address. Users who embark on developing a LIMS either internally or with external programmers also should consult the appropriate ASTM, ISO, and IEEE software development standards.
1.3 This guide is intended to educate individuals on LIMS validation, to provide standard terminology useful in discussions with independent validation consultants, and to provide guidance for development of validation plans, test plans, required standard operating procedures, and the final validation report.

SCOPE
1.1 This guide describes computer systems used to manage laboratory information. The term Laboratory Information Management Systems (LIMS) describes this class of computer systems.  
1.2 This guide covers LIMS ranging from small laboratories with simple requirements to large multi-site laboratories with complex requirements. The elements of the LIMS guide may be selected based on specific laboratory requirements.  
1.3 The audience of this document includes: (1) end users of LIMS, (2) implementers of LIMS, (3) LIMS vendors, (4) instrument vendors, and (5) individuals who must approve LIMS funding.  
1.4 The purpose of this guide includes: (1) help educate new users of Laboratory Information Management Systems (LIMS), (2) provide standard terminology that can be used by LIMS vendors and end users, (3) establish minimum requirements for primary LIMS functions, (4) provide guidance for the specification, evaluation, cost justification, implementation, project management, training, and documentation, and (5) provide an example of a LIMS function checklist.  
1.5 Information contained in this guide will benefit a broad audience of people who work or interact with a laboratory. New LIMS users can use this guide to understand the purpose and functions of LIMS. The guide can help prospective LIMS users in understanding terminology, configurations, features, design, and costs. Individuals who are purchasing a LIMS can use this guide to identify functions that are recommended for specific laboratory environments. LIMS vendor Research and Development staffs can use the guide as a tool to evaluate, identify, and correct areas that need improvement. LIMS vendor sales staffs can use the guide to accurately represent functions of their LIMS product to prospective customers. This guide does not define laboratory instrument interfaces.  
1.6 This guide can be used by laboratories of all sizes. The guide addresses complex issues that impact primarily large LIMS implementations. Small laboratories should review issues that may impact their environments. The implementation times and recommendations listed in this guide are directed at medium and large laboratories.

SCOPE
1.1 This specification covers deterministic remote control of laboratory equipment in an automated laboratory. The labor-intensive process of integrating different equipment into an automated system is a primary problem in laboratory automation today. Hardware and software standards are needed to facilitate equipment integration thereby significantly reduce the cost and effort to develop fully automated laboratories.
1.2 This Laboratory Equipment Control Interface Specification (LECIS) describes a set of standard equipment behaviors that must be accessible under remote control to set up and operate laboratory equipment in an automated laboratory. The remote control of the standard behaviors is defined as standard interactions that define the dialogue between the equipment and the control system that is necessary to coordinate operation. The interactions are described with state models in which individual states are defined for specific, discrete equipment behaviors. The interactions are designed to be independent of both the equipment and its function. Standard message exchanges are defined independently of any specific physical communication links or protocols for messages passing between the control system and the equipment.
1.3 This specification is derived from the General Equipment Interface Definition developed by the Intelligent Systems and Robotics Center at Sandia National Laboratory, the National Institute of Standards Technologies' Consortium on Automated Analytical Laboratory Systems (CAALS) High-Level Communication Protocol, the CAALS Common Command Set, and the NISTIR 6294 (1-4). This LECIS specification was written, implemented, and tested by the Robotics and Automation Group at Los Alamos National Laboratory.
1.4 Equipment Requirements-LECIS defines the remote control from a Task Sequence Controller (TSC) of devices exhibiting standard behaviors of laboratory equipment that meet the NIST CAALS requirements for Standard Laboratory Modules (SLMs) (5). These requirements are described in detail in Refs (3, 4). The requirements are:
1.4.1 Predictable, deterministic behavior,
1.4.2 Ability to be remotely controlled through a standard bidirectional communication link and protocol,
1.4.3 Maintenance of remote communication even under local control,
1.4.4 Single point of logical control,
1.4.5 Universal unique identifier,
1.4.6 Status information available at all times,
1.4.7 Use of appropriate standards including the standard message exchange in this LECIS,
1.4.8 Autonomy in operation (asynchronous operation with the TSC),
1.4.9 Perturbation handling,
1.4.10 Resource management
1.4.11 Buffered inputs an outputs,
1.4.12 Automated access to material ports,
1.4.13 Exception monitoring and reporting,
1.4.14 Data exchange via robust protocol,
1.4.15 Fail-safe operation,
1.4.16 Programmable configurations (for example, I/O ports),
1.4.17 Independent power-up order, and
1.4.18 Safe start-up behavior.

SCOPE
1.1 This guide covers the implementation of the Chromatographic Data Protocol in analytical software applications.

SCOPE
1.1 This specification covers a standardized format for chromatographic data representation and a software vehicle to effect the transfer of chromatographic data between instrument data systems. This specification provides protocol designed to benefit users of analytical instruments and increase laboratory productivity and efficiency.

SIGNIFICANCE AND USE
Validation is an important and mandatory activity for laboratories that fall under regulatory agency review. Such laboratories produce data upon which the government depends to enforce laws and make decisions in the public interest. Examples include data to support approval of new drugs, prove marketed drugs meet specifications, enforce environmental laws, and develop forensic evidence for trial. This also extends to LIMS used in environmental laboratories. In some cases these systems may need to be interoperable with CLIMS and computer-based patient records (CPR) for reporting environmental exposures and clinical laboratory testing for biologic measure of stressor exposure. The enormous financial, legal, and social impact of these decisions requires government and public confidence in laboratory data. To ensure this confidence, government agencies regularly review laboratories operating under their rules to confirm that they are producing valid data. Computer system validation is a part of this review. This guide is designed to aid users validating LIMS and incorporating the validation process into their LIMS life cycle.
Validation must provide evidence of testing, training, audit and review, management responsibility, design control, and document control, both during the development of the system and its operation life (2).
SCOPE
1.1 This guide describes an approach to the validation process for a Laboratory Information Management System (LIMS).
1.2 This guide is for validation of a commercial LIMS purchased from a vendor. The procedures may apply to other types of systems, but this guide makes no claim to address all issues for other types of systems. Further, in-house developed LIMS, that is, those developed by internal or external programmers specifically for an organization, can utilize this guide. It should be noted that there are a number of related software development issues that this guide does not address. Users who embark on developing a LIMS either internally or with external programmers also should consult the appropriate ASTM, ISO, and IEEE software development standards.
1.3 This guide is intended to educate individuals on LIMS validation, to provide standard terminology useful in discussions with independent validation consultants, and to provide guidance for development of validation plans, test plans, required standard operating procedures, and the final validation report.
WITHDRAWN RATIONALE
This guide describes an approach to the validation process for a Laboratory Information Management System (LIMS).
Formerly under the jurisdiction of Committee E13 on Molecular Spectroscopy and Separation Science, this guide was withdrawn in September 2015. This standard is being withdrawn without replacement due to its limited use by industry.

ABSTRACT
This practice elaborates on the different types, definition of basic operational terms, conventions, referencing procedures and substances, and terms and recommended means for signal-to-noise ratio determination and data presentation in the area of high-resolution nuclear magnetic resonance (NMR) spectroscopy. Some of the basic definitions apply to wide-line NMR or to NMR of metals, but this practice is generally not intended to cover these latter areas of NMR. Also, this version does not include definitions pertaining to double resonance, nor to rotating frame experiments.
SCOPE
1.1 This standard contains definitions of basic terms, conventions, and recommended practices for data presentation in the area of high-resolution resolution nuclear magnetic resonance (NMR) spectroscopy. Some of the basic definitions apply to wide-line NMR or to NMR of metals, but in general it is not intended to cover these latter areas of NMR in this standard. This version does not include definitions pertaining to double resonance nor to rotating frame experiments.
1.2 The values stated in SI units are to be regarded as standard. No other units of measurement are included in this standard.
WITHDRAWN RATIONALE
This standard contains definitions of basic terms, conventions, and recommended practices for data presentation in the area of high-resolution resolution nuclear magnetic resonance (NMR) spectroscopy. Some of the basic definitions apply to wide-line NMR or to NMR of metals, but in general it is not intended to cover these latter areas of NMR in this standard. This version does not include definitions pertaining to double resonance nor to rotating frame experiments.
Formerly under the jurisdiction of Committee E13 on Molecular Spectroscopy and Separation Science, this practice was withdrawn in September 2015 and replaced by Practice E2977 for Measuring and Reporting Performance of Fourier-Transform Nuclear Magnetic Resonance (FT-NMR) Spectrometers for Liquid Samples.1

ABSTRACT
This specification describes the Laboratory Equipment Control Interface Specification (LECIS). This is a set of standard equipment behaviors that must be accessible under remote control to set up and operate laboratory equipment in an automated laboratory. Discussed intensively herein are the equipment requirements, notations and general message syntaxes, control paradigms, message transactions, communication maintenance and locus of control, operational management, sample loading and processing, and error and exception handling.
SCOPE
1.1 This specification covers deterministic remote control of laboratory equipment in an automated laboratory. The labor-intensive process of integrating different equipment into an automated system is a primary problem in laboratory automation today. Hardware and software standards are needed to facilitate equipment integration thereby significantly reduce the cost and effort to develop fully automated laboratories.
1.2 This Laboratory Equipment Control Interface Specification (LECIS) describes a set of standard equipment behaviors that must be accessible under remote control to set up and operate laboratory equipment in an automated laboratory. The remote control of the standard behaviors is defined as standard interactions that define the dialogue between the equipment and the control system that is necessary to coordinate operation. The interactions are described with state models in which individual states are defined for specific, discrete equipment behaviors. The interactions are designed to be independent of both the equipment and its function. Standard message exchanges are defined independently of any specific physical communication links or protocols for messages passing between the control system and the equipment.
1.3 This specification is derived from the General Equipment Interface Definition developed by the Intelligent Systems and Robotics Center at Sandia National Laboratory, the National Institute of Standards Technologies' Consortium on Automated Analytical Laboratory Systems (CAALS) High-Level Communication Protocol, the CAALS Common Command Set, and the NISTIR 6294 (1-4). This LECIS specification was written, implemented, and tested by the Robotics and Automation Group at Los Alamos National Laboratory.
1.4 Equipment Requirements-LECIS defines the remote control from a Task Sequence Controller (TSC) of devices exhibiting standard behaviors of laboratory equipment that meet the NIST CAALS requirements for Standard Laboratory Modules (SLMs) (5). These requirements are described in detail in Refs (3, 4). The requirements are:
1.4.1 Predictable, deterministic behavior,
1.4.2 Ability to be remotely controlled through a standard bidirectional communication link and protocol,
1.4.3 Maintenance of remote communication even under local control,
1.4.4 Single point of logical control,
1.4.5 Universal unique identifier,
1.4.6 Status information available at all times,
1.4.7 Use of appropriate standards including the standard message exchange in this LECIS,
1.4.8 Autonomy in operation (asynchronous operation with the TSC),
1.4.9 Perturbation handling,
1.4.10 Resource management
1.4.11 Buffered inputs an outputs,
1.4.12 Automated access to material ports,
1.4.13 Exception monitoring and reporting,
1.4.14 Data exchange via robust protocol,
1.4.15 Fail-safe operation,
1.4.16 Programmable configurations (for example, I/O ports),
1.4.17 Independent power-up order, and
1.4.18 Safe start-up behavior.
WITHDRAWN RATIONALE
This specification covers deterministic remote control of laboratory equipment in an automated laboratory.
Formerly under the jurisdiction of Committee E13 on Molecular Spectroscopy and Chromatography, this specification was withdrawn in 2009. This standard was withdrawn without replacement because it has become obsolete to the industry and is not being used.