Learning from health information exchange technical architecture and implementation in seven beacon communities.

As health care providers adopt and make "meaningful use" of health information technology (health IT), communities and delivery systems must set up the infrastructure to facilitate health information exchange (HIE) between providers and numerous other stakeholders who have a role in supporting health and care. By facilitating better communication and coordination between providers, HIE has the potential to improve clinical decision-making and continuity of care, while reducing unnecessary use of services. When implemented as part of a broader strategy for health care delivery system and payment reform, HIE capability also can enable the use of analytic tools needed for population health management, patient engagement in care, and continuous learning and improvement. The diverse experiences of seven communities that participated in the three-year federal Beacon Community Program offer practical insight into factors influencing the technical architecture of exchange infrastructure and its role in supporting improved care, reduced cost, and a healthier population. The case studies also document challenges faced by the communities, such as significant time and resources required to harmonize variations in the interpretation of data standards. Findings indicate that their progress developing community-based HIE strategies, while driven by local needs and objectives, is also influenced by broader legal, policy, and market conditions.

Introduction

The federal government is offering financial incentives and technical assistance to help health care providers adopt and make meaningful use of electronic health records (EHRs) to improve patient care, reduce the cost of care, and promote a healthier population.1 Attaining this triple aim requires an infrastructure for health information exchange (HIE)—the secure, electronic movement of health-related information in a standard format between disparate sources and users.2

A well-designed HIE infrastructure furthers the aims of health care delivery and payment reform and fosters a learning health care system.3 For example, the systematic collection, aggregation, and analysis of electronic health information can be used to identify and engage patients at risk of poor health outcomes, to measure provider and communitywide performance, and to evaluate the effects of interventions to drive measurable improvements in care.4

In pursuit of these objectives, communities around the nation have exercised leadership in bringing together local stakeholders who can develop collaborative arrangements and technical infrastructure for HIE.5 This case study analysis examines the experiences of seven communities that built or extended HIE capabilities through their participation in the Beacon Community Cooperative Agreement Program.6 Although HIE was not the sole focus of the Beacon Program, it was and remains a crucial element of these communities’ objectives for data-driven improvements in care.7

The purpose of this article is to help community decision makers and policymakers understand how technical choices influence the capacity of resulting HIE infrastructures to help achieve stated community aims. We provide practical insight into a subset of decisions faced by study communities regarding the selection of HIE technical architecture that determines how data are shared, the factors influencing their choices, and the implications of these decisions for promoting and evaluating health care delivery system transformation.8 The article also documents challenges faced by the communities, such as significant time and resources required to harmonize variations in the interpretation of data standards. (Please note that technical terms are defined in a glossary at the end of this article.)

The communities selected for the study (Table 1) began with a range of health objectives and prior health IT experiences; each has progressed on a unique trajectory in developing its HIE capability. Together, their experiences illustrate a diversity of technical approaches and accomplishments that build on prior literature9 and, when synthesized, yield insights regarding key considerations, challenges, and promising practices in community HIE development.

Table 1.

Overview of the Case Study Sites

Community	Bangor	Central Indiana	Greater Cincinnati	Inland Northwest	Keystone	Greater Tulsa	Western New York
HIE Name	HealthInfoNet	Indiana HIE (Indiana Network for Patient Care)	HealthBridge	INHS Health Information Network	Keystone HIE	MyHealth Access Network	HEALTHeLINK
Formed*	2004 / 2006	1995 / 2004	1997	1994	2005	2009	2001 / 2006
Service Area	State of Maine	Statewide and inter-state	16-county area of Ohio, Indiana, and Kentucky	14-county area of eastern Washington and western Idaho	31 counties in Central/Northeastern Pennsylvania	11 counties in Northeastern Oklahoma	8-county region surrounding Buffalo
HIE population**	1.2 million patients	2.7 million patients	>3 million patients	1.3 million patients	600,000 patients	>2 million patients	1.5 million patients
Key Stakeholders	4 health systems, payer, public health	Providers, public health, business groups	5 health systems and 2 health plans	Members of Inland Northwest Health Services, an independent entity	Geisinger Health System and 36 community provider organizations	Providers, payers, purchasers, public health, tribes, university, patients	Providers, payers, public health, educational and community partners
HIE Users (at time of study)	28 (of 39) Maine hospitals, 7,000 providers, 5 FQHCs	90 hospitals and 19,000 physicians	7,500 physicians and over 50 total hospitals	16 hospitals, 16 clinics, specialists, LTPAC providers	1,110 clinicians, 274 LTPAC users, 1,200 patients	1,600 providers	2,550 providers and 7,567 total users
Technical Architecture	Centralized	Hybrid-Federated	Hybrid-Federated	Centralized	Hybrid-Federated	Centralized	Hybrid-Federated
Patient Consent	Opt-out (opt-in for mental health)	Opt-out	Opt-out	Opt-out	Opt-in at each care site for full record	Opt-out	Opt-in
Selected Examples of Advanced Health IT Tools & Services(see Appendix for details)	Community wide disease registryQuality reporting and provider comparisonQuality reporting and provider comparisonPatient text messaging (pilot)Public health surveillance	Public health surveillanceHealth screening remindersDisease registryQuality reporting and provider comparison	Community-wide disease registryPredictive risk modelingProvider reporting dashboard;Patient text messaging (pilot)	Risk-based algorithm to refer diabetes patientsQuality reports (sent to providers quarterly)Clinical decision support	KeyHIE Transform translates LTPAC patient assessment data to CCD formatElectronic flu shot reminderPerformance reporting	e-Referral managementPredictive risk modelingClinical decision supportAnalytics & reportingCloud-based apps	EHR-based registriesClinical decision supportQuality and outcomes reportingTelemonitoringPublic health surveillance

Source: Authors’ analysis. FQHC = federally qualified health center; HIE = health information exchange; IT = information technology; LTPAC = long-term and postacute care.

Notes:

Date Formed: Where two dates are indicated, the first marks when foundational elements of an HIE began, and the second marks the official formation of the HIE organization.

HIE Population: The number of patients whose clinical data had been electronically exchanged and/or stored in some form through the HIE infrastructure at the time of the study.

Methods

