Kenneth E. Blick, Ph.D.
Professor
Department of Pathology
University of Oklahoma Health Sciences Center
Oklahoma City, OK 73126, PH 405-271-7632, ken-blick@ouhsc.edu 

Download as a PDF here

Keywords: critical care, informatics, point of care testing, data management, laboratory management, electronic medical record, physicians orders, hospital information systems, laboratory information systems

Abstract

Laboratory medicine is undergoing tremendous change in recent years driven primarily by technology, regulations, reimbursement, and market forces. In this paradigm shift, the laboratory is under tremendous pressure to adapt to new requirements for critical care testing. Indeed, laboratories have entered the information age where chemical data is being extracted from specimens in totally automated fashion. In the past, laboratory data has played a more historical role in the care of critically ill patients, arriving at the bedside too late to be of significant use in the active, ongoing care of the patient. However, today's physicians taking care of critically ill patients now require that laboratory results are made available in real-time and, if possible, at the patient's pont-of-care. Many new testing point-of-care testing devices have been developed to address this need however often laboratories implement such distributed devices with little or no attention to the information technology requirements. In fact, as little as 10 percent of point-of-care testing is actually managed by the central laboratory computer hence critically importance results are not found on the patient's electronic medical record. In addition, the billing and management data for point-of-care testing is often handled manually with no plans to interface point-of-care devices to the laboratory billing and management systems. Because of recent improvements of information handling and interface capability, such shortcomings in data management are no longer acceptable. Indeed, the demands for laboratories to utilize information technology are such that those laboratories with no overall plan for data management of critical care testing will probably not survive this market driven paradigm. We present a discussion of the various approaches to computerization of point-of-care testing including the advantages and the disadvantages of each approach.

Introduction

Recent market-driven changes have placed increasing demands on laboratories to provide more and better services, and at the same time, use less resources. To survive in this new market-driven paradigm shift, laboratories must 1) improve access to testing services, 2) improve efficiency and quality of services, 3) improve (and document) patient outcomes, and, at the same time, 4) reduce costs. Clearly, many laboratories will not be able to respond effectively to these demands for value-added services and hence will be soon replaced by other providers of laboratory services.

One specific area requiring focus on adding value is laboratory support for services provided to critically ill patients. Traditionally, laboratory results have been of more historic value in critically ill patients because they frequently arrive at the patient's bedside too late to be of significant use in clinical decision making. Hence, to decrease turnaround time (TAT) and potentially add value to laboratory results, laboratories have 1) reorganized and re-engineered their laboratories into a highly automated core laboratories and 2) moved a higher percentage of critical-care testing to the point-of-care (POCT). While total laboratory automation (TLA) of the highly automated core laboratory presents a challenge to traditional laboratory information systems (LIS), some selected laboratory computer systems have been modified and have met this challenge with some level of success. On the other hand, the decentralization of POCT has challenged the traditional approaches to laboratory computing to the extent that only 10 percent of POCT is presently collected electronically and transmitted to the appropriate patient management systems. In addition, billing and management functions for POCT is also being handled by manual systems in most hospitals, making of POCT a poorly organized and managed activity. In fact, many hospitals forgo billing for POCT altogether. Inadequate Information Technology (IT) support for order entry/charge capture for POCT is reflected in a substantial loss of revenue which, if corrected, could make such services profitable. In addition, increasing and unique regulatory requirements for POCT have made manual monitoring of a comprehensive POCT program essentially impossible.

The message to vendors of POCT devices for critical care is similar. In the past, vendors with a focus on the analytical performance and ease of use were successful. However, in the present, those vendors not providing state-of-the art informatics solutions along with their devices, the future looks bleak. First of all, their current customer base as described above will probably not survive. Secondly, information technology issues in POCT have become the determining factor in the purchase of POCT systems. No longer will vendors with high quality testing devices be able to sell such systems based solely on the available test menu and accuracy/precision thereof. Rather, laboratories are selecting total solutions to POCT which handle all aspects of information management from the test order to verified results reporting. Why has this change in the marketplace taken place? In the past, many point-of-care projects were pursued independent of computerization/interface issues thus the project was handled poorly as an afterthought. Clearly, doing the test is now the simplest part of the testing process while daunting IT issues separate the good vendors from the incompetent.

