Where are the roadblocks to true HIE?

Much of the vision of how the nation’s healthcare system should ideally function, once moved from its paper-based legacy onto an electronic platform, involves the sharing of clinical information between different places and systems. After all, a given patient typically sees about 19 different physicians in a lifetime – which means that an individual’s health story is fragmented across a diverse landscape.

Getting information from where it is housed to where it is needed is the next big challenge of health IT. The first step along the way was to encourage physicians to replace paper with computers – Stage 1 Meaningful Use was focused on that. The thrust of this first step of transition was getting clinicians used to having computer screens, rather than paper, in front of their eyes all day long, and the workflow challenges were all about making that shift.

The next phase of health IT’s evolution is connecting the pieces together. Simply replacing paper charts with locally-housed databases does not change the general landscape of distribution of health information very much. But it allows the possibility of linking systems together, so that the needed health data can flow easily between all those different places.

Nice idea, but the devil is in the details
That is a nice vision, when seen with broad brushstrokes. As a result of some of the Stage 1 Meaningful Use criteria, different systems need to be able to create and consume certain standard kinds of summary records – Continuity of Care Records (CCRs) and Continuity of Care Documents (CCDs). But if, for example, a hospital’s system can create a CCD, where does it go? How does it get to the ambulatory clinician’s office/system? Is there a more sophisticated pathway than traditional faxing?

The questions may seem simple, but they present some significant challenges. There are technical challenges, and (more importantly) there are economic and medico-political challenges – in fact, the medico-political challenges are much more of an impediment than the technical ones.

In order to get a better grasp on the issues involved, it might help to focus on the exchange of information between the local hospital and community physicians. We are farther along the integration pathway when it comes to connecting e-prescribing with local pharmacies (e.g. through Surescripts integration), and also with commercial reference-laboratory integrations (e.g. LabCorp, Quest, and regional labs through their aggregators such as Atlas). But connecting doctors with their local hospitals is a more vexing feat.

What kinds of data need to go back and forth between community physicians and their local hospitals? Upon a closer look, the needs are asymmetric – the hospital needs chart elements, or even the whole chart, from the community docs; whereas the local doc needs only a handful of critical documents from the hospital: (1) medical records documents (admitting H&Ps, Consults, Surgery and other Procedure Notes, Discharge Summaries, Emergency Department summaries), (2) x-ray and imaging reports, and (3) lab test results.

Different tools are appropriate for each need
For a hospital to get information out to community docs, it is a simple document push (assuming that the recipient clinician has been identified), or a pull from the doc’s office. Traditionally, this has been via fax.

Some more sophisticated point-to-point connection might be best suited here. Perhaps implementing the Direct Project would be a way of getting these data elements out – if interfaces can be built that are as easy and familiar to use as a fax system, and if installation of such a system can be equally low-cost as spending staff time and equipment faxing that data (which is the default cost for comparison), then that might be a quick-and-easy solution. Of course, the recipient doc’s system needs to be able to import the documents that are sent over, but .PDF document file upload and insertion into a patient’s chart is a nearly-ubiquitous feature to most all ambulatory EHRs.

A certain amount of manual reconciliation at the community-doc’s end is implied here, to get the information received into the right place, but that is a step easier than reconciling faxes. Medication reconciliation between hospital or Emergency Department discharge documents and the medication list in the local doc’s EHR is a step that can be facilitated by a well-designed EHR (though it likely won’t be automated for some time).

The other direction
Getting information to flow in the other direction is better accomplished with a different approach. Instead of sharing specific documents, or exporting a CCR or CCD and sending it (somehow) to the hospital, it might be best to simply share the platform. This can be done via Community-based Chart Sharing, which is an emerging feature of web-based EHR platforms that are widely and easily used.

