Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

After reading this chapter, you should know the answers to these questions:

  • What are the primary information requirements of health care organizations (HCOs)?

  • What are the clinical, financial, and administrative functions provided by health care information systems (HCISs), and what are the potential benefits of implementing such systems?

  • How have changes in health care delivery models changed the scope and requirements of HCISs over time?

  • How do differences among business strategies and organizational structures influence information systems choices?

  • What are the major challenges to implementing and managing HCISs?

  • How are ongoing health care reforms, technological advances, and changing social norms likely to affect HCIS requirements in the future?

1 Overview

Health care organizations (HCOs), like many other business entities, are information-intensive enterprises. Health care personnel require sufficient data and information management tools to make appropriate decisions. At the same time, they need to care for patients and manage and run the enterprise; they also need to document and communicate plans and activities, and to meet the requirements of numerous regulatory and accrediting organizations. Clinicians assess patient status, plan patient care, administer appropriate treatments, and educate patients and families regarding clinical management of various conditions. They are also concerned about evaluating the clinical outcomes, quality, and increasingly, the cost of health services provided. Administrators determine appropriate staffing levels, manage inventories of drugs and supplies, and negotiate payment contracts for services. Governing boards make decisions about whether to invest in new business lines, how to partner with other organizations, and how to eliminate underutilized services. Collectively, health care professionals comprise a heterogeneous group with diverse objectives and information requirements.

The purpose of health care information systems (HCISs) is to support the access and management of the information that health professionals need in order to perform their jobs effectively and efficiently. HCISs facilitate communication, integrate information, and coordinate action among multiple health care professionals. In addition, they assist in the organization and storage of data, and they support certain record-keeping and reporting functions. Many of the clinical information functions of an HCIS were detailed in our discussion of the computer-based patient record (CPR) in Chap. 12; systems to support nurses and other care providers are discussed in Chap. 15. Furthermore, HCISs are key elements that interface with the health information infrastructure (HII), as discussed in Chap. 13. An HCIS also supports the financial and administrative functions of a health organization and associated operating units, including the operations of ancillary and other clinical-support departments. The evolving complexities of HCOs place great demands on an HCIS. Many HCOs are broadening their scope of activities to cover the care continuum, partially in response to Accountable Care Organization (ACO) initiatives from the federal government. HCISs must organize, manage, and integrate large amounts of clinical and financial data collected by diverse users in a variety of organizational settings (from physicians’ offices to hospitals to health care systems) and must provide health care workers (and, increasingly, patients) with timely access to complete, accurate, and up-to-date information presented in a useful format.

1.1 Evolution from Automation of Specific Functions to Health care System Information Systems

Over time, changes in the health care economic and regulatory environments have radically transformed the structure, strategic goals, and operational processes of health care organizations through a gradual shifting of financial risk from third party payers (e.g., traditional insurance companies such as Blue Cross and Blue Shield, Medicare and Medicaid programs that emerged in the 1960s and 1970s, and subsequently managed care companies that became quite prominent in the 1980s) to the providers themselves. This shifting of risk initially brought about a consolidation of health care providers into integrated delivery networks (IDNs) in the 1990s. Subsequently, there was a retreat from the most restrictive models of managed care toward greater consumer choice, a slowing of mergers and acquisitions activities, several high profile IDN failures (Shortell et al. 2000, Weil 2001, Kastor 2001), and major new regulatory requirements aimed at improved efficiency and greater patient privacy and safety. Most recently, the pendulum has swung back as IDNs acquire both physician practices and hospitals while shifting their focus to becoming identified as an ACO. All these changes have tremendous implications for HCISs.

The evolution of HCISs has paralleled—and in many ways responded to—the organizational evolution of the health care industry itself. The earliest HCISs were largely focused on the automation of specific functions within hospitals including, initially, patient registration and billing. The justification for these systems was relatively straightforward since large mainframe computers were easily capable of performing the clerical tasks associated with tracking patients and sending out bills. In the 1960s and 1970s, seeing the benefits coming from more highly automated financial systems, hospital departments began to focus on installing computer systems to support ancillary activities such as those found in radiology, the pharmacy, and the laboratories. Hardware vendors such as the Digital Equipment Corporation (DEC) responded with smaller computing platforms known as minicomputers, which enabled individual departments to remain quite separate not only in function but in terms of computer hardware, operating systems, and even programming languages—even though collectively they were now known as hospital information systems (HISs). The lack of connectivity among these various systems created significant obstacles to keeping track of where patients were located in a hospital, and more importantly, what kind of care was being provided and the clinical results of that care. It was not uncommon for caregivers to have to log on to several different computer systems just to learn the status of specific clinical results from different laboratories or departments. By the late 1980s, clinical information system (CIS) components of HISs offered clinically oriented capabilities, such as order writing and results communications. During the same period, ambulatory medical record systems (AMRSs) and practice management systems (PMSs) were being developed to support large outpatient clinics and physician offices, respectively. These systems performed functions analogous to those of hospital systems, but were generally less complex, reflecting the lower volume and complexity of patient care delivered in outpatient settings. Increasingly, these various systems were implemented within organizational boundaries, but with little or no integration between hospital and ambulatory settings.

The development of so many different, functionally specific information systems is one of the unique attributes of HCOs and one of the drivers of the complexity of HCOs. These systems were often developed in isolation from one another as vendors focused on developing as much highly specialized functionality as possible—in effect, striving for a “best of breed” designation in the marketplace for their particular type of system. The isolation of these systems, even within a single organizational structure, was overcome in part by the development of interfaces between the various systems. Initially these interfaces focused on delivering patient demographic information from registration systems to the ancillary systems and data on specific clinical events (e.g., laboratory tests, radiology exams, medications ordered) from the ancillary systems to the billing system. However, as more information systems were added to the HCIS environment, the challenge of moving data from one system to another became overwhelming. In response, two unique developments occurred: (1) the interface engine; and (2) Health Level Seven (HL7), a standard for the content of the data messages that were being sent from one information system to another as discussed in Chap. 7.

The challenge of sharing data among many different information systems that emerged in the 1980s and 1990s was daunting. As we noted earlier, the various components of the HCISs were in most cases developed by different vendors, using different hardware (e.g., DEC, IBM), operating systems (e.g., PICK, Altos, DOS, VMS, MUMPS on minicomputers, and IBM’s 360 OS on mainframes) and programming languages (e.g., BASIC, PL1, COBOL, MUMPS and even assembler). Sharing data among two different systems typically required a two-way interface—one to send data from System A to System B, the other to send data or acknowledge receipt from B back to A. Adding a third system didn’t require simply one additional interface because the new system would in many cases have to be interfaced to both of the original systems, resulting in the possibility of six interfaces. Introducing a fourth system into the HCIS environment increased the complexity further, since it often meant the need for two-way interfaces to each of the original three systems, for a total of twelve (Fig. 14.1). With the prospect of interfaces increasing exponentially as new systems were added (represented by the formula, I = n (n1) where I represents the number of interfaces needed and n represents the number of systems), it was clear that a new solution was needed to address the complexity and cost of interfacing. In response, an industry niche was born in the late 1980s which focused on creating a software application designed specifically to manage the interfacing challenges among disparate systems in the HCIS environment. Instead of each system having to interface to every other system independently, the interface engine served as the central connecting point for all interfaces (Fig. 14.2). Each system had only to connect to the interface engine; the engine would then manage the sending of data to and from any other system that needed it. The interface engine concept, which originated in health care, has given rise to a whole series of strategies for managing multiple systems. Many of the vendors who got their start in health care interfacing subsequently found new markets in financial services as well as other industries.

Fig. 14.1
figure 1

The challenge of moving data from one system to another becomes complicated with the addition of each new system. Considering that even small size hospitals may have several hundred applications, interfacing is a major challenge. While in reality not all systems need to have two-way interfaces to every other system, this figure illustrates the challenges that even small numbers of systems bring

Fig. 14.2
figure 2

The introduction of the Interface Engine (IE) made system interfaces much more manageable, particularly so with the implementation of HL7 data messaging standards. With an IE, each additional system only added two additional interfaces to the mix, one to send data and one to acknowledge receipt of the data

The creation of HL7 (see Chap. 7) was yet another response to the challenge of moving data among disparate health care systems. HL7 is a health care-based initiative, also started in the late 1980s, to develop standards for the sharing of data among the many individual systems that comprise an HCIS. The basic idea was to use messaging standards so that data could be sent back and forth using standard formats within the HCIS environment. Most of the departmental systems that were introduced at this time were the products of companies focused on specific niche markets, including laboratories, pharmacies and radiology departments. Consequently there was strong support for both the interface engine and the HL7 efforts as mechanisms to permit smaller vendors to compete successfully in the marketplace. In recent years, many of these pioneering vendors have been purchased and their products included as components of larger product families.

The decade of the 1990s was marked by a large number of mergers and affiliations among previously independent and often competing HCOs designed to drive excess capacity from the system (e.g., an oversupply of hospital beds) and to secure market share. Hospitals and medical centers began to build satellite ambulatory-care clinics and to reach out to community physician practices in an attempt to secure patient referrals to their specialty services and to fill their increasingly vacant inpatient beds. Later, facing competition with vertically integrated for-profit health care chains and with other integrating organizations, hospitals started at first affiliating and then more tightly integrating into regional aggregates of health care service providers—the Integrated Delivery Networks (IDNs) mentioned earlier (See Fig. 14.3).

Fig. 14.3
figure 3

Major organizational components of an integrated delivery network (IDN). A typical IDN might include several components of the same type (e.g., clinics, community hospitals. Physician group practices, etc.). Components within the same geographic area may have direct data connections, but increasingly the Internet is the preferred way to connect organizational components