Materials and Methods

Interfacing point-of-care testing is facilitated by existing information management infrastructure. For example, the laboratory must have in place a state-of-the art laboratory information system (LIS) which is interfaced to the hospital information system (HIS). It is helpful for the facility to have a network infrastructure thereby eliminating the need to pull additional point-to-point cable for POCT devices usually located remotely at the patient's bedside (or location).

While many POCT devices can be directly attached to the LIS, most are connected to the LIS via proprietary Data Management System (DMS). DMS systems commonly available from various vendors are listed in Table 1 along with types of POCT available. Some selected vendors of laboratory information systems capable of handling computerization of POCT are listed in Table 2.

Discussion

Major Problems with POCT Computerization

Because POCT has been present in hospitals for a number of years, it is surprising that most of these hospitals have not computerized their POCT. Aside from the cost of the interface being a problem, other more technical problems involved in computerization of POCT include:

- Connectivity issues with POCT devices and associated information management subsystems,
- Unique nature of POCT when compared to traditional central core-laboratory testing,
- Unique database requirements for POCT, and
- Information management support for a plethora of remote POCT devices.

Interface/Connectivity IssuesThe IT Project Team

Every installation of a POC/Critical Care testing program presents a variety of IT challenges with different networks, different LIS /HIS(Hospital Information System), and associated complexity. In general, information technology (IT) connectivity issues center on 1) hardware and related information infrastructural network issues, 2) software requirements for the plethora of various legacy LIS/HIS systems now in place in hospitals, 3) the degree of sophistication of the hospital's on-site LIS/HIS/Network computer staff, 4) the overall IT funding for the project, and 5) the site's expectation regarding the project in terms of resource commitment, time-frame, and implied warranties. Clearly, a hospital team approach is required for success with all vested parties involved in the project. In addition, the IT project requires an IT champion, i.e., an individual with the experience and expertise to keep the project on target relative to budget, schedule, and expectations.

Barriers to developing an overall infrastructural plan for automated data transmission from POCT devices center on 1) whether POCT is left to proliferate throughout the hospital with no overall plan for POCT informatics or 2) whether the central laboratory is to assume the primary role of interfacing all laboratory testing including central "core laboratory" testing data and POCT. With this latter approach, POCT is viewed as a necessary extension of laboratory testing and hence must be part of the overall interface plans for the LIS, HIS, and the patient's EMR(Electronic Medical Records) system. Clearly, to date, barriers to integration of POCT with traditional laboratory data have won out in most institutions with only 10 percent or less collecting POCT results and associated billing information electronically.

Barriers to POCT being under the overall control of the laboratory are often turf issues and political in nature. Nevertheless, laboratorians appreciate the value of electronic gathering of information as an essential asset for doing business especially when it comes to QC/QA,(Quality Control/Quality Assurance) billing/compliance, and regulatory requirements. POCT requires that the laboratory maintains control of critical care testing by insuring

- That all POCT meets all regulatory requirements (CLIA88, Clinical Laboratory Improvement Act, l988)
- That appropriate and documented training of all POCT testing personnel has taken place
- Timely review of calibration and quality control data
- Verification of all POCT results prior to reporting
- That information management mechanisms are in place for acquisition, storage, and reporting of POCT results
- That the laboratory has means for automatic charge capture, coding and billing for POCT and that compliance with all HCFA (Healthcare Finance Administration) rules for reimbursement is achieved.

Remote Installation/Support

