Information System Issues Facing Clinical Laboratories Serving Complex Integrated Delivery Systems

Information System Issues Facing Clinical Laboratories Serving Complex Integrated Delivery Systems

Walter H. Henricks, MD

ABSTRACT

Laboratory information systems (LISs) have evolved into complex applications to meet the specialized needs of laboratories. As integrated delivery systems (IDSs) continue to emerge as a dominant model for healthcare delivery, clinical laboratories serving them face two imperatives that affect IS decisions. First, laboratories in IDSs must consolidate to reduce costs and duplication yet deliver service across a region in both inpatient and outpatient settings. Second, laboratories that successfully perform reference laboratory testing will increase revenue, generate referrals, and leverage excess capacity, and may provide a competitive advantage for the IDS. This article examines laboratory information management in complex IDSs, presents options for IS support of consolidating or integrating laboratory operations, and reviews functionality requirements for laboratory outreach activities.

KEYWORDS

  • Clinical laboratory
  • Integrated delivery systems
  • Outreach
  • Laboratory informatics
  • Functionality requirements
  • Interfaces
  • Integration
  • Electronic medical record

Laboratory information is a cornerstone of the electronic medical record, representing the majority of the nondemographic, nonfinancial clinical data present in most healthcare institutions' information systems. Clinicians rely heavily on laboratory test results and interpretations to make critical decisions that govern patient diagnosis and treatment and dictate resource utilization. Although laboratory costs make up less than 5 percent of a hospital's budget, laboratory services affect 60 to 70 percent of all critical clinical decisions, such as admission, discharge, and drug therapy.1

As integrated delivery systems (IDSs) mature and put year 2000 compliance concerns behind them, the focus in many of these enterprises will be on achieving tighter integration of laboratory services throughout the organization. Delivery of laboratory service on a regional level requires laboratory information systems that can integrate information from multiple sites and settings. To meet the voluminous and complex data handling needs, laboratory information systems have evolved into specialized applications. The challenge to those contemplating, planning, or implementing laboratory information systems is to understand the unique requirements of laboratory computing so that informed purchase and planning decisions ensue.

This article will first discuss IDSs and the forces affecting the delivery of modern clinical laboratory services. Next, it will focus on the organizational and technical aspects of laboratory computing in complex IDSs by examining information system options for integrating laboratories and by outlining functionality requirements for laboratory outreach testing. Finally, it will discuss trends that will significantly affect laboratory computing in the future.

IDSs and Imperatives Facing Clinical Laboratories

Integrated delivery systems (IDSs) have emerged as a dominant model of healthcare delivery over the past ten to fifteen years. An IDS may be defined as a group of healthcare service units working together as an entity to provide a spectrum of healthcare services across a geographic region. An IDS may consist of any number of healthcare entities such as hospitals, outpatient clinics, ambulatory surgical centers, long-term care facilities, and physician offices.

Economic pressures brought on by managed care have stimulated the rapid growth of IDSs. Under managed care, a health provider network delivers healthcare services on a contracted, increasingly capitated basis. Capitation means that payments are prospective and fixed. Under capitation, healthcare providers make a profit only if costs do not exceed the fixed reimbursement. If costs are greater than the contracted revenue amounts, there is economic loss. Consequently, under managed care and capitation, economic survival demands controlling use of services.

IDSs are vertically and horizontally integrated organizations. They are vertically integrated in that they provide the entire spectrum of healthcare service ranging from primary to tertiary to long-term care. They are horizontally integrated in that they offer services at multiple locations in a geographic region.

Horizontal and vertical integration enables IDSs to meet economic goals. First, by providing the entire spectrum of care, they may promote wellness and prevention strategies to decrease utilization of more expensive services. Second, by their size and scope, they may realize economies of scale and reduce inefficient redundancy. Third, by extending the breadth of services offered and offering them over a geographic region, they can increase their market share. Fourth, by controlling a significant number of access points to healthcare in a region, an IDS gains leverage in negotiations with payers. The horizontal and vertical nature of these organizations has significant implications for the delivery of laboratory services.

