Keywords

Lindberg [111] described the evolution of the various information systems for clinical subspecialties (ISCSs) as the response to the need to keep in contact with the evergrowing mass of new medical knowledge. The rapid development of so many medical subspecialties strongly suggested that the growth of significant medical knowledge outpaced the ability of most individuals to master it. Although some of the earliest applications of computers to clinical medicine were in the clinical subspecialties, health professionals found these prototypes difficult to use since their data entry devices were awkward and inefficient, their order entry functions were not integrated, and their computer-based patient records lacked adequate standardization, so their information system did not fulfill the functional and technical requirements.

In 1968 a survey conducted for the National Center for Health Services Research and Development reported that in the United States about half of the 1,200 hospitals with more than 200 beds used computers for some business functions; but only about 15 % of these had some operational clinical subsystem or medical research computing applications [78]. Until the mid-1970s. the majority of hospitals subscribed to out-of-hospital shared computing services. In the mid-1970s, lower-cost, smaller, special-purpose minicomputers were introduced with the capabilities of being located in different clinical departments, all linked to one or more central, large mainframe computers [6]. In the mid-1970s a survey of computer applications in approximately 100 hospitals in the United States reported that only about one-third had clinical laboratory or other patient care applications [172]. In the 1980s the advent of local area networks that linked multiple lower-cost minicomputers permitted distributed information systems to be implemented in hospitals. Although information systems for clinical subspecialties (ISCSs) were some of the earliest and most advanced computer-based information systems in medicine, it was not until the advent of distributed minicomputers equipped with interactive visual-display terminals, that clinicians began to benefit from the ISCSs in direct patient care. Minicomputers allowed each ISCS to develop its own internal information system that best satisfied its own functional requirements.

1 Functional and Technical Requirements

Information systems for clinical subspecialties need to satisfy the many similar functional and technical requirements for all clinical information systems, including patient identification, registration and scheduling; and administrative and business functions. However, their clinical applications comprised a more limited domain of medical knowledge and clinical practice that varied with the clinical subspecialty and its specialized diagnostic and treatment procedures. The ISCS’s primary objective is to provide the computer processing of information in support of the direct care of patients in that subspecialty. As for any module in a system, the users of an ISCS needed to first define exactly what they wanted the ISCS to do. Since an ISCS usually operated as a referral service within a clinical department located within a larger medical information system (MIS), the functional requirements of the ISCS had to be compatible with those of the MIS and of the clinical department of which it was a part. Thus an ISCS usually has the general functional requirements to: (1) Identify and register the patient, identify the reason for the visit and for any specialized procedure requested. (2) Record the date and time, and the location of every patient care transaction. (3) Collect and store all data collected from the patient and from all procedures performed. (4) Fulfill billing and accounting procedures for all services provided to each patient. (5) Provide capabilities for data linkages to other medical sites for the transfer of patient data [37, 38, 102].

In the 1980s the advent of local area networks that linked multiple lower-cost minicomputers permitted distributed information systems to be implemented in hospitals. Although information systems for clinical subspecialties were some of the earliest and most advanced computer-based information systems in medicine, it was not until the advent of distributed minicomputers equipped with interactive visual display terminals, that clinicians began to benefit from ISCSs in direct patient care. Minicomputers allowed each ISCS to develop its own internal information system that best satisfied its own functional requirements. When lower-cost, smaller, special-purpose minicomputers that could be located in different departments and linked to large mainframe computers were introduced, separate information subsystems were developed for different clinical subspecialties within a hospital that needed to have compatible information systems technology, even though the functional requirements and the information domain were specific for the particular subspecialty, and interoperability of data was essential. Jenkin [92] pointed out that the clinical subspecialty systems, as functional parts of a MIS, do not represent separate information systems as much as they are separate knowledge bases; and the same technical information system can often function in different clinical subspecialties, even though the clinical data collected, the diagnoses made, and the treatments provided could vary.

When linked to, or functioning within a MIS, an ISCS needed to: (1) interface to an order entry (OE) module that communicated all requisitions for procedures that the patient was to receive, provided any special instructions to the patient and to relevant personnel that included the time the procedure was to be done, and noted any restrictions as to the patient’s physical activity and food intake prior to the procedure; (2) interface to a results reporting (RR) module and be able to communicate to one or more desired locations the time of completing the procedure, and the results of the procedure including any interpretive comments; (3) be able to transmit the data into a computer-based patient record; (4) support the decision-making processes involved in the patient care; (5) provide reliable and rapid turn-around services for urgent and emergency medical conditions; (6) include specific functional and technical requirements to support any unique procedures that the subsystem provides; (7) and provide the flexibility needed to meet future service requirements, adapt to changes in medical technology and knowledge, and accommodate an increasing volume and variety of procedures.

In the early 1990s distributed information systems allowed physicians to enter orders and retrieve test results using clinical workstations connected to client-server minicomputers in the local area network that linked the entire hospital. Patient data from distributed ISCS databases were integrated in a computer-based patient record. The advent of clinical workstations linked by local area networks to the clinical support services made a computer provider order entry (CPOE) program more acceptable for clinicians to use. Each ISCS had its own specialized functional and technical requirements; each evolved differently.

Requirements for the various clinical subspecialties have some important differences in their functional requirements due to differences in the clinical information processed and the different technical procedures provided to patients. In contrast to the surgery subspecialties, the internal medicine subspecialties perform primarily noninvasive procedures. The medical subspecialties include cardiology, pulmonology, endocrinology, nephrology, neurology, gastroenterology, oncology, rheumatology, physiatry and rehabilitative services, and others. The surgery specialties include head and neck surgery; eye, ear, nose, and throat (EENT) surgery; cardiothoracic surgery; abdominal surgery; orthopedics; proctology; urology; gynecology and obstetrics; and others. Pediatrics provides care to children. General medicine and family practice have the broadest domain of information, whereas urology and EENT have the most limited. Yet all clinical subspecialty systems require a uniform method for patient identification, a common data dictionary, and a communications network to enter patient data from their subspecialty or departmental databases into the central computer-based patient record. All specialty subsystems require the same degree of system reliability as that of the overall MIS; the acute and intensive care services have the highest rate of data processing and transfer, and cannot tolerate any system downtime. All clinical subsystems require the same level of security and confidentiality, except that psychology/psychiatry subsystems require even more severe requirements for security and data confidentiality protection, with the capability to lock out all other health professionals so that access to psychiatric data is permissible only to eligible psychiatrists and psychologists.

From the functional requirements developed for an information system for a clinical subspecialty, the technical design specifications had to be prepared by the system developer or by the vendor. The ISCS had to be designed to: (1) have acceptable computer terminals for entering patient and procedure data, and for reporting the results of the completed procedures; (2) provide appropriate interfaces between specialized instruments, data-acquisition equipment, and the ISCS computer; (3) include computer programs for processing order entry requisitions for services, for providing quality control measures, and for processing and reporting procedure or test results; (4) provide for a ISCS computer database adequate in capacity to store all of the patients’ data, and the information associated with and resulting from all procedures; (5) have a computer-stored data dictionary that described all tests and procedures performed, with any special instructions for conducting the procedures, and the normal and alert boundary limits for each procedure; (6) provide communication links to the information systems in affiliated medical offices and hospitals from which the patient came, and also provide links to any needed external databases; (7) provide a reliable computer system with an uninterruptible power supply; (8) have a flexible information system design that could meet changing and expanding requirements for technical and medical innovations; and (9) employ a vocabulary of standard terms to facilitate exchange of information with other information systems.

Since the exchange of clinical data between different databases required the use of standard terms, in 1983 standards for the transmission of clinical data between computers began to be developed [124]. The proposed standards addressed what items of information should be included in defining an observation, what data structure should be employed to record an observation, how individual items should be encoded and formatted, and what transmission media should be supported. Formal attempts to improve the standardization of medical information were carried out by collaborating committees, including the subcommittees on Computerized Systems of the American Standards for Testing Materials (ASTM) that is the oldest of the nonprofit standard setting societies and a standards-producing member of the American National Standards Institute (ANSI) [153].

The ASTM technical subcommittee E31.12 on Medical Informatics considered nomenclatures and medical records [61]. In 1988 ASTM’s subcommittee E31.11 on Data Exchange Standards for Clinical Laboratory Results published its specifications E1238 for clinical data interchange, and set standards for the two-way digital transmission of clinical data between different computers for laboratory, office, and hospital systems; so that, as a simple example, all dates would be recorded as an eight-character-string, YYYYMMDD. Thus the date January 12, 1988 would always be transmitted as 19880112.

Health Level Seven (HL7), an organization made up of vendors, hospitals, and consultants was formed in 1987 to develop interface standards for transmitting data between applications that used different computers within hospital information systems [165]. The message content of HL7 was to conform to the International Standards Organization (ISO) standards for the applications level 7 of the Open Systems Interconnection (OSI) model. The HL7 standard used the same message syntax, the same data types, and some of the same segment definitions as ASTM 1238 [123]. The Medical Data Interchange (MEDIX) P1157 committee of the Institute of Electrical and Electronics Engineers (IEEE), formed at the Symposium on Computer Applications in Medical Care (SCAMC) in 1987, was also developing a set of standards, based on the ISO application-level standards, for the transferring of clinical data over large networks from mixed sources, such as from a clinical laboratory and a pharmacy, for both intra- and inter-hospital communications [154]. Every ISCS had to accurately identify each patient; and link or integrate all patient data and reports that were collected on that patient. ISCSs located within a hospital or its associated clinics usually used the same patient identification (ID) number that had been assigned to the patient on the first outpatient visit or admission to the hospital; and that same patient’s ID number was recorded for each and all subsequent services received by that patient.

