A/C INTERFACE
Architecture for a Comprehensive Laboratory Information Management System
Robert D. McDowall Department of Bioanalytical Sciences Wellcome Research Laboratories Langley Court, Beckenham Kent BR3 3BS U.K.
Donald C. Mattes Department of Information Sciences SmithKline Beecham Pharmaceuticals MS-L331, 709 Swedeland Road Swedeland, PA 19479
The need to improve the performance of analytical laboratories in terms of the quality and quantity of information output has been a driving force in implementing automated systems. Laboratory Information Management Systems (LIMS) are used to improve productivity through the automation of administrative tasks and routine laboratory procedures. However, a large number of LIMS installations have failed to meet initial expectations, which implies that LIMS are not fully understood. Many organizations that 0003-2700/90/A362-1069/$02.50/0 © 1990 American Chemical Society
have a limited view of LIMS have missed opportunities for significant scientific and business benefits. To address these problems and to provide a basis for the development of the next generation of laboratory information management, we will define a LIMS model. This model provides a standard description of the scope of a LIMS as well as a tool that will aid analysts in defining, acquiring, and developing a LIMS for their specific laboratory requirements. The current misconceptions regarding LIMS cannot be resolved by existing literature definitions (1-4). Although these definitions are useful, a major weakness is their focus on the end results of a LIMS rather than consideration of the required functions and structure. They discuss the effect of LIMS without an explanation or understanding of the cause. This leaves a deficiency in our understanding, which may be compared with defining wind as "the thing that makes leaves on trees move." Current LIMS definitions give
us a vision of the accomplishments and the benefits without the understanding and insight necessary to implement a system. This lack of definition, combined with the variations in actual laboratory operation, results in LIMS meaning different things to different people. Answering the question "What is a LIMS?" still requires a significant amount of work to produce a description that is concise, accurate, and applicable to a variety of laboratories.
Strategic design The development of a LIMS model is similar to the initial design stages of an actual system. The key for designing a LIMS successfully is to define which functions within an organization a LIMS should automate and where in the organization the benefits of automated information management should be realized. Data and information domains. The benefits of a LIMS fall into two major areas: the data and the information domains. In the data domain the
ANALYTICAL CHEMISTRY, VOL. 62, NO. 20, OCTOBER 15, 1990 · 1069 A
INTERFACE
The model
Designed to meet the strategic require ments of managing and integrating both the data and information domains, the model provides a clear scope and func tional definition of a LIMS and, we be lieve, compensates for the shortcomings of the literature definitions (1-4). Fur thermore, the model provides the flexi bility and cohesive framework for any LIMS implementation. The model is based on objectives that define a laboratory environment and that must be addressed prior to developing a functional definition of a system. By providing an architecture to organize LIMS functions and their in teractions, the model allows the LIMS to be viewed from the perspectives of the user, designer, or builder (see box on p. 1071 A). This provides the frame work for the future development of lab oratory automation strategies and em phasizes the need for multidisciplinary communication. The model consists of two principles that form the basis of an architecture and a LIMS definition. First, a LIMS is divided into sets of functionally related components, and the boundaries and scope of each functional area can be clearly understood. Second, the inter action between these functional areas is defined by a common method that allows each area to grow and expand independently of any other, preserving a path for incremental growth, upward compatibility, and future expansion of the model itself. The LIMS model is shown in Figure 1. The center represents the LIMS database, which is surrounded by four functional components that are subdi vided further into three levels. The boundaries between functions are well
defined, and the interaction or connec tion between each functional area is via the database. The functional areas define the scope and the implementation levels define the capabilities of a LIMS. The relationships between the parts of the model (organization of the functions) outline the architecture of the system. Segmentation of each functional area of the model allows a modular ap proach to any implementation while providing system extensibility. Using these concepts, we can present a more detailed definition of a LIMS. The user's view of a LIMS focuses on the functional requirements that must be present when the system is opera tional. In our model, all functions fall into one of five categories. One is sys tem related and the remainder are user related. The system-related category is the data repository, where data and in formation are stored by a LIMS; this is the database. The user-related catego
ries are data capture (gathering of data), analysis of data (reduction and manipulation of data), reporting (pre sentation of data), and management (management of data and the laborato ry). In Figure 1, each user function has an equal share of the total system func tionality; however, in some applica tions certain functions will be empha sized more than others, depending on the implementation. The builder's view identifies the tools and construction techniques that are used to make a LIMS. To facilitate this view and the customization of a LIMS, we divide each of the four user function areas into three levels that represent the scope of possible imple mentation. These levels range from the fundamentals required for a computer application to be classified as a LIMS to the possibilities that we see for a LIMS of the future. Within any of the user function areas described above, the actual implemen-
Data versus information The distinction between data and information may appear to be trivial, but it is critical in realizing the full capability of a LIMS (5). To understand the distinction, we can start with an example of data shown in Figure A. Although this graph is an accurate representation of data, it contains no information. The data are correct, but there are no labels or context to describe the data that are in Figure B. Without context, data are of little value. Therefore, to provide information we must know the context of the data. To simplify this relationship, we can state the following: Data + Context = Information As a scientific community we are used to dealing with information, and we almost automatically insert context around our data to convert results to useful information. Although this conversion is simple for us, it is not always simple for a computer, and thus data that should be valuable become useless. A LIMS that is unable to maintain data in a proper context is of little value. Also, if the LIMS does not facilitate the correlation of multiple pieces of data to provide information, it will not be useful in promoting the laboratory science. Thus the information value of a LIMS is related not only to the quality of data stored, but also to the context or relationships that are also maintained within the system. The following statement is the key to an effective LIMS: More information value is not more data but more context. Β
A
ô
Ξ
100
a Β Ξ
a
0 H
-100
Boiling points of n- hydrocarbons versus carbon chain length 200
200
•
1
3
j ,
!r
10
.E
0
po
system objectives are to collect and manage data from the laboratory, whereas in the information domain the LIMS delivers information to effect decisions anywhere in the organization. (For a discussion on data vs. informa tion, see the box below.) Laboratory business objectives. One objective of a LIMS is to improve productivity. Therefore, the proper ap proach for a LIMS implementation is to address the total information han dling needs of the laboratory and its business environment by considering both the data and information do mains. If this approach is used, a LIMS should become the framework for an automation strategy rather than a "black box" for automating a laborato ry without integrating the information into the organization. Thus the LIMS becomes the facilitator for a coherent laboratory automation strategy.
°
yS
yT
1
I
1
I
1
4
5
6
7
8
1070 A · ANALYTICAL CHEMISTRY, VOL. 62, NO. 20, OCTOBER 15, 1990
-100 9
J*
s
Bo
A/C
.
!
1
3
.
I
4
.
!
5
.
1 ,
I
6
7
,
I
8
Carbon chain length
,
I
9
Architectural views and communication One function of architecture is to give different groups their own meaningful views of the same structure to ensure that the final building will meet the initial requirements. Think of architecture as it relates to a building (6). The architect starts by discussing the future owner's requirements of and constraints on the building. A set of drawings represents the owner's perception of the house, which can be reviewed prior to making a decision to proceed. In our LIMS model, the identification of the functional areas, the scope of the areas, and the initial constraints on the interactions between the areas provide the user (owner) with a description of what to expect from the LIMS. If the owner decides to proceed, the architect produces a set of plans that address the building from a new perspective, that of the designer. These plans provide more explicit specification of the design for the building without explaining or referencing the concepts that were the source and purpose of the earlier drawings. In our LIMS model we have minimized the design constraints to maintain flexibility; however, it still provides input into a design view of how the LIMS will work because of the constraints that are part of the model. The third view is that of the builder, who generates plans to present the building in a format suitable for construction. These plans focus on particular functions of the building and describe the requirements for construction without the general concern for the overall integration and the final product. In the LIMS model, the description of functional areas and levels provides this type of segmentation within the system. This description allows the developer to work on specific functions and yet integrate them to meet the overall requirements of the LIMS. If the architecture of a building is complete and meets the needs of each group, then it will be successful. The same is true of a LIMS.
tation may occur at various levels of complexity. We offer the following broad descriptions of these levels to help illustrate a LIMS framework and to facilitate discussion of a LIMS. Level I represents baseline functions of a LIMS, usually implemented manually, which are targeted at the data domain only. Level II represents intermediate functions, which are generally known applications of computer tools in a laboratory environment. Often these are automated functions that are complex and hence costly to develop and implement in a LIMS. However, it is only as these functions are added that the system begins to address the information domain. Level III offers advanced functions that are at the leading edge of technology. These may be high risk and costly and are not currently available on most systems. However, they should generate a competitive advantage for the organization if successful. Implementation of functions at this level will fuel future developments of the LIMS. The designer's view of the model focuses on the connections or communications between the various functional areas. The basic level of each area is responsible for communication with the data repository to ensure consistent data handling. The model shows that the levels in any area are developed in a layered and well-ordered fashion to include all of the lower level functions as layers are added to the sys-
tem. New functions do not exclude the use of basic functions. Therefore, a system with higher level functions should automatically incorporate those from a lower level in a specific group (e.g., a LIMS with Level II data capture will provide the capability to enter results manually in the computer). According to the model, a LIMS can be considered as a modular system with
Data capture
Management
each functional area dependent only on interaction with the database in order to work. Thus actual implementation of a LIMS can be undertaken in an "à la carte" manner to meet the requirements of any analytical environment and organizational structure. Because the model provides a functional plan for a LIMS, it can be used effectively to define the primary components for any implementation in any laboratory environment. (In addition, the major communication path or interaction between each functional area is handled via the database to allow each area to be developed and implemented in a modular fashion.) This plan provides minimum constraint and maximum flexibility to expand any functional area to meet a laboratory's requirements. Having classified functions into areas and levels, we now define a LIMS as a computer application that meets the requirements outlined by the model. It is a computer system with Level I functions from all four functional groups that must be able to capture, analyze, report, and manage data and information via a database. A more concise definition of a LIMS is an integrated computer-based system combining data capture, data analysis, reporting, and management functions, linked by a common data repository, to meet the needs of a laboratory environment. A system that does not meet the minimum functional requirements of this model may help to automate the laboratory, but it is not a LIMS.
Data analysis
Reporting
Figure 1. Schematic of the LIMS model. ANALYTICAL CHEMISTRY, VOL. 62, NO. 20, OCTOBER 15, 1990 · 1071 A
A/C
INTERFACE
Impact of the model
computing platforms that are consistent with other systems currently implemented within the laboratory or organization. For instance, the model ignores how data and information are stored. Database capabilities may facilitate several functions within the LIMS, such as reporting and management of data, but it may be difficult to capitalize on these capabilities. Functionality needs to be emphasized rather than the technologies that may have implicit functionality but may not be available within a LIMS. Therefore, the model is directed more toward the functional design of a LIMS and less toward the means by which the functions are achieved. The danger of this approach, however, is that the means to effect the model are neglected, leading to cumbersome or user-hostile systems. When designing a LIMS based on this model, it is important to specify the need for user-friendly operation. As technology develops, more functions will be available for the LIMS. These functions can be accommodated by adding levels to each group once sufficient functions are available. Adding levels provides not only a simple way to define a LIMS to meet laboratory in-
A major problem in the implementation of any computer application, including a LIMS, has been the crossing of disciplinary boundaries. Dessy (7) has been teaching analytical chemists the vocabulary necessary to discuss computing with management information systems professionals. The LIMS model can be used to help attain this goal by giving both groups the common concepts and vision required for effective communication. Implementation of a LIMS will be enhanced by each discipline's own perspectives and strengths fused together in a project team. It is also important to realize that the model should be fit to the user's requirements rather than a vendor's concept of a laboratory or organization. In this way a user can develop a complete functional picture of his or her requirements and match these to prospective commercial systems. Technology-independent model. We are concerned here with functions provided by the LIMS for the user rather than the details of system implementation. By basing the model on functional components, one can devise a LIMS with the appropriate tools and
formation technology requirements with current technology, but also a foundation with which to expand the model in a coherent and controlled manner. Classification of L I M S functions
This section contains our assignment of LIMS functions to the four userrelated functional areas and further classification of the three capability levels. This is intended to be of practical use for the LIMS user and the software developer when applying the model to real examples. The list is not comprehensive, but we hope that it will stimulate discussion for further refinement of the model. The levels illustrate a migration from basic to more complex functions within a functional area, and as the more complex operations are overlaid onto the model they become extensions of a functional area rather than new functional areas. Functions that are classified as data capture and analysis are generally involved with the data domain whereas the higher levels in the reporting and management areas are used to integrate the laboratory with the information domain. Table I presents the four user-related functional areas and their
Table I. Classification of LIMS functions by user-related functional areas and their corresponding levels Function Level
Data capture Manual entry of sample information (e.g., origin, batch, number, analyses requested) Manual results entry with verification
Data analysis Verification of data format entered into the LIMS Calculation of results Automatic calculations on data entered manually or online Transfer of result files to statistical and interpretive packages
•
One-way communication from analytical instruments to the LIMS concerned with online data capture from instruments Use of bar code readers for location and identification of samples and for r ID
III
Bidirectional communication (files downloaded from the LIMS to analytical instruments for method parameters and run lists; results files uploaded) Electronic transfer of files containing reduced data reports from instruments to the LIMS
Data reduction programs (e.g., calibration curves, calculation of unknown sample concentration or amount, LOD determination) Interpretation of results 2D graphics programs for visualizing data and results Data conversion from instrument to standard database management system format or abstraction of results from an instrument file
Reporting Hard-coded reports (reports are defined and coded, all selection parameters are predefined, and only values are entered at run time) Database searching via forms Comparison of results with predefined specifications
Sample log-in Acknowledgment of sample receipt Sample and status tracking, backlog reports Worksheet production Archiving and retrieval of data via magnetic media Approval and validation schemes for results Stand-alone error reporting
User-configured reports Graphical representation of results Ad hoc searching and reporting Internal electronic distribution of reports Interfacing with desktop publishing packages
Hierarchical security Location of samples Estimation and scheduling of work Audit trail of database Transaction logging Class security
Chemical structure drawing
Resource management
Natural language reporting methods
Online scheduling of work from other systems Electronic laboratory notebooks
Expert assistance for ad hoc reports
Dynamic balancing of laboratory resources
Substructure searches Conversion of data to information (artificial intelligence database searches to identify unknown samples)
Management
3D graphics
1072 A · ANALYTICAL CHEMISTRY, VOL. 62, NO. 20, OCTOBER 15, 1990
Error correction by use of expert systems
A/C
INTERFACE
££CJNTtËnFfAÇEs corresponding levels. Data capture. Data and information from samples entering the laboratory and the associated results must be entered into the LIMS. Functions in Level I are rudimentary; information about the sample and results is entered manually. To aid in this process and reduce error, verification is used to compare the format or range of the data input with expected values held within the database. A LIMS operates best when results are transferred electronically, as in Level II. However, transfer of data is only one way to the LIMS. The ease of interfacing analytical instruments varies greatly; thus, instruments with low data capture rates such as chromatographs, atomic absorption and emission spectrometers, and balances can be interfaced. Data can be captured online with well-proven peripheral equipment and software. The LIMS model, because it is technology independent, does not stipulate whether the computer running the LIMS or an ancillary computer acquires data. Therefore, a network of processors or a single system can still be classified as a LIMS— provided that it still performs the model functions. For identifying and tracking samples, bar code technology can be employed. Data capture at Level III involves bidirectional communication whereby a LIMS can pass a file to an intelligent instrument containing the information to set up and run an assay for a set of samples. After the analytical run, a file with the results will be imported into the LIMS and the results inserted in the appropriate database location. Equipment with faster data capture rates, such as NMR and mass spectrometers, presents an entirely different problem. For these instruments, usually there are specialized computers that acquire, reduce, and interpret data. The problem is, in what form should data be transferred to a LIMS: as a report file or as raw data? Ideally, only the report file should be transferred to the LIMS for inclusion in the final report. The only software that would be required in this case would be to interpret the report findings if it were not a simple text file. Data analysis. Once data are captured by the LIMS, they are reduced, manipulated, and analyzed by the appropriate functions. The functionality at Level I is rather rudimentary, providing verification of data format. For example, pH range and automatically calculated results from a set of input data can be obtained with user-defined routines that are specific to an analytical method.
Data analysis functions at Level II bring more power to the system: Files imported from instruments can be converted into database files, or the results contained within the original file can be abstracted by a utility program prior to insertion in the database management system. Furthermore, this process can work in the opposite direction and results files can be exported from the LIMS for graphical or statistical interpretation. Reduction of data is an important function. An example might be the reduction of chromatographic data to a concentration of analyte. Included in this process is the interpretation of results whereby an analyst might view a chromatogram and judge whether any further action is required. Functions at Level III involve the use of more sophisticated graphical interpretation packages (e.g., three-dimensional plotting). Substructure searching and interpretive packages are used for converting data to information. Reporting. Once data have been analyzed and interpreted, they are reported by functions ranging from text and figures to paper and electronic form. Level I consists of hard-coded report formats that only require the user to input the variables when the report is run. Forms are used to search the database, and results can be compared by using a predefined specification within the database. These functions confer basic reporting functions on a LIMS but offer little flexibility such as the ability to perform ad hoc searches. At Level II there is improved reportingflexibility.Results can be presented graphically, or the LIMS output can be merged with electronic mail facilities for faster distribution of reports or desktop publishing packages. Some laboratories may require chemical substructure searching and drawing, and an interface with such a package is available at this level. In addition, the functions that enable a LIMS to conquer the information domain begin to emerge. At Level III the LIMS has the ability for natural language interrogation of the database with online expert assistance for ad hoc searches. The system can interface with expert systems to help inexperienced users. In addition, the system is integrated into the information domain and interacts with other applications such as production information systems or manufacturing systems to provide information for computer-integrated manufacture. Management. In this group, the lower levels are concerned with managing data and the higher ones are involved with providing information to
1074 A · ANALYTICAL CHEMISTRY, VOL. 62, NO. 20, OCTOBER 15, 1990
manage the laboratory and also linking with the information domain in the organization. Functions at Level I cover the basic sample management operations such as logging samples into the system and tracking them, establishing the status of samples and basic work schedules, reporting any backlog, and archiving and retrieving data via magnetic media. System security is ensured by a hierarchical approach; users with a particular security level can access all system functions at or below that level. At Level II the ability to track sample location is integrated with the sample management functions of Level I: the data capture functions of bar coding via the database. Workloads can be predicted. In regulated industries this level provides audit trails and transaction logs to ensure the integrity of the stored data. Security of the LIMS is addressed by a class system; the responsibilities of the user are mirrored by access to the appropriate software modules for each individual. Archival functions and retrieval of data would use laser disk technology. Functions at Level III are concerned with planning resources and running the laboratory on a long-term basis: online scheduling of work from other computer applications and systems as well as interaction of the LIMS with project management software and electronic laboratory notebooks. When the functions in each level are viewed as a whole, two general comments can be made as one rises from Level I to Level III. First, the complexity of each functional level rises. The higher the level, the more the system will integrate into the business environment (i.e., the information domain) of the organization. On the other hand, the risk in implementing higher level functions increases the higher one rises in the model. This risk manifests itself in the technology and software available for the job and is compounded by the fact that very few LIMS installations are carried out by someone experienced in undertaking any of the functions in Level III in all four groups. Second, the overall cost of a system rises when a large number of higher level functions in one or more groups are required for an individual LIMS. The more complex functions for a LIMS may take a long time to specify and develop, may be expensive, and may carry a significant risk of failure. Knowing this information before the project starts, one can conduct feasibility studies and make informed judgments, which will reduce the uncertainty and enhance the likelihood of success for any LIMS project. Remember
American Chemical Society Announces Calculation and statistical programs
Reporting and desktop publishing
Electronic laboratory notebook
Practical HPLC Method Development Friday-Saturday October 26-27, 1990 Chicago, Illinois
LIMS database
Rule-based expert system
Graphics programs
Project management '
Artificial > intelligence laboratory management
Figure 2. Extension of LIMS model incorporating additional interfaces.
that building the credibility of a system involves providing simple services that work well initially and following later with difficult tasks (7). This advice may not be applicable for all systems, but it should certainly be kept in mind when considering particular Level III functions. Future development
In light of the model outlined here, it is apparent that some functions we include in the various groups already exist as separate packages for such areas as graphical presentation and statistical interpretation of data. How should these packages become part of a LIMS environment? One example of software development is in the microcomputer environment, where import and export are possible between different applications such as databases, graphics, and finances. A key to this integration is standardization of file interchange formats and other related architectures. These standards (and we use the term loosely) are being promoted by independent vendors and vendor associations. Examples of this approach are DTIF (Data Table Interchange Format), developed by Digital Equipment
Corporation, and ADISS (Analytical Data Interchange Software Standard), which is currently being developed by the Analytical Instrument Association. These standard interfaces and architectures will make possible a LIMS as shown in Figure 2. At the center of the figure is the LIMS database with the associated software modules, and around the periphery are other packages (either on the same or different processors) to carry out the functions of the model. Via import and export routines, files can be transferred to and from the various packages. Making use of specialized systems when interfacing is costeffective and provides a broader range of capabilities. Packages offering statistical interpretation, electronic laboratory notebooks, data transfer protocols, graphics, and project management applications are key areas for integration with a LIMS. In addition, expert systems are used for the interpretation of data. As an example, the project management application could interact with the LIMS database and an artificial intelligence laboratory management package to aid the smooth operation of the laboratory and to estimate and schedule work.
A comprehensive Short Course that will teach you strategies, techniques, and methods guaranteed to minimize your time and effort without compromising the goals of method development. Here's How You'll Benefit: • Learn when and how to use a particular HPLC method • Review the simplest techniques for optimizing the solvent in the separation • Learn the specifications for a good column and how to troubleshoot column problems • Examine specific monographs for estimating the strength of a different solvent from the known strength of an initial solvent • Submit actual separations problems of general interest for discussion and solution • AND MUCH MORE! Instructors: J.J. Kirkland and Lloyd R. Snyder For more information call the Continuing Education Short Course Office at (800) 227-5558 or at (202) 872-4508. Or, use the coupon below to request a free descriptive brochure on this dynamic course. American Chemical Society Dept. of Continuing Education Meeting Code PHM9010 1155 Sixteenth Street, N . W . Washington, DC 20036 Please send me a free brochure on the ACS Short Course, Practical HPLC Method Development (PHMD9010), to be held October 26-27, 1990, in Chicago, Illinois. Name Title Organization Address
City, State, Zip HPLC06
ANALYTICAL CHEMISTRY, VOL. 62, NO. 20, OCTOBER 15, 1990 · 1075 A
A/C
INTERFACE
Conclusion
References
This model provides the basis for the design and implementation of a LIMS. Although conceptual in nature, it de fines a LIMS in such a manner that it effectively encompasses the total auto mation requirements for a laboratory and the organization. Moreover, it pro vides a basis for a LIMS in the context of both the data and information do mains (i.e., an integrated information management environment). A LIMS using today's computer technology can provide the integrated framework to link all aspects of the laboratory envi ronment and thereby increase the pro ductivity of all functions inside and outside the laboratory.
(1) Gibbon, G. A. Trends Anal. Chem. 1985,3, 36-38. (2) Laboratory Information Management Systems, Concepts, Integration and Im plementation: McDowall, R. D., Ed.; Sig ma Press: Wilmslow, Cheshire, England, 1988.
The idea for this model arose at a meeting of the teaching team for a Royal Society of Chemistry (U.K.) residential school on LIMS in January 1988. Graham Martin, Chris Triner, Ray Dessy, Brian Fish, Adrian Hampshire, Paul Tebbs, Gor don Farrow, Dai Darkin, Graham Murkitt, and David Moore attended the meeting. The authors gratefully acknowledge the team for the genera tion of the idea for the model. We wish to thank Graham Martin, R*y Dessy, Mike Murphy, Mike Bertram, Milt Ratcliff, and Buck Rogers for helpful comments on the manu script, and other colleagues who contributed help through discussions during the preparation of this paper.
Robert D. McDowall (left) graduated in 1972 from the University of Newcastleupon-Tyne with a B.Sc. degree in biochemistry and obtained his Ph.D. from the University of London in 1977. He is presently bioanalytical unit head in the Department of Bioanalytical Services with Wellcome Research Laboratories in Beckenham. His research interests include LIMS, laboratory automation, and biological sample preparation. McDowall recently was appointed Editor of a new journal on laboratory information management. Donald C. Mattes received a B.S. degree in chemistry (1976) from Delaware Valley College in Pennsylvania. Since then he has worked with Polysciences, Inc.; Upjohn; and Digital Equipment Corporation. Currently he works for SmithKline Beecham Pharmaceuticals, where his focus has been on LIMS and laboratory automation systems.
LABORATORY
SERVICE CENTER
Acetylthiourea · Alizarin Complexone · m-Aminophenol · Benzoic Anhydride 2-Chloro-4-Nitrobenzoic Acid · Digitonin · 3,3-Dimethylglutaric Acid EGTA · Ethanesulfonic Acid · Ethyl Lactate · Ethyl Pyruvate · Furoic Acid Hippuric Acid · 3-(p-Hydroxyphenyl)propionic Acid · Methyl Acetamide 5-Methyl Hydantoin · 3-Nitrophthalic Acid · o-Phenanthroline Monohydrate Phenyl Urea · Potassium Acid Phthalate · Sodium Tetraphenylboron Suberic Acid · Succinic Acid · Tetraiodoethylene · 3.4,5-Trichloroaniline 1,1,1-Trichloro-2-Methyl-2-Propanol · 3.4,5-Trimethoxyaniline · n-Valeraldehyde Write for our Products List of over 3,000 chemicals Tel: 516-273-0900 · TOLL FREE: 800-645-5566
Telefax: 516-273-0858 · Telex: 497-4275
EASTERN CHEMICAL A Division of UNITED-GUARDIAN, INC.
(3) Golden, J. H. Intelligent Instruments and Computers July-August 1988,197200. (4) Megargle, R. Anal. Chem. 1989, 61, 571 A. (5) Bruce, T. A. Database Programming and Design November 1987,47. (6) Zachman, J. A. IBM Syst. J. 1987, 26, 276. (7) Dessy, R. E. Anal. Chem. 1983,55,70 A.
P.O. Box 2500 DEPT. AC SMITHT0WN, N Y . 11787
Laboratory Service Center (Equipment, Materials, Services, Instruments for Leasing), Maximum space — 4 inches per advertisement. Column width, 2-3/16"; two column width, 4-9/16". Artwork accepted. No combi nation of directory rates with ROP advertising. Rates based on number of inches used within 12 months from first date of first insertion. Per inch: 1 " — $165; 12" — $160; 24" — $155; 36" — $150; 4 8 " — $145.
HELP WANTED ADS ROP display at ROP rates. Rate based on number of insertions within contract year. Cannot be combined for frequency. Unit 1" (25 mm)
1-TI
6-TI
12-TI
$190
$170
$160
24-ΤΊ
48-T1
72-T1
$150
$140
$130
CALL OR WRITE JANE GATENBY
ANALYTICAL CHEMISTRY 500 Post Road East P.O. Box 231 Westport, CT 06880 203-226-7131 FAX: 203-454-9939
CALL OR WRITE JANE GATENBY
ANALYTICAL CHEMISTRY 500 Post Road East P.O. Box 231 Westport, CT 06880 203-226-7131/FAX: 203-454-9939 1076 A · ANALYTICAL CHEMISTRY, VOL. 62, NO. 20, OCTOBER 15, 1990
FREE DATA, FAST To quickly amass data on all of the prod ucts you need, consult the Lab Data Ser vice Section on our Analytical Chemistry reader reply card insert.
