Architectural Strategies and Issues with Health Information Exchange

Abstract

We describe architectural strategies and issues regarding health information exchange (HIE). This description is organized as a continuum of options, between separated systems and a monolithic approach. We discuss characteristics, examples and potential impacts of each approach, based on generalized observations of practical implementations. We also describe how strategies can migrate along the continuum, which allows for approaches that mature from an initial implementation to a long-term strategy.

BACKGROUND

The current health care delivery system in the United States is notable for its fragmentation of care across providers and care settings. Many factors contribute to this fragmentation. For example, American clinicians are increasingly limiting the scope of their practice to specialized areas of care and to single settings.¹ Fragmentation is only expected to increase as the mean patient age and complexity increases. For example, 83% of Medicare beneficiaries have at least one chronic disease, and see on average 8 physicians per year.^2–4 Current payment structures also contribute to fragmentation; one study documented that 24% of patients were forced to change physicians because of insurance changes.

Fragmentation poses a significant risk to health care quality.⁵ Effective care requires that appropriate patient information is communicated to clinicians as patients move between providers and sites. Unfortunately, such communication frequently does not occur,^{6, 7} and inadequate transfer of information at care transition points often leads to failures in patient safety, such as adverse events or near misses,^{8, 9} increased use of medical resources, and patient confusion and dissatisfaction.² Improved communication at these transitions of care is therefore critical to improved quality of health care and patient safety,^{8, 10–12} and various health care quality organizations have made strong recommendations regarding such improvements.^9–13

The increased awareness of quality and safety issues at transitions of care has given rise to increasing focus on structures to facilitate exchange of health information across institutions, especially clinical information systems. These range from local efforts to share electronic clinical information between physician practices,¹⁴ to an Executive Order from President George W. Bush for the creation of a nationwide interoperable health information technology infrastructure.¹⁵ Organizations have been created to not only increase awareness of the benefits of health information exchange (HIE), but to provide resources for individuals wishing to participate in HIE.^16–19 Standards and vendor offerings have also emerged to facilitate the technical challenges of HIE.^{20, 21}

However, organizations wishing to improve information exchange still have questions about how best to implement HIE. Much of the current technical discussions regarding HIE have focused on the initial barriers, such as patient matching and legal data sharing agreements. While these issues are critical to HIE, they do not represent the core architectural and strategic issues of HIE. Discussions of architecture or strategy usually identify only two approaches,²² federated or centralized, but variations among these approaches have not been addressed. This becomes a challenge for institutions attempting to design long-term solutions for HIE, where architectural strategy issues will likely outlast technological solutions.²³ In this paper, we address architectural and strategic issues for HIE. We describe architectural approaches to HIE, discuss the data exchange issues with the different architectural approaches, give examples of information exchange approaches pursuing that approach, and describe potential impacts of each option on clinician usage, quality of care, and health care costs.

METHODS

We describe various architectural strategies for HIE using a continuum model. This continuum model was developed using multiple sources of information, including:

• Experience of the authors in information system architecture, design, development, and implementation, and with health information exchange;

• Review of informatics research literature, trade publications, electronic presentations, and institutional and commercial websites regarding regional health information organizations (RHIOs) and information system architecture;

• Review of medical literature regarding quality of care;

• Review of publications on cost benefit of HIE and electronic health records (EHRs); and

• Data from existing systems, where available.

Much of the data from existing systems comes from the authors’ experience at Intermountain Healthcare. Intermountain is a health care delivery system consisting of 21 hospitals (2200 beds), more than 90 outpatient clinics, an employed physician group, and an insurance plan for patients located in Utah and southeastern Idaho. Intermountain provides more than 50 percent of all care delivered in the region it serves. Among more than 2,500 affiliated physicians, a core subset of 1,200 physicians accounts for more than 94% of all care delivery within Intermountain. Intermountain has extensive existing clinical information systems, and a history of using those information systems to improve patient care.^23–26 The hospitals currently use the HELP system, and data from this system is interfaced to a longitudinal patient record and stored in the Clinical Data Repository (CDR). In the ambulatory setting, providers enter visit notes, problems, and medications into the CDR. Desktop applications allow users in either inpatient or ambulatory settings to view laboratory results, text reports, and radiology images, regardless of where the care was provided. This information system also contains advanced decision support capabilities for alerting,²⁷ and privacy safeguards for protecting the electronic medical record. This system, which combines the data from acute hospital encounters within the longitudinal clinical data repository, allows an authorized provider to see a comprehensive picture of patient health information. Intermountain has also begun some initiatives to exchange information among non-owned facilities and providers.^{28, 29} As a result of its multiple and diverse facilities, strong regional presence and extensive information systems, Intermountain has many internal examples of health information exchange. We therefore felt it could illuminate architectural and strategic issues of HIE beyond patient identification and data sharing agreements.