By 2000, IDNs were prominent in almost every health care market in the United States and in several cases, spanned large geographic regions and multiple states. Each IDN typically consisted of multiple acute-care facilities, satellite ambulatory health centers, and owned or managed physicians’ practice groups. In addition, larger IDNs might have skilled nursing homes, hospices, home-care agencies, and for-profit sub-corporations to deliver support services back to the health care providers, including regional laboratories, separate organizations for purchasing and distributing drugs and medical supplies, and remote billing services. A major goal of such IDNs was cost reduction (both internally and from suppliers), as well as to retain or increase revenues by improving their negotiating strength with third party payers. Because they controlled a significant regional market share and were positioned to provide and manage comprehensive health services, IDNs expected to negotiate favorable purchasing contracts with suppliers and competitive service contracts with payers or directly with large employers. Some IDNs went further and affiliated with a regional health maintenance organization (HMO) or developed their own health-plan organizations to act as their own insurance carriers. The largest IDNs had annual revenues approaching several billions of dollars, were contracting with thousands of physicians and nurses, and managed contracts to provide comprehensive care for more than one million patients.

One of the major expectations was that IDNs could reduce costs by leveraging economies of scale; for example, by consolidating administrative and financial functions and combining clinical services. Such IDNs were challenged to coordinate patient care and manage business operations throughout an extensive network of community and regional resources. As a result, HCISs were developed to share information and coordinate activities not only within, but among multiple hospitals, ambulatory care sites, physicians’ practice groups, and other affiliated organizations.

Although IDNs are still a prominent feature in many health care markets, there had been a decrease in the rate of market consolidation and some highly visible IDN failures. While the most successful of IDNs have achieved a measure of structural and operational integration, gains from the integration of clinical activities and from the consolidation of information systems have been much more difficult. Many IDNs scaled back their original goals for integrating clinical activities and actually began to shed home care services, physician practices, health plans and managed care entities, although as noted earlier in this chapter, we are now seeing a return to consolidation, mergers and acquisitions as reimbursement constraints and federal ACO initiatives strive to improve both the efficiency and effectiveness of HCOs. It appears that the expertise gained from managing an inpatient-driven organization producing a relatively large amount of revenue from a relatively small set of events (e.g., a hospital) did not translate easily to the successful management of other organizational activities that in many cases required many more events to produce a similar level of revenue (e.g., from outpatient clinics). In some cases, it was even a challenge to translate management processes from inpatient operations to outpatient clinics, or one hospital to another. Attempts to apply hospital management principles to ambulatory clinics have been challenged because hospitals generate a relatively small number of patient bills with high dollar amounts whereas ambulatory clinics do just the opposite—generate a relatively large number of patient bills, each with a relatively small dollar amount. To date, it is fair to say that few IDNs have gained the degree of cost savings and efficiencies they had originally projected. The immense up-front costs of implementing (or integrating) the required HCISs in particular have contributed to this limited success. Regardless of organizational structure, all health care organizations are striving toward greater information access and integration, including improved information linkages with physicians and patients. The “typical” IDN is a melding of diverse organizations, and the associated information systems infrastructure is still far from integrated; rather, it remains in many cases an amalgam of heterogeneous systems, processes, and data stores.

1.2 Information Requirements

The most important function of any HCIS is to present data to decision makers so that they can improve the quality and timeliness of the decisions they need to make. From a clinical perspective, the most important function of an HCIS is to present patient-specific data to care givers so that they can easily interpret the data for diagnostic and treatment planning purposes, and support the necessary communication among the many health care workers who cooperate in providing health services to patients. From an administrative perspective, the most pressing information needs are those related to the daily operation and management of the organization—bills must be generated accurately and rapidly, employees and vendors must be paid, supplies must be ordered, and so on. In addition, administrators need information to make short-term and long-term planning decisions.

Since clinical system information requirements are discussed in Chaps. 12, 13, 15, and 22, we focus here on operational information needs, and specifically on four broad categories: daily operations, planning, communication, and documentation and reporting.

  • Operational requirements. Health care workers—both care givers and administrators—require detailed and up-to-date factual information to perform the daily tasks that keep a hospital, clinic, or physician practice running—the bread-and-butter tasks of the institution. Here are examples of queries for operational information: Where is patient John Smith? What drugs is he receiving? What tests are scheduled for Mr. Smith after his discharge? Who will pay his bill? Is the staffing skill mix sufficient to handle the current volume and special needs of patients in Care Center 3 West? What are the names and telephone numbers of patients who have appointments for tomorrow and need to be called for a reminder? What authorization is needed to perform an ultrasound procedure on Jane Blue under the terms of her health insurance coverage? HCISs can support these operational requirements for information by organizing data for prompt and easy access. Because the HCO may have developed product-line specialization within a particular facility (e.g., a diagnostic imaging center or women’s health center), however, answering even a simple request may require accessing information stored in different systems at several different facilities.

  • Planning requirements. Health professionals also require information to make short-term and long-term decisions about patient care and organizational management. The importance of appropriate clinical decision-making is obvious—we devote all of Chaps. 3 and 22 to explaining methods to help clinicians select diagnostic tests, interpret test results, and choose treatments for their patients. The decisions made by administrators and managers are no less important in their choices concerning the acquisition and use of health care resources. In fact, clinicians and administrators alike must choose wisely in their use of resources to provide high-quality care and excellent service at a competitive price. HCISs should help health care personnel to answer queries such as these: What are the organization’s clinical guidelines for managing the care of patients with this condition? Have similar patients experienced better clinical outcomes with medical treatment or with surgical intervention? What are the financial and medical implications of closing the maternity service? If we added six care managers to the outpatient-clinic staff, can we improve patient outcomes and reduce emergency admissions? Will the proposed contract to provide health services to Medicaid patients be profitable given the current cost structure and current utilization patterns? Often, the data necessary for planning are generated by many sources. HCISs can help planners by aggregating, analyzing, and summarizing the information relevant to decision-making.

  • Communication requirements. Communication and coordination of patient care and operations across multiple personnel, multiple business units, and far-flung geography is not possible without investment in an underlying technology infrastructure. For example, the routing of paper medical records, a cumbersome process even within a single hospital, is an impossibility for a regional network of providers trying to act in coordination. Similarly, it is neither timely nor cost effective to copy and distribute hard copy documents to all participants in a regionally distributed organization. An HCO’s technology infrastructure can enable information exchange via web-based access to shared databases and documents, electronic mail, standard document-management systems, and on-line calendaring systems, as well as providing and controlling access for authorized users at the place and time that information is required.

  • Documentation and reporting requirements. The need to maintain records for future reference or analysis and reporting makes up the fourth category of informational requirements. Some requirements are internally imposed. For example, a complete record of each patient’s health status and treatment history is necessary to ensure continuity of care across multiple providers and over time. External requirements create a large demand for data collection and record keeping in HCOs (as with mandated reporting of vaccination records to public health agencies). As discussed in Chap. 12, the medical record is a legal document. If necessary, the courts can refer to the record to determine whether a patient received proper care. Insurance companies require itemized billing statements, and medical records substantiate the clinical justification of services provided and the charges submitted to them. The Joint Commission (JC), which certifies the qualifications and performance of many health care organizations, has specific requirements concerning the content and quality of medical records, as well as requirements for organization-wide information-management processes. Furthermore, to qualify for participation in the Medicare and Medicaid programs, the JC requires that hospitals follow standardized procedures for auditing the medical staff and monitoring the quality of patient care, and they must be able to show that they meet the safety requirements for infectious disease management, buildings, and equipment. Employer and consumer groups are also joining the list of external monitors.

1.3 Integration Requirements

If an HCO is to manage patient care effectively, project a focused market identity, and control its operating costs, it must perform in a unified and consistent manner. For these reasons, information technologies to support data and process integration are recognized as critical to an HCO’s operations. From an organizational perspective, information should be available when and where it is needed; users must have an integrated view, regardless of system or geographic boundaries; data must have a consistent interpretation; and adequate security must be in place to ensure access only by authorized personnel and only for appropriate uses. Unfortunately, these criteria are much easier to describe than to meet.

1.3.1 Data Integration

In hospitals, clinical and administrative personnel have traditionally had distinct areas of responsibility and performed many of their functions separately. Thus, it is not surprising that administrative and clinical data have often been managed separately—administrative data in business offices and clinical data in medical-records departments. When computers were first introduced, the hospital’s information processing was often performed on separate computers with separate databases, thus minimizing conflicts about priorities in services and investment. As we have seen earlier in this chapter, information systems to support hospital functions and ambulatory care historically have, due to organizational boundaries, developed independently. Many hospitals, for example, have rich databases for inpatient data but maintain less information for outpatients—often including only billing data such as diagnosis and procedure codes and charges for services provided. Even today, relatively few clinical data are available in electronic format for most ambulatory-care clinics and physician offices in the United States, although this disparity is beginning to diminish as hospitals and physician practices continue a long term trend toward greater integration and increasing investments in HCISs. As fee-for-service reimbursement models continue to be challenged for their focus on activity-driven care, alternatives such as Accountable Care Organizations (ACOs), bundled payments for services, and pay for performance proposals will stimulate efforts toward greater data integration.

The historical lack of integration of data from diverse sources creates a host of problems. If clinical and administrative data are stored on separate systems, then data needed by both must either be entered separately into each system, be copied from one system to another, or data from both sources transferred to yet another location in order to be analyzed. In addition to the expense of redundant data entry and data maintenance incurred by these approaches (see also the related discussion for the health information infrastructure in Chap. 13), the consistency of information tends to be poor because data may be updated in one place and not in the other, or information may be copied incorrectly from one place to another. In the extreme example, the same data may be represented differently in different settings. As we noted earlier within the hospital setting, many of these issues have been addressed through the development of automated interfaces to transfer demographic data, orders, results, and charges between clinical systems and billing systems. Even with an interface engine managing data among disparate systems, however, an organization still must solve the thorny issues of synchronization of data and comparability of similar data types.

With the development of IDNs and other complex HCOs, the sharing of data elements among operating units becomes more critical and more problematic. Data integration issues are further compounded in IDNs by the acquisition of previously independent organizations that have clinical and administrative information systems incompatible with those of the rest of the IDN. It is still not unusual to encounter minimal automated information exchange among organizations even within an IDN. Patients register and reregister at the physician’s office, diagnostic imaging center, ambulatory surgery facility, and acute-care hospital—and sometimes face multiple registrations even within a single facility. Each facility may continue to keep its own clinical records, and shadow files may be established at multiple locations with copies of critical information such as operative reports and hospital discharge summaries. Inconsistencies in these multiple electronic and manual databases can result in inappropriate patient management and inappropriate resource allocation. For example, medications that are first given to a patient while she is a hospital inpatient may inadvertently be discontinued when she is transported to a rehabilitation hospital or nursing home. Also, information about a patient’s known allergies and medication history may be unavailable to physicians treating an unconscious patient in an emergency department.