IDSs have created imperatives for clinical laboratories that significantly affect information system decisions. The first imperative relates to laboratory consolidation in response to cost pressures. In addition to consolidating facilities and services, the clinical laboratory will have to deliver services on a regional basis. Second, laboratories that perform outreach testing will generate fee-for-service revenue to offset reimbursement losses from capitation and decreased reimbursement schedules.

Challenges of Consolidation and Geography. Laboratory testing is viewed as a prime area for consolidation of services and may be one of the first clinical areas so targeted in an IDS. Under capitated reimbursement and managed care, laboratory services are a cost center in healthcare organizations. Consolidation in laboratory services in an IDS means centralizing as much laboratory testing as possible at a minimum number of high-volume sites that maintain the technology and skilled personnel to offer broad test menus. The amount of lab testing and number of personnel at lower-volume or less well-equipped sites is reduced or eliminated. Analogous to consolidation of their parent entities, consolidation of laboratory services in IDSs decreases costs by eliminating redundant laboratory services and sites and by optimizing use of excess testing capacity. Furthermore, consolidation can reap the benefits of standardization of practices and economies of scale.2-6

At the same time laboratories are consolidating, the goals of IDSs dictate that laboratory service be delivered on an integrated basis over a geographically dispersed region into the variety of outpatient settings beyond the hospital, such as outpatient clinics, ambulatory surgery centers, and physicians offices that constitute the IDS.2,7 First, effective consolidation of laboratory services in an IDS, as already outlined, mandates a regional approach to the delivery of laboratory services. Second, and perhaps even more germane to the goals of a truly integrated IDS, clinicians, patients, and others will expect that laboratory information be entirely portable within the organization across the region, with laboratory information available anywhere the patient contacts the system and at any time. In other words, laboratory information will be of greatest value when seamlessly integrated across the system.8

Clinical Laboratory Outreach Testing. The second imperative for clinical laboratories serving IDSs is to develop outreach or reference laboratory testing programs in response to economic pressures. Now seen as cost centers, laboratories must take steps to reduce expenses. Furthermore, reimbursement schedules for laboratory testing not under capitated arrangements continue to decrease. In an outreach or reference laboratory testing program, a laboratory solicits and then performs tests for nonaffiliated clients (hospitals, physician offices, and so on). The laboratory, and by extension the IDS, receives direct reimbursement from those clients for tests performed, much like commercial reference laboratories.

The benefits of outreach testing are significant and may be necessary for the economic viability of the laboratory. Revenue generated offsets other revenue decreases brought on as a result of declining payer reimbursements and managed care contracts. Such revenue may become a crucial part of the laboratory's contribution margin to the organization. Furthermore, performance of outreach testing leverages any excess testing capacity of laboratory analyzers and processes. The existing plant and equipment fixed costs are spread over a greater test volume, lowering cost per test.1 Consider a simple example: The laboratory receives outreach specimens each evening for thyroid and tumor marker testing from client sites. An immunoassay analyzer that would otherwise be dormant during the night performs the tests. Because the analyzer is already a fixed asset in the laboratory with sunk costs, increasing the volume of tests reduces the fixed cost per test. Finally, outreach testing may generate patient referrals and thus provide a competitive advantage for the IDS.

Consolidating laboratory operations while delivering service on a regional basis and developing outreach programs requires a significant shift in focus for traditional hospital-based laboratories. No longer is it adequate to collect specimens from and then report results to the wards in a single hospital. Now clinical laboratories serving geographically dispersed IDSs must deliver services to a variety of settings, each potentially having different requirements and expectations. The leadership IDS and the laboratory must plan in terms of an integrated, regional laboratory service, and laboratories must meet the diverse requirements of the outpatient and outreach environments in addition to those of the inpatient setting.

From managed care, IDS creation, and desire for laboratory consolidation has emerged the model of a networked, regional laboratory service that typically consists of a main core laboratory and smaller, rapid-response laboratories. In this model, one hospital-based laboratory acts as the central core laboratory, performing non-STAT for all IDS sites as well as outreach testing. The term "hybrid" laboratory has been applied to laboratories that have the capability to service inpatient, outpatient, and outreach settings.6 The concept of the hybrid hospital-reference laboratory is that of a hospital-based lab that is both inward-focused and outward-focused. The inward focus refers to traditional hospital service at the main campus. For modern clinical laboratories, the outward focus consists both of the IDS at multiple sites over a geographic region and nonaffiliated outreach clients. Core laboratories of IDSs in this model indeed function like hybrid hospital-reference laboratories. Other sites in the IDS maintain rapid-response laboratories that perform STAT testing on site.

