Keywords

Multi-hospital information systems (MHISs) are medical information systems (MISs) that service three or more hospitals with their associated medical offices, clinics, and clinical support services. The important effect of economics on the development of MHISs was emphasized by Ermann and Gabel [39], who observed that at the time of the enactment of Medicare and Medicaid legislation in 1965, there were no investor-owned hospital information systems in the United States. By 1970 there were 29 investor-owned MHISs that owned 207 hospitals. In 1975 about 25 % of community hospitals belonged to a MHIS. In 1983 one in every seven hospitals, with nearly 19 % of the nation’s hospital beds, was part of an investor-owned MHIS. In September 1984 there were 53 investor-owned systems in operation; the four largest, Hospital Corporation of America (HCA), Humana, Inc., National Medical Enterprises, Inc. (NMR), and American Medical International, Inc. (AMI), owned or managed 53 % of investor-owned systems of hospitals and 75 % of the hospital beds [39]. By the mid-1980s, 44 % of hospitals were part of some MHIS [102]. Ermann and Gabel [39] further explained that the increasing financial pressure on hospitals to remain solvent stimulated the growth of MHISs. Hospitals required large sums of capital to replace, renovate, modernize, and expand, resulting in an increased use of cost-based reimbursement by Medicare, Medicaid, and Blue Cross. It also reduced the hospital’s incentive to control expenditures of finance capital in the least expensive manner, further fostering debt financing.

It was soon recognized that very complex information systems were essential if the perceived advantages of multi-hospital information systems (MHISs) over independent single hospital information systems (HISs) were to be fully realized. The expected advantages of MHISs included (1) economic benefits, including improved access to capital, increased efficiency, economies of scale, and ability to diversify; (2) personnel and management benefits, such as improved recruiting, and ability to develop and retain high caliber staff; and (3) planning, program, and organizational benefits with a regional rather than a local perspective on health needs; and greater power to control environmental factors [40].

When health care systems merged and evolved into a higher level of organization, such as was required in a MHIS, the amount of information that was processed at this new level was more than that at the lower levels owing to the greater diversity of the components. MHISs required more complex information systems with sophisticated communications and networks between facilities, and thus they evolved. The added information needs of a MHIS resulted from the associated responsibility for continuing, long-term patient care, such as under governmental sponsorship as in the Department of Defense and the Veterans Administration, or under private ownership such as health insurance agencies and health maintenance organizations. The need developed for MHISs to link and integrate all information from all affiliated facilities for each patient into one medical record for the full period of time that the health care program was responsible for the patient’s care. In such large health care programs, patients moved continually between hospitals and clinics and physicians’ offices; and sometimes these facilities were located some distances from each other. In such instances, the traditional separation of the patient’s medical record in each facility could be a serious impediment to a good quality of continuing care. For example, a physician might be unaware of a prior treatment for a chronic or recurring ailment because the medical record had not arrived from another treatment facility. As a result, by the 1980s, larger health care systems in the United States were becoming more vertically integrated for all inpatient, outpatient, and ancillary services. In addition, they were acquiring multiple facilities and becoming more horizontally integrated to provide a broader range of acute, specialized, chronic, and extended care services.

1 MHIS Added Requirements

The functional and technical requirements for MHISs were basically similar to those described in Chaps. 5 and 6 for outpatient information systems (OISs) and hospital information systems (HISs). The primary differences in their requirements were in scale for an increased workload and broader communications and interoperability. Because a patient’s data was collected in multiple facilities, MHISs had to link, communicate, and integrate this data among all these facilities, as well as between their multiple departments and subsystems. A completely integrated MHIS often had difficulty in meeting all the different objectives of its individual components. As a result, they usually exercised central coordination of their information services, supervised the security and confidentiality of computer-based patient data, and controlled the central databases for patients, personnel, services, and resources. Yet they generally supported decentralized computing applications to allow for differences in local business, administrative, and clinical requirements. In time, the MHISs usually provided centralized patient identification and eligibility files; scheduling, order entry, and results reporting for centralized services such as a regional laboratory; and tracking of pharmacy drug usage prescribed for patients by different physicians within multiple facilities. In the 1980s and into the 1990s users needed not only to exchange data between facilities, but also to exchange images and documents; they required electronic mail for interfacility consultations; they needed word processing and facsimile exchange; and they wanted online access to the National Library of Medicine ’s MEDLINE and its factual databases. For planning purposes, management sought patient demographic, broad environmental, and community social data.

Prior to the advent of open architecture systems in the 1980s, the technical specifications for a MHIS required uniform computer and communication standards for all hospitals and clinics in the system, so as to permit the integration of data from its various subsystem databases. Because MHISs required a high level of data integration, a single vendor was often mandated to support more consistent, interoperable, and compatible data handling procedures, file management, database organization, patient data security, computer hardware and software. In the 1980s and into the 1990s local area network (LAN) links were being used within most large hospitals between computers, between computers and workstations, and between workstations. Wide area networks (WAN) and satellite links were being used for communication between distant hospitals’ computers. The new integrated services digital network (ISDN) began to allow integration of voice, text, and images on one physical line. The ability of ISDN to use twisted-pair cables within a hospital offered an alternative to other network technologies and permitted transmission of high quality images between hospitals.

1.1 Translational Databases

Frey [42] and associates at Stanford Medical Center described the Advanced Computer for Medical Research (ACME) system that was developed as a research database able to (1) handle many data sets of many varieties and sizes, some that had to be held for long periods of time and some that required frequent updating; (2) minimize inadvertent loss of data; and (3) serve a group of medical researchers who often were inexperienced in computer technology. A typewriter terminal-driven, time-sharing system, ACME was designed to acquire, analyze, store, and retrieve medical research data, and to control laboratory instruments; it was served by an IBM 360-50 computer, with access to 2,741 typewriter terminals, and a variety of laboratory instruments that were interfaced through an IBM 1800 analog-digital computer with disc drives for storage and magnetic tape storage for backup and archival storage.

Translational database s evolved in the 1990s with the development of federated databases and more advanced designs of database management systems to (1) optimize the translation, transformation, linkage, exchange, and integration of the increasingly voluminous medical information that was becoming accessible from many large databases in multiple institutions that were widely located, by using wide area networks, the Internet, and the World Wide Web; (2) provide access to high-performance, super-computing resources; (3) facilitate the concurrent query, analyses, and applications of large amounts of data by multidisciplinary teams; (4) encourage knowledge discovery and data mining, and support the transfer of new evidence-based knowledge into direct patient care; and (5) advance the use of biomedical computational methods. Since most data warehouses had been developed with database management systems that employed their own legacy and data-encoding standards, their source data usually required some reorganization and modification in order to be compatible and interoperable with data transferred from other data warehouses, and then be merged into a single database schema. Thus the development of translational database software became necessary.

Translational informatics was developed in the 2000s to support querying diverse information resources located in multiple institutions. The National Center of Biomedical Computing (NCBC) developed technologies to address locating, querying, composing, combining, and mining biomedical resources; each site that intended to contribute to the inventory needed to transfer a biosite-map that conformed to a defined schema and a standard set of metadata. Mirel and associates [94] at the University of Michigan described using their Clinical and Translational Research Explorer project with its Web-based browser to facilitate searching and finding relevant biomedical resources for biomedical research. They were able to query more than 800 data resources from 38 institutions with Clinical and Translational Science Awards (CTSA) funding. Funded by the National Centers for Biomedical Computing (NCBC), they collaborated with ten institutions and 40 cross-disciplinary specialists in defining task-based objectives and user requirements to support users of their project.

Denny and associates [31] at Vanderbilt University developed an algorithm for phenome-wide association scans (PheWAS) when identifying genetic associations in electronic patient records (EPRs). Using the International Classification of Diseases (ICD9) codes, they developed a code translation table and automatically defined 776 different disease population groups derived from their EPR data. They genotyped a group of 6005 patients in their Vanderbilt DNA biobank, at five single nucleotide polymorphisms (SNPs), who also had ICD9 codes for seven selected medical diagnoses (atrial fibrillation, coronary artery disease, carotid artery disease, Crohn’s disease, multiple sclerosis, rheumatoid arthritis, and systemic lupus erythematosis) to investigate SNP-disease associations. They reported that using the PheWAS algorithm, four of seven known SNP-disease associations were replicated, and also identified 19 previously unknown statistical associations between these SNPs and diseases at P < 0.01.

2 Examples of Early Multi-Hospital Information Systems (MHISs)

In the 1960s The Sisters of the Third Order of St. Francis had a centralized administration for their multi-hospital information system (MHIS) that comprised 12 health care institutions; which included ten general hospitals, a continuing care center, and a geriatric care unit, all located in Illinois, Michigan, and Iowa. In 1961 a group headed by Huff [68] initiated time-shared services in their hospital in Peoria, Illinois; over the next few years they expanded the services to all their facilities. By the end of 1963, their MHIS provided centralized payroll, accounts payable, general ledger, financial reporting, accounts receivable, and inpatient billing. In 1970 they were acquired by the McDonnell-Douglas Automation Company (MCAUTO) of St. Louis, and became the Health Services Division of MCAUTO. In 1979 McDonnell-Douglas introduced its Patient Care System (PCS), after having acquired additional modules to provide a fairly comprehensive MHIS. In the mid-1980s it responded with its PCS to requests for proposals from the Veterans Administration (VA) and the Department of Defense (DoD). Lindberg [85] at the University of Missouri-Columbia, was already operating a MHIS for a statewide network in Missouri and using standard telephone lines. Lindberg found that the costs for transmission of data via telephone lines over a network were about equal to the costs for computer rental, but likely exceeded the computer problems in complexity and importance; and concluded that the issue of backup systems, ready access to distant medical communities, interactive inquiry for users, integrity of systems against unauthorized invasion of privacy, all depended primarily upon the capacity, adequacy, and cost of the data transmission services.

In 1975 when the Church of Jesus Christ of Latter Day Saints (LDS) divested itself of its LDS hospital holdings, Intermountain Health Care (IHC) was formed as a nonprofit multi-hospital corporation of 15 hospitals located in Utah, Idaho, and Wyoming. By 1982 IHC was servicing 22 hospitals with central services for applications such as payroll, general ledger, and productivity monitoring, designed for multi-hospital reporting and control; but the software had been developed permitting the sharing of a single S/38 IBM computer among multiple smaller institutions for decentralized data processing operations [53]. In the 1990s the IHC system expanded to provide comprehensive clinical support services in nine affiliated Intermountain Health Care Hospitals in Utah [46].

In 1973 the Health Maintenance Organization (HMO) Act was passed; by 1977 more than 150 HMOs were operational. Larger HMOs used multiple hospitals and office facilities and required the information processing capabilities of a multiple hospital information system (MHIS). In addition, to plan to meet their service requirements and an increasing competition, HMOs were dependent on an adequate, integrated database of their health plan members’ demographic attributes, their members’ utilization of services, the mix of health professionals needed to provide these services, the operational direct and indirect costs of all services provided, the facilities and equipment used and their capital costs, and the predicted changes of their competition and changes in their community [25, 132].

In 1994 Brigham and Women’s Hospital joined with Massachusetts General Hospital to form Partners Healthcare System that included ten hospitals and more than 250 medical practice sites [125]. In 1994 the Harvard Community Health Plan merged with Pilgrim Health Care and in 1998 joined with the Harvard Vanguard Medical Group. The largest inpatient facility for their hospitalized patients was Brigham and Women’s Hospital in Boston, with 720 beds; there an internally developed hospital information system, the Brigham Integrated Computing System built using Datatree MUMPS [118], had a patient database that already contained medical records for more than one million people and a PHARM system that contained some pharmacy data since 1981 [74]. By 1998, as a result of these mergers, automated pharmacy data for ambulatory patients with Harvard Community Health Plan could have their outpatient pharmacy data linked with their inpatient pharmacy data from their records with the Brigham and Women’s Hospital [21].

2.1 Federal MHISs

The U.S. Public Health Service (PHS) began in 1976 to develop for its PHS hospitals its own multi-hospital information system (MHIS), called the Public Health Automated Medical Information System (PHAMIS). PHAMIS was designed to meet the clinical data processing requirements of nine hospitals and of 26 free-standing PHS clinics. The primary beneficiaries of the PHS hospitals and clinics were American seamen, active duty and retired uniformed members of the Coast Guard, members of the National Oceanic and Atmospheric Administration, and PHS officers. In his comments on the PHAMIS concept at the 1979 Symposium for Computer Applications in Medical Care (SCAMC), Glaser reported that in 1976 approximately 540,000 individuals received care in PHS facilities. The ultimate objective of PHAMIS was to replace the handwritten medical record with a computer-based health information system which would support patient care, hospital management, and clinical research activities.