In general, the overall budgets involved in computerization of POCT for glucose for example is so low that it is not practical to have vendor's IT professionals on-site. Hence, most POCT vendors install, test, and troubleshoot their IT systems remotely using of-the-shelf software like PC Anywhere (pcANYWHERE, WWW.SYMANTEC.COM). The central POCT data management system(DMS) at the user's site must be equipped with a modem and telephone line (dedicated preferred). Remote support over the Internet is also an option; in this instance however the DMS must be attached to the Web which these days raises concerns relative to security.

Interface Standards

All POCT devices and associated instrument controllers subsystems (usually located in the central laboratory) must conform to either 1) ASTM (American Society for Testing and Materials) interface standards E 1381-91 and E 1394-91 or 2) the HL7 (Health Level 7) interface standard. The ASTM standards include specifications for hardware and communications protocols along with record types, record content, and record formats. In addition, the special interface needs of POCT are being considered by the Connectivity Industry Consortium (CIC) which most probably will suggest a new standard patterned after the ASTM and/or HL7 interface standards. HL7 is the standard for interfaces for computers exchanging medical information and is generally used by hospitals which must maintain interfaces between different computer systems. The Active X/COM/DCOM system communication standard has also be adopted by the healthcare industry. The laboratory has more commonly used the ASTM standards described above for instrument-computer interfaces with the HL7 standards being employed to interface the LIS with the HIS. However, these days, POCT patient results may need to be interfaced and broadcasted directly to the HIS, the Practice Management System (PMS), the EMR System, etc. without having POCT results transmitted only to the LIS. This emerging issue requires POCT vendors to handle both ASTM and HL7 interface standards.

Bidirectional, Host Query Interface.