The objectives of coordinated, high-quality, and cost-effective health care cannot be completely satisfied if an organization’s multiple computer systems operate in isolation. Unfortunately, free-standing systems within HCOs are still common, although HCOs and IDNs are increasingly investing in the implementation of new more consistent systems across all of their facilities or in integrating existing systems to allow data sharing. The capital investment required to pursue a strategy of system-wide data integration can be significant, and with ongoing challenges to reimbursement rates for both hospitals and physicians, the funding to pursue this strategy is often limited either due to competing investment requirements (e.g., acquiring or maintaining buildings and equipment) or the continued downward trend in reimbursement for services. In Sect. 14.4, we discuss architectural components and strategies for data integration.

1.3.2 Process Integration

To be truly effective, information systems must mesh smoothly with the people who use them and with the specific operational workflows of the organization. But process integration poses a significant challenge for HCOs and for the HCIS’s as well. Today’s health care-delivery models represent a radical departure from historical models of care delivery. Changes in reimbursement and documentation requirements may lead, for example, to changes in the responsibilities and work patterns of physicians, nurses, and other care providers; the development of entirely new job categories (such as care managers who coordinate a patient’s care across facilities or between encounters); and the more active participation of patients in their own personal health management (Table 14.1). Process integration is further complicated in that component entities typically have evolved different operational policies and procedures, which can reflect different historical and leadership experiences from one office to another, or in the extreme example, from one floor to another within a single hospital. The most progressive HCOs are developing new enterprise-wide processes for providing easy and uniform access to health services, for deploying consistent clinical guidelines, and for coordinating and managing patient care across multiple care settings throughout the organization. Integrated information technologies are essential to supporting such enterprise-wide processes. Mechanisms for information management aimed at integrating operations across entities must address not only the migration from legacy systems but also the migration from legacy work processes to new, more consistent and more standardized policies and processes within and across entities.

Table 14.1 The changing health care environment and its implications for an IDN’s core competencies

The introduction of new information systems almost always changes the workplace. In fact research has shown that in most cases the real value from an investment in information systems comes only when underlying work processes are changed to take advantage of the new information technology (Vogel 2003; see Figs. 14.4 and 14.5). At times, these changes can be substantial. The implementation of a new system offers an opportunity to rethink and redefine existing work processes to take advantage of the new information-management capabilities, thereby reducing costs, increasing productivity, or improving service levels. For example, providing electronic access to information that was previously accessible only on paper can shorten the overall time required to complete a multistep activity by enabling conversion of serial processes (completed by multiple workers using the same record sequentially) to concurrent processes (completed by the workers accessing an electronic record simultaneously). More fundamental business transformation is also possible with new technologies; for example, direct entry of medication orders by physicians, linked with a decision-support system, allows immediate checking for proper dosing and potential drug interactions, and the ability to recommend less expensive drug substitutes.

Fig. 14.4
figure 4

The process of managing the manual creation of orders requesting services on behalf of patients in a hospital involves numerous tasks performed not only by the ordering physician, but by nursing and clerical staff

Fig. 14.5
figure 5

The implementation of an electronic physician order entry system reduces the number of tasks that a physician needs to perform in order to enter an order, but such a system will only be successful if a number of other “complementary” changes are made to both the workflow of staff and the responsibilities of the IS Department

Few health care organizations today have the time or resources to develop entirely new information systems and redesigned processes on their own; therefore, most opt to purchase commercial software products and to use consultants to assist them in the implementation of industry “best practices”. Although these commercial systems allow some degree of custom tailoring, they also reflect an underlying model of work processes that may have evolved through development in other health care organizations with different underlying operational policies and procedures. In order to be successful, HCO’s typically must adapt their own work processes to those embodied in the systems they are installing (For example, some commercial systems require care providers to discontinue and then reenter all orders when a patient is admitted to the hospital after being monitored in the emergency department). Furthermore, once the systems are installed and workflow has been adapted to them, they become part of the organization’s culture—and any subsequent change to the new system may be arduous because of these workflow considerations. Decision-makers should take great care when selecting and configuring a new system to support and enhance desired work processes. Such organizational workflow adaptation represents a significant challenge to the HCO and its systems planners. Too often organizations are unable to realize the full potential return on their information-technology investments when they attempt to change the system to accommodate historical work flows, even before the new system is installed. Such management practices can significantly reduce much of the potential gains from the HCO’s IT investment.

To meet the continually evolving financial and quality documentation requirements of today’s health care environment, HCOs must continually evolve as well—and the analogy between changing an HCO and turning an aircraft carrier seems apt. Although an HCO’s business plans and information-systems strategies may be reasonable and necessary, changing ingrained organizational behavior can be much more complex than changing the underlying information systems. Technology capabilities often exceed an HCO’s ability to use them effectively and efficiently. Successful process integration requires not only successful deployment of the technology but also sustained commitment of resources to use that technology well; dedicated leadership with the willingness to make difficult, sometimes unpopular decisions; education; and possibly new performance incentives to overcome cultural inertia and politics. Government incentives to stimulate HCOs toward the meaningful use of information technology, which emerged from the 2010 Health care Reform legislation (Chap. 27), are a recent example of attempts to bring process integration and data integration together.

1.4 Security and Confidentiality Requirements

The protection of health information from unwanted or inappropriate use is governed not only by the trust of patients in their health providers but also by law. In accordance with the Health Insurance Portability and Accountability Act (HIPAA) of 1996 (Chap. 10), the Secretary of Health and Human Services recommended that “Congress enact national standards that provide fundamental privacy rights for patients and define responsibilities for those who serve them.” This law and subsequent federal regulations now mandate standardized data transactions for sending data to payer organizations, the development and adherence to formal policies for securing and maintaining access to patient data, and under privacy provisions, prohibit disclosure of patient-identifiable information by most providers and health plans, except as authorized by the patient or explicitly permitted by legislation. Recent changes to the HIPAA regulations have strengthened considerably the requirements for security and privacy protections and have also given patients the right to pursue actions against both organizations and individuals when they feel that their personal information has been compromised. HIPAA also provides consumers with significant rights to be informed about how and by whom their health information will be used, and to inspect and sometimes amend their health information. Stiff criminal penalties including fines and possible imprisonment are associated with noncompliance or the knowing misuse of patient-identifiable information.

Computer systems can be designed to provide security, but only people can promote the trust necessary to protect the confidentiality of patients’ clinical information. In fact, most breeches and inappropriate disclosures stem from human actions rather than from computer system failures. To achieve the goal of delivering coordinated and cost-effective care, clinicians need to access information on specific patients from many different locations. Unfortunately, it is difficult to predict in advance which clinicians will need access to which patient data and from which locations. Therefore, an HCIS must strike a balance between restricting information access and ensuring the accountability of the users of patient information. To build trust with its patients and meet HIPAA requirements, an HCO should adopt a three-pronged approach to securing information. First, the HCO needs to designate a security officer (and typically a privacy officer as well) and develop uniform security and confidentiality policies, including specification of sanctions, and to enforce these policies rigorously. Second, the HCO needs to train employees so they understand the appropriate uses of patient-identifiable information and the consequences of violations. Third, the HCO must use electronic tools such as intrusion detection, access controls and audit trails not only to discourage misuse of information, but also to inform employees and patients that people who access confidential information without proper authorization or a “need to know”, can be tracked and will be held accountable.

1.5 The Benefits of Health care Information Systems

On average, health care workers in administrative departments spend about three-fourths of their time handling information; workers in nursing units spent about one-fourth of their time on these tasks. The fact is that information management in health care organizations, even with significant computerization, is a costly activity. The collection, storage, retrieval, analysis, and dissemination of the clinical and administrative information necessary to support the organization’s daily operations, to meet external and internal requirements for documentation and reporting, and to support short-term and strategic planning remain important and time-consuming aspects of the jobs of health-care workers.

