An X Window System for Statlab Results Reporting. Randolph C. ... captures the datafor review in a custom spreadsheet format at ... this manual reporting method was inefficient for ... printer was installed in each of the five ICUs listed above.
An X Window System for Statlab Results Reporting Randolph C. Barrows Jr., MD; Bany Allen, PhD; Daniel J. Fink, MD Center for Medical Infornatics Columbia University New York, NY 10032 We have developed a system that receives "stat" results encoded in Health Level Seven from the Laboratory Infornation System, prints a report in destination Intensive Care Units (ICUs), and captures the data for review in a custom spreadsheet format at color X-terminals located in ICUs. Available services include a reference nomogram plot of arterial blood gas data, printed summaries, automated access to the Clinical Information System and a Medline database, electronic mail, a simulated electronic calculator, and general news and information. Security mechanisms include an audit trail of user activities on the svstem. Noteworthy technical aspects and non-technicalfactors impacting success are discussed.
several ICUs, five of which (the Surgical, the Cardiac Surgical, the Neurological and the Medical ICUs, and the Coronary Care Unit) provide a total of 76 ICU beds on two adjacent floors of the Milstein Hospital building. Stat tests for these five ICUs are processed daily from 8 a.m. to midnight by a small dedicated clinical laboratory ("statlab") located near them. CPMC has an Integrated Academic Information Management System (IAIMS) [2] with network connections in the ICUs that provide access to the Clinical Information System (CIS). Automated reporting of statlab data directly from the CIS was not possible due to batch processing delays in the Laboratory Information System (LIS) and current technical limitations in the CIS. Since results are entered into the LIS as they are finalized in the statlab, the strategic solution was to create a system that receives results from the LIS, utilizes X-terminals as printer servers and provides X Window programs for results display.
INTRODUCTION
Hospital intensive care units (ICUs) require frequent determinations of a subset of laboratory blood tests that are routinely requested on a "stat" (to be processed immediately) basis. The importance of this data for patient care generally necessitates that laboratory technicians communicate results to the requesting ICU as soon as possible. This is tme even if providers have access to a clinical or laboratory information system when delays in data entry or transfer occur. The report of a stat result is typically done by telephone and may be received by any available ICU personnel. Handwritten results are then hopefully delivered to the appropriate caregiver. It was recognized in our institution that this manual reporting method was inefficient for both laboratory personnel and care providers, and was error prone, so an automated solution was sought. At the same time it was recognized that an opportunity existed for experimenting with new computer interface techniques that could obviate the need for manual or paper-based reporting altogether. Such an effort is consistent with long-range institutional goals and the recommendations of the Institute of Medicine [1]. Below we describe our system and discuss technical features and the impact of non-technical aspects.
An X-terminal is a network-connected computing device with processing power and memory dedicated to running an X server program which gives the unit graphical display capabilities for X Window "client" programs remotely executing on "host" computers anywhere on the network. The X Window System is a platform-independent network-transparent software protocol that makes it possible to share Graphical User Interface (GUI) programs and computing resources in a networked environment. A printer connected to an X-terminal has a network defined location that makes it accessible for results reporting over a heterogeneous network like CPMC's.
HARDWARE AND SOFTWARE
X-terminals are the IBM Xstation 130 which have an attached keyboard, mouse, and a 16 inch color display (IBM model 8514). The Xstations are attached to a 16 megabit/sec Token Ring network in the ICUs. An Xstation and parallel-connected printer was installed in each of the five ICUs listed above. Printers are the IBM LaserPrinter (model 4019) with PostScript Option installed. The programs to process, print and display statlab results were written in the C programming language and
BACKGROUND
Columbia-Presbyterian Medical Center (CPMC) has 0195-4210/92/$5.00 © 1994 AMIA, Inc.
331
run on an IBM RS/6000 model 550 with 160 megabytes of main memory under the IBM AIX operating system. X Window programs utilize the Motif widget library (OSF/Motif, Open Software Foundation, Inc., Cambridge, MA) at the presentation layer. The system was designed and coded over a 6 month interval during which two of the authors (RCB, BA) worked approximately full time on the project. The LIS runs on an HP3000/58. A program written in BASIC and running on the HP encodes statlab results for transfer (see below) and sends them via File Transfer Protocol (FTP).
fields. The DSP segments each contain a data line intended for printing without modification. A program executing on the RS/6000 checks the designated directory for the existence of one or more result files every 15 seconds, processes any that are found, and creates an HL7 General Acknowledgement (ACK) message in a separate file for each result sent. The ACK message is retrieved by the LIS's sending program and communicates that either the result was successfully processed or that some error occurred.
Processing of a result file first involves extracting the statlab report and its intended destination from the HL7 encoding and queuing the report for printing in the specified ICU. For example, in Figure 1 the URD segment destination field contains "M4SI" which the program understands to mean the printer queue for the Xstation located in Milstein Hospital 4th floor Surgical Intensive Care Unit. Processing and queuing of each report takes less than one second. The printed report generally appears in the destination ICU within a minute of the time the result becomes available in the LIS, fulfilling the laboratory's obligation of immediate results reporting. The program then parses the statlab report and assigns component tests to one of three possible groupings for display purposes: ABG (arterial blood gases), CHEM (clinical chemistry tests), and CBC (blood cell counts). The report encoded in Figure 1 contains test results from all three groups. Parsed statlab results are stored in a shared memory area on the RS/6000, which is a means of inter-process communication that allows more than one program to use the data stored in one segment of the computer's memory.
RESULTS TRANSFER AND PROCESSING
Statlab data is transferred from the LIS to the RS/6000 as a file containing a single statlab result encoded in Health Level Seven (HL7), a standard for electronic data exchange in the healthcare environment [3]. The sending program creates a unique name for each result file and places it in a designated directory on the RS/6000. Each statlab result is encoded as an HL7 Unsolicited Display Message (UDM) [4], consistent with the laboratory's intent of sending a formatted result for immediate printing in the ICUs. UDM messages consist of a Message Header (MSH) segment, a Results/Update Definition (URD) segment, and multiple Display Data (DSP) segments (Figure 1). Fields within segments are delimited by the backslash ("\"). The MSH segment defines the type, source, destination and time of the message, as well as some syntax specifics. The file name of the result is used as the unique Message Control Id (field 10). The URD segment defines the result that is being sent and includes timestamp, patient id., and destination
MSB\-I-(\LIS\CPLIS\CIS\CUCIS\199301291452\\UIM\SLo1930127000034\P\2.1\\ URD\199301291452\8\1234567 \RES\SL01930127000034\M4SI\T
DSP\\\123-45-67 DOE,JOHN DSP\\\5L000034 01/27/93 11:01
DSP\\\ DSP\\\ DSP\\\ DSP\\\NANE DSP\\\ DSP\\\pH DSP\\\PCO2 DSP\\\PO2
DSP\\\BE(C) DSP\\\HCO3(C) DSP\\\O28AT-C
06/22/31 X M48I STAT LAB TESTS FINAL RESULT
RESULT UNITS 7.47 32 467 1.0 23 100 8.7 26.0 137 5.1
m Hg mm Hg
Ezqj1
nEq/1 %
REF RANGE
7.35-7.45
35.45
NAME
RESULT
UNITS
ION. CA
1.0
GLUCOSE
229
zN/1 ag/dl
72-104 -3.3-+1.2 22-26 94-100
DSP\\\HGB g/dl 14.0-18.0 DSP\\\HCT % 42.0-52.0 DSP\\\NA mEq/1 DSP\\\X mEq/1 DSP\\\ DSP\\\ COMMENT: SPOKE TO DR. OSLER
Figure I
332
REF RANGE
opens another window to display all tests for the patient in reverse chronological order. Results for both ward-oriented and patient-oriented reviews are displayed in a custom spreadsheet format in which color coding assists with visual alignment and in the detection of abnormal values. The displays have other notable GUI features that improve the ergonomics of the interface compared to character based screens. Scrollable subsections of the spreadsheet exist, and each value or label is a "button" which can be selected to reveal details. For example, clicking on a result value with the mouse opens a box which displays the reference range. Comments from the laboratory or messages from providers about a result are indicated on the display and are viewed or created via a mouse click which opens a dialogue box. These features allow organized displays and prevent information overload while keeping a maximum amount of information readily available for users.
THE X WINDOW DISPLAY An X Window program for review of statlab results accesses data in the shared memory area and formats it for display. A separate copy executes for each ICU's X-terminal. The initial screen seen by users has four windows. One small window displays the date and time. Another provides a queue monitor that indicates the functional status of the associated ICU printer queue and allows users, without logging into the system, to address printer and queue problems. The availability of new statlab results is indicated in another window by displaying patient names and the time of new results. Users can detect at a glance whether new results have arrived, but cannot see results without actually logging in to the system. A login window contains the familiar prompt for a user name and password. After a user enters a valid name and password, the "login" and "new results availability" windows are closed, and a window for the main menu is opened. Main menu options include "Statlab Review" described below; "CIS"; "Medline"; "Pine Mail", an electronic mail program available from the University of Washington; "Xcalc", a GUI calculator; "ColumbiaNet", a comprehensive news and information service maintained by Columbia University's Academic Information Systems; "Help"; and "Logoff'.
A nomogram plot for ABG data, adapted from the acid-base map of Arbus [5] is available (Figure 3). Clicking on 'Nomogram' opens a window displaying a graph of pCO2 vs. bicarbonate with normal values and the 95% confidence bands for the six simple acid-base disturbances. ABG data plotted on this graph allows rapid categorization and easy trend detection. Custom printed summary reports of statlab data are also available via mouse click. PostScript ability yields shaded bars, lines, and reverse coloring of abnormal results that promotes easy reading of data in a tabular format. Printed summaries are available for the ICU ward or individual patients and have a layout analogous to the screen designs.
When "Statlab Review" is selected from the main menu, a window opens displaying the most recent results for all patients in the ICU of the Xterminal's location (Figure 2). Patients in other ICU's are available via selection from the "Ward" pulldown menu in the top menu bar. ABG results are displayed initially by default, and results of other types are accessible quickly via a mouse button click on options listed in a second menu bar. From the Ward Review window a patient can be selected for a more focused review of statlab results which
SECURITY FEATURES A first level of security exists in the placement of the X-terminals and printers in the work area of each ICU, which makes the system relatively secure by location. Generally only valid hospital personnel, mostly ICU care providers, have unquestioned access to these locations. A second level of security exists with the login process, which restricts access to users with a valid name and password. User accounts are provided only for physicians and nurses who are ICU care providers. Users logging in for the first time have the option of giving their mainframe account number and password to the system, which will then provide automatic access to the CIS and Medline without a separate login to these systems by the user.
Figure 2
333
programs over a network. The only IAIMS resources not available from this system in our environment are those that run on Novell networks. The use of shared memory in a unix environment, rather than a database management system, is another novel aspect of this project. Normally, computer memory that is used by one executing program is not accessible to any other program, so data cannot be directly shared by programs. A library of procedure calls provided by the operating system makes it possible for a program to create a sharable memory segment and for other programs to use it. The advantages of using a shared memory segment are that it is fast, it requires no separate database management system, a convenient data structure can be shared by multiple programs, and data stored by one program is immediately available for display or update by other concurrently executing programs.
Figure 3 A next level of security is provided by automatic system timeout which covers the screen with a "security blanket". The security blanket is actually a colored functionless window that fills the entire screen and blocks access to other windows and services. This is invoked by the system when activities (keystrokes, mouse motions) are idle for more than five minutes or when a user exits the system. When the security blanket is up, the only windows a user has access to are the initial screen windows, described above, which the system places on top. If a user walks away, causing the system to time out, the same user may recover their session (exactly as they left it) by logging back in. If, instead, another user logs in, then the previous session (windows and programs started by that user) is ended, and the new user begins a session from the Main Menu.
Security issues arise because of the need to protect the health data of patients from unauthorized viewers while allowing authorized care providers relatively easy access. Caregivers including attending physicians at our institution are avid users of the CIS indicating comfort with the login process. Since it is usually not practical to prohibit access to medical data for most providers, the audit trail becomes a critical tool for managing data security issues [6]. This system succeeds in producing an audit trail via the log file of user activities discussed above. While time out mechanisms are commonly in place in software systems, most cause users to lose their session entirely. Resuming work after an interruption means redundant effort and wasted moments retracing steps within the program. This system succeeds in saving the state of a user's work session for recovery via the normal login process, unless the session is destroyed due to an intervening user.
A final security mechanism is a log file that provides an audit trail of user activities. This file records who logs in, what programs are used, and the specific patients whose data are reviewed in each
The most immediate goal of this project, to provide automated statlab reporting to the ICUs, was technically achieved. The system was designed to replace a time-consuming and labor-intensive manual reporting system in which all interested care givers may not receive timely notification of expected results, and errors in transcription or misplacement of handwritten results can occur. These deficiencies generate multiple telephone inquiries to the statlab for test results, which must be answered by limited personnel, causing processing delays on stat tests. Automated reporting of results provides potential savings in time and effort and may reduce errors concomitant with verbal reporting and written
ICU. DISCUSSION
Technical aspects of this project are noteworthy. We have integrated a number of standards into a working system, including networking/ communications standards, HL7, and the X Window software standard. Development under X Window provides the unique advantage of a hardware independent platforn for users. Any computer, including a DOS personal computer, that is capable of higher resolution graphics and of running an X server program has the ability to run X Window
334
References
transcription of values. In addition, the system provides enhanced data review capabilities that allow easy trend detection. The cost of this extra information to the user is the login process. Initial feedback from some physicians suggests that printed stat reports might be unnecessary as long as immediate results availability and enhanced data Provider review capabilities are provided. acceptance of the graphical user interface may facilitate transition to a paperless system for results reporting.
1. Institute of Medicine, Committee on Improving the Patient Record; The Computer-Based Patient Record: An Essential Technology for Healthcare; Washington, DC; National Academy Press; 1991. 2. lhendrickson G, Anderson RK, Clayton PD, et.al.; The integrated academic information management system at Columbia-Presbyterian Medical Center; MD Comput Jan-Feb 1992; 9(1):35-42.
The system has been operational for about 6 months as of this writing, but has met with limited success. ICU nurses have not found the automatically printed statlab results to be a critically useful technology for adoption. One reason is that statlab personnel continued to call results to the ICUs while the system was in trial phases. The phone reporting system with which nurses are comfortable and familiar makes printed reports redundant, so they are left at the printer. No person, such as the ward secretary, is assigned the job of distributing reports to appropriate caregivers. Unclear responsibility for keeping the printer stocked with paper causes reports to back up on the print queue when supplies are When paper is finally replenished, depleted. outdated and unneeded reports are printed in rapid succession. These factors combine to produce paper congestion and a disorganized pile of reports at the printer. Nurses prefer to call for needed results rather than search through the pile, perpetuating the manual system.
3. Simborg, D; An emerging standard for health communications: The HL7 Standard; Healthcare Computing and Communications, October, 1987. 4. I-Health Level Scven: An application protocol for clectronic data exchange in healthcare environments, Version 2.1, Manual section 5.2.3; available from llealth Level Seven, PO Box 66111, Chicago, IL 60666-9998.
5. Arbus GS; An in vivo acid-base nomogram for clinical use; CMA Joumal, August 18, 1973; 109:291-293. 6. Shea S, Sengupta S, Crosswell A, Clayton PD; Network information security in a phase III integrated academic information management system (IAIMS); Proceeding of the 16th annual SCAMC, pp 283-286,Baltimore, MD, November 8-11, 1992; McGraw-Iiill, Inc., Health Professions Division, New York, NY.
Another problem is that stat test results done when the statlab is closed are not available from this system. From midnight to 8 a.m. a subset of stat tests are performed on an analyzer which is located in one of the ICUs. Data are not entered into the LIS, so results during this time interval are not automatically printed and captured for review in our system.
Appendix A free software library written in the C Programming Language is available to assist with the encoding and decoding of HL7 messages within programs. It is available via anonymous ftp from cucis.cis.columbia.edu (128.59.160.100):
In summary, this project demonstrates some
user ID: anonymous password: guest ftp> cd pub/hl7/hl7imex ftp> binary 1tp> get hl7imex.tar.Z
technical successes in the development of a "next generation" physician workstation in our IAIMS environment, but incompleteness of data capture and non-technical issues have so far retarded its clinical acceptance. These problems are being addressed, and current plans call for an implementation in the emergency room, where "stat" results retrieval is especially problematic.
Uncompress and extract (tar) this file, then type "make install".
Acknowledgements Dr. Barrows is supported by a Medical Informatics training grant from the National Library of Medicine.
335
