Abstract
Introduction
The introduction of laboratory automation is viewed by many as key for the improvement of future productivity in clinical laboratories. As health care reimbursements continue to rachet downward, enhanced laboratory productivity will provide an advantage in the increasingly competitive laboratory marketplace. To become more productive, commercial laboratories have pursued a course of consolidation and automation, investing vast sums in the development and implementation of automated laboratories capable of handling upwards of 20,000 specimens per night. Hospital laboratories have begun incorporating automation on a more modest scale, also looking for ways to become more productive through consolidation of services and reengineering.
In assessing activities in the laboratory that could be improved by the application of automation, laboratory directors have placed emphasis on the areas of specimen preparation, automatic transportation, improved electronic control of analyzers, and improved facilities for workcell integration. Specimen preparation and transportation of specimens to the appropriate workcell in the laboratory are known to be labor-intensive activities that are amenable to automation. Additionally, current design of clinical analyzers requires interaction of laboratory personnel with instrument front panel functions in order for each instrument to carry out its analyses. The ability to control analyzers electronically using computers, and to integrate the control of several analyzers into a single workcell staffed by only one or two laboratory technologists will also lead to considerable labor-savings.
Underlying these approaches for automating laboratory analysis, however, is the need to integrate the new information generated by the automated specimen processing equipment and automated transportation equipment with that generated by the computer-controlled workcells. Currently, laboratory information management resides in the laboratory information system (LIS), but it is becoming apparent that the new information needs of automated specimen processing and specimen transportation may not be well-served by existing LIS designs. As more automation for specimen processing and specimen transportation has become available, several manufacturers have recognized these new information needs and have developed process control software to manage the functions of the new automation in clinical laboratories. A laboratory automation system (LAS) consists of the process control software integrated with automation hardware. Integration of newly introduced laboratory automation with existing clinical laboratory systems (including the LIS and other automated equipment) will be vital to ensure its success. Particularly important will be the integration of LAS controllers with LIS systems.
This article will consider the functions of LIS and LAS systems, examine the issues in interfacing LIS and LAS systems, relate a case study at our institution, and give a rationale for why client-server computer architecture is likely to be the technology that allows optimal integration of automation.
Traditional LIS functions
Traditional laboratory information systems were designed and developed ten to twenty years ago, using a central minicomputer to service multiple users who operated various data input and output devices (including terminals, printers, instrument interfaces, and card readers). All software and all data resided on the central computer. The software was written in second and third generation computer languages, was proprietary, and usually not available for user modification. These early LIS's were designed to service functions such as the input of test orders and generation of bar-code labels, the elementary tracking of specimens, the tracking of incomplete tests and generation of worklists of incomplete tests, the capture of data from on-line laboratory analyzers, assistance with the display and analysis of quality control data, assistance with result verification and reporting, provision of maintenance scheduling and inventory tracking, and the generation of billing information and management reports. Many laboratories today are running on LISs whose underlying design has not changed greatly from these early systems. Although these systems function very reliably in clinical laboratories, modification of their underlying design is not easy, and changes sometimes require modification of thousands of lines of computer code.
Emerging LAS functions
Laboratory automation systems encompass new functions in the clinical laboratory that have associated new information needs. Because the LAS may incorporate an automated specimen processing system, information regarding the physical characteristics of the specimen must be captured. This information can include such things as the specimen volume, the specimen tube size, the appearance of the plasma or serum following separation (e.g., assessment of hemolysis, icteria, or lipemia), the color of the tube cap, and the information written on the tube. Additionally, the LAS must capture information regarding tests desired on each specimen, the sample volume required for each test, and the workcells to which that specimen needs to be routed. The LAS must develop an itinerary for each specimen and physically track specimens through their itinerary. The LAS bears responsibility for monitoring the operation of the specimen conveyor and the status of each instrument, for rerouting specimens needing reanalysis, and for implementing rules for reflex analysis. The storage location of all specimens must be tracked for easy retrieval. Because the LAS must be aware of the status of each analyzer, it could reasonably be expected that the LAS would also consolidate and assist in the analysis and verification of results from the different analyzers. It could even implement automated result verification using rules supplied by the laboratory director. In order to fully optimize the scheduling of laboratory resources in light of specimen routing, analyzer setup, peak workload projections, etc., the LAS should be provided with information regarding clinical workload projections and laboratory workforce availability.
Information that must be shared between a LIS and a LAS
Although current interfaces between laboratory analyzers and LISs function very effectively, their design is not easily generalized to encompass the information needs of the LAS. As pointed out above, the LAS needs to acquire information regarding (in addition to the accession number and tests requested) the specimen container type, minimum specimen volume needed for each test, the number of aliquots to make and what workcells to route the various aliquots to, specimen tracking information, and instrument and/or conveyor status messages. If samples are placed directly on the automated specimen processor, the LAS will need to send specimen receipt messages to the LIS verifying the presence of a given sample in the laboratory. Regardless of whether the LIS or the LAS makes decisions regarding the routing of specimens for reanalysis, or for reflex testing, the interface will need to convey this kind of information to the corresponding systems. If the LAS is involved in the generation of finalized laboratory results, the interface will need to convey these results to the LIS database for storage. Information regarding workload projections and workforce availability (that is not usually stored on the LIS) will have to be acquired by the LAS from the hospital information system or personnel management system.
Difficulties in interfacing a LIS with a LAS
LAS vendors have taken very different approaches for the management of information related to laboratory automation ranging from very simple to very complex. At the simple extreme, a vendor could take the approach of making the LAS appear as a laboratory instrument, needing from the LIS only the accession number and the tests ordered. Based on the information supplied by the LIS and information that it holds in its own tables, the LAS would then develop a routing scheme and transport the laboratory sample to a predetermined set of workcells to be sampled by the analyzers in those workcells. Under this simple scheme, however, one item of information that this LAS system would require is knowing when an analyzer at a given workcell has finished sampling a specimen so that it can forward the sample to the next workstation. Unfortunately, this need goes beyond the information that is typically communicated by a laboratory instrument to an LIS, and, therefore, would either require the LIS vendor and the instrument vendor to revise their respective interface software to pass this kind of information or the LAS vendor to establish a separate interface with the instrument.
At the more complex end of the spectrum for information management, a LAS vendor could develop a much more elaborate interface with the LIS, and collect demographic information, information regarding the diagnosis of each patient, accession number, tests ordered, and specimen volume requirements. Such a system might store rules for reflex testing, for routing repeat analyses, a test to workcell mapping scheme, quality control data from the laboratory analyzers, and rules for autoverification of laboratory results. Taken a little further, this LAS system could probably carry out all of the LIS functions as well, and provide a truly integrated platform for the collection of laboratory information and control of laboratory automation devices.
Because the different philosophies of LAS process control software cover such a broad range at present, the development of an interface between a laboratory information system and a laboratory automation system is not a well-defined task and may present some difficult problems. First, the LAS may ask for information that the LIS does not have. Many traditional LIS systems, for instance, do not contain information regarding minimal sample sizes needed for each analysis (although they often contain information regarding the minimum number of tubes of blood to be drawn for a given set of analyses). In addition, traditional LIS systems cannot usually supply information regarding the exact numbers of aliquots needed for a given set of analyses or the route a specimen should take to get to the appropriate laboratory work cells. Although the LAS needs a unique tube identification number for each physical sample, some LISs assign the same accession number (which is also the number written on the tube barcode label) to multiple samples. Some of these information needs of the LAS require major database modifications to be made in the LIS in order to accommodate them. Particularly in the case of a traditional LIS operating on a central minicomputer with proprietary software, the required changes affect many lines of computer code and can be very expensive to implement. In many cases, LIS vendors are forced to make major changes in their database organization in order to accommodate these needs. For those vendors that have not built their systems around general relational database management software, such changes will have major impact on their existing computer code, and may adversely affect performance.
In addition, the new information needs of the LAS may not fit with ASTM or HL-7 standards as currently evolved. LIS vendors have attempted to use the ASTM or HL-7 standards as much as possible in writing interface software to reduce costs and improve reliability. However, neither of these standards, for example, currently includes general approaches for passing information relating to the status of devices such as conveyor belts, specimen processing systems, or laboratory instruments.
Possible Approaches
Assuming that agreement can be made between LAS and LIS vendors regarding who performs what function, several scenarios can be envisioned for the development of an integrated LIS/LAS platform in the clinical laboratory (fig. 1).
Three possible scenarios for integrating LIS functions with LAS functions: a) The LIS database has been restructured so that the LIS can supply all information needed by the LAS through the LIS/LAS interface; b) The LIS and the LAS have been integrated on a common platform and share an integrated LIS/LAS database; c) An intermediate computer has been placed between the LIS and the LAS to assist with the interface between the two systems. The intermediate computer has its own supplemental database that is used to augment information supplied by the LIS to the LAS.
Under the first scenario the LIS database would be restructured to be consonant with the LAS needs. Such a process can be more easily accomplished with Client/Server computer designs than with the older designs employing a central minicomputer with proprietary software. An attractive feature of the latest relational database management software (that is implemented on most servers in client/server designs) is that database restructuring to accommodate additional data elements is relatively straightforward and easy to carry out. Thus, if an LIS needed to incorporate an additional unique identifier number for each physical specimen, such a change could be accomplished much more readily on a client/server system than on older designs where considerable reprogramming would be required. The time and expense required to accomplish such changes with the older LIS software designs could be prohibitive.
Under the second scenario all of the LIS and the LAS functions would be integrated into a single system. This approach would offer the advantage of a truly integrated system without the need to develop a separate interface between the LIS and the LAS. Such an integration of functions could be accomplished by either a LIS vendor or a LAS vendor using currently available client/server computer architectures. However, neither LIS nor LAS vendors have taken on this project. A probable reason for the reluctance on either side to consider this task is the large base of knowledge and experience that is required to develop and support either a LIS or a LAS. Perhaps such a system could emerge from a partnership between a LIS and a LAS vendor.
Under a third scenario, an intermediate computer could be placed between the LIS and the LAS to translate and supplement information needed by each. Although this is at best a makeshift approach, it is the approach that is most likely to lead to a functional interface between a LIS and a LAS in a short period of time. An advantage of this approach is that one can usually use an existing instrument interface design for interfacing with the LIS, while providing the information needed by the LAS through supplemental tables that are developed and maintained on the intermediate computer.
Case study at UVA
In late 1995, the University of Virginia Clinical Laboratories needed to develop an interface between the Coulter IDS automated specimen processing system and their Sunquest Information Systems (Tucson, AZ) laboratory information system. At that time, Sunquest was in the process of developing software to supply a unique tube identifier number for each physical specimen, but estimated that it would take two years to fully integrate this change into their LIS software and make it market ready. Our laboratories could not wait this length of time for a true LIS/LAS interface. The University and Coulter adopted an alternative approach employing an intermediate computer system between the LIS and the LAS. This intermediate PC was to act as a translator, accepting data from the LIS (including accession number and tests requested) in the same format as would be supplied to a Johnson and Johnson Vitros 950 analyzer, and then providing all necessary data to the LAS, supplementing the LIS information with information derived from tables stored on the intermediate computer containing information regarding required specimen volumes, tube routing, and numbers of aliquots. It is important to emphasize that the supplemental information could not be supplied by the LIS, but was required by the LAS for proper operation.
This interface was developed collaboratively with Coulter Corporation over a period of 8 months. Coulter provided the intermediate translation computer and software was written by an independent software subcontractor. The laboratories provided a data connection between the Sunquest LIS and the translation computer and exported data from the LIS to the translation computer in Vitros 950 format. Personnel from the laboratories edited databases in the translation computer that linked requested analyses with required specimen volumes, tube routing and aliquot information. Once developed, the interface was subjected to careful testing to assure reliability.
Although this interface functionally allowed Coulter and the Clinical Laboratories at the University of Virginia to carry out needed testing of the Coulter IDS system, it had some limitations. Because of a limitation in the Sunquest Vitros 950 interface, only 96 different test codes could be passed through the interface. Additionally, the interface did not have any way to handle multiple tubes with the same accession number. Thus, if the Coulter IDS system had already processed one tube with a given accession number and then it received another, the second specimen was placed into a “rejection” area on the IDS for manual handling by the IDS operator (eventually, this problem will be solved after Sunquest deploys its software to provide a unique tube identification number for each physical specimen). Finally, the inter face was not able to report back to the LIS any information regarding status of LAS, the tubes it was handling, or the aliquots it had made, because the LIS was not prepared to receive such information. As implemented, this interface could not have handled the full service load of the laboratories at the University of Virginia, and was used only for a few months in testing the IDS system.
Our experience with this interface helped us to appreciate some of the difficult problems that must be resolved before truly effective LIS/LAS interfaces can be developed. As pointed out above changes to the database on the LIS side are likely to be extensive and expensive to accommodate information regarding the status of the LAS and the tubes on board the LAS. Likewise, the transfer of information regarding required sample volumes, numbers of aliquots, tube routing, and requests for specimen reanalysis and reflexive testing must be able to be accommodated in future interfaces. Very importantly, in LISs like Sunquest where the same accession number can be assigned to multiple tubes, a system for providing unique specimen identification numbers to each physical tube must be developed. Given the length of time that Sunquest has estimated this latter change will take, one can only presume major software revisions have been necessary. As discussed above it is probable that such database and software changes can be made more rapidly with use of client-server computer architectures.
Future needs of LIS/LAS interfaces for full process control
As the future of LAS systems begins to unfold, the need for full process control in the clinical laboratory will become an important objective. Full process control will involve the scheduling of both machines and human resources. Thus, to fully control the laboratory process, the LAS process controller computers will need information regarding workload projections and workforce availability that can be integrated into the development of an optimal scheme for scheduling of laboratory equipment and personnel. This information is presently available only from diverse information systems including the hospital information system, the clinic or institutional patient scheduling system, the personnel management system, and the laboratory information system. The collection of this information with a large enough time window to allow the process controller to optimize resource schedules will present many challenges, and, optimization software for the LAS process controller that integrates the data from these diverse information sources into an optimal plan for laboratory resource scheduling will need to be evolved.
The Role of Client/Server Computer Architecture
In recent years, the development of general purpose relational database management software (RDMS) that exhibits good performance under heavy transaction loads has led to the widespread application of client/server computer architecture. The RDMS can be rapidly adapted to store needed information in a flexible format on the server. Client systems can access the database stored on the server using queries written in a structured query language (SQL). The use of SQL allows users to program client systems to address the database using their favorite commercially- available software tools. Several RDMS vendors have developed database management software that can run on a multiprocessor server. These multiprocessor configurations provide the ability to support heavy transaction loads originating from hundreds of client systems while maintaining excellent response times. Widespread implementation of client-server architecture will allow the information needs of the LAS process controller of the future to be met more easily. If the diverse information systems described above, including the LAS, the hospital information system, the clinic or institutional patient scheduling system, the personnel management system, and the laboratory information system all employ client/server architecture, each system will be able to address the other directly using SQL queries. This capability should greatly ease the difficulty of acquiring real-time information on hospital census, clinic schedules, personnel availability, and the host of other information that will be necessary for the LAS to accurately project laboratory workload and schedule system resources.