Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Coverage Areas:

NHIN Direct v. HIEs: Competitors or Collaborators

by Wes Rishel  |  March 14, 2010  |  12 Comments

Recently a person organizing a state’s HIE effort reported a hospital CIO saying, “why do I need your complex HIE when can have NHIN Direct?

This question gets to the heart of the confusion that some states or stated designated entities are experiencing with the introduction of NHIN Direct into the mix. I wrote this fellow back, outlining the relative value propositions of HIEs and NHIN Direct. It is clear that the two notions are complimentary even if there is still some need to work out the rough edges. Here is what I wrote.

The hospital that is evaluating its need to participate in a state HIE needs to answer the following questions.

How long will the hospital and community physicians be satisfied with the following assumptions that will probably be baked into NHIN Direct:

  • We will be sending information but not offering clinicians the opportunity to look up a patient and retrieve their information.
  • We will be sending the information to a practice without sending the practice’s patient ID number
  • We will send out structured lab information from our lab using standard LOINC codes
  • We will independently determine whether it is appropriate to send each transmission to a specific provider.
  • We will send all information with only a very general usage agreement in place.
  • We will accept inbound information without our patient ID so each such input will have to be matched by the receiver.
  • We will accept information without assurance as to whether coded information is standard.

Most of the hospital CIOs that I talk to say, “I’d be happy to live with those restrictions in order to get started reaching out to physicians in my community sooner. I know that practices that I send info to would be willing to live with them as well.”

This is a fair trade-off. However, it provides clear limits in supporting care transitions in that the sender has to know to whom the patient is transitioning – or the receiver has to make a special request for information that must be manually approved by the sender.

Furthermore, it is unlikely that community physicians will remain satisfied with this approach if an HIE is available that supports both the hospital and the practice or if HIEs are linked in a way to provide the connection.

The value that HIEs typically add include

  • Maintaining a common patient index
  • Providing the trust mechanism, software interfaces. access control and consent mechanism that enables lookup up information
  • Developing a common trust agreement that all parties can accept.
  • An interface to consumer advocates that will assert their role protecting the interests of the patients.
  • A common software channel and active support to enable multiple data sources (e.g., labs and hospitals) to send results to multiple recipients and provide both senders and receivers a single point of contact for troubleshooting.
  • Mapping imprecise recipients data (e.g., taking a physician name as the recipient of the lab result and determining whether to deliver the result by fax, on-line lookup or structured transmission to the EMR).
  • Aggregating data at a community or state level for measuring quality, epidemiology, and other programs.

The only thing that an HIE has to do to compete with NHIN Direct-based communications is exist.

How, then should an HIE deal with the fact that by the time it comes to an operational state a great deal of communication may be going on under NHIN Direct? Easy: join it instead of fighting it. Be prepared to bring practices that are already using NHIN Direct into the fold without having to immediately change what they do. Add immediate value by forwarding patient results and notes with the practice’s patient ID. Provide shims for labs that cannot get to standard approaches. Allow them to begin to look up patients (using new interfaces) as soon as their EHR is ready. Allow them to use a portal to look up patients and have the results sent to them through NHIN Direct.

To really seize the initiative the HIE should become a provider of NHIN Direct services to physicians that don’t yet have an EHR or have an EHR that is not yet capable of dealing with NHIN direct. Operators of such a portal are in an ideal state to gradually introduce services that add value as soon as they can make the software and business agreement arrangements.

12 Comments »

Category: Interoperability Vertical Industries     Tags: , , , , , , ,

