Gartner Blog Network

NHIN Direct and Strange Bedfellows

by Wes Rishel  |  June 13, 2010  |  11 Comments

Sean Nolan’s blog highlights that NHIN Direct has stumbled on a “tough” decision. We didn’t come to agreement on the backbone protocol despite an absolutely outstanding process for increasing understanding as opposed to so many meetings where the opposite of speaking usually is not “listening” but “waiting to speak.” Sean characterized the split in the group as being between “big vendors” and “small vendors.” (Ironically, Microsoft is aligned with the “small vendor” axis because its interest is in enabling the hyper-evolution of new approaches that has been characteristic of the Internet in other industries – my words, not Sean’s.)

Writing separately, Arien Malec (the NHIN coordinator) has characterized the split as between EHR vendors and others, rather than Sean’s big vs. small categorization. It is hard to tell the difference because only large EHR vendors have the resources to put into big group processes like NHIN Direct has become.

Sean and Arien are lumpers and I’m a splitter. If you look at the assumptions that are driving the participation I saw nine different points of view:

  • A better way to make standards. The lesson taken from testimony at the HIT Standards Committee was that assembling a small group of players with a common vision, strong leadership and a plan for early implementation works better than the more ponderous “design by ballot box” approaches of large standards efforts. “Rough consensus and move to code; intermingle completing the consensus with writing code.” A consequence of this approach is that the work product will be judged later by whatever consensus process is necessary to adopt it as a standard; the work product is not preordained to get that far.
  • Discard and start again: the EHR market is basically broken and needs to be replaced by products that great innovators could produce if they weren’t constrained by a regulatory process and standards process that is way too willing to embrace complexity. NHIN Direct must lay the groundwork for this.
  • The Long View: the primary goal of NHIN Direct is to start a long term process of incremental architecture towards enabling the business innovation. Increment number one should be “messaging” across EHRs and non-EHR users, but that is only a start. The approach must enable future growth of the security infrastructure and the behaviors that can be enabled among participants that go way beyond simple delivery of messages.
  • The RESTful Long View: everything that that long-view guy said plus a commitment to the ultimate architecture being RESTful.
  • Top-downism the path for health information exchange has been set down by the grant program. Without such an organized approach attempts to interoperate are doomed to failure. NHIN Direct should be limited to those areas that can help the master plan succeed, but it should not create an alternative path to interoperability.
  • Minimal Value: EHRs are at least adequate to meet the needs of improving healthcare. The basic problems of interoperability have been solved by IHE, the HIE grants and prior NHIN work. The only reason for NHIN Direct is to get hospitals connected to EHRs owned by community physicians faster than can be accomplished by standing up HIEs.
  • Deadline Fatalism(1): the rules of the game are set by the ARRA; this effort is only useful if it allows are clients to more quickly achieve EHR-to-EHR communication in order to qualify for incentives earlier.
  • Deadline Fatalism (2): like #1 but it also includes supporting hospitals in communicating with physicians who do not have EHRs that qualify for incentives. This will be important for transitions of care and potentially for meaningful use requirements in Stage 2 or Stage 3.
  • There’s gotta be something better, sooner. The vision of nearly universal EHRs communicating through a ubiquitous set of HIEs that are interconnected via the NHIN too far in the future. These folks want to see something a little better than the fax machine as soon as possible. They will be happy if it helps compliance with meaningful use, but the requirement is much more basic and the impact more profound than simply helping to earn incentive money.

The size and diversity of the NHIN Direct is making it more difficult to hold to the “better way to make standards” view.  We have become a group of strange bedfellows where the strangeness is stronger than the fellowship.

The size of the group is partly a result of the attention it has received from ONC. Otherwise, we wouldn’t see the “top downists” and the “limited value” folks who basically believe that the main challenge is to execute on an established direction.  Many believe that the outcome of the NHIN Direct group is automatically destined to be a standard recognized in federal  regulations. ONC has said the opposite but they haven’t been heard or understood.

If those that don’t believe NHIN Direct is mission critical fall way, would any of the established EHR vendors continue to participate? If so, it would be because they fall into the “Deadline Fatalism (2)” or “There’s gotta be something better, sooner” categories.

To their credit the HIT vendors have come a long way in offering to adapt the IHE standards that are used in NHIN Exchange. They have offered a “pure push” approach. They have offered to remove any protected health information from the unencrypted portions of the messages available to HISPs.  The main sticking point seems to be whether the secure backbone protocol is SOAP, WS-* security, supported by the interface discovery capability in UDDI.