The communications between the POCT device and the DMS (Data Management System (DMS) and/or the LIS needs to be bi-directional, host query. More primitive interfaces are merely a "flat-file" download, or dump of data from the instrument (or instrument docking station) to the DMS. Obviously, delta checking and other QC/QA options for the device are not possible unless the device can communicate with the DMS or LIS. Also, bidirectional host query interfaces are quite useful for billing issues and may include the POCT device retrieving medical indications information (i.e., ICD9 codes, International Classification of Disease Version 9) and CPT4 codes (Current Procedural Terminology Versions 4) for compliance and billing purposes.

A bidirectional interface is required to upload new lot numbers for calibrators, quality control information directly to POCT devices. In addition, using bidirectional communication, a remote POC coordinator could deactivate a device remotely based on out-of-control QC result, calibration, or other reasons. Clearly, for overall control of a complex POCT program with many remote devices, a real-time bidirectional interface with all devices would be a desirable (if not essential) feature.

Handheld devices, unless equipped with wireless capability and the hospital can support wireless transmission of data to wireless hubs, are presently transmitting data via remote docking stations usually in batch mode. This docking station can use a modem for data transmision as shown in Figure 1. Some POCT vendors are actively developing Web Internet/Intranet communication capability. Clearly, the more the testing device "looks like" or emulates an HPC (Hand-held Personal Computer) or client on the network, the simpler the connection to the hospital's "client-server" information infrastructure.

Interface Approach

As described above, the networking of POCT requires that the system use commonly adopted standards for interface communication. The Internet protocol TCP/IP (Transmission Control Protocol/Internet Protocol) is the universally accepted standard for Ethernet network communications. Also, those vendors who have designed their instruments in a manner whereby they can function as "clients" on a "client server" network backbone have obvious connectivity advantages using a specific network IP address for each device (see Figure 2). For various hand-held devices presently not emulating an HPC (hand-held computer) client, the vendor must transmit data from these devices to a Data Management System(DMS)/Instrument Communication Controller (ICC, a high performance personal computer (PC, IBM compatible) usually located in the central laboratory) which then can emulate a client on the hospital network backbone (see Figures 1 and 2). To physically transmit the data from the hand-held device, a data docking station must be available on the floors(see Figure 1). This suggests a "batch" orientation to the transmission of patient results, etc. Also, the data docking station serves a dual purpose of charging the battery on the hand-held device in some configurations. The DMS then transmits patient results (in real-time or batch) from various interfaced POCT devices to the LIS via an EDI (Electronic Data Interchange) interface or a Scripted Interface (SI, see below). The DMS/ICC client is also best designed as a PC with a graphic user interface (GUI) running Microsoft Windows 95, 97, 2000 or NT ( Microsoft, Redmond, WA ). The application language most commonly used is Visual Basic (VB or C++) and the system usually saves data in a Microsoft database which must conform to ODBC (Open Database Communication) standards. Many vendors have selected Microsoft Access as the DMS database. Web based programming is also an option for the user interface (GUI) where HTML (Hypertext Markup Language) and XML (Extensible Markup Language) is used to develop and link user applications on the DMS client.

Other networks are found in hospitals which may impact the success of the POCT IT project. These networks include Novell Netware, Microsoft NT, and IBM Token-Ring. Older versions of network software may negatively impact interfacing particularly the TE/Scripted Interface.

Many vendors of LIS systems have moved to client server versions of their products. These include Cerner, Sunquest, HBOC, SCC, Citation, and others. Connecting to such client server LIS is facilitated when the POCT vendor has taken a client server approach to their products (see Figure 2). However, it is folly to assume that all hospitals have sophisticated client server networks, associated cabling, remote network closets with hubs, and readily available wall jacks (or wireless capability) available to attach POCT devices. Likewise, many vendors are not ready to handle sophisticated IT solutions. Table 3 lists the various types of physical connections that are now required to interface POCT devices.

Interfacing POCT Using Terminal Emulation(TE) and Scripting Tools

There are a number of vendors which supply connectivity tools using a combination of terminal emulation and scripting of screen data entry, navigation, function keys, hot-spots, etc. Vendors such as WRQ (WRQ Seattle, WA) provides a suite of emulation products for virtually any client mainframe including, IBM, DEC (Digital Electronics), DG (Data General), HP (Hewlett Packard), RS6000 (IBM RISC, AIX/Unix), etc. Since most legacy LIS/HIS systems use these systems, a personal computer PC can serve as an interface between these different platforms provided that 1) the PC is physically attached to both systems, 2) the PC is running a multitasking operating system, and 3) the emulation software for terminal emulation to the two systems being connected is running. For example, a DMS in the laboratory can communicate with a legacy LIS system using scripting. The scripted interface uses existing programs on the LIS (emulating a user manually keying data, commands, screen navigation, etc.), then passes along data collected from a remote POCT device to the LIS just as a user would manually enter the test results into the LIS. For a test result, the scripted interface could execute all of the functions listed in Table 4 by invoking existing programs on the LIS.

As can be seen, all aspects of the test are handled by the script including even the business functions of ordering and billing the test. The expert decision making scripts on the LIS then can make additional decisions about the data and can even auto-verify the results after delta checking, etc. In some cases, auto-verification is handled on the DMS automatically using scripted rules or done manually by the technologist in the central laboratory after viewing each result individually. Otherwise, verification is implied by the technologist uploading a batch of data from the DMS. Clearly, the advantages of scripting an interface over other approaches (see EDI interfacing below) for POCT are many. All aspects of the testing process can be potentially automated. Features of a scripted interface are as follows:

- Uses existing programs on the mainframe
- Less expensive to develop and implement
- More volatile and may crash with new releases of LIS/HIS software
- Potentially can handle all required aspects of the "testing process"
- Obviates the need of developing hard-coded inflexible interfaces with many different clients
- Works best with a server in the laboratory with one connection to the LIS
- Allows for batch downloads and/or real-time interfacing
- Runs slower than hardcoded EDI interface
- Does not require involvement of LIS/HIS vendor

