Health Information Exchanges' Tech Challenges 2

The nation's healthcare providers are digitizing loads of information about their patients. But all that effort will be of limited use if the data can't be shared easily and securely. Enter health information exchanges--organizations that are creating networks to let hospitals, doctors' practices, labs, and other healthcare providers exchange data securely with the ultimate aim of providing physicians and other caregivers more up-to-date and comprehensive patient data to improve care and cut costs.

HIEs vary in scope. Some merely link all the doctors in one hospital system to one another, as well as to independent labs and other outside facilities. Others have broader mandates to let doctors share data with colleagues in other hospital systems locally, regionally, and nationally.

Generally, HIEs provide electronic referrals, clinical messaging, public health surveillance, insurance eligibility, e-prescribing, and other services. Some exchanges operate a centralized data repository, requiring them to have their own infrastructure of servers and data centers. Others HIEs use decentralized data models and serve as less of a central hub, instead playing a traffic-cop role, coordinating the data-sharing, governance, and security policies the organization needs to function.

HIEs face a range of challenges as they try to get hundreds and even thousands of participants sharing data. Chief among them is the need to fund their efforts after their initial grant money runs out. Failure to come up with a sustaining financial model has doomed regional data-sharing organizations in the past; participants often don't see the value in funding the exchanges out of their own pockets once the initial support dries up.

For HIEs to succeed, "healthcare providers need to see the value in what they're paying for," says Micky Tripathi, president and CEO of the Massachusetts eHealth Collaborative, a nonprofit group that has helped create several regional HIEs. And that means HIEs must prove up front to participants that they're worth paying for. To do that, they have to quickly overcome many technical challenges--everything from choosing the right data-sharing platform to determining the best way for clinicians to view data to ensuring that patient data is secure.

Tools Available To Help

A handful of HIEs have been around for a decade or more. But most of the more than 200 U.S. exchanges have been launched recently, many using grants from the $547 million earmarked in the U.S. government stimulus plan to develop statewide HIEs.

There are dozens of products designed to help build HIEs. They range from those that aid healthcare providers in creating internal information exchanges to more ambitious ones that let multiple organizations share data. Electronic medical record and health IT vendors, such as Cerner, eClinicalWorks, Epic, GE, and NextGen, offer products that help healthcare providers exchange data with other caregivers, including those using different EMR software. Conventional software companies, like Microsoft and Lawson, offer healthcare-specific products that support data exchange. Microsoft's Amalga software, for example, lets clinicians access data from other healthcare systems.

HIE vendors such as Axolotl, Medicity, Orion, and RelayHealth offer products that let multiple healthcare organizations share data. Their product suites include a variety of interoperability, security, and repository tools; gateways; edge servers; master patient indexing; HIE participant directories; record locators; and portals. There also are open source options, such as those offered by Mirth and the federal Connect initiative.

But the products don't do it all, leaving HIE organizations strug-gling to solve data management, connectivity, interoperability, and security issues as well as a range of governance and policy questions.

What's more, there are relatively few successful, mature HIEs to serve as models, and no clear blueprint for the best approach to building one. Forty or 50 vendors are trying to provide products that do this, but so far, there are "few successes," says Jason Hess, general manager of clinical research at KLAS, a healthcare research firm.

"There's a lot of black art involved" in building HIEs, says Dr. Marc Overhage, CEO of the Indiana Health Information Exchange, one of the nation's longest running, most successful HIEs, providing data to 19,000 physicians and 70 hospitals across the state.

Centralized, Federated, Or Hybrid

The first question HIE organizations must address is where the data will reside: in an aggregate centralized repository, or on a federated or a hybrid platform. In the aggregate model, patient data from participants' systems is replicated in a central repository. When a participating provider enters a query for data on a specific patient, a master patient index or record locator service finds the data.

In a federated model, patient data stays in the source healthcare provider's system. Other providers search an index to locate the data they need and then request it from the source.

Many HIEs are taking a hybrid approach, where data is replicated on an edge server. Queries come in through a master patient index or record locator service, and are directed to the edge server containing the particular data requested. There's no commingling of data in a central repository, and the provider that's the source of data doesn't give up control.