RESULTS

We modeled the different architectural strategies of HIE as a continuum model, ranging between non-integraged, separated systems and fully-integrated monolithic systems (see Figure 1). The continuum was focused on functional integration, rather than data integration, with integration increasing to the left along the continuum.

Figure 1.

Continuum of architectural options for health information exchange. This continuum was designed around functional integration approaches currently existing, either among HIE initiatives or integrated health care delivery organizations.

Separated systems

Separated systems represent the pre-HIE health care environment, where information is communicated across providers and sites via telephone or fax. Such communication is dependent on synchronous participation, or a response by the sending party to a recipient’s request. While this is the most common approach to health information exchange between clinicians, it does not occur regularly in individual patient care. Recent studies have shown that primary care physicians spend only 3-4 minutes a day, among 20–29 patients.^{30, 31} Overhage et al. reported a survey where emergency physicians attempted to obtain information from external institutions via fax or telephone for 5% of patients, spending 15.2 minutes per attempt. Most health information is actually exchanged through the patient, who carries the burden of communicating between providers. But patients are often ill-prepared for this role.³² By improving the patient’s ability to communicate across transitions of care, quality and costs can be improved, as Coleman et al. demonstrated,³³ but such approaches require focused initiatives. A more-technical approach is to use patient-carried data, in electronic format that can be accessed by providers (discussed below).

Separated federated model

Organizations can move from a separated model to a separated federated model by giving clinicians outside a health care institution access to that institution’s electronic medical record. The main barriers in this model are legal, in addressing consequences of inappropriate access by these external users. The technical burden of information exchange is with the clinician user, who must authenticate into the system, and select the appropriate patient. The institution must only provide a method to access the system. Providing access has become more simplified when it is web-based, or requires no additional software installation.^{29, 34}

The benefit of a separated federated model is that it doesn’t require synchronous communication between providers, and is thus more likely to take place. But its actual use is still low. Overhage et al. reported the results of a study where users were given access to a separate institution’s EMR using a separated federated model, combined with a centralized data model. The usage of the separated federated system was low – less than 0.5%, but it was likely influenced by easier, though less-complete, access to centralized data. Physicians specifically identified difficulty remembering passwords, and the time required to search for information as barriers to access. Preliminary data from the LDS Hospital emergency department (ED) at Intermountain Healthcare showed that clinicians will access data in a model requiring authentication and patient selection for about 10% of patients.

However, there can still be demand and benefits of a separated federated model. Access to outpatient data in this model at Intermountain Healthcare has been widespread in inpatient hospitals and affiliated outpatient clinics; in fact, more users access Intermountain’s HELP-2 system, which is still primarily an outpatient EMR for employed physicians, from affiliated clinics or inpatient facilities than Intermountain-owned clinics. This access has also affected some ordering patterns among affiliated physicians.²⁹ The Center for Information Technology Leadership, in their report on Health Information Exchange and Interoperability (HIEI), estimated the annual savings for HIEI based on the level of data exchanged.¹⁹ The separated federated model would achieve only the benefits of machine-transportable data, but with significant limitations due to lower access of data at the point of care within this model.

Separated federated model with notification

This model adds notification functionality from the previous model. Examples include standard peer-to-peer information exchanges. Other examples include physician-patient communication systems, where one party receives notification of the presence of data in a less-secure but more accessible platform (e.g., standard email), but must access and authenticate within a more secure system to obtain the data. The notification allows providers to be alerted to the presence of data on separated systems, to avoid searching fruitless and labor-intensive searches for information. To accomplish this notification, the implementation must centralize and automate some level of patient identification across systems. Users still carry the burden of authentication, and patient selection in the separate systems. The notification model also requires each user have access to a notification review module, which are often paired with provider-to-provider messaging systems.

