By Andy Oram

It’s heavy tech time at THCB. Health 2.0 is running a developer conference called Health:Refactored on May 13-4, and a big topic there will be the opening of APIs from Microsoft, Intel, Walgreens, NY Health Information Network, MedHelp, Nuance and more. What’s an API, why does it matter for health care? Funny you should ask but Andy Oram from O’Reilly Radar wrote an article for THCB all about it!–Matthew Holt

As the health care field inches toward adoption of the computer technologies that have streamlined other industries and made them more responsive to users, it has sought ways to digitize data and make it easier to consume. I recently talked to two organizations with different approaches to sharing data: the SMART platform and the Apigee corporation. Both focus on programming APIs and thus converge on a similar vision off health care’s future. But they respond to that vision in their own ways. Differences include:

• SMART is an open source project run by a medical school and is partially government-funded; Apigee is a private company.
• SMART tries to establish a standard; Apigee accepts whatever APIs its customers are using and bridges between them.
• Finally, SMART is oriented toward a wide range of sites, large and small, hoping to create an ecosystem; Apigee seeks out a few willing players who want to increase the market for their services.

I’ll explain the approaches and explore their implications in this article.

The special value of an API in health settings

First let me take a minute to explain what an application programming interface (API) is and why APIs could be a very positive disruptive force in health care.

In software terms, an API is a collection of functions that a programmer can call to use someone else’s services and data. For instance, Facebook offers several APIs that let you publish postings, delete them, and so on. This can be quite useful for an enterprise that maintains many Facebook sites and wants to update them regularly.

More broadly speaking, APIs are the currency of software development. They make it possible for programmers and organizations to work together without having to coordinate every tiny change and grapple with each other’s code. When the Department of Health and Human Services under Todd Park started throwing data out to the public, in the hope of stimulating useful public health applications, they knew that plain tables of statistics would be of little help to programmers. Whenever they could, HHS offered an API to access the data. Many leading EHR vendors see where the field is heading and have provided APIs to their data, all in the hope that programmers outside the company will develop applications that enhance their products.

Although old-style programmers are used to APIs with long names and inscrutable lists of parameters, modern application APIs tend to use Web-friendly techniques going under the moniker REST. In health care, such an API would allow you to pull up a web browser and type in a location like this to get some lab results:

http://someclinic.org/patients/Joe_Somebody/labs/HDL_cholesterol/LDL-C

The URI works as follows: each slash precedes an element of the data (Joe Somebody is a patient, LDL-C is one result reported by an HDL cholesterol test, etc.). The results get more specific as you move from left to right. This URI returns the LDL-C reading of an HDL_cholesterol test.

RESTful APIs bring data within reach of every Joe Somebody, but still, they tend to be queried not directly by people, but by applications. And the goal of both SMART and Apigee is to vastly increase the number of useful applications getting access to data and services on the sites that provide APIs. The API provides not only a simple path to data, but a rigorous method friendly to programmers.

A second advantage of APIs is that they force sites to break data into tiny, atomistic chunks that can be individually consumed. This in itself can create a revolution in a field used to exchanging information (if at all) in the form of discharge summaries and continuity of care documents. Although some of these are now distributed in XML formats that allow a program to extract a particular piece of data like an LDL-C lab result, they’re much more complicated than the type of RESTful API I showed. Lots more data will be available to researchers when they’re exposed through an API.

Yet a third benefit offered by APIs is the standardization of data. Each field must use consistent units and terminology, quite different from the discourses put in most health care records. This is not to dismiss the importance of clinicians’ narrative, subjective observations–they often provide the key to diagnosis. But clinical decision support, public health, and research depend on quantifiable data, which APIs lead to.

This doesn’t mean that clinicians will be forced to pull down a dozen drop-down boxes or fill endless text fields to provide the hungry APIs with their fodder. Institutions are starting to contract with software firms that can use natural language processing to extract the necessary data from clinical notes.

With these three benefits–a consistent programming interface, a breakdown of data, and a standardization of terms and units–APIs are posed to bring health care into a new era. Now we can see how SMART and Apigee embrace APIs.

SMART: openness as an impetus to apps and patient empowerment

The SMART project is a young but fairly mature project that gives health care providers a simple, modern, and consistent API for data exchange. The idea is that, no matter what EHR you use or how you define your data, you can share it with others in a standard manner. A developer can write a single app that can run on any site that adopts SMART. It’s no surprise that the government has supported SMART through the Office of the National Coordinator, because one of their major goals is to standardize on a common format to push Meaningful Use forward.

