Accessing & Using APIs from Major EMR Vendors–Some Data at Last!

Today I’m happy to release some really unique data about a pressing problem–the ability of small tech vendors to access health data contained in the systems of the major EMR vendors. There’ll be much more discussion of this topic at the Health 2.0 Provider Symposium on Sunday, and much more in the Health 2.0 Fall Annual Conference as a whole.

Information blocking, Siloed data. No real inter-operability. Standards that aren’t standards. In the last few years, the clamor about the problems accessing personal health data has grown as the use of electronic medical records (EMRs) increased post the Federally-funded HITECH program. But at Health 2.0 where we focus on newer health tech startups using SMAC (Social/Sensor; Mobile OS; Cloud; Analytics) technologies, the common complaint we’ve heard has been that the legacy–usually client-server based–EMR vendors won’t let the newer vendors integrate with them.

With support from California Health Care Foundation, earlier this year (2016) Health 2.0 surveyed over 100 small health tech companies to ask their experiences integrating with specific EMR vendors.

The key message: The complaint is true: it’s hard for smaller health tech companies to integrate their solutions with big EMR vendors. Most EMR vendors don’t make it easy. But it’s a false picture to say that it’s all the EMR vendors’ fault, and it’s also true that there is great variety not only between the major EMR vendors but also in the experience of different smaller tech companies dealing with the same EMR vendor. All the data is in the embedded slide set below, with much more commentary below the fold.

Health 2.0 EMR API report
Few easy onramps, and costs everywhere. Despite the noise about open architecture and the proliferation of apps stores outside of health care, and the work by standards and integration bodies like Commonwell, it’s tough sledding for health tech companies wanting to integrate with EMRs. Only two EMR vendors (athenahealth, Allscripts) were regarded as having a well-advertised, easy to access, partner program for smaller vendors. But almost all vendors impose costs and most small tech companies felt that they needed some pressure from their provider customer to allow them to integrate. But integrations can and have been done with all vendors including those regarded as the most difficult to work with.Of those roughly 30% of small health tech companies we surveyed who hadn’t (yet) integrated nearly all thought EMR integration would be a “nice to have”, but half though it wasn’t valuable enough to try and half thought the technical or cost wise it wasn’t worth it, or they weren’t far enough along in their evolution to attempt the integration. A few were focused on gathering data from other sectors (e.g. wearables or wellness) and we suspect a few others had failed in their attempt

Some vendors are better partners, and it takes work. Of those who did integrate, most EMR vendors were regarded as not supporting integrations (other than the 2 exceptions Allscripts & athenahealth). But when asked whether the individual EMR vendors hindered or helped in specific integrations, while NextGen & eCW scored poorly, Epic, Cerner & GE were about 50-50, while surprisingly to us McKesson (albeit with a smaller sample size and despite being on its way out of the business) joined Allscripts & athenahealth as helping in the vast majority of instances. The survey confirmed that for Epic in particular health tech companies need to have a client (70% saying it was needed) recommend them before Epic will help. Only Allscripts & athenahealth didn’t need a client in most (but not all) cases.

But the technical issues and other barriers remain. Most health tech startups we surveyed believe that the quality of the EMR vendors’ APIs which they did access is mixed to weak. With at least 25% of those using the Epic and Cerner APIs saying they were poorly designed, while that number rose to the mid 30%s for NextGen, GE, Meditech and was at 50% for eCW.  Only athenahealth (which clearly had the best API in this survey), Allscripts and McKesson had better numbers. While more companies used APIs to integrate than any other method, using 3rd party integration engines (Catalyze.io and Redox were frequently mentioned) and doing specialized batch data transfer were also used. Indeed, some commenters warned that the coming proliferation of APIs may make things more complicated.

Surprisingly costs weren’t regarded as a huge deal, with the majority of integrations being fee-free, and those who did charge mostly asking less than $25,000. The comments suggest a trend to demanding share of revenue or payment for bundles of services via integrations. Commonwell is charging $50K for (hopefully) access to a bundled group of APIs.

The potentially good news is that over 50% of tech companies integrating with EMR vendors are attempting to do complex integrations, rather than just read from the EMR or write back into it.

Not just EMR vendors to blame. While it’s been open season slamming the EMR vendors for being closed, There’s probably enough blame to go around. For example, health tech startups may not want to acknowledge the problem. Despite what we believed was aggressive outreach to nearly a thousand companies in our ecosystem we got a lower response rate than we expected. For those who did respond, once we went from asking generalities to asking details about experiences with individual vendors about 40% of respondents stopped the survey. This may of course be poor survey design and insufficient outreach but in several comments it appears that smaller health tech companies view integration as a competitive advantage, and even delivering anonymous information about specifics was regarded as a risk.

And of course, even though it wasn’t a specific topic question, in the comments providers–and especially their in-house IT groups–get a lot of flack from small health tech companies who regard them as a road block in many cases. Finally, some of the respondents criticized themselves (or other smaller health tech companies) for not adding enough value and not being worthy of effort from the EMR vendors—who we know have a great deal of other stuff on their plates, especially dealing with Meaningful Use.

And even if we fix the API access issue. While it was outside the scope of this survey, there’s a strong sense that we got, both in initial pre-survey interviews and in the comments, that solving integration, using APIs or not, is going to reveal a bigger problem. Data quality and standardization is very poor, and for most of the client-server EMR vendors, each data model is different. So on a population level, data exchange may require much more work correcting data before it’s ready for analytics and treatment.

Full disclosure, I, Matthew Holt am the owner/publisher of THCB and, yes, also Co-Chairman at Health 2.0. Kim Krueger was responsible for much of the work on this project and CHCF generously supported the work, although all the opinions expressed are mine

Categories: Uncategorized

Tagged as: , , , ,

8 replies »

  1. Great Post!

    Here is some top EMR vendors list. Who are best in the securing the patient date. Their systems not only help medical practitioners in the creation, storage, and organization of electronic medical records but also patient charts, electronic prescriptions, lab orders as well. The rating is taken by the Medical Economics, Captera and Software Advice.


  2. And for patients to manage their *full* health record on their smartphone, there is the innovative Andaman7 – http://www.andaman7.com – user friendly, complete, 200% open (see API http://developers.andaman7.com), no data abuse (we are an anti-cloud solution aka peer-to-peer), compatible with privacy, medical secrecy… (European level)… And based on a true story: http://bit.ly/a7vkblogen. I’ll be at Health Conf 2.0 and looking for partners, bus devs, investors (for mid 2017)… I will also demo Andaman7 – thanks Matthew for the invitation!

  3. Looks like Zac & Richard at MI7 have it all solved, surprised we’;re having this discussion!

  4. The standard for this is the JSON interface for over 37 EHRs by MI7 (http://mi7.io). Hundreds of digital health companies use it.

  5. I’ve been griping about “Interoperababble” for years now. http://regionalextensioncenter.blogspot.com/search?q=Interoperababble

    Also, another issue rarely mentioned: under HIPAA 45 CFR 164 et seq regs, any time PHI is created, viewed, edited/updated, transmitted, or deleted by a CE or BA, there must be a transaction “audit log” entry capturing “by whom, about whom, date/time stamp, and what data element(s)” metadata.