We think that Medicine is a scientific discipline, and we believe it too, right? So what is a core tenet…
Readers Write: Liberating Data with Open API
Liberating Data with Open API
By Keith Figlioli
Today, people all over the world use Twitter as a means of everyday communication. But how useful would the application be if you had to contact the company and get a custom code each time you wanted to post a thought? As ludicrous as this seems in the social media space, it’s reality in healthcare information technology.
For all the hype around electronic health records (EHRs), healthcare providers still lack the ability to easily access data in EHRs. This in essence means that developers can’t just build applications that meet a use case need. This is because each system is closed behind a proprietary wall that requires custom coding in order to be unlocked for add-on workflow applications. If you want to marry EHR with pharmacy data so that doctors can be alerted when a medication hasn’t been refilled, for instance, health systems must contact their EHR vendor and pay to have that application developed to their specs.
These walls around data have real consequences. Not only are healthcare providers spending millions on one-off applications, but they are missing innovation opportunities by requesting custom builds. In the case of smartphones, both Apple and Google released their application programming interfaces (API) for any developer to leverage, creating thousands of apps, many of which users would not have imagined on their own. In healthcare, these APIs don’t exist, meaning that apps are only developed if they are imagined by either the provider or the vendor, with all potential for crowdsourced innovation completely cut off.
Although it’s hard to put a price tag on missed opportunity, a McKinsey & Company report found that the US loses between $300-$450 billion in annual economic potential because of closed data systems.[1] With more “liquid” data, McKinsey predicts new applications that close information gaps, enable best practice sharing, enhance productivity, support data-driven decision making, pinpoint unnecessary variation, and improve process reliability — all sorely lacking in today’s healthcare environment.
There’s also a price for patients. According to a recent Accenture poll, 69 percent of people believe they have a right to access all of their healthcare data in order to make decisions about their personal care. Yet almost none of these patients (76 percent) have ever accessed their EHR, chiefly because they don’t know how to, nor do they have the ability to integrate EHR data with other applications, such as those that track weight, diet or exercise via a smart phone or home computer.
Two forces need to align in order to facilitate change. In the marketplace, healthcare providers and patients both need to advocate for open API and liquid data in order to get the most out of healthcare applications. With increased demand for open access, market forces will be unleashed to prevent closed systems from being introduced for a single vendor’s financial gain. Moreover, with open systems and free access to development platforms, EHR vendors can differentiate themselves with the diversity and utility of the apps that are built to work with their systems, creating an added value to end users.
Secondly, we need a policy environment that enables innovation. One way this could be achieved would be for the Office of the National Coordinator to require open API for health data. In an optimal environment, vendors should have to demonstrate that data can be extracted via open API and leveraged by third-party software developers.
The business of healthcare should not be predicated on keeping data trapped behind proprietary walls. Given the critical need to use data to better predict, diagnose, and manage population health, the truly differentiated vendor is one that allows open access and third-party application development in order to create systems that providers and patients truly value. It’s time to liberate information and unleash innovation in healthcare.
[1] McKinsey & Company, “Open Data: Unlocking innovation and performance with liquid information”, October, 2013, p.11.
Keith Figlioli is senior vice president of healthcare informatics for Premier, Inc. of Charlotte, NC.
“In healthcare, these APIs don’t exist,” … don’t most major EHR companies (athena, Greenway, Allscripts, etc) have APIs and developer programs available today?
APIs are definitely a need in the industry, but these type of illustrations do demonstrate a knowledge gap in the industry regarding truly viable options for leveraging this type of technology in a safe manner
First off, many of the large vendors have this capability today. Cerner, Epic, Athena, etc… all allow for the general concept of API development by outside resources. Some have limited this access to their customers, thus limiting the crowdsourcing effect, but the capability has existed for 5+ years in many instances.
The other consideration is that some of the most important information is also the most dangerous to open up to “the crowd” due to the nature of use. It’s hard enough to find an IDN with a consolidated medication formulary across all of their facilities, let alone two distinct organizations with matches. Multiply the amount of variables required for accurate mapping and the odds of getting it correct across facilities in a general region starts to look more remote than winning Powerball.
Until national standards are established & adopted, this idea of open source is nothing more than a pipe dream and ultimately has the potential for much more harm than good as the amount of risk managed by an EHR is much greater than those managed by a smartphone or tablet.
Great perspective Keith – Allscripts agrees with you! We have an Open API that is available for developers to use today to connect with our EHRs and other Allscripts solutions. See some of the solutions already certified through our program and apply to get access to our APIs at https://store.allscripts.com.
I’ve been rather unimpressed with the API support that I’ve experienced in the industry. My take is that there is a cultural issue that means that making the data available to others means that:
1). This isn’t a priority since it mainly benefits the recipient of the data and not the sender;
2). This is a revenue opportunity.
On the one system we eventually built an interface which was highly successful. However I’m not blind to the limitations of what we did. It was a one-way interface, it was perhaps 80-90% custom code, it only connected 2 specific systems and it only did so for one specific data stream. For all those caveats, it met all the identified needs and made our clients very happy.
For the other system, the interfaces exist and we’ve used them. One limitation is that the vendor charges for using those interfaces, on a per-instance basis. And it isn’t cheap! Another is that the interfaces are stuck on an old version of the interface standard and it’s been that way for years.
As for the notion that standards don’t exist, well I don’t buy that. They do. They aren’t perfect and they change over time, but the standards exist and are relatively well organized, at least the ones I saw. The bigger issue is, I think, that the software companies like to drag their feet. At least the ones I have experience with.
This leads, or can lead, to a chicken-and-egg problem. 2 vendors don’t interface. With no moves by the vendors to provide that functionality, the customers (mostly) stop asking for that capability. Then the vendors claim there is no demand for interface functionality! Yet all related enhancement requests by customers are either ignored, voted down, or denied without consultation.
I cannot speak for the industry at large. This was for 2 large and well-known HIS vendors, one of which had multiple product offerings.