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:
- Solve the technical problem of moving messages around securely;
- Be more convenient for doctors than the fax machine;
- Provide a credible path from unstructured to structured exchange; and
- 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:
- 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.
- 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.