Integrating an LIS into a PIN.

For many years, the patient care providers at our 650-bed medical center had anticipated that computerizing patient data would be the only way to cope with our exponential growth and complex record keeping. Accompanying this growth was a heightened need to integrate and display patient data in ways that would enhance diagnosis and treatment of patients. A computerized clinical database was important as well for meeting the needs of our educators, researchers, and administrators and the requirements of Federal and state regulatory agencies.

In January 1984, a formal planning process was initiated to assess the facility's needs for managing clinical information. The result, more than four years later, was a detailed plan for a clinical information system.

Historically, our laboratory has played a leading role in the computerization of information at our hospital. The first system that the facility used for processing clinical data was a computer installed in the laboratory in 1971. This system was designed to enhance the acquisition, management, and reporting of laboratory data. Eventually other departments acquired computer systems as well.

One problem inherent in our growing family of unrelated systems was that the treatment of patients was registered as a fragmented series of unrelated encounters rather than as a smooth clinical process. Each department would ask a patient for the same information over and over again. A key way to overcome such fragmentation is to install an information system capable of integrating clinical information from all components of the delivery system for a total view of patient data. This integration was our goal as we planned our patient information network (PIN).

* Solutions. In an effort to include as many viewpoints as possible, the hospital established a clinical information advisory committee consisting of about 50 people. Some were wise in the ways of computers, while others were in place to identify needs of their departments. The committee made three key recommendations: first, that the unconnected departmental and clinical information systems be integrated; second, that a smaller group of "worker bees" be formed to set the direction in developing the PIN; and third, that a hospitalwide patient identification and registration system be implemented.

A major commitment from the hospital administration permitted us to create the medical informatics group, headed by a part-time thoracic surgeon and consisting of five others at first and soon afterward of nine. Four years after its inception, the clinical information advisory committee was boiled down to a patient information network advisory committee of 20 people who gave direction to the medical informatics group.

We knew that success would depend on five principles:

1. Nursers, physicians, and ancillary staff would have to collaborate throughout the project.

2. Because active patient care providers would always impart a strong clinical direction to the management of the PIN, it would have to be set up accordingly.

3. To provide effective and flexible linkages, the overriding system would have to be integrated with all subsidiary systems.

4. Each function within the PIN should perform at least as well in extent and quality as it had before the PIN was implemented.

5. All systems would have to be evaluated for effectiveness to insure that the goals and objectives of the "super-system" were being realized.

* Plans begin. The medical informatics group was charged with providing clinical direction for the new system. This staff would--with the advice and assistance of clinical staff who would eventually use the system--design, develop, implement, and maintain the PIN with support from the hospital's department of information management. They and the project manager would report to the patient care operations group, an administrtive body within the institution.

The medical informatics group would coordinate three integral components of the system: clinical direction, provided by physicians and nurses; operational efficiency, with the consultation of administration; and integration of diagnostic and therapeutic data, developed with the assistance of ancillary staff. This organizational structure was consistent with our institution's philosophy that the users of an information system are the most appropriate group to oversee its development, implementation, and management (Figure I).

* Design and development. It was with all this groundwork laid that I started my job as ancillary systems associate in the medical informatics group in May 1988. I was assigned to work with the staffs of the ancillary departments as they were integrated into the PIN. In the process, their needs would have to be meshed with those of the soon-to-be-implemented admissions, discharges, and transfers (ADT)/registration system. This comprehensive system would include both inpatients (under "ADT") and outpatients (under "registration").

The laboratory's capabilities and requirements would have to be represented in the design and implementation of a prototype clinical system. The largest ancillary group I would work with was the laboratory, which had just signed a contract for a new laboratory information system (LIS), to go on line that November. The LIS would interface with ADT/registration, test order entry, and result reporting.

The PIN would be implemented in several phases. Phase I consisted of installing two departmental computer systems (laboratory and ADT/registration) and a network to make them interface with new and existing computer systems. Phase II consisted of a prototype clinical system on a single nursing unit designed to test the feasibility of integrating data from several different hospital computer systems and to test the functionality of the clinical software. The prototype would include result reporting, charting by nursing and ancillary staff, and direct order entry by physicians.

A vital component of the PIN was its integration of the various systems by means of a network. The network we set up would have to be able to distribute data in a way that would translate information from one computer system to another.

The first round of interfaces to use this network would involve the ADT/registration system. We set up interfaces not only with the LIS but also with the computer systems used in our pharmacy and patient care systems. This interface was scheduled to be installed in October 1988. After we had narrowed down our choice of vendors, representatives of several hospital departments made site visits to two facilities to observe various data elements and time/date formats in action.