In 1979 PHAMIS was still in a developmental stage. Its patient registration module gave patients a unique identification number and included demographic information. An admission, discharge, transfer (ADT) and bed-control system recorded the admission of patients to the facility and kept track of bed occupancy. At the PHS facility in Seattle, there was an appointment scheduling system in one clinic. An outpatient pharmacy module maintained a complete medication history, which included known allergies, as part of the patient’s medical database. In 1979 an automated laboratory information system was in the procurement phase, to be interfaced with PHAMIS. Problem lists for outpatients were maintained in one clinic. The patient database stored all patient information in a single central file. With the same patient identification number used in all facilities, it was possible to integrate a patient record from different facilities by storing the information in a central database common to all facilities and also in local databases that were queried as required. For example, a request for a medication profile retrieved all the recent medications received, regardless of the dispensing facility. The PHS hospitals were closed in the 1980s. In 1981 Glaser founded PHAMIS, Inc., as a private vendor; and further development and marketing was continued commercially. By the end of the 1980s Seattle-based PHAMIS was installing its own MHIS, now called LASTWORD, with a long-term integrated relational database and modules for inpatient and outpatient care, in the Humana Hospitals system [89].

The U.S. Indian Health Service (IHS) had unique requirements for providing health services to its patients. In 1955 responsibility for the health care of Native Americans and Native Alaskans was transferred to the PHS from the Bureau of Indian Affairs. The Surgeon General established the Division of Indian Health to administer the program. In the 1960s there were 380,000 Native American and Alaskan people living in 23 states on federal Indian reservations and in Alaska [108]. In the 1970s the IHS took care of about 750,000 people and operated 52 hospitals, 99 full-time health centers, and several hundred health stations. Garratt [47] described the status of the MHIS being developed by the IHS in 1979 as being a widely dispersed, multi-facility, multi-disciplinary, multi-organizational, multi-level Patient Care Information System (PCIS) designed to operate in this environment. Prototype versions of PCIS became operational in southern Arizona in 1969 and in central Alaska in 1974. A pilot test of the PCIS was implemented in all IHS facilities in the states of Montana and Wyoming, and it became operational in December 1978. A second pilot test including all IHS facilities in Alaska became operational in April 1979.

A third large-scale project was initiated in 1979 on the Navajo Reservation. The PCIS maintained a computer-stored single record for each patient; and the record contained relevant health data from each encounter with all providers of care at all facilities. This required the linkage of health data from all sources of care. Multipart encounter forms were used by all health professionals to document all visits. The original copy of the encounter form provided the legal record of the patient visit and included prescription blanks for ordering medications, consultation and referral requests, appointment slips, and instructions to patients. Copies of all PCIS forms were mailed to a central data processing center in Tucson, Arizona, where ICD-9-CM codes were added for all diagnoses and to any narrative free text. The data were then entered by keyboard, and stored on magnetic tape. The tape files of data were then sent to the computer center in Albuquerque, New Mexico, where a master tape file was created from which all reports were generated. Computer output to microfiche was used to provide patient health summaries that contained significant medical data from all services. The health summaries were updated every 2 weeks and were distributed to all appropriate PCIS users. The average turnaround time from the date of encounter to the receipt and availability of health summaries back in Alaska was approximately 4–6 weeks [18]. The data available to a clinician at a facility included the facility’s medical record, which contained the original copies of past input forms completed at that facility, together with paper copies of the computer-generated microfiche health summaries with essential medical information from all inpatient and outpatient facilities [131].

In 1983 the IHS implemented its Resource and Patient Management System (RPMS). This replaced the centralized PCIS, which had been programmed in COBOL language, and operated in a mainframe environment. RPMS used the VA Decentralized Hospital Computer Program (DHCP), which was programmed in the MUMPS language, used the DHCP File Manager database management system, and operated in a distributed minicomputer setting [30]. At the end of the 1980s, a typical RPMS configuration in a health facility included patient registration, pharmacy, dental, maternal and child health, contract health services, and laboratory, together with its Patient Care Component (PCC) [69]. The PCC of the RPMS used the File Manager database and provided a computer-based patient record for the collection, storage, and retrieval of the patient health data from all sites. Ultimately, the patient’s health information from multiple facilities was integrated in the PCC database at each site where the patient had an active medical record. Revised multipurpose forms were still used for collecting patient data, and the originals were filed in the patients’ paper charts. A data entry module featured English language textual data entered from PCC encounter forms, with automated coding of the data where necessary. At that date the health summary report was the principal output of the PCC. A structured report extracted from the PCC database, it was displayed in a standardized format, printed routinely whenever a patient was seen, and updated by the entry of new data from the encounter forms. The health summary included an integrated report of the patient’s demographic data, an overview of the medical history, a list of active medical problems, inpatient and outpatient visits, recent medications, laboratory test reports, allergies and immunizations, and health reminders. The facility’s visual display terminals permitted users to retrieve a variety of other reports from a displayed menu. In 1989 the IHS had the PCC operational in 53 sites.

2.2 Veterans Administration Decentralized Hospital Computer Program (DHCP)

In the 1980s the Veterans Administration (VA), an agency of the federal government, operated 172 hospitals and 229 outpatient clinics. There were about 26 million veterans in the United States; the VA provided care to 1.5 million inpatients and furnished almost 20 million outpatient visits per year to these veterans. The VA was the largest centrally coordinated civilian health care system in the United States.

Since the 1950s the VA had maintained, in Chicago, a national centralized computer-based file of all VA patients that included their identification data, claims, and Social Security numbers. A Patient Treatment File contained inpatient admission and discharge data including diagnoses, surgical procedures, and patient disposition data. Initially, each month every VA hospital submitted a deck of punched cards to the processing center. Each card represented data covering a completed hospital episode for an individual patient [23]. They soon extended the Patient Treatment File to include outpatient visits and used this central database as their Automated Management Information System (AMIS) at the Veterans Administration Central Office [110]. Data from clinical records in all VA treatment facilities were coded locally onto standardized forms, and these coded data forms were sent to the computer center for editing and entry into the computer. These data were used primarily for statistical analyses by the VA Administration [28].

In 1960 the VA began to explore the use of computers in its medical program when it reached an agreement with the Systems Development Corporation in Santa Monica, California, to use the Los Angeles VA Center and the Wadsworth General Medical and Surgical Hospital to prepare a comprehensive HIS functional requirements description. Successful implementation of the total simulated hospital operations was started the last week of March 1962 [133]. In 1965 the VA installed a pilot Automated Hospital Information System (AHIS) in its 710-bed hospital in Washington, DC. They used an IBM 360/40 computer with 40 input-output terminal devices consisting of IBM 1052 typewriters and IBM 1092 keyboards with variable-overlay plastic key mats. Plans were to develop subsystems corresponding to the organizational divisions of the hospital: admissions and dispositions, medications, laboratory, radiology, dietetics, surgery, central services, clinic and ward care, patient information, and medical administration [111]. A regional data processing center was to collect and store the current patient-treatment data while the patient was in the hospital. Any permanently required data would be transferred into a Patient Treatment File in a central database, which would serve as the historical record of all treatment episodes for each person served by a VA medical installation. Budd [19], then chief data manager of the VA, reported that they expected the date for completion of the pilot AHIS project in September 1967. In 1968 and 1969, several modules were reported as being operational in the VA hospital in Washington, DC [24]. However, this pilot system was soon found to be an inadequate solution for the VA’s requirements for an MHIS, and the pilot project was terminated. During the 1970s a variety of clinical computer applications were developed independently in several different VA hospitals, mostly using MUMPS software for applications programming and File Manager as the database management system [71].

The File Manager had its origin in the early 1970s at the Beth Israel Hospital in Boston as the MISAR application package [73]. MISAR (Miniature Information Storage and Retrieval System) was developed by Karpinski and Bleich [75] as a general-purpose, time-sharing, information storing and retrieval system that facilitated the rapid creation, maintenance, and searching of small data files. In 1978 the rewriting of the MISAR II program from a dialect of MUMPS into the Standard MUMPS language, while adding a substantial number of desired enhancements, was undertaken by a San Francisco VA hospital staff member [73]. The VA File Manager allowed the user to define new files; add new attributes to existing files; enter, edit, and delete data within those files; and then list or search the files for any combination of data elements [126]. Hauser [57] extolled the importance of the advocates of the MUMPS language in the development of the DHCP by noting that there were two non-VA organizations which had significant roles in the success of the DHCP, namely the MUMPS Users Group (MUG) and the MUMPS Development Committee (MDC), custodian of the MUMPS ANSI standard. Many VA medical professionals employed professional networks and used MUMPS to create small prototype applications in the clinic setting; this grass roots effort was dubbed the MUMPS “Underground Railroad.”

In February 1982, to provide some central management, the VA Administrator developed a policy of support for the decentralized computer operations in the VA medical centers, and directed the establishment of six regional Verification and Development Centers (VDCs) to assist with the implementation of computer-based medical applications at the medical centers. In addition, a VA Project Management Task Force was formed to compile an inventory of computer capabilities in the field and to develop plans for implementing existing in-house developed software on available computers. In June 1982 the Medical Information Resources Management Office (MIRMO) was established to further the task force’s objectives by assisting with the creation of the regional VDCs, developing a complete Department of Medicine and Surgery (DM&S) Automated Data Processing (ADP) Plan, and formulating procurement and budget strategies in support of field ADP needs [34]. Originally MIRMO had been given the responsibility for the planning, direction, and control of the DM&S information-system development program, but its overall responsibilities were re-delegated to the VA’s regional directors and the VDCs. In April 1983 DM&S published its first ADP Plan that identified the major objectives of the Veterans Administration Decentralized Hospital Computer Program (DHCP): (1) Provide adequate ADP support for key functions in all VA medical centers; (2) Implement an integrated DM&S management information system; (3) Decentralize to the field the responsibilities for ADP planning, budgeting, and operations to the maximum extent possible; and (4) Improve the management of information resources [34].

In 1983 Special Interest User Groups (SIUGs) composed of field- and central-office program-area experts were established, and they initiated a department-wide computer literacy effort. The high degree of decentralization in the VA Decentralized Hospital Computer Program (DHCP) was demonstrated by the great responsibilities delegated to the SIUGs for system development. The SIUG’s many responsibilities were to: (1) Recommend development, enhancement, and modification of a data processing system, and work closely with the Verification and Development Centers (VDCs) which were assigned the primary responsibility for the software development. (2) Establish priorities for system development. (3) Develop and maintain functional requirements for DM&S automated systems. (4) Provide professional assistance to the VDCs in the specialty area. (5) Assist VDCs in system validation and certification. (6) Recommend means for resolving conflicts between automated systems and the current modes of operation. (7) Participate in implementation planning and execution. (8) Monitor the status of system development in the specialty areas. (9) Represent the program area in DHCP/CORE activities. (10) Serve as an advocate for program-area interests in the competition for system resources (DM&S [35]).

Great authority was granted to the six Verification and Development Centers (VDCs), one for each VA medical region and to their Council, to ensure uniform and compatible systems throughout the VA. This arrangement essentially delegated oversight, direction, and control of the DHCP to the VDC Council. Each VDC provided a central point of technical expertise and support for its region and was responsible for installation, implementation, support, and maintenance of the DHCP CORE and all CORE applications in each VA medical center (VAMC) within the region. It was responsible for dissemination of standard programs, for new releases of existing programs and locally developed software, and for maintenance of an inventory of all software. The VDC assisted in the preparation, review, and approval of facility data processing plans. Some VDCs were also responsible for the development and maintenance of CORE software modules. The VDC Council was composed of six VDC directors, and was responsible for recommending software development and verification, and for providing guidance to the VA in the implementation of the DHCP. Coordination of activities at a national level was established to prevent duplication of effort, to assure exportability of systems, and to assure the rapid development of a complete VA Management Information System made possible by VA Standardized Data Dictionaries in use at every VAMC. To carry out the continuing decentralized effort, the DHCP was initiated and administered by the DM&S. Within the DHCP a DHCP Kernel and a DHCP CORE system were developed, both written in the MUMPS programming language and sharing a common patient database.

