Compur. Biol. .Med. Vol. 8. pp. 197-206. 0 Pergamon Preu Ltd. 1978. Printed in Great Britain
0010‘@25/78/ck5014197
CLINICAL LABORATORY DATA PROCESSING A CENTRAL HOSPITAL COMPUTER
s02.00/0
WITH
CLARENCEC. WHITCOMB Department of Pathology, University of Vermont College of Medicine, Burlington, Vermont, U.S.A.
and CHRISTIANP. VOGT Department of Data Processing, Medical Center Hospital of Vermont, Burlington, Vermont, U.S.A.
and NANCYM. WILBUR Clinical Laboratory, Medical Center Hospital of Vermont, Burlington, Vermont, U.S.A. (Received 4 October
1977; received for publication 20 February
1978)
Abstract - A system for storing, retrieving and organizing laboratory test request and result information within the biochemistry, hematology, immunology, microbiology and urinalysis sections of a large clinical laboratory is described. All data files are maintained in a central hospital computer system separate from the laboratory. Specific items ofinformation as well as various groupings of data can be retrieved in real-time by laboratory technologists and clinicians. Schedules, batch processing routines are used to produce more complex reports which are not required at a moments notice. Critical factors in the design of such an information handling system are discussed.
Laboratory
Information
System
Hospital
Computer
INTRODUCTION
The quality of service provided by a modern clinical laboratory is determined only in part by the accuracy, precision, and efficiency of the analytical procedures performed. To clinicians using the laboratory, timeliness of test completion and availability of test results are as important as the quality of these results. Procedures for recording, filing, retrieving, organizing, and transmitting data in an accurate and timely manner are essential laboratory activities and should receive the same careful attention which has been given to individual test procedures. Such data handling activities can significantly influence the possible uses for information generated during the various testing procedures - uses which can affect patient care as well as laboratory management. Increasingly sophisticated techniques for automated data handling tasks have been applied within clinical laboratories as electronic data processing technology has evolved. Small computers have been directly interfaced with a wide variety of laboratory instruments for on-line analysis of data. Indeed, automation of the complex calculations required in radioisotopic analyses has become indispensable in many laboratories. Larger computers have been used to store and process the enormous quantities of data generated by large service laboratories. The interrelated data processing functions performed by such large computers constitute a laboratory information system. A variety of laboratory information systems have been developed during the past decade. Most of these systems have attempted to facilitate such activities as filing test request and result data, retrieving data for patient care or intralaboratory use, generating billing data, and integrating data from multiple source records into specialized summary reports. Many, however, have been designed to operate independently of other data processing systems which might be present within modem large hospitals. This report describes a laboratory information system in which all data storage and processing functions are performed by a CB.M. a/3--s 197
198
CLARENCE C. WHITCOMB, CHRISTIAN P. V~GT and NANCY M. WILBUR
large, general-purpose hospital computer. Both real-time and batch data processing capabilities are utilized to facilitate the data handling tasks described above. This laboratory information system was developed by the Data Processing Department of the Medical Center Hospital of Vermont for the Clinical Laboratory of this 510-bed general hospital affiliated with the University of Vermont College of Medicine. The system has been operational since 1974 within the laboratory areas of biochemistry, hematology, immunology, microbiology, and urinalysis. Approximately 985,000 test procedures are performed annually in these areas. The laboratory system currently operates on an IBM System/370 Model 145 with 640K of central processing storage and an on-line storage capacity of 1.6 billion characters. Approximately 15% of the on-line storage is allocated to laboratory data. At present 12 remote cathode-ray tube (CRT) display terminals and 3 remote printer terminals are employed for real-time interactions between laboratory personnel and the central computer. The central System/370 provides real-time and batch processing support to many other areas of activity in addition to the Clinical Laboratory. Currently 85 remote communication devices (CRT terminals and printers) are deployed throughout the hospital departments of Admitting, Business Office, Clinical Laboratory, and Pharmacy, as well as several patientcare areas including the Intensive Care Unit and the Emergency Department. The heart of the central computer system is an on-line data base of patient information which is available to all users and which is used to integrate and relate data from different specialized user files. Currently cu. 170,000 patient records reside in the on-line data base. Interaction with this data base permits efficient and continuous access to current information by all users, and facilitates the timely dissemination of information among users served by the communications network. The varied applications for the different hospital areas were developed primarily by the various users to suit their individual needs and were not elements of a preconceived hospital information system. Yet interactions between the departments served by the central computer are numerous, and many of the benefits which would be expected from a total information system have been realized. During the design of the laboratory data processing applications, several general observations evolved which seem applicable to any large-scale effort in laboratory data handling automation. These will be discussed in some detail below. Analyses of clinical laboratory activities demonstrate that primarily clerical tasks such as recording, filing, retrieving, and organizing data may frequently constitute rate-limiting constraints to optimal laboratory efficiency. Discussions of laboratory information systems have emphasized the critical nature of such basic tasks [ 11. In our system design, therefore, we sought to develop mechanisms which would improve the efficiency of such tasks as maintaining records of test request and result data, retrieving critical data in a timely fashion, and organizing data for a wide variety of uses. Special data “analysis” applications, such as algorithms for developing differential diagnoses or for detecting “suspicious” test results, were deliberately deferred for consideration at a later stage. The following specific observations relate to the design of data records, real-time processing requirements, and practical batch processing applications.
COMPLETENESS
OF RECORDED
DATA
Records should contain sufficient specific items of information to assure their usefulness in a wide variety of laboratory activities. In our system each individual request for a test procedure (e.g. a biochemistry panel, prothrombin time, urinalysis or sputum culture “work up”) generates a unique and rather lengthy data record which contains numerous items of administrative as well as technical information .relevant to the request. Table 1 lists some of the specific data which are contained within each individual test record. The individual data records are procedure-oriented and contain all data necessary for billing, organizing workbenches, reporting results, and trouble-shooting potential problems.
Clinical Table
laboratory
1. Data included
I. Administrative Data A. Patient name, age, sex, birthdate, hospital B. Location of patient. C. Identity of physician requesting this test.
data processing
199
in each test record
identification
number.
11. Laboratory Procedural Data A. Specimen identification number (may be assigned by the automated system or manually within each section). B. Progress status of this request (e.g. specimen not yet obtained, specimen in laboratory, preliminary result available - if any, final result available, etc.) C. Worklist to which this test may be assigned. D. Date and time of specimen receipt, test completion, and any subsequent updating of test result data. E. Identity of technologist responsible for the final test result. III.
Test Result Data A. Test name, result(s), units of measure, normal values. B. Optional pre-coded, standardized textural comments (e.g. specimen hemolyzed, results reviewed pathologist, pre-dialysis specimen, etc.). A maximum of three such comments can be included. C. Optional 4Ocharacter free-text note. D. Patient problem - list number to which this test relates.
EASE
OF
DATA
by
RECORDING
Individual items of information are recorded directly into on-line storage via peripheral CRT terminals having either typewriter input,keyboards or touch-sensitive display screens. Input of data by these methods has been readily accepted by our technical and clerical personnel, but manual entry of large quantities of data can create a burden for the staff. Indeed, initial implementation of the basic system in some sections required an expenditure of effort which seemed out of proportion to the benefits returned directly to the technical personnel of those areas. It was for this reason that direct acquisition of test result data from high-volume analytical instruments including the Technicon SMAC, Technicon SMA6-60, Radiometer ABL Blood Gas Analyzer, and Coulter Counter Model S were developed soon after implementation of the basic system. On-line data acquisition was accomplished by adding an IBM System/7 processor to the System/370. Laboratory instruments were interfaced directly to the System/7. The smaller computer is used to monitor and process both analog and digital output signals from laboratory instruments. Appropriate alphanumeric data generated from the input signals are then transmitted to the System/370 for storage in on-line laboratory files. In addition to monitoring laboratory instruments, the System/7 is also used to monitor and control the hospital fire detection and alarm system. On-line monitoring has improved both the efficiency and accuracy with which the data generated by high-volume analytical instruments can be recorded. However, should the on-line monitoring mechanisms fail, the well-tested manual data entry system remains available. We believe that had undue emphasis been given to instrument monitoring initially, the development of a workable basic data entry system (which serves all areas of the laboratory - automated as well as nonautomated) might have been compromised. EFFICIENCY
OF
DATA
RECORDING
Incorporation of laboratory data files within the central system contributes substantially to the efficiency of data input by laboratory personnel. Administrative data such as patient name, age, sex, physician, current hospital location, and pertinent billing information for the automated hospital billing system are maintained within nonlaboratory files of the central system by Admmitting and Business Office personnel. Such data are automatically copied from these source files into laboratory data records at the time of test request entry, thereby obviating redundant data entry steps. Furthermore, because the administrative data in the central files are maintained current in real-time, there is no requirement for laboratory personnel to maintain any on-going surveillance of patient admission, transfer, or discharge activities.
200
CLARENCEC. WHITCOMB,CHRISTIANP. V~GT and NANCY M. WILBUR
APPROPRIATE
DATA
FORMS
While the format of administrative data within each record can be standardized, differences in the style and content of results from such dissimilar test procedures as biochemical analyses, blood cell differential and morphology examinations, or microbial isolation and antibiotic sensitivity testing demand a suitable variety of formats for test result data. Data records are allowed to differ, therefore, in the format of the test result portion. The result format of a data record automatically controls the selection of appropriate routines for displaying the test result items, but does not affect the standardized way in which the record is stored and retrieved. FLEXIBILITY
OF
DATA
RETRIEVAL
Individual data records must be easily retrievable singly or in groups. However, the variety of ways in which records may need to be organized can be quite extensive. For example, different patterns of work organization frequently require differing groupings of data records. The practice commonly employed in a biochemistry section, in which a specimen is divided into multiple aliquots to be analyzed in parallel at different workbench stations, generally requires the creation of worklists containing identifying data for all specimens upon which individual test procedures are to be performed. Such worklists are created by retrieving as a group all records which are related by representing different requests for a common procedure. Such a procedure-oriented format for data organization may be less useful in sections such as hematology, where several different test procedures may be performed in a temporally sequential fashion upon a single specimen. In a microbiology section workbenches may be organized to perform either a single test procedure on multiple specimens, or multiple procedures upon a single specimen. A laboratory information system must accommodate the differing requirements for data organization which can arise from differing work patterns. Our system employs a general-purpose retrieval routine which permits retrieval not only of individual data records but also groups of records which share various common parameters (eg. patient identity, test type, nursing unit, date of request, test completion date, etc.). Table 2 lists some of the retrieval parameters which can be used to define groupings of test records. This general-purpose retrieval mechanism provides sufficient flexibility in the specification of retrieval parameters to readily accommodate most moment-to-moment requirements for lists of test request data. Indeed, the versatility of this retrieval routine may well be the single most important attribute of the laboratory information system. REAL-TIME
ACCESS
TO STORED
DATA
When specific data are needed for organizing workbenches, trouble-shooting intralaboratory problems, or reporting specific test results to a patient-care area, retrieval of records containing the required data must be accomplished in real-time. In general, however, effective use of such data does not require elaborate display formats. The general-purpose retrieval routine described above permits rapid access to stored data, but provides only simple visual or printed displays. Such presentations are not intended to serve as permanent records, but rather are designed for rapid communication of information for moment-to-fable 2. Data retrieval parameters. Any combination of the following items may be specified to define a “list” of records to he retrieved. Items designated * may be specified uniquely or an inclusive range may be specified Patient location *Patient identification number (hospital medical record number) *Date of request *Date and time of test completion *Laboratory workhst to which specimen may be assigned *Specimen identification number *Specific test procedure code
Clinical
laboratory
data processing
201
moment use. To further facilitate rapid dissemination of critical test result data, the central computer system permits inquiry into laboratory files from CRT terminals located in patient-care areas and also allows laboratory personnel to transmit test results directly to printer terminals in such locations as the Emergency Department and the Intensive Care Unit. Such non-telephonic mechanisms for communication of test results to users have benefited both nursing and laboratory personnel. INTEGRATION
AND
ANALYSIS
OF
STORED
DATA
The production of complex, specialized summaries of data extracted from many different source records is satisfactorily accomplished by scheduled, batch processing. Real-time processing is not required for such reports. In our system individual patient reports, which include results of tests performed on previous days as well as newly completed tests, and in which results can be organized meaningfully, are currently produced at a scheduled time once each day. Figure 1 depicts such a cumulative patient report. Other reports produced at scheduled times include listings of test results for all patients at individual nursing stations, for all patients of individual physicians, for all procedures performed within a given laboratory section, as well as a specialized report which correlates current microbial isolates with their sources for use in hospital infections surveillance. The processing routines for retrieving and integrating data from multiple records require considerable computer processor time, and real-time execution of these routines might well impede real-time access to specific data records. In addition, changes in user practices not infrequently dictate requirements for changes in the computer programs used to generate such reports. We believe that special data integrating applications are most expeditiously managed when they can operate in an off-line or batch mode at scheduled intervals. Happily such is the case with most of the complex reports produced by this laboratory. Scheduling of laboratory report production requires consideration of both clinicians’ AS OF
1600 HOURS
FOR - PATIENT, MRN - 960-007-3
co2 MEQ/L
POTASSIUM
31
5.2
30
3.8 4.1
435P 715A 745A
101
01131 01/30
435P 435P
LDH SERUM SCOT SERUM
435P
103
715A 1130A
MEQ/L
103OP
1977 LOC
BUN MC/DL
138 136 140
18
UNITS UNITS MCV CU.MIC
7.2
15.3
44.2
85.3
CONTROL SECS
TIME
19.5 16.6
24 37
URINE
15
32 42 HEMATOCRIT “.
Tl.ME % OF NORM
11.5 11.0 HEMOLYSED
- WD#Z
SODIUM MEQ/L
HEMOGLOBIN CMIDL
SPECIMEN 01/30
15,
MALE
WBC COUNT TH/CUMM
PROTHROMBIN PATIENT SECS 01/31 02101
FEBRUARY
AGE 039 Y, - DOE, J
CHLORIDE MEQ/L 01130 01/31 c2/01
01/30
TUESDAY
JOHN Q DOCTOR
MCH uuc 28.5
DRAWN
0730 1110
CULTURE
ESCHERICHIA SENSITIVE
COLI TO
RESISTANT
GREATER
CEPHALO
TETRACY
TO AMPICIL
THAN
100,000
WLYMIX
AMIKACN
/ML
GENTAMI
TOBRAMY
Fig. 1. Format ofcomputer-printed patient report. This sample report was re-typed for photographic clarity. Dates and times in left-hand margin are the date and time that specimen was received within the laboratory.
202
CLARENCEC. WHITCOMB,CHRISTIANP. V~GT and NANCY M. WILBUR
habits and laboratory work patterns [2]. In general, some satisfactory schedule can eventually be established. Dependence upon scheduled, batch generation of listings for use within the laboratory is less desirable, however. Indeed, laboratory work flow patterns may well be disrupted by dependence upon rigidly scheduled processing. The real-time data retrieval routine described above has proved suitable for most moment-to-moment intralaboratory requirements. RETENTION
OF
DATA
A realistic assessment of real-time data access needs is required to efficiently allocate online storage capacity. In our system data records are retained in on-line storage as long as the test procedure is in progress. When final test results are entered, the records are designated as “complete”. Complete records are thereafter retained on-line as long as the patient remains within the hospital or, for outpatients, for an additional two weeks. After these time periods have elapsed, complete records are automatically copied to magnetic tape files. Data in the tape files may be subsequently retrieved by general-purpose batch routines, which can be scheduled as required. To meet the occasional demands for test request or result information for procedures completed weeks or months previously, long-term, hard-copy data summaries are maintained within the laboratory office. In our laboratory such records are maintained for seven years. The laboratory information system facilitates maintenance of these long-term files by allowing for the periodic production of microfiche cards which contain, in condensed but easily readable Term, summaries of all test request and result data generated during a specified period of time. Direct transcription of data from on-line files to microfiche is performed biweekly. Figure 2 is an example of such a microfiche card. This method for providing hard-copy data summaries has greatly reduced the clerical effort and physical space required for long-term data retention. EASE
OF
SYSTEM
MODIFICATION
Changes in laboratory procedures or patient-care practices may necessitate new ways for organizing or displaying data contained within laboratory test records. System routines should be designed to easily accommodate changing user requirements. In our system each test record contains a number of coded parameters which control the manner in which the record will be processed by different real-time or batch routines. These parameters control such actions as assigning the test to a particular worklist, selecting the format for the result portion of the record, assigning a specific charge for the hospital billing system, designating an output printer on which the test result may be automatically printed, and placing of the result on the printed cumulative patient report. The parameters are automatically obtained from specification tables at the time of record creation, and these tables can be modified at any time (even in real-time) by authorized laboratory personnel. Given appropriate definition of the control parameters, many real-time and batch processing functions can be quickly altered to accommodate changes in laboratory or hospital practices. Other changes in system operations require the assistance of data processing personnel. Changes in schedules for batch processing jobs are arranged with the data processing operations manager. Addition of new applications programs or modification of existing software requires the assistance of the programming staff. Such changes have virtually never been required under emergent conditions, however. This division of responsibility for laboratory information system operations between the Data Processing Department and the Clinical Laboratory has proved quite workable in our setting. Liaison between the Clinical Laboratory and the Data Processing Department is maintained by one senior laboratory technologist, who assumes this responsibility as a complement to other laboratory administrative tasks. The attention of most of the technical and professional staff of the laboratory remains appropriately focused on the generation of “quality” test result data and their interpretation, while responsibility for system hardware and software remains logically with data processing personnel.
Clinical laboratory data processing
Fig. 2. Sample of microfiche card used for long-term storage of laboratory test request and result data. Approximately 18-20 such cards are required for storage of data generated in a one-month period.
203
Clinical
laboratory
data
processing
205
Our experience with the Medical Center Hospital of Vermont laboratory information system supports several general principles which have been discussed in the literature of information processing systems. System design must carefully consider input from a sufficiently broad spectrum of involved individuals in order to identify those activities for which automation can be reasonably expected to result in improved overall performance [3]. Automation of activities which may appear intellectually glamorous may not necessarily prove as advantageous as automation of basic data handling tasks [4]. Rational use of professional skills as well as equipment resources can be achieved by a careful division of responsibilities for system operations and maintenance between clinical laboratory users and data processing personnel [S].
SUMMARY A clinical laboratory information system which utilizes the resources of a central hospital computer has been implemented in the biochemistry, hematology, immunology, microbiology, and urinalysis sections of a large hospital laboratory. The general-purpose hospital computer provides both real-time and batch processing of laboratory test request and result information. Optimal use of stored information requires that data records be complete, and the differing requirements of laboratory and patient-care personnel necessitate many different ways for retrieving and grouping data records. Data presentations for most moment-to-moment uses need not be elaborate, however. Production of complex data summaries is best performed in batch mode. Such processing is quite suitable for presentations in which careful data formating or the application of data analwis algorithms may be required. Such complex data summaries are rarely needed in realtime. Basic data recording and retrieval operations are performed via CRT display terminals. Direct acquisition of test result data from automated analytical instruments was developed as an embellishment to the basic manual input system in order to increase the efficiency and accuracy of data recording. Additional special data analysis applications can undoubtedly be developed and added to the basic system as required. Incorporation of the laboratory data processing functions within the repertoire of the central hospital computer system permits beneficial interchanges of information between the Clinical Laboratory and other hospital areas and greatly increases the efficiency of information recording and dissemination. The design of system software in a generalpurpose fashion with specific record handling control parameters being defined in specification tables permits easy modification of many real-time and batch processing operations by laboratory personnel. System operating schedules and software maintenance remain the responsibility of data processing personnel. This rational division of responsibilities has proved quite workable. Acknowledgements - Dr. Robert W. Coon, formerly Director of the Clinical Laboratory and Mr. Walter X. Kane, formerly Director of the Data Processing Department, played key roles in the development of this system. Mrs. Kerri Collette provided valuable assistance with the preparation of this manuscript
REFERENCES 1. A. R. Walter, What to look for in a computerized laboratory information system, Lab. Med. 3( 12), 31, December (1972), and 4(l), 32, January (1973). _ 2. W. F. Hamilton and S. Raymond, A system of computer-generated laboratory reports for clinical use, Comput. _ Biol. Med. 3, 141 (1973). _ 3. J. Orlicky, The Successful Computer System. McGraw-Hill, New York (1969). 4. S. Raymond, Criteria in the choice of a computer system, JAMA 228, 591 (1974) and 228, 1015 (1974). 5. J. Dearden, How to organize information systems, Harvard Bus. Rev. 43, 65 (1965).
CLARENCEC. WHITCOMB,CHRISTIANP. V~GT and NANCY M. WILBUR
206
About the Autbor - CLARENCEC. WHITCOMBreceived his B.A. degree from Harvard College in 1964 and his M.D. from the University of Vermont College of Medicine in 1968. Residency training in anatomic and clinical pathology was received at Medical Center Hospital of Vermont. He is presently Asst. Professor of Pathology at the University of Vermont College of Medicine and is a Diplomate of the American Board of Pathology and a Fellow of the American Society of Clinical Pathologists. Dr. Whitcomb has pursued interests in medical applications ofdecision theory and automated data processing throughout graduate and post-graduate training. He has assisted in the design and implementation ofclinical laboratory data processing systems for the U.S. Army and for the Medical Center Hospital of Vermont. His other activities have included responsibility for the hematology laboratory at Medical Center Hospital of Vermont as well as research in blood coagulation and the effects of ultrasound on blood platelet function. About tbe Autbor - NANCY M. WILBURreceived her B.A. degree in Zoology
from Mt. Holyoke College in 1963. After receiving a certificate in Medical Technology from Washington Hospital Center, Washington, D.C. in 1964, she worked as a MT(ASCP) registered technologist in the chemistry laboratory at Washington Hospital Center. In 1967 she joined the laboratory stalfat Medical Center Hospital of Vermont where she has held positions of chemistry supervisor and currently, assistant administrative technologist. In thesecapacities she has served as primary laboratory liaison with the hospital data processing department for development and operations of the laboratory information system. Ms. Wilbur has pursued graduate studies at American University and at the University of Vermont, where she currently holds the appointment of Clinical Instructor in Medical Technology. About tbe Author - CHRISTIANP. VCGT was born in Berlin, Germany
States in graduate computers. has, since currently
in 1941. He came to the United 1957 and received a B.A. degree in Psychology from Hamilton College in 1964. During work at the University of Maryland he became interested in process control devices and Switching his career to data processing, he worked at Henry Ford Hospital in Detroit and 1969, been at the Medical Center Hospital of Vermont in Burlington, Vermont where he is the Director of Data Processing.
During the period from 1969 to 1975 Mr. Vogt developed a Hospital Information System at Medical Center Hospital of Vermont. The Laboratory system described here is part of this HIS and is a result of the cooperative efforts of the clinical laboratory and data processing staff.
0010‘@25/78/ck5014197
CLINICAL LABORATORY DATA PROCESSING A CENTRAL HOSPITAL COMPUTER
s02.00/0
WITH
CLARENCEC. WHITCOMB Department of Pathology, University of Vermont College of Medicine, Burlington, Vermont, U.S.A.
and CHRISTIANP. VOGT Department of Data Processing, Medical Center Hospital of Vermont, Burlington, Vermont, U.S.A.
and NANCYM. WILBUR Clinical Laboratory, Medical Center Hospital of Vermont, Burlington, Vermont, U.S.A. (Received 4 October
1977; received for publication 20 February
1978)
Abstract - A system for storing, retrieving and organizing laboratory test request and result information within the biochemistry, hematology, immunology, microbiology and urinalysis sections of a large clinical laboratory is described. All data files are maintained in a central hospital computer system separate from the laboratory. Specific items ofinformation as well as various groupings of data can be retrieved in real-time by laboratory technologists and clinicians. Schedules, batch processing routines are used to produce more complex reports which are not required at a moments notice. Critical factors in the design of such an information handling system are discussed.
Laboratory
Information
System
Hospital
Computer
INTRODUCTION
The quality of service provided by a modern clinical laboratory is determined only in part by the accuracy, precision, and efficiency of the analytical procedures performed. To clinicians using the laboratory, timeliness of test completion and availability of test results are as important as the quality of these results. Procedures for recording, filing, retrieving, organizing, and transmitting data in an accurate and timely manner are essential laboratory activities and should receive the same careful attention which has been given to individual test procedures. Such data handling activities can significantly influence the possible uses for information generated during the various testing procedures - uses which can affect patient care as well as laboratory management. Increasingly sophisticated techniques for automated data handling tasks have been applied within clinical laboratories as electronic data processing technology has evolved. Small computers have been directly interfaced with a wide variety of laboratory instruments for on-line analysis of data. Indeed, automation of the complex calculations required in radioisotopic analyses has become indispensable in many laboratories. Larger computers have been used to store and process the enormous quantities of data generated by large service laboratories. The interrelated data processing functions performed by such large computers constitute a laboratory information system. A variety of laboratory information systems have been developed during the past decade. Most of these systems have attempted to facilitate such activities as filing test request and result data, retrieving data for patient care or intralaboratory use, generating billing data, and integrating data from multiple source records into specialized summary reports. Many, however, have been designed to operate independently of other data processing systems which might be present within modem large hospitals. This report describes a laboratory information system in which all data storage and processing functions are performed by a CB.M. a/3--s 197
198
CLARENCE C. WHITCOMB, CHRISTIAN P. V~GT and NANCY M. WILBUR
large, general-purpose hospital computer. Both real-time and batch data processing capabilities are utilized to facilitate the data handling tasks described above. This laboratory information system was developed by the Data Processing Department of the Medical Center Hospital of Vermont for the Clinical Laboratory of this 510-bed general hospital affiliated with the University of Vermont College of Medicine. The system has been operational since 1974 within the laboratory areas of biochemistry, hematology, immunology, microbiology, and urinalysis. Approximately 985,000 test procedures are performed annually in these areas. The laboratory system currently operates on an IBM System/370 Model 145 with 640K of central processing storage and an on-line storage capacity of 1.6 billion characters. Approximately 15% of the on-line storage is allocated to laboratory data. At present 12 remote cathode-ray tube (CRT) display terminals and 3 remote printer terminals are employed for real-time interactions between laboratory personnel and the central computer. The central System/370 provides real-time and batch processing support to many other areas of activity in addition to the Clinical Laboratory. Currently 85 remote communication devices (CRT terminals and printers) are deployed throughout the hospital departments of Admitting, Business Office, Clinical Laboratory, and Pharmacy, as well as several patientcare areas including the Intensive Care Unit and the Emergency Department. The heart of the central computer system is an on-line data base of patient information which is available to all users and which is used to integrate and relate data from different specialized user files. Currently cu. 170,000 patient records reside in the on-line data base. Interaction with this data base permits efficient and continuous access to current information by all users, and facilitates the timely dissemination of information among users served by the communications network. The varied applications for the different hospital areas were developed primarily by the various users to suit their individual needs and were not elements of a preconceived hospital information system. Yet interactions between the departments served by the central computer are numerous, and many of the benefits which would be expected from a total information system have been realized. During the design of the laboratory data processing applications, several general observations evolved which seem applicable to any large-scale effort in laboratory data handling automation. These will be discussed in some detail below. Analyses of clinical laboratory activities demonstrate that primarily clerical tasks such as recording, filing, retrieving, and organizing data may frequently constitute rate-limiting constraints to optimal laboratory efficiency. Discussions of laboratory information systems have emphasized the critical nature of such basic tasks [ 11. In our system design, therefore, we sought to develop mechanisms which would improve the efficiency of such tasks as maintaining records of test request and result data, retrieving critical data in a timely fashion, and organizing data for a wide variety of uses. Special data “analysis” applications, such as algorithms for developing differential diagnoses or for detecting “suspicious” test results, were deliberately deferred for consideration at a later stage. The following specific observations relate to the design of data records, real-time processing requirements, and practical batch processing applications.
COMPLETENESS
OF RECORDED
DATA
Records should contain sufficient specific items of information to assure their usefulness in a wide variety of laboratory activities. In our system each individual request for a test procedure (e.g. a biochemistry panel, prothrombin time, urinalysis or sputum culture “work up”) generates a unique and rather lengthy data record which contains numerous items of administrative as well as technical information .relevant to the request. Table 1 lists some of the specific data which are contained within each individual test record. The individual data records are procedure-oriented and contain all data necessary for billing, organizing workbenches, reporting results, and trouble-shooting potential problems.
Clinical Table
laboratory
1. Data included
I. Administrative Data A. Patient name, age, sex, birthdate, hospital B. Location of patient. C. Identity of physician requesting this test.
data processing
199
in each test record
identification
number.
11. Laboratory Procedural Data A. Specimen identification number (may be assigned by the automated system or manually within each section). B. Progress status of this request (e.g. specimen not yet obtained, specimen in laboratory, preliminary result available - if any, final result available, etc.) C. Worklist to which this test may be assigned. D. Date and time of specimen receipt, test completion, and any subsequent updating of test result data. E. Identity of technologist responsible for the final test result. III.
Test Result Data A. Test name, result(s), units of measure, normal values. B. Optional pre-coded, standardized textural comments (e.g. specimen hemolyzed, results reviewed pathologist, pre-dialysis specimen, etc.). A maximum of three such comments can be included. C. Optional 4Ocharacter free-text note. D. Patient problem - list number to which this test relates.
EASE
OF
DATA
by
RECORDING
Individual items of information are recorded directly into on-line storage via peripheral CRT terminals having either typewriter input,keyboards or touch-sensitive display screens. Input of data by these methods has been readily accepted by our technical and clerical personnel, but manual entry of large quantities of data can create a burden for the staff. Indeed, initial implementation of the basic system in some sections required an expenditure of effort which seemed out of proportion to the benefits returned directly to the technical personnel of those areas. It was for this reason that direct acquisition of test result data from high-volume analytical instruments including the Technicon SMAC, Technicon SMA6-60, Radiometer ABL Blood Gas Analyzer, and Coulter Counter Model S were developed soon after implementation of the basic system. On-line data acquisition was accomplished by adding an IBM System/7 processor to the System/370. Laboratory instruments were interfaced directly to the System/7. The smaller computer is used to monitor and process both analog and digital output signals from laboratory instruments. Appropriate alphanumeric data generated from the input signals are then transmitted to the System/370 for storage in on-line laboratory files. In addition to monitoring laboratory instruments, the System/7 is also used to monitor and control the hospital fire detection and alarm system. On-line monitoring has improved both the efficiency and accuracy with which the data generated by high-volume analytical instruments can be recorded. However, should the on-line monitoring mechanisms fail, the well-tested manual data entry system remains available. We believe that had undue emphasis been given to instrument monitoring initially, the development of a workable basic data entry system (which serves all areas of the laboratory - automated as well as nonautomated) might have been compromised. EFFICIENCY
OF
DATA
RECORDING
Incorporation of laboratory data files within the central system contributes substantially to the efficiency of data input by laboratory personnel. Administrative data such as patient name, age, sex, physician, current hospital location, and pertinent billing information for the automated hospital billing system are maintained within nonlaboratory files of the central system by Admmitting and Business Office personnel. Such data are automatically copied from these source files into laboratory data records at the time of test request entry, thereby obviating redundant data entry steps. Furthermore, because the administrative data in the central files are maintained current in real-time, there is no requirement for laboratory personnel to maintain any on-going surveillance of patient admission, transfer, or discharge activities.
200
CLARENCEC. WHITCOMB,CHRISTIANP. V~GT and NANCY M. WILBUR
APPROPRIATE
DATA
FORMS
While the format of administrative data within each record can be standardized, differences in the style and content of results from such dissimilar test procedures as biochemical analyses, blood cell differential and morphology examinations, or microbial isolation and antibiotic sensitivity testing demand a suitable variety of formats for test result data. Data records are allowed to differ, therefore, in the format of the test result portion. The result format of a data record automatically controls the selection of appropriate routines for displaying the test result items, but does not affect the standardized way in which the record is stored and retrieved. FLEXIBILITY
OF
DATA
RETRIEVAL
Individual data records must be easily retrievable singly or in groups. However, the variety of ways in which records may need to be organized can be quite extensive. For example, different patterns of work organization frequently require differing groupings of data records. The practice commonly employed in a biochemistry section, in which a specimen is divided into multiple aliquots to be analyzed in parallel at different workbench stations, generally requires the creation of worklists containing identifying data for all specimens upon which individual test procedures are to be performed. Such worklists are created by retrieving as a group all records which are related by representing different requests for a common procedure. Such a procedure-oriented format for data organization may be less useful in sections such as hematology, where several different test procedures may be performed in a temporally sequential fashion upon a single specimen. In a microbiology section workbenches may be organized to perform either a single test procedure on multiple specimens, or multiple procedures upon a single specimen. A laboratory information system must accommodate the differing requirements for data organization which can arise from differing work patterns. Our system employs a general-purpose retrieval routine which permits retrieval not only of individual data records but also groups of records which share various common parameters (eg. patient identity, test type, nursing unit, date of request, test completion date, etc.). Table 2 lists some of the retrieval parameters which can be used to define groupings of test records. This general-purpose retrieval mechanism provides sufficient flexibility in the specification of retrieval parameters to readily accommodate most moment-to-moment requirements for lists of test request data. Indeed, the versatility of this retrieval routine may well be the single most important attribute of the laboratory information system. REAL-TIME
ACCESS
TO STORED
DATA
When specific data are needed for organizing workbenches, trouble-shooting intralaboratory problems, or reporting specific test results to a patient-care area, retrieval of records containing the required data must be accomplished in real-time. In general, however, effective use of such data does not require elaborate display formats. The general-purpose retrieval routine described above permits rapid access to stored data, but provides only simple visual or printed displays. Such presentations are not intended to serve as permanent records, but rather are designed for rapid communication of information for moment-to-fable 2. Data retrieval parameters. Any combination of the following items may be specified to define a “list” of records to he retrieved. Items designated * may be specified uniquely or an inclusive range may be specified Patient location *Patient identification number (hospital medical record number) *Date of request *Date and time of test completion *Laboratory workhst to which specimen may be assigned *Specimen identification number *Specific test procedure code
Clinical
laboratory
data processing
201
moment use. To further facilitate rapid dissemination of critical test result data, the central computer system permits inquiry into laboratory files from CRT terminals located in patient-care areas and also allows laboratory personnel to transmit test results directly to printer terminals in such locations as the Emergency Department and the Intensive Care Unit. Such non-telephonic mechanisms for communication of test results to users have benefited both nursing and laboratory personnel. INTEGRATION
AND
ANALYSIS
OF
STORED
DATA
The production of complex, specialized summaries of data extracted from many different source records is satisfactorily accomplished by scheduled, batch processing. Real-time processing is not required for such reports. In our system individual patient reports, which include results of tests performed on previous days as well as newly completed tests, and in which results can be organized meaningfully, are currently produced at a scheduled time once each day. Figure 1 depicts such a cumulative patient report. Other reports produced at scheduled times include listings of test results for all patients at individual nursing stations, for all patients of individual physicians, for all procedures performed within a given laboratory section, as well as a specialized report which correlates current microbial isolates with their sources for use in hospital infections surveillance. The processing routines for retrieving and integrating data from multiple records require considerable computer processor time, and real-time execution of these routines might well impede real-time access to specific data records. In addition, changes in user practices not infrequently dictate requirements for changes in the computer programs used to generate such reports. We believe that special data integrating applications are most expeditiously managed when they can operate in an off-line or batch mode at scheduled intervals. Happily such is the case with most of the complex reports produced by this laboratory. Scheduling of laboratory report production requires consideration of both clinicians’ AS OF
1600 HOURS
FOR - PATIENT, MRN - 960-007-3
co2 MEQ/L
POTASSIUM
31
5.2
30
3.8 4.1
435P 715A 745A
101
01131 01/30
435P 435P
LDH SERUM SCOT SERUM
435P
103
715A 1130A
MEQ/L
103OP
1977 LOC
BUN MC/DL
138 136 140
18
UNITS UNITS MCV CU.MIC
7.2
15.3
44.2
85.3
CONTROL SECS
TIME
19.5 16.6
24 37
URINE
15
32 42 HEMATOCRIT “.
Tl.ME % OF NORM
11.5 11.0 HEMOLYSED
- WD#Z
SODIUM MEQ/L
HEMOGLOBIN CMIDL
SPECIMEN 01/30
15,
MALE
WBC COUNT TH/CUMM
PROTHROMBIN PATIENT SECS 01/31 02101
FEBRUARY
AGE 039 Y, - DOE, J
CHLORIDE MEQ/L 01130 01/31 c2/01
01/30
TUESDAY
JOHN Q DOCTOR
MCH uuc 28.5
DRAWN
0730 1110
CULTURE
ESCHERICHIA SENSITIVE
COLI TO
RESISTANT
GREATER
CEPHALO
TETRACY
TO AMPICIL
THAN
100,000
WLYMIX
AMIKACN
/ML
GENTAMI
TOBRAMY
Fig. 1. Format ofcomputer-printed patient report. This sample report was re-typed for photographic clarity. Dates and times in left-hand margin are the date and time that specimen was received within the laboratory.
202
CLARENCEC. WHITCOMB,CHRISTIANP. V~GT and NANCY M. WILBUR
habits and laboratory work patterns [2]. In general, some satisfactory schedule can eventually be established. Dependence upon scheduled, batch generation of listings for use within the laboratory is less desirable, however. Indeed, laboratory work flow patterns may well be disrupted by dependence upon rigidly scheduled processing. The real-time data retrieval routine described above has proved suitable for most moment-to-moment intralaboratory requirements. RETENTION
OF
DATA
A realistic assessment of real-time data access needs is required to efficiently allocate online storage capacity. In our system data records are retained in on-line storage as long as the test procedure is in progress. When final test results are entered, the records are designated as “complete”. Complete records are thereafter retained on-line as long as the patient remains within the hospital or, for outpatients, for an additional two weeks. After these time periods have elapsed, complete records are automatically copied to magnetic tape files. Data in the tape files may be subsequently retrieved by general-purpose batch routines, which can be scheduled as required. To meet the occasional demands for test request or result information for procedures completed weeks or months previously, long-term, hard-copy data summaries are maintained within the laboratory office. In our laboratory such records are maintained for seven years. The laboratory information system facilitates maintenance of these long-term files by allowing for the periodic production of microfiche cards which contain, in condensed but easily readable Term, summaries of all test request and result data generated during a specified period of time. Direct transcription of data from on-line files to microfiche is performed biweekly. Figure 2 is an example of such a microfiche card. This method for providing hard-copy data summaries has greatly reduced the clerical effort and physical space required for long-term data retention. EASE
OF
SYSTEM
MODIFICATION
Changes in laboratory procedures or patient-care practices may necessitate new ways for organizing or displaying data contained within laboratory test records. System routines should be designed to easily accommodate changing user requirements. In our system each test record contains a number of coded parameters which control the manner in which the record will be processed by different real-time or batch routines. These parameters control such actions as assigning the test to a particular worklist, selecting the format for the result portion of the record, assigning a specific charge for the hospital billing system, designating an output printer on which the test result may be automatically printed, and placing of the result on the printed cumulative patient report. The parameters are automatically obtained from specification tables at the time of record creation, and these tables can be modified at any time (even in real-time) by authorized laboratory personnel. Given appropriate definition of the control parameters, many real-time and batch processing functions can be quickly altered to accommodate changes in laboratory or hospital practices. Other changes in system operations require the assistance of data processing personnel. Changes in schedules for batch processing jobs are arranged with the data processing operations manager. Addition of new applications programs or modification of existing software requires the assistance of the programming staff. Such changes have virtually never been required under emergent conditions, however. This division of responsibility for laboratory information system operations between the Data Processing Department and the Clinical Laboratory has proved quite workable in our setting. Liaison between the Clinical Laboratory and the Data Processing Department is maintained by one senior laboratory technologist, who assumes this responsibility as a complement to other laboratory administrative tasks. The attention of most of the technical and professional staff of the laboratory remains appropriately focused on the generation of “quality” test result data and their interpretation, while responsibility for system hardware and software remains logically with data processing personnel.
Clinical laboratory data processing
Fig. 2. Sample of microfiche card used for long-term storage of laboratory test request and result data. Approximately 18-20 such cards are required for storage of data generated in a one-month period.
203
Clinical
laboratory
data
processing
205
Our experience with the Medical Center Hospital of Vermont laboratory information system supports several general principles which have been discussed in the literature of information processing systems. System design must carefully consider input from a sufficiently broad spectrum of involved individuals in order to identify those activities for which automation can be reasonably expected to result in improved overall performance [3]. Automation of activities which may appear intellectually glamorous may not necessarily prove as advantageous as automation of basic data handling tasks [4]. Rational use of professional skills as well as equipment resources can be achieved by a careful division of responsibilities for system operations and maintenance between clinical laboratory users and data processing personnel [S].
SUMMARY A clinical laboratory information system which utilizes the resources of a central hospital computer has been implemented in the biochemistry, hematology, immunology, microbiology, and urinalysis sections of a large hospital laboratory. The general-purpose hospital computer provides both real-time and batch processing of laboratory test request and result information. Optimal use of stored information requires that data records be complete, and the differing requirements of laboratory and patient-care personnel necessitate many different ways for retrieving and grouping data records. Data presentations for most moment-to-moment uses need not be elaborate, however. Production of complex data summaries is best performed in batch mode. Such processing is quite suitable for presentations in which careful data formating or the application of data analwis algorithms may be required. Such complex data summaries are rarely needed in realtime. Basic data recording and retrieval operations are performed via CRT display terminals. Direct acquisition of test result data from automated analytical instruments was developed as an embellishment to the basic manual input system in order to increase the efficiency and accuracy of data recording. Additional special data analysis applications can undoubtedly be developed and added to the basic system as required. Incorporation of the laboratory data processing functions within the repertoire of the central hospital computer system permits beneficial interchanges of information between the Clinical Laboratory and other hospital areas and greatly increases the efficiency of information recording and dissemination. The design of system software in a generalpurpose fashion with specific record handling control parameters being defined in specification tables permits easy modification of many real-time and batch processing operations by laboratory personnel. System operating schedules and software maintenance remain the responsibility of data processing personnel. This rational division of responsibilities has proved quite workable. Acknowledgements - Dr. Robert W. Coon, formerly Director of the Clinical Laboratory and Mr. Walter X. Kane, formerly Director of the Data Processing Department, played key roles in the development of this system. Mrs. Kerri Collette provided valuable assistance with the preparation of this manuscript
REFERENCES 1. A. R. Walter, What to look for in a computerized laboratory information system, Lab. Med. 3( 12), 31, December (1972), and 4(l), 32, January (1973). _ 2. W. F. Hamilton and S. Raymond, A system of computer-generated laboratory reports for clinical use, Comput. _ Biol. Med. 3, 141 (1973). _ 3. J. Orlicky, The Successful Computer System. McGraw-Hill, New York (1969). 4. S. Raymond, Criteria in the choice of a computer system, JAMA 228, 591 (1974) and 228, 1015 (1974). 5. J. Dearden, How to organize information systems, Harvard Bus. Rev. 43, 65 (1965).
CLARENCEC. WHITCOMB,CHRISTIANP. V~GT and NANCY M. WILBUR
206
About the Autbor - CLARENCEC. WHITCOMBreceived his B.A. degree from Harvard College in 1964 and his M.D. from the University of Vermont College of Medicine in 1968. Residency training in anatomic and clinical pathology was received at Medical Center Hospital of Vermont. He is presently Asst. Professor of Pathology at the University of Vermont College of Medicine and is a Diplomate of the American Board of Pathology and a Fellow of the American Society of Clinical Pathologists. Dr. Whitcomb has pursued interests in medical applications ofdecision theory and automated data processing throughout graduate and post-graduate training. He has assisted in the design and implementation ofclinical laboratory data processing systems for the U.S. Army and for the Medical Center Hospital of Vermont. His other activities have included responsibility for the hematology laboratory at Medical Center Hospital of Vermont as well as research in blood coagulation and the effects of ultrasound on blood platelet function. About tbe Autbor - NANCY M. WILBURreceived her B.A. degree in Zoology
from Mt. Holyoke College in 1963. After receiving a certificate in Medical Technology from Washington Hospital Center, Washington, D.C. in 1964, she worked as a MT(ASCP) registered technologist in the chemistry laboratory at Washington Hospital Center. In 1967 she joined the laboratory stalfat Medical Center Hospital of Vermont where she has held positions of chemistry supervisor and currently, assistant administrative technologist. In thesecapacities she has served as primary laboratory liaison with the hospital data processing department for development and operations of the laboratory information system. Ms. Wilbur has pursued graduate studies at American University and at the University of Vermont, where she currently holds the appointment of Clinical Instructor in Medical Technology. About tbe Author - CHRISTIANP. VCGT was born in Berlin, Germany
States in graduate computers. has, since currently
in 1941. He came to the United 1957 and received a B.A. degree in Psychology from Hamilton College in 1964. During work at the University of Maryland he became interested in process control devices and Switching his career to data processing, he worked at Henry Ford Hospital in Detroit and 1969, been at the Medical Center Hospital of Vermont in Burlington, Vermont where he is the Director of Data Processing.
During the period from 1969 to 1975 Mr. Vogt developed a Hospital Information System at Medical Center Hospital of Vermont. The Laboratory system described here is part of this HIS and is a result of the cooperative efforts of the clinical laboratory and data processing staff.