If, for example, the community doc were using an EHR like Practice Fusion, then several scenarios can be envisioned: (1) if the clinician wants to look up his/her own clinic records from the hospital, to be printed out locally or cut/pasted into a hospital system, then the EHR can be logged into via the web from within the hospital, and the chart seen in its entirety. (2) If someone else (a hospitalist, an Emergency Department physician, or a consultant) needed to see the patient’s office chart, then either (a) that physician can be temporarily made a member of the ambulatory practice, in order to see the patient’s chart like any other member of the ambulatory practice group, or (b) the chart can be shared via Chart Sharing (once it is rolled out in the near future) and the recipient can log in to a new account filled with that one shared chart – after all, a new account on the Practice Fusion platform is free, and can be created in a few minutes.

In any such deployment, the entire ambulatory chart – medication lists, problem lists, allergies, past medical histories, lab values, tests already done, and recent chart notes – can all be made available to the professionals within the hospital who would benefit from that information and deliver better, safer, more efficient care than is the experience otherwise.

Where does that leave traditional HIEs?
Many hospitals are wedded to the notion that traditional “library-style” Health Information Exchanges (HIEs) are the only way that information can be shared between institutions. That means that everyone must be able to create and consume the summary records (CCDs, generally), and safely upload them to some location where the community physician can pull them when needed. In the absence of functional HIEs, a hospital is often looking at the daunting task of creating a custom interface with each of its local community physicians – a prospect that is cost-prohibitive, and results in hospital CIOs saying things like “we can’t create EHR interfaces with anyone else.”

The other option, tied to hospitals that want to consolidate their positions by buying community physician practices, is to believe that HIE can be accomplished by pushing the hospital-based EHR (increasingly, an Epic solution) out onto the purchased-physician practice. Simply including these “preferred” practices within the hospital EHR’s “walled garden” is the conception of HIE from that perspective. But that is not enough interoperability to satisfy the national vision.

The traditional HIE notion, where a separate organization (public utility or private business) acts as a hub for data exchange, is only as successful as the number of subscribers it get (Metcalf’s Law). The fewer the connections, the less valuable it is to everyone. And how are such organizations to stay in business – particularly the ones set up by federal grants, once that grant money runs out?

Will physicians pay a connection fee, like they do (indirectly) for billing services? Not likely – billing service fees are recouped by the fact that such activity directly yields payment; but EHR data exchange does not yield payments, only overhead.

Will hospitals pay for these HIEs? Why should they? It only makes sense if the transaction costs are less than (or similar to) the costs they incur using fax-based information exchange with their community doctors. Further, hospitals have little desire to share their data with other hospitals (who subscribe to the same HIE), as they view other hospitals as “the competitor down the street.” The only data hospitals are willing to share are patient-specific records with the docs either admitting patients to that hospital, or using the hospitals outpatient services. Data analysis is done within the hospital, and there is a financial disincentive to share that data with others – only summary data resulting from internal analysis is shared, and mostly for marketing (“our hospital scores better than the others in cardiac care”).

Conclusions
The biggest barriers to interoperability are economic and medico-political, not technical. We have seen this from practical experience. Hospitals are dis-incentivized to share their data with competitors. Local and regional HIEs will struggle with this fact, and will suffer from low numbers of connections, thus reducing their value as data hubs. HIEs that rely on transaction fees for survival will have a hard time convincing physicians to pay for it, and will have a similarly hard time convincing hospitals that it is worth their while to pay for them too.

That means that, for the next phase of health IT, interoperability will be mainly the push/pull of simple patient-record sharing. Outbound data from hospitals to community physicians will need methods that are as cheap and easy as faxing – this is an opportunity for Direct Project tools. Inbound data from clinicians to those taking care of patients in the hospital will benefit most from full-chart sharing – why not share the whole platform, especially when that platform is free and quick to set up using a simple web browser? This is where efforts like Community-based Chart Sharing will have a notable impact over the next year.

The whole field of health data exchange is a nascent, emerging one. We can expect to see great strides in this area, and there is ample opportunity for innovation in this arena.