A set of software tools for database management, electronic communications, security, and software management, the Kernel provided the basic tools that held the system together and provided the means for individual sites to adapt to their unique user, database, and security needs. The Kernel allowed both centrally developed and locally adapted software to coexist [99]. Composed of routines that interfaced DHCP application packages with the MUMPS operating system, the Kernel insulated applications from operating system-specific concerns, and allowed the writing of applications that would run on any MUMPS operating system. The Kernel included the VA FileMan (File Manager), which was the database for the DHCP. Initially the CORE system of applications included patient identification and registration, admission/discharge/transfer, ward census, clinic scheduling, and outpatient pharmacy. The Full VA CORE system added inpatient pharmacy, clinical laboratory, and radiology [71]. The Full CORE system was planned for all VAMCs, with terminals located on wards for order entry and ward reporting.

Developers of the DHCPs recognized the importance of system and data standard ization, and the difficulty of achieving standardization in a decentralized operation. Before any program was put into operational use at more than one location, it was verified by one of the Verification and Development Centers (VDCs). The Kernel database approach allowed system users to modify the CORE system at its local level; for example, by appending extra fields to the standard data elements of the CORE database, without foregoing standardization. The format, definition, names, and range of values of the CORE data elements were mandatory and could not be changed by an individual VAMC. The Department of Medicine and Surgery (DM&S) established a VA Hospital Information Systems Data Dictionary to mandate a common data structure for use in the various field-developed systems, and to insure standardization throughout the hospital network. By December 1987 the DHCP Data Dictionary comprised several volumes. For example, the second volume contained for each data element, a file location, label, type, and description. It had a glossary of specific terms used by the inpatient pharmacy and clinical laboratory. VA Medical Center (VAMC) directors had the authority to add optional application programs; they produced an Enhanced DHCP Software that was developed in the standard MUMPS programming language in various VAMCs, and was made available to other VAMCs that had a need for such support. Although not considered part of CORE, the Enhanced DHCP software was used in conjunction with the CORE system, sharing the same patient database. Enhanced DHCP software included the medical service, surgical service, radiology, dietetics, patient records tracking, nursing, mental health, social work, dentistry, and engineering. In 1982, so that they would conform to generally used community hospital standards, the computer programs were modified to permit the Patient Treatment File to calculate patients’ length of stay, average daily census, projected annual hospital days, and required hospital beds. Later, an algorithm was added to adjust for diagnostic related group (DRG) classification for claims reimbursement [76]. In December 1982 legislation was passed that supported the VA program and directed the agency to concentrate its resources on DHCP implementation and to provide a single VA patient database that could be accessed by all users.

In 1983 the U.S. Congress, which controlled the VA’s budget and had repeatedly directed the VA to examine commercially available vendor HISs, mandated (as it also did for the DoD TRIMIS program) that the VA procure, install, and assess three competing commercial HISs and compare their effectiveness for the VA DHCP . In April 1986 the Congress’s House Appropriations Committee requested an investigation be made into the progress of the medical computer program of the VA. The committee reported that VA DHCP contracts were awarded in 1984 to Shared Medical Systems for the Philadelphia VAMC; to McDonnell-Douglas Health Systems for the Saginaw, Michigan, VAMC; and to Electronic Data Systems for the Big Spring, Texas, VAMC. They were designated by the VA as the VA Integrated Hospital Systems (IHS) Program and were scheduled to end in 1987. The Medical Information Resources Management Office (MIRMO) awarded a $2.9 million contract to A. Andersen to perform an objective evaluation of the three IHS test sites and to compare them to the VA DHCP. The House Appropriations Committee Report pointed out that the DHCP was not required to document performance, objectives, schedules, or fixed and operational costs, whereas the vendor Integrated Hospital Systems (IHS) sites were required to do so; thus comparable evaluations were not possible. The VA provided little management or staff support to carry out the IHS program, and it was generally acknowledged that the VA DHCP in the mid-1980s could not equal the capabilities of the commercial systems [26]. The 1984 DM&S ADP Plan reported that 429 DEC PDP 11/44 computers had been procured at a cost of $48 million. Implementation of the DHCP Full CORE system began in 1985; in that year, the VA Decentralized Hospital Computer Program (DHCP) installed computer systems in 169 medical centers with the basic software package called the Kernel.

The Kernel was now written entirely in American Standard National MUMPS and included: FileMan (a database management system, data-entry editor, report writer, and data dictionary); MailMan (a computer-based messaging, teleprocessing, and networking system); a log-on security system; and a set of programs and tables to allow applications programs to be written in a manner independent of device; operating systems, communications protocols, and vendors [100]. A VA Integrated Planning Model was also developed in 1987 that ran on minicomputers and was programmed in the Pascal language [76]. A strong training program for users of DHCP contributed to the successful implementation of various modules. Computer overview classes were mandatory for all users and were held at least once a week. Attempts were made to teach physicians, nurses, etc., in professional groups, thus allowing user-specific issues to be addressed in the class; training manuals were developed as an important adjunct [20].

An independent review of the VA’s DHCP conducted by the Office of Technology Assessment (OTA) of the U.S. Congress in 1987 produced an OTA VA report recommending that, if the VA was to implement at least a minimum level of automation in all its hospitals within the next year or two, the OTA found no reasonable alternative to the VA DHCP since DHCP modules offered reasonable features and functions to meet the VA’s near-term needs for hospital information. In the long term DHCP might have limitations that could make it an unsuitable platform for the transition to the information system VA would need in the 1990s [105]. The OTA report included an analysis of the VA DHCP’s costs: VA historical cost data and projections for the period 1983 through 1987 indicated that the total costs for Core Plus 8 would be about $1.1 billion. VA’s 10-year (fiscal years 1987–1996) lifecycle costs were estimated at about $930 million for six Core modules plus eight Enhanced Modules [105]. Since the VA Decentralized Hospital Computer Program was not yet an integrated system, but was rather a series of interfaced applications, the OTA report addressed its capability to integrate patient data entered and retrieved from the various system modules, a critical requirement of any MIS. A shortcoming observed in DHCP was the order entry/result reporting function that was inherently difficult to operate due to the separate development of the pharmacy, laboratory, and dietetics modules used on the nursing wards [105]. Andrews and Beauchamp [3] described the development of a pilot integrated uniform database (UDB) to extract patient data from the separate laboratory, pharmacy, and radiology databases installed at the Sioux Falls, South Dakota, VAMC. They found it difficult to integrate information across the modules, so they wrote a new set of programs, the clinical database management system (CDMS) that supported the UDB; and was used to assist most clinical functions. While the file structures were created and maintained with FileMan, the CDMS provided utilities for queries, reporting, entry, and translation of data from ancillary packages into the UDB, and provided some decision support. By the end of 1989 the DHCP contained clinical management packages for inpatient and outpatient pharmacy, clinical laboratory, radiology, anatomic pathology, blood bank, dietetics, medicine, surgery, oncology, nursing, mental health, dentistry, social work, quality assurance and utilization review, order entry, and results reporting. A health summary served as the beginning of a computer-based patient record that integrated clinical data from ancillary support packages into patient health summaries for viewing by clinicians on display terminals or as printed reports. VA admission, discharge, and transfer (ADT) module functioned as the focal point in the collection of patient information for DHCP to encompass demographic, employment, insurance, and medical history data; and was used by other DHCP subsystems including laboratory, pharmacy, radiology, and dietetics [35]. The decentralized nature of the VA DHCP program was clearly shown in its November 1989 report, which detailed the responsibilities of each of the VDCs, now called Information Systems Centers (ISCs): (1) The Albany ISC was responsible for the radiology, ADT, medical administration, and outpatient-scheduling and record-tracking packages; (2) Birmingham ISC for pharmacy, surgery, and social work; (3) Hines ISC for dietetics, nursing, and quality-assurance; (4) Salt Lake City ISC for laboratory, pathology, mental health, order entry and results reporting, and health summary; (5) San Francisco ISC for the Kernel FileMan; and (6) Washington, DC, for oncology, medicine, dentistry, library, and MailMan, in addition to Integrated-Funds Control, Accounting, and Procurement (IFCAP) [35].

In 1988 DoD awarded a contract to Science Applications International Corporation (SAIC) of San Diego, California, to implement DoD’s Composite Health Care System (CHCS) with a MUMPS-based system derived from the VA DHCP experience [98]. At the end of 1989, the VA decided to award a contract for $52 million to SAIC to install health information systems at three of its medical centers [97].

2.3 Department of Defense Composite Health Care System (CHCS)

The Department of Defense (DoD) oversees a large health care delivery system with many and varied facilities that are managed and operated by the three armed services: the Army, Navy, and the Air Force. DoD provides a full spectrum of clinical and hospital services throughout the world to active-duty and retired military members and their eligible dependents, while it maintains a constant state of readiness to support the national defense. In the 1970s within the continental United States, there were nearly one million hospital admissions and about 35 million outpatient visits annually. Military medical facilities within the continental United States then numbered 126 hospitals; the 4 largest had up to 1,000 beds. All medical facilities had extensive outpatient services, with the largest having two million patient visits per year; and there also were several hundred free-standing clinics.

In 1959 the U.S. Air Force Research and Development Command at Andrews Air Force Base undertook with the Lovelace Foundation the development of a database on punched cards for the Air Force’s Man in Space program. Data from a fairly comprehensive medical examination were recorded on mark-sense cards. The decks of cards were transferred to an IBM facility at Kirtland Air Force Base, where the data were assembled and were used to select candidates for the National Aeronautics and Space Administration (NASA) program [115]. In 1968 the Secretary of Defense directed that studies be made to determine the feasibility of improving health care delivery within DoD through the use of automated data processing. The period during the late 1960s and early 1970s also saw independent development efforts within each of the three armed services. In the late 1960s, with the Air Force as lead service, DoD undertook a project with A.D. Little, Inc. that resulted in a nine-volume, Systems Analysis for a New Generation of Military Hospitals [86]. Its aim was to use computers to improve patient care and to help to control resource consumption with a prototype hospital; but this hospital was never built [4]. In 1971 Craemer initiated service with an outpatient information system (OIS) at the U.S. Naval Air Station Dispensary in Brunswick, Maine, a primary care clinic that served about 15,000 active-duty and retired Navy personnel and their dependents (about 20,000 visits a year). Physicians dictated their patient care notes, and the full text was entered by transcriptionists using display terminal keyboards. The patients’ medical complaints and diagnoses were coded, and then were stored by keyboard entry. Laboratory findings were entered by the clinical laboratory. Computer services were provided by a commercial vendor located about 130 miles away. The medical record available during a patient’s visit was a computer-generated abstract that contained a limited amount of essential medical data. During the visit, more medical record data could be obtained, if needed, within a few seconds from the terminal on an online basis [64].

In 1973 the Defense Systems Acquisition Review Council (DSARC), with the concurrence of the three Surgeons General, recommended that the automated information systems development efforts of the three military departments be combined into a single tri-service program. In July 1974 the Deputy Secretary of Defense established the Tri-Service Medical Information Systems (TRIMIS) Program [15]. The mission of TRIMIS was defined as to: (1) Improve the effectiveness and economy of health care delivery administered by the Military Departments, through the application of standardized automatic data processing (ADP) techniques to health care information systems; (2) Centralize and coordinate the application of existing technology and the development of standardized automated systems to meet the Tri-Service functional requirements in the medical area; (3) Adapt advanced data automation technology to health care delivery, and streamline, modernize, and standardize DoD medical information systems [127]. Initially the TRIMIS requirements and direction were provided by the three Surgeons General. However, in June 1976 the TRIMIS Program Office (TPO) was formed, and its direct management was taken over by the Assistant Secretary of Defense for Health Affairs. Responsible for planning, budgeting, and managing program activities, the TPO focused its activities on achieving three related objectives: functional (work-center) applications to improve patient care; resources to improve management applications; and integration of functional and management applications into an overall replicable system to be applied first for a single hospital, and then for successively larger entities. The TPO centrally funded all tri-service systems and provided coordination and direction for the program. The Assistant Secretary of Defense for Health Affairs managed the TRIMIS program with the advice and guidance of the TRIMIS Steering Group. In addition to the three Surgeons General, this group included the Principal Deputy Assistant Secretary of Defense for Health Affairs as Chair, the President of the Uniformed Services University of Health Sciences, and representatives of the VA and HEW. In addition, three defined critical milestones in the procurement and diffusion of TRIMIS systems had to be reviewed and approved by the Major Automated Information Systems Review Council (MAISRC), which consisted of the Assistant Secretary of Defense Comptroller as Chair, the Assistant Secretary of Defense for Manpower, the Assistant Secretary of Defense for Health Affairs, and the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence.

