Building — But Not Overbuilding — Next Gen HIEs

Today I’m delighted to bring you some thoughts from Micky Tripathi, founding president and CEO of the Massachusetts eHealth Collaborative.  In a write-up for the useful blog, Tripathi argues that the HIT world is in danger of seriously overbuilding the next generation of HIEs.

As he notes, a generation of private HIEs (known as CHINs at the time) failed or struggled in the early to mid-1990s. He also reminds us that the failures — such as the demise of Tennessee’s CareSpark and the Minnesota Health Information Exchange — are far from over. In his mind, this is mostly because these groups tried to create over-architected HIEs.

Now, we’re at the heart of the matter. What is an over-architected HIE?  I’ll let Tripathi speak:

Put simply, it’s one that tries to do too much for too many with not enough money and time. It tries to establish an all-encompassing infrastructure and service to meet multiple, heterogeneous current and future requirements of multiple, heterogeneous current and future customers. It tries to do all of this with a shoestring budget and staff. And worst of all, it focuses more on long-term potential “big-bang” value at the expense of short-term, realizable, incremental value. Or as one HIE organization’s promotional material put it, the value proposition is to be a “one-stop shop for Clinical and Administrative Information.”  (Editor’s note: They actually made that claim? Wow.)

What’s wrong with trying to build a Holy Grail of HIEs that solves everyone’s problems?  His analysis:

1.   HIEs can only develop so fast no matter how much money and people you throw at them, given that moving clinical documents around, searching and retrieving clinical info and getting everything into a big database requires a lot of manual labor, legal and technical judgement, cultural and clinical change.

2. While HIEs can only move so fast, business and technology can move at breathtaking speed. Building out an infrastructure which is supposed to work five years from now may turn out to be a massive waste of resources. As he points out, remember that the game-changing iPad is only two years old.

3. CIOs are, let us say, a little overwhelmed at the moment. Asking them to build out a huge infrastructure for the HIE doesn’t exactly make things better. “Better to proceed with achievable steps that deliver incremental value along the way,” he says.

Well, all I can say is that I agree with him completely. Incremental moves and technologies like the Direct Project seem infinitely smarter than a “Big Bang” approach. HIEs are going to be part of our future like it or not, for many reasons, so why not get it right a little bit at a time?

About the author

Anne Zieger

Anne Zieger

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.


  • “so why not get it right a little bit at a time?”

    Because the HHS needs to spend big money now so it can reward its big donors before it gets booted out of office.

  • I’m not sure what others want. But what I’d like to see is simple. I’m going in for an operation. I want the hospital to get a copy – easily and quickly, of recent health exams that might impact my surgery. I’m getting an ecg, chest xray and some blood tests. Want those to get transmitted to my PCP and to the hospital as appropriate. Post surgery, I want a report to go back to the appropriate doctors.

    Or; I’m at hospital A today for an MRI and other tests/imaging. Weeks later, I have an emergency visit to another hospital. I need my ER to be able to see my images from that other hospital – while I’m still in the ER. I don’t want repeat inaging; in fact, it’s the ‘base’ image that’s important.

    This is not about sharing everything with everyone, but being able, on demand or by required push, to have or get my data where needed when needed. Hospital A reaches out to B, or to Doctor C. This is not fancy. This is just about having a standardized request protocol and matching response protocol. It does not need to be over thought or over done.

Click here to post a comment