Today, the justifications for implementing HCISs include cost reduction, productivity enhancement, and quality and service improvement, as well as strategic considerations related to competitive advantage and regulatory compliance (Vogel 2003):

  • Cost reduction. Much of the historical impetus for implementing HCISs was their potential to reduce the costs of information management in hospitals and other facilities. HCOs continue to make tactical investments in information systems to streamline administrative processes and departmental workflow. Primary benefits that may offset some information-systems costs include reductions in labor requirements, reduced waste (e.g., dated surgical supplies that are ordered but unused or food trays that are delivered to the wrong destination and therefore are wasted), and more efficient management of supplies and other inventories. Large savings can be gained through efficient scheduling of expensive resources such as operating suites and imaging equipment. In addition, HCISs can help to eliminate inadvertent ordering of duplicate tests and procedures. Once significant patient data are available online, information systems can reduce the costs of storing, retrieving, and transporting charts in the medical-records department.

  • Productivity Enhancements. A second area of benefit from an HCIS comes in the form of improved productivity of clinicians and other staff. With continuing (and at times increasing) constraints on reimbursements, HCOs are continually faced with the challenge of doing more with less. Providing information systems support to staff can in many cases enable them to manage a larger variety of tasks and data than would otherwise be possible using strictly manual processes. Interestingly, in some cases hospital investments in an HCIS support the productivity improvement of staff that are not employed by the hospital, namely the physicians, and can even extend to payers by lowering their costs. One of the major challenges with introducing a new HCIS is that the productivity of users may actually decrease in the initial months of the implementation. With complex clinical applications in particular, learning new ways of working can lead to high levels of user dissatisfaction in addition to lowered productivity.

  • Quality and service improvement. As HCISs have broadened in scope to encompass support for clinical processes, the ability to improve the quality of care has become an additional benefit. Qualitative benefits of HCISs include improved accuracy and completeness of documentation, reductions in the time clinicians spend documenting (and associated increases in time spent with patients), fewer drug errors and quicker response to adverse events, and improved provider-to-provider communication. Through telemedicine and remote linkages (see Chap. 18), HCOs are able to expand their geographical reach and improve delivery of specialist care to rural and outlying areas. Once patient data are converted from a purely transaction format to a format better suited for analytic work, the use of clinical decision-support systems in conjunction with a clinically focused HCIS can produce impressive benefits, namely improving the quality of care while reducing costs (Chap. 22) (Bates and Gawande 2003; James and Savitz 2011; Goldzweig, et al. 2009; Himmelstein and Woolhandler 2010; McCullough et al. 2010).

  • Competitive advantage. Information technologies must be deployed appropriately and effectively; however, with respect to HCISs, the question is no longer whether to invest, but rather how much and what to buy. Although some organizations still attempt to cost justify all information-systems investments, many HCOs have recognized that HCISs are “enabling technologies” which means that the value comes not from the system itself but from what it “enables” the organization to do differently and better. If workflow and processes are not changed to take advantage of the technology, the value of the investment will largely go unrealized. And it is not just the ratio of financial benefits to costs that is important; access to clinical information is necessary not only to carry out patient management, but also to attract and retain the loyalty of physicians who care for (and thus control much of the HCO’s access to) the patients. The long-term benefits of clinical systems include the ability to influence clinical practices by reducing large unnecessary variations in medical practices, to improve patient outcomes, and to reduce costs—although these costs might be more broadly economic and societal than related to specific reductions for the hospital itself (Leatherman et al. 2003, James and Savitz 2011). Physicians ultimately control the great majority of the resource-utilization decisions in health care through their choices in prescribing drugs, ordering diagnostic tests, and referring patients for specialty care. Thus, providing physicians with access to information on “best practices” based on the latest available clinical evidence, as well as giving them other clinical and financial data to make appropriate decisions, is an essential HCIS capability.

  • Regulatory compliance. Health care is among the most heavily regulated industries in our economy. State and federal regulatory agencies perform a variety of oversight activities, and these require increasingly sophisticated and responsive HCISs to provide the necessary reports. For example, the Food and Drug Administration now mandates the use of barcodes on all drugs. Similarly, HIPAA rules specify the required content and format for certain electronic data transactions for those HCOs that exchange data electronically. OSHA, the Department of Labor, the Environmental Protection Agency, the Nuclear Regulatory Commission, and a host of other agencies all have an interest in seeing that the health care provided by HCOs is consistent with standards of safety and fairness.

1.6 Managing Information Systems in a Changing Health Care Environment

Despite the importance of integrated information systems, implementation of HCISs has proved to be a daunting task, often requiring a multiyear capital investment of tens (and at times, hundreds) of millions of dollars and forcing fundamental changes in the types and ways that health care professionals perform their jobs. To achieve the potential benefits, health organizations must plan carefully and invest wisely. The grand challenge for an HCO is to implement an HCIS that is sufficiently flexible and adaptable to meet the changing needs of the organization. Given the rapidly changing environment and the multiyear effort involved, people must be careful to avoid implementing a system that is obsolete functionally or technologically before it becomes operational. Success in implementing an HCIS entails consistent and courageous handling of numerous technical, organizational, and political challenges.

1.6.1 Changing Technologies

As we discussed in Chaps. 5 and 6, past decades have seen dramatic changes in computing and networking technologies. These advances are important in that they allow quicker and easier information access, less expensive computational power and data storage, greater flexibility, and other performance advantages. A major challenge for many HCOs is how to decide whether to support a best of breed strategy, with its requirement either to upgrade individual systems and interfaces to newer products or to migrate from their patchwork of legacy systems to a more integrated systems environment. Such migration requires integration and selective replacement of diverse systems that are often implemented with closed or nonstandard technologies and medical vocabularies. Unfortunately the trade-off between migrating from best of breed to more integrated systems is that vendors offering more integrated approaches seldom match the functionality of the best of breed environment. However, this strategy is becoming less of an option since commercial vendors are broadening and deepening the scope of their application suites in order to minimize the challenges of building and managing interfaces and to protect their market share. In a sense, it is the information content of the systems and the ability to implement them that is much more important than the underlying technology—as long as the data are accessible, the choice of specific technology is less critical.

1.6.2 Changing Culture

In the current health care environment, physicians are confronted with significant obstacles to the practice of medicine as they have historically performed it. With a long history of entrepreneurial practice, physicians face significant adjustments as they are confronted by pressures to practice in accordance with institutional standards aimed at reducing variation in care, and to focus on the costs of care even when those costs are borne either by hospitals or by third party payers. They are expected to assume responsibility not simply for healing the sick, but for the wellness of people who come to them not as patients but as members of health plans and health maintenance organizations. In addition, they must often work as members of collaborative patient-care teams. The average patient length of stay in a hospital is decreasing; at the same time, the complexity of the care provided both during and after discharge is increasing. The time allotted for an individual patient visit in an ambulatory setting is decreasing as individual clinicians face economic incentives to increase the number of patients for whom they care each day. Some HCOs, aided by federal funding incentives, are now instituting pay-for performance incentives to reward desired work practices. At the same time, it is well known that the amount of knowledge about disease diagnosis and treatment increases significantly each year, with whole new areas of medicine being added from major breakthroughs in areas such as genomic and imaging research. To cope with the increasing workload, greater complexity of care, extraordinary amounts of new medical knowledge, new skills requirements, and the wider availability of medical knowledge to consumers through the Internet, both clinicians and health executives must become more effective information managers, and the supporting information systems must meet their workflow and information requirements. As the health care culture and the roles of clinicians and health executives continue to change, HCOs must constantly reevaluate the role of information technology to ensure that the implemented systems continue to match user requirements and expectations.

1.6.3 Changing Processes

Developing a new vision of how health care will be delivered and managed, designing processes and implementing supporting information systems are all critical to the success of evolving HCOs. Changes in process affect the jobs that people do, the skills required to do those jobs, and the fundamental ways in which they relate to one another. For example, models of care management that cross organizational or specialty boundaries encourage interdisciplinary care teams to work in harmony to promote health as well as treat illness. Although information systems are not the foremost consideration for people who are redesigning processes, a poor information-systems implementation can institutionalize bad processes.

HCOs periodically undertake various process redesign initiatives (following models such as Six Sigma or LEAN), and these initiatives can lead to fundamental transformations of the enterprise. Indeed, work process redesign is essential if information systems are to become truly valuable “enablers” in HCOs. Too often, however, the lack of a clear understanding of existing organizational dynamics leads to a misalignment of incentives—a significant barrier to change—or to the assumption that simply installing a new computer system will be sufficient to generate value. Moreover, HCOs, like many organizations, are collections of individuals who often have natural fears about and resistance to change. Even under the best of circumstances, there are limits to the amount of change that any organization can absorb. The magnitude of work required to plan and manage organizational change is often underestimated or ignored. The handling of people and process issues has emerged as one of the most critical success factors for HCOs as they implement new work methods and new and upgraded information systems.

1.6.4 Management and Governance

Figure 14.6 illustrates the information-technology environment of an HCO composed of two hospitals, an owned physician practice, affiliated nursing homes and hospice, and several for-profit service organizations. Even this relatively simple environment presents significant challenges for the management and governance of information systems. For example, to what extent will the information management function be controlled centrally versus decentralized to the individual operating units and departments? How should limited resources be allocated between new investment in strategic projects (such as office-based data access for physicians) and the often critical operational needs of individual entities (e.g., replacement of an obsolete laboratory information system)? Academic medical centers with distinct research and educational needs raise additional issues for managing information across operationally independent and politically powerful constituencies.

Fig. 14.6
figure 6

An example of an information systems environment for a small integrated delivery network (IDN). Even this relatively simply IDN has a complex mix of information systems that pose integration and information management challenges for the organization

Trade-offs between functional and integration requirements, and associated contention between users and information-systems departments, will tend to diminish over time with the development and widespread adoption of technology standards and common clinical-data models and vocabulary. On the other hand, an organization’s information-systems “wants” and “needs” will always outstrip its ability to deliver these services. Political battles will persist, as HCOs and their component operating units wrestle with the age-old issues of how to distribute scarce resources among competing, similarly worthy projects.

A formal HCIS governance structure with representation from all major constituents provides a critical forum for direction setting, prioritization, and resource allocation across an HCO. Leadership by respected clinical peers has proved a critical success factor for clinical systems planning, implementation, and acceptance. In addition, the creation of an Information Systems Advisory or Steering Committee composed of the leaders of the various constituencies within the HCO, can be a valuable exercise if the process engages the organization’s clinical, financial, and administrative leadership and users and results in their gaining not only a clear understanding of the highest-priority information technology investment requirements but also provides a sense of accountability and ownership over the HCISs and their various functions (Vogel 2006). This supports one of the principles of information technology governance: how an institution makes IT investment decisions is often more important than what specific decisions are made (Weill and Ross 2004). Because of the dynamic nature of both health care business strategies and the supporting technologies, many HCOs have seen the timeframes of their strategic information-management thinking shrink from 5 years to three, and then be changed yet again through annual updates.

2 Functions and Components of a Health Care Information System

Carefully designed computer-based information systems can increase the effectiveness and productivity of health professionals, improve the quality and reduce the costs of health services, and improve levels of service and of patient satisfaction. As described in Sect. 14.1, the HCISs support a variety of functions, ranging from the delivery and management of patient care to the administration of the health organization. From a functional perspective, HCISs typically consist of components that support five distinct purposes: (1) patient management and billing, (2) ancillary services, (3) care delivery and clinical documentation, (4) clinical decision support, (5) institutional financial and resource management.

2.1 Patient Management and Billing

Systems that support patient management functions perform the basic HCO operations related to patients, such as registration, scheduling, admission, discharge, transfer among locations, and billing. Historically within HCOs, maintenance of the hospital census and a patient billing system were the first tasks to be automated—largely because a patient’s location determined not only the daily room/bed charges (since an ICU bed was more expensive than a regular medical/surgical bed) but where medications were to be delivered, and where clinical results were to be posted. Today, virtually all hospitals and ambulatory centers and many physician offices use a computer-based master patient index (MPI) to store patient-identification information that is acquired during the patient-registration process, and link to simple encounter-level information such as dates and locations where services were provided. The MPI can also be integrated within the registration module of an ambulatory care or physician-practice system or even elevated to an enterprise master patient index (EMPI) across several facilities. Within the hospital setting, the census is maintained by the admissiondischargetransfer (ADT) module, which is updated whenever a patient is admitted to the hospital, discharged from the hospital, or transferred from one bed to another.