A TRIMIS Peer Review Group was assembled in 1978. An interdisciplinary body of nationally known experts from outside the Government, the group reviewed various aspects of the TRIMIS Program several times a year and provided their assessment of the Program’s progress and activities to the Assistant Secretary of Defense for Health Affairs [14]. Managed in the late 1970s by Roberts of Medical Systems Technical Services, Inc., under contract with the National Bureau of Standards, throughout the 1980s, the group was managed by Simpkins of Battelle Laboratories through a contract with the TPO. Collen (Director, Division of Research, Northern California Kaiser Permanente), Cunningham (formerly Chief, ADP Management Branch, ODP), Dammkoehler (Department of Computer Sciences, Washington University), and McDonald (Chief Scientist, Missile System Division, Rockwell International Corporation) were continuing members of this Peer Review Group from 1978 to 1989. Other members who participated in the Peer Review Group in the later 1970s, included Cox (Washington University), Lindberg (University of Missouri-Columbia), Reals (University of Kansas-Wichita), and Sorensen (Southern California Permanente Medical Group). In the later 1980s, they included Ball (University of Maryland Baltimore) and McDonald (Indiana University).

The basic planning document that guided TRIMIS decision-making within this rather complicated environment was known as the TRIMIS Master Plan (TPM) produced in the TPO in February 1977 [14]. The TMP was an overall technical approach to address its objectives through three levels of automated data processing capabilities, namely, the work center, the medical treatment facility (MTF), and DoD higher command; all were to be implemented through a four-phase time schedule. In phase I, Initial Operational Capabilities (IOCs) pilot systems were to be acquired by competitive procurements of commercially available applications modules to support selected high-volume work centers. Other than to accommodate such features as unique military data elements, there was to be no major modification to these systems. The strategy was for these IOC subsystems to achieve a significant level of standardization of their functional and operational characteristics within the work centers so that the experience gained from using these systems would lead directly to the determination of the functional specifications for the next phase. In phase II, Standardized TRIMIS Systems would evolve to permit some expanded functional support of additional work centers; to develop applicable TRIMIS standards necessary for integration of the initial modules; and to design a network-integrating system. In phase III, a Composite Hospital System (CHS) would be designed from the experience gained in the first two phases and culminate in specifications by which the Standardized Systems would be integrated within the medical treatment facilities (MTFs). In phase IV, a DoD Health Care Information System (HCIS) was to be implemented to manage both resource and patient-centered data on a system-wide basis; collect transaction data from a CHS or from Standardized Systems; provide patient record data and resource management data to multiple MTFs; and provide data to facilitate reporting requirements above the MTF level [127].

The initial DoD Master Plan was for the TPO to acquire the major automated support for the military treatment facilities in three procurement steps. First, a limited number of systems were to be procured to satisfy the immediate support requirements of the three armed services in four functional work centers: laboratory (LAB), pharmacy (PHARM), radiology (RAD), and patient appointment and scheduling (PAS). Next the principal thrust would be to interface these four modules in an operational environment through the development of a DoD Network Interface System. Finally, integratable systems to fulfill the CHS requirements were to be acquired in sufficient quantity to support all treatment facilities justified by the armed services. In advance of the development of the TRIMIS modules in the mid-1970s, each of the three services was allowed to proceed with some pilot automation projects in their larger hospitals. A clinical laboratory system was installed at Wilford Hall Air Force Medical Center; a pharmacy system at Charleston Naval Hospital; a radiology system at San Diego Naval Hospital; food service and hospital logistics systems at Walter Reed Army Medical Center.

One of the earliest TPO cost-benefit analyses was reported in 1978 for a Tri-Service Wards and Clinics Support module implemented as a part of the early CHS. It compared the automated system’s costs and benefits to the traditional manual alternative in three medical treatment facility sites: the Naval Regional Medical Center, Jacksonville, Florida; the U.S. Air Force Regional Hospital, Eglin AFB, Florida; and the Dwight David Eisenhower Army Medical Center, Ft. Gordon, Georgia. Based on actual 1977 data from these three sites viewed as a single regional system, the total (11 years, discounted) cost for the TRIMIS system was 0.5 % less than for the manual system. The following were identified as quantified advantages of implementing the TRIMIS system in the hospital and clinics: reduction in the cost of patient services, notably of redundant or unnecessary services delivered to the wrong location or after the patient had left; reduction of clerical support required; improvement of outpatient pharmacy management and control; reduction in administrative supplies costs; and relief from an excessive clerical workload burden on military health care providers in reduction in patient non-effective time and time away from active duty. Unquantifiable benefits attributed to TRIMIS were improvements in the quality of information associated with patient care through more thorough accumulation, systematic organization, and accurate transmission. TRIMIS reduced the interval required to transmit information on admission, patient status, physicians’ orders, diagnostic results, and supportive services throughout the medical treatment facility; and improved the accuracy of information by providing system edits that reduced the number of opportunities for error and the automatic transmission of multiple errors. By capturing data at their source, TRIMIS improved resource utilization, collected data for research and peer review activities, and supported consistent and reliable patient care planning and its documentation for the medical record [127].

By 1979 TRIMIS had made considerable progress with the procurement and installation of its phase I nonintegrated modules. In that year, the program provided full funding and management-support coordination for a number of existing operational, interim, and pilot systems. These included the following:

  • Clinical Laboratory (AFCLAS/TRILAB and LABIS) systems at USAF Medical Center, Wright-Patterson AFB, Ohio; Malcolm Grow USAF Medical Center, Andrews AFB, Maryland; and the National Naval Medical Center, Bethesda, Maryland.

  • Pharmacy (PROHECA/Data Stat) pilot systems at the Naval Regional Center, Charleston, South Carolina; Naval Hospital, Beaufort, South Carolina; USAF Clinic, Charleston AFB, South Carolina; Naval Weapons Station Clinic, Charleston, South Carolina; Outpatient Clinic, Charleston Naval Base, South Carolina; USAF Regional Hospital Shaw, Shaw AFB, South Carolina; and Dwight David Eisenhower Medical Center, Augusta, Georgia.

  • A Tri-Service Formulary at Health Services Command, San Antonio, Texas, that supported 77 health care facilities.

  • A Medical Administrative Management System at USAF Regional Hospital, McDill AFB, Florida; USAF Medical Center, Wright-Patterson AFB, Ohio; Wilford Hall USAF Medical Center and Lackland AFB, Texas.

  • A Patient Registration System at Walter Reed Army Medical Center, Washington, DC.

  • An Interim Hospital Logistics System and an Interim Food Service System at Walter Reed Army Medical Center, Washington, DC.

  • An Automated Multiphasic Health Testing system at National Naval Medical Center, Bethesda, Maryland.

  • A Clinical Decision Support system for hypertension and diabetes at the Naval Regional Medical Center, Oakland, California [14].

At that time TRIMIS also installed a Computer Assisted Practice of Cardiology (CAPOC) system at the Naval Regional Medical Center, San Diego, California, to provide electrocardiogram analysis to military facilities in southern California and portions of Nevada. They were also procuring an Automated Cardiac Catheterization Laboratory System (ACCLS) to provide 12 existing manual cardiac catheterization laboratories with a computer processing capability [14]. In 1979 the TPO had satisfied its phase I requirements. It had acquired an adequate number of commercial stand-alone Initial Operational Capabilities (IOCs) work-center systems and had installed them in military treatment facilities for pharmacy, laboratory, radiology, patient administration, and patient appointment and scheduling. The implementation of the IOCs created some user problems, since each was a separate operating unit, and without an integrating system, the professional users had to access each module individually to retrieve data from their respective databases. In February 1979 the Major Automated Information Systems Review Council (MAISRC) approved the installed IOCs as having achieved Milestone 0 for the TRIMIS program and authorized their further implementation to provide interim support in the larger DoD hospitals until replaced by the soon-to-be-initiated Composite Health Care System (CHCS). December 1984 became the target date for Milestone I to obtain the approval of the functional requirements, developed from the experiences of using the IOCs by the three armed services, for the core modules to be included in its phase II Network Interface System. These core modules included patient administration, patient appointment and scheduling, nursing, clinical laboratory, radiology, pharmacy, and clinical dietetics [129].

In March 1979 the TRIMIS Program Office received a critical report from Congressman Brooks, Chair of the House Committee on Government Operations, which stated that the TPO had spent or obligated approximately $70 million on TRIMIS since DoD assumed responsibility in 1974; that this money, for all intents and purposes, had been wasted; and after 5 years of operations few concrete results could be found. The Brooks report included a strong recommendation to terminate the outside contractor, a major reorganization of the TPO structure should be undertaken if the TRIMIS concept was to be saved; and systems to be procured, at least initially, should be commercial off-the-shelf items [17]. It was apparent to TPO and to the Peer Review Group that the Congressman had not fully appreciated the substantive accomplishments of TRIMIS under its many difficult constraints. Following the Brooks report, the TPO decided to skip phase II and to move directly into phase III, and to develop the requirements and plans for the acquisition of a comprehensive, fully integrated system, now called the Composite Health Care System (CHCS).

In 1980 the U.S. Congress directed the DoD to install and assess two or three competing commercial HISs, as it had for the VA. As a result, in 1982 DoD awarded three separate contracts to two vendors: Technicon Data Systems to install its system in the William Beaumont Army Medical Center at Fort Bliss, Texas, and Martin Marietta Data Systems to install its system in the Naval Regional Medical Center at Jacksonville, Florida, and in the U.S. Air Force Regional Hospital at Eglin Air Force Base in Fort Walton Beach, Florida. Using a phased approach, the plans selected by the Air Force and the Naval facilities consisted of initially bringing the registration, admission, disposition, and transfer module online [67]. This was to be followed by outpatient appointment scheduling and order entry and results reporting for pharmacy, laboratory, and radiology, with inpatient applications to be implemented last.

In 1981 A.D. Little, Inc. was awarded a contract to evaluate the TRIMIS IOC systems and to provide information needed for the decision regarding further system proliferation. Based on evaluations already completed, A.D. Little’s project director, Drazen, estimated that the annual benefits of automated information systems in DoD medical treatment facilities would be derived from the following: 31 % from increased service capacity resulting from more effective utilization of the DoD health care system due to fewer repeat clinic visits because of missing laboratory tests, and a reduced length of hospital stay from more timely test reporting and earlier initiation of treatment; 28 % from increased availability of time on the part of the health care provider from less time spent in searching for charts and test results; 15 % increased availability in staff time due to less clerical time spent in scheduling, registering, and maintaining records; 15 % from improved patient health status from better review of care plans and treatments and automated monitoring of adverse drug reactions; 7 % increase in availability of effective time of military personnel due to less of their time being spent in obtaining needed office visits; and 4 % in other savings [37].

Because of its concerns about the possible duplication of effort between the DoD and the VA, Congress directed DoD to test the feasibility of using the VA Decentralized Hospital Computer Program (DHCP) software [26]. The MITRE Corporation had in 1984 completed an assessment of the VA DHCP ’s ability at that date to satisfy the functional requirements of the DoD’s CHCS; and it reported that the TRIMIS functionality demonstrated by the VA system was adequate for the CHCS [96]. Tests were carried out using the VA DHCP software at March Air Force Base in Riverside, California, and at Fitzsimmons Army Medical center in Aurora, Colorado, to test the feasibility and cost-effectiveness of the VA DHCP in DoD MTFs. To determine the cost and level of effort required to meet the Composite Health Care System (CHCS) requirements using DHCP as a baseline [93]. Some evaluation results were reported, such as the early findings from A. D. Little on the VA Patient Appointment and Scheduling (PAS) module of the DHCP at March Air Force Base that had been chosen because of the high priority placed on this application by its hospital commander. The VA PAS was readily modified to meet the requirements of March Air Force Base; its users were generally pleased with the system [50].