Another feature of the DMS in the Core laboratory is that it can emulate a terminal on the LIS obviating the need for a separate "dumb terminal" or client to view transmitted POCT data on the LIS to verify transmission, verify POCT results, view and verify QA/QC, etc. The terminal emulation session is always displayed on the task bar when the DMS is running under Microsoft Windows.
Even though some vendors of LIS systems run on standard hardware such as Data General, their applications employ special functions, navigation, and keystroke features that require a proprietary emulation program. The legacy Meditech (non-client server version) LIS is such a system. Hence, the user must purchase a special emulation package from the LIS vendor in order to use a TE/scripted interface approach. Also, some vendors of LIS are not cooperative with POCT vendors when it comes to developing an EDI (Electronic Data Interchange,see below) interface leaving the scripted interface as the only option for connectivity.

The "Hard-Coded" EDI Interface

Hardcoded interfaces are required by POCT devices that do not have DMS systems to handle communication with the LIS/HIS. Such devices are usually connected to a terminal server port in the remote closet or require a "pull" of serial cable to the central laboratory LIS device controller. Essentially "Dumb" POCT devices can be made to emulate intelligent devices using a "black box" from third party vendors (Dawning Technologies, Fairport, NY). Indeed, as mentioned the DMS (or ICC) can be either be proprietary (usually from the vendor of the POCT devices) or from a third party "universal translator" (Instrument Manager, Data Innovations, South Burlington, VT or Dawning Technology) which accepts data from any "dumb" instrument in any format or protocol then converts it to a language that the LIS/HIS can accept. Such data translators such as Dawning and Data Innovations are called "interface engines." If the POCT device conforms to the ASTM standards for information interchange, interfacing the device directly to the LIS is feasible using an EDI approach. Many POCT blood gas instruments can be directly interfaced using EDI. Rarely is EDI used with a POCT service using many hand-held devices and/or docking stations. For example, many hospitals may have hundreds of POCT devices (glucose monitors, etc.). It is not feasible to attach each device independently and accordingly vendors usually transmit remote device data to one DMS in the core laboratory which emulates one instrument (using EDI) or one user (using Scripting) on the LIS. The EDI interface usually supports the transfer of patient results serially ( using serial ASCII code (American Standard Code for Information Interchange)) to the LIS and may (but usually does not) support all required aspects of the testing process. The EDI interface does run faster and in many cases is more reliable than the Scripted Interface. Most EDI interfaces can run in real-time for data transmission or in batch. The EDI does not require an additional personal computer workstation for data transmission but usually requires a "dumb" terminal to 1) establish and troubleshoot the connection between the instrument and LIS, 2) to place the order manually on the LIS, and 3) to review and verify the result on the LIS after data is transmitted from the POCT device. Some newer POCT devices are actually Microsoft PCs and hence can emulate a "dumb terminal"; these POCT devices do not require the extra terminal for use.

Connecting devices to the LIS/HIS obviously gets more complicated and expensive the less the vendor has planned for IT issues. While a vendor may be able to workaround the lack of IT expertise and planning for data transmission using black boxes, third-party devices, etc., it is obviously an advantage to have the POCT device designed to embrace data communication and associated standards as part of the original design of the instrument. However, when using older legacy POCT devices, workarounds for data management are generally the only option.

Data Management Subsystems/Instrument Communication Controller

As mentioned above, most DMS/ICC, as the name implies, have major functions which include:

- Data management of QC/QA of the POCT program
- Data management of patient test results
- Communication control and connectivity with the LIS/HIS
- Terminal Emulation on the LIS to establish connection, verify transmission, etc.
- Data repository and archival functions for outcomes analysis
- Data concentration and communication with multiple POCT devices
- Monitors remote devices in real-time and allows for remote deactivation
- Transmits new QC and calibration data, lot numbers, to remote devices
- Facilitates on-line troubleshooting of remote devices
- Prints hardcopy logs, corrective action logs, QC lot reports, patient logs, preventative maintenance logs, calibration logs, Levey-Jennings QC Graphs, etc.
- Facilitates meeting JCAHO, CLIA88 and CAP requirements for POCT accreditation
- Allows scanning or manual entry of data for non-automated POCT tests for urinalysis, pregnancy, cardiac markers, glucose strips, etc.

