Family Health Guy

In which Sean talks about HealthVault and other cool ideas in Personal Health

NHIN Direct: Losing our way; need small business at the table

NHIN Direct: Losing our way; need small business at the table

  • Comments 8

This last week we held two days of face-to-face meetings for NHIN Direct. The goal was very clear: decide on the base technology underlying the simple push messaging system we've been asked to create. We need to do this so that we can move into the implementation phase and deliver value by October. Unfortunately, we did not arrive at a final decision.

But much worse than that, as a group we drifted further and further away from our original charter, slipping into the same business-as-usual, fundamentally flawed approach that has delivered a stunning lack of success over the last decade. The process is now dominated by the same big vendors and organizations that simply cannot see past their current business models and history.

Do I get the irony of taking a position against "big vendors" while using an @microsoft.com address? You bet I do. But this is exactly the problem that is going to make us fail, and it has to be made clear. I found myself unexpectedly emotional trying to plead my case at the meeting yesterday, and have been unable since then to shake my dismay at the risk of losing this incredible opportunity.

Our problem is economics, not technology.

Securely sending a message from point to point is actually an amusingly trivial problem. You can do it with any of a zillion technologies. If that was really the problem on the table, we've wasted a lot of brainpower on this project. But it's not.

The really (really) hard part is identifying which of these options will support the emergence of a scalable, self-sustaining commercial ecosystem, in the short time window we have been given. Or put another way, which approach makes the right people sit up and say, "I can build or grow my business based on that."

To make that assessment, we need to understand who is likely to be providing services to that huge majority of small practices that have, so far, opted out of the EHR market.

The only answer to this is, it'll be the same small-to-mid-size ISPs, SAAS vendors and VARs that these offices work with today for their practice management and other office needs. It is clearly NOT Epic, Cerner, IBM, GE, or some government agency. I'd say it's not Microsoft either, but I'm not quite as sure about that --- we do deliver millions of boxes of Windows and Office to these doctors, and provide many of their non-clinical email services, so we at least have something to start from. Google is in a similar boat as us, with Google Apps and their other productivity products. So put us both in the "maybe" category.

So our job, then, is to identify the package of technology that will:

  1. Solve the technical problem of moving messages around securely;
  2. Be more convenient for doctors than the fax machine;
  3. Provide a credible path from unstructured to structured exchange; and
  4. Be attractive to these ISPs and VARs as a commercially-viable extension to their existing product lines.

If you've ever been part of these small service businesses (and I have, albeit not in healthcare), you know that the key to maintaining your profitability is to be laser-focused on managing operational costs. This generally translates into leveraging your investments in as many different ways as you can. Training and paying staff to administer systems and help customers is expensive. Billing management is complicated and expensive. Being sure that you can host the maximum number of customers on one physical piece of hardware is really important. And so on.

My big mistake

I thought we all got this as part of first principles. Oops.

Because I thought this was a given, I've been spending my time on all the "secondary" issues ... how can we manage certificates, how do we make sure policy variance doesn't stop us, how do we integrate with existing infrastructure like email and DNS, how do we make sure that the client is simple to manage so the providers don't need extensive (and expensive) hand-holding, and so on.

When these issues didn't seem to resonate with the room over the last week, I was really confused. But then I took a closer look around, at the problem became obvious. These were all huge IT vendors that sell to hospitals, huge systems and the government (or they actually were the government). We had almost zero people who think about the real IT and economic environment these small businesses (both the providers and services) live in. All the usual suspects.

Holy misaligned frame of reference, Batman!

Why "IHE" won't create a winning ecosystem

The people who support small practices today will not stand up an IHE SOAP/XD* stack. Well, wait a second --- a few will, sure. You always have folks who are willing to make a visionary bet. But at scale across the country, so that a small provider can sign up for a $10/month service plan? No. Freaking. Way.

The first problem, of course, is that the IHE SOAP stack is incredibly complex and poorly documented. Anybody who has tried either path --- implementing a stack or configuring a CONNECT server --- will tell you it's crazy. Even the strongest proponents of the technology readily admit this. They say "we just need to fix it" --- but somehow we got to where we are. Why do we believe we can suddenly just make that better? I don't get it.