We could have used point-to-point (direct) connections to write separate interfaces from the ADT system for each other system (clinical system, laboratory, radiology, and pharmacy). Instead, we wrote one comprehensive interface that incorporated all data elements we were likely to need.

Data were sent to an intermediary computer, which acted as a hub, in the hospital computer room. The software manufacturer tailored its program to meet our specifications. In the resulting program, the data distribution function of the interface sorted each element of data to the appropriate system and made any necessary formatting changes. Our second round of interfaces to be implemented using the network would consist of the result reporting and order entry interfaces between our upcoming prototype clinical system and the laboratory system.

One component integral to the PIN was a centerwide patient identification and registration system. Previously, multiple patient numbers could be generated from our inpatient ADT system, our outpatient registration system, or our physicians' practice registration system. In the old lab system, the key was the patient's name. If the name were entered in slightly different forms at different times, multiple files could easily be created for the same patient.

A committee of representatives from the ADT and registration areas directed the implementation of the ADT/registration system. (In hindsight, a representative from one of the ancillaries should have been included.) That committee decided that a unique patient identification number would serve throughout the medical center. The laboratory then defined that number as the unique identifier in our system as well. A medical record number would have to be assigned to every patient, therefore, before he or she could be registered with the lab. Since the registration/ADT system was supposed to be installed in October 1988, one month before installation of the LIS, it was the logical one for us to use.

At that time, most inpatients did have medical record numbers, but these numbers did not always appear on their identification plates, the means used by the lab to register patients in the LIS. Procedures within the centerwide registration system would prevent this discrepancy in the future.

I worked closely with the users as the systems and interfaces were designed. Workflow had to be examined. For the ADT interfaces, the main effort in desig was determining what transactions would flow between our ADT system and the LIS. Other questions to be answered: Did the lab want to receive all pre-admittance transactions or only those related to regular hospital admissions? Should all 1,500 daily outpatient visits be registered in the lab even though only a fraction of them would need lab work?

For the order entry interface, we had to examine all details of that process as they related to the laboratory. We reviewed questions such as these: Should the interface include the patient's height and weight? Should copies be sent to more than one physician? How would our program work within the clinical system overall?

One of our greatest challenges was to design workflow associated with specimen collection. The many people involved included our medical informatics group, laboratory users, phlebotomists, physicians, and nurses. Designing workflow proved to be much harder than might have been expected for the usual technical aspects of designing an interface.

What we came up with consisted of two different categories of specimen collection: "ancillary to collect" and "unit to collect." Routine phlebotomy rounds every two hours would start as the phlebotomist picked up a set of collection lists and collection labels generated by the LIS. The list consolidated all orders that were designated "ancillary to collect" when entered into the clinical system--that is, most specimens. Designated as "unit to collect" were Stat specimens, fluid specimens, and specimens with special conditions, such as "collect 30 minutes after bolus of K+."

These specimen orders did not appear on the phlebotomists' collection list. Instead, a transmittal slip was printed on the unit. Whenever a "unit to collect" specimen was obtained, it would be sent to the lab with the transmittal slip. The slip contained the order number corresponding to what had been sent across the interface. In this way each specimen was matched with its transmitted order in the laboratory system.

* Implementation. Integrating multiple systems usually makes them dependent on each other. At times, we learned, their interdependence can cause problems.

On about Sept. 15, 1988, the laboratory system was on schedule for its November live date, but the ADT/registration system was far from meeting its October 15 one. We had two serious concerns about the laboratory's ability to implement its component of the PIN. First, the laboratory was staffed for an electronic ADT interface, not for manual entry of ADT information. Second, without the ADT/registration system, we would have no guarantee that medical record numbers would be assigned and available for all patients, as the laboratory system required.

To resolve the understaffing issue, the hospital committed itself to hiring temporary personnel who would assume the extra workload created by the missing interface. The delay in the identification system was resolved operationally. We held meetings with representatives from patient reservations, emergency, and medical records departments to obtain their guarantees that medical record numbers would be assigned and new identification plates created to replace any original plates that were missing numbers. This was occasionally the case, since at the time, those numbers had not been considered important enough to be mandated. (They are now.)

Despite the obstacles, the laboratory system was implemented on schedule in November 1988. The network and ADT interfaces were implemented at the same time as the ADT/registration system in January 1989, several months past deadline.

The prototype clinical system and associated interfaces, brought up in August of that year, represented two vastly different experiences. It was to our advantage to have brought up ADT first, since ADT-related problems were troublesome but not potentially life-threatening to patients, as glitches in interfacing with test order entry and result reporting interfaces might have been. We applied lessons learned from the first implementation when we did the second one.