2 Internal Medicine

In 1959 the evolution of ISCSs began when Schenthal [158, 159] and Sweeney at Tulane Medical School, used an IBM 650 computer equipped with magnetic tape storage to process medical record data for their internal medicine office patients. They used a mark-sense card reader that sensed marks made with high-carbon content pencils on special formatted cards. The marks were converted into punched holes in standard punch cards. They read these punched cards into the computer, which then processed and stored the data for the clinic’s physicians. Internal medicine requires a relatively broad domain of medical knowledge, so internists often limited their practices to the internal medicine subspecialties of cardiology, rheumatology, endocrinology and metabolism, diabetes, pulmonology, nephrology, oncology, geriatrics, and others.

2.1 Cardiology

Cardiology information subsystems were developed to support the care of patients with heart disease; provide computer-based patient records; collect data from computer-supported cardiac catheterization procedures; generate diagnostic cardiac stress-test reports; and furnish computer interpretations of electrocardiograms. Starting in the mid-1960s, Warner and associates at the LDS Hospital in Salt Lake City applied their cardiovascular research computer to provide a cardiology information system for patient care. By the mid-1970s their data input programs used for cardiology patients included admission data, a self-administered history, clinical laboratory test-results, blood gas laboratory data, spirometry and pulmonary function data, electrocardiographic data, pharmacy records, and catheterization laboratory data [34]. Their cardiology system functioned as an integral component of their cardiac catheterization unit and of their intensive care unit (ICU), and integrated its patient data into the LDS HIS.

In the late 1960s, Crouse and associates at Stanford University reported the use of their Advanced Computer for Medical Research (ACME) by their Division of Cardiology to analyze online cardiac catheterization data for diagnostic purposes. By 1974 this cardiac catheterization system was reported to have a simplified user interface, flexible data-sampling sequence, immediate display of results of computer analysis for physician review, and hard-copy output of computer measurements [1]. In 1969 the Division of Cardiology at Duke University Medical Center in Durham, North Carolina, began to collect data on patients hospitalized with coronary artery disease. The information collected included each patient’s history, physical examination data, and the results of laboratory and diagnostic tests and of cardiac catheterization. Users entered data from cardiac catheterization by using a coding algorithm that displayed a series of questions, and the user entered the responses. A total of ten keystrokes was used to describe the coronary artery anatomy of a patient. The database was used in their clinical practice to provide automated reports of the testing procedures and results, and to provide diagnostic and prognostic profiles of new patients based on their previous experience [145]. These data on cardiac catheterization results and patients’ outcomes were aggregated into the Duke Databank for Cardiovascular Disease and used to support clinical research in this field [146].

In 1970 the Cardiovascular Clinic in Oklahoma City initiated an office information system (OIS) for six physicians providing care for about 14,000 cardiology patients. This system included medical records, patient scheduling, and business office functions. On entering the clinic, the patient completed an automated, interactive, branching, self-administered medical history. The physician then completed an encounter form containing physical examination findings, patient’s symptoms, medical problems, and diagnoses all focused on the cardiovascular system. Using a video display terminal with keyboard entry, clerks entered the data from the encounter forms into the computer. For follow-up clinic visits, appropriate information was added using additional encounter forms. This OIS was entirely funded by the clinic; the PDP-15 computer and its software were acquired from Meditech [64, 204].

For the care of ambulatory hypertension patients, a Data General Nova computer, with CRT terminals for data input and retrieval, was programmed to provide algorithms to support a non-physician practitioner’s clinic at the Naval Regional Medical Center in Oakland, California. It was used to maintain a computer-based patient record for more than 2,000 office patients with hypertension. Patients completed a self-administered questionnaire form at the initial visit. Nurse practitioners and hospital corpsmen completed a physical examination, and recorded the patient’s blood pressure and other findings. All the data were entered into the computer, which provided printout reports. Using computer-directed therapy algorithms, the paramedical staff maintained a large hypertensive population with a satisfactory degree of blood pressure control in the majority of patients [80]. Whenever abnormalities were evaluated by the nurse practitioners to be significant, a physician would be called in to see the patient. An evaluation of the first year’s experience showed that the operational costs of the computer-supported clinic were 13 % less than those for their general internal medicine clinic, primarily due to a 25 % savings in physicians’ time.

Similarly, in the hypertension clinic at the Wayne State University Medical School in Detroit, a nurse practitioner provided full services to patients being treated for hypertension. The nurse used forms to record data for entry by key punch to a time-sharing computer. For follow-up visits, using a CRT display terminal, the nurse could access the computer-stored patient record to enter new data, to retrieve prior data, to query the clinical laboratory file for test results, and to generate flow sheets of blood pressure and clinical laboratory data. In their first 30 months of operation the clinic processed almost 8,000 office visits [104].

2.2 Pulmonology

Pulmonary diseases require special pulmonary function studies that are greatly facilitated by computer analysis in a special pulmonary function laboratory that can provide a variety of procedures to quantify patients’ breathing deficiencies. In 1964 a group of investigators led by Caceres at the Heart Disease Control Program at the Department of Health, Education, and Welfare developed a method for computer analysis of pulmonary function curves. Using an analog-to-digital converter, they digitized the vital-capacity curves obtained from a spirometer to provide values for 1-, 2-, and 3-s measures of volume and expiratory air-flow rates; and the capacity of the lungs to diffuse oxygen from the pulmonary alveoli into the blood capillaries, and to diffuse carbon dioxide from the blood back into the lungs. Patients with severe pulmonary insufficiency could accumulate an excess of carbon dioxide in their blood, which disturbed their blood acid-base balance and produced respiratory acidosis [164].

In the late 1960s, Osborn’s group at the Pacific Medical Center in San Francisco began to develop their pulmonary function monitoring system. In 1974 they reported the use of the data obtained from the pulmonary function tests and the cardiac catheterization procedure done on patients before and after surgery, along with chest x-ray reports and clinical laboratory tests. This helped to determine when patients on automated ventilation following cardiac surgery could be weaned from the respirator and returned to spontaneous breathing [79]. By the mid-1970s Caceres’ laboratory was providing a service to other providers. Providers would submit the required data and in return would receive patient’s vital capacity and ventilation measurements, plus gas analysis and arterial blood data, before and after exercise. The computer generated a printout that showed the patient’s values for ventilation, diffusion and gas exchange, and blood gas measurements; the printout also compared the patient’s values to age- and gender-specific normal ranges [152].

Spencer and Vallbona at the Texas Institute for Research and Rehabilitation (TIRR) in Houston provided arterial blood-gas analysis in their respiratory center for patients with respiratory insufficiency. They developed a computer program that assisted the technician in the automatic calculation of blood pH, blood gases, and acid-base balance; and provided the physician with an automatic interpretation of the results as well as with recommendations on the treatment to correct acidosis if present [200]. Menn et al. [128] described the clinical subsystem for the respiratory care unit at the Massachusetts General Hospital (MGH), where the data on the patient’s medical status were entered into the computer in a conversational interactive mode. The clinician entered the patient’s data by replying to a series of questions with “Y” (yes) or “N” (no), or the numerical value. Additional data were entered concerning arterial blood gases, the patient’s state of consciousness, and certain laboratory test values. The computer then printed out a summary of the patient’s respiratory data in a tabular form, with an interpretation of the information.

In the 1970s more advanced techniques were available to provide pulmonary function tests, such as were instituted in 1976 at the University of Nebraska Medical Center. That computer-based system, written in FORTRAN and using a PDP 11/03 computer, processed patient data to provide lung volumes, breathing mechanics, diffusing capacity, arterial blood gases, and capillary blood volume [65]. Similarly at the Veterans Administration (VA) Medical Center in Washington, DC, a pulmonary function test was written in the MGH Utility Multi-Programming System (MUMPS) language, and used a PDP 11/34 computer to process pulmonary function and arterial blood-gas data. A printed report with test results and an interpretation of the test data was produced in letter form for transmission to the physician [95]. By the late 1980s spirometry test modules for office information systems (OISs) were available to permit physicians in their offices to conduct pulmonary function tests, to store the data in the patient’s OIS record, and to complete the test reports while the patient was still in the office for the immediate consideration of diagnosis and treatment [135].

2.3 Nephrology

Kidney diseases in patients often require long-term care ending with renal dialysis. Pryor et al. [147] employed the HELP system at the LDS Hospital in Salt Lake City, and reported that its nephrology information system assisted in planning the management of patients with end-stage renal disease. The program gave advice as to the best mode of dialysis (either hemodialysis or peritoneal dialysis), best location (home dialysis versus hospital dialysis), and best treatment (dialysis or kidney transplant).