Registration and patient census data serve as a reference base for the financial programs that perform billing functions. When an HCIS is extended to other patient-care settings—e.g., to the laboratory, pharmacy, and other ancillary departments—patient-management systems provide a common reference base for the basic patient demographic data needed by these systems. Without access to the centralized database of patient financial, demographic, registration and location data, these subsystems would have to maintain duplicate patient records. In addition, the transmission of registration data can trigger other activities, such notification of hospital housekeeping when a bed becomes available after a patient is discharged. The billing function in these systems serves as a collection point for all of the chargeable patient activity that occurs in a facility, including room/bed charges, ancillary service charges, and supplies used during a patient’s stay.

Scheduling in a health care organization is complicated because patient load and resource utilization can vary by day, week, or season or even through the course of a single day simply due to chance, emergencies that arise, or to patterns of patient and physician behavior. Effective resource management requires that the appropriate resources be on hand to meet such fluctuations in demand. At the same time, resources should not remain unnecessarily idle since that would result in their inefficient use. The most sophisticated scheduling systems have been developed for the operating rooms and radiology departments, where scheduling challenges include matching the patient not only with the providers but also with special equipment and support staff such as technicians. Patient-tracking applications monitor patient movement in multistep processes; for example, they can monitor and manage patient wait times in the emergency department.

Within a multi-facility HCO, the basic tasks of patient management are compounded by the need to manage patient care across multiple settings, some of which may be supported by independent information systems. Is the Patricia C. Brown who was admitted last month to Mountainside Hospital the same Patsy Brown who is registering for her appointment at the Seaview Clinic? Integrated delivery networks ensure unique patient identification either through conversion to common registration systems or, more frequently, through implementation of an enterprise EMPI (see Sect. 14.4) that links patient identifiers and data from multiple registration systems.

2.2 Ancillary Services

Ancillary departmental systems support the information needs of individual clinical departments within an HCO. From a systems perspective, those areas most commonly automated are the laboratory, pharmacy, radiology, blood-bank, operating rooms, and medical-records departments, but can also include specialized systems to support cardiology (for EKGs), respiratory therapy and social work. Such systems serve a dual purpose within an HCO. First, ancillary systems perform many dedicated tasks required for specific departmental operations. Such tasks include generating specimen-collection lists and capturing results from automated laboratory instruments in the clinical laboratory, printing medication labels and managing inventory in the pharmacy, and scheduling examinations and supporting the transcription of image interpretations in the radiology department. In addition, information technology coupled with robotics can have a dramatic impact on the operation of an HCO’s ancillary departments, particularly in pharmacies (to sort and fill medication carts) and in clinical laboratories (where in some cases the only remaining manual task is the collection of the specimen and its transport to the laboratory’s robotic system). Second, the ancillary systems contribute major data components to online patient records, including laboratory-test results and pathology reports, medication profiles, digital images (see Chap. 20), records of blood orders and usage, and various transcribed reports including history and physical examinations, operating room and radiology reports. HCOs that consolidate ancillary functions outside hospitals to gain economies of scale—for example, creating outpatient diagnostic imaging centers and reference laboratories—increase the complexity of integrated patient management, financial, and billing processes.

2.3 Care Delivery and Clinical Documentation

Electronic health record (EHR) systems that support care delivery and clinical documentation are discussed at length in Chap. 12. Although comprehensive EHRs are the ultimate goal of most HCOs, many organizations today are still building more basic clinical-management capabilities. Automated order entry and results reporting are two important functions provided by the clinical components of an HCIS. Health professionals can use the HCIS to communicate with ancillary departments electronically, eliminating the easily misplaced paper slips or the transcription errors often associated with translating hand-written notes into typed requisitions, thus minimizing delays in conveying orders. The information then is available online, where it is easily accessible by any authorized health professional that needs to review a patient’s medication profile or previous laboratory-test results. Ancillary departmental data represent an important subset of a patient’s clinical record. A comprehensive clinical record, however, also includes various data that clinicians have collected by questioning and observing the patient, including the history and physical report, progress notes and problem lists. In the hospital, an HCIS can help health personnel perform an initial assessment when a patient is admitted to a unit, maintain patient-specific care plans, chart vital signs, maintain medication-administration records, record diagnostic and therapeutic information, document patient and family teaching, and plan for discharge (also see Chap. 15). Many organizations have developed diagnosis-specific clinical pathways that identify clinical goals, interventions, and expected outcomes by time period. Using clinical pathways, case managers or care providers can document actual versus expected outcomes and are alerted to intervene when a significant unexpected event occurs. More hospitals are now implementing systems to support what are called closed loop medication management systems in which every task from the initial order for medication to its administration to the patient is recorded in an HCIS—one outcome of increased attention to patient safety issues.

With the shift toward delivering more care in outpatient settings, clinical systems have become more common in ambulatory clinics and physician practices. Numerous vendors have introduced smart phones, tablets, and other mobile devices with software designed specifically for physicians in ambulatory settings, so that they can access appropriate information even as they move from one exam room to another. Such systems allow clinicians to record problems and diagnoses, symptoms and physical examinations, medical and social history, review of systems, functional status, active and past prescriptions, provide access to therapeutic and medication guidelines, etc. The most successful systems are integrated with a practice management system, providing additional support for physician workflow and typical clinic functions, for example, by documenting telephone follow-up calls or printing prescriptions. In addition, specialized clinical information systems have been developed to meet the specific requirements of intensive-care units (see Chap. 19), long-term care facilities, home-health organizations, and specialized departments such as cardiology and oncology.

2.4 Clinical Decision Support

Clinical decision-support systems (Chap. 22) directly assist clinical personnel in data interpretation and decision-making. Once the basic clinical components of an HCIS are well developed, clinical decision-support systems can use the information stored there to monitor patients and issue alerts, to make diagnostic suggestions, to provide limited therapeutic guidance, and to provide information on medication costs. These capabilities are particularly useful when they are integrated with other information-management functions. For example, a useful adjunct to computer-based physician order-entry (CPOE) is a decision-support program that alerts physicians to patient food or drug allergies; helps physicians to calculate patient-specific drug-dosing regimens; performs advanced order logic, such as recommending an order for prophylactic antibiotics before certain surgical procedures; automatically discontinues drugs when appropriate or prompts the physician to reorder them; suggests more cost-effective drugs with the same therapeutic effect; or activates and displays applicable clinical-practice guidelines (see Chap. 22). Clinical-event monitors integrated with results-reporting applications can alert clinicians to abnormal results and drug interactions by electronic mail, text message or page. In the outpatient setting, these event monitors may produce reminders to provide preventive services such as screening mammograms and routine immunizations. The same event monitors might trigger access to the HCO’s approved formulary, displaying information that includes costs, indications, contraindications, approved clinical guidelines, and relevant online medical literature (Perreault and Metzger 1999; Teich et al. 1997; Kaushal et. al. 2003).

2.5 Financial and Resource Management

Financial and administrative systems assist with the traditional business functions of an HCO, including management of the payroll, human resources, general ledger, accounts payable, and materials purchasing and inventory. Most of these data-processing tasks are well structured, and have been historically labor intensive and repetitious—ideal opportunities for substitution with computers. Furthermore, with the exception of patient-billing functions, the basic financial tasks of an HCO do not differ substantially from those of organizations in other industries. Not surprisingly, financial and administrative applications have typically been among the first systems to be standardized and centralized in IDNs.

Conceptually, the tasks of creating a patient bill and tracking payments are straightforward, and financial transactions such as claims submission and electronic funds transfer have been standardized to allow electronic data interchange (EDI) among providers and payers. In operation, however, patient accounting requirements are complicated by the myriad and oft-changing reimbursement requirements of government and third-party payers. These requirements vary substantially by payer, by insurance plan, by type of facility where service was provided, and often by state. As the burden of financial risk for care has shifted from third party payers to providers (through per diem or diagnosis-based reimbursements), these systems have become even more critical to the operation of a successful HCO. As another example, managed care contracts add even more complexity, necessitating processes and information systems to check a patient’s health-plan enrollment and eligibility for services, to manage referrals and preauthorization for care, to price claims based on negotiated contracts, and to create documentation required to substantiate the services provided.

As HCOs increasingly go “at risk” for delivery of health services by negotiating per diem, diagnosis-based, bundled and capitated payments, their incentives need to focus not only on reducing the cost per unit service but also on maintaining the health of members while using health resources effectively and efficiently. Similarly, the HCO’s scope of accountability broadens from a relatively small population of sick patients to a much larger population of plan members (such as might be found in ACOs), most of whom are still well.

Provider-profiling systems support utilization management by tracking each provider’s resource utilization (costs of drugs prescribed, diagnostic tests and procedures ordered, and so on) compared with severity-adjusted outcomes of that provider’s patients such as their rate of hospital readmission and mortality by diagnosis. Such systems are also being used by government bodies and consumer advocate organizations as they publicize their findings, often through the Internet. Contract-management systems have capabilities for estimating the costs and payments associated with potential managed care contracts and comparing actual with expected payments based on the terms of the contracts. More advanced managed-care information systems handle patient triage and medical management functions, helping the HCOs to direct patients to appropriate health services and to proactively manage the care of chronically ill and high-risk patients. Health plans, and IDNs that incorporate a health plan, also must support payer and insurance functions such as claims administration, premium billing, marketing, and member services.

3 Historical Evolution of the Technology of Health care Information Systems (HCISs)

Technological advances and changes in the information and organizational requirements of HCOs have driven many of the changes in system architecture, hardware, software, and functionality of HCISs over time. The tradeoff between functionality and ease of integration is another important factor that accounts for choices that vendors have made in systems design (see Fig. 14.7).

Fig. 14.7
figure 7

The evolution of computing systems in hospitals has followed a path that parallels the evolution of computing systems in general. From mainframes to minicomputers to desktops, and more recently mobile devices, the purpose and function of systems in hospitals has followed a path from financial systems to departmental systems to systems designed specifically to enhance the productivity and raise the quality of health care services