In 1984 to accomplish a more complete integration of all the military MISs, the Assistant Secretary of Defense for Health Affairs established the Defense Medical Systems Support Center (DMSSC) composed of six program offices: TRIMIS and Hospital Systems; Defense Enrollment Eligibility Reporting System (DEERS); Medical Readiness and Theater Systems; Management Information Systems; Architecture, Communications and Technology; and Quality Engineering. Mestrovich, who had headed DEERS, was appointed the first director of DMSCC. In 1984 the experience gained from these assessments became the basis for the specific requirements developed for the Composite Health Care System (CHCS). In May 1985 the TPO released to commercial vendors a Request for Proposals (RFP) for the design, development, deployment, and maintenance of the CHCS. Detailed and comprehensive as to functional and operational requirements, the RFP kept technical specifications to a minimum to encourage competing vendors to use products they had already developed. The RFP specified that CHCS should support the full set of CHCS system capabilities for eight functional areas: patient administration (PAD), patient appointment and scheduling (PAS), laboratory, radiology, pharmacy, nursing support, clinical dietetics, and health care provider support. Detailed functional requirements for each of these areas were presented as appendices. The RFP further specified that the CHCS contractor should provide a Data Base Management System (DBMS) as the primary vehicle through which the CHCS database would be constructed, accessed, and maintained. The DBMS requirements for CHCS fell into seven major functional areas: general DBMS requirements, integrated data dictionary, data base management, data query and data transactions, report generator, DBMS backup and recovery, and data base utilities. TPO recognized the need for requiring a capability for maintaining the logical integrity of the data base [130]. It was also required that users of the DBMS had online access to their Integrated Data Dictionary, which was to have a set of basic characteristics that included unique identifiers, physical characteristics, and textual information for each data element; showed the relationships between elements; contained the official external name and acceptable synonyms for each data element, the type of units to be used for the data items (for example, degrees Celsius, milligrams); and the rules or algorithms to be used by the DBMS for data elements which were computed from the values of other data elements (for example, body surface area). An English-like query language was to be a highly supportive interactive display of the data dictionary, with prompts, HELP messages, query and modification status displays. The Report Generator was to have the capability of generating low-resolution simple graphic outputs such as scatter plots, histograms and pie charts; for data security, it required the capability to record the name of the user, the identification of the actual device used, and the dates and times of log-in and subsequent log-off. The CHCS System Manager was to have the capability to prevent dial-in access to CHCS without the System Manager’s approval for each dial-in session. The RFP required that CHCS have the ability to communicate with other external support services, including the Tri-Service Food and Tri-Service Logistics systems; and it specified that the CHCS Contractor should utilize the Reference Model for Open Systems Interconnections (OSI) developed by the International Standards Organization for these interfaces. It also required an interface with DEERS that provided the basic eligibility information on all DoD personnel. The RFP furthermore specified that the contractor should provide initial and follow-up training programs specific to military treatment facility users that included supervisors, professionals, and clerks and administrative personnel [130].

Earlier the TRIMIS Program Office had developed a statement that described the requirements for a Computerized Medical Record Information System (CMRIS) for both hospital and outpatient care, since the TPO had expressed the need that readily accessible patient medical information was necessary to provide the military health care provider with accurate, timely, legible, and well-organized medical information to support the patient’s treatment and follow-up care. Thus the CMRIS RFP required that the automated comprehensive medical record (inpatient and outpatient data) would be a component part of the Composite Health Care System (CHCS) database so that required data could be transmitted automatically [129, 130]. As a part of the CMRIS project and to obtain some experience with other computer-based patient records, the Computer-Stored Ambulatory Record (COSTAR) was installed in 1981 in the Family Practice Clinic in the Silas B. Hays Army Community Hospital at Ford Ord, California, [103] and also in the Family Practice and Primary Care clinics at the USAF Hospital Pease at Pease Air Force Base, New Hampshire, that used the time-sharing capabilities from G. Barnett’s Laboratory of Computer Science at the Massachusetts General Hospital [38]. Because the Brooks Congressional Committee considered the computer-based patient record and the health care provider functional requirements as “gold-plated” enhancements of CHCS, both of these requirements were removed from the 1984 RFP; and a second RFP for CHCS was released in March 1987. Even at the end of the 1980s, however, CHCS had not yet planned to provide an integrated, computer-based medical record, nor did it satisfy such functional requirements of the health care professional as the inclusion of patients’ medical histories, physicians’ physical examination findings, or consultation reports. These functions were to await a later phase of CHCS enhancements in the 1990s.

In September 1986 a stage I, cost-plus-fixed-fee contract was awarded to four contractors: TDS Healthcare Systems Corporation (formerly Technicon Data Systems), McDonnell-Douglas Health Information Systems, Science Applications International Corporation (SAIC), and Baxter International, Inc. The contracts specified that each was to develop a proposal to meet the functional and technical requirements of CHCS. Since a system design was not specified in the contract, the vendors were allowed considerable flexibility in this regard, but TDS Healthcare Systems soon withdrew from this contest. Following extensive tests, demonstrations, and evaluations, DoD conducted a complex, competitive bidding process among the remaining vendors. In March 1988 the Milestone II review was completed that authorized proceeding with the installation of CHCS in selected sites; and DoD awarded a stage II fixed-price contract in the amount of about $1.1 billion to SAIC for the development and deployment of CHCS. The report of the Source Selection Evaluation Board concluded that SAIC was clearly superior to its competitors: it developed more health care functionality, offered the only completely integrated system, received slightly better ratings than its nearest competitor in management, and slightly lower ratings than the highest-rated competitor in deployment. In addition its system cost was significantly less than the nearest competitor’s system. The U.S. General Accounting Office (GAO) published a report that called the selection process results fair and reasonable [48].

An employee-owned company in San Diego, Science Applications International Corporation (SAIC) used a major software contractor, Di-Star, whose founders had helped develop the MUMPS-based VA DHCP [70]. MUMPS users were delighted with the selection of SAIC and its proposed MUMPS-based CHCS, and published an announcement that DOD had awarded to SAIC a $1 billion, 8-year contract for a MUMPS-based integrated hospital information system. SAIC’s major subcontractor for most of the CHCS hardware components was Digital Equipment Corporation (DEC). The selected CHCS architecture was to be decentralized at the hospital level, with a mainframe computer in each hospital linked to its associated clinics with a communications network. Independent clinics that were separate from hospitals were to receive their own mainframe computer. All software was to be written in ANSI-standard MUMPS. The database manager was FILEMAN, an updated version of the VA’s FileMan. A comprehensive data dictionary, SCREENMAN, provided a standard terminal-display presentation and editing tool. TASKMAN allowed control over the timing and priority of both interactive and batch processes. MAILMAN provided electronic mail to all users.

Mestrovich [93] described the planned operational features of CHCS in 1988. The CHCS would provide the health care providers with patient care data through integration with the functional work centers of clinical dietetics, laboratory, nursing, patient administration, patient appointment and scheduling, pharmacy, and radiology. It would assist health care professionals by providing support to the entry of orders and the reporting of results, and support administration in quality assurance, management of resources, mobilization, and mass casualty operations. CHCS would also provide interfaces to other TRIMIS and DoD activities such as the Medical Expense and Performance Reporting System (MEPRS), DEERS, food service, medical logistics, service-specific administrative systems, tactical automation systems, national disaster medical system, and the VA systems. CHCS would provide support to military hospitals, clinics, dental clinics, and Service schools throughout the world. Eventually 14 sites were selected for Stage II CHCS beta testing: the Bethesda, Camp Lejuene, Charleston, and Jacksonville Naval hospitals; the Carswell, Eglin, Keesler, Shaw, and Shepard Air Force hospitals; and the Eisenhower, Ireland, Nuernberg, Tripler, and Walter Reed Army hospitals. By the end of 1989 DoD had ten operational CHCS beta test sites; and deployment activities were under way at four additional sites for operational testing and evaluation [2]. Most of the stand-alone IOC modules were expected to be replaced in the early 1990s by CHCS installations.

Following full deployment, the annual operating cost of CHCS in 167 military hospitals and 583 clinics worldwide was estimated at $108 million [93]. This level of expenditure obviously called for appropriate cost-benefit evaluations. The TPO prepared a two-stage Test and Evaluation Master Plan (TEMP) to review and monitor in selected sites the extent to which the installed CHCS fulfilled its specified functional and technical requirements. The first stage included pre-installation and acceptance testing to see whether the contractor’s system met the functional and technical requirements prior to the system deployment. The initial alpha testing of CHCS software was conducted at Ireland Army Community Hospital in Fort Knox, Kentucky, and at Tripler Army Medical Center in Hawaii, after which the approved software was released to beta test sites. The second stage included installation and acceptance testing of the CHCS at each beta site. Data collection at the beta sites began at the end of 1988, and analysis and reporting of evaluation results of CHCS to be completed by Milestone III in the early 1990s, at which time worldwide deployment would be authorized. The A. D. Little group obtained a contract to provide a CHCS benefits assessment that used a list of 168 pre-specified measures and indicators as evidence of obtained benefits. Data that measured these indicators of potential benefits were to be collected at the beta sites (and also at matched non-automated control sites) prior to the implementation of CHCS (so-called “period X”) and scheduled for release in 1990. These period X data then would be compared to data collected for these same indicators after each CHCS site became operational (in “period Y”) in the 1990s [87]. The TPO was especially interested in the determination of any significant changes in the quality of health care services following the introduction of CHCS. The system would be assessed in regard to whether it effectively performed all the required functions in typical DoD medical treatment facilities; whether the process of delivering health care services became more efficient after the CHCS was introduced; whether the system was easy to use; whether it was flexible enough to handle future workload expansion and technological developments; whether the training procedures were adequate; whether the system provided the required security, confidentiality and data integrity without constraining legitimate authorized access; and whether the system exhibited in the operational environment, the desired reliability, availability, restorability and safety characteristics [128].

In the 1970s and 1980s the TRIMIS Program Office provided an instructive model for the development of a very large MHIS. The TPO first developed detailed functional requirements by user committees. It then procured, tested, and evaluated vendor-supplied, prototype, stand-alone modules for all major functional departments. Following this, it revised its functional requirements and technical specifications for integrating all modules into one CHCS. Finally, after competitive bidding, it contracted for a phased-in procurement and installation of CHCS in all of DoD’s worldwide military medical facilities. DoD also contracted for and completed an independent cost-benefit evaluation of CHCS. Despite its shortcomings, by the end of the 1980s, DoD’s CHCS represented the largest and most comprehensive MHIS in the world.

3 Mental Health Information Systems

Mental health information systems was the term used by Hedlund [61] at the University of Missouri-Columbia in a review of computers in mental health hospitals. Such systems attempted to integrate information about mental health care from a number of different sources in order to satisfy a variety of administrative and clinical needs. Laska [80] noted that the magnitude of the economic costs to society of mental illness was already immense. In the United States almost half of the hospital beds in the 1970s were set aside for the treatment of the mentally ill.

Glueck [51] described the operation of a psychiatry information system using an IBM 1440 computer, partially funded by NIMH, at the Institute of Living, a 400-bed private mental hospital in Hartford, Connecticut. Their first data reporting process used descriptive statements of patient’s behavior that were listed on punch cards. Numbers corresponding to the appropriate statements were circled, keypunched, and processed to produce a set of narrative statements corresponding to the patient’s behavioral index [51]. The primary objective of the computer project was the application of automated techniques to the clinical aspects of hospital care [13]. It was this system’s emphasis on clinical applications directed to individual patient care that served as an operational model for other mental health information systems [61]. By 1980 Glueck’s staff had developed programs in such areas as mental status, behavioral assessment, biofeedback monitoring, automated nursing notes, computerized education, and psychophysiological monitoring [27]. The need for adequate information about the mentally ill was so basic that the National Institute of Mental Health (NIMH) and many state departments of mental health shared in the financial support of many of the early mental hospital information systems. However, governmental support sometimes emphasized administrative needs over clinical needs of mental health institutions. This led Lindberg [84] to ask whether computer applications and systems in mental health were being shaped by exterior mandates such as the production of mental health statistical reports, and to advise that computers should be primarily used to help in patient care, to help to improve the lot of the patients, and increase our understanding of mental illness. Consistent with Lindberg’s advice, clinically oriented mental health information systems soon became more common.