We selected study sites that had made substantial investments in HIE infrastructure, and where that HIE infrastructure was instrumental to implementing their specific Beacon initiatives. These sites represented a range of Beacon program objectives (Table 2), varied technical architectures (Figure 1), and diverse Beacon Community contexts (Table 3). (The characteristics of the Beacon Communities have been previously described elsewhere.10) Background information on HIE technical architecture and on study sites was synthesized from documentary sources (e.g., Beacon Community websites and annual reports, peer-review articles, and grey literature). Semistructured telephone interviews were conducted with key informants representing six of the seven sites (the Central Indiana site provided written responses only). Informants included operational and technical leaders in HIE organizations, clinical leaders in provider organizations, and researchers engaged in evaluating Beacon Community program interventions. All interviews were recorded and transcribed.

Table 2.

Beacon Case Study Site Objectives

Beacon Community	Clinical Focus Area(s)	Beacon Community Objectives
Bangor	DiabetesCongestive heart failureCardiovascular disease Chronic obstructive pulmonary diseaseAdult asthma	Fill information gaps & strengthen care connections to: Reduce health care utilizations: Hospital admissions, ED visits, 30-day hospital readmissions Improve care management/care coordination during transition of care for chronic conditions Improve population health via immunization
Central Indiana	DiabetesCancer screening	Expansion of services and service area to: Increase diabetes control Reduce hospitalizations and ED visits Reduce redundant imaging Increase cancer screening
Greater Cincinnati	DiabetesPediatric asthma	Help physicians deliver optimal care for 32,000 pediatric asthma and adult diabetes patients. Reduce preventable ED visits & rehospitalizations. Promote safe and effective care transitions.
Inland Northwest	Diabetes	Implement a robust HIE framework independent of hospital system to: Reduce emergent and inpatient care for diabetes and its complications; Increase receipt of diabetes preventive health services; Improve access to diabetes preventive information by public health agencies; Increase meaningful use of health IT for all medical conditions.
Keystone	Chronic obstructive pulmonary diseaseCongestive heart failure	Integrated managed care for COPD and Heart Failure Reduce 30-day hospital readmissions Better outcomes for lower cost Engage and educate patients in their care Provide advanced data analytics from a community data warehouse Provide ER rapid access to new patients
Greater Tulsa	Cancer screeningImmunizations	Implement communitywide care transition management Implement communitywide decision support Increase cancer screening Increase immunizations Decrease time required for patients to receive an initial touch from specialists Reduce unnecessary care transitions and their associated costs
Western New York	DiabetesHealth disparities	Improve clinical outcomes & patient safety through health IT and HIE, focusing on diabetes. Use EHRs to achieve meaningful use and optimize diabetes control Reduce hospital use among diabetics through preventive measures Implement clinical decision support in relevant physician practices for monitoring and reducing disparities.

Sources: Office of the National Coordinator for Health Information Technology and case study sites.

Note: CHF = chronic heart failure; COPD = chronic obstructive pulmonary disease; EHR = electronic health record; ED = hospital emergency department; HIE = health information exchange; IT = information technology.

Figure 1.

Continuum of HIE Architecture Models

Table 3.

Summary of Findings: Community Contextual Factors

Model	Hybrid-Federated Form 1	Hybrid-Federated Form 2	Centralized
Description	HIE participants maintain separate control of their data & share it via the HIE infrastructure upon request	Hybrid-federated model combined with—or designed to achieve the functionality of—a normalized central data repository	Data shared by HIE participants are normalized, housed in and accessed from a central data repository
Communities	Western New York*	Central Indiana, Greater Cincinnati, Keystone	Bangor, Inland Northwest, Greater Tulsa
Contextual Factors Influencing HIE Technical Architecture Decisions
Trust and Cooperation	Balance cooperation & autonomy: participants share data on request but maintain control over sources	Facilitate access to distributed data while building trust & readiness for comprehensive data sharing	Cooperative norms (“trust fabric”) promote community custodianship of comprehensive shared clinical data
Health IT Context & Approach	Accommodate disparate EHR systems & varied stakeholder objectives for health IT	Provide a flexible approach at the cost of increased technical complexity	Leverage common EHR systems or centralized HIE infrastructure to create a “supra-EHR” capability
Cost & Timing	Build incrementally to meet community needs & funding flows as the value of HIE is demonstrated	Similar to federated model (with added cost for central repository)	Realize long-term vision & cost-efficient implementation (may require larger initial investment)

Source: Authors’ analysis of case study findings.

Note:

At the time of the case study, Western New York planned to add a central data repository to become Hybrid-Federated Form 2; Cincinnati had already done so.

Three members of the research team conducted a qualitative cross-case analysis of interview transcripts and secondary documents using case-ordered displays11 to identify commonalities and differences between study sites and to stratify the analysis congruent with the HIE architecture model. Case-ordered displays were organized around predefined categories used in the interview guide. The research team also drew on knowledge gained from prior qualitative study of several Beacon Communities.12 The entire research team reviewed and refined the resulting thematic analysis and contributed to the preparation of this manuscript.

Technical Architecture

Clinical applications of HIE are relatively recent and have evolved rapidly from earlier efforts to electronically exchange health insurance transactions. Industry observers have noted that HIE is progressing from a “first-generation” to a “second generation” paradigm.13 First-generation HIE focuses on basic clinical data exchange to support care transitions and referrals, typically using Web-based portals and secure messaging services to exchange patient information (e.g., laboratory test results, medication histories, hospital discharge summaries). Typical first-generation HIE users, largely motivated by the efficiency gains associated with simplified electronic connections and the elimination of paper faxing, have been physician practices, hospitals, health systems, pharmacies, and agencies for long-term care and home care.

The evolving second-generation HIE paradigm (referred to as “HIE 2.0”) seeks to extend clinical data interchange and deploy the analytic capabilities necessary for delivery system and payment reforms.14 To support a broader array of “use cases” (e.g., quality improvement, population health management, research and evaluation), HIE 2.0 technical architecture may evolve to execute more advanced functions and incorporate other data sources, including disease and immunization registries, health insurance claims, patient-reported outcomes, and data from home telemonitoring devices.15 This expanded functionality and additional source data engages new end users, including but not limited to patients, employers, health insurance plans, public health agencies, and researchers. Many Beacon communities were early adopters of HIE, and used their grant funding to pioneer and extend the services, data, and users of the technical architecture in their catchment areas.

