Events Calendar

Mon
Tue
Wed
Thu
Fri
Sat
Sun
M
T
W
T
F
S
S
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
14
15
16
17
18
19
20
21
23
24
25
26
28
29
San Jose Health IT Summit
2017-04-13 - 2017-04-14    
All Day
About Health IT Summits U.S. healthcare is at an inflection point right now, as policy mandates and internal healthcare system reform begin to take hold, [...]
Annual IHI Summit
2017-04-20 - 2017-04-22    
All Day
The Office Practice & Community Improvement Conference ​​​​​​The 18th Annual Summit on Improving Patient Care in the Office Practice and the Community taking place April 20–22, 2017, in Orlando, FL, brings together 1,000 health improvers from around the globe, in [...]
Stanford Medicine X | ED
2017-04-22 - 2017-04-23    
All Day
Stanford Medicine X | ED is a conference on the future of medical education at the intersections of people, technology and design. As an Everyone [...]
2017 Health Datapalooza
2017-04-27 - 2017-04-28    
All Day
Health Datapalooza brings together a diverse audience of over 1,600 people from the public and private sectors to learn how health and health care can [...]
The 14th Annual World Health Care Congress
2017-04-30 - 2017-05-03    
All Day
The 14th Annual World Health Care Congress April 30 - May 3, 2017 • Washington, DC • The Marriott Wardman Park Hotel Connecting and Preparing [...]
Events on 2017-04-13
San Jose Health IT Summit
13 Apr 17
San Jose
Events on 2017-04-20
Annual IHI Summit
20 Apr 17
Orlando
Events on 2017-04-22
Events on 2017-04-27
2017 Health Datapalooza
27 Apr 17
Washington, D.C
Events on 2017-04-30
Articles

What a Real Open EHR API Should Accomplish

open ehr api

There’s been a lot of talk in the EHR world about APIs and most of the time they talk about it as an open API. The problem is that there’s been a lot of talk about EHR APIs and not a lot of action. Having an open API is more than just giving a couple people access to some really small subset of your EHR. We need truly open EHR APIs that are more than just a nice press release.

A successful EHR API requires two core elements: Access to EHR Data and a User Base.

The first element is the obvious one and the one that everyone focuses on. An API needs to have access to the data in the EHR. This includes accessing that data for display in an outside application. Plus, it requires that an EHR accept data from an outside application. EHR APIs seem to fall short on both of these areas. Most only give you access to some really small portion of the EHR data. Even fewer let you write any sort of data to the EHR.

If you don’t give an outside application the ability to access the EHR data and write data to the EHR, there are very few applications you can build on top of it. Is it any wonder that the third party EHR developer community isn’t doing more things with EHR software? If they had these two things, EHR vendors would be amazed at what they’d build. I love Jonathan Bush’s idea of “every surface area” of athenahealth being available in an API. If he achieves this vision, third party developers will flock to that EHR and enhance it in ways that would have never been possible for athenahealth to do on their own.

The second piece is just as important to an API. EHR API developers need to get access to your existing EHR user base. This doesn’t mean you have to give them a list of all your clients. It does mean you need to feature the work of these third party developers to your existing user base. This can be in your application, in an email list, at your user conference, etc.

Think about the message you’re sending to your developer community and your existing user base when you do this. The developer community wants to build even more functionality into your product. Your EHR users get more value out of your EHR application thanks to the development efforts of an outside party. Plus, ambitious EHR users can even create their own functionality using the EHR API.

I can’t wait for the day that EHR vendors fully embrace the idea of a third party EHR API. There are so many outside companies that would benefit from an EHR API, but the EHR vendor will benefit just as much. Plus, the real winners will be the EHR users and patients who get the functionality they’ve been wanting from their EHR that the EHR vendor couldn’t deliver.

(Source)