12 responses so far ↓

  • 1 Brett Peterson   March 15, 2010 at 12:27 pm

    Very interesting post.

    One of the benefits of participation in NHINdirect.org for HIEs and others (aside from the obvious ability to help shape the outcome) will be a fundamentally correct understanding of the resulting standards, services, and policies. This understanding will help an HIE (or any other organization) see how NHIN Direct could be an opportunity (for extending provider outreach) rather than a threat.

    The same argument can be made for providers themselves. Taking the time to provide opinions on NHINdirect.org (especially in the context of User Stories) would be immensely useful to the effort and might help providers better understand how some of their needs could be met.

    Brett

  • 2 Anand Shroff   March 15, 2010 at 3:42 pm

    Wes,

    I couldn’t agree more. By agreeing to a standard communication/transport mechanism, HIEs can focus on providing value added services based on the data that is flowing through a connected community rather than spend a majority of their effort on interfacing and connections. Providing value-added services will also further their drive towards sustainability.

    Thanks,
    -Anand

  • 3 Mark Frisse   March 15, 2010 at 4:32 pm

    Wes,

    Thanks for helping differentiate these two complementary but distinct notions. Organizations supporting more exchange than simple NHIN protocols have the opportunity to create a deeper set of relationships. Some of these organizations will be bounded by geography and some will not. Some, I suspect, will be affinity groups using common vendors. Others may be data publishers (plans, pharmacies, aggregators). If we’ve learned anything from the few HIEs that are really robust, it’s that the forms of exchange practiced by these “non-traditional RHIOs” don’t go away when a geographic HIE or RHIO comes into being. So these various entities can and will co-exist. It’s an “AND” and not an “OR,” More affinity groups will sprout up so the number of disjuncts will grow for awhile. The NHIN CONNECT specifications will help bring them together.

    As always, you said it better than I could.

    Thanks
    - Mark

  • 4 Mark Frisse   March 15, 2010 at 4:36 pm

    Wes,

    I am reminded of the early days of Phase I NHIN (that you nicely summarized in a report some years back). I was talking about the fully functional Exchange Vanderbilt created for the greater Nashville area. Someone said why do you need to do that when we’re going to all be connected by NHIN in a year?

    That was quite a few years ago. Another reason to pursue both of the courses you describe is that change comes slowly and there are a lot of issues we have to discover and work out.

    Again,
    - Mark

  • 5 R. Dirk Stanley, MD, MPH   March 15, 2010 at 5:06 pm

    It is projects like this that encourage me about speakflower.org – (http://www.speakflower.org) – Developing a truly national way of exchanging meaningful data deserves all the support it can get, and I think if we build it, patients will come.

  • 6 Arien Malec   March 15, 2010 at 7:52 pm

    Wes — This is good food for thought. I’ve added some contextual thoughts in an extended culinary metaphor here: http://blog.nhindirect.org/2010/03/cakes-bakeries-and-recipes.html Bon appetit.

    Arien

  • 7 David McCallie   March 15, 2010 at 11:20 pm

    Wes,

    Good post. I want to offer one additional possible reason for the existence of NHIN-Direct in addition to (or in preparation for) a more full-featured HIE.

    Privacy.

    OK, loaded term, but I propose that sending secure direct messages that do not create any intermediary side-effects (like being added to a registry, or processed for value-add services) will appeal to many providers and to their patients who do not feel the need (or want) to share their health data any more broadly than the direct message causes.

    A key advantage of the direct-message approach is that it fits already well-understood privacy and consent processes (HIPAA TP&A.) More robust HIE-like registry/repository approaches require us to extend HIPAA to new models — models which are not yet well-understood, and not yet trusted by all people.

    I’ll make a crude analogy — We all started sharing our data over the internet by using email. When we wanted to share with more than one person, we used mailing lists, etc. Then along came Facebook and we found a new way to share — by pooling data on our “wall” and allowing selected friends to read it. However, the emergence (and power) of FB did not remove the need for private, direct emails.

    Here’s where my analogy breaks down a bit, but I see HIE as being similar to a (secured) FB, and NHIN-Direct being like (secure) email.

    Both can exist, but we _must_ have private messaging.

    And a second, off topic, point — There’s no reason why NHIN Direct couldn’t target the HIE (or a PHR) as the end point. If the provider or patient wants to share the data widely, then send it to the HIE via a direct push to the sharing service. On the other hand, if the patient wants his or her data to be shared only via their PHR, then they simply ask the provider to push the data to the PHR instead of the other alternatives. (This assumes that the patient has some kind of choice as to where her data is reposited and shared.)

  • 8 Art Glasgow   March 16, 2010 at 3:18 pm

    Wes,

    Great perspective and I agree, the two should be collaborators instead of competitors. When you consider future use cases of potentially aggregating data for purposes other than pure exchange (EBM, health analytics, public health), there is an advantage to having exchanges and stores at various “levels”. They must work together though so they are additive to each other rather than duplicative.

  • 9 Dave Perry   March 16, 2010 at 4:14 pm

    I agree that HIE networks and NHIN direct are both valuable. It makes sense that electronic exchange of data needs to occur to meet meaningful use and not all communities will have HIEs in time.

    In my opinion, if a community has access to an HIE they would get no benefit from NHIN Direct. However, the comments contained in this blog seem to indicate that it would be practical for both services to coexist.

    Can any of you provide specific examples of the need for NHIN Direct where an HIE already exists?

  • 10 Anand Shroff   March 17, 2010 at 12:35 am

    Dave,

    One example could be transitions of care across MTAs. An HIE typically operates within an MTA.

    Thanks,
    -Anand

  • 11 John Moehrke   March 17, 2010 at 10:13 pm

    Well said. I am involved for the very reasons you outline. I think there are ways to leverage NHIN-Direct to start with the use-cases it intends, while offering a stepping stone to HIE. These stepping stones can be a way to make progress without having to make major changes. Ultimately most will use the native NHIN standards, some will be happy with the stepping stone.

    I like the constrained usecases of the NHIN-Direct. They are far more realistic, actionable, with a clear return-on-investment. They are also less radical changes to the workflow. These are all good things.

    The likely stepping stones will leverage capabilities already built into EHRs today. Fact is there may be multiple options for these stepping stones to support a small number of architectures. Surely there will be a HTTP-POST (RESTful) approach. And I welcome them all.

    I fully expect that FHA-CONNECT will be an implementation of these stepping stones. It already is trying to fill this need. I hope others step forward as well.

  • 12 Will Ross   March 20, 2010 at 2:33 pm

    Dave, without identifying the guilty I know a State HIE (not yours) that asks for a one time $25k charge plus $30k/year as the participation fee for a small critical access hospital. For a competent small hospital IT shop this compares to a one time $30k charge plus $6k/year for the same size facility to launch their own “non-State” HIE by using the CONNECT + NHIN Direct combination. Taking this to the next level, ten small hospitals could easily share the same CONNECT gateway, a bottom up approach with sufficiently compelling financial leverage to disintermediate unnecessarily expensive State HIE business models.

    Wes, the missing piece of this discussion is that we need 1 NHIN, not 50 SHINs. From my perspective (a non-State HIE) the State HIEs are the answer to the wrong question. I want to see health data become agile, not trapped in new Statewide silos. What I like about NHIN Direct is that it is asking the “1 NHIN” question, and that it places no bureaucratic barriers on participation. I expect great things from NHIN Direct, even if it only exists to force top-heavy projects to become more agile and relevant to thinly resourced small healthcare facilities.