We should have done more testing beforehand that simulated actual use of the ADT system, forcing any operational and technical problems to surface. We tried to do this when we brought up our clinical system, but the clinical setting proved to be even harder in which to create parallels to true situations. Although our clinical simulations were better than the ones we had done with ADT, thus keeping technical problems to a minimum, we spent a lot of time correcting operational problems that we hadn't been able to simulate.

* Troubleshooting. Among the difficulties that cropped up were some we had anticipated and had made efforts to prevent. For example, it wasn't unusual for physicians to order the wrong tests. This seemed to be the case especially in microbiology--perhaps because the results of those tests invite more interpretation than, say, chemistry results. Since we had expected this to happen, we had provided cues in the ordering pathway.

Unfortunately, that wasn't enough. The codes in the lab system had been set up to reflect lab procedures, which didn't always make sense to the physician. Physicians who wanted only to rule out streptococcal infection would order a throat culture, far more comprehensive than the [beta]-strep culture that would have given them the information they needed. Another problem was that blood was unnecessarily drawn several times from some patients because the health care provider who had previously acted as intermediary--the nurse--had been eliminated from the ordering loop.

The following scenario was typical. A physician would order a CBC to be drawn at 0600 and 1400. At 1000 he would order a sed rate. At 1130 a different intern would order a reticulocyte count for the same patient. At 1400 blood would be taken again from the patient for the CBC ordered earlier. The computer was transmitting each order as it was written, complete with draw time; thus, multiple sticks were being done. In a noncomputerized situation, the nurses' participation eliminated the duplication. The nurses grouped tests and prevented redundant phlebotomy. Software changes were installed on the clinical system to identify duplicate orders.

Phase I consisted of implementation of a new laboratory system, a centerwise registration system, and a network to allow integration between those and other systems. Although it took us several months to work out the technical and operational problems associated with the ADT interface, we can say today that it has been running successfully for two and a half years. The data distribution network does its job quietly, passing about 10,000 transactions a day to the various systems. We have been able to add to the network easily, as evidenced by our adding a medical records system to the network. We have plans to interface a new billing system and dialysis management system in the near future.

Phase II consisted of the prototype clinical system that was tested on one nursing unit. Toward the end of the four-month prototype period, various means were set up to evaluate it. Questionnaires were sent to 70 nurses, 160 physicians, and 18 ancillary department staff members who had used the prototype. The response to the result reporting aspect was extremely positive. In addition, routine quality assurance studies captured by the laboratory staff showed a 25% decrease in phone calls from the prototype nursing unit requesting test results.

Our highest hurdle was the physicians' response to entering test orders themselves. They hated it! When we realized how distraught they were, we spent time watching them in action.

We learned that the more complex the order, the less likely it was to be executed properly. For example, routine blood collection during the 0600 draw, with no special conditions attached, went smoothly. When the physician introduced a variable that required a decision, such as "draw after K+ is given," problems arose. We decided to correct that situation in the future.

One serious problem we faced was to keep the systems coordinated when new test codes were added to the LIS. Deciding that our operations were being undermined by "too many cooks," we resolved the problem by developing a form that had to be filled out whenever a test code was added. We also decided to allow only the LIS manager and assistant manager to add new test codes; before, they and about a dozen supervisors had been authorized to do so.

Although the order entry interface had worked well technically, its operation had not been fully successful. Suggestions from users have been invaluable. Decisions about system design and problem resolution can't be made in a vacuum. A system developed exclusively by our information management staff would have had little credibility with users later. Instead, we brought together nurses, physicians, phlebotomists, and people using the computer in the laboratory to assist in problem solving.

Our recommendations at the end of the prototype period were twofold. First, we stated that staggered implementation of functions across the institution is prefereable to bringing up each unit with full functionality. Second, for any further development of a clinical information system, it was important to maintain a management structure similar to that of the medical informatics group. Strong clinical direction and involvement are vital for successful implementation.

* The economy. Just as we were eliminating the bugs in our clinical prototype, the economy caught up with our plans, forcing the medical informatics group to be dissolved as a formal entity. Nevertheless, an informal group continues and the advisory committees meet ad hoc. We have made great strides in integrating the LIS with the other systems and in making other improvements.

Following our recommendation, the medical center purchased the result reporting module we had tested as part of the clinical system prototype. Installed with the assistance and guidance of our advisory committees, the system has been used since October 1990 by clinicians on all 30 nursing units. Daily phone calls to the laboratory for results have been cut by more than half since we started working on that problem.

Presently, the hospital administration's focus is on updating the financial systems of the institution. When the time comes to shift attention back to the clinical system, we will have established a strong foundation to build upon.

Karen K. Ellis is project leader for ancillary systems in the information management department of Albany (N.Y.) Medical Center.