In 1977 Stead and Hammond [179] began to use an OIS when treating patients with kidney diseases in the nephrology service at the VA Medical Center in Durham. Developed at the Duke renal outpatient clinic in 1977, the system was written in the GEMISCH language and operated on a DEC PDP-11 minicomputer with a display terminal and printer available in the clinic area for interactive data entry and printouts. The system stored in its computer-based records the patient’s demographic data, a medical problem list, and a time-oriented summary of subjective and physical data, laboratory and therapeutic data. Data was collected from the physician, nurse, or technician using either computer-generated paper encounter forms, or interacting with a video terminal where the data could be displayed graphically [182]. By 1980 the Stead-Hammond nephrology service was responsible for over 300 active patients. About one-third of these patients required renal dialysis therapy. The initial transfer of legacy medical data from the old paper-based charts to the computer-based records involved the extraction by the physicians of selected information for up to two prior years of care, and averaged 1.5 h per record for about 200 patients. The clinical acceptability of the computerized records was judged to be 93.2 % [62]. In 1981 the computer record was the only record used for a patient’s encounter with the nephrology service. The physician could supplement the record with textual notes, either handwritten or entered as text into the computer record. The intensity of data collection on the nephrology service was indicated by the facts that these patients were seen as often as three times a week. The patients had an average of 11 medical problems, at least 18 laboratory tests were performed every 1–4 weeks, and each patient took an average of nine different medicines [180, 183]. It was from Stead’s and Hammond’s experiences with this subsystem that they went on to develop their TMR system.

Pollak and associates [142] at the University of Cincinnati Medical Center reported a nephrology system for inpatients with acute and chronic renal diseases; their patient care included renal transplants, renal dialysis, and outpatient follow-up. They developed a time-oriented record similar to that used by Fries for his rheumatology clinic. They used a program written in BASIC+, for a PDP 11/70 computer. Visual display terminals were located in the clinic for ambulatory patients and in the hospital for the care of renal patients admitted for kidney transplants or other reasons. Data were entered using the display terminal keyboard. Visual display terminals permitted access to the system over telephone lines protected with password security. Data were entered in a conversational mode, and the computer prompted the user for items to be entered. Each data item was coded in their data dictionary. A single patient’s daily, time-oriented, data could be entered in 2–4 min, depending on the number of items; up to 11 different visits, usually the most recent, could be displayed simultaneously. Computer printouts supplemented the paper-based patient record. The first page of their computer-based record system contained a problem list that displayed a continuous summary of major clinical events and problems. Flow sheets displayed time-oriented data, and the progress notes recorded the serial interpretations of the data.

In 1983 Levy and Say [109] at the Henry Ford Hospital in Detroit, described their large nephrology information system for five clinics that provided 10,200 patient visits per year. These clinics used a central IBM time-sharing computer system with telecommunications that supported, in the clinics, light-pen visual display terminals and printers for data entry and information retrieval. Although this was primarily a batch-processing operation, online data entry and retrieval of reports were obtainable. A single patient’s daily, time-oriented data could be entered in 2–4 min, depending on the number of items; up to 11 different visits, usually the most recent, could be displayed simultaneously. Levy and Say chronicled their 8-year experience and described the many lessons learned in implementing their vendor-provided system. The first vendor went bankrupt after completing only 30 % of the system; and the authors concluded from their experience that implementing a nephrology dialysis subsystem could be almost as difficult as installing a medical information system.

2.4 Metabolic

Metabolic disorders occur in patients with a variety of diseases; they appear as disorders of body fluids electrolytes and acid-base balance, and as abnormalities of nutrition. The assessment of metabolic disorders required a complicated set of calculations. In 1968 Vallbona et al. [199] at TIRR first reported using their computer to support calculations of doses of medications, and of fluid and electrolyte requirements of such patients. The tabular printout of the fluid-balance report provided calculations of water, glucose, sodium, and potassium requirements; and recommended parenteral fluid therapy for a 24-h period to meet the calculated requirements. The computer process took into account the data obtained on the patient including specific gravity, blood urea nitrogen, and an estimate of the patient’s dehydration by the physician.

Bleich [16] at the Beth Israel Hospital in Boston wrote a program in the MUMPS language that asked the physician to enter the values obtained for the patient of the serum electrolytes, carbon-dioxide tension, and hydrogen-ion activity. The computer then evaluated the patient’s acid-base balance, recommended appropriate therapy, and cited relevant references. Bleich [17] soon reported that the program had been used about 1,500 times. With the later implementation of the Beth Israel hospital information system (HIS), the electrolyte and acid-base program automatically obtained clinical laboratory data from the HIS; it then directed a dialogue in which the physician supplied clinical information; upon completion of the interchange, the program produced an evaluation note that resembled a consultant’s discussion of the problem [156]. Kassirer and associates [97] at Tufts University School of Medicine in Boston described an integrated information system that was programmed for reading and punching into cards the data from an automated chemical analyzer and from other laboratory equipment; using these data supplemented by the patient’s weight and urine volumes, the program completed the required calculations and printed out the final and full fluid balance study. Thompson [192] wrote a program in the BASIC language using a Radio Shack TRS handheld, pocket computer designed for nurses to monitor total parenteral nutrition. A series of displays directed the nurse to enter the quantities of urine output, and of the fluids and nutrients that the patient had received during the 24-h period. The program then calculated the patient’s fluid balance, caloric intake, percentage of calories provided by each energy source, nitrogen balance, calorie ratio, and catabolic index.

2.5 Endocrine

Endocrine disorders are common and include diabetes mellitus, obesity, and thyroid disorders. In 1964 a diabetes clinic was developed at the University Hospitals of Cleveland, Ohio, by Levy and associates. They used encounter forms for recording patients’ data. The data were then keypunched into cards, which periodically were read into the computer and stored on magnetic tape. Printed reports of the patient records were available prior to a follow-up visit. In 1964, 209 patients had their records in the system. In 1973 McDonald’s Regenstrief Medical Record (RMR) system initiated its diabetes clinic, which evolved to provide a comprehensive ambulatory care system that served as one of the model office information systems (OISs) in the United States [125]. In the mid-1970s, an OIS for patients with diabetes mellitus became operational and was reported by Thomas and Moore [191] in the diabetes clinic at the University of Texas Medical School in Houston. Using paper encounter forms and keypunched cards for data entry, they provided services to 500 patients who received continuing care that resulted in voluminous medical records. After 4 years of experience with 6,000 patient visits, the contents of the records had evolved to entering only the significant data necessary for each physician to make medical decisions in this clinic; and they had developed algorithms that selected, for their routine office practice, about 20 % of the data specific to diabetes and its complications.

By the early 1980s, OISs in diabetes clinics were using display terminals with keyboard entry of data to microcomputers [63, 195]. Lomatch and associates [112] at the University of Michigan, used a relational database system to collect information on 1,200 patients with diabetes to monitor their care and to support clinical research in diabetes. By the end of the 1980s a fully interactive diabetes management system on a personal computer was reported by Zviran and Blow [212] at the Naval Postgraduate School in Monterey, California. It provided a computer-based patient record, a log display of trends of the patient’s blood glucose levels, decision support reminders as to diet and exercise, and instructions with a dictionary of common terms for patient education.

2.6 Rheumatology

Rheumatology and immunology services were initiated in the late 1960s by Fries at Stanford University Medical Center using their Time Oriented Database (TOD) System to collect data over long-time periods on their patients who had chronic arthritis. The objectives of their OIS were to support both patient care and clinical research and to provide a research database. In the 1970s the Stanford group joined with other rheumatology centers in the United States and Canada to form the American Rheumatism Association Medical Information System (ARAMIS), which became a model for national chronic disease research databases [59, 60]. By 1974 this clinic served 900 patients with 4,000 visits per year; most of the patient data were stored in the immunology and rheumatology OIS [77]. At this time in its development, computer time-sharing services were obtained from the Stanford University Center for Information Processing, which maintained the software for TOD, which was also used by other Stanford medical services. Patient data were collected by physicians, clerks, and technicians on formatted pages and on flow sheets with tabulated data. Then the data were entered into the computer by using modems and telephone lines. The paper-based patient record remained the primary medical record; the computer-based patient record provided backup and was also the research database. The medical record contained patient identification, medical history, a problem list, treatments specific to rheumatology and immunology, and selected follow-up data. The system permitted retrieval of the complete computer-stored patient record, or an abstract of the last visit. Statistical analysis of the data with scatter plots and bar graphs were available. Computer-generated prognostic summaries of patients’ records could be obtained that selected a population comparable to the patient, and displayed the group experience as to morbidity and mortality. A password system controlled user access to the system. Administrative and business functions for the clinic were provided by other Stanford systems. According to [77], the development of this OIS involved about eight person-years of effort at an estimated cost of $100,000. Fries’ system was so successful that it became the basis for ARAMIS, a national database for rheumatoid diseases.

2.7 Neuromuscular

Neuromuscular and locomotor disabilities in patients were often treated in specialized rehabilitation services. Spencer and Vallbona [171, 173] at the Texas Institute for Research and Rehabilitation developed a HIS for a specialized hospital that provided rehabilitation services. As early as 1960, they reported the use of electronic data processing techniques in the description and evaluation of disabilities in their patients. They placed data pertaining to the patient’s physical activities and functional limitations on a punch card. Records of treatments and exercises, and other routine HIS data, were also added. By 1969 they had computer programs that could suggest plans of care and specific treatments for disabled patients, and a computer model for the prediction of recovery of muscle strength in patients with paralytic disease [196]. By the early 1970s, they used a set of programs in which therapists evaluated and graded 94 muscle groups of the patient. A computer algorithm then computed the total score for different body parts as well as for the whole patient. The system generated a report that represented the patient’s ability to perform the basic tasks related to normal living. It also provided a profile of the disability for each patient that described the primary pathology with its related impairments and complications, and any operative procedures performed [198].