HIE Architecture Models

Community design choices for HIE technical architectures fall along a continuum from fully decentralized on one end to fully centralized on the other, with several hybrid permutations in between.16 Although these models can be grouped into general categories (Figure 1), there are distinctions within each model, as well as variations in the ways a model may be implemented. Communities may refer to their HIE architecture by the same name, even when their particular configurations differ. This section describes in high-level terms the defining features of each HIE model and their potential implications for enabling advanced HIE capabilities.17

In a (see Figure 1, left side), also known as a “federated” or “distributed” model, each participant organization maintains separate control of its data, typically in special “edge servers” at its own location, and shares patient-specific data upon request from other HIE participants. In a strictly decentralized model, every request for patient data must be made to every participating data source, which effectively limits its bandwidth to relatively low volume applications. None of the study sites represented this far end of the continuum.

In a (see Figure 1, right side) all data that participants agree to share are normalized in a common format and terminology, and are housed together in a central data repository where they can be accessed and used by participants in accordance with defined policies and procedures. More than one repository may exist for different kinds of data; for example, digitized radiographic images might be housed in a separate repository given their large size and specialized use. A centralized model may offer the best technical performance when measured by patient data availability and response time to user queries.18 Study sites representing this model were Bangor, Inland Northwest, and Tulsa.

The (see Figure 1, center column) builds on the decentralized model by adding a “record locator service” that tracks where patients have received care and, consequently, where their source data can be requested. We found two general forms of the hybrid-federated model among the study sites. In hybrid-federated form 1 (represented by Western New York), the HIE organization manages participants’ data (copies of the original) in separate edge servers at a central location, but without a shared central repository. This model is designed primarily for clinical applications, in which heath care providers access data for one individual patient at a time. Hybrid-federated form 2 achieves the functionality of a centralized model for analytic purposes, either by layering a central repository of normalized shared data on top of the hybrid-federated architecture (Cincinnati and Keystone), or by normalizing data in one computer where the data are partitioned by source (Central Indiana). The hybrid-federated form 2 model thus facilitates data use about multiple individuals by providers and others who may want to identify patient cohorts or specific populations of interest.

Some basic technical infrastructure is common across all models to support data connectivity and routing. For example, in the absence of a uniform, national patient identifier, all sites used a master patient index to match information about a single patient treated by multiple health care providers.

Factors Influencing HIE Technical Architecture Decisions

Contextual factors influencing study sites’ choice of HIE architecture can be broadly categorized as internal, and therefore susceptible to local influence, or external and therefore more difficult for communities to influence, at least in the short term. Although we discuss each of these factors in turn, they exerted influence on technical decisions in an interconnected fashion. Table 3 summarizes these factors for each of the HIE architecture types the study sites represent.

Internal Factors

Among the study sites, internal concerns arose from each community’s unique characteristics and culture, and were shaped by factors such as previous and existing trust relationships, competition and market dynamics, existing health IT infrastructure, prior health care technology experience, functional expectations of EHRs and HIEs, funding opportunities, and time frame.

Trust and Competition

Convening and building trust among the key stakeholders was a critical foundational task for all Beacon Communities regardless of the ultimate HIE architecture model adopted. We conceptualized trust in two complementary ways. The first involved a secure relationship with others in the HIE community and confidence in the integrity of the HIE technology and its associated outputs such that an HIE participant was willing to share data with other participants and use the shared data to support decision-making. Another way of conceptualizing trust was a willingness to sublimate individual organizational interests in favor of coopetition—that is, cooperating with competitors to create a shared infrastructure that provided all participants with greater benefit than any could achieve on one’s own, while also recognizing that each continued to seek competitive advantage in other ways. The time and strategy needed to build sufficient trust levels varied according to a number of stakeholder attributes, which included attitudes about data sharing and health IT in general, the degree of shared common values and objectives, as well as previous collaborative experiences and existing relationships. (Detailing the complex dynamics at work to foster and achieve trust within individual communities is beyond the scope of this paper and is deserving of further study.)

Generally speaking, trust took longer to build in communities (such as Greater Cincinnati and Western New York) where market dynamics led stakeholders to view their clinical data as a competitive asset, or where other concerns precluded sharing data in a central repository. In these communities, stakeholders appeared to feel more comfortable initially adopting a hybrid-federated HIE model without a central data repository. In the Western New York Beacon Community, for example, initial electronic patient data exchange focused on the delivery of clinical test results and medication prescribing—and then expanded over time to encompass bidirectional sharing of continuity of care documents between providers. As stakeholders gained mutual trust in sharing data, they committed to (eventually) adding a central data repository to their hybrid-federated HIE model, which will support the region’s developing accountable care and patient-centered medical home arrangements.

In contrast, the Bangor Beacon Community, which participated in the ongoing development of a statewide centralized HIE model, described an existing “trust fabric” among key providers that had been woven, at least in part, by a history of working together to treat shared patients. This history, along with other forms of cooperation, seemed to foster a data sharing culture, rooted in community stewardship and cooperative values, which transcended organizational boundaries. Further, an agreement to make key decisions by consensus, such as the adoption of common performance metrics, deepened provider engagement and trust in the community’s Beacon-funded activities.

Although its experience was not common, the Greater Tulsa Beacon Community built trust relatively quickly from a shared belief that a centralized HIE capability could be an important community resource that would address a perceived urgency to reduce the region’s enormous health disease burden. Hospital leaders also saw potential immediate value in sharing clinical data to help improve care transitions and reduce readmissions as they faced a common threat—federal financial penalties for excess readmissions.19 The community’s rapid progress may have also been due to their framing the HIE planning period as a collaborative 100-day challenge led by community leaders. Providers developed trust and asserted leadership by collectively volunteering more than 10,000 hours to HIE planning, development, and implementation.

Existing Health IT Infrastructure and Experiences

The choice of HIE architecture model also was influenced by community perspectives on the inter-relationship between HIE and EHRs and how communities elected to build on existing health IT infrastructure and experiences. Western New York, for example, used its hybrid-federated HIE model to support disease registries and clinical decision support capabilities within providers’ EHRs; rather than create a central repository for this purpose, they viewed the EHR as the core tool for enabling more efficient clinical work-flow. In Greater Cincinnati, the multi-stakeholder group promoting HIE sought a flexible hybrid-federated architecture in the late 1990s because its health care community was wary about making any large investments in HIE too soon after weathering a failed attempt to build a Community Health Information Network. The new HIE organization, HealthBridge, subsequently allayed these concerns by demonstrating competence in meeting a business need,20 paving the way for it to add a central data repository as part of its participation in the Beacon Community Program.