And even if it were easy to get your arms around what it means --- it means a brand new type of application. How you provision users will be brand new. How you make backups of the message store will be brand new. How you learn about security vulnerabilities and patch the system will be brand new. How you configure your firewalls will be brand new. The training needed by customer service staff will be brand new. The way you monitor the system to see if it's healthy is brand new. The way you try to determine why a message didn't get delivered is brand new. I could go on for hours here.

And by the way, there is zero software written that would help you run multiple organizations on a single machine, or meter and bill customers. This kind of thing just hasn't been on the radar of any of the organizations working within IHE.

Finally, most of the potential service providers have never heard of XD*. Try to imagine how you would respond to these two questions:

  1. Do you want to get into the "NHIN Direct" business? It's a new service for small providers that lets them communicate securely. I can send you a link to the site where you can learn about IHE and the SOAP/XD* profiles to get started.
  2. You already provide email services to your clients. We've created this thing called "NHIN Direct" that extends your existing email infrastructure so that providers can use it to share clinical information securely. It would be a great "upsell" to your existing product line, so you can capture additional revenue from your existing customers.

Does the difference seem subtle to you?  If so --- you haven't worked in that business before.

All is not lost

Like I said at the beginning, we didn't actually pick a final winner yesterday --- although the leanings of the room were trending towards an IHE XD* solution. Arien collected up all of the objections for each possible solution (IHE, HTTP/REST, and SMTP) and asked that the teams formally respond to them in advance of some intensive last-mile wrangling this coming week. I've started our responses for SMTP here.

More importantly --- we need to hear from the folks that are really in the field: small providers, their VARs and ISPs, and their representatives. The AAFP and CGC are two organizations that have weighed in in support of a more appropriate option already - we need to hear from more. You can help by posting your thoughts to the NHIN Direct Google Group.

Unfortunately, these are the very folks who are busy doing the real work of healthcare, so often aren't able to invest the kind of time I've been lucky enough to spend. To those folks --- and to Todd and Aneesh who cleared a ton of roadblocks to create this incredible opportunity for us --- I feel badly for where we are, but will keep working to try to make it a success.