In the early 1980s, bioengineers began to interface microprocessors with electromechanical devices to aid severely physically handicapped people. Sanders and associates [157] at the Georgia Institute of Technology devised a system using a personal computer (PC) interfaced with a robot arm. Commands could be entered by (1) touch selection with a finger, or with an instrument held in the mouth, from a display of numbers; or (2) words spoken to a speech-recognition unit with a 200-word vocabulary. The robot arm could turn pages, pick up a cup, dispense medications, operate an electric bed, and turn on a radio or television. By the end of the 1980s computers were providing increasing independence to physically handicapped persons. Quadriplegics could operate wheelchairs controlled by microprocessors. The hearing impaired could use a computer-based, electromechanically powered, aluminum hand that could engage in sign language and finger spelling, and provide their interpretations [66].

2.8 Oncology

Oncology information systems for patients with cancer required a wide variety of hospital medical, surgical, chemotherapy, and radiation services. One of the earliest, large, oncology information systems was developed at Johns Hopkins Hospital (JHH) that provided comprehensive care to adult cancer patients in a 56-bed oncology center that also served 500 outpatients per week [20]. In l970 at the Johns Hopkins Hospital (JHH), a prototype information system was initiated to process physicians’ written orders, produce work lists for ward nurses, and generate daily computer-printed, patient drug profiles for the patients’ records. In 1975 a Minirecord (minimal essential record) system was initiated in the JHH Medical Clinic that used encounter forms that were filled out at each patient visit; and they contained an area for medications and procedures [119]. Work also was begun on a prototype Clinical Oncology Information System (OCIS). The OCIS contained patient care data for both hospital and clinic services, and also captured clinical laboratory test results and pharmacy data [19, 20, 22].

In 1976 a radiology reporting system was implemented at JHH using a terminal that permitted the radiologist to select phrases with which to compose descriptions and interpretations of x-ray studies. Its output was a computer-printed report which became available as soon as the radiologist completed his interpretation [202]. In 1978 a clinical laboratory information system was operational; it provided the internal working documents for the laboratories, and produced the patient’s cumulative laboratory report [94]. During the early 1980s, a network gradually evolved in the JHH information system. By 1986 the JHH system included IBM 3081 and 3083 computers that supported an inpatient pharmacy system with a unit dose medication distribution system, a clinical laboratory system which ran on three PDP 11/70 computers, and a radiology system [194]. At any one time, 2,000 patients were being treated with one or more of several hundred established treatment plans called oncology protocols. Their prototype Oncology Clinical Information System (OCIS) used a remote computer located at the Johns Hopkins Applied Physics Laboratory. It also operated a tumor registry that ran in batch mode and was used for searches, tumor reports, abstract preparation, and quality assurance.

In 1976 JHH purchased a PDP-11 computer with a MUMPS operating system [20] to support the development of a larger system for their Oncology Center. By 1979 their enhanced OCIS organized the clinical data to produce plots and tabulations that assisted in decision making. Since they often collected as many as 100 different clinical and laboratory values for a single patient each day, it was useful for the data to be organized in the form of plots and flow sheets (time-sequenced tabulation of data) to assist physicians in handling large amounts of data [25]. In addition daily care plans were implemented, with protocols (treatment sequences) processed by their OCIS that provided printed plans for ordering tests and procedures, with warnings and reminders of potential adverse clinical events.

Because of the complexity of the treatment plans for many cancer patients, much of the therapy followed predefined protocols that often involved the use of anti-tumor drugs in multi-drug combinations and administered using complex time-sequenced relationships; and therapy that could extend for months or years [24]. A daily care plan generally contained patient status data, summary of therapy protocols, treatment sequence-generated comments, tumor measurements, clinical findings, chemotherapy orders, history of chemotherapy administered, and tests and procedures [121]. In 1979 JHH acquired a second computer and a new programming tool, TEDIUM, was used to provide database management system functions, and the old MUMPS-based system was retired in 1982 [108]. The two computers were linked with distributed database software, and a direct link was made to the computer system in the department of laboratory medicine so that all test results were transferred automatically to the OCIS.

The computer also supported an oncology center pharmacy with a common database. Blum [23] reported on the data model, which described their database at that time, as containing patient identification data, patient clinical data, patient protocol assignments, patient standing orders, patient recommended orders, treatment sequence, clinical actions (such as tests and procedures), and protocol-descriptive text and flowchart schema that defined the protocols. Since the system now managed a large and comprehensive database, they implemented an enhanced system that provided the tools to manipulate the database for retrospective analysis. Online access was provided to the data required by the health care team by means of a summary abstract that contained identification and administrative data; and for each primary tumor site, the diagnosis, a summary of treatment, and a summary of the pathology report. Clinical data were displayed as a chronological tabulation for a specifically defined time period.

These flow sheets presented the desired data in columnar format, according to the date the data were collected. In addition, graphic plots were provided when a display was desired of changes in data through time. Daily care plans were designed to assist the physician who treated many patients over long periods of time using complex treatment modalities in both an inpatient and an ambulatory setting. Patients treated for their cancer, as well as for other disease or therapy related medical complications, often followed one or more predefined protocols that detailed treatment sequences. A daily care plan provided printouts for each patient every day, with changes resulting from the entry of new orders [23]. The cumulative OCIS database permitted increasingly useful analyses to aid physicians in making clinical decisions and to evaluate the clinical management of cancer patients [106, 107]. In 1986 they reported the active use of 125 formal cancer therapy protocols [22]. Blum [21] published a historical review of the development of the OCIS at Hopkins; and Enterline and associates [52] reviewed its clinical applications. McColligan [118] reported that the Hopkins OCIS had also been implemented in 1989 at Ohio State University’s Cancer Hospital. Friedman [58] and Horwitz [83] and associates at the Boston University Medical Center described Cancer Data Management System (CDMS), which operated on a PDP-11 computer with a MUMPS operating system. Their CDMS provided the functions generally necessary for the care of cancer patients, including computer-generated medical records, and supported their oncology research. Serber and associates [162] at the Memorial Sloan-Kettering Cancer Center, New York, also implemented an information system for clinical oncology using a Data General Eclipse C330 computer and MUMPS programming, designed largely to support research. Marciniak and associates [116] at the National Cancer Institute in Bethesda and the VA Medical Center in Washington, DC, reported on the activities of VA hospitals tumor registry using their HIS; they cited the use of the VA File Manager program by the MD Anderson Hospital in Houston for their protocol data management system. In the mid-1980s, the National Cancer Institute made Physician Data Query (PDQ) available, a cancer information database of active oncology protocols, accessible to hospital cancer units through the NLM’s MEDLINE [84].

2.9 Gastroenterology

Gastroenterology patients were treated by Kahane and associates [96] at JHH who employed a clinical workstation that permitted them to use a variety of data input methods, including voice-recognition technology, to record observations made of the inner surface of the gastrointestinal tract during endoscopy.

2.10 Geriatrics

Elderly patients received care in an ambulatory clinic with an OIS specially designed in 1988 for their care in the VA Medical Center in Tacoma, Washington, and appropriately called GRAMPS (Geriatric Record and Multidisciplinary Planning System). This interactive MUMPS-based application operated off of the VA’s File Manager-based record system. It allowed physicians to document patient care in a problem-oriented format with structured narrative and free text, eliminating handwritten input [73]. Sets of data were developed for 38 geriatric syndromes that could be displayed as menus for data selection to facilitate data entry.

3 Surgery, Obstetrics, and Gynecology

Surgery specialties have administrative and business requirements for their patients similar to those for the medical specialties. However, the clinical data collected by neurosurgeons, head and neck surgeons, chest surgeons, abdominal surgeons, obstetricians, gynecologists, and urologists are more limited to office surgery procedures and to pre- and postoperative follow-up care of patients whose surgical procedures had been performed in the hospital or specialty surgery clinics. Surgery specialties in a hospital are characterized by their application of invasive procedures, which usually require specialized technology. In addition to the general information processing requirements similar to those for any HIS department, surgery services require records of anesthetics given and detailed reports that document the operative procedures. The operating room is the basic workshop for the surgeon, and each surgery specialty requires some equipment in the operating room tailored to its needs.

3.1 Operating Rooms and Surgicenters

The operating room is an expensive resource in the hospital [13], so the operating room supervisor is continually challenged to improve its efficiency. Most operating rooms are busiest in the morning; some rooms are often idle in the afternoon, so optimal scheduling of operating room staff can significantly affect hospital costs. As early as 1968, Barnoon and Wolfe [10] developed a computer simulation model to test the effectiveness of various configurations of schedules by analyzing the use of its facilities and manpower. Ausman and associates at Roswell Park Memorial Institute began to use precoded operative record and report forms on which the surgeons noted the appropriate information after completing an operation [3, 4]. Clerks transferred the codes to punch cards; these were read into an IBM 1401 computer that stored the data on magnetic tape that generated printouts for insertion in the patients’ charts. Michas and associates [130] at the University of California in Davis reported that their surgery services were using a special form to record patient’s diagnoses, operative procedures, and other relevant data, which were then typed onto magnetic cards using the IBM Magnetic Card/Selectric Typewriter (MC/ST). The data on the cards were then transmitted to a time-sharing mainframe computer that stored the data, and provided printout reports for the patients’ charts. Brown [27], at the University of Michigan in Ann Arbor, wrote that since 1976, for each patient undergoing a surgical operation, clinical data had been collected, punched into cards, and computer processed. Yearly data were abstracted from the surgery database, analyzed, and compared to the prior year’s data to improve operating room scheduling and utilization.