Redwood MedNet, a five-year-old HIE that serves three hospitals and about 50 other providers in two rural counties in Northern California, started with a federated topology because it provided better security. But it turned out to be unwieldy as the HIE grew, so Redwood migrated to a hybrid platform in January. "Excessive security was imposing on the productivity of the system," project manager Will Ross says.

The HIE's size and need for scalability play a key role in determining which approach it chooses. The hybrid model is particularly good for large and growing HIEs because it's easy to scale, since it doesn't require a large database. The decision on which way to go often hinges on whether participants can agree on what data and how much of it to share, and who retains control. It's often "driven as much by trust as the technical capabilities," says Overhage at the Indiana HIE, which uses a federated approach.

"Healthcare providers need to see the value in what they're paying for." - Micky Tripathi, Massachusetts eHealth Collaborative

How Docs View Data: The Portal Problem

Getting data in front of doctors and other clinicians is one of the biggest challenges HIEs face. Ideally, it would be delivered directly to a providers' EMR system, so when a patient goes to an outside lab for blood tests, the results would show up in the electronic record at the doctor's office, and the doctor would be notified that the results are there. However, with limited EMR use across the country, HIEs have had to provide alternative delivery methods.

The Indiana HIE, for instance, tries "to meet clinicians wherever they are with their technological capability," Overhage says. Physicians who have EMRs can have results pushed directly to their systems. If an EMR isn't compatible or if doctors don't have systems, they can use a Web portal to see data. Doctors can also get a summary of patient information printed out in their offices. "If they can print out the information the night before a patient visit, it's better than not having the information at all," Overhage says.

A survey of 100 HIEs this year by KLAS found 71% of clinicians view data about their patients using a Web portal into a centralized site. That data can include results from recent tests such as CAT scans and blood work, diagnoses from other doctors patients have seen, and medication prescribed by those doctors.

The problem with portals is that they force doctors to take an extra step to view data--to remember to check the portal for new information every time they're about to treat a patient, says KLAS's Hess. Doctors often end up using the HIE less as a result, and some provider groups decide the exchange isn't worth the investment if their clinicians aren't using it.

The Interface Expense

An alternative for viewing data, one that fits into most doctors' workflow, is to send data directly to patients' EMRs. But that requires physicians have an EMR system, and for it to be integrated with the systems of other providers and facilities participating in the exchange.

HIE software can link an EMR system into an exchange so it can locate and access patient data from, say, a hospital lab, but that data might not be viewable or readable in the provider's system without building an additional interface between that specific EMR and the lab's system.

A doctor's practice that spends as much as $80,000 installing an EMR system expects that patient data from labs and other sources will interface with the system--"like buying a new car and expecting it to start when you turn the key," says Redwood MedNet's Ross. But that's not always the case with health data interoperability. There ends up being a lot of finger-pointing among providers, labs, vendors, and others when data isn't deliverable or readable, he says.

In some cases, the HIE or the EMR vendor already may have developed the needed interface. In other situations, either the doctors' practice or the HIE must build the interface. Building an interface requires skilled developers, and it can cost thousands of dollars for a vendor or other third party to do the job.

It can easily cost $20,000 or more to build all the interfaces a practice's EMR system needs to participate in an HIE, says KLAS's Hess. Larger, more sophisticated healthcare companies need as many as 100 interfaces to get all their different systems integrated with an HIE, says Overhage. In the HIE world, there are no hard rules or best practices as to who's responsible for building or paying for interfaces; it's usually negotiated between the HIE and the healthcare provider, and depends on who has the resources to do the job.

Indiana's HIE provides participants with five basic data sets, including laboratory, radiology and EKG results; transcribed reports; and admission, discharge, and transfer information from hospitals. Who builds the interfaces a particular healthcare provider needs to access these data sets depends on how many interfaces the provider needs and what resources they have available, Overhage says.

Redwood MedNet helps its 140 participating physicians troubleshoot any problems that arise. If there are interface conflicts with an EMR system not accepting data from a particular lab, for instance, the exchange might supply an interface it already has on hand that will work, or it will build a new one.

