NDLI: In praise of computing

Please wait, while we are loading the content...

In praise of computing

How DENDRAL was conceived and born

Planting the seeds

Medical informatics: a personal view of sowing the seeds

History of the development of medical information systems at the Laboratory of Computer Science at Massachusetts General Hospital

The LINC was early and small

The UCLA Brain Research Institute data processing laboratory

The history of the use of computers in the interpretation of radiological images

Recollections on the processing of biomedical signals

An historical perspective on clinical laboratory information systems

Health care information systems: a personal historic review

The perception of system and the reduction of uncertainty

History of the TDS medical information system

Patient management systems: the early years

The background of INTERNIST I and QMR

Artificial intelligence in medicine: a personal retrospective on its emergence and early function

In praise of computing

Content Provider	ACM Digital Library
Author	Lindberg, D. A. B.
Abstract	I shall describe briefly some early work in applying computing systems to clinical laboratory, diagnosis, and medical records problems. If we compare the early work with what can be done now, we shall see many examples of enormous improvements in speed and power of computing techniques. A particularly striking difference in comparing 1960 with 1987 is the very much more widespread use of computing devices now and the shift in the pattern of scientific and business work to depend upon automated information systems for support of ordinary professional functions. In other words, computing systems really work now, and lots of people really use them.Let me first establish this contrast and share with you the pleasure this day brings to all of us in taking pride in these accomplishments. We should do this first, because I shall end by drawing attention to some desirable changes that have not occurred over the 25 years. The organizer of this conference, Bruce Blum, urged us to include personal remembrances, so I shall do so.My own interest in computing arose grudgingly from two requirements, one scientific and one professional. I was working under NIH support on an infectious disease problem when I moved from Columbia Presbyterian to the University of Missouri in 1960, taking my NIH grant with me. This in itself may add an element of nostalgia, since most institutions no longer permit residents to hold grants and NIH can barely fund one-third of the applications from senior faculty nowadays. In any event, my interest turned to a systematic investigation of the (then and now) poor correlation between in vitro and in vivo antibiotic sensitivity of bacteria that infect lung and blood. I did not believe (and still do not believe) that 24-hour disc-diffusion growth inhibition was a reasonable measure of the bacteria's susceptibility to antibiotic killing or growth inhibition. I reasoned that the battle between bacteria and pulmonary macrophages was probably over in 20 minutes to an hour. Hence I wanted to study bacteria growing in liquid media, with and without antibiotics. To do this I built a machine, along with a sophomore undergraduate physics student.1The observations the machine permitted gave a great deal of insight into this problem, although never the ultimate secret.2 Nevertheless we were able to prescribe therapy based on these experiments that unquestioningly cured patients with subacute bacterial endocarditis and other infectious diseases on whom others had given up. In any event, computers were necessary to process and organize the output data, and to model the processes of bacterial growth. The progression of steps we took in developing our data processing was rather pitiable in modern terms. First we learned how to wire nixie tubes to display the numbers that represented optical measurements of light scatter (hence bacterial growth) in the hundred or so test tubes that cycled past the light source. In the next version of the machine we took these signals to a Victor adding machine printer. We pasted up the tapes in rows, then read down the resulting columns to sum growth over an individual tube. Next we output the whole run to paper tape which we read into a Burroughs 205 computer. This was the beginning of wisdom, but the Burroughs was not a nice computer and paper tape was awkward. Our next step was to re-design the machine to output to a card punch so that we could process on the “modern” IBM 1620 computer. In both cases, the computers resided in “open shop” mode in the basement of the University Mathematics Department. The Computer Center Director was a half-time job held by an assistant professor of mathematics who was never given tenure. We usually processed at midnight because there would be no one to object if we vacuumed out the detritus from the tape reader.All this was quite good fun with one exception: namely, I was simultaneously supposed to be directing and supervising clinical chemistry, clinical microbiology, a section of the sophomore path class, and doing frozen sections. The biggest practical problem was getting correct reports out of the clinical laboratories and to the clinics and wards. The blackest day I can remember was when I was called to deal with the potential problem that Clinical Chemistry might not get out any of today's reports before they reached quitting time. Even blacker was the discovery that they also hadn't reported the previous day's AutoAnalyzer runs.My personal love was Microbiology. This was a well run laboratory that always got the work out. Unfortunately the report slips—which pathologists in those days personally signed—usually contained a great and imaginative assortment of spellings of the bacteriological names. This may not have actually impeded patient care, since the clinical house staff receiving them also did not spell with much precision. It did, however, allow the Professor of Microbiology to hold me and the Pathology Department up to ridicule and contumely. This academic paragon did not, of course, know that the Record Room had at all times hundreds of lab reports on which the patient names did not even match the patient unit numbers. These were not permitted to be placed in the charts, and hence were lost forever. Misspelling was only one of our problems.I made a number of managerial changes to put a temporary “fix” on the reporting problem. The next morning was the brightest day I can remember; it suddenly occurred to me that the computing system I was using for the antibiotic sensitivity experiments could be used to solve my clinical laboratory problem as well. After all, I reasoned, computer programs always spelled things the same way day after day, and the tabulating printer certainly was faster than the folks running the laboratory typewriters. In addition, I could establish limits, so that at least some of the ridiculous errors could never again be reported out and truly life-threatening findings could be identified for telephone reporting. Once one yielded to this line of thinking, it immediately became obvious that the product of the clinical labs (with the exception of the Blood Bank) was purely information: hundreds of thousands of items per year. Tables outside the programs could contain editing and limits values, pointers to other medical record elements, pricing and quality control data, etc.That day was my moment “on the road to Damascus.” I had been seriously troubled by my divided loyalties between pushing ahead in the research laboratory, while simultaneously knowing the clinical laboratory needed attention. I would then spend futile hours correcting spelling and dilutions in the clinical labs while feeling neglectful of the research. That day I realized computers were the answer to the common problem in both settings: namely, information control. From that moment forward I have been professionally happy, and committed to working out the best uses of automated information systems.The first electronic laboratory reporting system at Missouri (and I believe the first anywhere) was—as you can easily imagine—a kludge too.3,4 We could not do much better, since we did not even have a computer in the Medical School. I arranged a system of pre-punched cards, in which each card contained a line of the ultimate lab report. These were arranged in a kind of pigeon roost from which the lab secretaries composed the messages. Using punch cards on the wards on which to write the clinical order to accompany the specimen worked out well, and various envelopes kept things together during the specimen processing. Incidentally, I was astounded a few years later to see that Warner Slack at the University of Wisconsin had devised an almost identical pigeon roost to hold the cards that provided the basis for his patient history system.Getting our laboratory results printed on the wards was a problem, since there were no teleprocessing systems even if we had owned a computer. We solved this by converting the cards to paper tape, and using the paper tape to drive circuit codes into what Teletype Corporation called a “Stunt Box.” This in turn activated the print circuits to teletype Model 28 printers which we installed in linen closets at the ward and clinic locations. The whole business was slow—and incredibly noisy—but it worked. We summarized the decks of cards—at midnight as usual—in the IBM 1620. This reduced each report to an individual punched card with massive use of “over punches” into the x and y fields. Most of the resultant cards had so many illegal codes that they looked like lace doilies. An easy by-product of all this was a billing punched card for each transaction. These were interpreted and sent to the Business Office. I took considerable glee in knowing that no one in the Business Office, nor in their auditors Price, Waterhouse, had the slightest idea what to do with punched cards. Actually they read them and entered the numbers into posting machines.The only down-side effect of the new lab system was a deal I made to finance the operation. Since we were printing directly to the patient locations, I discharged 20 pretty co-eds who had been employed to deliver lab reports. That was the first but not the last time I heard colleagues say I was “destroying life as we knew it.”This old original laboratory reporting system did of course get replaced. We brought in an IBM 1410 for the Medical School and implemented what amounted to a fast turnaround batch system using punched card input and output. The memory on the 1410 was 40,000 characters; our languages were Autocoder, Fortran, and COBOL.In this system the input was written to a patient record as well as a batch print file. Consequently patient unit numbers really had to be correct. We added Modulus Eleven self-check digits to all patient numbers, persuaded the Record Room to rearrange the filing system, and persuaded the hospital administrator that all his Addressograph-Multigraph plate-stamping equipment really needed replacing in any case. Self-check digits were also used for lab reports and specimen numbers. I imagine Missouri was first here too. I have never been able to understand how American hospitals got along without self-check digits, since European hospitals use them with an even better algorithm.The 1410 system was implemented in the laboratories with a new kind of input terminal: what became the IBM 1092 Densely Coded Matrix. This was a joint development between IBM and the University of Missouri. Its original purpose was to enter size, shape, color, and cutting instructions for the garment trade in New York, but it seemed to me ideal for lab reporting. One used plastic overlays to redefine the key designations and microswitches to detect unique notches on the individual overlays.The matrix keyboard got me my NIH automation grant. We had a terrific proposal to use the 1410 to do complete lab automation integrated into hospital patient record keeping. The obvious missing piece was some kind of device to input the data. Since the new IBM matrix device—indeed the whole 1050 system—was unpatented and unannounced, I could not include these descriptions in the grant proposal. I knew this would draw a site visit. At that time Melvin Belli had just pulled off his trial scene trick of leaving the leg-shaped package wrapped in butcher paper on the courtroom desk. I took a leaf from his book and draped the sheet metal prototype of our reporting device with an Operating Room sheet at the head of the Dean's Conference Room. Essentially we were daring the site visitors to ask us to breach our confidentiality agreement. It worked. They started, but they never asked. And they approved the grant request.The 1410 system worked quite well but was replaced in time by a true on-line system once the 360/50 became available. The latter got to be a rather extensive system, including a lot of quality control, cost analysis, interpretation, etc.5 I know some of those programs ran for fully 20 years.In the course of this work the University of Missouri formed the Medical Computer Program, and I became its first director beginning in 1962. The commitment of the School to make a serious investigation of computers was made by the Dean, Vernon Wilson. He encouraged us to test the question, “Could computers contribute something to teaching, practice, and research in medicine?”, and he did this with much encouragement, advice and support. He was a really fine academic leader. I saw the task to be to create an institutionally-based information utility, to establish a multidisciplinary group including medical, engineering, and mathematical skills, and to support and encourage creative ventures in the professional services of the School and the Hospital. Gwil Lodwick in Radiology at Missouri was certainly at the head of this list. It also included computer groups in Pathology, Dietary, the Dean's Office, and subsequently Surgery, then Medicine and Pediatrics. I still believe central information groups should be institutionally-based, preferably as academic departments of their own; certainly not as service units within other departments.Incidentally computer science has not been mentioned so far because there was none. I remember vividly some years hence getting a telephone call from the Vice President for Academic Affairs at the University. He asked, “Is there such a thing as computer science? Someone wants to make a new department.” Our group had spent a lot of time convincing the Personnel people to believe in job descriptions and career ladders for computer programmers, system analysts, system programmers, technical writers, etc., so this was not so much of a leap of faith for us as for the Graduate School.Other events must be mentioned briefly. Use at Missouri of the AMA Current Medical Terminology tapes in the Consider system was really fun. We used sets of symptoms and findings from patient cases as search arguments against the AMA structured text that constituted fairly regularized disease definitions. This produced a differential diagnosis: at least diagnoses to “consider.”6 The latter were of course ranked according to disease prevalence at the University of Missouri Medical Center as reflected in its discharge diagnosis file. These searches were first done in batch mode. It was clear, however, that teaching of students and residents would be greatly enhanced if we could go on-line. We did this using the IBM 1410 at a time when IBM had not yet produced even its first cathode ray tube terminal. Our display was a Control Data Corp. CRT kludged onto the 1301 RAMAC disk controller. To his credit, the IBM field engineer showed us how to hook it up so the controller thought it had a second RAMAC unit. This CMT work has been subsequently extended by Scott Blois and his Reconsider collaborators, who have added many improvements in software services. To our mutual regret, AMA has not made comparable improvements to the data base itself.I should mention, however, that even the early version of CMT (later called CMIT) contained literature references. These were part of the tape record, even though they were not part of the printed books. This impressed upon me the tremendous power of the formal scientific literature, as well as the great scope of even the central core of medical knowledge. We frequently demonstrated the system with half a dozen excellent clinicians present, in addition to students and residents. I'm certain there never was a time when the differential diagnoses Consider produced did not far exceed the range of thinking and knowledge of the observers. Our simple reasoning that “you can't diagnose something you don't consider” was compelling then and remains so today.The Regional Medical Program must be mentioned. To me, this was a wonderful development by the Federal Government. It turned out to be short-lived, but during this period we had the privilege of testing the Caceres PHS system for EKG interpretation.7 Luther Terry was PHS Surgeon General at the time. He called to initiate the demonstration and trial. This was the first time the Caceres system had been used “in real life” outside the Federal labs. Now that I am a “Fed,” I can understand better why this was so. We tested it statewide in 22 different kinds of settings. We found it to be the most appealing and understandable of all the RMP-proffered aids to medical care. I should also note that in addition to Dr. Caceres, Hubert Pipburger from the Veterans Administration was most generous in giving me help and advice in this RMP project. I won't describe the Caceres system in detail; I hope he will do this. The bottom line scientifically is that it worked extremely well. In general practice settings, 90% of the tracings were normal; 70% from a group of three cardiologists were normal; and 50% from tertiary care hospitals were normal. Fortunately “normal wave form” was a highly reliable statement, as were many of the 150 interpretations. The statements concerning complex arrhythmias were hampered by the relatively short length of tracing then being studied. The bottom line from the point of view of health services research was that the system, with its costly data acquisition carts, transmission, and processing charges was relatively expensive for a rural area like central Missouri but an instant economic success in cities like St. Louis and San Francisco.8A turning point for me professionally came in 1971 after about ten years of directing the Medical Computer Program. We had by then fully operational information systems in clinical laboratory, radiology, dietary, business office, and an institutional integrated file that combined all these medical data with discharge diagnoses, surgical operating room records, surgical pathology and cytology diagnoses, and EKG interpretations. The Clinical literature system was laggard. We had established an SDI system for scientific journal articles and were prepared to leave the rest to NLM! I realized at the time that the future of the field and my own desires lay in research and teaching, not with hospital service systems. The Computer Program had grown from five persons and \$98,000/year in 1962 to 125 people and over \$4 million in 1970. Consequently we recruited Dr. Peter Reichertz to become director of the Computer Program, and I formed the Information Science Group. The latter has ever since been dedicated to efforts to train the cadre of scientists and health professionals that are needed to build the theoretical and scientific basis for future advances in this field.This brings me to closing on the topic, what has not happened in 25 years? Briefly, we have not seen the creation of the body of theory and principles that should underly our efforts. That we use better, faster computers and more pleasant display devices is simply due to our coupling with the aerospace and business technology evolution. More importantly, medical informatics has remained reasonably well coupled with advances in understanding of basic biomedical fields. This is a struggle: how to keep current in a technical area and in clinical medicine simultaneously. We can already see that the cutting edge research in molecular biology/ biotechnology is seriously challenging even the best people in medical informatics to make room once again for brand new ideas. Biotechnology is especially challenging because at the moment it benefits so much from mathematical computation at a time when medical informatics has half-way convinced itself it needs only symbolic reasoning.The real value of a day of retrospection such as this one must surely be to see more clearly how to progress. The day is just starting, so we must not draw hasty conclusions. Yet I'll bet we will see and hear lots of reasons today to invest in individual creative investigators, that we will see many examples of the need for an atmosphere of interdisciplinary research on topics of fundamental importance, and that we will end the day wanting scope and support for building the formal academic basis for medical informatics.
Starting Page	1
Ending Page	4
Page Count	4
File Format	PDF
ISBN	0897912489
DOI	10.1145/41526.41527
Language	English
Publisher	Association for Computing Machinery (ACM)
Publisher Date	1987-12-01
Publisher Place	New York
Access Restriction	Subscribed
Content Type	Text
Resource Type	Article