Leave a Comment
  • Please add 8 and 5 and type the answer here:
  • Post
  • Sean --

    When you say "small businesses", I think you mean "non-healthcare companies serving small businesses." The clear lesson I drew from the week were that most of the EHR vendors, and all of the EHR vendors, HIE vendors, and consulting organizations, many of whom are small businesses or typically or exclusively deal with smaller providers, preferred the SOAP/XDx approach. In the room, it wasn't a big vs. small distinction, by and large. There *were* aspects of a traditional healthcare IT vs non-traditional healthcare IT break.

    You wrote: "And by the way, there is zero software written that would help you run multiple organizations on a single machine, or meter and bill customers. This kind of thing just hasn't been on the radar of any of the organizations working within IHE." That's just not correct: the multi-tenant web-based SaaS vendors (e.g., MedPlus, RelayHealth) were breaking SOAP, because they already need to support it.

    I've tried to frame what I see as the key issues over here:

    blog.nhindirect.org/.../debrief-from-face-to-face-meeting.html

    For me, the key issue is between choosing an approach that best fits what a substantial set of the current health care organizations have already done vs. choosing an approach that provides more support for non-traditional organizations but requires new development for the organizations that are already playing in the market. How you make that judgement call isn't clear, to me, at least. It's a value judgement.

    I would appreciate your thoughts here.

  • Sean:  Very astute commentary and analysis.  As I said at the meeting yesterday, the IHE contingent's proposal is "NHIN Connect Lite," but certainly not NHIN Direct.  I have no objections to the large vendors and their big clients constructing a light-weight version of the very complex NHIN Connect and Exchange protocols to support their organizations and their business models.  They should have done this a long time ago.

    However, I do agree with you that this is something very different from the first principles and goals of NHIN Direct, which were "direct" in the sense of both providing simple, secure, and affordable messaging over the Internet for physicians in small and medium size medical practices and their patients in support of Meaningful Use, and in doing so point-to-point using minimally complex transport.   The IHE "solution" is very far from meeting these goals and principles, and has nothing really at all to do with health information network that is "directly useful" for most physicians.

    The issues don't need any more "framing."   They've been well-framed, sort of written into stone, at this point.  What is left to decide is whether there is any commitment left at ONC to the first principles of NHIN Direct, or whether they'll be satisfied with NHIN Connect Lite masquerading as NHIN D.   Time will tell if the little guys will be left out of the ARRA/HITECH picture, but this development as you describe it, and we both witnessed it yesterday, is not a good sign.  

    Very kind regards, DCK

  • I think is important to remember one of the primary purposes of this project. We must find a way for small practices and rural and underserved providers to participate in exchange. We already have made some great progress on NHIN Connect and Exchange and I would encourage those who wish to continue working on IHE to focus in that area. My strong feeling is that we should use a combination of REST with SMTP ~ how exactly that will look is what we need to figure out this week.

  • Sean, great post.  

    Arien,  it is a large vs small as well as non-healthcare vs healthcare.  All the "providers" around the table in Redmond stating their preferences for SOAP/XD* where HIOs not small practices.  The IHE stack is designed for enterprises not small practices.  Therefore there are assumptions made, for example the patient identifier must be in the meta-data, and that we must force users to submit structured data.  If one looks at the organizations that have implemented XD* (via connect-a-thon) few focus on practices with less than 10 physicians and they all are in the $30-$50k per provider price range.  Sean's arguments make the point why that business model will not work for NHIN-Direct.  We need new models for physicians that are focused on driving quality and that make it easy to support care coordination.  I don't see IHE as a viable widely-adoptable solution today.

    Although I have some technical issues with XD*, they could probably be fixed - that is not the real issue.  The real issue is the assumptions in what will drive interoperability and health information exchange.  Going with IHE XD* is like trying to start the Internet with the Semantic Web.  We are 15+ years into the Internet and still do not have the Semantic Web.  We need to stop trying to create the health care Semantic Web and create the health Internet.  Until we do, we will never get to wide-scale semantic interoperability in healthcare. That is the reason AAFP supported REST and SMTP and not SOAP/XD*.  I don't see why we cannot add the "IHE" content constraints as optional payloads for the REST/SMTP approaches.

  • Hi Sean. I appreciate your perspective, but have to disagree with some of the premise. MedAllies is a small company, serving small docs, and have implemented the IHE stack. I hope we (the collective "we" from each side) can get a chance to further understand one another's perspectives because I think there are upsides to each approach, and I think this is a multi-faceted problem requiring a multi-faceted approach toward solving it.

  • Sean,

    Although I'm from a "big IT vendor" I want to say that your arguments DO resonate, with me at least. While at Siemens we don't run a local ISP per se, we (from our long hosting experience) totally agree with the importance of scaling, multitenancy, minimizing physical servers, minimizing operational cost (including the number of people to run the shop), etc. I won't presume to speak for any other organization. So just because someone is "big" (like Siemens, Microsoft, etc.) they can still care about the same things you mentioned. And I think we are also in agreement that the "IT" in the small practice is (hopefully) not an "IT Shop" at all, but simply some PCs, thin clients, appliances, whatever, that talk to the "black boxes" where the IT management really occurs, e.g., HISPs, SaaS providers, etc. As you know from our participation in the SMTP team, we DO believe in the benefits of the SMTP approach, in addition to the IHE approach, and are looking forward (once the current impasse is resolved) to actually doing the NHIN Direct prototypes demonstrating how providers with e-mail clients can exchange data with other providers (who have just e-mail, and/or web browsers and/or EHR modules).

    Thanks,

    David

  • Sean,

    What do you think of the latest Convergence Proposal -- nhindirect.org/NHIN+Direct+Convergence+Proposal -- in light of your comments in this post regarding the likelihood of potential service providers to build businesses on NHIN Direct?  

    Thanks,

    Mike

  • Mike, I'm super-excited about the new proposal and that we may be able to get to consensus. A small group led by Allscripts, Epic and Cerner has been working through the details and I'm hopeful that we will see a new proposal this week! We will see.....

Page 1 of 1 (8 items)