By Robert Rowley, MD, co-founder and Chief Medical Officer of Flow Health
Twitter: @RRowleyMD
Health information exchange (the verb) has been the goal of health IT, now that we have moved into the “post-EHR adoption” era of healthcare. Published and private surveys have shown that about 80% of physician practices have implemented an Electronic Health Record (EHR), and of those, about 90% have participated in Meaningful Use. The challenge before us now, then, is somehow connecting the fragmented places where health data resides, and bring them together into a unified health data layer that is current, secure, and usable.
From the perspective of healthcare providers, the goal of health information exchange is to have all the useful information about a patient in one’s hands at the time of clinical decision-making. From the perspective of a patient, the goal has been to have one centralized place where one can see one’s health information from all providers, and interact with them as needed.
The initial vision of the HITECH portion of the 2009 ARRA legislation, which set up the EHR Incentive Program (Meaningful Use) in the first place, included the desire to create regional “community” Health Information Exchanges (HIEs), where everyone could come to share data about patients. There was funding set aside to pilot such HIEs, but most of these efforts have not taken hold. In part, the failure of “community” HIEs has been because of uncertain business models to sustain them (who should pay?) as well as reluctance of competitors to share data with each other. Instead, what has grown up more organically are local, institution-created HIEs where there is a pressing business need to share data. And these local HIE efforts are now starting to try to connect with each other, facing new challenges as they do. Let us look at the issues involved here in a bit more detail.
Physician group connectivity
In a clinical setting that is fully integrated (Kaiser is an example of this), each provider’s practice is 100% from a single group, contracted with a single health plan channel, and using a single hospital system. In such a setting, one can deploy a single enterprise-wide EHR system, and achieve an Enterprise Chart experience that achieves the goal of health information exchange. The problem is, however, that much healthcare in this country is not delivered in such a fashion. More commonly, providers have multiple health plans they deal with, and share patients in more open, looser networks.
Some physician groups will deploy a single EHR across all their providers, so that each clinician has an Enterprise Chart shared within the group. Other associations are looser, and have providers using multiple different EHRs. A look at the health exchange dilemmas for an independent physician association (IPA) helps illustrate the challenge. An IPA is a loose association of practices that come together for the sake of access to insurance contracts, usually HMO contracts
In such a setting, providers participate with multiple payers, in addition to the IPA. IPA-derived patients may constitute only a percentage of the practice, say 10-40%. The remainder of the practice may be Medicare, Medicaid, direct PPO contracts, or (the somewhat rare) indemnity plans – a collection that is different for each IPA provider. Let’s say that the IPA offers a preferred EHR to its members. Some IPAs lean heavily on their participating providers to adopt the chosen EHR; others make it advantageous but do not require it. If there is an IPA-hosted EHR, then, it must house data on IPA patients as well as non-IPA patients – after all, a physician won’t use an EHR that cannot service the entirety of its practice.
So IPAs face a provider membership on multiple EHRs, some using the preferred one and others using their own. Given this common situation, there is a goal of achieving the experience of an Enterprise Chart to all its participants – a Virtual Enterprise Chart (VEC). In order to build such a VEC, the IPA will need to build an internal HIE to support it. And that internal HIE will contain data on IPA patients as well as on non-IPA patients seen in the offices of participating providers.
Connecting to hospital data
Regardless of whether the outpatient setting is a single group using a single enterprise EHR, or a looser IPA-like setting with multiple EHRs in play (with or without a VEC available to share data among each other in an outpatient setting), physicians will want to access and exchange data with the local hospital(s).
Hospitals may be local stand-alone community hospitals (surgi-centers may be included in this category for these purposes), or they may be part of a larger hospital system. Each hospital system may have its own HIE hub.
From the perspective of a hospital system, building their own HIE is a way of connecting with community physicians. Hospital admission/discharge/transfer (ADT) notifications, chart notes, imaging results, lab results, etc., can all be pushed onto the hospital’s HIE hub. It expects that community physicians will enroll in their hub, and somehow upload their patient lists so that the routing of data can take place – the hub needs to know which provider is taking care of which patients. The hospital HIE can be set up to push out alerts to clinicians who are enrolled, telling them to log in and retrieve information about their patient from their hub.
Now, if the hospital’s HIE tries to connect with an IPA’s HIE, there will be questions of permission and access. The IPA’s HIE contains data on the patients seen by participating practices (which includes IPA patients as well as non-IPA patients), and may never have been in the hospital. The hospital HIE will contain data on patients seen by IPA providers, as well as patients seen by non-IPA providers. Who should be allowed to see which data?
Payer-based HIEs – another layer of complexity
If we wanted to add a yet further layer of complexity, health plans are also starting to set up their own HIEs (in California, CalINDEX is such an example). This contains health plan data on members who are enrolled in those health plans. A subset of the hospital’s data overlaps here, and a subset of the IPA’s data overlaps here.
This complexity illustrates the intrinsic dilemma of provider-centered health data. How are permissions to be managed? Can the data ever be aggregated in ways that are useful? If a provider, seeing patients in the office (or in the hospital), is unable to see all the data on all the patients in the practice – including data from the hospital as well as the outpatient settings from everywhere the patient has been seen – then the tool is not adequate. The physician may very well not adopt it.
In fact, adoption (or lack of it) may be the biggest risk for HIE-HIE aggregation efforts. This may never be overcome with the traditional institution-centered data that we currently have.
Is there a solution?
Centralized universal health data which can be securely and quickly accessed is the foundation for the next generation of health IT. New types of EHRs which connect directly to this universal data will emerge once the platform is in place.
The universal health data layer needs to be patient-centric, not institution-centric. That means that such an effort will come from outside of current institutions – not EHRs, not medical groups, not hospitals, not health plans. Rigorous patient identity matching needs to be part of the solution, so that data from all sources – local EHRs as well as local HIEs – can be blended into a common data store (of course, with tagging of each data element as to its source). Conceivably, HIE efforts that are successful in connecting other HIEs will help accelerate this movement. But, so long as they remain institution-centered, their ability to cleanly manage permissions will be difficult. The patient needs to be at the center of this data, in order to manage the consent and permissions in a direct way.
Until there is a universal data platform, there will be a perpetual dilemma
So long as health data is fragmented into the institutional silos that created them, health data will always be a little out of sync. For the type of HIEs that simply relay queries to the connected data sources, this is not as much of an issue, since such an approach leaves data segregated into its silos and does not try to blend it.
But for more robust data-aggregation HIE efforts, the question of data being out of sync from its sources remains. An upload from an external source (like a physician’s EHR) is a static request, and the collected data won’t be updated until there is a renew/refresh request. Is this a problem? Maybe not. So long as the centralized data can be read or updated when an encounter occurs (or when a “data updated” alert from the HIE is routed to a connected physician, even in the absence of an encounter), the need to make all the databases synced at all times is not as pressing. This makes a local EHR database in a doctor’s office a sort of “buffer” of data, which can be synced with the universal data store when needed. Universal, external data is very important to the clinician, since it contains all the hospital, emergency department, and other physicians’ data (each using potentially different, incompatible EHR systems) which the physician wants in her/his hands at the point of care.
Syncing data with regular updates, most likely upon encounters or alerts, will be the work-around needed for this next intermediate period, when health data remains fragmented but efforts at consolidating it are maturing. Once the universal data becomes the lingua franca of healthcare, and is accessed directly by a new generation of EHRs that don’t keep local data (except maybe as a temporary buffer), then the “out of sync” issue goes away – all the tools (EHRs, patient portals, etc.) draw from and update the same universal data. That is the “holy grail” towards which we are building.
About the Author: Dr. Rowley is Co-Founder and Chief Medical Officer of Flow Health. Previously, Dr. Rowley served as Chief Medical Officer of Practice Fusion. This article was original published on the Flow Health blog and it is republished here with permission.