There are currently over 500,000 apps for the iPhone. Apple has written only a handful of those. How many would there be if Apple had to write a custom interface for every developer who wrote an app?
My previous post threw down the latex gauntlet announcing that, “My medical data should move with me as easily as my music or photo library…”, because, well, it sure doesn’t. And I blamed that problem partly on healthcare IT vendors’ current practice of requiring custom interfaces to be written for every application that wants to interoperate with them. How do other industries avoid this problem? Stay with me to learn the deep dark secret…
But first, back to the iPhone: Apple wasn’t so arrogant as to think that they would come up with all possible good ideas for using the iPhone — or that they would ever be able to hire enough developers to do that. So they built an open platform, and now I can pay my bills, play my games, and find restaurants in the “C” concourse at O’Hare, all through third party apps.
Need more examples? There are at least two applications that will automatically generate an online newspaper filled with articles that interest me, simply by searching through my Twitter account and seeing who and what I follow and what I find important enough to re-tweet. Neither of these apps are written by Twitter, but I simply have to log onto them through Twitter and they are off and running.
How this is magic accomplished? Well, except for the applications themselves, there’s not much new here. Public “Application Programming Interfaces” (API‘s) have been a standard programming technique since at least the early 80s. To calibrate that, the Macintosh computer was introduced in 1984. For PC folks, that was the era of the Intel 386 microprocessor, which ran at a speed of about 33MHz. APIs been around for a long, long time.
OK, enough history, what are these API’s all about?
It’s a pretty simple concept: any system that wants to share data publishes the parameters of a public interface – what calls to make, what parameters to pass in, and which values will be returned.
Let’s say I’m a hospital Electronic Medical Record system and I want to allow other applications to access a patient’s temperature. I have all the functionality that allows the clinical staff to record the info, so nobody else needs to develop that. But if I want to make that data available to outside systems, I write a public API that says, “To access a patients’ temperature, call my ‘Get-Patient-Temperature’ function with the ID of the patient you’re interested in. I’ll pass back the temperature, the time that the temperature was recorded, and the date it was recorded as well.”
A calling system doesn’t care whether I pass the temperature in Fahrenheit, Centigrade, or Kelvin, as long as I have documented the units. The caller also won’t care whether the format for time is a 12 hour AM/PM format or a 24 hour military format. As long as the format is publicly documented, the caller knows what to expect, and can write an internal routine to convert units if necessary. (Although if I was a really friendly EMR, I might provide a way for callers to specify the units they wanted so that they wouldn’t have to do the conversions themselves. Friendly platforms get more support from applications programmers, encouraging more apps to be written, which, as Apple knows, makes your own software much more valuable to the end user…)
That’s it????
Yeah pretty much.
Not such an Earth-shattering concept, is it? So what’s the hold-up in the healthcare world? Why doesn’t my medical data move with me as easily as my music?
I can’t really answer that, but here are some possibilities (all speculation on my part):
Speculation #1): Vendors want all IT dollars spent in hospitals to be spent only with their company.
Closed platforms do indeed create a situation where all new ideas need to come from the vendor themselves, often as extra-cost options. They also make it much, much harder for the customer to switch to another vendor – because there’s all that data trapped in the systems that would have to be extracted somehow, and then laboriously converted to the format used by the new system.
This actually turns out to work against the vendors’ best financial interests (see below). And it clearly holds back the state of the practice — again, just imagine if Apple would have had to come up with all the apps that are currently available for their phones…
Speculation #2): There’s a data security problem; it’s not “safe” for private patient data to flow freely between systems.
Security and privacy of patient data is without question a high priority, and that responsibility must not be taken lightly. But, for example, the financial industry has billions of dollars of transactions flowing between disparate systems every single day. And please don’t try to convince me that security of their financial data is not top of mind for them. Yet somehow they’ve managed to interoperate securely.
Speculation #3): “We’ve always done it this way.”
I have trouble coming up with too many other players in the high tech world that aren’t itching to constantly innovate – from hardware (“Moore’s law”), to programming languages, to computers, to smartphone apps…you get the point.
One last point to make. Not only do public APIs enable third parties to build applications that interoperate with your system, making your product more valuable to your customers, but it also makes pretty good business sense. Sure, healthcare IT vendors can charge $50K per custom interface, but, for
“…some of the brightest stars of tech: Amazon, Apple, Google, SalesForce, and Facebook…a significant source of their revenue comes from APIs… Salesforce does 300 million transactions a day just in API calls, about half their more than 600 million/day total transaction volume.”
Public APIs are good for innovation, good for vendors’ bottom lines, and, the reason that ultimately should trump all others, they are good for the patient.