Having presented the contextual environment for laboratory computing in an IDS, this article shall now examine technical and organizational aspects of the options for information system support for networking and integrating laboratories in IDSs.

LIS Foundation for IDSs

As a consequence of laboratories' voluminous data handling requirements and complex operational needs, laboratory information systems (LISs) have evolved into highly specialized and complicated applications that require domain-specific knowledge to implement and support. Laboratories depend on LISs to support the preanalytic, analytic, and postanalytic phases of laboratory testing. Central to an LIS is the laboratory test-definition database, which defines each test element, such as test name, order code (mnemonic), units of measurement, reference ranges, panic values, and so on. For a comprehensive discussion of LIS functionality, the reader is referred elsewhere,9 but briefly, in the preanalytic phase the LIS processes test orders either by manual entry or by electronic interface to a clinical order-entry system, creates phlebotomy lists for inpatients, routes tests to appropriate locations in the laboratory, and electronically downloads test orders and demographic information to automated analyzers (for example, hematology cell counters). In the analytic phase, the LIS receives test results both manually and electronically from interfaced automated analyzers, orders additional tests reflexively based on preliminary results, and automatically accepts or rejects test results based on predetermined criteria. In the postanalytic phase, the LIS transmits results to clinicians through paper and electronic interfaces to other computer systems and maintains the database of test results. In addition, the LIS creates and stores audit trails and other information necessary to meet regulatory and accreditation mandates.

An integrated laboratory service in an IDS is even more dependent on effective laboratory information systems than is an individual laboratory. For an IDS to meet its patient-care and economic goals, laboratory service must be delivered on a regional basis. In order to coordinate services and achieve the portability of laboratory information required by clinicians and patients, laboratory sites in various facilities must be able to communicate with one another, particularly as consolidated models are adopted in which specimens collected at certain sites are transported to other sites, such as the core laboratory, for testing.

Two basic laboratory information system options exist to enable distributed laboratory services across an IDS: deploy a single LIS with multifacility functionality across the entire system, or interface multiple existing LISs at different sites to the LIS at the core lab. Organization and technical aspects of these options, their advantages and disadvantages, and other issues to consider are described in the following paragraphs.

Multifacility Software Option. Many LIS vendors offer multifacility logic capability as part of their system. This single multifacility LIS approach provides for the sharing of a single hardware and single LIS software platform among the multiple hospital laboratories serving an IDS. The facilities share one set of processor (CPU) and storage hardware, one operating system, one user area, and one laboratory test-definition database. Comprehensive specimen tracking across multiple sites is possible.

The consolidated or networked laboratories may range from relatively independent facilities to smaller rapid-response laboratories networked to a main core lab, depending on the degree to which true consolidation and integration in laboratory operations has occurred across the IDS. If laboratory services are truly integrated—that is, IDS-wide standard practices and procedures are in place—the laboratories can share all system parameters and a single test result database. All users potentially have access to the entire database, although certain restrictions (for example, based on patient location) may be possible.

If the individual laboratories in an IDS function with some independence, the database can be partitioned on the basis of different laboratories. In this environment, each facility is assigned some form of specific facility code identifier. User access can be restricted on a site-specific basis. Furthermore, the multifacility software option does not necessarily require a common patient identifier to be in use across the IDS. Methods such as associating the facility ID code with each patient ID number can maintain unique patient identification.

The single multifacility LIS approach requires application interfaces, preferably adhering to the health level 7 (HL-7) standard, between the hospital information systems (HISs) at the various sites and the LIS. If there is only one HIS for the IDS, only one interface will be required. The HIS-LIS interfaces are necessary to transfer ADT (admission-discharge-transfer) and other patient registration information between the two systems. In addition, in those facilities where test-order entry into the HIS occurs or where clinicians electronically access lab test results through either the HIS or other repository (rather than through the LIS), application interfaces must communicate test orders, status messages, and results between the LIS and these systems.

