The most important API you’ve never heard of
Levin Brown is a MD/MPH candidate studying Health Policy and Management at Harvard School of Public Health.
Right now, one of the most important and exciting developments I’ve seen in health data is happening, and I really think you should be part of it.
Recently, a group of large EMR vendors and hospital stakeholders started exploring the new data exchange standard, HL7 FHIR. After many years of pressure, these vendors are sitting down together to discuss how to start exposing health data in a modern, consistent fashion. It’s taken a lot of work and leadership to get to this point and is going well so far—but now it’s time for the startup community to get involved.
Why’s this so important? Currently it’s really tough to build anything for the enterprise health industry. It’s not that you can’t build at all, it’s just that there are few ways for anyone to ever use or buy what you build. For example, if it touches patient data and requires a nurse, doctor, administrator, payor, or even the patient to use it—you’ll probably be integrating with a 70’s-era MUMPs-based EMR system, which will be expensive, painful, and slow.
How expensive? Generally, about $10-150k dollars per integration depending on what data the app needs. How painful? I hope you like XML documents, flat files, pipes and hats, SOAP, and even CORBA. How slow? Well, welcome to the enterprise IT game and its years-long sales cycles.
But the APIs are coming, right? What about Healthkit?
Healthkit is exciting, but is just getting started and is focused mostly on getting fitness and survey data into an EMR, not on getting clinical data out—and we have yet to see how ResearchKit integrates. It exposes methods for only a small fraction of the types of data captured in the clinical setting. Since providers and hospitals mostly pay the bills taking care of sick people, the extra miles we’re all logging on Strava and Misfit won’t often be interesting to our physicians, and won’t incent providers or hospitals to pay for apps that tell them about the health of people who aren’t their usual customers.
Similarly, Cerner, Epic, Athena, Allscripts, Optum, and others have announced ‘open’ APIs and Appstores, but it seems unlikely that they’ll be providing early-stage innovators many options soon. Athena is doing a good job so far from what I’ve seen, but it’s just too early to tell if any of these shops will really embrace working with potential competitors.
Competition is an important thing to keep in mind. Every one of these companies builds dozens of different products that overlap in some way with what you’ll want to build and will be wary of undercutting their own offerings. These are not platform companies accustomed to treating developers as allies like the folks in Cupertino or Redmond. My guess is that over the next couple years, 100 app-flowers will bloom, but that many startup products will turn into enterprise features before you have the chance to gain traction.
These aren’t the APIs you’re looking for…
It’s worth noting that Allscripts tried the API thing a few years ago. How did that go? Developers had to sign up and be approved before they could even see what could be built, much less how to build it. Essentially, companies had to first be an ‘enterprise’ outfit that built something that didn’t compete with Allscripts, then they had to review the company, consider the customers they were going after, and decide if it was in their best interest to even let them read the docs. Although it’s gotten better, at this point I don’t see much evidence that the API rollouts from other large vendors will play out too differently. The only reason I get to see much evidence at all is because I’ve worked at hospitals with startups that get the developer view of these things.
Even with access, the challenges to building are formidable. EMR APIs are generally poorly documented, rigid, non-portable and thus non-scalable. Remember that many of these companies’ installed EHRs aren’t interoperable even between themselves, and data outside the API will continue to require custom integration. You’ll be playing the enterprise sales game with your product-hand tied behind your back.
So what can we get excited about?
I think FHIR is the most promising step in getting access to data in a consistent fashion. After years of gnashing of teeth, HL7 and the ONC are putting real effort into standards that make sense. FHIR is RESTful, can deliver nicely parsable JSON, and has a resource-based data model that’s reasonably straightforward (for healthcare), and based on ontological principles that have come out of 30 years of medical informatics research. It allows for the embedding of standardized codes with much more meaning than the bloated and often silly ICD system that we are used to. Just harmonizing things like this could enable all kinds of analysis currently stymied by organizational data silos that can’t be integrated or correlated in a useful way. This is a really big deal, with the potential to empower innovators to advance research, reduce waste, and improve health outcomes for those who need it most.
We need to you participate.
Traditionally, HL7 decisions are made in a very ‘enterprise’ setting; think waterfall projects, not agile. The guys that created FHIR are different—Grahame Grieves, Lloyd McKenzie, and Ewout Kramer have all been working passionately to make FHIR more open and accessible than anything else HL7 has ever done. And they’ve done a good job, the ONC is beginning pilots to assess how we can use FHIR this year. This is a good thing, because FHIR is still undergoing continuous development and many features and details with major implications are yet to be decided. It’s critical you get involved, so that we can begin a process whereby ‘API style interoperability’ becomes broadly supported, and perhaps even the backbone for the improvements in continuity of care across settings that we all want to see.
So what do you do?
First of all, if you’re in the Bay Area on March 19th you should come by Rock Health, where we’ll be discussing the healthcare API landscape and hosting special guest Josh Mandel with dinner and drinks. Josh is lead developer of the SMART Platforms project based out of Harvard’s Boston Children’s Informatics Program. He’s one of the central figures in the development of FHIR and has been working to promote standards, APIs, and accessible EHR architecture for years. He also knows more about what’s happening in the world of interoperability than just about anybody.
After that, start trying to build stuff using the SMART on FHIR server, or one of the other FHIR servers that are keeping up with the spec (HAPI is good for visualizing requests). After you hack on something, follow one of the FHIR implementer chats to get a sense of what the conversation is like as FHIR moves forward. Or if you’re a builder that wants to help move health care along, let the ONC know what you think and join the conversation. They really are listening, and we need startup voices to be heard.
There are a lot of exciting things happening in health these days. The attitude in hospitals and government seems to be that the time has come to take more rapid innovation and progress seriously. Healthcare is big, complicated, and slow, but it affects all of us, our communities, and our families. Come help us get health care better, so one day it can return the favor. We’ve got a lot of apps left to build.
Stay up to date with the biggest news in digital health. Sign up for the Rock Weekly.