It’s funny how topics wax and wane in our business … turns out I’ve got a number of events coming up where I’m on tap to discuss the emergence of “APIs” in Health and what it might mean for interoperability and adoption. The first of these is tomorrow at ITdotHealth at Harvard; great to follow-up the meeting that kicked off so much of the “Health Internet” movement back in 2009!
First let me say, hooray for all of the energy that folks are bringing to this new phase of healthcare technology. It’s fantastic that people are realizing that no single company/tool/app can do everything, and that we have to find ways to create composite, federated solutions. ePrescribing is the grand-daddy of this dynamic, and the work that Zac, Ken, Josh (and Ben!) have done with SMART is the natural next step. More investment and work and experiments are always a good thing, so AT&T, Aetna, etc. --- keep it up!
That said, we’ve been at the API game with HealthVault longer than most in the business, and I’ve talked in the past about why I returned to Microsoft to start the venture. This is a company that understands both the complexity of building API-driven ecosystems and has the need for patience and resources to bring them to critical mass.
Which leads me to ask the question --- do all of these new companies introducing “APIs” really know what they’re signing up for? From where I sit, the answer is pretty clearly no … but we’ll see. In any case, I thought it’d be useful to outline some of the key challenges and at least add to the conversation.
APIs live or die on developer adoption. No connections == no ecosystem. Pretty simple. So what makes developers adopt an API?
1. Do my users expect me to be connected?
This is, frankly, the Holy Grail for an API --- developers are forced to build to it because, if they don’t, their users simply won’t buy. Not many folks enjoy a catbird seat like this … Windows in the enterprise, Apple with hipsters (joke!).
Nobody in the health market holds this position broadly today, which is why we all have to be delivering value along the other key dimensions, namely….
2. Does it get me to market quicker/faster/cheaper?
This can be a really powerful dynamic … e.g., can you help people deal with policy or regulatory issues? Can you help them avoid the need to backup or encrypt/store sensitive data themselves? Do you provide pre-built UX controls or other functionality that accelerate development? Do you handle accounts and credentials so the developer can take fewer support calls?
There are lots of ways to help here, but it also can be a tough sell … because developers are both (a) lazy about learning new things, and (b) smart about limiting their dependencies. So these advantages really have to stand out to make a difference.
This is also about building the *right* API. For example, there’s a very specific tradeoff that I’ve spent a lot of time talking to Josh about wrt SMART. At HealthVault, we made the decision that the most important thing in a medication list is that it be complete … so we will accept uncoded data. Josh made a different choice … he requires that every medication have an RxNorm code associated with it. This is easier for developers using data, but quite a bit harder for developers storing data. Which choice is right? I have an opinion, but really I dunno --- this is hard stuff!
3. Does it give me efficient access to a user base (i.e., marketing)?
Truth be told, this is what a lot of folks are looking for. It’s why somebody like Aetna has an interesting premise, because presumably they can offer up their entire insurance base as a market for application developers --- pretty cool. But they also have to be careful about “spending” this capital … if they start inundating their users with lousy apps, they’ll quickly lose the attention of that market.
My opinion is that it’s usually a mistake to focus so much here. Health is kind of special --- people engage differently than they do for other products, and it’s really about intersecting targeted, personalized life events and trusted advisors rather than mass market blasts. This is really complex and sinks a bunch of naïve developers, and is something we continue to refine ourselves with HealthVault, for example by expanding our reach globally and creating personalized vehicles for our users to discover great apps.
4. Does it offer me features that I’m not in a position to build myself?
This is one where HealthVault really excels. We’ve invested a TON of time in things like:
- Making it really easy to share information with care circles
- Helping developers integrate into healthcare enterprise workflows
- Making as much rich data available as possibly --- by connecting to and interpreting data from devices, labs, pharmacies, federal programs like Blue Button and Direct, etc. etc. …
I put a ton of resource every year into making sure that we’re the richest “patient health information hub” in the world … and I think it’s paying off. When I look at the other APIs out there, I sometimes see a lot of Field of Dreams … remember, it’s not the API that’s compelling, it’s the data and features inside the API.
5. Does it activate new business development opportunities?
This is kind of like #3, but about linking developers up with each other. For example, one of HealthVault’s best development partners is a company called Get Real Consulting that has built a portal-in-a-box product called InstantPHR. Because they use HealthVault as their data layer, GRC has been able to combine forces with other developers like the folks at MediGuard, who’ve built some great drug safety functionality --- integration is easy because they’re using the same API underneath. Win-win!
This is a flywheel play --- you have to get enough folks and functionality into the mix to create opportunities for collaboration. Not easy!
6. Is it a safe bet for my business?
This is my biggest worry about the cacophony of APIs emerging today --- I don’t think folks have really thought through what it means to support their developers over the long haul. Remember, we’re asking developers to bet their businesses on us. This means we have to:
- Be committed to real support and real uptime and scalability. If HealthVault goes down, 300+ applications go down with me … and those apps are powerless to do anything about it other than abandon the API. So I put a metric TON of effort and money into making sure that never happens.
- Respect the cost of integration and provide real backwards compatibility. HealthVault has a formal approach to upgrading our API, and guarantee support for existing interfaces for a period of time that developers can count on. We even have a patented system that automatically transforms data between new and old versions … so that an application written to an older data model will continue to work even as we advance the system forward. It’s really easy to underestimate the ripple-effect on hundreds of developers that have to react to “simple updates” to your API.
- Be where developers need to be. Developers need to keep up with an insanely-fast-paced tech industry … and if they take a dependency on your API, it had better be available where they need it. These days this is easier than it used to be … but it still can suck up a ton of resource. Right now I’m burning a bunch of my oil getting ready for Windows 8 … it’s a new world.
I could go on and on here … building a great API that people truly build business on is hard, costly, long-term work. I am super-excited about all the energy in our market, and am confident that awesome new innovations will emerge as a result of it. But our next phase as an industry has to be about growing up just a little bit … each of us recognizing what we’re really good at and working together to optimize those pieces around a few data hubs and APIs.
I’m committed to make HealthVault one of those hubs over the long term. And we’re always looking for more great developers: check us out!