3.1 Central and Mainframe-based Systems

The earliest HCISs (typically found in hospitals) were designed according to the philosophy that a single comprehensive or central computer system could best meet an HCO’s information processing requirements. Advocates of the centralized approach emphasized the importance of first identifying all the hospital’s information needs and then designing a single, unified framework to meet these needs. As we have seen, patient management and billing functions were the initial focus of such efforts. One result of this design goal was the development of systems in which a single, large computer performed all information processing and managed all the data files using application-independent file-management programs—although focusing almost exclusively on financial and billing data. Users accessed these systems via general-purpose video-display terminals (VDTs) affectionately known as “green screens” because the displayed numbers and text were often green on a dark background.

One of the first clinically-oriented HCISs was the Technicon Medical Information System. System development began in 1965 as a collaborative project between the Lockheed Corporation and El Camino Hospital, a community hospital in Mountain View, California. By 1987, the system had been installed in more than 85 institutions by Technicon Data Systems (TDS), which had purchased the system from Lockheed in 1971. TDS was one of the earliest examples of a large, centrally operated, and clinically focused HCIS. Depending on the size of the central machine, the TDS center could support from several hundred to a few thousand hospital beds. Because of this high capacity, one computer installation could serve multiple hospitals in an area. The hospitals were connected via high-speed dedicated telephone lines linked to the central computer. Within a hospital, a switching station connected the telephone lines to an onsite network connecting to stations on every patient-care unit. Each unit had at least one VDT and one printer which enabled users to display, and print patient information. Initially, TDS sold proprietary terminals, printers, light pens and even implemented their own data transmission protocols, but as more general purpose PCs became prominent and data networking protocols more standardized, the proprietary nature of the system diminished to where the focus was entirely on the software. Because the TDS system was designed for use by both nurses and physicians it was one of the first systems to support both nursing clinical documentation and physician order entry.

The Center for Clinical Computing (CCC) system, developed by Howard Bleich and Warner Slack as a centralized clinical computing system, was first deployed in 1978 at the Beth Israel Medical Center in Boston (now part of the Beth Israel Deaconess Medical Center and the CareGroup IDN). Still in operation, this system is designed around a single common registry of patients, with tight integration of all its departmental systems. It was remarkable in the breadth of its functionality to support physicians and the intensity of its use by clinicians. It was the first system to offer hospital-wide electronic mail, as well as end-user access to Medline via PaperChase. In addition, CCC was among the first to employ audit trails on who was looking at patient data, a feature now common in clinical systems (and a HIPAA requirement). In ambulatory clinics, an electronic patient record including support for problem lists, clinic notes, prescription writing, and other functions supported over 1,000 clinicians in more than 30 primary-care and specialty areas (Safran et al. 1991). On the other hand, the system provided only limited support for order entry, alerts, and reminders. The CCC also featured a MUMPS database functioning as a clinical-data repository and an online data warehouse, called ClinQuery (Safran et al. 1989) with complete data on all test results and medications, as well as ICD-9-CM and SNOMED diagnosis codes. The CCC was transferred to the Brigham and Women’s Hospital in 1983 and was subsequently developed separately as the Brigham Integrated Computer System (BICS), a distributed client–server system. In 2012, Partners Health care, of which Brigham and Women’s Hospital is a member organization, made the decision to replace BICS and other in-house developed systems with a commercial vendor product.

Central systems integrated and communicated information well because they provided users with a centralized data store and a single, standardized method to access information simply and rapidly. On the other hand, the biggest limitation of central systems was their inability to accommodate the diverse needs of individual departments. There is a tradeoff between the uniformity (and relative simplicity) of a generalizable system and the nonuniformity and greater responsiveness of custom-designed systems that solve specific problems. Generality—a characteristic that enhances communication and data integration in a homogeneous environment—can be a drawback in an HCO because of the complexity and heterogeneity of the information-management tasks. In general, central systems have proved too unwieldy and inflexible to support current HCO requirements, except in smaller facilities. The development of smaller but powerful computing platforms subsequently led to software development that focused more on specific departmental requirements.

3.2 Departmental Systems

By the 1970s, departmental systems began to emerge. Decreases in the price of hardware and improvements in software made it feasible for individual departments within a hospital to acquire and operate their own computers. In a departmental system, one or a few computers can be dedicated to processing specific functional tasks within the department. Distinct software application modules carry out specific tasks, and a common framework, which is specified initially, defines the interfaces that will allow data to be shared among the modules. Radiology (Chap. 20) and Laboratory systems are examples of this type of system.

The most ambitious project based on the departmental approach was the Distributed Hospital Computer Program (DHCP) for the Veterans Administration (VA) hospitals which was initially announced in 1982, although based on work begun at the VA in the 1970s. The system had a common database (Fileman), which was written to be both hardware- and operating-system-independent. A small number of support centers in the VA developed the software modules in cooperation with user groups. The CORE—the first set of applications to be developed and installed—consisted of modules for patient registration, ADT, outpatient scheduling, laboratory, outpatient pharmacy, and inpatient pharmacy. Modules to support other clinical departments (such as radiology, dietetics, surgery, nursing, and mental health) and administrative functions (such as financial and procurement applications) were developed subsequently. By 1985, the VA had installed DHCP in more than one-half of its approximately 300 hospitals and clinics. The software was in the public domain and was also used in private hospitals and other government facilities (Kolodner and Douglas 1997). Interestingly, one of the reasons for the success of the VA system was its ability to focus on the clinical environment. Given the nature of government reimbursement for the care of veterans at the time, there was no need to develop or integrate a billing function into the DHCP system.

The departmental approach responded to many of the challenges of central systems. Although individual departmental systems are constrained to function with predefined interfaces, they do not have to conform to the general standards of an overall system, so they can be designed to accommodate the special needs of specific areas. For example, the processing capabilities and file structures suitable for managing the data acquired from a patient-monitoring system in the intensive-care unit (analog and digital signals acquired in real time) differ from the features that are appropriate for a system that reports radiology results (text storage and text processing). Furthermore, modification of departmental systems, although laborious with any approach, is simpler because of the smaller scope of the system. The price for this greater flexibility is increased difficulty in integrating data and communicating among modules of the HCISs. In reality, installing a subsystem is never as easy as simply plugging in the connections.

Also in the early 1980s, researchers at the University of California, San Francisco (UCSF) Hospital successfully implemented one of the first Local Area Networks (LANs) to support communication among several of the hospital’s standalone systems in the early 1980s. Using technology developed at the Johns Hopkins University, they connected minicomputers that supported patient registration, medical records, radiology, the clinical laboratory, and the outpatient pharmacy. Interestingly, each of the four computer systems was different from the other three: the computers were made by different manufacturers and ran different operating systems (McDonald, Wiederhold et al. 1984a) but were able to communicate with each other through standardized communications protocols.

By the late1980s, HCISs based on evolving network-communications standards were being developed and implemented in HCOs. As distributed computer systems, connected through electronic networks, these HCISs consisted of a federation of independent systems that had been tailored for specific application areas. The computers operated autonomously and shared data (and sometimes programs and other resources, such as printers) by exchanging information over a local area network (LAN; see Chap. 5) using standard protocols such as TCP/IP and Health Level 7(HL7) for communication and in many cases utilizing the interface engine strategy we discussed earlier in Sect. 14.1.1.

The University of Michigan Hospital in Ann Arbor later adopted a hybrid strategy to meet its information needs. The hospital supported a central model of architecture and operated a mainframe computer to perform core HCIS functions. In 1986, however, it installed a local area network (LAN) to allow communication among all its internal clinical laboratories and to allow physicians to obtain laboratory-test results directly from the laboratory information system. At the time of installation, more than 95 % of all the peripheral devices in the laboratories were connected to the network rather than hardwired directly to the laboratory computer. A second clinical host computer, which supported the radiology information system, was later added to the LAN, allowing physicians to access radiology reports as well. Although the mainframe HCIS initially was not connected to the LAN, the hospital later adopted the strategy of installing universal workstations that could access both the mainframe computer and the clinical hosts via the LAN (Friedman and Dieterle 1987).

One advantage of LAN-connected distributed systems was that individual departments could have greater flexibility in choosing hardware and software that optimally suited their specific needs. Even smaller ancillary departments such as Respiratory Therapy, which previously could not justify a major computer acquisition, could now purchase microcomputers and participate in the HCIS environment. Health care providers in nursing units or at the bedside, physicians in their offices or homes, and managers in the administrative offices could eventually access and analyze data locally using what were initially termed microcomputers (later known as desktop personal computers or PCs). On the downside, the distribution of information processing capabilities and responsibility for data among diverse systems made the tasks of data integration, communication, and security more difficult—a fact that continues to the present day. Development of industry-wide standard network and interface protocols such as TCP/IP and HL7 has eased the technical problems of electronic communication considerably. Still, there are problems to overcome in managing and controlling access to a patient database that is fragmented over multiple computers, each with its own file structure and method of file management. Furthermore, when no global architecture or vocabulary standards are imposed on the HCISs, individual departments and entities may encode data values in ways that are incompatible with the definitions chosen by other areas of the organization. The promise of sharing among independent departments, entities, and even independent institutions has increased the importance of defining clinical data standards (see Chap. 7). As noted earlier, some HCOs pursue a best of breed strategy in which they choose the best system, regardless of vendor and technology, then work to integrate that system into their overall HCIS environment. Some HCOs modify this strategy by choosing suites of related applications (e.g., selecting all ancillary systems from a single vendor, also known as best of cluster), thereby reducing the overall number of vendors they work with and, in theory, reducing the costs and difficulty of integration. Commercial software vendors have supported this strategy by broadening their offerings of application suites and managing the integration at the suite level rather than at the level of individual applications. Cerner and Epic are examples of clinical systems vendors who have pursued this strategy, and Oracle’s PeopleSoft and Lawson are examples on the financial/administrative side.