The three sites that opted for a centralized model (Table 1) appeared to view the aggregation of shared clinical data in a central repository as a community resource that would enable enhanced capabilities to supplement or more fully realize EHR functionality. The Greater Tulsa Beacon Community, for example, aimed to use its clinical data repository to power communitywide health analytics; efficient performance measurement and reporting; and a range of cloud-based applications for clinical decision support, care coordination, and secure communications.

Past experiences with health IT had been positive and collaborative in the community hospitals that participated in the Inland Northwest Beacon Community, which served the predominantly rural region around Spokane, Washington. For many years, the community had shared IT services provided by a single EHR vendor, including an existing central data repository. This made it easy to choose a centralized HIE model that could be extended to include other community providers in the area, many of whom had adopted the same EHR vendor system. (Technology and changing market dynamics have made it difficult to extend the HIE to include urban health systems located in Spokane.) Likewise, major health systems serving Bangor used the same EHR platform, which made it easier for the community to create an integrated HIE infrastructure and to optimize opportunities for effectively sharing best practices.

Cost Considerations and Timeframe

Study communities did not provide an accounting of implementation costs, nor was it the focus of this study. However, communities all made choices about how and when to absorb the costs of building HIE capability based on the needs and limitations of their particular business models and funding sources. Sites that implemented a hybrid-federated model felt comfortable making smaller initial investments, with the opportunity to build out the infrastructure in stages as community needs evolved and stakeholders’ understanding and confidence in the value of HIE increased. Centralized model sites, in contrast, tended to view the hybrid-federated model as requiring reworking and a later financial reinvestment to add a central data repository; they deemed early incorporation of the central repository as essential to their vision for a successful fully functional HIE infrastructure with advanced capabilities. Each community made choices about technical architecture that its stakeholders believed were right for their circumstances.

External Factors

Regardless of the HIE technical architecture chosen, study communities shared common concerns about vendor capabilities and cooperation, technical standards and interoperability, and privacy and consent policies. These concerns posed implementation challenges that influenced technical design decisions and required sites to develop innovative solutions.

Vendor Capabilities and Cooperation

Study communities reported that no single commercial off-the-shelf product could build and implement the broad range of functionalities for an advanced HIE solution. Instead, to varying degrees, they adopted a “best of breed” approach that knit together multiple vendor solutions. Nearly every community cited the need for cooperation with EHR vendors to extract discrete clinical data from EHRs necessary to support interoperability and/or to build central data repositories. Both of these factors necessitated access to skilled, in-house IT teams who understood the needs of the community, had the expertise to customize an HIE system from disparate components, and worked successfully with vendors.

Standards and Interoperability

Study communities were eager to normalize data through the use of agreed-upon standards to facilitate EHR interoperability; consistent data collection; and efficient analytic, reporting, and evaluation capabilities. However, health care provider use of nonstandard clinical codes and terminology and variable data entry practices, as well as vendors’ weak support for or differential implementation of transactional standards and data transport protocols, made data normalization challenging for all sites. Harmonizing the resulting data and technical variations required significant additional time and resources.

An illustrative case is the Continuity of Care Document (CCD), which is used to extract standard patient data from EHRs into a central data repository, or to enable standardized data exchange between EHRs. Two methods currently exist to exchange CCDs between EHRs. The first is a fully functional CCD with metadata that instructs the receiving EHR on how to incorporate the clinical data content into the patient’s electronic record. The second method is a simple text file of clinical data elements exchanged via secure email attachment, which the recipient manually incorporates into the receiving EHR (an example of “directed exchange” defined in the glossary). Several study sites reported that EHR vendors interpreted compliance with the CCD standard to mean enabling only the second method, essentially subverting full EHR interoperability. Consequently, the CCD standard could not be implemented as a data exchange mechanism without technical workarounds.

Privacy and Consent Policies

Because the United States does not have a uniform policy approach to data privacy, but a patchwork of information-specific legal standards, administrative uncertainty, and technical complexity may have influenced HIE technical architecture choice.21 For example, the Keystone Beacon Community used a hybrid-federated HIE model as an adjunct to a central data repository at least in part because state law was interpreted to require that patients give consent to each provider holding data should they wish to have their clinical records added to the central data repository. The practical difficulties of this consent model led to limited data collection in the central repository. In consequence, providers who wanted to access individual patient data depended primarily on a query tool to identify the patient’s other providers who held data, which they then obtained through separate portals or by request.

Practical Implications of HIE Technical Design

Having weighed some or all of these internal and external factors, study communities ultimately developed an HIE design that reflected these considerations. The most important practical implication of their design choice was whether, and if so how easily, an HIE architecture could evolve to enable HIE 2.0 functionalities, which meant implementing communitywide disease registries, enabling advanced analytic capabilities, and supporting the reuse of clinical data for research purposes. The particular architecture did not appear to impact capacity to perform some advanced capabilities, such as clinical event notifications; however, it may have influenced the way they were executed. Table 4 summarizes these practical implications by type of architecture model. (See the Appendix for specific examples of the functionalities described in this section.)

Table 4.

Summary of Findings: Practical Implications

Model	Hybrid-Federated Form 1	Hybrid-Federated Form 2	Centralized
Description	HIE participants maintain separate control of their data & share it via the HIE infrastructure upon request	Hybrid-federated model combined with—or designed to achieve the functionality of—a normalized central data repository	Data shared by HIE participants are normalized, housed in and accessed from a central data repository
Communities	Western New York*	Central Indiana, Greater Cincinnati, Keystone	Bangor, Inland Northwest, Greater Tulsa
Practical Implications of HIE Technical Architecture Models
Clinical Transformation	Enhance EHR capabilities for clinical decision support & workflow (e.g., templates for data collection)	Some combination of the two models	Offer common care management tools (e.g., communitywide disease registries, e-referral management)
Continuous Learning & Improvement	Extract & aggregate EHR-generated quality reporting for community analysis and benchmarking	Similar to centralized model (depending on data availability)	Develop a community resource with consolidated & standardized data for clinical, analytic & reporting uses
Research & Evaluation	Identify study populations & extract data for each individual (laborious & may be impractical for large studies)	Similar to centralized model (depending on data availability)	Use central data repository to identify, aggregate data, and follow study populations of interest