The set-up fees a healthcare provider pays to get hooked into Redwood MedNet can range from a couple of thousand dollars to as much as $50,000, depending on the provider's size, what interfaces it needs, and other factors, Ross says. The exchange helps participants find government and private grants to cover those costs. Often a hospital's philanthropic organization will help pay the costs of area providers plugging into the exchange.

Ideally, EMR and other clinical systems would have built-in interfaces to most of the healthcare systems they would need to link to. But "vendors don't have a large incentive to get their systems talking to each other," Ross says. "The state of healthcare software is like the Internet 15 years ago. Back then you could have an AOL account, but you couldn't send or get messages from a user of Prodigy or CompuServe."

Many standards are available to facilitate healthcare data sharing, but that's part of the problem: There are too many, according to Ross. Data-sharing standards need to be "tightened up" so they're more concise and reusable, Ross says. Right now, many labs pick and choose which standards they support, he notes, making this the "era of custom interfaces."

The Health Information Technology Standards Panel is a five-year-old, public-private effort, launched under a contract with the U.S. Department of Health and Human Services to "harmonize and integrate" health data-sharing standards. The panel has done good work, Ross says, but industry-wide adoption and agreement on common standards are still needed.

The interface and interoperability issue is expected to be less of a problem in the future as EMR vendors start developing products with data sharing in mind, says Bob Steffel, CEO of HealthBridge, a 13-year-old HIE that covers a 50-mile area in Cincinnati. Most legacy clinical systems were built assuming that patient data would only be shared inside an organization, but that vision is changing. Now, the possibility of HIE-enabled EMRs "is very exciting," Steffel says. No one has done it yet, he notes, but HealthBridge hopes to start working on them with vendors.

Security And Privacy Requirements

Most healthcare providers are already well versed in what's required to adequately secure patient data and ensure privacy, from years of complying with HIPAA. However, HIE participation opens new security and privacy questions. Will data be shared only with appropriate personnel within the exchange? Will data be safe from outsiders' eyes? Are the systems flexible enough to give patients say over who can see their data?

The HITECH Act, part of the American Recovery and Reinvestment Act of 2009, has increased the penalties healthcare providers face if their systems are breached. Maximum annual penalties for violations can reach $1.5 million, up from $25,000 previously.

When it comes to security, HIE systems tend to have much of what's needed, such as patient identity, matching index, and user authentication technologies. Efforts such as the government's Connect project also provide guidelines for securing HIEs. "The technology is there or almost there," says Jennifer Covich Bordenick, CEO of the eHealth Initiative, which works to use IT to improve healthcare. What's missing are clear guidelines about information and data-sharing policies, she says.

With closed health systems, such as Geisinger Health and Kaiser Permanente, everyone is on the same system and working for the same organization, so security and privacy challenges are reduced. But once you start connecting different healthcare groups, it gets complicated, she says.

Privacy policies can be particularly hard for an HIE to deal with. Can the HIE system let patients opt in or out of having their data exchanged, or let one doctor but not another see certain data? "The question is how much granularity will be allowed and can the solution implemented map back to that?" says IDC analyst Lynne Dunbrack.

Privacy laws vary from state to state, complicating things even more for cross-state HIEs. Also, giving patients access to their own data via a personal health record is difficult for HIEs because of security considerations and also because it might cause doctors to censor what they write.

Most HIE products can ensure patient privacy for structured data, such as lab results, says Ross, but adding those capabilities across an exchange can be expensive. Also, products don't provide that capability yet for unstructured data, including doctors' notes and images such as radiology studies. "Those are technological gaps," Ross says. The hope is that work under way with natural language processing tools will address the unstructured data problem.

Redwood MedNet has avoided thorny security and privacy issues by only making data available electronically that was previously shared via paper and faxes, such as lab reports, Ross says.

But limiting the scope of an HIE is only a short-term answer to these security and privacy concerns, as well as to the many other technological challenges exchanges face. Longer term, much depends on the current set of HIEs maturing to the point where they can establish an accepted set of best practices and reusable models. That, in conjunction with vendors providing more interoperable products and the industry agreeing on a set of common standards, will lead to the creation of secure information exchanges that doctors and other healthcare providers want to use and are willing to pay for.