Unfortunately, the RESTful Web services movement was founded as a reaction against some of the assumptions inherent in the SOAP/WS-*/UDDI approach. RESTful Web services is a different approach for dealing with complexity. There is substantial justification for this but, but the basic notions of how to design  RESTful Web services is still evolving. The team working on NHIN Direct didn’t get beyond some very simple test code and didn’t demonstrate the deeper values of the RESTful  approach. I personally think those values can be achieved but this will take much longer than the REST advocates believe.

(This debate about RESTful vs traditional Web services sounds a bit like the Astronomy society deciding whether Pluto is a planet. But it is more like cosmologists arguing a theorem. The outcome can profoundly shape future directions.)

Frankly, there is not enough evidence in the world to put to bed the argument about whether the WS-* approach is good enough or better, or whether RESTful Web services  is the way to go. Absent evidence people will back their instincts and their instincts will be guided by their experience (they work they have already done), the amount that they will have to work to adopt a new approach and which of the nine points of view (above) they have.

If it goes to an approach of achieving decisions that are not consenuses (e.g., simply voting) then the process becomes one of which side can muster the most votes. One of the factors that shaped this effort was complaints about the HITSP experience wherein a number of participants felt steam-rollered by a few that they perceived to be an organized bloc with a particular agenda. I am not endorsing this view, just pointing out that thoughts like this are the inevitable outcome of a decision process that is not a true consensus process .

A Path Forward
I have rewritten this blog several times now. The trend has been from trying to find a path to reconciliation towards trying to have purposeful “disreconcilation.” Instead of having the group make a decision the decision is going to make the group.

The group must be reduced to a working size of folks can roll forward enthusiastically instead of feeling put upon because this is a diversion from their important work. So I would urge those who really think that NHIN Direct is unnecessary or unimportant to drop out. We can arrange for better communication beyond the group on what is going on than we have achieved so far, so those folks shouldn’t feel that they lose their insight into what is going on by dropping out. If you like what you see or find more industry acceptance than you imagine, we are doing everything we can to make it easy to get back in again later.

Among the members who do feel that the NHIN Direct idea is needed, we need to split into two or three groups. There still may be a substantial group that supports SOAP+UDDI for the backbone. If so, they should be a group with whatever governance they favor and their own process for getting to a working body of open source code and unfettered, comprehensible specifications. Perhaps IHE would like to host this effort since it so strongly builds on existing IHE work products.

Those that support “RESTful but maybe SMTP” or “SMTP but maybe RESTful” may become one or two groups according to whether they have enough appreciation of the combination of short-term and long-term views to have enthusiastic agreement. If this is one group it should favor an initial implementation using SMTP with a security infrastructure that will also support REST. It should look for another opportunity to use REST for a behavior that is different than pushing packaged messages around.

The deciding rule for forming groups should be to establish the minimum number of groups where the members of the group can work enthusiastically rather than feeling dragged along against their better judgment or when other work is more important.

With one or two smaller groups we can get back to proof by code rather than design by the ballot box.

This not ideal. Maybe all the groups will fail. Maybe they each will continue to split until there is no critical mass. Maybe they’ll all succeed and we’ll have “many standards to choose from.” Those would all be bad outcomes. But the current path is not tenable and the most likely path is that one of the two or three groups will be better able to prove their approach in the next few months and will end up with a strong enough case that others join in.

Isn’t that how the Internet was built?

(Last revision 13 June 2010 10:25 pm EDT)

Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research

Category: healthcare-providers  interoperability  vertical-industries  

Tags: arra  ehr  health-information-exchange  health-it  healthcare-interoperability  hie  meaningful-use  nhin  nhin-direct  restful-web-services  simple-interop  uddi  

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