Source: Authors’ analysis of case study findings.

Note:

At the time of the case study, Western New York planned to add a central data repository to become Hybrid-Federated Form 2; Cincinnati had already done so.

Clinical Transformation: Care Coordination and Care Management

Supporting improved care coordination and care management is one benchmark by which to measure the clinical effectiveness of HIE. Study sites reported a rich array of activities that used HIE in primary care settings to track clinical care and outcomes for defined populations, particularly to prompt referrals or appointments for patients in need of preventive or chronic care services.

Generally speaking, communities with a central data repository or equivalent functionality used (or planned to use) it to implement communitywide disease registries and care management tools that tracked and reported on services received from multiple providers and thus allowed holistic identification of gaps in care. In contrast, Western New York, which lacked a central repository (at the time of the case study), supported providers in using EHR-specific decision-support tools for this purpose. In the latter case, the treating clinician can use a Web-based HIE query portal to look up a history of care the patient has received from other providers.

Electronic admission-discharge-transfer (ADT) alerts, which require technical HIE functionalities such as a master patient index, an integration engine, and a rules engine,22 were used in all study sites (along with other tools) to alert clinicians when patients were admitted or discharged from the hospital, thereby more effectively monitoring and supporting patient care transitions and follow-up chronic disease management.23 Some sites with central data repositories, in addition to alerting providers, used data elements contained in ADT alerts as an efficient means of populating their repositories.

Patient Engagement: Patient Portals and Home Telemonitoring

HIE architecture appeared to exert only marginal influence on how study communities implemented patient portals. Some communities philosophically preferred a single communitywide portal that allowed patients to access their clinical information collected by the HIE across multiple providers. However, health care providers generally preferred that patients access clinical data directly from portals connected to their own EHRs, which they perceived as reinforcing the patient’s relationship with the provider. Although less convenient for patients who must use multiple provider portals, this EHR-specific approach is currently favored by EHR meaningful-use requirements. In an apparent compromise, Western New York’s pilot tested both approaches. Home health agencies in the Western New York community also tested how its hybrid-federated HIE capability could be used to support patient home telemonitoring (see Appendix for details).

Continuous Learning and Improvement

Reuse of electronically exchanged clinical data—while sometimes challenging to implement—appeared to advance continuous learning and improvement in all the study communities. Advanced HIE functionality supported deeper analysis of previously untapped data; facilitating performance measurements and reports, clinical analytics, public health surveillance, pay for performance, and evaluation of interventions.

Communities using the centralized HIE model (Bangor, Tulsa, Inland Northwest) and hybrid-federated models that functioned like a centralized model (Cincinnati, Indiana) more easily performed varied and robust analytic tasks. For example, the Greater Tulsa Beacon community deployed a commercial analytic tool, Archimedes IndiGO, that calculated patient-specific predictive risk scores for certain health conditions, recommended interventions, and allowed providers and patients to explore the relative effects of different health improvement strategies. Tulsa’s centralized HIE model allowed it to develop a process to run the tool each night through the complete patient population in the central data repository (about 850,000 people), and display risk scores on a custom dashboard so that providers could prioritize when to use the IndiGO tool with a particular patient.24 (See the Appendix for additional examples.)

Performance Measurement and Improvement

Regardless of the HIE architecture model chosen, a central data repository or equivalent normalized data storage (e.g., communitywide registry) provided comprehensive clinical data across care settings, giving a more complete understanding of care gaps and a more accurate assessment of how interventions had an impact on care processes that spanned organizational boundaries.

In the absence of a central data repository, Western New York established a common EHR registry template to collect and aggregate clinical quality performance results from community providers’ EHR systems.25 This purpose-driven manual repository was useful in providing performance feedback to physicians, which also reinforced the value of consistent and accurate data collection within EHRs. Greater Tulsa is evaluating how clinical quality performance reported by individual providers’ EHRs compares to performance results reported using the HIE central data repository on the assumption that the repository enables more complete and accurate reporting on patients’ use of community-wide services.

Public Health Surveillance

All study sites collected and shared clinical data in a timely manner with public state health authorities. Western New York used its federated HIE model to develop open-source solutions that facilitate electronic biosurveillance and transmission of immunization records. Maine’s statewide central data repository, derived from providers’ EHRs, supports automated reporting of specified conditions such as Lyme disease or food poisonings. Indiana electronically collected emergency department visit complaints from more than 100 hospitals statewide for use by state and local health department epidemiologists to detect and investigate disease outbreaks, acts of bioterrorism, and other public health emergencies.26 (See the Appendix for details on their programs.)

Research and Evaluation

HIE architecture had significant practical implications for the study sites’ research capabilities. For example, by normalizing clinical data in a centrally managed, hybrid-federated architecture, the Indiana Network for Patient Care makes it possible for researchers to query or extract data (with appropriate oversight) to create cohorts, identify potential research subjects, track patient outcomes, and conduct epidemiologic studies to identify drug side effects.27 In a decentralized or strictly federated HIE model that lacks such functionality, patients can be identified for research studies, but data must be laboriously extracted one patient at a time from distributed sources. Comprehensive evaluation often required other sources of data, such as insurance claims, reports, or patient reported experiences and outcomes. (See Appendix for examples.) In the future, as electronic data sources and types further proliferate, and are incorporated into community HIE infrastructure, their applications for evaluation and research (e.g., crosscommunity comparisons) will be further enhanced.

Discussion

This qualitative study finds that communities’ choice of HIE architecture primarily reflected differences in how their circumstances and philosophies shaped their use of health IT for achieving particular aims. It builds on, and is congruent with, prior research on communitywide HIE, which emphasized the importance of fostering trust, addressing strategic interests, and providing quality measurement benefits.28

Our findings suggest that communities embarking on HIE initiatives would do well to examine how particular HIE technical architectures map to their objectives, local context, existing relationships, sustainability plans, and vision of both present and possible future needs. (See Table 5 for a list of practical questions that communities should consider when choosing to set up an HIE, based on lessons learned from the case study sites.)

