Laboratory Suggestions Distributed Laboratory
Computing
Integration of a Laboratory Computer into a Hospital Information System DELANE A. WYCOFF, M.D., AND JAMES R. WAGNER, M.S.
AS THE largest university-owned teaching hospital in the country, the 1,090-bed University of Iowa Hospitals and Clinics complex places heavy demands on its clinical laboratories. In 1976-1977 more than 2,500,000 laboratory results were reported to the 800 physicians serving 900 inpatients and 1,200 outpatients each day. The challenges of dealing with this volume of laboratory work were successfully met by a system that employs a unique design integrating a vendor-supplied laboratory computer as part of the larger hospital information system. The success of this system is a result of planning that began in 1972. At that time, cumbersome manual reporting mechanisms and heavy clinical demands challenged the laboratories to provide adequate service. These problems were compounded by projections of significant growth in patient services during the years ahead. This situation prompted the pathologists responsible for the clinical laboratory to initiate planning meetings Received March 1, 1978; accepted for publication March 27, 1978. Address reprint requests to Dr. Wycoff: Department of Pathology, University of Iowa College of Medicine, Iowa City, Iowa 52242.
Department of Pathology, University of Iowa College of Medicine, and the Systems Development Department, University of Iowa Hospitals and Clinics, Iowa City, Iowa
with hospital systems analysts. Discussion of possible automated laboratory reporting methods 3,1 revealed a potential for significant benefit. The individuals involved agreed to form a committee to define system goals and conduct preliminary planning. Preliminary
Planning
The earliest planning produced an overall goal; it was agreed to provide laboratory test requisition and reporting capabilities on a hospital-wide network of data terminals. This goal was compatible with established plans for the hospital information system to support patient care applications in an online fasion. Our planning group decided that the most promising design would be provided by a commercial laboratory system interfaced with our central hospital computer. This approach would allow earlier implementation and minimize internal development effort by incorporating a proven laboratory system. Furthermore, total system efficiency would be maximized by distributing the processing load between two computers. This dual-processor design was consistent with existing trends toward distributed processing. 1 - 5 ' 610 " 12 It was recognized, however, that the success of the design would depend upon selection of a laboratory computer vendor capable of implementing an interface that could be easily supported by the central system. Design
Finalization
Having selected the dual-system approach to laboratory information management, the next step was to identify functional specifications for all components.
0002-9173/78/0900/0390 $01.05 © American Society of Clinical Pathologists
390
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
Wycoff, Delane A., and Wagner, James R.: Distributed laboratory computing. Integration of a laboratory computer into a hospital information system. Am J Clin Pathol 70: 390-399, 1978. The University of Iowa Hospitals and Clinics, a large teaching hospital and tertiary care referral center, has implemented a vendor-supplied laboratory computer package operating on a dedicated minicomputer. A high-speed communications link allows the laboratory computer to share patient administrative, census, and test result data with the central hospital information system on an interactive basis. Operational characteristics of the system are discussed, and special attention is given to the critical problems and advantages of interfacing two computers. (Key words: Hospital information system; Laboratory computing.)
Vol. 70 • No. 3
LABORATORY SUGGESTIONS
391
dor by function was used. Each vendor was also given a sample medical record with extensive laboratory data and asked to generate its computerized cumulative summary report. Copies of these summaries were distributed for critique by hospital clinicians. Even though a prospective vendor had been tentatively selected to provide the laboratory system, no contract was signed at this point. Instead, attention was directed to the communications interface, and a series of design meetings between the vendor and hospital representatives was set up. The product of these meetings was a detailed set of specifications for the communications hardware and the message formats of all information to flow across the interface. Only when these specifications for the critical interface functions were satisfactory to both parties was a contract signed.
Despite the dependence generated between the two systems as a result of extensive information sharing, the design stipulated that each computer retain some autonomy. Specifically, the systems would be operationally independent. If one should fail, the other should continue to run normally and queue up all communications for later transmission. A request for quotation was distributed to five vendors deemed eligible to respond. Their eligibility was based upon their successful installation of clinical laboratory systems in other hospitals of sizes comparable to our own. Since it was our intention to minimize customtailored modifications to an available laboratory system package, we purposely avoided listing specifications that were fundamentally inherent in the systems under consideration. Instead, we focused on a number of key questions designed to determine how various functions were performed in each of the laboratory systems and how the vendor might meet requirements for the critical interface to the central system. Evaluation of the vendor responses to the request for quotation was conducted jointly by the Pathology Department and the Systems Development Department.* Analysis of each vendor's approach to laboratory data management activities was performed by the Pathology staff, while the overall system design, including plans for the interface, was addressed by Systems Development. A detailed matrix rating each ven-
Contract finalization signaled the commencement of parallel program development by the vendor and University Hospitals. Since the central system software was designed to achieve maximum flexibility through user-controlled tables, the first programs coded were the on-line transactions to maintain a master laboratory procedure table. This development sequence allowed laboratory personnel to proceed with the nontrivial task of inputting critical information such as test name, units, price, and specimen collection information for each procedure, while other programs necessary for later implementation were being written. All central system software required to support the initial implementation can be functionally organized into the following categories: 1. Automatic transmission of all inpatient and outpatient census data to the laboratory system. 2. Receipt of test requests and results from the laboratory system with corresponding error detection and file update routines. 3. Cathode-ray-tube (CRT) retrieval of patient-specific laboratory data and automatic printout of test results in high-volume outclinics. 4. On-line transactions to maintain master laboratory procedure table, interface queues, and file purge, including data archival via computer-output microfiche. Since programs required for the first two categories relied heavily on intersystem communications, they presented a unique challenge from the standpoint of program debugging. Preliminary testing of these routines was conducted via long-distance telephone lines with the vendor to assure elimination of program errors prior to actual system installation and implementation. The difficult period of training and implementation of the system took place in only four weeks. Labora-
* The results of this analysis led to the recommendation that Laboratory Computing, Inc. (LCI), Madison, Wisconsin, be selected to provide the system. In the opinion of the selection committee, the overriding assets of the LCI system were that it provided the most comprehensive capabilities, coupled with the greatest user flexibility. Other major considerations included system reliability, maintainability, and expansion capabilities.
Software
Development
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
The underlying philosophy governing the assignment of operational responsibilities for each system was to allow each processor to perform the tasks for which it was best suited. Consequently, the general design stipulated that the laboratory computer would focus on efficient data mangement within the clinical laboratory, while the central hospital computer would concentrate on the timely distribution of information throughout the institution. Patient census and registration information routinely recorded on the hospital information system would be automatically transmitted to the laboratory computer. A similar communication of test requests and corresponding results from the laboratory processor to the central computer would provide immediate access to specific patient laboratory information via a terminal network extending throughout the hospital. This reporting capability would also be complemented by immediate result printouts at highlaboratory-volume patient care areas.
392
WYCOFF AND WAGNER
A.J.C.P. • September 1978
Table 1. Laboratory System Configuration* Central processing unit
Digital Equipment Corporation PDP-11/45
Memory
64K core; 2K bipolar
Disk storage Fixed head Movable head (single platter)
3 RS04 drives (1 megabyte each) 2 RK05 drives (2.4 megabytes each)
Industry standard tape
DECTM11 800 bpi, 45 ips
Line printer
DEC LP05 (Data Products) 300 1pm
Mark sense card reader
DEC CM 11 (Documation) 285 cpm
Dedicated label printers
2 Centronics 503 1 DECwriter II
Interactive printer terminals
7 DECwriter II (300 Baud)
Interactive CRT terminals
10 DEC VT52; 5 BeeHive BI00 (2400 Baud)
Communications interface
DEC DQ-11 synchronous DMA interface
On-line instruments
SMA 6/60 analog interface SMA 12/60 analog interface Hemalog ASCII 110 Baud 20 ma. digital interface Hemalog ASCII 110 Baud 20 ma. digital interface Wang 360-C ASCII 110 Baud 20 ma. digital interface
165 cps (bidirectional) 30 cps
tory personnel required the most extensive training and were assisted during this period by daily lectures and tutoring provided by the vendor's educational staff. Nursing station-unit secretaries were trained in placing the computer printouts into the patient medical record, and physicians were made familiar with the new reporting mechanisms. This training period included a week of parallel operation using the old requisition and reporting methods and also the new computer functions. With the abandonment of manual reporting on the fourth week, Clinical Chemistry, Hematology, and Urinalysis were fully implemented for all work, including quality control.
The laboratory system is based on a Digital Equipment Corporation PDP-11/45 processor with 64K core and 2K bipolar memory. The detailed system configuration is shown in Table 1 and Figure 1. The laboratory computer emulates two CRT terminals attached to a central system remote control unit. Each pseudoterminal functions as a strict oneway device, with one handling messages from the laboratory system and the other handling messages to the laboratory system. The PDP-11/45 accomplishes this emulation via a DQ-11 synchronous interface and custom software supplied by the laboratory system vendor.
Hardware Description
lntersystem Communications
The University of Iowa's central hospital computer is an International Business Machines (IBM) System/370 Model 158. This large-scale processor is used exclusively for health care and hospital financial management applications. Its three megabytes of main memory are complemented by several highdensity disk drives, which provide instant access to more than 2.7 billion characters of information. The teleprocessing network, consisting of more than 112 terminals, is managed by the IBM Customer Information Control System/Virtual Storage (CICS/ VS). This software package handles all the programming details associated with the management of communication lines, terminals, and the resources of the computer.
The communications interface between the central hospital computer and the laboratory system is the most distinctive aspect of our installation. For purposes of software development, the data transmission routines are being implemented in two phases. The first phase, which has been operational since April 1976, supports unidirectional transmission of both administrative and laboratory-related data. Specifically, the information sent from the central system to the laboratory system includes all inpatient and outpatient census data. The information sent from the laboratory system to the central system includes all test requests, deletions, acknowledgments of specimen receipt in the laboratory, specimen accession numbers, and laboratory results or
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
* This table itemizes major components of the system hardware devoted to data management in the clinical laboratories.
LABORATORY SYSTEM
CENTRAL HOSPITAL SYSTEM
FIG. 1. University of Iowa Hospitals and Clinics laboratory information system. This overview illustrates in parallel fashion the appropriate association between physical hardware and system functions.
Scheduled for Implementation in 1978:
ON-LINE LABORATORY INSTRUMENTS
HARDWARE CONFIGURATION:
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
VI
m H O Z
o o
d
VI
93
r > o
WYCOFF AND WAGNER
394
PACE 01 OF 03
RLAB 77-12343 02/17/49
77-12345 DOE.JOHN A PROCEDURES PENDING
A.J.C.P. • September 1978
STATUS
BLOOD GASSES PH. P-C02. P-02 AR DRUG ASSAY PC GLUCOSE OR INDIRECT COOMBS OR BLOOD TYPE/ ABO & RH OR
H
PVT
COLLECTION
CSURC A
SMITH, 8
OtOOR 12/07/77 12/08/77 12/08/77 12/08/77
SMITH.B TEAM 11 TEAM II TEAM 11
During normal operation of the laboratory system, patient files are kept current on a minute-by-minute basis, since all admissions, discharges, and transfers are automatically transmitted from the central system to the laboratory system. This eliminates the need for routine keyboard entry of census data on the laboratory system and permits completed test results to be rerouted automatically to the correct nursing station when patient transfers occur. The mechanism for outpatients is somewhat different. During evening hours administrative data are transmitted to the laboratory system for patients scheduled to be seen on the coming day. Data for
FIG. 2. Photograph of a nursing station CRT display (negative image). The laboratory retrieval transaction displays pending procedures first. R = receipt times: AR = awaiting results; PC = partially complete; OR = on order— to be collected by phlebotomy.
nonscheduled outpatients are sent individually throughout the day at the time each patient is registered. This means that the process of manually entering administrative data on the laboratory computer is eliminated for most patients, since this information is already in the system. The result is efficient processing of specimens and requests as they reach the laboratory. Emergency test specimens sometimes arrive in the laboratory before the registration information has been transmitted from the central system. The necessary administrative data for these patients can be entered by keyboard on the laboratory system. When the same information subsequently arrives from the central system, it simply updates (or corrects) the data entered manually. The bulk of our laboratory work is submitted as specimens with attached requisitions. As requests arrive in the receiving/processing area, they are keyboard-entered, and specimen accession numbers are assigned by the computer. This process generates appropriate specimen processing labels and initiates transmission to the central system of the test request information. This shared information enables the central system to display the status of pending laboratory procedures. Later, as results are entered on the laboratory system they are also transmitted to the central system. Selected results are printed immediately at appropriate clinic destinations as laboratory result bulletins. At this time the results are also immediately
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
System Operation
bOI
CLIN/PHYS
0400R 12/07/77
modifications. With this information it is possible to display the exact status of all tests for any patient on central system CRTs. Additional interface communications specified in the vendor contract are currently being developed. These include transmission of test requests and results from the central hospital computer to the laboratory system. This capability should permit limited backup for the laboratory system and permit small remote laboratories to be served entirely via central system terminals. It should also enable results entered via central system terminals to be included in the cumulative reports generated by the laboratory system.
fe-S
Vol. 70 • No. 3
LABORATORY SUGGESTIONS / /
/
RLAB
12/Ok
PAGE 03 OF 0 3 02/17/4*
M
PVT
0713 R
GSURG A
b-S
bOI
TW1MSPLANT CLINIC
HEMALOG BLOOD CELL PROFILE
/
Fio. 3. Subsequent screens of the laboratory retrieval transaction show complete work. These results are sequenced, with the most recently completed tests appearing first. Two special-function keys permit the operator instantaneously to move forward or backward through multiple page displays.
\
77-12J45
7 7 - 1 2 3 * 5 DOE.JOHN A
/
395
PLATELET COUNT
345
K/MH3
/
U8C COUMT
lb.5
K/MM3
/
RBC COUNT
4.24
M/MM3
HEMOGLOBIN
13.0
G/DL
HEMATOCRIT
38.4
MCV (MEAN RBC VOLUME)
12sefc
y.
11
CU.MICRONS
MCH (MEAN RBC MB)
30.b
PICO-GRAMS
MCHC (MEAN RBC HB CONC)
33.0
G/DL
071S R
THMSPliWfT C L I N I C
SMA-b'bO PROFILE 1
SODIUM
130
MEO/L
\
POTASSIUM
5.2
MEO'L
\ \
Computing
Integration of a Laboratory Computer into a Hospital Information System DELANE A. WYCOFF, M.D., AND JAMES R. WAGNER, M.S.
AS THE largest university-owned teaching hospital in the country, the 1,090-bed University of Iowa Hospitals and Clinics complex places heavy demands on its clinical laboratories. In 1976-1977 more than 2,500,000 laboratory results were reported to the 800 physicians serving 900 inpatients and 1,200 outpatients each day. The challenges of dealing with this volume of laboratory work were successfully met by a system that employs a unique design integrating a vendor-supplied laboratory computer as part of the larger hospital information system. The success of this system is a result of planning that began in 1972. At that time, cumbersome manual reporting mechanisms and heavy clinical demands challenged the laboratories to provide adequate service. These problems were compounded by projections of significant growth in patient services during the years ahead. This situation prompted the pathologists responsible for the clinical laboratory to initiate planning meetings Received March 1, 1978; accepted for publication March 27, 1978. Address reprint requests to Dr. Wycoff: Department of Pathology, University of Iowa College of Medicine, Iowa City, Iowa 52242.
Department of Pathology, University of Iowa College of Medicine, and the Systems Development Department, University of Iowa Hospitals and Clinics, Iowa City, Iowa
with hospital systems analysts. Discussion of possible automated laboratory reporting methods 3,1 revealed a potential for significant benefit. The individuals involved agreed to form a committee to define system goals and conduct preliminary planning. Preliminary
Planning
The earliest planning produced an overall goal; it was agreed to provide laboratory test requisition and reporting capabilities on a hospital-wide network of data terminals. This goal was compatible with established plans for the hospital information system to support patient care applications in an online fasion. Our planning group decided that the most promising design would be provided by a commercial laboratory system interfaced with our central hospital computer. This approach would allow earlier implementation and minimize internal development effort by incorporating a proven laboratory system. Furthermore, total system efficiency would be maximized by distributing the processing load between two computers. This dual-processor design was consistent with existing trends toward distributed processing. 1 - 5 ' 610 " 12 It was recognized, however, that the success of the design would depend upon selection of a laboratory computer vendor capable of implementing an interface that could be easily supported by the central system. Design
Finalization
Having selected the dual-system approach to laboratory information management, the next step was to identify functional specifications for all components.
0002-9173/78/0900/0390 $01.05 © American Society of Clinical Pathologists
390
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
Wycoff, Delane A., and Wagner, James R.: Distributed laboratory computing. Integration of a laboratory computer into a hospital information system. Am J Clin Pathol 70: 390-399, 1978. The University of Iowa Hospitals and Clinics, a large teaching hospital and tertiary care referral center, has implemented a vendor-supplied laboratory computer package operating on a dedicated minicomputer. A high-speed communications link allows the laboratory computer to share patient administrative, census, and test result data with the central hospital information system on an interactive basis. Operational characteristics of the system are discussed, and special attention is given to the critical problems and advantages of interfacing two computers. (Key words: Hospital information system; Laboratory computing.)
Vol. 70 • No. 3
LABORATORY SUGGESTIONS
391
dor by function was used. Each vendor was also given a sample medical record with extensive laboratory data and asked to generate its computerized cumulative summary report. Copies of these summaries were distributed for critique by hospital clinicians. Even though a prospective vendor had been tentatively selected to provide the laboratory system, no contract was signed at this point. Instead, attention was directed to the communications interface, and a series of design meetings between the vendor and hospital representatives was set up. The product of these meetings was a detailed set of specifications for the communications hardware and the message formats of all information to flow across the interface. Only when these specifications for the critical interface functions were satisfactory to both parties was a contract signed.
Despite the dependence generated between the two systems as a result of extensive information sharing, the design stipulated that each computer retain some autonomy. Specifically, the systems would be operationally independent. If one should fail, the other should continue to run normally and queue up all communications for later transmission. A request for quotation was distributed to five vendors deemed eligible to respond. Their eligibility was based upon their successful installation of clinical laboratory systems in other hospitals of sizes comparable to our own. Since it was our intention to minimize customtailored modifications to an available laboratory system package, we purposely avoided listing specifications that were fundamentally inherent in the systems under consideration. Instead, we focused on a number of key questions designed to determine how various functions were performed in each of the laboratory systems and how the vendor might meet requirements for the critical interface to the central system. Evaluation of the vendor responses to the request for quotation was conducted jointly by the Pathology Department and the Systems Development Department.* Analysis of each vendor's approach to laboratory data management activities was performed by the Pathology staff, while the overall system design, including plans for the interface, was addressed by Systems Development. A detailed matrix rating each ven-
Contract finalization signaled the commencement of parallel program development by the vendor and University Hospitals. Since the central system software was designed to achieve maximum flexibility through user-controlled tables, the first programs coded were the on-line transactions to maintain a master laboratory procedure table. This development sequence allowed laboratory personnel to proceed with the nontrivial task of inputting critical information such as test name, units, price, and specimen collection information for each procedure, while other programs necessary for later implementation were being written. All central system software required to support the initial implementation can be functionally organized into the following categories: 1. Automatic transmission of all inpatient and outpatient census data to the laboratory system. 2. Receipt of test requests and results from the laboratory system with corresponding error detection and file update routines. 3. Cathode-ray-tube (CRT) retrieval of patient-specific laboratory data and automatic printout of test results in high-volume outclinics. 4. On-line transactions to maintain master laboratory procedure table, interface queues, and file purge, including data archival via computer-output microfiche. Since programs required for the first two categories relied heavily on intersystem communications, they presented a unique challenge from the standpoint of program debugging. Preliminary testing of these routines was conducted via long-distance telephone lines with the vendor to assure elimination of program errors prior to actual system installation and implementation. The difficult period of training and implementation of the system took place in only four weeks. Labora-
* The results of this analysis led to the recommendation that Laboratory Computing, Inc. (LCI), Madison, Wisconsin, be selected to provide the system. In the opinion of the selection committee, the overriding assets of the LCI system were that it provided the most comprehensive capabilities, coupled with the greatest user flexibility. Other major considerations included system reliability, maintainability, and expansion capabilities.
Software
Development
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
The underlying philosophy governing the assignment of operational responsibilities for each system was to allow each processor to perform the tasks for which it was best suited. Consequently, the general design stipulated that the laboratory computer would focus on efficient data mangement within the clinical laboratory, while the central hospital computer would concentrate on the timely distribution of information throughout the institution. Patient census and registration information routinely recorded on the hospital information system would be automatically transmitted to the laboratory computer. A similar communication of test requests and corresponding results from the laboratory processor to the central computer would provide immediate access to specific patient laboratory information via a terminal network extending throughout the hospital. This reporting capability would also be complemented by immediate result printouts at highlaboratory-volume patient care areas.
392
WYCOFF AND WAGNER
A.J.C.P. • September 1978
Table 1. Laboratory System Configuration* Central processing unit
Digital Equipment Corporation PDP-11/45
Memory
64K core; 2K bipolar
Disk storage Fixed head Movable head (single platter)
3 RS04 drives (1 megabyte each) 2 RK05 drives (2.4 megabytes each)
Industry standard tape
DECTM11 800 bpi, 45 ips
Line printer
DEC LP05 (Data Products) 300 1pm
Mark sense card reader
DEC CM 11 (Documation) 285 cpm
Dedicated label printers
2 Centronics 503 1 DECwriter II
Interactive printer terminals
7 DECwriter II (300 Baud)
Interactive CRT terminals
10 DEC VT52; 5 BeeHive BI00 (2400 Baud)
Communications interface
DEC DQ-11 synchronous DMA interface
On-line instruments
SMA 6/60 analog interface SMA 12/60 analog interface Hemalog ASCII 110 Baud 20 ma. digital interface Hemalog ASCII 110 Baud 20 ma. digital interface Wang 360-C ASCII 110 Baud 20 ma. digital interface
165 cps (bidirectional) 30 cps
tory personnel required the most extensive training and were assisted during this period by daily lectures and tutoring provided by the vendor's educational staff. Nursing station-unit secretaries were trained in placing the computer printouts into the patient medical record, and physicians were made familiar with the new reporting mechanisms. This training period included a week of parallel operation using the old requisition and reporting methods and also the new computer functions. With the abandonment of manual reporting on the fourth week, Clinical Chemistry, Hematology, and Urinalysis were fully implemented for all work, including quality control.
The laboratory system is based on a Digital Equipment Corporation PDP-11/45 processor with 64K core and 2K bipolar memory. The detailed system configuration is shown in Table 1 and Figure 1. The laboratory computer emulates two CRT terminals attached to a central system remote control unit. Each pseudoterminal functions as a strict oneway device, with one handling messages from the laboratory system and the other handling messages to the laboratory system. The PDP-11/45 accomplishes this emulation via a DQ-11 synchronous interface and custom software supplied by the laboratory system vendor.
Hardware Description
lntersystem Communications
The University of Iowa's central hospital computer is an International Business Machines (IBM) System/370 Model 158. This large-scale processor is used exclusively for health care and hospital financial management applications. Its three megabytes of main memory are complemented by several highdensity disk drives, which provide instant access to more than 2.7 billion characters of information. The teleprocessing network, consisting of more than 112 terminals, is managed by the IBM Customer Information Control System/Virtual Storage (CICS/ VS). This software package handles all the programming details associated with the management of communication lines, terminals, and the resources of the computer.
The communications interface between the central hospital computer and the laboratory system is the most distinctive aspect of our installation. For purposes of software development, the data transmission routines are being implemented in two phases. The first phase, which has been operational since April 1976, supports unidirectional transmission of both administrative and laboratory-related data. Specifically, the information sent from the central system to the laboratory system includes all inpatient and outpatient census data. The information sent from the laboratory system to the central system includes all test requests, deletions, acknowledgments of specimen receipt in the laboratory, specimen accession numbers, and laboratory results or
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
* This table itemizes major components of the system hardware devoted to data management in the clinical laboratories.
LABORATORY SYSTEM
CENTRAL HOSPITAL SYSTEM
FIG. 1. University of Iowa Hospitals and Clinics laboratory information system. This overview illustrates in parallel fashion the appropriate association between physical hardware and system functions.
Scheduled for Implementation in 1978:
ON-LINE LABORATORY INSTRUMENTS
HARDWARE CONFIGURATION:
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
VI
m H O Z
o o
d
VI
93
r > o
WYCOFF AND WAGNER
394
PACE 01 OF 03
RLAB 77-12343 02/17/49
77-12345 DOE.JOHN A PROCEDURES PENDING
A.J.C.P. • September 1978
STATUS
BLOOD GASSES PH. P-C02. P-02 AR DRUG ASSAY PC GLUCOSE OR INDIRECT COOMBS OR BLOOD TYPE/ ABO & RH OR
H
PVT
COLLECTION
CSURC A
SMITH, 8
OtOOR 12/07/77 12/08/77 12/08/77 12/08/77
SMITH.B TEAM 11 TEAM II TEAM 11
During normal operation of the laboratory system, patient files are kept current on a minute-by-minute basis, since all admissions, discharges, and transfers are automatically transmitted from the central system to the laboratory system. This eliminates the need for routine keyboard entry of census data on the laboratory system and permits completed test results to be rerouted automatically to the correct nursing station when patient transfers occur. The mechanism for outpatients is somewhat different. During evening hours administrative data are transmitted to the laboratory system for patients scheduled to be seen on the coming day. Data for
FIG. 2. Photograph of a nursing station CRT display (negative image). The laboratory retrieval transaction displays pending procedures first. R = receipt times: AR = awaiting results; PC = partially complete; OR = on order— to be collected by phlebotomy.
nonscheduled outpatients are sent individually throughout the day at the time each patient is registered. This means that the process of manually entering administrative data on the laboratory computer is eliminated for most patients, since this information is already in the system. The result is efficient processing of specimens and requests as they reach the laboratory. Emergency test specimens sometimes arrive in the laboratory before the registration information has been transmitted from the central system. The necessary administrative data for these patients can be entered by keyboard on the laboratory system. When the same information subsequently arrives from the central system, it simply updates (or corrects) the data entered manually. The bulk of our laboratory work is submitted as specimens with attached requisitions. As requests arrive in the receiving/processing area, they are keyboard-entered, and specimen accession numbers are assigned by the computer. This process generates appropriate specimen processing labels and initiates transmission to the central system of the test request information. This shared information enables the central system to display the status of pending laboratory procedures. Later, as results are entered on the laboratory system they are also transmitted to the central system. Selected results are printed immediately at appropriate clinic destinations as laboratory result bulletins. At this time the results are also immediately
Downloaded from http://ajcp.oxfordjournals.org/ by guest on June 5, 2016
System Operation
bOI
CLIN/PHYS
0400R 12/07/77
modifications. With this information it is possible to display the exact status of all tests for any patient on central system CRTs. Additional interface communications specified in the vendor contract are currently being developed. These include transmission of test requests and results from the central hospital computer to the laboratory system. This capability should permit limited backup for the laboratory system and permit small remote laboratories to be served entirely via central system terminals. It should also enable results entered via central system terminals to be included in the cumulative reports generated by the laboratory system.
fe-S
Vol. 70 • No. 3
LABORATORY SUGGESTIONS / /
/
RLAB
12/Ok
PAGE 03 OF 0 3 02/17/4*
M
PVT
0713 R
GSURG A
b-S
bOI
TW1MSPLANT CLINIC
HEMALOG BLOOD CELL PROFILE
/
Fio. 3. Subsequent screens of the laboratory retrieval transaction show complete work. These results are sequenced, with the most recently completed tests appearing first. Two special-function keys permit the operator instantaneously to move forward or backward through multiple page displays.
\
77-12J45
7 7 - 1 2 3 * 5 DOE.JOHN A
/
395
PLATELET COUNT
345
K/MH3
/
U8C COUMT
lb.5
K/MM3
/
RBC COUNT
4.24
M/MM3
HEMOGLOBIN
13.0
G/DL
HEMATOCRIT
38.4
MCV (MEAN RBC VOLUME)
12sefc
y.
11
CU.MICRONS
MCH (MEAN RBC MB)
30.b
PICO-GRAMS
MCHC (MEAN RBC HB CONC)
33.0
G/DL
071S R
THMSPliWfT C L I N I C
SMA-b'bO PROFILE 1
SODIUM
130
MEO/L
\
POTASSIUM
5.2
MEO'L
\ \
