HOW CAN A STANDARDSOFTWAREPACKAGEFOR DATA MANAGEMENTIN ANESTHESIABE ACHIEVED? Alex M. Zbinden,* Jens Christensen,* Mario Kuster']"
Zbinden AM, Christensen J, Kuster M. How can a standard software package for data management in anesthesia be achieved? J Clin Monit 1992;8:315-318 ABSTRACT.Collecting data for administrative, statistical, medical, and organizational purposes is becoming increasingly important in anesthesia. In 1986 the Swiss Society for Anesthesiology decided to create a program that would be compatible for different computers and would expedite data collection. The system developed was called Information System for Operations (ISOP), which was written in the database and programming system Massachusetts General Hospital Utility Multi Programming System (MUMPS). It was installed in eight hospitals and met the initial requirements, but the individual requirements of the hospitals were greatly underestimated. MUMPS has an impressive data storage capability and handling when used in a personal computer (PC) network. The user-interface, however, is inferior to other PC packages, partly because windowing and mouse support were not implemented when the ANSI standard was set. Improved statistical programs, a module for on-line data acquisition, and intensive care unit (ICU) use will be additional modules to the program. KEYWORDS.Records, anesthesia. Equipment: computers.
The practice o f anesthesiology d e m a n d s that great quantities o f rapidly p r o d u c e d data be processed efficiently for m a n y purposes, including administrative, statistical, medical, and organizational needs. T h e same data processing system for these applications could also be used for the entire hospital. If a single p r o g r a m can integrate surgical scheduling and data acquisition for an anesthesia department, maintain statistical data for other departments, and p e r f o r m administrative functions, there w o u l d be no r e d u n d a n c y o f data acquisition. T h e system w o u l d be an effective and cost-efficient p r o g r a m for both the anesthesia d e p a r t m e n t and the hospital. INFORMATION SYSTEM FOR OPERATIONS
*From the Department of Research, institute for Anesthesiology and Intensive Care, University of Berne, Switzerland; and J-COBRA Software AG, Arlesheim, Basel, Switzerland. An address delivered on the occasion of the First Annual Meeting of the European Society for Computing in Anesthesia and Intensive Care, Goldegg, Austria, Oct 26, 1990. Received July 22, 1991, and in revised form Jan 13, 1992. Accepted for publication Mar 30, 1992. Address correspondence to Dr Zbinden, Inselspital, Department of Anesthesiology and Intensive Care, 3010 Berne, Switzerland.
In 1986 a g r o u p o f 6 representatives o f middle- and large-sized hospitals in Switzerland requested a p r o g r a m that w o u l d permit the exchange o f data between the hospitals. In 1987 the Swiss Society for Anesthesiolo g y decided to create a p r o g r a m that w o u l d m a n a g e anesthesia data immediately and intensive care data eventually and to offer this p r o g r a m to its members. A c o m m i s s i o n o f representatives f r o m these hospitals outlined the following requirements for this p r o g r a m .
Requirements FUNCTION. I S O P should p r o v i d e accounting data for administration and statistical data for hospital departments and individuals (for example, anesthetic procedures, Copyright © 1992 by Little, Brown and Company 315
316 Journal of CIinicaI Monitoring VoI 8 No 4 October 1992
complications, or operations; patient statistics by such categories as age, risk, or hospitalization class; and operating theatre statistics such as hours o f use).
CONCURRENT USE. ISOP should permit simultaneous use of the same database by multiple persons with appropriate additional logistics (e.g., record-locking).
EASEOF OPERATION. ISOP should be operated and partly maintained by laymen and provide a "help" function anywhere in the program.
PROGRAMDEVELOPMENT
COST. ISOP should be cost efficient and affordable for medium- and small-sized hospitals, with a m a x i m u m purchase price o f $7,000. DOCUMENTATION. ISOP should provide on-line documentation so that people who are unfamiliar with the program can care for the system. DATA HIERARCHY. tSOP should file data in hierarchical o r d e r - - t h a t is, by personal patient data, date o f hospitalization, and date o f anesthesia and s u r g e r y - - s o that several procedures are entered for each hospital stay (Fig 1). REFERENCE TABLES. ISOP should provide easily stored and easily accessed codes for anesthesia, material, equipment, and persons. MODULES. ISOP should organize programs and data by module so that additional functions can be easily added to the system. COMPATIBILITY. ISOP should be compatible with all standard hardware, including personal and mainframe computers.
I
I
Fig 1. Data hierarchy in ISOP. The number of branches belonging to each unit is not limited. O R = operating room; I C U = intensive care unit.
O f the five software engineering bids solicited, the one accepted had the best cost:benefit ratio and permitted the same software to run on many different personal and mainframe computers. The Massachusetts General Hospital Utility Multi Programming System (MUMPS) was chosen as the database and programming system because: 1. It was created (in 1975) for use in hospitals [1, 2]. 2. It permits a large database in a multiuser environment. 3. It is based on the ANSI standard and is compatible with many computer systems. 4. It is an interactive programming language, which reduces development and maintenance. 5. It accesses large amounts o f data quickly. 6. It manages and stores data efficiently and reduces hardware costs. M U M P S does not, however, require structured programming, and this ostensible convenience may lead to badly structured programs. In 1988 the program was installed at the University of Berne, Switzerland, in the Department o f Anesthesia and Intensive Care and was implemented on IBMcompatible personal computers and Novell Netware 386. DataTree M U M P S 4.01 was selected as the basic ISOP. It is a variation o f standard M U M P S according to ANSI ANS X>11-1988, and with the 2.0 network added, remarkable performance was achieved. D T M U M P S using the Net-BIOS (IBM Corp) interface was seamlessly integrated into the existing network o f wordprocessing, graphics, and research applications. The system was connected to the host computer with T C P / I P protocol stack by Novell. Results
The system now contains data on 60,000 patients. The initial goals o f the committee have been met, and the system is used for billing, statistics, and scheduling. It is used by the anesthesia department, surgical departments, and for some operating r o o m nursing functions. The speed o f data retrieval is remarkably constant, and does not slow d o w n even though the central server station is only an 80286 processor. The system requires little maintenance, and database upgrade is needed ap-
Special Communications: Zbinden et al: Data Management in Anesthesia
proximately every 3 months to maintain high performance. Some o f the benefits to the anesthesia department were immediate. Billing was more efficient and income improved, as was operating r o o m scheduling. Before the system was installed elective surgery was too frequently scheduled after 4 PM. Employees were unhappy and overtime costs were high. But when the computer-generated figures for personnel overtime were presented to the surgeons in 1989, there was significant cost improvement in 1990 (Fig 2). It was necessary to develop variable statistical programs to cope with the different and continuously changing needs o f users. Anesthesiologists could choose their preferred way o f selecting, sorting, and grouping their patients, as well as choosing the appearance o f their printouts. The usual training time for a new ISOP user was less than 4 hours.
in use after 4.00 p.m.
Fig 2. Theater usage by elective cases @er 4:00pro on weekdays. A reduction of overtime work in 1990 compared with 1989 is shown. E N T = ear, nose, throat.
caulJ~
lumbar epldural
~,,oreclcepidural
axill~y
] w i t h success [ ] failure ] p a r t i a l success
[ ] uni~own
Fig 3. Success rate of various types of regional anesthesia. The high proportion of "unknown" success shows the limits of selfevaluation.
317
There were, however, two serious problems: inaccurate data and missing data (Fig 3) on the survey forms returned by the anesthesiologists. The forms are used in lieu o f computer terminals for operating rooms that are so far away that it is not cost efficient for terminals to be installed. A possible reason for the missing data might be the anesthesiologists' reluctance to report failures. T h e accuracy o f the data entered by the t20 persons using the terminals has probably reached a plateau and cannot be improved. One full-time secretary enters data from 20,000 cases annually and spends 60% o f his or her time checking for missing or erroneous data. We wanted to scan the survey forms, but that approach has been abandoned. DISCUSSION Introducing these off-line systems into clinical routine was not initially welcomed by the anesthesiologists, nor were benefits perceived for the patient or the anesthesiologist. Recording data becomes increasingly important not only for billing but also for documentation. It can provide useful information for setting priorities that are necessary because o f r o o m and/or personnel restrictions. Combining a system that can provide data for anesthesiologists, surgeons, and operating r o o m nurses with a system that can provide statistics and assist scheduling will increase the acceptance for both the users and the hospital administration, which will have to pay for it eventually. ISOP was begun when PC networks were not yet sophisticated and powerful enough to accomplish the necessary tasks. Because mainframe systems were more accepted, M U M P S was chosen as a powerful and easily transferable database system. Today, PC networks have become more widespread and the disadvantages o f M U M P S have become more evident. It is still a very cheap, powerful and efficient database system, but the interfaces for both the user and the programmer appear less favorable than the currently available interfaces. Creating a system that will become a true standard remains a challenge. Although other systems with comparable functions have been described [4, 5], there is no report o f a successful, versatile standard package. Several reasons for this can be cited. First, the medical, administrative and organizational requirements vary from hospital to hospital; there are no internationally accepted coding systems for anesthetic procedures, techniques, or outcome. Second, a successful package would have to be very complex and thus very costly. Because the market for such a package is small, this task is not attractive for software engineering companies. Third, the development in the area o f hardware and
318 Journal of Clinical Monitoring Vol 8 No 4 October 1992
software is very rapid, and systems that have become established in one place over years might not appear as attractive as a new system in another place. One o f the main goals for ISOP is to update the program continuously so that it will remain a powerful and attractive package during the coming years. This goal will become even more difficult to achieve if every user makes independent and substantial changes to the software. In general, the system has demonstrated high performance and low cost for development and maintenance. With our extensive experience, however, some disadvantages have become apparent. 1. Programming can be difficult with this third-generation language--for example, when creating a good user interface. 2. Windows and mouse capability are nonexistent in ISOP because o f our decision to conform ISOP to a wide range o f hardware needs, including PCs and minisystems (although DataTree M U M P S offers window capability and mouse support, these features cannot be used with the ANSI standard). 3. Data exchange among other programs takes place only via ASCII files, and graphic exchange with other programs is not possible. 4. After considerable investment put into ISOP since we first described it, it is n o w installed in eight other hospitals in Switzerland and Germany. Unfortunately, we have not been able to create a standard program similar to one for wordprocessing, so each hospital changed or added a number o f features. This may be partly related to the highly differing organizational structures, needs, and requirements among hospitals, including: a. Varied billing systems. b. Data protection requirements that limit personnel access [2] to particular programs, data, and statistics and that demand periodic password changes. This assumes importance because o f the strict and variable laws in this area; for example, members o f one specialty are not allowed to access information related to another specialty. c. The need to extend personal statistics to specific anesthetic procedures. If, for example, one person inserted a central venous catheter and another person performed the intubation, these actions are assigned to the statistics o f each person separately. d. Specific recording o f the workload o f the various shifts. For example, the system should be able to answer the question, "What was the workload imposed on the night shift by abdominal surgery performed during the day?"
e. Statistics on complications should be improved, with more logical connections between event and complication. The two major goals for the near future are (1) connecting the intensive care unit to ISOP, which will result in an additional 27 working places, and (2) connecting the on-line recordkeeping systems o f the major operating rooms. These changes should result in a system capable o f creating complete long-term patient records. Another goal is to update the program continuously so it will remain a powerful and attractive package during the coming years. This goal, difficult as it is, will be even more difficult to achieve if every user makes independent and substantial changes to the software. REFERENCES 1. Cooper RaM, McGuire JR. Automating the Veterans Administrations' hospitals using MUMPS. Proceedings of the Xth Annual Meeting of the MUMPS User Group 1983;91-97 2. Alonso C. A case for MUMPS. Computerworld 1984;Jan: 27-32 3. Zbinden AM, Ganz M, Thomson DA, Kuster M. Entwicklung eines Informations systems f'tir Operationen. Anaesthesist 1987;36:493-500 4. Strauss PL, Turndorf H. A computerized anesthesia database. Anesth Analg 1989;68:340-343 5. Bashein G, Barna CR. A comprehensive computer system for anesthetic record retrieval. Anesth Analg 1985;64:425431
Zbinden AM, Christensen J, Kuster M. How can a standard software package for data management in anesthesia be achieved? J Clin Monit 1992;8:315-318 ABSTRACT.Collecting data for administrative, statistical, medical, and organizational purposes is becoming increasingly important in anesthesia. In 1986 the Swiss Society for Anesthesiology decided to create a program that would be compatible for different computers and would expedite data collection. The system developed was called Information System for Operations (ISOP), which was written in the database and programming system Massachusetts General Hospital Utility Multi Programming System (MUMPS). It was installed in eight hospitals and met the initial requirements, but the individual requirements of the hospitals were greatly underestimated. MUMPS has an impressive data storage capability and handling when used in a personal computer (PC) network. The user-interface, however, is inferior to other PC packages, partly because windowing and mouse support were not implemented when the ANSI standard was set. Improved statistical programs, a module for on-line data acquisition, and intensive care unit (ICU) use will be additional modules to the program. KEYWORDS.Records, anesthesia. Equipment: computers.
The practice o f anesthesiology d e m a n d s that great quantities o f rapidly p r o d u c e d data be processed efficiently for m a n y purposes, including administrative, statistical, medical, and organizational needs. T h e same data processing system for these applications could also be used for the entire hospital. If a single p r o g r a m can integrate surgical scheduling and data acquisition for an anesthesia department, maintain statistical data for other departments, and p e r f o r m administrative functions, there w o u l d be no r e d u n d a n c y o f data acquisition. T h e system w o u l d be an effective and cost-efficient p r o g r a m for both the anesthesia d e p a r t m e n t and the hospital. INFORMATION SYSTEM FOR OPERATIONS
*From the Department of Research, institute for Anesthesiology and Intensive Care, University of Berne, Switzerland; and J-COBRA Software AG, Arlesheim, Basel, Switzerland. An address delivered on the occasion of the First Annual Meeting of the European Society for Computing in Anesthesia and Intensive Care, Goldegg, Austria, Oct 26, 1990. Received July 22, 1991, and in revised form Jan 13, 1992. Accepted for publication Mar 30, 1992. Address correspondence to Dr Zbinden, Inselspital, Department of Anesthesiology and Intensive Care, 3010 Berne, Switzerland.
In 1986 a g r o u p o f 6 representatives o f middle- and large-sized hospitals in Switzerland requested a p r o g r a m that w o u l d permit the exchange o f data between the hospitals. In 1987 the Swiss Society for Anesthesiolo g y decided to create a p r o g r a m that w o u l d m a n a g e anesthesia data immediately and intensive care data eventually and to offer this p r o g r a m to its members. A c o m m i s s i o n o f representatives f r o m these hospitals outlined the following requirements for this p r o g r a m .
Requirements FUNCTION. I S O P should p r o v i d e accounting data for administration and statistical data for hospital departments and individuals (for example, anesthetic procedures, Copyright © 1992 by Little, Brown and Company 315
316 Journal of CIinicaI Monitoring VoI 8 No 4 October 1992
complications, or operations; patient statistics by such categories as age, risk, or hospitalization class; and operating theatre statistics such as hours o f use).
CONCURRENT USE. ISOP should permit simultaneous use of the same database by multiple persons with appropriate additional logistics (e.g., record-locking).
EASEOF OPERATION. ISOP should be operated and partly maintained by laymen and provide a "help" function anywhere in the program.
PROGRAMDEVELOPMENT
COST. ISOP should be cost efficient and affordable for medium- and small-sized hospitals, with a m a x i m u m purchase price o f $7,000. DOCUMENTATION. ISOP should provide on-line documentation so that people who are unfamiliar with the program can care for the system. DATA HIERARCHY. tSOP should file data in hierarchical o r d e r - - t h a t is, by personal patient data, date o f hospitalization, and date o f anesthesia and s u r g e r y - - s o that several procedures are entered for each hospital stay (Fig 1). REFERENCE TABLES. ISOP should provide easily stored and easily accessed codes for anesthesia, material, equipment, and persons. MODULES. ISOP should organize programs and data by module so that additional functions can be easily added to the system. COMPATIBILITY. ISOP should be compatible with all standard hardware, including personal and mainframe computers.
I
I
Fig 1. Data hierarchy in ISOP. The number of branches belonging to each unit is not limited. O R = operating room; I C U = intensive care unit.
O f the five software engineering bids solicited, the one accepted had the best cost:benefit ratio and permitted the same software to run on many different personal and mainframe computers. The Massachusetts General Hospital Utility Multi Programming System (MUMPS) was chosen as the database and programming system because: 1. It was created (in 1975) for use in hospitals [1, 2]. 2. It permits a large database in a multiuser environment. 3. It is based on the ANSI standard and is compatible with many computer systems. 4. It is an interactive programming language, which reduces development and maintenance. 5. It accesses large amounts o f data quickly. 6. It manages and stores data efficiently and reduces hardware costs. M U M P S does not, however, require structured programming, and this ostensible convenience may lead to badly structured programs. In 1988 the program was installed at the University of Berne, Switzerland, in the Department o f Anesthesia and Intensive Care and was implemented on IBMcompatible personal computers and Novell Netware 386. DataTree M U M P S 4.01 was selected as the basic ISOP. It is a variation o f standard M U M P S according to ANSI ANS X>11-1988, and with the 2.0 network added, remarkable performance was achieved. D T M U M P S using the Net-BIOS (IBM Corp) interface was seamlessly integrated into the existing network o f wordprocessing, graphics, and research applications. The system was connected to the host computer with T C P / I P protocol stack by Novell. Results
The system now contains data on 60,000 patients. The initial goals o f the committee have been met, and the system is used for billing, statistics, and scheduling. It is used by the anesthesia department, surgical departments, and for some operating r o o m nursing functions. The speed o f data retrieval is remarkably constant, and does not slow d o w n even though the central server station is only an 80286 processor. The system requires little maintenance, and database upgrade is needed ap-
Special Communications: Zbinden et al: Data Management in Anesthesia
proximately every 3 months to maintain high performance. Some o f the benefits to the anesthesia department were immediate. Billing was more efficient and income improved, as was operating r o o m scheduling. Before the system was installed elective surgery was too frequently scheduled after 4 PM. Employees were unhappy and overtime costs were high. But when the computer-generated figures for personnel overtime were presented to the surgeons in 1989, there was significant cost improvement in 1990 (Fig 2). It was necessary to develop variable statistical programs to cope with the different and continuously changing needs o f users. Anesthesiologists could choose their preferred way o f selecting, sorting, and grouping their patients, as well as choosing the appearance o f their printouts. The usual training time for a new ISOP user was less than 4 hours.
in use after 4.00 p.m.
Fig 2. Theater usage by elective cases @er 4:00pro on weekdays. A reduction of overtime work in 1990 compared with 1989 is shown. E N T = ear, nose, throat.
caulJ~
lumbar epldural
~,,oreclcepidural
axill~y
] w i t h success [ ] failure ] p a r t i a l success
[ ] uni~own
Fig 3. Success rate of various types of regional anesthesia. The high proportion of "unknown" success shows the limits of selfevaluation.
317
There were, however, two serious problems: inaccurate data and missing data (Fig 3) on the survey forms returned by the anesthesiologists. The forms are used in lieu o f computer terminals for operating rooms that are so far away that it is not cost efficient for terminals to be installed. A possible reason for the missing data might be the anesthesiologists' reluctance to report failures. T h e accuracy o f the data entered by the t20 persons using the terminals has probably reached a plateau and cannot be improved. One full-time secretary enters data from 20,000 cases annually and spends 60% o f his or her time checking for missing or erroneous data. We wanted to scan the survey forms, but that approach has been abandoned. DISCUSSION Introducing these off-line systems into clinical routine was not initially welcomed by the anesthesiologists, nor were benefits perceived for the patient or the anesthesiologist. Recording data becomes increasingly important not only for billing but also for documentation. It can provide useful information for setting priorities that are necessary because o f r o o m and/or personnel restrictions. Combining a system that can provide data for anesthesiologists, surgeons, and operating r o o m nurses with a system that can provide statistics and assist scheduling will increase the acceptance for both the users and the hospital administration, which will have to pay for it eventually. ISOP was begun when PC networks were not yet sophisticated and powerful enough to accomplish the necessary tasks. Because mainframe systems were more accepted, M U M P S was chosen as a powerful and easily transferable database system. Today, PC networks have become more widespread and the disadvantages o f M U M P S have become more evident. It is still a very cheap, powerful and efficient database system, but the interfaces for both the user and the programmer appear less favorable than the currently available interfaces. Creating a system that will become a true standard remains a challenge. Although other systems with comparable functions have been described [4, 5], there is no report o f a successful, versatile standard package. Several reasons for this can be cited. First, the medical, administrative and organizational requirements vary from hospital to hospital; there are no internationally accepted coding systems for anesthetic procedures, techniques, or outcome. Second, a successful package would have to be very complex and thus very costly. Because the market for such a package is small, this task is not attractive for software engineering companies. Third, the development in the area o f hardware and
318 Journal of Clinical Monitoring Vol 8 No 4 October 1992
software is very rapid, and systems that have become established in one place over years might not appear as attractive as a new system in another place. One o f the main goals for ISOP is to update the program continuously so that it will remain a powerful and attractive package during the coming years. This goal will become even more difficult to achieve if every user makes independent and substantial changes to the software. In general, the system has demonstrated high performance and low cost for development and maintenance. With our extensive experience, however, some disadvantages have become apparent. 1. Programming can be difficult with this third-generation language--for example, when creating a good user interface. 2. Windows and mouse capability are nonexistent in ISOP because o f our decision to conform ISOP to a wide range o f hardware needs, including PCs and minisystems (although DataTree M U M P S offers window capability and mouse support, these features cannot be used with the ANSI standard). 3. Data exchange among other programs takes place only via ASCII files, and graphic exchange with other programs is not possible. 4. After considerable investment put into ISOP since we first described it, it is n o w installed in eight other hospitals in Switzerland and Germany. Unfortunately, we have not been able to create a standard program similar to one for wordprocessing, so each hospital changed or added a number o f features. This may be partly related to the highly differing organizational structures, needs, and requirements among hospitals, including: a. Varied billing systems. b. Data protection requirements that limit personnel access [2] to particular programs, data, and statistics and that demand periodic password changes. This assumes importance because o f the strict and variable laws in this area; for example, members o f one specialty are not allowed to access information related to another specialty. c. The need to extend personal statistics to specific anesthetic procedures. If, for example, one person inserted a central venous catheter and another person performed the intubation, these actions are assigned to the statistics o f each person separately. d. Specific recording o f the workload o f the various shifts. For example, the system should be able to answer the question, "What was the workload imposed on the night shift by abdominal surgery performed during the day?"
e. Statistics on complications should be improved, with more logical connections between event and complication. The two major goals for the near future are (1) connecting the intensive care unit to ISOP, which will result in an additional 27 working places, and (2) connecting the on-line recordkeeping systems o f the major operating rooms. These changes should result in a system capable o f creating complete long-term patient records. Another goal is to update the program continuously so it will remain a powerful and attractive package during the coming years. This goal, difficult as it is, will be even more difficult to achieve if every user makes independent and substantial changes to the software. REFERENCES 1. Cooper RaM, McGuire JR. Automating the Veterans Administrations' hospitals using MUMPS. Proceedings of the Xth Annual Meeting of the MUMPS User Group 1983;91-97 2. Alonso C. A case for MUMPS. Computerworld 1984;Jan: 27-32 3. Zbinden AM, Ganz M, Thomson DA, Kuster M. Entwicklung eines Informations systems f'tir Operationen. Anaesthesist 1987;36:493-500 4. Strauss PL, Turndorf H. A computerized anesthesia database. Anesth Analg 1989;68:340-343 5. Bashein G, Barna CR. A comprehensive computer system for anesthetic record retrieval. Anesth Analg 1985;64:425431