Hedlund [61] credited the National Institute of Mental Health (NIMH) with funding the earliest mental health information systems, and reported that in the mid-1970s there were five multi-state mental health information systems in the United States. The Fort Logan Mental Health Center was one of the first to automate a relatively comprehensive psychiatric patient record system that became operational in 1961. In 1962 the Camarillo State Hospital in California, with NIMH funding, became what is generally considered to be the first large inpatient facility to attempt to computer- process comprehensive psychiatric case- record data in a time frame prompt enough to be of day-to-day clinical use. In 1966 the Missouri Division of Mental Health initiated a statewide information system. Begun as a joint project with the Missouri Institute of Psychiatry, a branch of the University of Missouri [119], the Missouri Mental Health Information System provided support to five large mental hospitals, three large community mental health centers, three state schools and hospitals for the mentally retarded, and nine smaller regional centers for the developmentally disabled.

Also in the 1960s a multi-state mental health information system was developed at the Rockland Research Institute in Orangeburg, New York, a state mental institution with a capacity of 5,200 beds, in a program that grew to involve seven states in developing a common computer-based patient record system designed to follow the patient through all phases of psychiatric service [79]. In 1966 Laska had used an IBM 360/30 computer for its computer-based electronic patient record (EPR) system at the Rockland State Hospital. In 1967, funded in part by a 5-year demonstration grant from the NIMH, the system was expanded to support five large mental hospitals, three large community mental health centers, three state schools and hospitals for the mentally retarded, and ten regional centers for mental retardation and developmental disabilities. Its software was compatible with IBM 360/370 model computers. In 1968 the IBM 360/30 computer was replaced by a 360/50 model and an IBM 360/44 computer was added for backup; each had direct-access disk drives and optical mark page readers. Remote terminals included an optical mark page reader and a keypunch machine linked to the central computer by telephone lines. In 1970 the files at Rockland contained more than 20,000 patient records from 13 facilities in seven states (Connecticut, Maine, Massachusetts, New Hampshire, New York, Rhode Island, and Vermont); and had about 300,000 patient records in its database.

Using a central IBM 370/155 computer in its Institute of Psychiatry, with remote terminals in each facility, it provided a computer-stored database for clinical and administrative information. Computer-generated reports provided clinicians, supervisors, and auditors with information about which patients had been treated, which patients were receiving what types of treatment for what types of problems, and which patients were receiving multiple or even incompatible medications [59, 61]. The electronic patient record included identifying data, examination and treatment data, medical problems, mental status examinations, medical and neurological examinations, medications, laboratory reports, and follow-up information after discharge. Users recorded the data by placing marks on forms that either were read directly by an optical mark reader to a card-punch machine or were keypunched. The forms were generally designed as multiple-choice checklists to reflect the clinical information from all health professionals who came in contact with the patient. The records included both hospital inpatients and patients seen in other psychiatric settings, such as clinics and community health centers. Data were transmitted in batches to the central computer over telephone lines from card-reader terminals located in each participating facility. The computer updated the patient’s record as indicated, and sent back a series of reports reflecting the information received. These reports included daily patient census, narratives based on mental status examinations, progress notes, and admission-record face sheets. The psychiatric services rendered to a patient could be identified in their continuity through different services in various types of facilities, for example, inpatient service in a state hospital or day care in a clinic. The same computer record followed as a patient moved from facility to facility.

In 1972 all participating states began contributing to its operating costs [29], and in 1974 this Multi-State Information System began to operate as a nonprofit, user-supported system. By 1975 they had added to their system the states of Hawaii, South Carolina, and Tennessee, as well as the District of Columbia [80]. In 1975 they replaced the IBM 360/50 computer with an IBM 360/67 model [131]. Their database contained all their accumulated patient records, in addition to information needed for generation and transmission of reports and reference tables. Each facility was allocated a storage area to contain its files. Since these computer-based storage areas were physically distinct, each facility’s data were protected from unwarranted access and accidental damage while the computer system processed another facility’s files. Provision was made within the database to link separate episodes within the patient records. In some facilities, the records for many episodes were linked together by the same case number. Other facilities allocated a new case number for each episode, including multiple episodes occurring within the same facility; these facilities, in most cases, used the patient’s Social Security number for linking episodes. The master patient record file and case index were stored on direct-access devices. Magnetic tapes were used to store historical copies of the patient files. In 1973 the files had grown to include approximately 165,000 patient records.

Using the central IBM computer in its Institute of Psychiatry, with remote terminals in each facility, it provided a computer-stored database for clinical and administrative information. Computer-generated reports provided clinicians, supervisors, and auditors with information about which patients had been treated, which patients were receiving what types of treatment for what types of problems, which patients were receiving multiple or even incompatible medications [60, 61]. In 1980 visual display terminals with keyboards for data entry replaced the optically scanned forms [78]. The team developed a Patient Narrative Document Display Program in which they entered the information that had been filled out on their periodic evaluation record document. This information was then processed to produce a narrative equivalent to the data just entered. The narrative was then displayed to the user, who could make changes, if necessary, to the original input. The system permitted the user to request a complete record or selected areas of specific interest. More than one user with a display terminal could access the database simultaneously. The group also developed a psychotropic-drug monitoring system that provided prescribing rules for medications as they were ordered. Lists of exceptions to approved rules provided alert to clinicians and supervisors to the occurrence of possibly inappropriate prescribing practices [114].

To satisfy the strict legal requirements for maintaining the confidentiality of psychiatric patient data, the group set up the system in a way that each terminal had access to only its own data files and could not access those of any other terminal. Personnel at each terminal dialed the computer when data were ready to be transmitted. A password was required to identify the individual. Failure to provide the correct password resulted in the immediate termination of the call. Passwords were changed periodically and as needed. At the headquarters, guards were posted 24 h a day to prevent unauthorized personnel from entering the computer room [29]. After visiting the Rockland Center, Wiederhold [131] reported that data were protected by limiting physical access to the terminal sites and by using passwords, and this protection was considered adequate.

Community mental health centers (CMHC) were usually understaffed and underfunded, but were well suited to use computer-based interviews. Harman and Meinhardt [56] explored the use of automated multi-test evaluations that eliminated the need for human raters, and provided a comprehensive and reliable method for acquiring data directly from patients. He proposed that for a community mental health center, an independent automated data-acquisition and follow-up system could be operated by community volunteers or other nonprofessionals. Such a system could produce printouts of comprehensive intake and follow-up evaluations, and provide a coordinated identification and tracking system utilizing a uniform data-acquisition and follow-up system for all county agencies. The results of a 1978 survey of the directors of 149 community mental health centers indicated that there was then a moderate use of computers, primarily in administrative areas; three-fourths of the centers had computer applications for financial procedures and for external reporting to accountability sources; and some automation had been applied to client monitoring and to program evaluation [49].

As a centralized approach to support computer applications in community mental health centers, the NIMH designed a prototype minicomputer-based management information system for such centers. The NIMH system comprised seven subsystems. The first was the Service/Activity Event Monitoring Subsystem which collected, organized, and reported data related to the services provided and the activities performed by community mental health center personnel [134]. The second subsystem provided patient demographics and case-manager caseloads. The remaining subsystems were for accounts receivable and billing, cost finding, general accounting, payroll/personnel reporting, and statistical analysis. Hedlund expressed hope that community mental health centers had the potential of improving direct patient care [58, 62].

4 Commercial Vendors’ MHIS

In the 1950s users of commercial mainframe computers began to explore the capabilities of vendors’ time-sharing computers for data processing in hospitals; and in the 1960s some hospitals began to use commercial time-sharing computer systems. In 1961 the Sisters of the Third Order of St. Francis established a centralized administration for their 12 health care institutions that included ten general hospitals, a continuing care center, and a geriatric care unit, located in Illinois, Michigan, and Iowa. In 1961 a group headed by Huff [68] initiated time-shared services in their hospital in Peoria, Illinois; and over the next few years expanded the computing services to all their facilities. By the end of 1963 their multi-hospital information system provided centralized payroll services, accounts payable, general ledger, financial reporting, accounts receivable, and inpatient billing. In 1970 they were acquired by the McDonnell-Douglas Automation Company (MCAUTO) of St. Louis, and became the Health Services Division of MCAUTO.

In 1964 the Information Systems Division of the Lockheed Missiles and Space Company in Sunnyvale, California, began to apply their aerospace expertise to develop a Lockheed Hospital Information System. In 1969 the Lockheed management decided to develop its Lockheed HIS in the El Camino Hospital in Mountain View, California, a 464 bed, general community hospital with a medical staff of 340 physicians [44, 45]. In l97l Lockheed sold its system to the Technicon Corporation, which had come to dominate automation in the clinical laboratory; its new owner, Whitehead, saw an opportunity to extend computer automation from the clinical laboratory into the entire hospital information system by developing its Technicon Medical Information System (MIS). In March 1971 the El Camino Hospital signed a contract for the installation of the Technicon MIS, that operated on an IBM 370/155 time-shared computer located in Technicon’s Mountain View offices [116]. In 1972 the Technicon MIS was installed at the Ralph E. Davies Medical Center in San Francisco that operated off of the Technicon regional time-sharing computer center. In 1973 the first in-hospital computer installation was implemented at the Nebraska Methodist Hospital in Omaha. The next two systems Technicon installed ran from the company’s second regional center in Fairfield, New Jersey; one was at St. Barnabas Hospital in Livingston, New Jersey, the other at the Maine Medical Center in Portland. In 1975 Technicon installed its system at the Clinical Center of the National Institutes of Health. Initially operated from a time-shared computer at the Technicon Fairfield Center, it was later transferred to the NIH computer facility in Bethesda, Maryland. The El Camino Hospital continued through the 1980s to operate with a time-shared computer.

In 1980 the Technicon Data Systems Corporation (TDS) was acquired by Revlon, Inc. In 1986 it was repurchased by a new company called TDS Healthcare Systems Co., headed by the son of the founder of Technicon; its enhanced TDS 4000 system was announced in 1987 [22]. By 1986 the Technicon Data Systems (TDS) MIS had been installed in about 40 hospitals [16]; by the end of the 1980s, 85 TDS systems had been installed in the United States, Canada, and the United Kingdom. These installations included the Clinical Center in the NIH and sites in major teaching institutions such as New York University, Temple University, Medical College of Virginia, University of Illinois, Loyola, University of Chicago, Baylor University, and University of California at Irvine [66]. The Lockheed HIS that was initiated in 1966 became the Technicon MIS in 1971, and then the TDS. It was probably one of the best commercially developed HIS in the United States throughout the 1970s and 1980s, although it had deficiencies, such as a discontinuous patient record that did not integrate patient data collected over multiple admissions, and it did not allow for an office information system. By the end of the 1980s enhancements had been added to the TDS 4000 system that partially corrected these deficiencies by an expanded electronic patient record (EPR) with linkages of the hospital system and to attending physicians’ offices. In 1986 Technicon TDS was sold to Revlon; and it became Allscripts. In 2008 Allscripts acquired several health care information system vendors and became a major vendor for electronic health record (EHR) systems.

In 1965 a survey of computer-based information systems in medicine by Summerfield and Empey [124] at Systems Development Corporation (SDC) in Santa Monica, California, listed 73 ongoing projects developing hospital information systems or subsystems. In a review of commercial HIS vendors in the 1960s, Jacobs [72] noted that it was not until the mid-1960s that vendors began to take notice of the potential of the hospital data processing market. In 1966 Honeywell announced the availability of a business and financial package, acquired from Blue Cross of Minnesota, for a shared hospital data processing center. International Business Machines (IBM) followed in the next year with Shared Hospital Accounting System (SHAS). Lockheed and National Data Communications, Inc. (then known as REACH, Inc.) began the development of HISs to be offered to hospitals on a turnkey basis. In the late 1960s MEDELCO, Inc. brought a simplified HIS to the market that met with some success.

In 1968 Thompson in the Department of Health Services in Los Angeles County, California, operated a large countywide system with terminals at 48 different sites that provided patient identification data, clinic registration and appointment scheduling with a limited amount of clinical information for about 550,000 patient visits a year. Thompson also operated at the East Los Angeles Child and Youth Clinic, California, a Los Angeles County-supported clinic that collected patient data on paper forms, coded the data by a medical technician, and entered the data by keypunch off-line batch processing to provide a supplement to the paper-based medical record for about 10,000 patients [64]. In 1969 a centralized information system for nine Los Angeles County Hospitals was initiated using an IBM 360/40 computer connected by telephone cable to remote display terminals and printers, located initially in the admitting offices and pharmacies, and then to a centralized patient records database, it soon added order entry of medications, diets, and laboratory tests [113].