At the hardware level in this model, the computing power resides primarily at one main data center. The hardware configuration must provide for excellent performance and responsiveness across the system as well as for adequate data storage. For a host-based system, the only hardware requirements at the individual sites are printers and dumb terminals. In client-server systems, individual sites retain PC workstations, possibly running thin-client versions of the LIS application. Wide area network (WAN) links, most likely in the form of T1 lines, must be in place. Redundancy of systems and network connections is critical to provide sufficient fault-tolerance.

Multiple Interfaced LISs Option. In the multiple interfaced LIS model, the LISs currently in use (legacy systems) at IDS hospitals remain operational. Application interfaces developed using an interface engine create connections among the various LISs. An interface engine is a powerful computer that resides centrally in the IT architecture and routes and translates messages among disparate systems.10 Interface engines simplify interface development and management because the interface from each system is built only once, to the interface engine rather than to each of multiple systems. In addition, based on predefined rules, the engine can duplicate or route messages to other systems connected to the engine. The interfaces connecting LISs in this model route test orders, status, and results among sites according to which laboratories perform given tests.

In contrast to the single multifacility LIS option, which uses a single database, the multiple interfaced LIS model uses various LISs serving the IDS laboratories to maintain multiple individual different sites. Each site retains its own security and user access rules. Standardization of laboratory operations requires redefinition of certain database elements across multiple systems in order to achieve uniformity. Current HIS interfaces to legacy LISs are maintained for ADT data, test orders, and results. Individual laboratory sites retain their existing hardware. Like the single multifacility LIS model, WAN redundancy is critical for this model as well.

Weighing the Pros and Cons. The advantages of the single multifacility LIS approach are significant. Standardization and consolidation of hardware and software decrease maintenance fees and simplify system support. Adding new sites is not only technically simpler because the database is standardized but also incrementally less expensive than deploying a new LIS. Furthermore, IT and laboratory staff need only know one system, facilitating cross-training and eliminating the need to maintain expertise in multiple systems. A more simplified, uniform IT architecture supports the operational goals of standardization of laboratory practices. The potential exists under this option for the LIS to be a single enterprisewide repository for laboratory data.

The disadvantages of the single multifacility LIS approach are primarily the costs of replacing legacy LISs, so-called switching costs. The license and capital costs of the multifacility software and hardware to be extended throughout the IDS will be significant. Legacy LISs will be removed from different sites at various stages of their depreciation cycle, and the more recently a system was installed the greater the cost of removing it. Further costs include new HIS-LIS interfaces and LIS-instrument (for example, cell counter) interfaces. Perhaps even greater than these costs, though, are the implementation costs and the organizational changes required at the labs that are switching LISs. Users who are comfortable and facile with the existing LIS must undergo significant retraining on the new system. Nuances of the new system will become familiar to them only with time and effort. Furthermore, because change of the LIS in this model is linked with standardization of lab practices, laboratory staff must learn not only a new computer system but also new procedures in many aspects of their jobs. Depending on the strength of the corporate mandate to implement the system across the IDS, resistance encountered because of these issues may be the greatest impediment to success as individual sites fight the loss of their autonomy.

The advantages of the multiple interfaced LISs model center on reduced switching costs and the need for less procedural change. Because legacy LISs remain in place, no new multifacility LIS software and hardware costs are necessary, nor are new LIS-HIS interfaces. More importantly, this option requires less organizational change and retraining, and laboratories retain more autonomy (which may or may not be an advantage). Furthermore, as the laboratory IT staff gains experience with the interface engine, the opportunity exists to use this technology to develop interfaces to high-volume outreach clients.

Although its up-front switching costs may be lower, the multiple interfaced LISs approach has a number of drawbacks. Deploying interfaces between different LISs, even when using an interface engine, can be a costly, time-consuming, and frustrating venture, and those not familiar with the process can easily underestimate its complexity. Development of an interface requires cooperation and coordination among at least four parties—the two LIS vendors and the two laboratories involved. Differing timetables and priorities among the principals involved can cause these projects to drag on for many months. At the technical level, because each laboratory has its own unique identifier codes to refer individual laboratory tests, interface development necessitates the building of translation tables to ensure accurate communications. For instance, one LIS may define a serum potassium analysis as "POT" whereas another defines it as "K." The translation table performs the lookup function necessary to map disparate test codes between laboratories. It is important to note here that the recently developed logical observation identifier names and codes (LOINC) standard11,12 defines a standard coding system for laboratory tests and holds great promise to facilitate electronic data exchange among laboratories. If all tests at individual LISs are mapped to the LOINC standard, new translation tables need not be built for each new interface. Not all LIS software currently provides an indexed field in each test definition for a LOINC code, however.13