Many of these functions are generally not available on the LIS or HIS and hence a DMS/ICC is required for a comprehensive POCT program. Many of the DMS systems are proprietary and hence, a different DMS is required for each POCT program. Vendors view the DMS as part of the POCT product and are not receptive to solving connective issues for other vendor's competing devices. The lack of a universal DMS means that the POC coordinator must have a plethora of DMSs to run and support, each with unique software and connectivity features as described above. Third-party DMS systems such as Dawning and Data Innovations are less proprietary and can potentially connect devices from any vendors. Neon (a third party software vendor formerly named Microscript) has developed a TE/ Scripted Interface system called MediSense Precision Net for Abbott (Abbott Laboratories, Abbott Park, IL). This latter system appears to be proprietary in that MediSense is only sold as a solution to users of Abbott POCT products.

Data Management Requirements of DMS

The DMS must maintain databases in order to support the POCT program. One database is designed to store patient test results and associated normal ranges, units, patient's age, sex, birthdate, date and time of test performance, transmission date and time, verification date and time, performing analyst ID, verifying analyst ID, ICD9 code or medical indications for test, doctors UPIN (Universal Physician ID Number), location of patient and device, device code, quality control results (electronic) or from QC material and lot number, date and time of QC, date and time of calibration and lot number for calibration material, electronic status checks or flags from the instrument, free text comments, coded text comments, LIS accession number, order number, patient's medical records number and encounter number, etc. The DMS should also maintain a second database with information regarding QC and calibration of each device and track this information over time to insure the device is in continuous control. The DMS database should also store QC results and provide Levey-Jennings plots and printouts. A third database may include operator training and performance data especially on QC materials. Accuracy and precision of every analysts should be monitored periodically using this database. An archival database for patient outcomes, cost analysis, trending and tracking of the overall POCT program should also be available to justify the expense and effort required for a comprehensive POCT program. A system maintenance database is also required for large program such as glucose meters.

The database on the DMS should conform to industry "open" ODBC standards and thereby compatible with off-the-shelf spreadsheet software, databases like Microsoft Access, and ad hoc reporting software such as Crystal Reports (Seagate Software, Bellingham, WA). These tools will allow for data reduction of subsets of the database and ad hoc reports essential for satisfying management and accreditation requirements.

The Physician Order, Coding, Billing and Business Functions

The cost involved in any POCT program must include plans to bill for services when appropriate. Indeed, non-Medicare billing in the USA can amount to millions of dollars for a glucose monitoring program alone. For example, many larger hospitals may perform 200,000 POC glucose tests each year at $14.50 per test. The amount of revenue that can be generated can more that cover the expenses of POCT. However, less than 10 percent of POCT is billed currently. This is due to the fact that many POCT programs are poorly planned with regard to electronic capture of charges, CPT4 codes, ICD9 codes (or text strings with findings, signs, symptoms, or diagnosis), physician UPIN numbers, and other data elements required for billing purposes.

The Physician Order

In order to bill for a test, the physician must place the order. For the Scripted Interface, the LIS can order the test using a special charge program or the charge for the POCT can be captured as part of the scripted test order. For hospitals requiring order entry from the floors and Units, the scripted order can be placed on the HIS or patient management system. Billing is usually captured on such systems as the order is placed. In this case, the order for the POCT is transmitted to the LIS in real-time. Experience has shown that nurses and physicians in critical care areas are not willing to manually place the order for the POCT directly on the HIS system because of the time and effort required. In this situation, a scripted interface with the order being placed on the LIS has worked out as the best solution. However, the script must have the physician's UPIN or other identifier in order to place the POCT order electronically by EDI or script.