In 1968 a survey conducted for the National Center for Health Services Research and Development (NCHSR&D) 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 medical or medical research computing applications. For 248 respondents who used computer manufacturers for advice or assistance in the development of their hospital computer activity, the following vendors and the number of systems they had installed were listed as IBM 168, National Cash Register 37, Honeywell 19, Burroughs 10, UNIVAC 10, General Electric two, RCA one, and unspecified one [65]. An Arthur Young & Co. report identified four well-known, large, time-sharing HISs capable of servicing several hospitals in the 1960s [117]. The Medi-Data system, formed by a group of four hospitals in North and South Carolina, shared a common data processing center using Burroughs computers [6]. In an attempt to maintain low operational costs, Medi-Data avoided the use of real-time processing and provided all output reports on a regularly scheduled basis; its terminals were designed for use by clerks rather than by health professionals. The Medinet system, based on General Electric (GE) equipment, was used in a number of hospitals in the New England area. The MISs Program (MISP) used a number of programs developed at teaching hospitals supported by research grants, and was designed for the IBM 360 series of computers. Fourth was the Technicon HIS which also used IBM equipment. By the end of the 1960s a number of commercial HISs were competing for what was heralded as a potentially great market.

In the early 1970s a series of reviews [6, 8, 9] reported on the status of vendor HISs and added the following as offering systems that attempted to meet the needs for comprehensive services: Biomedical Computer Services, which focused on the medical record, and used a variety of computers linked to touch-screen terminals; Control Data Corporation (CDC); MEDICOM, which used CDC computers connected to CDC touch-screen terminals; Medelco’s Total HIS (T.H.I.S.), which used prepunched cards for each order, service, or product available in the hospital and read into a hard-wired, pre-programmed machine; McDonnell-Douglas Automation Company (MCAUTO), which in 1970 acquired the HIS of the Sisters of the Third Order of St. Francis; Medical Information Technology, Inc. (Meditech), which originated with the MUMPS founder Pappalardo, and initially used DEC or Data General minicomputers with display terminals and their own software developed for a relatively comprehensive integrated HIS; National Data Communications, whose Real-Time Electronic Access Communications for Hospitals (REACH) System used Honeywell and other computers connected to Raytheon cathode ray tube (CRT) display terminals with 20 selector push buttons located along the left side of the display for order entry and routine tasks; and a keyboard for entering textual data; Searle’s Medidata System, with touch terminals that used sets of overlays (for example, one for laboratory, another for pharmacy, and so on), each of which presented 320 order choices in addition to display terminals with keyboards for entry of text. However, Searle offered Medidata for only a few years when it was taken over by Mediquip, a subsidiary of Quanta System Corporation and Spectra Medical Systems, which used a Data General Nova minicomputer connected to color display terminals with keyboards and light-pen selectors designed for data entry by physicians. In 1974 Huff and associates, who had developed the system at the Sisters of the Third Order of St. Francis Hospital acquired by MCAUTO, left MCAUTO and formed HBO and Co. [73]. In 1975 the company unveiled a new second-generation level-1 system, MEDPRO, which used modern cathode ray tube (CRT) order-entry terminals [7].

Until the mid-1970s the majority of hospitals subscribed to out-of-hospital, shared computing services [11]. In the mid-1970s lower-cost minicomputers introduced the capabilities of locating small, special purpose computers in various departments, all linked to one or more central, large mainframe computers. Ball [10] considered this distributed approach to functionally oriented HISs a major change in their development. The use of minicomputers in subsystems such as laboratory and pharmacy expanded the concept of a HIS into a network of interrelated, modular, functional processing systems. 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 [120]. In 1976 a Spectra 2000 system for 800 beds was installed at Rush-Presbyterian-St. Luke’s Medical Center in Chicago; in 1980 it was replaced by a Spectra 3000 system that was linked to minicomputers and used visual display terminals with light-pen selectors for users to select items from displayed, predefined data sets. Physicians entered their orders directly, and a nursing module was well accepted [109]. In 1976 Bleich, Slack and associates at Beth Israel Hospital in Boston initiated their HIS. In 1982 they expanded it into the Brigham and Women’s Hospital. By 1984 it ran on a network of Data General Eclipse minicomputers that supported 300 video-display terminals located throughout the hospital. In 1994 Brigham and Women’s Hospital joined with Massachusetts General Hospital to form Partners Health Care System including 10 hospitals and more than 250 practice sites [125].

After reviewing the history of the diffusion of HISs through the early 1970s, Jacobs [72] concluded that there had been a rapid growth that decade in the number of hospitals with on-site computers, especially in the larger, general, not-for-profit, non-governmental hospitals. In a smaller survey of computer applications in approximately 100 responding U.S. hospitals [120], three-fourths indicated they had some computer applications for administrative functions, and about one-third reported clinical laboratory or other patient care applications. Ball [12] and Jacobs reported that although level-1 HISs, which provided primarily administrative, business, and communication applications had begun to be accepted in the second half of the 1960s, a 1974 survey showed that the majority of hospitals still subscribed to out-of-hospital shared computing services. However, the percentage of short-term general hospitals with in-hospital computers had increased from 30 % for small hospitals to 75 % for hospitals with 500 or more beds. Other surveys of U.S. hospitals found that 80 % in 1975 and 90 % in 1976 used some sort of data processing for business applications [1].

In 1976 a prototype of IBM’s Patient Care System (PCS) began to be implemented as a joint project with Stead and Hammond’s group at Duke University Medical Center in Durham, North Carolina. The Duke HIS used an IBM 3033 computer with IBM’s IMS database management system and its terminal handlers [55]. It used IBM 3278 visual displays with light-pen selectors; and its terminals were available at each nursing station and in each service department. It stored all clinical information in its database and was interfaced with Duke’s outpatient information system (OIS) and system known as The Medical Record (TMR). The initial Duke HIS transmitted its OIS prenatal records to the inpatient obstetrics department when a woman in labor was admitted [55].

By 1984 the Duke HIS serviced 52 nursing stations containing an aggregate of 1,008 beds, and was linked to 18 service departments and 64 specimen laboratories [121]. Microcomputers were used as departmental workstations linked to the central computer. In 1987 the Duke HIS central computer was upgraded to an IBM 3090–200 computer that serviced 550 display terminals. It used an application generator program called the Application Development System (ADS), also marketed by IBM. IBM’s Patient Care System (PCS) was also developed to run under ADS [77]. IBM’s PCS/ADS provided the development-modification tools for any desired modifications after the delivered applications had been installed and thus served as an application-enabling system for large mainframe HISs. In 1987 IBM announced its Patient Care System/ Application Development System (PCS/ADS) was available as a licensed product for ADS-based application development [63]. Through the 1980s IBM continued to provide most of the mainframe HISs in the United States. In parallel with the development of the Duke HIS, IBM also began in 1976 to install its PCS using an IBM 370 computer at Parkland Memorial Hospital in Dallas, Texas, where it was called the Parkland Online Information System (POIS), and was under the direction of Mishelevich and associates; by 1978 a relatively comprehensive HIS was operational with terminals at all 40 nursing stations [95].

In 1979 McDonnell-Douglas introduced its Patient Care System (PCS), after having acquired additional modules to provide a fairly comprehensive HIS. In the mid-1980s it responded with its MCAUTO PCS to requests for proposals from the Veterans Administration (VA) and the Department of Defense (DoD). In 1979 Fetter [41] described a Yale University microcomputer-based MIS (medical information system) using a Digital Equipment Corporation (DEC) 16-bit LSI-11 processor, with computer terminals installed in Yale’s radiology department and clinical laboratory.

At the end of the 1970s Maturi and DuBois [90] conducted a survey for the National Center for Health Services Research (NCHSR) of the state of commercially available hospital department information systems (HISs), including their relationship to hospital-wide communication systems. The department-specific applications that they reviewed were medical record room functions (tracking charts, coding diseases, and similar record librarian activities); and also laboratory, radiology, and pharmacy systems; but they did not include computer-based patient records or general clinical applications. They reported that the department specific subsystems were usually acquired by the hospital before a hospital-wide communication system was in place. However, many department-specific systems soon became part of a communication network as industry provided expanded interfacing capabilities, a trend which encouraged distributed systems involving department-specific and hospital-wide systems. They reported that the major clinical laboratory vendors at that time were Becton Dickenson, Technicon, Medlab, and Community Health Computing. The major vendors of radiology systems were Siemens and General Electric; and of pharmacy systems were Becton Dickenson, International Business Machines, and Shared Medical Systems.

At the end of the 1970s, Young [137] and associates at the University of Southern California also conducted a survey of minicomputer-based HISs in medium-sized hospitals with 100–300 beds. They identified 75 different applications that they grouped into five levels or steps of difficulty in a modular implementation of an HIS. They found that essentially all had level-1 hospital applications (primarily by batch processing), which included billing and accounting, payroll, and inpatient census. Some also had level-2 hospital applications (with limited online data entry), which included admission-discharge-transfer (ADT), patient record data collection, patient identification number assignment, general ledger interface, and credit and collections. Only about one-half of the hospitals had level-3 hospital applications (using online data entry terminals), which included order entry transmission, message communication, patient number retrieval, discharge abstract preparation, and various inventory applications. Less than one-fourth had level-4 hospital applications (with most functions automated), which included patient identification number (ID) assignment, discharge analysis and reports, laboratory worksheets and schedules, budget preparation and expense reports, and labor time collection. Few hospitals in this survey had level-5 hospital applications (with two-way data transmission and clinical functions), which included test results reporting, medical chart reports, personnel history, and utilization review. Young [137] concluded that smaller HISs with minicomputers fell short of the more sophisticated HISs in larger hospitals with mainframe computers supporting a variety of patient care applications.

In the late 1970s and early 1980s constant changes occurred in the vendors providing HISs as increasing competition resulted from the new hardware and software that evolved in this time period. Among some of the more notable changes were the following: HBO expanded and acquired new subsystems; Whittaker Corporation’s MEDICUS, initially organized in 1969, acquired Spectra Medical Systems; Perot’s Electronic Data Systems (EDS) expanded into the HIS market in 1980; and IBM offered its new PCS with some applications developed at Duke University Medical Center and Parkland Memorial Hospital [72]. In the early 1980s federal legislation gave a major impetus to HISs when Medicare reimbursement policies changed to require the payments for hospital services to Medicare patients be made on the basis of classifying patients’ conditions into Diagnostic Related Groups (DRGs). As a result, every hospital in the United States providing care to Medicare patients required major changes in its HIS to accommodate these DRG requirements.

In the early 1980s strategies for designing an HIS were sufficiently advanced that a hospital administrator could select the HIS functional components desired and refer to the Automated Hospital Information System (AHIS) Component Catalog developed at the Health Services Research Center of the University of Columbia-Missouri by Leonard, Goldman, and associates. This document described 112 commercially available components that might be used to design an HIS, and it provided standardized descriptions of cost and performance of each component [82, 83]. Young [136] published an Automated Hospital Information Systems Workbook in two volumes: the first was designed to guide the planning, selecting, acquiring, implementing, and managing a HIS; and the second described 180 available HIS applications, and the characteristics of 24 HISs available from 22 vendors. In 1980 a survey by Ball and Jacobs [7] found that 18 HIS vendors provided some nursing, pharmacy, laboratory, and radiology functions. Another survey by Ball and Jacobs [12] found that 18 vendors offered second-generation, Level-1 HISs (which provided some nursing, pharmacy, laboratory, x-ray, and medical record-room functions, in addition to business and administrative applications); more than 500 such systems had been sold as of the spring of 1980. As of that time, eight vendors also offered Level-2 HISs which also provided a computer-based patient record (CPR) and supported nursing and clinical applications. In the 1980s local area networks (LANs) permitted their users with inexpensive microcomputers to integrate their various individual databases into large, centrally shared databases. Multiple computers in affiliated hospitals began to use communication networks to link their hospital databases.