Maintenance and support are more challenging in the multiple interfaced LISs model and more costly because of the number of different systems involved and the complexity of the environment. Perhaps the greatest drawback of this option is the failure to achieve fully the goals of laboratory integration and consolidation because of the lack of a standard information system and data structure for the laboratories.

Given the imperatives of laboratory integration across an IDS and the envisioned benefits of consolidation, the preferred solution is the single multifacility LIS model, in which a single LIS platform supports operations across multiple sites. The standardization of data and practices as well as the simplification of the IT environment form a powerful underpinning for a truly integrated laboratory service. Strategically, the long-term benefits will likely outweigh the initial costs and organizational challenges that will arise during implementation.

Unfortunately, as mentioned, the switching costs in deploying a single IDS-wide LIS may be higher than the organization can tolerate financially or operationally. Furthermore, because IDSs in reality are dynamic entities, the degree to which laboratory services are consolidated and integrated may vary widely from IDS to IDS and perhaps even within an IDS. Certain issues influence the extent and rate of integration of laboratory services, such as the timing of new mergers and acquisitions, institutional priorities, and the relative balance of enterprise mandates to consolidate services versus political concerns such as desire for autonomy at certain facilities. If the start-up costs are prohibitive or if timing or other issues are paramount, interfacing different LISs may be the only feasible option. A workable interim solution may be a hybrid situation in which some sites deploy multifacility LIS logic and others are initially interfaced, with a strategic vision of migrating such sites incrementally to the main LIS.

Functionality Requirements for Outreach Testing

As described earlier, in addition to delivering integrated laboratory service across an IDS, a second imperative for modern clinical laboratories is to develop outreach, or reference laboratory, testing programs. Most if not all of these laboratories are running traditional hospital-focused LIS software, however. Although these systems are optimized for the hospital-based laboratory setting, they often lack important functionality necessary to support outreach operations. In fact, even recently, outreach functionality present in hospital-type LISs has been described as abysmal by a leading authority inthe field.2

Successful outreach programs in hybrid hospital-reference laboratories require information systems that have a client-centric orientation in addition to the patient-centric view of the hospital environment. The challenge facing laboratories in this regard is to find an information system—or potentially, combinations of systems—that satisfies the requirements of both environments. In the hospital-based, patient-centric view, laboratory information is oriented longitudinally around a patient stay, and laboratory reports are delivered to inpatient units for charting each day. Test requisition forms and report formats are uniform. Lab results are accessed electronically in either the HIS or LIS on the basis of patient name or identification number. The database does not accommodate client-specific information.

In a client-centric orientation, the LIS database maintains a field for client ID codes to which client-specific information and parameters are linked. The ability to view information filtered by client is central to meeting customers' expectations in the outreach testing market. Important client-specific functions include electronic results inquiry, fee schedules, requisition forms, report formats, utilization and management reports, and data mining.

In addition to these client-specific features, the best outreach systems will have the following capabilities that are necessary for outreach-specific elements of laboratory operations, billing and financial concerns, and logistics:14

  • Multiple methods for remote report distribution, including remote printing, fax, e-mail, Internet, pager, personal digital assistant (PDA)
  • Multiple site report distribution
  • Graphical reporting
  • Grouping of all test results from a single requisition in a single report
  • Electronic test order entry at client site
  • Instrument-ready barricaded specimen label printing at client site at time of order
  • ICD-9 input capability
  • Required fields during order entry
  • Medical necessity checking and advance beneficiary notice (ABN) printing
  • Billing flexibility-ability to bill by client, insurance, patient
  • Management reports by test, by payer, by client
  • Courier management
  • Help desk-client call center
  • Specimen tracking
  • On-line test directory


Trends Affecting LIS Decisions in the Future