Thoughts on NHIN Direct and Strange Bedfellows

  1. Will Ross says:

    Wes, great suggestions. As one of the small open source interoperability shops in the hinterlands (i.e, Mendocino County) that lacks the time, bandwidth or budget for endless top down committee-ism such as NHIN Direct is falling victim to, I note that the “Simple Interop” process has been gamed. As such, while I plan to pay attention to the discussion the best I can given my bandwidth constraints, I think we are now at a lesser of evils fork. I believe it is now necessary to get down into small teams that can build stuff that works in the real world. Btw, it is really fascinating to be on the same side as Microsoft defending the (let’s be clear) majority of the market that has yet to see a compelling software solution for interoperability. And I still like XMPP the best.

    With best regards,


  2. […] Article Wes Rishel, Gartner, 13 June 2010 SHARETHIS.addEntry({ title: "NHIN Direct and Strange Bedfellows", url: "" }); […]

  3. Wes,

    Interesting observations, as always.

    Back in the early 1950s a group of AT&T folks were tasked with conceptually reinventing the phone system. That session lead to a stream of innovations such as touch-tone phones, long-distance dialing, high-speed (T1 and above) lines, and solid-state switches. The underlying network and its bits & pieces were, and still very much are, much more complex that the prior electro-mechanical switches and human operator system.

    The first people to use (and help refine) the new systems were the human telephone operators who were trained and observed. We also saw the emergence of phone hackers with their blue boxes, taking advantage of holes in the new system’s architecture. Much was learned from these early user populations. And some lessons were forced, such as the emergence of customer-supplied and -installed phones after some court fights to break the phone device monopoly.

    Fast forward… Now we can call long-distance and internationally without operator assistance, and the calls are less expensive in absolute dollars than they were 50 years ago. Domestic distance and time based billing is now replaced by connectivity-based fees.

    But the user interface stayed simple, except for the addition of area codes and numeric-only telephone numbers.

    Stretching the analogy only a bit, we now have cellular phones with all kinds of add-on features. We also have the simple “Jitterbug” models, targeted at those who want plain-old-telephone-service simplicity. Both use the same underlying complex network.

    I think we can achieve the same results for the NHIN, for all users. Let’s focus our collective energies on user simplicity and usability, not the complexities of the underlying network and protocols.

  4. Rich Elmore says:

    Wes –

    Thanks for your post. We both heard a lot more agreement than disagreement in the NHIN Direct meeting.

    o Each concrete implementation team said they could support multiple edge protocols for secure email, clinical workflows, and innovative system to system communication.

    o Each EHR vendor said that they would support whichever backbone protocol was selected.

    An XDR backbone may have simplified support for the hospital and practice IT staffs that manage EHR connectivity. If a different backbone protocol is selected, perhaps the HISP concept should be extended to include standard extensions for protocol step-up/step-down.

    I’m optimistic that there is still a path to agreement. We should try to avoid falling victim to the old adage that the “great thing about standards is that there are so many of them”.


  5. Jeff Brandt says:

    Whatever protocol we come up with will be outdated as soon as it gets started. (e.g., HL7). In engineering practices we start with the requirements. The phone system as mention above did not mandate protocol but requirements. At least at first, then the protocol. Why not multiple protocols, OSI layer 7 that is. Companies will build gateway to support conversions.

    NHIN attempted to develop a top down approach with is very difficult to get by-in and one of the longest paths to implementation. I prefer the bottom up approach, HIO to HIO and up from there.

    States are out there already moving forward with their own idea’s. Oregon is speaking to the Northwest states about connectivity. It would be great if you started with simple guideline such as CCR and CCD and security mandates.

    One of the biggest problems that I see is the Privacy and consent issues. This will be the “tough” one to move data across state boundries.

    Jeff Brandt

  6. We should not worry about the complexities of the underlying networks and protocols, so we can have the same monopolies as we saw in the telecommunications industry.

  7. Wes Rishel says:

    Thanks, Steve. I think this comment is intended to be ironic, but I don’t quite understand the context. Could you amplify just a little?

  8. Wes,

    Yes it was intended to be ironic. My point is that not only must the NHIN-Direct solution be easy for the user; it must also be “easy” for businesses to stand up a HISP. This allows for multiple organizations to compete for users. This will decrease the cost to the user and continue to drive innovation, while help retard monopolies from forming.

  9. […] by admin on Jun.16, 2010, under Uncategorized Interesting discussions in the standards committees regarding how issues regarding security and privacy can be approached. Even more interesting discussions in the blogosphere regarding HNIN Direct. […]

  10. Anand Shroff says:

    Wes – are you detecting a split between EMR vendors and HIE vendors? From where I sit, the HIE vendors should be fairly neutral about what gets picked, as long as there is a single standard and not multiple \standards\. It is fairly easy for HIE vendors to implement IHE/SOAP (most of us have done that already) and SMTP/REST.

    I suspect that the real pushback might be coming from the EMR vendors, who have recently started adopting IHE based integration and from what I have seen, they are beginning to see incremental results from substantial efforts. Their fear may be that a change in fundamental standards (from SOAP to REST) may obviate their current investment and will instead require them to refocus on building to new specs. Their core competency is clinical EMR development, not interoperability and therefore this is an acquired taste at best.

    Secondly, there is a concern in some corners that NHIN Direct sets too low a bar and as a result undermines the Meaningful Use effort and the REC funds that are supposed to foster broader and more meaningful EMR adoption. A \mailbox\ type solution that is built using NHIN Direct principles and without a roadmap to getting to the level 1 Meaningful Use criteria can dilute those efforts.

    We are not certain about how to address that concern. I know that this issue came up at the Seattle face-to-face meeting, but didn’t seem to have been resolved to a level that can be messaged to the community as a whole.

  11. Wes Rishel says:

    Good question. The answer may surprise you. I replied in a new blog posting.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.