In 1981 Grams [52] at the University of Florida initiated a series of annual surveys of HISs in the United States, offering the data collected in 1982 prior to the imposition of DRGs and the new federal requirements for prepaid medical care as a reference point for analyzing any new changes or trends in HISs. In the 1982 survey, 37 % of 1,430 responding hospitals reported that they used their own in-house developed financial computer system (of these, 55 % used IBM computers, 14 % used NCR, 13 % used Burroughs, and 4 % used DEC computers); 42 % of the respondent hospitals used a vendor-maintained turnkey financial system (of these, 26 % used Shared Medical Systems (SMS), 25 % used McDonnell-Douglas Automation Company (MCAUTO), 5 % used Systems Associates, Inc. (SAI), and 2 % used HBO systems). In 1984, only 30 % of 1,263 respondents used an in-house developed financial system (with approximately the same distribution of computer vendors as in 1982); 44 % used vendor turnkey systems (of these, 24 % used SMS, 19 % used MCAUTO, 8 % used SAI, 5 % used HBO, and 2 % used Dynamic Control Co (DCC) financial systems. The success of vendor time-shared systems such as SMS and MCAUTO for hospital business and financial applications was highly apparent.

The responding hospitals also reported on hospital nursing-station and order-entry systems. In the 1982 survey, 7% used an in-house developed system (of these, 64 % used IBM computers, 9 % NCR, 7 % Burroughs, 7 % DEC computers); 14 % used vendor turnkey systems (40 % used HBO, 23 % SMS, 14 % MCAUTO, 4 % Technicon, and 3 % used EDS systems). In the 1984 survey, 8 % used in-house developed nursing-station and order-entry systems (of these, 56 % used IBM, 16 % DEC, 7 % Burroughs, 6 % NCR, 1 % Data General computers); 16 % used vendor turnkey nursing systems (34 % HBO, 21 % SMS, 11 % MCAUTO, 5 % Technicon, 5 % DCC, 4 % EDS, 4% Meditech, and 3% SAI systems [52].

Rozner [112] noted that competition was intense with over 150 companies providing products and services to support hospital computerization, with IBM, SMS, and MCAUTO accounting for 45 % of the total market in 1982. In the 1984 and 1985 market, after several acquisitions and mergers, eight vendors accounted for almost one-half of the total market revenues: IBM for 19 %, SMS 10 %, McDonnell-Douglas (formerly MCAUTO) 7 %, Baxter Travenol (who acquired Dynamic Control Co.) 4 %, Meditech 1 %, and SAI 1 % [106].

In the 1980s Leberto [81] ranked the top vendors of HISs with patient care systems by their 1986 sales (in millions of dollars), as follows: IBM $925; SMS $350; McDonnell-Douglas $185; DEC $175; Data General Corp. $140; Unisys Corp. $125; Baxter Management Services $115; NCR Corp. $75; Hewlett Packard $50; Technicon Data Corp $40; Professional Healthcare Systems, Inc. $30; Systems Associates, Inc. $30; Meditech $28; Tandem Computers $25; Ferranti Healthcare Systems Corp. $20; Motorola Computer Systems $15; Electronic Data Systems $15; 3 M Health Information Systems $12; and Gerber Alley $12.

Through the 1980s IBM continued to provide most of the mainframe HISs in the United States. Ball [5] observed that despite the diversity of the marketplace with more than 400 vendors, IBM still comprised the largest one-vendor commitment to HISs, with 34 % of HISs using IBM computers. Over half of these used IBM mainframes, while the remainder used mini- and/or microcomputers; about half of the IBM mainframe users relied on in-house development rather than on turnkey systems; and over 70 % used IBM Patient Care System (PCS).

Stoneburner [123] listed 73 vendors of outpatient information systems (OISs) in the United States. Friedman and MacDonald [43] reported that more than 100 different varieties of personal computers were available for use by physicians, most of them based on 8-bit microcomputer chips; but 16-bit microprocessors were beginning to appear in 1983. Lund and associates [88] at the Henry Ford Hospital in Detroit, Michigan, reported the installation of a broadband, cable-television LAN that connected by cable a variety of computers located in seven buildings. The system was capable of transmitting digital computer data, as well as analog video information. In 1985 the Health Data Sciences (HDS) Corporation in San Bernardino, California installed a pilot system of its Ulticare HIS, a bedside terminal system that used keyboard data entry, in the 1,120-bed William Beaumont Hospital in Royal Oaks and Troy, Michigan. This system used distributed Data General minicomputers for its applications, and one archival computer that stored a duplicate copy of all information. By 1989 the Ulticare HIS with a MUMPS-based operating system had 15 operational applications, including a computer-based patient record, order entry and results reporting, patient assessment, care planning, patient scheduling, nurse charting, and medication programs. Humana, Inc., Louisville, Kentucky, that operated 88 hospitals nationwide, also began using the Ulticare system [101].

By the second half of the 1980s, a large HIS generally used a mix of large, mini- and microcomputers linked by a LAN. More advanced HISs linked clinical data to the financial database and permitted association of quality-assurance measures with cost data, so as to provide guidelines for more cost-effective procedures [135]. By 1987 almost all hospitals with more than 100 beds had a HIS financial system, and 44 % had a nursing station order entry system [122]. About 20 % of U.S. hospitals had computer links between their HISs and affiliated physicians’ offices. Some had workstation terminals that enabled data to be exchanged, copied, and modified; some permitted direct access to laboratory and radiology reports from an office information system [104]. Such linkage required additional security procedures to protect patient confidentiality and to prevent unauthorized access to patient data. Linkage of a HIS to staff physicians’ offices was encouraged because it facilitated the transfer of results of diagnostic tests to the physicians [91]. In 1987 a Medical Software Buyer’s Guide listed more than 900 products that included software for laboratory, pharmacy, and radiology systems [107]. Leberto [81] ranked the top vendors of HISs with patient care systems by their 1986 sales (in millions of dollars), as follows: IBM 925; SMS 350; McDonnell-Douglas 185; DEC 175; HBO & Co. 145; Data General Corp. 140; Unisys Corp. 125; Baxter Management Services 115; NCR Corp. 75; Hewlett Packard 50; TDS Corp. 40; Professional Healthcare Systems, Inc. 30; Systems Associates, Inc. 30; Meditech 28; Tandem Computers 25; Ferranti Healthcare Systems Corp. 20; Motorola Computer Systems 15; Electronic Data Systems 15; 3 M Health Information Systems 12; and Gerber Alley 12.

The fifth annual edition of the Computers in Healthcare (1988) market directory listed 750 vendors of computer systems and supplies available to the health care industry. Hammon [54] noted that average hospital data processing costs, as a percentage of the hospital budget, had increased from 2.85 % in 1985 to 3.73 % in 1987, an increase of 30 % in 2 years; and that the use of computers in hospitals was moving from the financial applications to the clinical applications. Dorenfest [36] also reported that the number of hospitals using computers for other than finance had risen dramatically as computers moved into patient registration, pharmacy, nursing, and laboratory; when the manual systems that supported patient care processes in the 1960s proved inadequate in the 1980s, there was a huge opportunity to improve hospital operations through better automation in the 1990s.

By the 1990s most hospitals had a variety of integrated or linked clinical subsystems. In 2010 commercial vendors of the systems reported that Meditech had 1,212 EHR installations, Cerner Corporations 606; McKesson Provider Technologies 573, Epic Systems 413, Siemens Healthcare 397. In 2014 Epic Systems Corp. was reported to be the top vendor of complete EHR systems used by physicians and other professionals who earned Medicare incentive payments for using the technology, according to federal data; and Cerner Corp. led among the smaller number of physicians who used modular EHR systems.

5 Summary and Commentary

Up to the 1980s, the two largest multi-hospital information systems (MHISs) in the United States were independently developed: one by the Veterans Administration (VA) for its hospitals, and the other by the Department of Defense (DoD) for its hospitals. Both systems were similar in their requirements in that each served more than 100 hospitals with associated clinics in the continental United States, and both began to develop their systems in the 1960s. Both ended up with MUMPS-based software systems; each was operated by a different national governmental agency, but the multimillion-dollar annual budgets of both were controlled by the U.S. Congress. There was a difference in design and development taken by these two systems, in that DoD took a centralized “top-down approach” in which a central office for the three armed services, the TRIMIS Program Office (TPO), did all the planning, developed the functional and technical requirements, budgeted for and procured its hardware and software, and installed and maintained all of its medical treatment facilities. The VA, on the other hand, took a decentralized “bottom-up approach,” in that the development of functional and technical requirements, all software development, installation, and maintenance of all systems were done in the various VA Medical Centers (VAMCs). The DoD implemented its stages of system evolution by purchasing vendor turnkey systems, whereas the VA DHCP was predominately an in-house development. Costs for the DoD system were closely monitored each year. In the VA system, only VA budgeting and hardware procurement were done centrally; therefore, only the costs for procurement of hardware were monitored, since most other systems and software costs were absorbed by the local VAMCs and these costs were not always identified. DoD contracted for independent evaluation of the effectiveness of achieving its system objectives and of the cost-effectiveness of system modules, whereas the VA evaluated the effectiveness of system modules by its own regional Verification and Development Centers (VDCs), and it did so primarily for purposes of standardization and transportability. User satisfaction was variable in the DoD systems, whereas in the VA systems user satisfaction was generally high wherever the software had been locally developed. These two examples of MHISs sponsored by the U.S. government were of special interest, since they demonstrated that, with relatively unlimited resources, huge MHISs could be implemented successfully using different approaches. Since the SAIC’s DoD’s CHCS that was installed in all DoD medical centers had some features of the VA’s DHCP, and since both systems were using similar computers and MUMPS-based software, some potential benefits were possible if the DoD and VA information systems would eventually become interoperable.

By the end of the 1980s, the multi-system information systems had matured such that the Institute of Medicine decided that a committee should be formed to examine the impact of this maturing technology on the future of medical care. The report from this group, The Computer-Based Patient Record: An Essential Technology for Patient Care, was released in 1991 and re-released in 1997 with an update [32, 33]. Morris Collen was a member of the study and was responsible for the choice of its title, the computer-based patient record. With the exception of the challenge of managing personal authentication since the use of a unique national personal health identifier was banned from the USA in the mid-1990s and interoperability among EHRs, the era of health information technology (HIT) research and development had largely ended, that is in the context that practical systems for the mass market were now available and being used in a variety of clinical care settings. Looking forward, the challenging work that remains relates to informatics versus information technology (IT) per se, e.g., the science of the use of information and communications. Improving user interfaces as well as better natural language processing remain with us and these are not to be trivialized but some consider these to be informatics rather than IT challenges. Informatics challenges in terms of better decision support, system improvements through the use of “big data” analytics, etc., gain ever more attention as healthcare budget pressures rise.

As noted earlier, the next two decades saw continued expansion of a few large MSIS into broader commercial use. Following the federal investment in EHRs through the HITECH provisions of the Recovery and Reinvestment Act of 2009, a few vendors, especially Epic, separated from the pack as industry consolidation occurred [58].

One could argue that from 2000 through today much of the excitement and continued development in MSIS have related to communications rather than information technology and its impact on care. From the personal digital assistants of the period from 1999 to the emergence of the iPhone in 2007, linking providers and other users to EHRs data, especially via secure websites referred to as “patient portals,” has represented the most dramatic leap of technology. Telemedicine that had required large investments of personnel and equipment by MSISs for image transfers and assured connectivity suddenly began to merge into a routine care dimension furthered by the arrival of the iPad and other tablets.

The HITECH provisions also placed a premium on Health Information Exchanges (HIEs) to deal with the continued angst especially among care providers over the lack of interoperability and limits to secure data exchange. HIEs had been around using different terminology, e.g., community health information networks (CHINs) among other titles, for a few decades as efforts were made to improve interoperability across MSIS.

Alas, their major limitation was not technology per se but rather the absence of a sustainable value proposition to underwrite the costs relating to assuring that the system remained live. While HIEs hold great value to the overall system, their function as a utility failed since no single player seemed willing to come forward to pick up the costs over time. Further, few innovators have figured out an acceptable way for all users of the commons to support the service. Even today there are too few working examples akin to the Indiana Network for Patient Care that imports data from 103 of Indiana’s 120-some hospitals and their hospital-based outpatient practices as well as four small ones that are mostly based in surrounding states (Michigan, Ohio) and include some of the border hospital systems It is managed by the Indiana Health Information Exchange, a non-profit organization [92]. The HIEs remain as arguably the dominant challenge for HIT and MSISs in this nation today.