In the 1970s the appearance of free standing surgical centers for ambulatory patients generated a need for their information systems to provide hospital-type patients’ records, including any laboratory, x-ray, and pathology data as well as to maintain extensive records of the surgeons, of the anesthesiologists, and of the insurance carriers. As an example, the Salt Lake Surgical Center reported providing services to 500 patients per month using four operating rooms; and maintained a computer-based patient record on a Texas Instruments minicomputer that was accessed by eight visual display terminals. Their computing applications included interactive preoperative scheduling of surgical procedures, and storing the scheduled procedure codes. Also included were patients’ preoperative diagnoses, identification of the surgeons and referring physicians, and the type of anesthesia to be given. Data stored on postoperative patients included the code number of the actual procedure performed, length of time of the procedure, the anesthesia given, and any postoperative complications. Pre- and postoperative instructions for each patient were personalized and were printed out by the computer [99].

Computerized Operating Room Management System (CORMIS) was developed by Nault and associates [137] to assist surgery personnel in scheduling and staffing, as well as in using operating room facilities. Data were collected on forms and keypunched into cards for time in and out, by procedure, for surgeons, anesthetists, and surgical nurses. Any causes for delay also were noted. A time-sharing computer service then prepared summary reports for scheduling and staffing requirements. Schmidt and associates [160] at the University of Michigan Hospitals in Ann Arbor described a computer model for predicting a surgeon’s operating room time for a specific scheduled procedure based on 5 years of experiential data stored in their hospital’s mainframe computer database. Other investigators developed computer programs for operating room scheduling. Hancock and associates [74] at the University of Michigan divided their experiential database into many subsets to improve the reliability of predicting the operating room time to be scheduled for a specific surgeon for a specific procedure.

By the early 1980s many hospitals had operating room management information systems. Some of these used minicomputers, such as at Johns Hopkins Hospital [120, 122]; but most used microcomputers, as reported by the University of California in San Diego [86] and the Thomas Jefferson University Hospital [209]. By the end of the 1980s, microcomputer-based surgical suite management systems were available that provided case scheduling, the surgeons’ preference lists of instrument and supply needs with automatic inventory control, and a posting and log program to monitor surgeon and staff activities and performance [5]. More advanced minicomputer-based operating room information systems were beginning to offer real time clinical patient record data acquisition and retrieval from terminals located in each operating room, in addition to anesthesia and recovery room information, infection control, and incident reporting [105]. Building on the industrial experience with computer-aided systems design, software was being developed that would assemble two-dimensional x-ray scans into three-dimensional x-ray images for computer-aided surgery performed in complex orthopedic and neurosurgical procedures [155]. The monitoring of patients who were critically ill was usually done in an intensive care unit.

3.2 Anesthesiology

Anesthesiology became a prime target for patient safety concerns by the second half of the 1980s. The Joint Commission for Associated Hospital Organizations (JCAHO) chose anesthesiology as one of the first areas in which to incorporate outcome indicators into its hospital accreditation standards. Some states began to require that, when general anesthesia was used, there must be continuous monitoring of the patient’s blood oxygen content and of changes in exhaled carbon dioxide [49]. Monitoring anesthesia administration to surgical patients required as great a variety of technology as any other medical specialty. It had many of the same requirements as monitoring patients in intensive care units (ICUs). A surgery anesthesia monitoring system developed by Michenfelder and associates [131] at the Mayo Clinic with IBM monitored and stored the vital physiological variables for an anesthetized patient. These data included measurements of arterial and venous blood pressures, heart rate and electrocardiogram, respiratory rate, airway pressure, and body temperature. The digitized data were stored on magnetic tape; displays of the data appeared on television-type monitors.

Through the years the anesthetist became somewhat comparable to the airplane pilot in the cockpit surrounded by myriad instrument and computer displays. The surgery and the anesthetic affected many organ systems, so the anesthetist had to continually monitor the anesthetic and oxygen-gas intake and their blood concentrations, the depth of anesthesia and the brain function, the cardiac and pulmonary functions, intravenous fluid intake, body temperature, and degree of muscle relaxation. The anesthetist usually determined a patient’s blood-gas levels during surgery by periodically testing blood samples for dissolved oxygen, carbon dioxide, and pH value. In 1968 Warner [201] and associates at the LDS Hospital inserted into the patient, prior to surgery, a central aortic-pressure catheter that was connected to a pressure transducer. The anesthetist obtained measurements of arterial pressure, stroke volume, heart rate, and cardiac output by pressing buttons on the console; and the results were displayed on the oscilloscope of the console. Other pertinent data, such as drugs administered and comments about the status of the patient, were entered in the computer-based record and printed out at the end of the operation in the form of an integrated anesthesiology record.

Crouse and Wiederhold [44] reported the use of their ACME system for monitoring patients under anesthesia by recording measured concentrations of carbon dioxide during respiration, and continuously analyzing data obtained from their electrocardiogram and carotid pulse monitors. Chodoff and Gianaris [32] at Johns Hopkins University School of Medicine and Gianaris at Northwestern University Medical Center reported using a preoperative anesthesia management system in which a nurse anesthetist interviewed the patient scheduled for surgery, and recorded on mark-sense forms the patient’s history and physical examination findings. The data were then read into the computer and were subjected to a clinical decision support system (CDSS) developed by IBM, which suggested significant anesthetical abnormalities and their possible causes, orders for further study, and anesthesia recommendations. However, when the researchers compared data from the system to data recorded from the physicians, they found little agreement between the computer and the physicians.

Shaffer and associates [163] at the George Washington University Medical Center used handwritten forms to record the anesthesiologist’s preoperative summary of the patient’s condition and of the postoperative course; the nurse’s notes on the operative course; and the recovery-room course. From these forms, data items were coded and keypunched into cards for batch processing by an IBM 370 computer. Monthly statistics were provided of operating room utilization. By the end of the 1970s, system developers began to use microcomputers for surgery information systems. Cozen [43] at the California Hospital Medical Center in Los Angeles, used a microcomputer connected to a monitor to measure and display the patient’s blood pressure and pulse rate; the data were then transmitted to a minicomputer database.

At the University of California in San Francisco, Young [209] used a DEC minicomputer-controlled mass spectrometer to analyze samples of both inspired gases and expired air, and thus eliminated the need for drawing blood samples. Similarly, Harbort and associates [75] at Emory University used a Hewlett Packard minicomputer for the management and display of data from a Perkin-Elmer microcomputer-controlled mass spectrometer used to monitor and plot, every 5 min, the flow of anesthetic gases administered and the levels of oxygen, carbon dioxide, nitrogen, and argon in the patient’s respired air.

At Yale University School of Medicine, Miller [132] developed a program called ATTENDING that received a list of the patient’s problems, a planned surgical procedure, and a proposed anesthetic plan. The system critiqued this plan from the standpoint of the patient’s underlying problems and their inherent risks, suggested alternative approaches, and discussed the risks and benefits of different approaches for the patient’s problems.

In the 1980s integrated technologies began to be developed for noninvasive monitoring of both the gas anesthetics and a patient’s physiologic measurements. Lewis and associates [110] at the Eastern Virginia Medical School reported the use of a desktop-sized Hewlett Packard microcomputer to store the data entered by clerks in a coded format from the operative records of patients who had undergone vascular surgery. As the preoperative evaluation of a patient is an important procedure, Keating and associates [98] at Jefferson Medical College developed a Computer-Assisted Preoperative Evaluation (CAPE) system to help identify risks associated with the patient’s diagnosis and with the planned surgical procedure. The system also provided estimates of mortality, and specific recommendations for decreasing risks for the patient. In the 1980s operating room information systems were reported by Ball et al. [7] to be available in 18 software packages, each of which provided some of the 21 important functions, including operating room scheduling, anesthesia and surgery logs, equipment control, medical records, staff records, inventory control, resource use, infection control, and patient care plans. Of the 18 vendors, only two software packages offered all 21 of these functions. Berg [13] estimated that only 10 % of U.S. hospitals used some type of computer support in their operating rooms.

3.3 Oral Surgery and Dentistry

Oral surgeons and dentists began to explore the use of computers in their offices in the late 1960s. According to Tira et al. [193], in the 1970s an increasing number of journal articles began to appear describing computer applications in clinical dentistry, and dentists began to employ computer batch-processing using time-sharing service bureaus for office administrative and business applications. Diehl [47, 48], at the Naval Dental Research Institute in Great Lakes, Illinois, noted that in the 1970s microcomputers and floppy discs brought computer capabilities to dentist’s office staff. Some computer-based simulation models were developed to assist dentists in planning and operating their offices by studying their practice mix for tooth fillings, crowns, extractions, and other procedures; by evaluating the effects of adding auxiliary personnel or altering office configuration [100]; and by planning a new dental practice [148]. In the 1980s there were available several hundred dental office software packages, many had been custom written by dentists. By the end of the 1980s, computer-assisted imaging systems were available to make dental prostheses such as crowns; so rather than making a physical model or a die of the tooth to be replaced, an electro-optical scanning method obtained the necessary three-dimensional information, which was digitized by camera and entered into the computer [14].

