Printer Friendly

How to succeed with a lab-hospital interface.

How to succeed with a lab-hospital interface

Hospitals are under fierce pressure to achieve greater efficiency. This makes it virtually certain that any laboratory information system (LIS) will be required to interface with an existing or planned hospital information system (HIS) or operate within such a system as an integral component.

Interfacing will take place more often because most LISs are stand-alone systems developed by firms other than the HIS vendor. Unfortunately, laboratorians and data processing specialists alike view the task of interfacing with considerable trepidation.

Why is this so? What can be done to avoid pitfalls? I will review some of the key operational considerations in LIS-HIS interfaces from a user's perspective and suggest ways to minimize trauma and improve the odds of success.

An interface significantly enhances both the LIS and HIS. For one thing, redundant entry is eliminated; patient demographic data are immediately available in the lab, as an example. The HIS validates test orders, insuring that they are properly executed, and transmits them electronically to the laboratory system, thus reducing paperwork costs as well as expediting processing.

More important, laboratory results can be immediately transmitted to the point of use--nursing unit, emergency room, outpatient clinic, physician's office. Faster data availability for clinical decision making can reduce a patient's length of stay, an important goal under prospective payment.

A variety of messages pass back and forth between interfaced systems. These messages fall into the following general categories:

Admissions, discharges, transfers. This is often the first interface function to be implemented, together with billing. It includes demographic, location, and diagnostic information about the patient; transfer and discharge notifications; and physician identification data.

Transmission is typically one way from the HIS to the LIS, and on-line immediate updating on each patient is more common than delayed batch transmissions of patient information. This is of significant benefit to the laboratory. There's no need to reenter such information into the LIS, and important data can be instantly retrieved.

Billing/charge collection. The scope of this interface is largely determined by the method of charging for laboratory services. If charges are applied at the time of order entry, for example, the HIS will post most charges directly. The interface would then include only laboratory-generated charges--for follow-up testing that is contingent on previous results, say--and credits.

If, however, charges are posted at the time the laboratory receives a specimen, the laboratory information system must generate a charge record for transmission to the HIS. Another alternative is to record charges at the time of result entry. This method reduces the number of credits required. Microbiology would have to be handled as an exception since it takes weeks to obtain final results on some cultures.

Laboratory billing transactions are usually recorded on magnetic tape for manual batch transfer to the HIS or hospital billing system. Direct on-line interfaces are less common.

Result inquiries and reporting. Getting accurate and timely results back to the clinician is a key role of any laboratory information system. An interface to the HIS can assist in the rapid dissemination of laboratory data and in making the data available on demand to authorized staff.

Result inquiries/reporting is second only to order entry as the most complex of the LIS-HIS interfaces. The primary difficulties lie in these areas:

Reconciling results with orders. Order numbers assigned by the hospital information system generally are not consistent with optimum laboratory assignment of accession numbers for the tests to be performed. Hospital information systems often limit the number of tests per order, necessitating a new order entry for additional tests. Typically, the LIS will record the HIS order numbers, assign its own accession numbers, and revert to HIS order numbers when returning results to the hospital system.

Preventing inquiry bottlenecks. The LIS should transmit laboratory results as soon as they are verified, and the HIS data base should retain the results for rapid response to inquiries. Storing results in the HIS instead of the LIS averts inquiry response delays that are due to limits on transmission speed between the two systems. In addition, this approach develops an integrated clinical data base within the HIS.

Compatible formats. Frequently, space allocated by the LIS for data items on a screen or a printout varies considerably from space allowed in the HIS. Hospital information systems tend to underestimate the size of laboratory results and, in particular, the need for free-text comments. The number of displayable lines per screen can also differ.

Incompatibilities can be overcome by splitting lengthy results into separate reports. Field sizes of the LIS and HIS might also be adjusted to achieve a reasonable amount of consistency.

Order entry. Interfacing complexity increases greatly when the order entry process is added. Considerably more is involved than a simple one-way transmission from the HIS to the LIS. No single order entry interface logic decision is, in itself, complex. But the order entry interface requires many such decisions. For example:

Under what conditions should the LIS generate a label? If the nursing unit collects the specimen, should the label come from the HIS? On Stat requests, is it faster for the lab or the hospital system to issue the label?

When patient demographics are not already present in the LIS, should the LIS query the HIS for them?

Should a check be made for existing duplicate orders? If so, what action should be taken when duplicate orders are discovered?

How should standing orders and timed test requests be conveyed --all at once as a group of future orders or fed one by one from the HIS to the LIS as each test falls due? If the former course is taken, how long should the LIS hold future orders? Should they be canceled automatically after a specified period? What about entry of back orders after a computer that has been down returns to operation? For how many days past should orders be accepted from the HIS?

Under what conditions and time limits may different test orders for the same patient be combined in the laboratory? To avoid drawing a patient twice, for example, the laboratory might combine two blood tests if they are requested within an hour of each other.

Besides these kinds of questions, system managers must consider translation of various HIS codes into LIS nomenclature--order codes, diagnostic codes, comment codes, priority codes, and so forth.

Correlation must be maintained between the order number or numbers used by the HIS and the LIS accession numbers. Multiple orders with multiple order numbers might be assigned a single accession number by the LIS; alternatively, single orders from the HIS may result in multiple LIS accession numbers. The approach used depends on the specific ordering characteristics of the HIS and the accession assignment methodology of the LIS.

We have reviewed the categories of interface messages and suggested ways to minimize difficulties. It should be noted that industry adoption of intersystem standards and protocols has resolved most, if not all, of the technical issues that have impeded computer-to-computer communication. What remains is for the HIS and LIS to understand and properly react to the messages passing between them. That is where you, as the user, come in.

You should require the HIS and LIS vendors to develop detailed specifications in concert with system users. The specifications should encompass all the categories of interface messages and set down the details of physical communication (wiring and so on) and logical communication (the types of messages, for example). Part of the specifications should cover contingencies. What happens if the HIS is unavailable? Or if the LIS is unavailable?

The user's responsibility is to indicate preferred choices from an operational standpoint, as a means of resolving the issues we have noted throughout this discussion, and to estimate the volume of messages expected between the systems.

With today's technology, most delays in bringing about an interface are due to lack of initiative by one or both of the vendors involved, rather than any programming or system constraint. Granted, some systems have incompatibilities, but these often can be worked out or worked around if both sides are sufficiently motivated by their common client-- you!
COPYRIGHT 1986 Nelson Publishing
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1986 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:computer use
Author:Winsten, Dennis
Publication:Medical Laboratory Observer
Date:Jan 1, 1986
Previous Article:A viable DRG path for small hospital laboratories.
Next Article:Office testing in group practice.

Related Articles
Microcomputers in the lab: the sudden boom.
Planning for your new laboratory computer; laying the proper foundation for installation of a computer system can avert disaster.
The impact of DRGs after year 2: evaluating the tactics.
A look at packaged microcomputer systems.
The impact of DRGs after year 3: how labs continue to cope.
Available in most labs, fully utilized by few.
How financial executives view their hospital labs.
Getting to the point: Integrating critical care tests in the patient care setting.
Integration at two levels: West Coast healthcare delivery system tackles automating lab facilities and merging separate vendor systems. (Laboratory...
Paean to process: Tennessee hospital lab's dedication to process improvement culminates in patient identification system that streamlines the...

Terms of use | Copyright © 2017 Farlex, Inc. | Feedback | For webmasters