I recently decided to stop participating in the ONC “Architecture, Services and APIs” workgroup. I have an incredible amount of respect for the people running the group, but I also believe that the momentum at ONC right now is just wrong. My plan was to just go quietly into the night, but looking through the recently-released Meaningful Use 3 requirements convinced me that I really ought to put this out there.
This is too long and probably super-boring to 99% of humans, so if you keep reading, that’s on you.
The Connectathon Problem
When I first testified at a FACA meeting in 2009 (six years ago!) — I talked about the “Connectathon” problem. Interop is a tough nut for HIT vendors, because it’s obviously important to individual health outcomes, but it’s also a net loser from a competitive and commercial point of view.
Industry solved this dilemma by creating a false measure of success — the Connectathon. They defined some technical specs for sharing data (at the time, IHE profiles) and got together in a room to show that the technology “worked”. And it did — in this completely artificial environment. But the technologies were in no way appropriate to actually deploy in the real world, so things fell into place nicely — success at the Connectathon allowed EHR vendors to claim high ground on interoperability, but without any risk that it would actually be implemented for real.
So what about these technologies made them unsuitable for real use? One issue was technical complexity for sure. But what became clear over time was that the two killer issues were discoverability and authentication/authorization — problems that made interoperability unworkable at scale.
“Discoverability” helps machines find each other on the Internet. If Clinic A wants to request data from Clinic B, it needs to know the “address” for Clinic B. The telephone is pretty good at this for voice interactions; if I know your number I can pick up almost any phone and find you. And we’ve created many ways for us to share and remember phone numbers (contact lists, databases, searching on the web, etc.). The same wasn’t true for old-school healthcare interop solutions.
“Authentication and authorization” help machines decide if they should talk to each other. There are pretty complicated rules for this in healthcare, starting from who has a right to ask about a patient and how to communicate who that patient actually “is,” but going much deeper than that. Person-to-person, we typically work these out ok. But old-school interoperability just punted on the problem. In the Connectathon it was all magically (and painstakingly) set up ahead of time.
Direct tries to help
The Direct Project was an attempt to simplify interoperability and create something that could actually scale. In particular, we tried to build in at the very core solutions for discoverability and auth. The hope was that if we could tackle these, people would find more and more reasons to leverage the basic technologies, and we’d see a network effect start to take hold.
We addressed discoverability by latching onto the one technology that works for this on the Internet today: email addressing. Without creating anything new at all, machines can take a Direct address and find its home. And because it’s just an email address, we can use all the same ways we keep track of these today — they’re easy to add to patient or provider records in EHRs, we can post them on the internet, we can use directories like LDAP, etc. … all ready to go today.
Auth was tougher, because neither email nor the domain naming system which underlies its addressing were created with security in mind. And if every single person with a Direct address had to decide for themselves if they should trust every other Direct address, things wouldn’t scale very well!
We decided to address this by using the natural groupings offered by HIPAA. Direct users don’t have to decide if they trust an individual, they decide if they trust a group of individuals (which can be a small group like a clinic, or a large group like a member of DirectTrust or NATE). The technology innately understands the dynamics of these groups so that the problem can become manageable.
I think we did a pretty good job. And there may still be just enough oomph in this approach to get it over the hump — where virtually zero messages have been exchanged at scale using old-school methods, millions move every month via Direct.
Even so, it hasn’t had nearly the impact we’ve hoped. Why? Well, technology can only do so much. The hard work of building it into clinical workflows, and of getting people on board with the trust associations, takes time and commitment. Those aren’t fun problems — they’re a slog in the best of worlds. People like to look for the next shiny thing, and that’s where the momentum is moving right now.
I’m still hopeful, but it’s tough to watch.
Why APIs aren’t the answer
That next new shiny thing is healthcare “APIs.” An API (or “application programming interface”) is just a fancy way of describing how machines can talk to each other. In fact, Direct is an “Messaging API.” But in hipster parlance, an “API” usually means using web protocols like HTTP and JSON to talk between machines. And often implied is that the consumer of an API is a mobile app, like the ones that run on your iPhone.
APIs can make some cool things happen. Amazon revolutionized affiliate marketing and enabled the creation of some incredible tools by opening up their catalog with an API. Government has done the same thanks to the early work of Todd Park and friends. The Google Maps API has spawned thousands of awesome new mashups. And so on.
And they have their place in healthcare too. I won’t go deeply into that now, but I am a 100% fan of using APIs to extend EHRs within the clinic, adding functionality and all kinds of great stuff. The SMART project is at the forefront here, although it seems that Epic may have just given then the stiff arm with their new stuff.
BUT. Acknowledging all that awesome — they simply won’t help for healthcare interop. Why? Because they solve neither discoverability nor auth. We’re just back to the old days.
APIs work really well when they are delivered either by a single big instance (Amazon, Facebook, Open Government), or users only need to talk to one instance (your email server, or your Salesforce.com instance, or your internal EHR). When LOTS of machines need to talk to LOTS of different instances — things break down very quickly. And unfortunately, that’s healthcare.
Let’s go back to the simple case of Clinic A asking Clinic B for some data on a patient. In the API world, Clinic A first needs to configure their system to know where Clinic B “is” on the Internet. Clinic B then needs to grant Clinic A access to make calls into their system — say Clinic A gets a password to do this. They need to save that password somewhere. OK, good enough.
This now has to be repeated dozens or maybe hundreds of times, each time Clinic A wants to get data from some new clinic’s API. To keep things secure, each clinic probably expires its passwords periodically. Oops, things stop working until IT departments get involved. And maybe Clinic B wants to upgrade their software, and the API changes a bit. Dang, that connection to Clinic A is broken.
This stuff just spirals and grows into a huge mess. And the API crowd is explicitly ignoring it. As in, ignoring it on purpose by saying “that’s out of scope.”
Or course, all of these problems are “solvable” — but THEY ARE THE PROBLEMS TO BE SOLVED. Not data formats or query patterns.
That was why we spent some much effort on the innards of Direct. C/CDA and other data formats may be stupid and overly complex, but that ultimately doesn’t matter. The hard problem is solving discoverability and auth in the context of an incredibly diverse and distributed ecosystem.
We have a path forward on this. I wish we’d have the discipline to stick to it.
As an interesting aside, the “Connectathon” problem rears its head all over the place … people are increasingly “dishonest” about the state of problems and ideas, e.g.,:
- How many news articles do you see that talk about a “cure for Alzheimer’s” … but when you look closer they just have discovered an interesting mechanism that maybe in fifteen years after a ton more work could be useful?
- How many awesome new gadgets do you see talked about on the web as if they exist … but when you try to buy it you find they’re just a Kickstarter trying to raise money for an idea they haven’t even prototyped yet?
- …. And on and on … we are increasingly awash in a world that pretends neat ideas are finished solutions. And increasingly I’m a crabby old guy, kind of pissed off about it. 😉
I agree that the API-hype does more harm than good (Hype around SOA and ESB has all but killed the potential in the idea of service orientation). I believe APIs have great potential but the hype diverts attention from the real challenges. Discoverability and Authorization are challenging in itself, making them technical problems by throwing technical solutions/mechanisms makes it impossible to solve. IMHO, Discoverability and Authorization is about organisational and legal interoperability – which are issues of governance and responsibility i.e. who offers what and who can do what (IMO, authentication is fundamental for auth, but the focus should be on auth).
Even a kick-ass Service Registry would not make Discoverability and Authorization work; It is the _data_ that populates the service registry that is crucial and hence managing that data requires good governance practices. Openness, standards and collaboration are good principles to have. However these principles are difficult in environments that govern by hierarchy (as opposed in a collaborative network). What if data from systems that support the process for authorization of practitioners could flow to such registries? Or data describing clinical practices and care plans could flow to these registries? Securing that level of interop would change the nature of the discussion about APIs – and APIs then become powerful tools and not a silver bullet. Technology can help with technical interop (formats and protocols), and to a large extent also with semantic interop (HL7, IHE, SNOMED etc). But the higher levels of organisational and legal interop require more than APIs – those levels are about the free flow of services – health and clinical services, not webservices or APIs.
Connectedness is more than APIs and technical/semantic interoperability. There is a certain degree of recursion that needs to be addressed. I am no way suggesting that this is a trivial problem, however we may be shooting ourselves in the foot by ignoring the nuances of interoperability and throwing technology at it. I have never participated in a Connectathon, I regard it as a tool from the marketing department – a means to raise awareness and galvanize/incentivize to action. I’ve seen many good marketing tools end up as the proverbial tail that wags the dog.