Digital Health Transformation Strategy

Post navigation

Open.Epic: A (Not So Open) API

If one more person describes Epic’s new API as being “open”, I’m going to turn purple. Don’t let the URL fool you: http://open.epic.com/

Last week EHR vendor Epic unveiled it’s new API (application programming interface) targeted at developers — more specifically at remote patient monitoring companies and health/wellness apps or portals. Epic seems to have had second thoughts about the site since only remnants of the landing page are still there as of today.

Not to worry. As a public service, I kept a copy and have reproduced the text below — with personal annotations/translations added.

What’s Wrong With Epic’s API?

What’s wrong with Epic’s API from a developers POV? Data goes in. It doesn’t come out. If you are a developer, this is a great way to disintermediate yourself — you create all the value, Epic captures all the value.

Would you bank at an institution that allows you to make deposits, but not withdrawals?

Despite the chatty language that was on Epic’s website, their API is a continuing extension of Epic’s ethos of control rather than collaboration. It’s downright condescending.

What part of health information exchange do they not get over at Epic?

Enough banter. Let’s get to the meat of it.

Open.epic Website As of September 18

I’ve reproduced below text that was found on the open.epic website as of September 18, 2013. (The parts in parentheses and red text represent my personal additions).

Here is it (or was):

Ready? Let’s do this.
Data-driven healthcare is possible when the data is available (to us), reliable, and actionable. With open.epic, we’re doing whatever it takes (“whatever it takes”—did we actually just say that?) to make personal tracking data integrate with clinical records to drive better care. Here, developers who collect this data can find the APIs, sample code, and implementation guides to put that data in the hands of clinicians. Together, we’ll create the tools to put this data to work.
Here’s how it works (graphic)
We think that a careful approach and elegant integration of this data can open new possibilities to supplement how clinicians make decisions today.
We invite you to join us in this exploration.

for developers (not you patients, the general public, the press, or anyone else)
Learn more about how to connect and why to connect. Sign up for documentation.

Are you a manufacturer of a consumer-facing monitoring device? We have an API for that.
Have you developed a health or wellness-related tracking app or portal? Clinicians need that information. (Not that we considered that patients themselves might also want this information.)
We’ve designed open.epic to make it gosh-darn simple to integrate the data you collect into your patients’ medical records. Interested? (whaddya think of the Wisconsin friendly “gosh-darn simple”? It’s designed to throw you from our real view that we continue to be the center of the patient record universe.)

the technical stuff
Let’s walk through the flows in a little more detail, so we can collect some information about the data you collect today and how you collect it. That information will be used to create the documentation package that matches your needs, without a lot of stuff you don’t need to worry about. (Isn’t it great that we think FOR you? Never mind your pretty little heads. Just trust us.)
Establishing identity
To exchange data with an electronic health record, the very first step is to make sure we’re talking about the same patient.
We’ll need to know how you manage identities within your application to figure out the best way to link the two together.
Online account
Mobile application
Other
Filing data
Once we’ve linked your app or account with the patient’s online account at the organization where she receives care, she’s free to start taking readings or entering data. Those readings, when filed back to the electronic medical record as discrete data, can be used for population management, risk scoring, or within complex visualizations in the context of other clinical information on file. As such, it’s pretty powerful! (Yes, YOUR data can now become OUR data. We understand that in a digital economy that data is currency, and we gosh-darn really appreciate your sending us YOUR data for OUR EMR.)
This step is optional, but its clinical and operational benefit to organizations is substantial, and your support could make your app more valuable to them.
We’ve listed the types of information that might be clinically relevant below. What do you collect? What would you like your patients to be able to share with their doctors?

Blood Pressure

Heart Rate

Breathing

Weight

Exercise

Eating and Food

Elimination

Blood Glucose

Sleep

Mood

Environment

Fertility

Prenatal

Development

Other

Visualizations
Getting data discretely into the EHR opens up a lot of opportunities, but it’s not the only way to bring information to clinicians. Optionally, you can provide your own visualizations for your data as well. If you choose to support this functionality, clinicians will be able to see your rendering of the patient’s information from right within their visit workflow, without having to leave the EHR or log into another portal. (Physicians will be able to see how YOU think about the data. You want to understand how physicians might think about the precious data you’ve provided?? That’s another story.)
This step is optional, but if you offer slick ways to see their patients’ data, clinicians could be more likely to appreciate what you have to offer, and advise their patients accordingly. ( You create the value, we’ll take the credit.)

HTML

Other

GET THE DOCUMENTATION