Two trends promise to transform the delivery of integrated laboratory services in an IDS: advanced point-of-care testing (POCT) technologies and expansion of the use of Internet and World Wide Web tools. Point-of-care testing refers to the use of portable or handheld devices to perform laboratory measurements at the patient's side. The most common examples of POCT are glucose and coagulation monitoring. POCT offers the advantage of nearly immediate availability of test results at the time and place the patient is being evaluated. As POCT technologies continue to improve, menus of available test types will increase and costs will likely decrease. As these advances occur, more healthcare organizations may wish to take advantage of the benefits of POCT. The net effect will be a decentralization of laboratory testing, with a greater percentage of testing occurring at the patient's side.

The information management challenges of POCT are substantial.15 As healthcare organizations expand the use of these devices, effective information management measures are necessary to integrate POCT results into the electronic medical record and to meet regulatory requirements. The need to capture and to integrate data from hundreds of individual dispersed handheld POCT devices adds another layer of complexity to laboratory computing. Such integration requires the development of electronic interfaces between the POCT devices and the LIS. A lack of connectivity standards for POC devices, however, poses the greatest hurdle for institutions wishing to deploy such interfaces. As a consequence, the development of interfaces depends on either vendor-dependent proprietary schemes or customized site-specific ("home-brew") programming. Recently, the Connectivity Industry Consortium (CIC), which includes representatives from POCT vendors, LIS vendors, and healthcare institutions, has formed with the aim of developing connectivity standards for POCT.16

The second trend is that laboratories and IDSs will increasingly make use of Internet and Web-based tools to achieve their regional information integration needs.7,17 Central to the attractiveness of Web-based solutions is that the technology uses accepted, well-defined, open standards, which facilitates deployment and interoperability and reduces costs. Because Web-based architecture can be layered over existing legacy systems, the potential exists to achieve integration without replacing current systems or writing specific interfaces. Web-based software achieves integration by providing the means to access information from different legacy systems across the IDS and present it to the user seamlessly in an integrated format in the familiar browser-user interface. As an example pertaining to laboratories, using a Web-enabled LIS from anywhere (with proper privileges and authentication) and using any device running a browser, a clinician could access lab test results on a given patient that reside in multiple LISs and view them in an integrated, standardized display. In addition, because browsers require relatively little computing power (and are known as "thin clients"), the access device may even be an information appliance such as a personal digital assistant (PDA) or a cellular phone.

Evidence of migration toward Web-based tools in clinical systems exists. The deployment of Web-based tools in clinical laboratory information systems is still in its relative infancy but promises to expand dramatically in the near future.18 One of the first areas in which this occurs will likely be in the software that physicians' offices use to exchange test orders and results with reference laboratories. A number of vendors of these systems currently offer Web-based solutions for this application.19 At the enterprise level, IDSs are beginning to deploy intranets to integrate all functions systemwide.20,21

The increasing decentralization of laboratory testing to the point of care coupled with the improving integrative capabilities of information technology, particularly Web-based tools, promises to continue to transform clinical laboratories serving IDSs into so-called virtual laboratories.6,17 The notion of the virtual clinical laboratory, or the "laboratory without walls," has emerged in recent years to describe a laboratory service that is distributed across multiple testing nodes ranging from POCT to core laboratories and made possible only by the "glue" that modern information technology provides. Such a laboratory service is virtual in that it appears to be a single entity while actually consisting of multiple entities functioning in a coordinated manner. In this respect, the concept of the virtual laboratory represents the completely integrated regional laboratory service, consolidated and decentralized at the same time, that meets the patient care and business needs of the IDS.

Conclusion

Optimal delivery of clinical laboratory services is necessary for an integrated delivery system to meet its patient-care mission and its business goals. Hybrid hospital-reference laboratories in IDSs must deliver service to geographically dispersed inpatient, outpatient, and outreach environments. Because laboratories depend on laboratory information systems to support their operations, these systems must be able to accommodate the unique requirements of all of these settings. Just as clinical laboratory information is a cornerstone of the electronic medical record, laboratory information technology is the cornerstone of integrated laboratory services in an IDS.