Billing for non-Medicare patients should be added to other patient charges. For outpatient settings using POCT, billing is electronically charged on a fee-for-service basis. Also, for outpatient POCT, compliance rules require medical necessity documentation be transmitted electronically in the form of free text or ICD9 codes. If the laboratory is providing POCT on a contract basis, each service unit should receive an end of the month statement reflecting all POC tests performed and amount charged.

Integration of POCT Devices with Bedside Monitors

Physicians in critical care areas would prefer to have POCT integrated with the other monitoring data and displayed on the patient's monitor/screen in real-time. Accordingly, significant efforts have been made to allow for the integration of POCT in a modular fashion with other bedside monitoring devices. To date, POCT efforts interfaced with other bedside devices include Viewlink (Hewlett Packard, Andover, MA), BAM-Blood analysis module (Hewlett Packard), Octanet (Marquette Medical Systems, Milwaukee, WI), and Flexport (SpaceLabs Medical, Inc., Redmond, WA). Even though some of these vendors have not succeeded as yet, the ultimate Intensive Care Unit goal is to automatically collect POCT data via the bedside monitoring system. The challenge to the laboratory is to insure that POCT results from bedside monitoring integration systems is transmitted from the monitoring system via network hubs, routers, and gateways to the LIS/HIS and accordingly becomes part of the patient's EMR along with other POCT data.

Integration of POCT Results with Other Laboratory Results

POCT results are reported locally on the device and in real-time and from the LIS via 1) patient cumulative reports, 2) autofax, and 3) remote printing. POCT results are also usually available on inquiry screens on the LIS and HIS systems. Most LIS report POCT results under a separate POCT header rather than combining these data with other non-POCT results. Also, expert LIS software automatically appends a coded comment to POCT results stating that all testing was performed by nursing or respiratory care personnel.

Conclusions

It is clear that the technology of POCT devices along with associated DMS is such that presently computerization of POCT data can be achieved in most laboratories. With current IT trends in hospitals, vendors of POCT devices and users alike must continue to enhance their ability to install and support complex networked IT systems using affordable off-the-shelf tools. Indeed, the POCT automation system of the future must have expert capability allowing for remote support and decision making by the software which continuously evaluates each device on the POCT network backbone. To achieve this level of connectivity, the system must conform to all existing and emerging standards for communication, databases, medical terminology, medical coding, etc. Vendors and users alike must recognize that they are no longer in the laboratory testing business. Indeed, laboratories are in the information business where information is essentially extracted from specimens using biosensors and probes. Furthermore, this information is of little or no value in critical care unless it arrives at the patient's bedside in time to assist in the clinical decision making. As we move to more evidence-based medicine throughout the hospital, turnaround time and the predictability of laboratory services will drive decisions to both 1) centralize and automate core laboratory testing while at the same time 2) decentralizing critical care testing to the patients' units, floors and bedside. It would appear that for at least the foreseeable future, information technology issues and costs will continue drive the automation and POCT computerization decisions in the laboratory more than any other considerations.

References

[1].  Herzlinger R. Market driven health care who wins,who loses in the transformation of America�s largest service industry. New York:Addison-Wesley;1996.

[2].  Kost G, Hague C. The current and future status of critical care testing and patient monitoring. Am J Clin Pathol 1995;104:S2

[3].  Blick KE, Halpern NA. Information Systems in Critical Care, Point-of-Care Testing: Principles, Management and Clincal Practice, GJ Kost, Ed., in press. 

[4].  Nichols, JH, Management of Point-of-Care Testing, Blood Gas News 1999; 8:1-4. 

[5]. ASTM Committee (l991) E-31 ASTM specifications for protocol to transfer messages between clinical laboratory instrument�s and clinical laboratory computers, ASTM Standards, Vol 14.01, American Society for Testing and Materials, Philadelphia, PA.

[6].Health Level 7(HL7) Standard, Version 2.2, 1994, (http://www.hl7.org), Ann Arbor, MI