By removing one of the most significant barriers to usage in a simple federated model, the notification component increases usage. Within the ED at LDS Hospital, physician access of longitudinal patient information, even when authentication and patient selection were required, reached 20% of patients. The messaging application, part of the notification system at Intermountain, became one of the most used components of the EHR shortly after its introduction.^{23, 28} Analysis of message destinations indicated that the majority (~60%) of provider-to-provider messages were to physicians outside the sending clinic or hospital. Notifications and messages are generally unstructured, with more structured content being available only by accessing the separate system. Therefore, the cost benefits of this model from CITL projections at best reach the level of machine-transportable data; though they are higher than the benefits of the simple separated federated model.

Context-aware federated model

The context-aware model addresses the logon and patient selection tasks of the previous model, which can be barriers to use. Beyond the technical requirements of the previous model, it requires some level of centralized control or coordination of users, and robust patient matching between systems, which is a significant barrier in HIE initiatives. It also requires the use of applications that can appropriately handle clinical context messaging. This model maintains the context of clinician user and patient across different systems. Examples include the current Santa Barbara County Health Data Exchange.³⁵ These systems allow providers to move between separate applications or medical record systems without having to re-authenticate or select patients. Implementations typically use the HL7 CCOW standard.³⁶ Information must still be accessed according to its location, but movement between locations is eased significantly.

Like other federated models, the context-aware model shares only machine-transportable data. However, it reduces all the major barriers to information access. In the LDS Hospital ED at Intermountain, we accomplished context-aware exchange (with notification) by reducing the user sign-on and patient selection to a single click process with proximity card authentication from a notification screen. The result was a rise in patient EHR access from 20% to 45%.

Patient-carried data, such as “smart cards”,³⁷ functionally fit within the context-aware federated model, because they don’t require additional patient selection and user authentication processes. However, effective smart card implementation requires patients to manually transport data, which is likely less robust than other technical solutions.

Centralized data

The centralized data model extends previous models by centralizing actual patient data. While this extension can be relatively simple technically, if only text data are being shared, it typically involves sharing of both structured and unstructured data. With a centralized data-sharing model, organizations must transmit data to a centralized source, where data can be combined in structured form. This can be accomplished virtually, by having data shared directly between systems, though such an approach requires each system to both send and receive data correctly. They also require a centralized vocabulary if structured data are to be organized across sources. The IHE XDS is an emerging standard supporting this type of data sharing.²⁰ The Indiana Health Information Exchange is the prototypical example of this approach, where data from multiple systems are sent to a single service that organizes and aggregates data. Other examples include clinical information systems that follow a service-oriented architecture (SOA), such as the Intermountain CDR.²³

From the user experience, centralization eases data access. Over 90% of the employed physicians at Intermountain voluntarily use the centralized EHR to access data.²⁸ Centralization also allows proactive decision support on data from multiple institutions, and the decision support systems can be more accurate. For example, at Intermountain, the Antibiotic Assistant application³⁸ was being migrated from the single-institution HELP system to the centralized HELP-2 system. During the migration, developers were able to identify instances where patients had transferred between hospitals within a single treatment period, where the centralized application was able to give more-correct recommendations. Depending on how structured data are within systems, to allow decision support, centralized models exchange either machine-organizable or interpretable data, and thus can attain the most advanced level of HIE. The estimated annual cost benefit is thus between $24-78B nationally. These systems also allow the greatest improvement to quality of care, depending on the level of decision support implemented.

Monolithic system

Monolithic data exchange systems currently only exist within large integrated delivery organizations, that also use a monolithic EMR. This approach requires that all participants in the HIE use the same EMR, which is usually only possible where organizational control is centralized. Migrating to monolithic systems is thus the most disruptive change on the continuum. Within monolithic systems, exchange can be direct at the data level, provided the configuration of the system is standardized across locations. Where data are structured, it is usually machine-interpretable across systems. Eventually, the barriers to machine-interpretable data become more an issue of user data entry preference. That is, users must enter data in structured form for it to be shared as structured data.

Actual usage of information by users within monolithic systems is at least as high as centralized models. Use can actually be higher, if use is mandated. The benefits are also similar to centralized data systems, though they are potentially higher. However, the real benefits seen in monolithic systems may be more due to the ability to standardize care processes across a network, than from the exchange of information in the EMR.³⁹ The Veterans Administration is a notable institution that uses a monolithic approach to information exchange.

CONCLUSION

This description uses a continuum of options, between separated systems and a monolithic approach. In reality, few institutions are able to initially implement what would be a long-term strategy. By presenting options as a continuum, we allow institutions to adopt an initial approach tailored to their existing constraints, that can mature to a long-term strategy. While the description does not contain all the issues of HIE, it does address many of the important architectural considerations related to long term strategies and HIE expectations.