Like most legacy healthcare IT companies, Epic runs an ancient technology stack. Its core database is a pre-SQL, cache-based database, which went out of style long before I was born. They’re currently in the midst of transitioning the front end from VB6 to .NET. Unfortunately, they decided to leave their core database technology untouched.
Epic doesn’t like working with 3rd party vendors. Epic wants to be THE solution for all hospital IT. Because of its ancient technology stack and business practices, Epic has been notoriously difficult to interface with. Epic doesn’t provide anything that even resembles an open API. They will, if a prominent customer makes enough noise, provide an HL7 ADT feed. Without getting into the technical details, I’ll say that HL7 is the opposite of a standardized, consistent API. To be fair, it’s not Epic’s fault that HL7 is lacking, it’s the government’s.
Epic recently held its annual user group meeting. They surprised the world by announcing open.epic, an open API. I almost had a heart attack out of excitement. Unfortunately, that was unwarranted. The API will allow developers to feed passively gathered wearable device data into an Epic database. The API doesn’t offer a protocol to reciprocate data exchange. Moreover, the launch was clearly a hastily thrown together soft launch. At this stage, Epic is just getting feedback from developers. They are years from a live solution at a client site.
This of course begs the question, why open an API at all? For the past 30 years, Epic has slowly built software modules for virtually every hospital function. Epic has never acquired another company, and tries to insource everything. I suspect that Epic concluded that it will never want to be in the business of manufacturing, marketing, and selling devices to consumers, so it actually found it in its own interest to open up a one-way API for passively collected patient health data.
The big winners here are Epic and analytics companies that can get their hands on Epic databases. Perhaps they’ll be able to drive new insights with wearable device data. Although there aren’t any explicit losers per se, relative to what the API should’ve and could’ve been, the big losers are the device makers that are going to feed the API. Just imagine how much more powerful this could’ve been if your Jawbone or FitBit could query an Epic database and return some intelligent insight to the patient. That’s a profound and unrealized concept.
Per the laws of capitalism, necessity is the mother of all invention. Developers want 2-way data exchange with EHRs, so they’re taking it upon themselves to make it a reality. Startups such as Human API and Validic are creating platforms that make it easy for developers to easily exchange data between previously silo-ed systems in real-time. Catalyze is simplifying the process of getting data out of complicated healthcare data files and stores.
Surprisingly, the major health information exchange (HIE) vendors, Mirth and Orion, aren’t going after these markets more seriously. They’ve been focused on connecting healthcare providers with one another, and analytics on top of that data. They’ve been less interested in pulling in additional data from patients themselves.
The federal government has been pushing the Blue Button initiative for some time, though it’s a one-way read-only API that’s limited to claims data: demographics, problems, allergies, meds, and lab results.
The silos that have characterized health IT are being slowly breaking down, in many cases without the blessing of the monolithic EHR vendors. This is perhaps the least hyped sectors of health IT, but one of the most profound. The companies that support robust data exchange will be in a position of significant market power with strong networks effects.
Off to the races.