In the second half of the 1980s, Zimmerman [211] at the University of Maryland at Baltimore that a survey of 628 dentists showed about one-fourth had some type of computer system in their offices. Two-thirds of these were microcomputers or minicomputer inhouse systems used mostly for billing and accounting applications; only about one-third had some patient record-keeping applications. In 1986 Southard and Rails at the Naval Dental Research Institute in Great Lakes, Illinois, described a computer-based dental record system that collected, stored, and displayed in a standard clinical format, the information generated during a comprehensive general dental examination. They used a microcomputer with a keyboard, visual display, and a dot matrix printer with high-resolution graphics capabilities for printing symbols, markings, and text, to print a copy of the computer-stored examination record in the same textual and graphic format as standard, manually recorded dental charts [170]. Using preprinted examination charts showing all 32 teeth, their computer program overprinted on each of the teeth appropriate marks and symbols for missing teeth, existing restorations, root-canal treatments, partial dentures, and caries; it also gave recommendations for extracting any teeth. In 1986 Rails and associates also developed a computer-assisted dental diagnosis program to operate on a microcomputer; it was written in the BASIC language. After taking a dental history and completing an examination of the teeth, the user would answer a series of computer-displayed questions. Using algorithms and rules such as, if this … then do this …, if the answers representing the dental findings fit a diagnostic pattern, the computer classified the patient’s dental abnormality and recommended treatment if requested [170].

In the 1970s some computer-based simulation models were developed to assist dentists in planning and operating their offices by studying their practice mix for tooth fillings, crowns, extractions, and other procedures; by evaluating the effects of adding auxiliary personnel or altering office configuration [100]; and by planning a new dental practice [148]. By the end of the 1980s, computer-assisted imaging systems were available to make dental prostheses such as crowns; rather than making a physical model or a die of the tooth to be replaced, an electro-optical scanning method obtained the necessary three-dimensional information, which was digitized by camera and entered into the computer [14]. Simulated surgery on three-dimensional models became available in the 1980s when interactive computer graphics introduced the capabilities of preoperative planning for difficult operations. Using x-ray scans that focused on the abnormality, the surgeon could simulate operating on an abnormality, and refine and repeat the process until the appropriate surgery was planned properly [45].

3.4 Obstetrics and Gynecology

Obstetricians use the general surgery suite for surgical procedures such as Cesarean sections; otherwise, obstetrical deliveries were completed in separate delivery rooms to minimize the risk of contamination. Since most pregnancies resulted in the collection of similar patient data for around 9 months, in the 1970s the American College of Obstetricians and Gynecologists (ACOG) and the American Academy of Pediatrics (AAP) developed standard data collection obstetrics data forms for the prenatal visits, for the delivery and hospital course of the infant, and for the first post-partum visit of the mother [88].

Obstetricians have the special requirement of maintaining a continuing record of the prenatal care of a pregnant woman, and having this record available at the time of delivery. In 1971 Jelovsek and associates [91] at the Duke University Medical Center initiated an OIS with a computer-based patient record using the Duke GEMISCH database management system, the precursor to Duke’s TMR system. Stead et al. [178] reported that the patient’s record for an entire pregnancy was gathered on 50 pages of check sheets, resulting in a printout that averaged 10 pages. A set of paper forms was used to collect a self-administered patient history, a physician’s physical examination, and clinical laboratory test results. These forms were then entered into the database using an optical scanner and an interactive video display. A complete printout of this data was then placed on the patient’s paper chart within 48–72 h [26]. An updated printout was always available from a Teletype printer located in the delivery suite. After several revisions of the data collection forms and printout reports, in 1974 the computer-based obstetrics record was implemented using a separate PDP 11/40 computer and two visual display terminals, and programmed as an application of the GEMISCH system. The records of approximately 10,000 pregnant women had been processed by the system by the end of 1975 [178].

In 1980 their Women’s Clinic began to use the Duke TMR system. Physicians still recorded patient data and orders on encounter forms that were given to a clerk to enter into the computer using visual display terminals with keyboards while the patient was still present. The computer printed out laboratory requisitions and billings that were then given to the patient. They concluded that their information system in which data transactions were captured in realtime in the presence of the patient, had a significant effect on office personnel and patient flow. Jelovsek [91] reported its advantages included improved data quality, control, and timely availability; its disadvantages included increased hardware requirements, major retraining of personnel, and more rigid adherence to organizational policy.

In the late 1970s, Wirtschafter and associates [205] in Birmingham, Alabama, initiated the development of a computer-based medical record system serving the obstetrics services of two hospitals and several clinics located in the county. In 1982 they provided care to more than 4,000 pregnant women per year, and generated more than 40,000 encounter forms. In 1977 they acquired an IBM 370/158 computer and used the Time Oriented Database (TOD) system, developed at Stanford University; the system was operational in all clinics by the end of 1979. Data input paper forms from the various prenatal clinics were transmitted to their computer center where a prenatal summary report was generated and made available online at the two hospitals for the patient’s delivery. Labor and delivery data were handled similarly from physicians’ recorded data on forms, and a perinatal discharge summary was prepared at the time of the patient’s discharge.

In 1986 Gonzalez and Fox [67] at the Columbia University College of Physicians and Surgeons implemented a complete computer-based obstetrics record. All patient encounters were recorded directly into the system by the health care providers; all of the information was stored in the computer and was available in real time. Personal computers acting as terminals were placed in all examination rooms, consultation rooms, physicians’ offices, and in the labor and delivery rooms; and all were connected to a central microcomputer. Even into the late 1980s, most obstetricians still used paper forms to record their patient data, which clerks then entered into the computer-stored medical record. Since the time of delivery was usually unpredictable and often occurred at night when there was not easy access to paper-based records, the main advantage of a computer-based obstetric record was that of assured availability of prenatal patient data at the time of delivery, night or day.

Listening to the fetal heart during a delivery by placing a stethoscope on the mother’s abdomen is a routine procedure for obstetricians to monitor the fetal heart rate for evidence of fetal distress. Electronic fetal monitoring by recording the fetal electrocardiogram was introduced in the 1960s [103] for the purpose of detecting fetal distress. Hon [81] at the Loma Linda School of Medicine in Los Angeles, used electrodes placed in the mother’s vagina to pick up the fetal signals and to record them on magnetic tape. These analog signals were then digitized and analyzed by an IBM 7094 computer, which permitted monitoring of the fetal electrocardiogram and the fetal heart rate. In the 1970s continuous electronic monitoring of the fetal heart rate became increasingly common in the United States; and computers began to be used to apply techniques developed for automated monitoring of the electrocardiogram in ICUs, with alarms that sounded when preset normal values were exceeded [151]. However, an evaluation by Banta and associates [8, 9] at the National Center for Health Services Research reported that monitoring of the fetal electrocardiogram was no better than auscultation by the stethoscope; this report somewhat dampened for a time the diffusion of electronic fetal monitoring in the United States.

4 Pediatrics

Pediatricians provide care to children from birth through teenage years. The data processing requirements vary considerably for newborns, preschool and school-aged children. Important medical procedures include immunizations and body measurements for identifying growth and developmental problems. In contrast to the data collection process in adult patients, pediatricians in most cases acquire the medical histories from parents. The hospital information system functional requirements for children in the hospital pediatric services are generally similar to those for adults in the medical and surgical services. However, newborns require very different specialized care. The first data relevant to a pediatric patient are those recorded for the yet unborn baby in the mother’s obstetrics prenatal record. At birth, the newborn is transferred to the nursery service and assigned an identification code; and the baby’s pediatric record is initiated. Monitoring the growth and development of infants and children is important since these variables were closely related to children’s health; and these data required comparisons to standard charts.

In 1969 a pediatric information system was initiated by Lyman and Tick for the pediatrics department of Bellevue Hospital in New York Medical Center that supported 30,000 patients with 70,000 clinic visits per year. Since the traditional paper-based record had been available for only 20–30 % of visits, a major objective of the outpatient information system (OIS) was to provide realtime access to the patients’ records. In 1975 the clinic was staffed by eight to ten physicians; and a relatively comprehensive computer-stored patient record was maintained for the patients’ initial and follow-up visits. Data collection mostly used free-text encounter forms for data organized by categories. All data were entered via Teletype terminals connected by telephone lines to a large mainframe, time-sharing UNIVAC computer at New York University. In 1975, 35,000 children were registered, receiving about 75,000 encounters a year. The central Univac computer provided both online and batch processing services via telephone lines to terminals located in the hospital and clinics [64]. Retrieval of patient records could be initiated within a few seconds; but printing the reports in the 1970s on teletypewriters could take several minutes depending on the length of the record. Patients were seen with a traditional paper-based record, supplemented by attached computer printouts of abstracts of the computer-stored record of recent data, such as diagnoses and medical problems, laboratory test results, and hospitalization discharge summaries. The system was also used by Tick and associates for research in the computer processing of natural language free text [77].

In 1976 the obstetrics medical record implemented by Jelovsek [89] at Duke University Medical Center in 1971 was modified to collect newborns’ data from the nursery. A data sheet for each infant was entered into the computer and combined with the maternal information to generate automatically an infant discharge summary). A computer-based perinatal data system was developed at the St. Josephs Hospital in Phoenix, Arizona, that served as the basis for the statewide Arizona Perinatal Program [93]. Wasserman and Stinson [202] at the University of California San Francisco and Stinson at the University of Rochester Medical School developed detailed specifications for their perinatal records, that included information collected from the mother and fetus during pregnancy and delivery, and for the first 28 days postpartum or until the baby left the hospital. Pediatricians at the Medical University of South Carolina developed a computer-based system that provided information on the growth of infants and children, and compared the height and weight of the patient with those of a child of the same age, race, and sex in a standard population. In addition visual warnings were included on a computer terminal screen of any possibility that measurement errors had occurred or that the patient was experiencing abnormal growth [149].