Table 5.

Practical Considerations When Choosing to Set Up a Community HIE

Factors	Questions to Consider
Assess existing trust levels in your community	What is the potential to build trust over time? What are common interests that you can draw upon to find common purpose? What pitfalls or past negative experiences do you need be mindful of and overcome to build support?
Identify the strengths and weaknesses of health IT infrastructure in your community	How can you build on existing health IT infrastructure, and what gaps do you need to fill? How many EHR vendors will you need to engage, and what is their track record for supporting communitywide HIE?
Consider sources of funding and timing of investments	Is it more realistic for your community to make a series of incremental investments as you build support for HIE? Or can your community make a larger upfront investment to seek more immediate return?
Carefully evaluate HIE vendor capabilities	Will you need to depend on one vendor for a turnkey solution? Are you prepared to provide skilled in-house IT expertise to link together multiple components from different vendors?
Be prepared to engage with providers to standardize and normalize data	Will you work with providers to agree on common coding practices, and if so, how? How will you gain the cooperation of EHR vendors to fully support a common implementation of technical standards?
Assess the implications of privacy regulations and expectations in your locality	Will you follow an opt-in or an opt-out approach to patient consent? What effect will that approach likely have on your ability to collect data in a central data repository?

Source: Authors’ analysis.

Regardless of architectural model, all communities profiled for this study pursued a rich array of activities to embed HIE into clinical practice; however, the basic design and the community philosophy toward HIE affected implementation for patient care and management, as well as capabilities for performing some advanced functions. Their experiences suggest that the vision of HIE 2.0—with its promise to leverage the analytic capabilities necessary for delivery system and payment reforms and to support a broader array of “use cases” for population health management—requires a central data repository of normalized data and a functional method to access and extract data on patient cohorts. Given the current capabilities of health IT and variable adoption of interoperability standards, it seems unrealistic to expect that simply linking disparate EHR systems will enable these kinds of shared analytic capabilities at the community or regional level without the addition of advanced HIE capability.29

Communities may choose to build a centralized model from the start, or a hybrid-federated model that achieves the functionality of a centralized model. Communities may choose to adopt hybrid-federated models without a central repository because they are relatively easier to establish and build incrementally. Over time, however, communities (e.g., Greater Cincinnati) that chose this initially easier path to HIE had to face their models’ limitations and eventually made a decision to add a central data repository.

Building and leveraging trust was crucial to counteract reluctance around sharing data across all communities, but especially when implementing a central repository. As communities built trust and comfort levels, and as market dynamics shifted and new policy levers emerged to reflect the value of more advanced HIE capabilities, most stakeholders became ready to contribute clinical data to a central repository for specific stated purposes.

The convergence of technical HIE capabilities in hybrid-federated models that offer equivalent functionality to centralized models means that there may be fewer “edge cases” in which one technical approach or another is clearly superior for implementing community HIE infrastructure. Continuing advances in technology will likely change the future landscape for community decision-making in terms of both the functionality and value offered by health IT. One community leader noted that, in regard to different technical approaches, “every community [using] HIE is still different enough that it’s difficult to say what the right answer is at this moment. To me the right answer is only determined by what impact it has on health outcomes.”

Conclusion

This case study analysis suggests that it is worthwhile for local health system stakeholders to invest in developing community-wide HIE capabilities to support shared goals. While they have progressed from different starting points along multiple pathways, the study sites now commonly recognize the need for advanced HIE functionalities (including a central data repository) to support the “triple aim” of health system improvement. Communities embarking on building HIE infrastructure should consider how the lessons of the study communities apply to their own circumstances, and plan from the outset to identify the pathways for evolving from basic to advanced HIE functionality as they also identify a business model to support these services.