References

  1. Forsman, R. W. "Why Is the Laboratory an Afterthought for Managed Care Organizations?" Clinical Chemistry, 1996, 42(5), 813-816.
  2. Aller, R. D. "Creating Integrated Regional Laboratory Networks." Clinics in Laboratory Medicine, 1999, 19(2), 299-316.
  3. Diehl, C. "Standardization Across Multiple Sites." Clinical Laboratory Management Review, 1998, 12(5), 347-352.
  4. Fattal, G. A., Frost, Y., and Winkelman, J. "Operational and Financial Outcomes of Shared Laboratory Services in a Consolidated Hospital System." Journal of the American Medical Association, 1985, 253, 2076-2079.
  5. Steiner, J. W., Michel, R. L., and Watt, D. K. Case Studies for Laboratory Restructuring: Developing Practical Business Solutions. Managed Care Series, Washington G-2 Reports and Clinical Laboratory Management Association, 1995.
  6. Steiner, J. W., Root, J. M., and Michel, R. L. The Transformation of Hospital Laboratories: Why Regionalization, Consolidation, and Reengineering Will Lead Laboratories into the 21st Century. Report in the Hospital Technology Series. Chicago: American Hospital Association, 1995.
  7. Connelly, D. P. "Integrating Integrated Laboratory Information into Health Care Delivery Systems." Clinics in Laboratory Medicine, 1999, 19(2), 277-297.
  8. Friedman, B. A., and Mitchell, W. "Integrating Information from Decentralized Laboratory Testing Sites: Creation of a Value-Added Network." American Journal of Clinical Pathology, 1993, 99(5), 637-642.
  9. Elevitch, F. R., and Aller, R. D. The ABCs of LIS: Computerizing Your Laboratory Information System. Chicago: ASCP Press, 1989.
  10. Gendler, S. M., Friedman, B. A., and Henricks, W. H. "Using Hub Technology to Facilitate Information System Integration in a Healthcare Enterprise." American Journal of Clinical Pathology, 1996, 105(Suppl. 1), pp. S25-S32.
  11. Forrey, A. W., McDonald, C. J., DeMoor, G., Huff, S. M., Leavelle, D., Leland, D., Fiers, T., Charles, L., Griffin, B., Stalling, F., Tullis, A., Hutchins, K., and Baenziger, J. "Logical Observation Identifier Names and Codes (LOINC) Database: A Public Use Set of Codes and Names for Electronic Reporting of Clinical Laboratory Test Results." Clinical Chemistry, 1996, 42(1), 81-90.
  12. LOINC Home Page. [http://www.mcis.duke.edu/standards/termcode/loinc.htm].
  13. Aller, R. D., and Carey, K. "Are We the Way We Were?" System review series, CAP Today, 1999, 13(11), 64-88.
  14. Fantus, J. E. "Business Strategies for Hospital Outreach Programs." Clinical Laboratory Management Review, 1999, 13(4), 188-196.
  15. Halpern, N. A., and Brentjens, T. "Point of Care Testing Informatics: The Critical Care-Hospital Interface." Critical Care Clinics, 1999, 15(3), 577-591.
  16. CIC Home Page. [http://poc.labs.agilent.com/poc].
  17. Friedman, B. A. "Integrating Laboratory Processes into Clinical Processes, Web-Based Laboratory Reporting, and the Emergence of the Virtual Clinical Laboratory." Clinical Laboratory Management Review, 1998, 12(5), 333-338.
  18. Southwick, K. "Intranet Technology Seeping into Laboratories." CAP Today, 1999, 13(1), 5-7, 11.
  19. Aller, R. D. "Delving into Designs of Physician Office-Lab Links." CAP Today, 1999,13(5), 36.
  20. Southwick, K. "Baylor's Intranet: More Than an 'Electronic Brochure.'" CAP Today, 1999, 13(5), 26, 28-30.
  21. Bowers, D. "Linking and Integrating Enterprisewide Health Information Management Data." Journal of Healthcare Information Management, 1998, 12(3), 81-88.

About the Author

Walter H. Henricks, MD, is Medical Director of Laboratory Information Services at The Cleveland Clinic Foundation. He also practices surgical pathology and clinical pathology at The Cleveland Clinic.


JOURNAL OF HEALTHCARE INFORMATION MANAGEMENT®, vol. 14, no. 3, Fall 2000
© Healthcare Information and Management Systems Society and Jossey-Bass Inc., Publishers