Newborns with a low birth weight (2,500 g or less) or with a very low birth weight (1,500 g or less) were mostly premature infants and were usually placed in incubators in a neonatal intensive care unit (NICU) for their first week or two of life. With the advent of neonatal specialists in the 1970s, a NICU was established in many pediatric hospital services [29]. Initially the Primary Children’s Hospital in Salt Lake City used the computer at the LDS Hospital, with which it was affiliated [33]. However, it soon employed a dedicated PDP-8 computer to process all the patient data generated in the NICU and used the LDS time-sharing computer for compiling and printing reports [54]. Maurer and associates [117] at Washington University in St. Louis developed a data management system for neonatology which they defined as the hospital-based subspecialty of pediatrics devoted to the care of sick infants from birth to generally 1–2 months of age, but in cases involving hospitalization might extend to 8–9 months. Cox and associates [42] at Washington University proposed the design for a formal model of a database system for neonatology based on Maurer’s database. Neonatal information systems often shared the HIS central computer, as did the one at the Loma Linda University Medical Center in California [87].

In the 1970s and 1980s, many pediatric services installed information subsystems. With increasing use of the newer technology, Ertel and associates [53] at the Children’s Hospital in Columbus, Ohio, initiated an outpatient information system for their pediatric clinics, which at that time provided more than 100,000 outpatient visits per year. Initially, their primary objectives were to support administrative functions and to automatically generate the detailed external reports that were required. They developed encounter forms for data input for family and child demographics, and for the basic clinical data summarizing each patient’s visit as to diagnosis and treatment. Copies of these paper forms were transmitted to a central computer, which entered and batch processed the data; and periodically generated individual patient reports and tabulations of data for frequency of diagnoses, clinic visits, of immunizations given, and other statistical analyses. After nearly 2 years of full operation and the processing of more than 187,000 documents, they concluded that their data system met all major design specifications; and the effect on service operations included a significant increase in efficiency at administrative, clerical, and clinical levels.

In 1970 Haessler and associates at Searle Medidata in Lexington, Massachusetts, extended their automated self-administered history taker to provide a pediatric database history. Their branching history questions included the child’s current symptoms and diagnosed illnesses as well as perinatal, developmental, family, social, and school history data. After a period of testing the system, they added more questions covering the first 2 years of life, provided the option of abbreviated histories for children with a single problem, and added encounter forms for return visits. With these modifications, they reported that their new Pediatric Database Questionnaire was acceptable to both physicians and patient responders [50].

The pediatricians at Duke University Medical Center also developed a specialized, online, computer-based, self-administered, tree-structured questionnaire for use in their well baby clinic, which provided services to children up to 27 months of age. This was an application of their Generalized Medical Information System for Community Health (GEMISCH) program. Their questionnaire was administered on a visual display terminal to the mothers. Computer printouts provided to the clinic pediatricians contained alerts to certain identified problems, such as problems with feeding the baby. They concluded that the computer could take much of the patient history for the physician, could make “suggestions” depending on the data acquired, and allowed the physician more time to attend to the patients more pressing problems [139].

In 1976 a group of pediatricians in the Boston City Hospital and its seven affiliated Neighborhood Health Centers implemented a computer-based Medical Record Communications (MARCO) system for the care of 30,000 pediatric patients. This system operated on a DEC PDP 11/45 computer using a MUMPS/11 based operating system, which supported seven terminals. During a patient’s visit, the physician recorded the patient’s data on a structured paper encounter form, from which a clerk entered the data into the computer using the computer terminal. The computer then generated a report for the physician, and printed a copy as part of the chart for the patient’s next visit. By 1978, 55,000 encounters had been processed by the system [134].

Newborn screening information systems were established to track babies from their first screening test through their last follow-up test [46]. In 1980 the University of New Mexico Hospital employed two DEC PDP-11 computers to provide an information system for its newborn ICU. Codes were used to enter data in response to sets of menus shown on display screens asking for specific information. Daily updated summaries of patients’ information and discharge summaries were provided by display or by printouts to be filed in the patients’ charts [169]. In 1980 the First National Conference on Perinatal Data Systems was held in Milwaukee [76]. In the 1980s large perinatal databases, such as the University of Illinois Regional Perinatal Network Database, were used to support decision making by clinicians, administrators, and research epidemiologists [70]. Systems such as the Maryland Perinatal Database used a series of forms for recording and entering data to provide a comprehensive repository of the clinically significant information during the perinatal period; the data were retrievable for both patient care and research purposes [136]. In the early 1980s some states began to mandate newborn screening tests for certain metabolic disorders, such as phenylketonuria and hypothyroidism. The proceedings of a conference on computer-based newborn screening programs were reported in the April 1988 issue of the Journal of Medical Systems. In the early 1980s, perinatal and neonatal computer-based systems were becoming common, often using minicomputers: Chicago Lying-in Hospital installed a DEC PDP-10 computer l [113]; the Medical University of South Carolina used a Prime 550 computer [133]; and the Los Angeles County Hospital used a PDP-11/40 computer [208]. Soon microcomputers became more widely used to acquire data from monitoring equipment, and to process and display of patient data in graphic and textual formats [82]. A microcomputer-based perinatal and neonatal information system using a Radio Shack TRS computer for interactive processing of patient data was used at the East Carolina University School of Medicine [51].

In 1983 narrative discharge summaries of some pediatric patients in the New York University Medical Center were being analyzed by a computer system for the processing of natural language records [114]. Due to the large population served, the Los Angeles County Hospital modified its perinatal system by using an Apple II Plus computer for data entry; when the data file was completed, it was transmitted using a telephone line to an IBM 370/168 mainframe computer [207]. The University of Minnesota used a microcomputer for its neonatal system and linked it to the clinical laboratory system for other patient data [41]. Budd and associates [28] at the University of Minnesota Medical School described a medical information relational database system (MIRDS) for their division of pediatric pulmonology; the system accessed their clinical database by using microcomputers. By the late 1980s, large, multiuser pediatric office information systems were available that provided patient management with specialized sets of display screens for programs requiring clinical calculations, for administrative and business functions, word processing for report writing, and electronic mail [144]. In the 1990s, some placed an interactive terminal in the patient’s home, with access to a pediatric mobile database in their system, which was programmed to provide advice to a patient’s family in response to queries when a child had certain common symptoms [206].

5 Mental and Behavioral Health

Not all hospitals will admit patients with mental disorders since these patients require special facilities for their care and security. Patients who require long-term psychiatric care usually are in psychiatric hospitals. When hospitals with a computer-based patient record system have psychiatrists and psychologists on their staff, all data processed for psychiatric patients require extraordinary protection for the security, privacy and confidentiality of the patients’ data; only the patient’s personal psychiatrists and psychologists are legally permitted access to that patient’s records. Otherwise, the information processing requirements for a psychiatric service are similar to those for a general medical service. Interviewing and history taking constitute a prominent part of a psychiatric patient’s medical record, and are generally similar for hospital and for office patients.

Beckett [11] noted that psychiatrists collected a vast amount of clinical information in lengthy interviews with patients, and proposed that this information could be reliably recorded in a form suitable for high-speed data processing. Since most data in the practice of psychiatry and psychology were collected by interviews with patients, a great amount of effort was directed to the development of computer-based questionnaires and programs for interpreting their results.

In 1971 Slack developed and used a computer-based psychiatry history system based on an automated history taker [168]. However, processing of data from patients with mental disorders required not only a specialized data dictionary for terms used in psychology and psychiatry, but also extraordinary measures for the security and protection of the confidentiality of the patients’ data.

Rome [150] at the Mayo Clinic in Rochester, Minnesota, reported the initiation in 1961 of a joint project with IBM to test an automated version of the then widely used paper-and-pencil-based Minnesota Multiphasic Personality Inventory (MMPI). This test, was developed to help distinguish between functional and organic disease, consisted of 550 statements to which the patient responded by checking each statement as “true” or “false”. The responses were then scored to generate 14 scales that predicted personality patterns, such as hypochondriasis, hysteria, depression, paranoia, schizophrenia, and others, in addition to “normal”. The test was modified for computer processing so that the 550 statements were printed on 23 standard-sized punch cards. The patient used a special electrographic pencil to fill in the space at the left of the statement if “true”, or to the right of the statement if “false”. The patient’s identifying data were keypunched into a header card, which was then processed with the test cards by a mark-sensing machine that read the marks and punched them into cards readable by the computer. The patient’s responses were automatically scored and scaled into personality patterns by the computer program, and a printed report of descriptive diagnostic statements was provided to the patient’s psychiatrist or psychologist [188]. By 1964 the Mayo group reported the evaluation of the automated MMPI for the testing of 50,000 patients; they concluded that the automated MMPI was well tolerated by patients and provided meaningful information to psychologists to motivate its continued use [140].

The data derived from this large group of patients permitted them to refine the personality patterns, and the automated MMPI began to be used by others [39, 187, 189]. Finney [55] at the University of Kentucky Medical Center in Lexington advanced this work by combining the automated MMPI with another test, the California Psychological Inventory. Finney’s program counted patient’s responses and converted them into scores; the scores were combined into indices for which designated statements were put into proper order and into paragraphs. Rather than providing a series of statements, this program generated a report that read as if it had been spontaneously composed by a professional looking at the results of testing. The report described the various processes going on in a person and how they are related to each other. As a variance to using patients’ responses to predict psychiatric diagnoses, Overall [138] at the University of Texas Medical Branch in Galveston used the responses of psychiatric patients with known diagnoses who were receiving multiple medications to develop a program that advised which particular drug would be best suited for a given patient.