The complexity and variety of information processing requirements across today’s HCOs and IDNs, means that some level of distributed architecture is often required. Simply put, no single vendor has been able to develop and implement applications that support the entire range of an HCO’s information processing requirements. So in general, all large commercial systems support some type of distributed model. PC-based universal workstations are the norm as well. In fact, some HCOs and IDN’s now support thousands of PCs in enterprise-wide networked environments. The requirement for direct access to independent ancillary systems has been largely eliminated not only by enterprise data networks, but by interfaces that join such systems to a core clinical system or a centralized clinical data repository that receives clinical data from each ancillary system. For example, whereas staff working in the laboratory may access the laboratory system directly, clinicians may view all clinical results (laboratory, radiology, and so on) stored in a centralized clinical data repository. The ability to access patient databases (by clinicians), human resources documents (by employees), financial information (by administrators) and basic information about facilities, departments, and staff (by the public) is enabled through a single enterprise-wide data network (See Fig. 14.3).

3.3 Integrated Systems from Single Vendors

Many smaller HCOs have opted for implementation of turnkey systems, in which commercial vendors have bundled a number of functional capabilities into a single application suite (MEDITECH is a good example of this type of offering).

These systems offer a way to achieve reasonable function and integration, although they typically permit minimal customization to meet institution-specific workflows and requirements. In addition, they may not have the depth of specialized functions compared to systems designed for specific departmental functions. Numerous debates have been held at national conferences regarding the desirability of an integrated system versus best of breed approaches in which the various systems have to be interfaced in order to function. In the late 1990s, several large IDNs developed their IT strategies based on the use of integrated systems from vendors historically focused on smaller hospitals. This provided greater credibility to these vendors and at the same time challenged the long held assumption that the greater functionality of best of breed strategies, with their inherently greater cost and interface requirements, is the only viable strategy for large IDNs.

4 Architecture for a Changing Environment

As the complexity of the health care business continues to increase, HCOs and IDNs present new challenges to information systems developers. As we described in Sect. 14.1, most IDNs have developed through the merger or acquisition of independent organizations. Thus, the information systems environment of a new or evolving IDN can be a jumble of disparate legacy systems, technologies, and architectures. In such an environment, the challenge is for the IDN’s information systems team to configure systems and processes to support new business strategies (such as a diabetes management program or a central call center) and provide integrated information access throughout the IDN, while maintaining uninterrupted operational support for the IDN’s existing business units, and do so within the financial constraints of reimbursement levels that seem to decline almost annually.

Sometimes, an IDN will selectively replace specific systems to fit its new organizational structure and strategies (e.g., consolidation of the finance and human resources departments and migration to common corporate general ledger, accounts payable, payroll, and human resources systems for all business entities). As always, resources (both money and staff) are limited; and often it is simply not feasible for an IDN to replace all legacy systems with new common systems, so specific HCISs may remain relatively isolated for long periods of time.

Legacy systems environments and business strategies in both large HCOs and IDNs present unique information challenges. Nonetheless, a few lessons can be learned from past efforts. First, a strategy for data preservation must be developed by providing access to data and implementing an approach for standardizing the meaning of those data. Second, to the extent possible, IDNs and HCOs should separate three conceptual layers—data management, applications and business logic, and user interface—to allow greater flexibility (See Fig. 14.8).

Fig. 14.8
figure 8

Three conceptual layers of an information systems architecture illustrate the separation that occurs among the data, business logic and presentation layers. Over time, changes in the presentation and business logic layers may be made while retaining the data layer. As noted in the figure, the three layers can typically be found even within a single application (e.g., a laboratory or radiology system)

The first layer of architecture is the data layer. Data—the results of transactions that the HCO generates—are of central importance. One fundamental mistake that a health care organization can make is to fail to provide access to its data. Organizations that choose information systems based on the functionality available to meet short-term needs may find that these needs are no longer as important as the HCO or IDN continues to evolve. For this reason, a long-term data strategy needs to be a separate component of the information-management plan. This plan must include access to data for applications and a method to ensure that demographic, clinical, and financial data collected across business units are consistent and comparable. Security and confidentiality safeguards (see Sect. 14.1.4) should also be part of the data strategy.

With respect to clinical data, HCOs and IDNs need data for both real-time operations and retrospective data analysis. These needs generate different requirements for data management. In the first case, detailed data need to be stored and optimized for retrieval for the individual patient. In the second case, the data need to be optimized for aggregation across a population of patients. Although the terms are sometimes used interchangeably, the distinction should be made between a clinical data repository (CDR), which typically stores “transaction” data and serves the needs of patient care and day-to-day operations, and an enterprise information warehouse (EIW) which serves as the foundation for analytic tasks for both retrospective and longer term business and clinical planning such as contract management and outcomes evaluation. Both the CDR and data warehouse should be purchased or developed for their ability to model, store, and retrieve efficiently the organization’s data. Quite often, vendors of a CDR or warehouse include programs to view and manipulate these data. Conceptually, this packaging makes sense.

The second component of a clinical data strategy is an ability to keep patient information comparable. At the simplest level one needs to uniquely identify each patient. When a health organization consisted of only one hospital and one major information system, the authority over patient identification was relatively simple and usually resided in the HCIS’s admitting or registration module (see Sect. 14.2.1). As HCOs evolve into IDNs, there is no one authority that can identify the patient or resolve a conflicting identification. Thus, as we noted earlier, a new architectural component, the enterprise master patient index (EMPI), has arisen as the name authority. In its simplest form, the EMPI is an index of patient names and identification numbers used by all information systems in the IDN that store a patient registry. Using this type of EMPI requires considerable manual intervention to ensure data synchrony, but it does enable an IDN to uniquely identify its patients and link their data. Alternatively, an EMPI can be configured as the name authority for all systems that hold patient information even within a single HCO. Then each system must interact with the EMPI in order to get a patient-identification number assigned. This type of EMPI requires that all other systems disable their ability to assign identification numbers and use the external—and unique—EMPI-generated identification numbers.

Uniquely identifying patients within the HCO and the IDN is just a necessary first step in ensuring data comparability and consistency. Health care providers also may want to know which of their patients are allergic to penicillin, which patients should be targeted for new cardiac-disease prevention services, or which patients are likely to need home services when they are discharged from the hospital or emergency room. To store and evaluate the data that could be used to make such determinations, a consistent approach must be developed for naming data elements and defining their values (see Chaps. 7 and 8). Some institutions, such as Columbia University Medical Center (CUMC) in New York City, have developed their own internal vocabulary standards, or terminology authority. CPMC separates the storage and retrieval of data from the meaning of the terms in the database using a medical entities dictionary that defines valid database terms and synonyms for use by its clinical applications. An alternative approach is to develop a set of terminology services. These services fall into three categories: (1) linking or normalizing the data contained within the HCO’s or IDN’s legacy databases before these data are copied to a CDR; (2) reregistering all terms used by new applications and linking them to external authoritative vocabulary terms, such as those contained within the Unified Medical Language System’s Metathesaurus (see Chap. 8); and (3) providing real-time help in selecting the appropriate term to describe a clinical situation.

The second layer of architecture is the business logic layer. As we discussed in Sect. 14.1.6, once a system has been installed, its users will usually resist change. The reason for this inertia is not just that there is a steep learning curve for a new system but also that historical systems embody institutional workflow. Separating the workflow or business logic from the database will enable more natural migrations of systems as the HCO or IDN evolves. Organizations should not, however, assume that old workflow is correct or should necessarily be embodied in new information systems. The point here is that a modern architecture that separates the workflow from the data allows prior data to be carried forward as the systems migrate. This also enables organizations to change workflow as new features and functions become available in newer products or product releases.

The third layer, the user-interface layer, is how users “see” the data, and most often the layer most subject to frequent change. The cost of desktop devices and support represents a significant portion of HCO and IDN information systems budgets—often as much as one-third of the total budget. For example, an IDN that supports 10,000 workstations will incur ongoing costs for hardware and software alone of close to $10 million per year, assuming a $3,000 unit cost and a 3-year life span per workstation. Thin clients, and web-based technologies, which minimize processing at the workstation level, can substantially reduce this cost by allowing simpler maintenance and support as well as decreased cost per device.

Future network and computer systems architectures such as Services Oriented Architecture (SOA) will likely increasingly rely on the tools and technological developments driven by the ubiquity of the Internet. Smart phones, tablets, pagers and other mobile devices continue to shrink in size while increasing in functionality. However, often due to size limitations (and specifically the form factor limits of keyboards and display screens available on smaller devices), these systems are currently better suited for one-way retrieval and presentation of information and do not adequately support clinicians’ requirements for data input where free text entry continues to be used. But even with shrinking size, these devices are still suitable for accessing electronic schedule and contact lists and have (modified) handwriting recognition capabilities, and support other productivity tools which have become popular. Voice-entry devices have found some utility where noncontinuous speech is supported by good screen design (see Chap. 5). The introduction of computer tablets with handwriting recognition show promise for use in specialized clinical applications. Most likely, clinicians will require a variety of devices—some that are application specific and some that vary with personal preference. The important design consideration is that, if possible, the design of the display and the nature of the input devices should not be so tied to the application that change and modification are difficult.

5 Forces That Will Shape the Future of Health Care Information Systems

As we have discussed throughout this chapter, the changing landscape of the health-care industry and the strategic and operational requirements of HCOs and IDNs have accelerated the acquisition and implementation of HCISs. The acquisition and implementation of Electronic Medical Records (EMRs) have been a particular focus, especially with the availability of federal stimulus funding through the provisions of the Health Information Technology for Economic and Clinical Health (HITECH) Act under the American Recovery and Reinvestment Act of 2009 (ARRA). Although there are many obstacles to implementation and acceptance of smoothly functioning, fully integrated HCISs, few people today would debate the critical role that information technology plays in an HCO’s success or in an IDN’s efforts at clinical and operational management.

We have emphasized the dynamic nature of today’s health care environment and the associated implications for HCISs. A host of new requirements loom that will challenge today’s available solutions. We anticipate additional expectations and requirements associated with the changing organizational landscape, technological advances, and broader societal changes.

5.1 Changing Organizational Landscape