answers
If you’ve got a question that isn’t answered here, shoot us an email at open@epic.com.
Why should I integrate with you?
You’ve built something that you think has clinical value to your patients. If they want to share the information they collect in your app or solution with their clinicians, then this integration is a great way to do it. We make software for mid-size and large medical groups, hospitals, and integrated healthcare organizations, and we’re used by community hospitals, academic facilities, children’s organizations, safety net providers, and multi-hospital systems. Organizations that use Epic care for 51% of patients in the U.S. (yes, your uncle Louis’ lab test from 2006 counts as part of that 51% , even though that’s all we know about him. You didn’t think that we meant this 51% as some sort of complete and rounded picture of a patient, did you?) and 2.4% of the world. Creating this connection once means you’ll be able to provide that feature to a good population of your users.
Is this all you’ve got?
Of course not! A list of the different types of vendors our customers integrate with today can be found here. (Note that when you click “here” you’ll see a list of categories, not companies. That’s how we treat all our “partners”. We’re not sure that we consider anyone up to being our “partner”). We participate in numerous standard setting bodies, and we encourage you to also review our IHE integration statements. (We do this to slow down Health IT standardization as much as possible.) In the coming weeks, we’ll be updating open.epic.com with our other public APIs and a list of the developers currently taking advantage of them.
Do I have to sign an NDA?
Gosh, let’s try to avoid that. How’s this – we won’t show you anything we think is confidential. Sound okay? (We will send you OUR standard contract, written by OUR lawyers. If, however, YOU violate any terms, YOU will hear from us. Sound okay?)
Will you sign an NDA?
Do you think we’ll need one? Could you complete your part of the integration without revealing confidential information to us? (You want confidentiality from us! EPIC!! Who are you frickin kidding? Let’s get this straight. We just want your data. The contract our lawyers are working on will say that YOUR data is now OUR data and that we can do anything legally permissible we want with it.)
How would I do that?
We’ll try to make it easy. In the coming months, we’ll be publishing test harnesses and creating development sandboxes, so you can simply test how you call our webservices on your own. You won’t need access to our EHR itself (not that we would ever think of actually allowing you access to OUR EMR or OUR data.), and in turn, we won’t need to see your software (we really don’t care about your software, we just want your data).
Will you charge me to integrate with Epic?
That shouldn’t be necessary. (It’s enough that you and your investors create all the value and that we capture all the value.)
Can I charge Epic to integrate with me?
Sure! In that case, we might need to levy a convenience fee, which coincidentally would be the exact amount you will be charging us. (That’s Wisconsin-snotty, in case you didn’t get it.)

We think this will be a pretty neat idea (back to “Wisconsin-friendly again) , and we hope you think so too. We’re currently working to refine our approach before widescale distribution. Fill out the information below to get on the list for updates and final documentation. And let us know what you think! (We had to pay our Wisconsin PR agency 3 cows to come up with phrases like “sounds okay”, “gosh-darn simple”, “gosh”, “let’s do this”, “sure”, “slick” and “let us know what you think”. Was it worth it? Do you trust us now?)

Top of Form

YOUR COMPANY
YOUR WEBSITE
TELL US MORE ABOUT YOU
WHOM SHALL WE CONTACT?
ROLE
EMAIL

So while this is funny, I do agree with StevenA’s comment re what other EHR out there is offering this type of integration to Devs. A lot have promised, who else has delivered? I also know a lot of Devs who are really psyched about this announcement, they see it as a way to get access to potential customers via Docs prescribing or recommending their apps now that they can actually see the data and its value.

StevenA please educate yourself on Blue Button and then show me what other initiative or EHR out there is even close to getting data out of the medical record on behalf of patients into a consumer application. Don’t hate on ONC just because data holders like Epic aren’t doing the full implementation that they are being asked to.

As a developer, Epic has made it easier to integrate than any other major EMR provider I’ve worked with … this said, its very difficult to integrate with Epic — but it is possible … with supporting documentation and the right level of hospital system support. I think the biggest sin of Epic is actually their (incredibly unfounded) fear of publicity and a fear of publicly documenting how to integrate. The net result is the public view of Epic is horrible and no one thinks they can get data out. In reality — every large scale EMR makes it very hard, but Epic is the only common one with well documented APIs (just not public facing)!

AnonMD: Shouldn’t we hold the bar a little higher for Epic who claims 51% of the population in their systems and gets a massive amt of taxpayer funded revenue? It’s true that the modernity of EHR vendors is abysmal but that’s a stupefyingly low expectation to hold out as an excuse. I believe Practice Fusion (another vendor who drastically overstates their market reach but still is a big player) is integrating with biometric devices. The tech work to enable this, btw, is trivial.

It’s a sucker’s bet for app developers to give their value away and think it’s going to benefit them. There’s no reason NOT to share the data and be a good example but thinking they will realize value back is naive. Until it’s a two-way street, the value is limited.

It’s fun to bash Epic but they are enabled by their customers who also have the mistaken impression that they are the center of the universe. That medieval-era view will ultimately speed their demise as modern healthcare providers recognize that’s it’s not a marketing gimmick to put truly put the patient at the center. Instead, it’s the only way to succeed in the post fee-for-service world.

StevenA – with varying degrees of friendliness and openness, many other EHR vendors are opening APIs to developers – AthenaHealth, Practice Fusion, Greenway, Cerner, Allscripts… This is an inevitable evolution in the market; no vendor can do it all.

My article is written from the POV of the developer. You’re at an IDS, so you too might have a POV similar to Epic. Best case scenario though would be to create win/win and have 2-way info exchange.

AnonMD – Can you name developers that like Epic model? Or just ask them to comment here? I don’t doubt that there will be a few unique biz models where there might be a fit.

You suggest Devs might see Epic as access to potential customers. Let’s play this out. So a dev connects to Epic; Dr. views dev data through Epic EMR and makes a change in patient treatment plan; data recording this goes into Epic EMR and presumably patient can access through Epic patient portal.

This is the exact scario where the dev cuts themself out of the loop; since data flows only 1 say, the dev app will not have record of Dr. change in treatment plan. No reason for Dr. to recommend the app or for patient to go to the app. Epic portal is positioned as center of the universe and dev is disintermediated.

Anon – Let’s differentiate between past INTERFACING (very costly; a single, unique connection between Epic and another vendor) and an INTEGRATED API (which should allow for low cost & generic connection between EHR and many vendors, e.g., Apple has 1 million apps in app store).

Since Epic has not had a true API in the past, I presume you are referencing INTERFACING work you have done as a software dev? Help me understand how this relates.

Regardless, market will inevitably move toward more open, plug-and-play modularity. Epic will figure out they do not want to be like Wang.

Idaho Bear – we are on same wavelength: “sucker’s bet for app developers to give their value away.”