Starkweather [177] at the University of California in San Francisco addressed the more difficult problem of developing automated text processing from the psychiatric interview, and concluded that analyzing psychotherapeutic interviews introduced the problem of processing immense amounts of verbal and textual material. Starkweather first developed a listing of all words used by patients in their recorded interviews, and wrote a program to build a vocabulary and an organized summary of the patient’s usage of words. He studied ways of grouping words, and counting word frequency of use as related to categories of meaning and psychologic diagnoses, and developed a program he called COMPUTEST, which simulated a psychiatric interview. The program had questions that were typically used by a psychologist interviewer; the questions and answers were transcribed on an electric typewriter and entered into the computer. The computer program recognized individual words and groups of words, and varied subsequent questions in accordance with the occurrence of “right” or “wrong” answers, and whether the word “yes” was found in the answer. The program could simulate and take the part of either the interviewer or the patient [176]. Starkweather applied factor analysis to the rate of occurrence of words in patients’ responses, and applied labels, such as “denial” or “self- aggression” to factors produced from such analysis [175]. As an example, the occurrence of the word “discouraged” in a response was one of a group of words found to suggest a depression of mood [174]. Starkweather’s group went on to develop a computer-based medical record system for the Langley Porter Neuropsychiatric Institute, with a System for Efficient Automated Retrieval and Checking of Hypothesis (SEARCH) program to retrieve text on the basis of criteria that included psychiatric terms [186]. The system was first developed to include the psychiatry department’s outpatients; later it also included their inpatients [115].

In the 1960s studies were also reported of computer interpretations of unstructured tests, such as the Rorschach, Figure Drawing, and Thematic Apperception tests, which depended on the clinical experience and judgment of the interpreter rather than on statistical scores and rules of interpretation [56]. A relatively advanced program was developed by Piotrowski [141] for interpreting the Rorschach inkblot test by using the detailed scores derived from experts experienced with the test to develop several hundred decision rules to print out a series of interpretive statements based on configurations of scores. In addition to developing methods for computer-assisted assessment of patients with mental disorders, computer-aided psychology therapy was evaluated for conditions that could be helped through behavior modification by processes similar to computer-assisted education [185]. In the early 1970s, a survey of 243 responding psychologists showed that two-thirds were using minicomputers, and one-third used remote-terminal systems attached to a central processing unit. Of those using minicomputers, 57 % wrote their own computer programs mostly using the FORTRAN language, and mainly for clinical and research purposes. Primary applications of users of central processing computers were for statistics and large-scale data reduction [190].

Computer-aided counseling was employed for psychological problems [165] for patients with dietary problems; and a program offered education and altered dietary behavior for overweight patients [143]. Stillman and associates [184] at Stanford University Medical Center developed a Computer Assisted Special Enquirer (CASE) to elicit and record mental status, psychometric, and personal history information directly from patients without the aid of an interviewer. They found that even severely disturbed patients could answer computer-presented questions without assistance. Slack and Slack [167] also evaluated the computer as an interviewer for patients with emotional problems; suggested that the computer-based interview, a “psychology soliloquy”, encouraged the patient talking to oneself; and hoped that it would be therapeutic to proceed with questions to encourage relevant soliloquy.

Angle and Ellinwood [2] at Duke University Medical Center reported that their computer interview system routinely gathered extensive patient pretreatment or baseline problem data in a number of psychology treatment programs, and also patient progress information and outcome results. In the 1970s reports of activity in developing computer-based information systems for hospital psychiatry patients were published by professionals at the University of California in San Francisco [115], Forest Hospital in Des Plaines, Illinois [127], Duke University Medical Center [2], West Virginia University Medical Center [161], and the University of Michigan [101]. Black and Saveanu [15] published a comprehensive analysis for the entire decade of the 1970s of the admissions into the Ohio State Mental Health hospitals, using his group’s computer-based patient data systems. He identified high-risk groups of patients and emphasized the need to integrate community and hospital data for more accurate evaluations.

In the 1980s microcomputer programs were developed for interactive display and data processing of the mental status examination, the past history, treatment plans, progress notes, real time psychological testing, biofeedback training, and accounting and billing. Because of their low cost, these instruments could be useful in the psychiatrist’s office practice [126]. The MMPI was reported to be administered on the TRS-80 computer [31]. A portable microcomputer was used to administer tests, store responses, and view results for psychiatry patients at several locations in Dallas, Texas [30]. The Computer-Stored Ambulatory Record (COSTAR) system was modified to meet the needs of clinicians and administrators in the Outpatient Navy Mental Health Clinics [40]. Greist and associates [69] at the University of Wisconsin developed a computer-based Lithium Library, which in 1983 contained 9,000 citations, and provided online access by free-text entry for information requests by clinicians or investigators on diagnosis, pretreatment work-up, and possible complications of lithium treatment. In the 1980s many information systems for psychiatry departments were reported, using minicomputers, including the University of Pittsburgh School of Medicine [35, 129] and the VA Hospital in Loma Linda, California [72]; and using microcomputers at Northwestern University Medical School [71].

6 Other Clinical Specialties

6.1 Ophthalmology

Ophthalmologists began to exploit the capabilities of the computer in their office practice in the 1980s, primarily through advances in bioengineering and instrumentation. Jacobs [85] reviewed the then-current applications of computers in ophthalmology and described computer-controlled perimeter devices that detected the absence of vision in automated testing devices of visual fields, with the test results stored in microcomputers. Jacobs also reported a microprocessor-controlled, automated refractometer that measured infrared light reflected back from the retina of the eye, converted the signals to a digital format, and measured the refractive power of the eye. Similarly, automated keratometers with photosensors detected infrared light reflected from the cornea, and measured the curvature of the cornea. Jacobs also described automated lens analyzers that measured deviations of light beams through the lens of the eye.

6.2 Physical Medicine and Rehabilitation

Physiatrists and physiotherapists in rehabilitation centers, such as Spencer and Vallbona at the Texas Institute for Rehabilitation and Research (TIRR) developed a fairly comprehensive medical information system (MIS) with several clinical subspecialty systems for patients’ rehabilitation. TIRR was a private, non-profit, special-purpose hospital in the Texas Medical Center at Houston that delivered comprehensive rehabilitation services to patients having a wide variety of physical disabilities. In February l959 physiological test data were manually recorded on specially designed source documents. The data were then coded, keypunched, and processed on a batch basis with unit-record equipment. The software consisted of diagrams of complex patch boards. In l96l the acquisition of IBM l40l and l620 computers with magnetic tape storage provided for data processing, storage, and data retrieval capabilities [18]. In 1965 the problem of errors in data entry associated with the use of punched paper tape and cards required TIRR to advance to online computing with an IBM 1410 computer. Data entries were made by a clerk at TIRR via a remote typewriter terminal. With the establishment of a conversational mode between the terminal and the computer, error detection and correction by staff personnel became feasible.

In l967 the system was enhanced by the acquisition of an IBM 360/50 computer [197]. In 1968 physicians’ orders began to be entered into their medical information system; and appropriate displays were accessed on IBM 2260 cathode-ray-tube terminals located in various clinical departments [12]. In 1969 using these display terminals connected to the Baylor University IBM/360 computer, updated reports were batch-processed daily for each patient [68]. By the mid-1970s, TIRR had an information system with several operational modules, including the provision of results of all patients’ laboratory and functional capacity tests [197].

7 Summary and Commentary

Although some of the earliest applications of computers in clinical medicine were in the clinical subspecialties, health professionals found these prototypes difficult to use since their data entry devices were awkward and inefficient, and their order entry functions were often not integrated. Each information system for a clinical subspecialty had its own specialized functional and technical requirements; each evolved differently. In the 1960s hospitals information systems with ISCSs used large mainframe computers that served all computer applications within the hospital. It was soon found that although a single mainframe computer could readily integrate patient data into a single patient record database, it could not adequately support the information processing requirements of all of the multiple departmental and clinical support systems within a large hospital.

In the 1970s, the advent of minicomputers permitted each ISCS to have its own computer-based information system; and the computers in the various departmental information systems were directly linked to the central mainframe computer. Healthcare professionals used terminals connected to the central computer to enter orders and to receive test results. Directly linked to the departmental minicomputers, the central computer transferred the orders to the appropriate ISCS subsystems and integrated the data coming back from the ISCSs into the patients’ records stored in the mainframe computer. In the 1980s the advent of local area networks that linked multiple lower-cost minicomputers permitted distributed information systems to be implemented in hospitals. Although ISCSs were some of the earliest and most advanced computer-based information systems in medicine, it was not until the advent of distributed minicomputers equipped with interactive visual-display terminals, that clinicians began to benefit from the ISCSs in direct patient care. Minicomputers allowed each ISCS to develop its own internal information system that best satisfied its own functional requirements.

In the 1990s, distributed information systems allowed physicians to enter orders and retrieve test results using clinical workstations connected to client-server minicomputers in the local area network that linked the entire hospital. Patient data from all of the distributed ISCS databases were integrated in a computer-based patient record. The advent of clinical workstations linked by local area networks to the ISCSs made the clinical subsystems, and applications such as a computer provider order entry (CPOE) program more acceptable for clinicians to use [36, 57].

These achievements, and more since, stand on the “shoulders of giants” who had the foresight and innovation to move forward in a new way of supporting clinical care through the use of digital information within computer systems. Today the technology has evolved to allow the goals of early ISCS creators to be easily implemented. As the technology has become more sophisticated, the computer based programs have grown richer and richer.