Computer--Assisted Medical Decision-Making
Computer--Assisted Medical Decision-Making
Medical Information Systems: A Resource for Hospitals
Medical Information Systems: A Resource for Hospitals
What is biomedical informatics?
Journal of Biomedical Informatics
| Hi-index | 0.00 |
As I scanned through old papers and reports in preparation for these remarks, I became depressed in the “sameness” of those proposals and descriptions with what is happening today. Then I realized there are major differences - today's systems work and are affordable.The health care delivery system is an industry whose magnitude, complexity and pervasiveness are rarely acknowledged. In a few decades, the industry has literally changed from a cottage industry to a multi-billion dollar giant with whom every individual in our society has come into contact. It is a personal industry, yet at the same time, one of our most technically sophisticated industries. It is not surprising that computers are becoming an integral part of that system. This paper discusses some of the experiences in reaching that goal.As a beginning engineer back in the 1960s, I, with many others, felt that the development of computerized patient management systems was not only natural but mandatory. One merely needs to observe the process to realize that keeping track of what was done and charging appropriately, of sending information from one place to another, of storing data and printing it on demand, and of controlling process and flow are tasks which computers perform well. Many medical specialties already used forms for the collection of data. Most medical knowledge was already clearly identified in textbooks, including what questions to ask, what parameters to measure, what tests to order, how to diagnose, and how to treat. “A simple matter of programming” was a phrase often used and believed. It later became a standing joke. Many predicted that the use of computers for medical applications would develop into a multi-million dollar market whose potential would be quickly realized. The actual events proved to be quite different.The development of patient management systems has been influenced by several factors. The first, and perhaps one of the most significant factors, is that of technology - hardware and software. During this development period, computers evolved from single tasking, “untouchable” and “unfriendly” mainframes to highly interactive, multiuser minicomputers.A second factor is that of the people involved - both the developers and the users. The developers had to learn first what to do and how to do it and then learn how to package and sell it to the ultimate user.Economic factors also influenced progress. As computer costs decreased, the cost of delivering patient care increased. Computers seem to be offer one way to reduce and control these costs.Another factor was the tremendous increase in the amount of data generated and the demand for that data by a variety of individuals. For example, both the number of laboratory tests available and the number of tests actually ordered increased exponentially during this period. Estimates on the costs of information handling vary between 25 and 39% of the total cost of health care [1]. With the influx of many research dollars from NIH, actual medical knowledge increased.Finally, the influence of external factors such as the government and third party payers contributed significantly to the development of patient management systems. As one observer commented [2], “I think that just as the Medicare legislation forced hospitals, almost without exception, to use the computer for financial processing, patient accounting, and patient billing, the PSRO type of thing - which will get built on more and more, particularly with national health insurance likely to go in within the next year - will force computerization of the clinical side of the hospital.”The digital computer became available for general use in the late 1950s. These first systems provided few user-oriented features and required considerable knowledge and skill to use. Early systems were batch oriented and supported single tasking only. These computers were large, required specially prepared spaces, and were quite expensive. In addition to machine language, followed by assembly language, only Fortran and Cobol were available as higher level languages. Most programs were written by computer specialists who had only limited interaction with those who would ultimately use the systems. The reliability of early systems left much to be desired. Hardware failures were the norm rather than the exception. Software crashes were commonplace. Perhaps life with these early systems was best described as “working with a machine you couldn't touch; working with a machine that didn't work; working with a machine that you couldn't afford; and working with systems that were not useful.”I shared office space with two cardiology fellows who seemed to spend most of their day making meticulous measurements of amplitudes and time durations of the various waveforms of the ECG. After recording these carefully on paper, they applied a set of rules to interpret the ECG readings. This task seemed to me to be a simple engineering problem which could be solved almost trivially by a computer. Unfortunately there were the problems of noise, wandering baselines, arrhythmias and PVC's, variations in patterns and other factors to solve to produce the same result as the human. Researchers quickly learned that it was difficult to teach the computer to recognize patterns which were easily identified by humans [3, 4, 5].Gordon [6] points out difficulties of attempting to overlay the computer's orderly, pedantic and, indeed, binary world with the softness, variability and “between the lines implications” of medical data under human direction - a point that is still valid. He notes that the adoption of computer technology in practice must be concerned with the customs of 200,000 physicians serving independently or in 7,000 hospitals and clinics. Changes from manual documentation to automated procedures are often bewildering and ineffective.The early development of patient management systems was supported primarily by NIH grants. Since 1968, the National Center for Health Services Research has played a major role in supporting the development, application and evaluation of patient management systems [7]. No hospital could afford a computer. Since the funding came from external sources, developers often did what they wanted to do and how they wanted to do it, rather than interfacing with users who wanted to have nothing to do with the system in the first place.Developers were consistent in their reasons for developing patient care systems. Almost all papers or proposals started with a line, “We are currently in the midst of a health-care crisis. The average cost of a hospital bed has tripled since 1957.” Systems were proposed to reduce the costs of patient care, to reduce length of stay, to improve patient care, to improve nursing care, to improve communication, and to improve decision making. Little evaluation was done. For the most part, we did what we knew how to do and wrote research papers to justify it.Melville H. Hodge sets the stage for this period in the Preface of his book Medical Information Systems [8]. He states that, in the early 1960s, a small group of hospitals became identified with one common goal, that of a commitment to serve as a site for the development of computerized handling of patient information. Some of these early hospitals include Akron Childrens' Hospital in Ohio; El Camino in Mountain View, California; Baptist in Beaumont, Texas; St. Francis in Peoria, Illinois; Charlotte Memorial in North Carolina; Washington Veteran's Administration Hospital; Henry Ford Hospital, Detroit, Michigan; Monmouth Medical Center, Long Branch, N.J.; Mary's Help Hospital, Daly City, California; Deaconess Hospital, Livingston, Indiana; Latter Day Saints Hospital, Salt Lake City, Utah; and Downstate Medical Center, New York City, New York. We owe a debt of gratitude to these early pioneers, and I might say suffering sites.Most major computer companies, such as IBM, Burroughs, Control Data, Honeywell and NCR, seeing the potential of significant sales, were active in their support. Industries experienced in using computers to manage complex systems joined in. Some of these companies include Lockheed, who supported the early development of the Technicon Hospital Information System; McDonnell-Douglas, who is still active in the field; and other companies, such as GE, who later abandoned these efforts. Most of these systems were well reported in the literature (See, for example (9,10]).Many groups in Europe were developing systems at the same time: the Danderyd Hospital [11] and Karolinska Hospital [12] in Sweden; London Hospital [13] and Kings Hospital [14] in England; and the Hanover Hospital [15] in Germany to mention a few.Unfortunately, most of these early systems resulted in resounding failures. The reason primarily for these failures and for the slow progress into the 1970s was largely due to underestimating the complexity of the information requirements of patient management systems. Furthermore, users, as contrasted to developers, were not involved at an adequate level and, in fact, were not ready for computers. Hardware and software tools were inadequate. Hospitals felt that they had been oversold an unattainable product, and, at the loss of millions of dollars, abandoned their efforts in computerization. As Hodge notes, optimism and enthusiasm was replaced by skepticism and then cynicism.Fortunately others persisted. As technology advanced, driven by the space efforts of the '60s, developers learned to appreciate the complexity of the problem and began to address smaller, more easily defined components of the overall system. A few successes appeared, although some projects failed in the transition from carefully nurtured demonstration projects into systems which interfaced with, usually, the least paid, least motivated, and least educated employees of the medical support staff.By the early 1970s, however, some of these early systems, after years of development and many more development dollars than anyone anticipated, became commercially available [16,17]. After a period of overpromise and underachievement, some progress could be noted [18].The Technicon system, begun by Lockheed in the 1960s, was installed at the El Camino Hospital in Mountain View, California and became, perhaps, the best known “successful” application. The “success” of this system in its early years at El Camino can perhaps be measured by an article in the October 1973 issue of DATAMATION [19]. El Camino was truly a guinea pig in the development of the hospital information system and suffered through the many bugs. During the first year of installation, more than 2000 changes were made to the system, many of these major changes which affected the appearance of things such as reports. Each passing day saw improvement in the attitude of doctors and nurses. In mid-1972, 66% of the doctors opposed the system. By the beginning of 1973, the majority of doctors, except for internists, favored the system. The El Camino system is perhaps one of the most thoroughly evaluated systems of any of the early development systems [20, 21]. The results of this evaluation did encourage further development in patient management systems.The ultimate success of the system at El Camino led to the spread of this and other systems into other hospitals.New crises were encountered as reduced funding from the federal government forced hospitals to decide if computerization was worth the cost and then to find the money to do it. Some hospitals were forced to abandon systems even though the systems finally looked promising.Patient management systems tend to be primarily an automation of manual processes. In 1969, Feinstein [22] noted that while computers had been applied effectively in situations where a standard mechanism already exists for dealing with the data, computers had not yet had an important impact on the more inherently clinical features of medical strategy and tactics. Many of the points made in this article are still valid criticisms of patient management systems. Schwartz [23] makes a similar point. He states that “few systems have fully explored the possibility that the computer as an intellectual tool can reshape the present system of health care, fundamentally alter the role of the physician, and profoundly change the nature of medical manpower recruitment and medical education - in short, the possibility that the health-care system by the year 2000 will be basically different from what it is today.” We clearly have some distance to go.The development of many of the components of a patient management system was driven in the late 1960s and early 1970s by interest in automated multiphasic health testing. The work of Dr. Morris Collen and his colleagues at the Kaiser-Permanente Medical Group in California [24,25] contributed to both a high level of interest in this field and in the progress of automation of tests, data collection and analysis. Dr. Collen stressed the need for AMHT systems to provide high quality testing, to provide good service to doctors and patients, and to be economical. In the early 1970s, only the first of these conditions had been met. The same could be said about other components of patient management systems.Barnett, in an article [26] in The New England Journal of Medicine, again argued the cause for computer applications in areas of medical care. He identified seven major areas in patient management systems which had made progress in development. Caceres [27] similarly reviewed the state of the art and stressed that the physician and patient care data must interact via the computer to realize automated patient management system goals.Patient management systems, to be effective, do need to become a part of the physician/patient interface. Early systems were designed partly by the scientist, partly from the business world, and very little by the practicing physician. Systems designed in our computer laboratories often had major flaws which were obvious when we introduced them into the real world. Intelligent use of computers requires an understanding of the things computers do well: quantified information, well-defined vocabulary, great speed, repetition, accuracy, and versatile control. Humans, on the other hand, communicate by speech, vision, and touch, and have an unlimited vocabulary and great adaptability. It is when the computer is applied in areas of human incompetence, that previously impossible results can be achieved [28]. Too few systems take advantage of this fact. Often we fail to realize that the computer is no substitute for intelligence. It is not a magic box which can make gold from straw.One early experience at Duke is typical of the early days. For over two years, Duke had been involved with IBM in the development of a system called Clinical Decision Support Systems (CDSS). Duke had sent several MDs to work with IBM to develop a system in which the doctor would sit down with a computer terminal, describe the patient's history, physical findings, and laboratory data, and the computer would return the diagnosis and recommend a treatment. A remote system was set up at Duke, and the system was to be demonstrated to the faculty and house staff. Before the grand opening, a few doctors sat down and entered data on patient with some “easy” problems, such as influenza or pneumonia. After an hour of conversation with the computer, the computer was no closer to a conclusion than it was at the beginning. It seems that the computer did not know of the more common diseases since they were not well defined in the literature. The decision was made not to demonstrate or implement the system.Instead, Duke then decided to develop a smaller subset of the system - the automation of the initial or screening medical history. A 19-page mark sense form was designed to be completed by the patient, processed by the computer, and be presented to the doctor in narrative form. After three iterations, the form was complete, and actually did an effective job of collecting the initial medical history. Unfortunately, the logistics of processing this form on a large, remotely located main frame computer led to itsfailure. The 19-page history was scanned by a mark sense reader and the results written on a 9-track magnetic tape. The patient's name, address, and free text data was keypunched onto cards, and the tape, cards, and program were submitted for delivery to the Triangle Universities Computation Center (TUCC), located some 12 miles away, for processing. Rarely did the tape, data, and program arrive at TUCC at the same time, and we spent most of our time trying to track down the components and get them together for processing. And when we managed that, the tape, created on one vendor's machine, could not be read on the other vendor's tape unit. The result was the history usually arrived in the doctor's hands a week after the patient had been seen. This problem was ultimately solved with a minicomputer directly interfaced to the scanner which produced the histories immediately.We tried to use what we had learned with the automated histories to develop a computerized medical record for the Division of Obstetrics at Duke. We metwith a group of physicians, argued over what parameters constituted an appropriate data base, and finally compromised by including any parameter any person felt they might use. The result was a 23 page, narrative printout for a new OB workup. Obviously, this computer program was not reducing the paper work nor helping the doctor. A quick redesign with the assistance of only one physician reduced the output to an acceptable amount; in fact, the essence of the output was reduced to approximately ten lines on the first page in a starred box. We learned an important lesson - the difference between “what I might want and what I need”.Technology produced the minicomputer in the mid-60s and removed some of the problems associated with the mainframes. The cost of these computers was around $30,000. The first of these was the LINC or Laboratory Instrumentation Computer developed at MIT and distributed to a number of system developers by NIH. This move by NIH was, in my opinion, one of the most significant events in the field of medical informatics, and really led to the development of the minicomputer industry. The LINC permitted an affordable, hands-on, real-time interaction with a computer. The minicomputer moved into the locations in which the projects were developed. The first minis were single user and had to be programmed in assembly language. The University of Washington in St. Louis developed a popular operating system which solved many of the system problems.The minicomputer opened the door for many new development in patient management including clinical laboratory systems, automated ECG systems, and ambulatory care patient record systems. Octo Barnett, at Mass General, led the way with the development of COSTAR and the programming language MUMPS [29].At Duke, we learned of the power of the minicomputer on a borrowed LINC-8 and designed a system in 1967 to createon-line surface maps of cardiac body potentials - a process which had previously been performed on a mainframe at a much greater expense of time and money. A group of us then became interested in developing a computerized medical record. Our newly-acquired Digital Equipment Corporation PDP-12 was a dream. It had a 4K memory of 12-bit words, a CRT screen which had to be refreshed under program control, two 135 kbyte DEC minitapes, 12 binary control switches, 6 A-to-D channels, and 6 potentiometers A-to-D inputs. Our first system was the Obstetrical Medical Record in which detailed data was retained during the pregnancy of some 1500 women who subsequently delivered at the Duke Medical Center. One tape would contain the records of approximately one month's pregnancies. Near the end of each month, someone was on call to change the tapes as the women came to Duke for delivery. The output was in upper case only on a teletype located just outside the delivery suite. One lesson we learned was that MDs did place value on the ability of a system to deliver information reliably as it was needed.The programs were written originally in assembly language and used the LAP-6 operating system. These assembly language programs were later converted into a programming language called GEMISCH which we use today.The PDP 12 gave way to a PDP 11/20 in the early '70s. The addition of a movable head, 1.2 Mbyte hard disk seemed to offer more storage than we could ever need. This minicomputer had 28 Kwords of 16-bit memory. We wrote a multiuser operating system which supported 7 simultaneous users using a round-robin swapping algorithm.User acceptance of computers played a major role in the development of patient management systems. The success of any innovation in a medical setting depends upon the attitude of the physicians involved. Surveys [30] indicated that physicians were reluctant to touch the keyboard of a CRT. They were doctors and “not typists”. Systems designed and introduced by physicians were more apt to be accepted than one designed by a non-MD.At Duke, we conducted one experiment which demonstrates this attitude. We asked a number of primary care physicians to look at a computer-generated medical history and a hand-written, human-generated history. The physicians overwhelmingly selected the hand-written form. We then reversed the process, taking the computer-generated medical history and coping it by hand, reformatting it slightly. We then took a human-generated history, typed it into the computer, and printed it on a drum printer so that it was obviously computer-generated. We showed these two histories to a number of physicians and again they overwhelmingly selected the hand-written form.Many worried, and perhaps justly, that computers would be over-accepted, andthe computer's “word” would become truth. In an editorial in JAMA [31], M. Southgate compares today's physician with the medicine man of a primitive tribe who consults his spirits for knowledge. To the modern physician, the computer becomes the powerful and all knowing spirit.Patients had little problem in accepting the computer as part of their health care delivery team [32]. Our own experience with using the PDP-12, certainly a rather imposing creature to a unenlightened patient, for collecting headache histories suggested that patients were less intimidated by the computer than the doctor. The adventuresome spirit of our patients was best illustrated by one incident involving a 67 year old lady. While answering questions about her headache, she would occasionally laugh. Not thinking our displays were humorous, we finally asked her what was funny. She replied that she was just waiting until the man hidden in the “computer box” would step out and greet her.The developers of patient management systems were committed to the task. Typical of that attitude is Mel Hodge: “I am a believer. I happen to believe that the problems of health care delivery are susceptible to well-considered, well-executed approaches and that the introduction of information systems technology is among the more powerful approaches available. I have invested more than a decade to my life in this belief [8].” Many of us can now say we have invested a career to this belief.Both of our speakers in this patient management systems section have contributed significantly to the development of this field. Both have been involved from the early years. Melville Hodge headed the development team which was responsible for the Technicon Medical Information System. This system was the first successful HIS which was subsequently implemented in a number of institutions and is today still a leader in the field of patient management systems.Homer Warner, with his colleagues at the Latter Day Saints (LDS) Hospital in Salt Lake City, Utah, developed a number of subsystems over this period which constitute a patient management system called HELP.The HELP system had its beginning in the late 1950s when Dr. Warner and colleagues began exploring the use of computers in the diagnosis of congenital heart disease [33]. The HELP system grew out of a group of subsystems which were designed to directly help the doctor or the nurse with specific data as relates to recognizing and dealing with specific events in a patient's illness [34]. These efforts included the goal of using the computer to enhance the decision making process [35] in the medical arena. Dr. Warner and colleagues dealt early with specific data collection, management [36], and analysis in such areas as the clinical laboratory, patient monitoring [37], and electrocardiographic interpretation by computer [38]. In the early 1970s, theseareas were integrated to use a common database. Warner describes the HELP system in a recent book [39].The Technicon system, and the contributions of Hodge, is important because it was one on the first systems which worked and was accepted. This system primarily dealt with the service-related components of a patient management system - order entry and result reporting. Contributions were made in what was done and how it was done, even though other systems did not necessarily follow exactly the same patterns. The Technicon system represents one milestone in the development of patient management systems.Warner and his group, through years of development, have added and important and necessary component of clinical involvement. By early-on collecting data, Warner and his group were able to develop their own probabilities for diseases and their relationship to signs, symptoms, and findings. Most impressive is that the HELP system is still evolving at even now represents a state of the art approach to automated patient management.These early years of development had to occur. I am always impressed that, as we became smart enough to recognize what we should do next, technology was always just available to enable us to do it. We are now entering a stage in which the tools seem to be adequate, the users seem to be receptive, the results justify the costs, and the applications seem to be useful. Perhaps we have now arrived at the point in which computerized patient management systems can change the way we teach physicians, the way we practice medicine, and the way we do medical research.