Private EHR vendors have been slower to sign up, but SMART has seen some adoption there and is increasingly popular among health researchers. Last year’s conference on the topic drew people from as far as South Korea and Switzerland.

The designers of SMART place it into a larger agenda as well: to build patient portals that can be reached through SMART and therefore encourage doctors to access patient data as a routine part of care. Once a patient is in control of her data, she can offer it to doctors as she moves from one specialist or practice to another. She can also share it at her discretion with researchers.

The designers have created patient portal software called Indivo that supports SMART, with the hope it will be installed and widely used. Some sites indeed now offer patient portals based on Indivo.

SMART is a read-only API. That means that you can extract data from the sites that support SMART, but not store data back into them. Dr. Kenneth Mandl, leader of the SMART and Indivo projects, says that he didn’t want to encourage the loading of data into proprietary and non-standard records, where it can get trapped. However, a write API will be needed to support patient’s burgeoning interest in shoveling data from Fitbits, Withings scales, and other devices they pick up in a sports shop or get recommended by their doctor. Mandl says, therefore, that a write API is on the roadmap for SMART.

Once patients have a data set that can contribute to their care, the data gives them bargaining power to make doctors open their EHRs up to the patients. Furthermore, patient data sets will arouse the appetites of health researchers, and insofar as research leads to better care, doctors will have incentives to install EHRs that support SMART. This is the virtuous cycle that SMART could lead to.

Apigee: business requirements drive incremental data sharing

Apigee lauds the virtues of incrementalism as strongly as SMART’s designers promote their grand vision of standards. David Andrzejek, head of the Apigee’s recently announced API Exchange project, says that a good standard is the best solution to interoperability, but is hard to achieve. Certainly, standards can take a long time to develop and end up overloaded with features or suboptimal in other ways. Sometimes the community comes up with a popular standard and then (according to many programmers) ruins it in a follow-up release by stretching it to achieve too much.

Instead of waiting for a standard, API Exchange bridges the APIs of different customers. This requires the customer to have an API already in place (although it doesn’t have to be RESTful–many older styles of API are in place, and Apigee can work with them). Because APIs are something of a luxury that small businesses cannot afford, Apigee tends to work in markets with large companies. They have achieved a good deal of success in telecom, which is certainly an industry of giants. In health care, their initial focus in on insurance companies, which also meet the criterion.

To see what the Apigee API Exchange makes possible, imagine that someone who has an app running on AT&T switches to T-Mobile, and finds he can run the same app. (I’m just picking popular names for an illustration–I’m not saying Apigee actually works with these companies.) Neither AT&T nor T-Mobile would have to change their API, nor would users have to download new versions of the apps. Apigee’s bridging software translates between the APIs. This is comparable to the translation done between databases when, for instance, two companies merge and have to generate reports that combine the fields in their database.

The more companies join, the better, but the bridging approach that Apigee uses means there must be specific bridges for each company: one bridge into Apigee’s internal standard and another bridge from its standard out to the company’s API.

Why use Apigee? Forward-thinking companies in health care realize that their services will be more valuable if programmers write apps on top of them. For instance, an insurance company could boast of a “Find a Doctor” app. And if the same app can query multiple companies, programmers are more likely to write apps and patients or providers to use them. This is a win-win for the insurers and anyone interested in their data.

“Find a Doctor” types of apps are by no means the limit of what we can get from insurance company data sets. Claims data, even though criticized often as unrepresentative of patient conditions, is a huge and crucial source of trends. It can be helpful to individuals as well as governments, providers, and insurers to know, for instance, where cluster of leukemia occur. Partnerships that use Apigee make it more likely that researchers will uncover such insights.

But unlike SMART, Apigee is a business, and its service is a business proposition. Before approaching Apigee, two or more companies have to form a relationship and agree to tie together their APIs. Each has to think of a solid business reason to join the partnership. The Apigee approach may be less likely than SMART to spawn serendipitous advances in health care, although once the APIs are exposed, there is no telling where innovation may come from.

Bridging APIs should also be of interest to health care providers who are quickly consolidating and forming partnerships such as ACOs. It remains to be seen whether they’ll create APIs and seek to tie them together. A lot of the responsibility for creating an API lies on the EHR vendor, and they have strong incentives to keep data locked up, so there are many steps to take before the doctors can boast of interoperability through the Apigee approach. The formation of CommonWell shows that pressure is building for collaboration.

Here, therefore, we have two models for change, both embracing the benefits of APIs, but with different approaches to interoperability. It will be interesting to see how far Apigee penetrates in the health care space, and whether the scattered sites using SMART reach a tipping point where everyone wants to come to the party.