Although the concepts underlying HCOs and IDNs are no longer new, the underlying organizational forms and business strategies of these complex organizations continue to evolve. The success of individual HCOs varies widely. Some, serving target patient populations such as those with heart disease or cancer or age-defined groups such as children, have been relatively more successful financially that those attempting to serve patients across a wide range of illnesses or those attempting to combine diverse missions of clinical care, teaching and research. IDNs, on the other hand, have by and large failed to achieve the operational improvements and cost reductions they were designed to deliver. It is possible that entirely new forms of HCOs and IDNs will emerge in the coming years. Key to understanding the magnitude of the information systems challenge for IDNs in particular is recognizing the extraordinary pace of change—IDNs reorganize, merge, uncouple, acquire, sell off, and strategically align services and organizational units in a matter of weeks. While information technology is itself changing with accelerating frequency, today’s state-of-the-art systems (computer systems and people processes) typically require months or years to build and refine.

All too frequently, business deals are cut with insufficient regard to the cost and time required to create the supporting information infrastructure. For IDNs even in the best of circumstances, the cultural and organizational challenges of linking diverse users and care-delivery settings will tax their ability to change their information systems environments quickly enough. These issues will increase in acuity as operational budgets continue to shrink—today’s HCOs and IDNs are spending significant portions of their capital budgets on information-systems investments. In turn, these new investments translate into increased annual operating costs (costs of regular system upgrades, maintenance, user support, and staffing). Still most health care organizations devote at most 3–4 % of their total revenues to their information systems operating budgets; in other information-intensive industries (e.g., financial services, air transportation), the percentage of operating budgets devoted to information technology investment can be three to four times higher.

5.2 Technological Changes Affecting Health Care Organizations

Future changes in technology are hard to predict. For example, although we have heard for over two decades that voice-to-text systems are 5 years away from practical use, with the introduction of controlled vocabularies in areas such as radiology and pathology, we are beginning to see commercial products that can “understand” dictated speech and represent it as text that can then be structured for further analysis. First, the emergence of increasingly powerful processor and memory chips, and the decreasing cost of storage media will continue to be a factor in future health-systems design—although the tsunami of data coming from genomic medicine sequencing and analysis may be a significant challenge (see Chaps. 2, 25, and 26). Second, the ever expanding availability of Internet access, the increasing integration of voice, video, and data, and the availability of ever smaller platforms like tablets and smart phones, will challenge HCOs and IDNs to have communications capacity not only within their traditional domain but also to an extended enterprise that may include patients’ homes, schools, and workplaces. Third, the design of modern software based on the replicability of code, code standards such as XML, and frameworks such as Services Oriented Architecture (SOA) should eventually yield more flexible information technology systems.

One of the most significant technological challenges facing HCOs and IDNs today occurs because, while much of the health care delivered today is within the four walls of a physician’s office or a hospital, as the population ages, patients may seek care from both primary and specialty practices, may have multiple hospital visits (and even visits to multiple hospitals) and may increasingly be monitored in their homes. Health care information technologies (and clinical systems in particular) have focused historically on what happens within a physician’s office or within a hospital, and not across physicians’ office nor between the physicians’ office and the hospital nor in the home of the patient.

In general, EHR products on the market today started with a single purpose: to automate the workflow of clinicians within a particular organizational setting. Among other features, EHRs focus on making data from previous encounters or activities easier to access, and assuring that orders for tests and x-rays have the correct information, or that the next shift knows what went on previously. In spite of visible successes and failures for all manner of products, EHRs in general can facilitate the automation of a complex workflow—of automating intra-organizational clinical processes.

Architectures that focus on what happens within organizational boundaries do not easily facilitate access to data across organizational boundaries. This is the challenge of interoperability. Recognizing that patients often receive care in a variety of organizational settings—hospitals, physicians offices, rehabilitation facilities, pharmacies, etc.—the challenge is to extend the internal workflow beyond the boundaries of individual organizations so that data is available across a continuum of care. Interoperability then is not so much about what happens within an organization (although there can be challenges here as well), but what happens across organizational boundaries.

The architectural requirements for automating intra-organizational clinical workflows are very different from the architectural requirements for facilitating inter-organizational interoperability. An intra-organizational architecture focuses on facilitating real time communications among providers, on optimizing the process of collecting data at the point of care, and on ensuring that clinical tasks are carried out in an appropriate sequence. An inter-organizational architecture needs to be designed to minimize the duplicate collection of data in different care settings, to facilitate quick searches of relevant data from a variety of (often external) sources, and to rank data in terms of relevance to a particular clinical question. Transitioning from intra- to inter-organizational data sharing is a significant technological challenge. While Health Information Exchanges (HIEs) and Health Record Banks (HRBs) are at the forefront of this transition (see Chap. 13), over time we can expect that the architectures of clinical systems that currently focus on what happens within an organization will need to transition to facilitate what happens across organizations.

Security and confidentiality concerns will likely increase as the emergence of a networked society profoundly changes our thinking about the nature of health care delivery. Health services are still primarily delivered locally—we seldom leave our local communities to receive health care except under the most dire circumstances. In the future, providers and even patients will have access to health care experts that are dispersed over state, national, and even international boundaries. Distributed health care capabilities will need to support the implementation of collaborative models that could include virtual house calls and routine remote monitoring via telemedicine linkages (see Chap. 18).

5.3 Societal Change

At the beginning of the twenty-first century, clinicians find themselves spending less time with each patient and more time with administrative and regulatory concerns. This decrease in clinician–patient contact has contributed to declining patient and provider satisfaction with care-delivery systems. At the same time, empowered health consumers interested in self-help and unconventional approaches have access to more health information than ever before. These factors are changing the interplay among physicians, care teams, patients, and external (regulatory and financial) forces. The changing model of care, coupled with changing economic incentives to deliver high quality care at lower cost, places a greater focus on wellness and preventative and lifelong care. Although we might agree that aligning economic incentives with wellness is a good thing, this alignment also implies a shift in responsibility from care givers to patients.

Like the health care environment, the technological context of our lives is also changing. The Internet has already dramatically changed our approaches to information access and system design. Concurrent with the development of new standards of information display and exchange is a push led by the entertainment industry (and others) to deliver broadband multimedia into our homes. Such connectivity has the potential to change care models more than any other factor we can imagine by bringing fast, interactive, and multimedia capabilities to the household level. Finally, vast amounts of information can now be stored efficiently on movable media such as memory sticks, which brings more flexibility as well as more risk, as such devices are both more convenient and more susceptible to being lost or misplaced. With the increase in the availability of consumer-oriented health information, including, for example, video segments that show the appearance and sounds of normal and abnormal conditions or demonstrate common procedures for home care and health maintenance, we can expect even more changes in the traditional doctor/patient relationship.

With societal factors pushing our HCOs and IDNs to change, cost constraints looming larger, and the likely availability of extensive computing and communication capacity in the home, in the work place, and in the schools, HCOs and health providers are increasingly challenged to rethink the basic operating assumptions about how to deliver care. The traditional approach has been facility and physician centric—patients usually come to the hospital or to the physician’s office at a time convenient for the hospital or the physician. The HCO and IDN of the twenty-first century may have to be truly “patient centric”, operating within a health care delivery system without walls, where routine health management is conducted in nontraditional settings, such as homes and workplaces, using the power of telemedicine and consumer informatics.

Questions for Discussion

  1. 1.

    Briefly explain the differences among an HCO’s operational, planning, communications, and documentary requirements for information. Give two examples in each category. Choose one of these categories, and discuss similarities and differences in the environments of an integrated delivery network, a community-based ambulatory-care clinic, and a specialty-care physician’s office. Describe the implied differences in these units’ information requirements.

  2. 2.

    Describe three situations in which the separation of clinical and administrative information could lead to inadequate patient care, loss of revenue, or inappropriate administrative decisions. Identify and discuss the challenges and limitations of two methods for improving data integration.

  3. 3.

    Describe three situations in which lack of integration of information systems with clinicians’ workflow can lead to inadequate patient care, reduced physician productivity, or poor patient satisfaction with an HCO’s services. Identify and discuss the challenges and limitations of two methods for improving process integration.

  4. 4.

    Describe the trade-off between functionality and integration. Discuss three strategies currently used by HCOs to minimize this tradeoff.

  5. 5.

    Assume that you are the chief information officer of multi-facility HCO. You have just been charged with planning a new clinical HCIS to support a large tertiary care medical center, two smaller community hospitals, a nursing home, and a 40-physician group practice. Each organization currently operates its own set of integrated and standalone technologies and applications. What technical and organizational factors must you consider? What are the three largest challenges you will face over the next 24 months?

  6. 6.

    How do you think the implementation of clinical HCISs will affect the quality of relationships between patients and providers? Discuss at least three potential positive and three potential negative effects. What steps would you take to maximize the positive value of these systems?

5.3 Suggested Readings

Christensen, C., Grossman, J., & Hwang, J. (2009). The innovator’s prescription. New York: McGraw-Hill. This book builds on the author’s previous work on disruptive innovation with specific applications to the health care industry. Christensen uses terms such as “precision medicine” to describe the advent of more personalized approaches to medical diagnosis and treatment, and builds on his analysis of disruptive business models in other industries to analyze both the underlying problems and challenges of our health care delivery system.

Lee, T., & Mongan, J. (2009). Chaos and organization in health care. Cambridge, MA: The MIT Press. The authors describe the current health care situation as one simply of “chaos”. Among the solutions they propose are increasing the use of electronic medical records and information technology in general for sharing knowledge.

Ong, K. (2011). Medical informatics: an executive primer (2nd ed.). Chicago: Health care and Management Information Systems Society. An excellent overview of the challenges facing information technology applications in hospitals, physicians’ offices, and in the homes of patients. Also includes a discussion of recent federal legislation intended to stimulate the use of electronic medical records and the challenges of measuring how to determine whether such investments are in fact “meaningfully used”.

Porter, M., & Teisberg, E. (2006). Redefining health care: creating value-based competition on results. Cambridge, MA: Harvard Business School Press. The authors begin with a very straightforward assumption, which is that “the way to transform health care is to realign competition with value for patients” (p. 4), and proceed with an exhaustive discussion of the historical failures at reforming the health care system, the challenges inherent in physician-provider organization relationships, and how the only likely solution set to the current high cost of health care is to focus our efforts on what brings value to the patients.