Central Library (ISO-9001:2015 Certified)
Indian Institute of Technology Kharagpur
Kharagpur, West Bengal, India | PIN - 721302

See location in the Map
03222 282435
Mail: support@ndl.gov.in

Sl.	Authority	Responsibilities	Communication Details
1	Ministry of Education (GoI), Department of Higher Education	Sanctioning Authority	https://www.education.gov.in/ict-initiatives
2	Indian Institute of Technology Kharagpur	Host Institute of the Project: The host institute of the project is responsible for providing infrastructure support and hosting the project	https://www.iitkgp.ac.in
3	National Digital Library of India Office, Indian Institute of Technology Kharagpur	The administrative and infrastructural headquarters of the project	Dr. B. Sutradhar bsutra@ndl.gov.in
4	Project PI / Joint PI	Principal Investigator and Joint Principal Investigators of the project	Dr. B. Sutradhar bsutra@ndl.gov.in Prof. Saswat Chakrabarti will be added soon
5	Website/Portal (Helpdesk)	Queries regarding NDLI and its services	support@ndl.gov.in
6	Contents and Copyright Issues	Queries related to content curation and copyright issues	content@ndl.gov.in
7	National Digital Library of India Club (NDLI Club)	Queries related to NDLI Club formation, support, user awareness program, seminar/symposium, collaboration, social media, promotion, and outreach	clubsupport@ndl.gov.in
8	Digital Preservation Centre (DPC)	Assistance with digitizing and archiving copyright-free printed books	dpc@ndl.gov.in
9	IDR Setup or Support	Queries related to establishment and support of Institutional Digital Repository (IDR) and IDR workshops	idr@ndl.gov.in