Advanced HIE Applications	Examples from Seven Beacon Community Case Study Sites
Care Coordination and Care Management Clinical event notification using hospital admission-discharge-transfer (ADT) alerts Referral management communication tools Clinical data exchange using continuity of care (CCD) document standards Disease management using patient registries and tools	Bangor – Experts have long recommended that primary care providers use disease registries to track the clinical care and outcomes of defined patient populations. The Bangor Beacon Community purchased a commercial product (Meridios) that extracts data from electronic health records (EHRs) to monitor the needs and outcomes of patient populations at a provider, practice, system, or regional level. To fulfill the community’s stated aim of improving the management of chronic diseases, they have selected 44 metrics to track performance improvement among patients with diabetes, cardiovascular disease, chronic obstructive pulmonary disease, or asthma. The disease registry generates reports that allow medical staff to identify high-risk or high-need patients, reach out to offer preventive care, and identify where improvement is happening to learn from success across the community.Greater Cincinnati – Many primary care providers no longer see patients in the hospital and, consequently, may not know when their patients are hospitalized. To overcome this information gap, HealthBridge engaged with hospitals to generate electronic admission, discharge and transfer (ADT) alerts, to match the alert to a master patient identifier, to translate the alert into one of four standard formats, and then electronically send the alert to the individual’s primary care provider using their preferred message format. The primary care provider can then reach out to interact with hospital staff as needed and schedule follow-up care after the patient is discharged. At Cincinnati Children’s Hospital Medical Center, for example, primary care-based care coordinators use the alerts to connect with and evaluate asthmatic children in the hospital and then follow-up with them in the clinic.Greater Tulsa – Providers can use a secure, web-based tool (Doc2Doc) to manage patient referrals, consultations, care transitions and ongoing care coordination. Although the tool was in use prior to their centralized HIE infrastructure, its use has been expanding as MyHealth Access Network, the region’s HIE organization, included Doc2Doc in its suite of cloud-based apps. Users include primary care providers, hospital emergency departments (EDs), urgent care centers, physical therapists, home health agencies, diagnostic imaging centers, and patient educators. This integrated communication system has been shown to reduce unnecessary specialty care referrals, thus reducing wait times for Medicaid beneficiaries to access specialty care. The system also immediately alerts primary care providers of an ED visit, allows EDs and urgent care centers to monitor whether patients receive follow-up care, and creates a detailed log of the actions taken to monitor quality and support quality improvement.Inland Northwest – A risk-based algorithm, integrated into the HIE, draws from the clinical data repository and from patient interviews to provide care coordinators with diabetes patient-specific recommendations on evidence-based follow-up care.Keystone – Nursing facilities and home health agencies are required to conduct and submit patient assessments to the federal government for quality assessment purposes, but this information is also useful for routine care management. The Keystone Beacon Community partnered with its HIE vendor to develop a tool called “KeyHIE Transform” to make this information more readily accessible for this purpose. To do this, the tool translates patient assessment data from the quality reporting formats used by skilled nursing facilities and home health agencies to the standard Continuity of Care Document (CCD) format defined for electronic data interchange, and then transfers this data into the HIE where it can be accessed by the patient and the patient’s care team. The tool can be used with or without an EHR, making previously inaccessible information from long-term and postacute-care facilities available in a patient’s health record.Western New York – To realize the goal of interoperable EHRs, providers must exchange clinical data in a standard format that has the same meaning in both the sending and receiving EHR. In 2008, HEALTHeLINK began collaborating with Catholic Medical Partners (CMP), a large regional independent practice association, to test electronic data exchange among providers using a standard format known as the continuity of care document (CCD). Since then, HEALTHeLINK has enabled over 500 CMP providers to exchange more than 200,000 CCDs. Despite this success, the community has struggled to expand CCD interchange capability among other EHR systems, in part because simpler-though less comprehensive-methods for information exchange (e.g., Direct) have come onto the scene in recent years.
Patient Engagement* Patient portals Patient education & shared decision-making Home telemonitoring *Note: Several communities have implemented mobile health technology as an informational service to provide tips and reminders for disease prevention, such as physical activity and diet, and preventive care such as flu shots. While these tools did not appear to be integrated with or dependent on the HIE architecture, it may be useful to consider whether and how they could be improved by doing so in the future.	Bangor – In January of 2012, Maine’s statewide HIE organization, HealthlnfoNet, entered into a partnership with a personal health record (PHR) vendor to offer all Maine residents equivalent access to their personal health information stored in the HIE. However, after Meaningful Use Stage 2 criteria required EHRs to give patients an electronic copy of their health information, providers have indicated their preference for patients to use EHR-based patient portals for this purpose. As a consequence, HealthlnfoNet suspended its PHR initiative and will instead support a “single sign-on” capability by which patients can access their health information from any of the disparate EHR patient portals used at the practice-level.Greater Cincinnati and Greater Tulsa – These Beacon communities are testing the use of an analytic tool (Archimedes IndiGO) for clinical decision support. Using clinical data collected from EHRs and stored in a central data repository, IndiGO calculates a patient-specific risk profile for certain health conditions, recommends evidence-based interventions, and allows physicians and patients to explore the impact of different health improvement strategies together, such as quitting smoking, undergoing medical procedures, or taking medications.Greater Tulsa – Health care providers can send a patient’s health report into a community-wide patient portal and the patient can upload their personal health records from their Microsoft HealthVault account. Expanding the use of this portal will require that it be certified in meeting Stage 2 meaningful use requirements.Keystone – MyKeyCare, a networked personal health record, allows patients to access their health records from clinicians who participate in the HIE. Patients may also upload health records to make them available to HIE providers, send and receive messages from their providers, receive preventive care alerts, and assign access to someone they designate as their health care proxy. Clinicians can add information with patient consent. Keystone Beacon is partnering with Zweena, an outside service that assists patients, especially transients, who need help scanning and uploading their information.Western New York – The community has provided nearly 150 diabetic patients at risk for hospitalization with preventive telemonitoring tools – measuring glucose, blood pressure, weight, and oxygen levels – through three home health agencies. The information recorded by patients at home is fed directly into the HIE, making the region one of the first in the U.S. to achieve this integration. Patients’ physicians can opt to receive telemonitoring data via HIE clinical results delivery or simply access telemonitoring data as needed by logging in to view a patient’s virtual health record.Western New York – With Beacon funding, HEALTHeLINK is supporting two patient portal models. For the first model, the HIE partnered with Catholic Medical Partners (CMP), a large regional independent practice association, to enable 30 physician practices to include clinical test results from the HIE in patient portals provided by their EHR vendor. The practices have been signing up diabetic patients (over 500 in the pilot) and educating them on how to use the portal to facilitate the coordination of care across their team of providers. For the second model, HEALTHeLINK built a gateway to Microsoft HealthVault accounts, giving providers the ability to manage how and when certain HIE information appears in patients’ personal health records.
Continuous Learning and Improvement Performance reporting Clinical analytics Pay for performance Public health surveillance	Bangor – see Care Coordination and Care Management above.Central Indiana – This Community focused much of its Beacon-funded effort to expand a program called Quality Health First (QHF), which supports chronic disease management and new pay-for-performance contracts. QHF combines clinical data collected through the Indiana HIE and claims data contributed by insurers to attribute patients to their primary care physicians, identify departures from evidence-based practices, provide clinical decision support and report on standard quality measures to physicians and payers. In addition to generating monthly reports for physicians to use in improving patient care, QHF also provides community-level physician comparisons, summaries to payers to track progress, summaries for provider groups to support systemwide improvements, and population-based reports for all stakeholders.Greater Cincinnati – To support a community patient-centered medical home initiative, HealthBridge developed a “quality improvement toolbox” to help primary care practices integrate health IT into their workflow. This included letters that the practices could send to follow-up with patients who visited the emergency department. The HIE organization also sent each practice a monthly summary of the ADT alerts generated about its patients, indicating where patients received emergency care, the times of day they presented, and their chief complaints. This summary allowed providers to discover trends and determine if there were opportunities for improving patient care management.Greater Tulsa – MyHealth collaborated with a biostatistician and an epidemiologist at the University of Oklahoma to develop and validate measures to report on communitywide and provider-specific clinical quality, cost and use of services using data from a central repository collected from EHRs. These measures were derived primarily from those endorsed by the National Quality Forum, plus others to assess the outcomes of a local referral management tool, Doc2Doc. Health plans participating in the federally sponsored Comprehensive Primary Care initiative (CPCi) are requiring participating physician practices to participate in the community HIE organization. MyHealth provides the practices with secure access to comprehensive viewing of each of their patients’ records, enabling the delivery of a true medical home model of care. In addition, MyHealth offers the practices advanced analytics tools to support them in meeting the extensive performance reporting requirements of the CPCi.Greater Tulsa – One challenge to efficiently using the Archimedes IndiGO tool (described above) is that physicians don’t know in advance whether it will be worthwhile engaging in extensive patient counseling with a particular patient; those who are relatively healthy will have little to gain. To solve this problem, MyHealth developed a process to run the analytic tool proactively each night through the complete patient population (about 850,000 people) represented in the central data repository whenever a change is made to their clinical records. Identified care gaps and health risks are brought to the attention of providers via the MyHealth Web portal and secure messages. Results can be viewed on a custom dashboard that ranks risk as high, medium, or low to help providers prioritize when to utilize the interactive IndiGO tool with patients.Inland Northwest – Quality of care reports including diabetes metrics and performance goals (from the National Committee for Quality Assurance Diabetes Recognition Program and the American Diabetes Association) are sent to providers quarterly to use for internal quality improvement initiatives. Metrics pertain to each provider patient population, along with comparable metrics for other providers within each clinic and de-identified providers in the community and region. A “care coordination readiness assessment” tool helps provider practices measure whether they are really doing as much to coordinate care as they think they are and to recommend in-person staff trainings and online educational series that had been developed in-house.Bangor – Using a robust statewide central data repository of patient health information extracted from providers’ EHRs, HealthlnfoNet supports public health surveillance through automated reporting of specified conditions to the Maine Center for Disease Control and Prevention (CDC). For example, records on Lyme disease, foodborne diseases, and immunizations are among those sent to the Maine CDC by automated exchange.Central Indiana – Indiana’s Public Health Emergency Surveillance System (PHESS) electronically collects emergency department visit complaints from more than 100 hospitals statewide for use by state and local health department epidemiologists to detect and investigate disease outbreaks, acts of bioterrorism, and other public health emergencies.Western New York – HEALTHeLINK used its federated HIE model to develop open-source solutions that facilitate electronic biosurveillance and transmission of immunization records to the New York State Department of Health, an approach that can be adopted by other communities.
Research and Evaluation Human factors research Cost & use studies Network analysis Comparative program evaluation studies	Bangor – One of several pilot projects undertaken by the Bangor Beacon Community has been testing the impact of HIE-enabled care management on self-management among high-risk chronic disease patients (defined by past 6-month hospital use or ED visit, plus a diagnosis for asthma, Congestive Heart Failure, COPD, or diabetes, and one or more additional risk factors). The pilot included 1,500 patients (300 controls) who completed additional consent for participation. Evaluators used hospital billing data, as well as de-identified data drawn from EHRs and the HIE, which covered clinical outcomes, preventive measure outcomes, utilization, and patient-reported outcomes. They assessed individuals health markers and care utilization in 6-month intervals over an 18-month period. While the team is still collecting more control data in order to perform a more rigorous analysis, preliminary data suggest patients with the care management intervention experience significantly fewer ED visits and three to four times fewer admissions than controls.Central Indiana – The HIE architecture of the Indiana Network for Patient Care makes it possible for researchers to query or extract data (with appropriate oversight) to identify potential research subjects, track patient outcomes, and conduct epidemiologic studies to identify drug side effects. For example, one epidemiologic study found that use of the antibiotic erythromycin in newborns was associated with increased risk of pyloric stenosis, a narrowing of the opening from the stomach into the small intestine (Mahon B.E., Rosenman M.B., and Kleiman M.B. (2001) J Pediatr. Sep;139(3):380–4). Research related to the Beacon program includes studies of the effects of HIE on the use of imaging tests, how telemedicine-enabled hospital discharges influence rates of rehospitalizations in patients with heart failure or COPD, and a comparison of diabetes outcomes with three different modalities of care management.Inland Northwest – To determine whether Beacon interventions had a beneficial influence on the receipt of preventative services for diabetes patients, the Beacon Community of the Inland Northwest engaged outside aggregators to provide de-identified patient claims data and compared the number of preventative services patients received in adjacent hospital referral regions. They are also planning to do qualitative analyses, primarily in the form of interviews of clinic personnel–who are at different stages of implementation or intervention–to determine how well the intervention has served their needs and the needs of their patients.Keystone – An evaluation team co-led by Dr. Pascale Carayon of the University of Wisconsin-Madison focused strongly on human factors analysis to better understand what variables contribute to the usability and usefulness of newly implemented technologies. One such study (Carayon et al. (2012) Work 41(Supplement 1):4468–4473) explored how use of multiple health IT applications could complicate postdischarge care coordination for patients with COPD, chronic heart failure (CHF), or a surgical admission. Researchers suggested the range of challenges (organizational barriers, technology design problems, skills and knowledge issues, task performance demands) as a checklist to evaluate IT infrastructure proposing integration of various IT applications.Western New York – HEALTHeLINK is receiving a steady stream of longitudinal data from home telemonitoring devices used by a cohort of nearly 150 diabetic patients. The Beacon community’s evaluation team plans to continue collecting these data through September 2013 before analyzing them to determine what impact the telemonitoring pilot may have had on patients’ outcomes. Because the HIE also collects basic demographic and insurance information for their pilot participants, the evaluators will be able to link additional utilization and cost data from insurers’ claims to enable more comprehensive evaluations.
Usability to Support Provider Workflow Provider portal Middleware or filtering capability from Portal to EHR Single sign-on	Bangor – A “middleware” program (Qvera) pushes key data such as clinical test results to providers’ EHRs without additional workflow steps, and also gives providers the option to download a patient’s entire record or selected elements of the record from the HIE to the provider’s EHR using a standard continuity of care document (CCD) format. HealthInfoNet, the statewide HIE organization, stores a 12-month medication history for each unique patient, some providers have found this to be a burdensome and unnecessary amount of information. Using middleware, providers can elect to receive only 90 days of history to suit their needs and workflow preferences.Greater Tulsa – MyHealth Access Network, the regional HIE organization serving 11 counties in Northeastern Oklahoma, developed “single sign-on” capability, with patient context, for providers to easily log into the HIE within the framework of their local EHR system.Western New York – Because it can be burdensome to remember and use multiple sign-on credentials, HEALTHeLink developed a single sign-on capability with “two-stage authentication” so that providers can securely identify themselves just once to access various community EHR portals maintained by different institutions that hold information on their patients.