5 takeaways from Health 2.0’s: Accessing using APIs from major EMR vendors survey

October 5, 2016
George McLaughlin Director of Solutions Marketing

Recently, Matthew Holt (THCB, Health 2.0) released the results of a broad survey titled Accessing & Using APIs from Major EMR Vendors. With over 100 responses from digital health organizations, the data paints a vivid picture of the current state of healthcare integration.

As the leading integration platform for digital health applications, this survey hit close to home. We’ve helped our customers integrate with dozens of EHRs and have experienced first hand the various roadblocks and inconsistencies that many of these survey respondents touch on.

We’re very appreciative of Health 2.0 and the California Health Care Foundation for putting in the effort to solicit these responses and make the results public. As a community, understanding the actual experiences and roadblocks faced by groups working to develop and deliver solutions that improve patient care is vital to making them a reality. Together, we can share best practices, separate the truth from rumors and marketing campaigns, and when necessary, apply pressure to organizations that are impeding progress.

I highly recommend anyone interested in this topic to review the full results of the survey along with Matt’s commentary over at The Healthcare Blog.

Here are five findings that I found particularly interesting:

1. Epic tied with Allscripts for the most number of successful integrations by respondents.

For all the heat Epic gets for being a “closed-system”, this graph should cause a few smiles out in Verona. While it’s true Epic doesn’t roll out a red carpet for vendors to integrate with their customer’s Epic instances, we’ve found the path to successful integration with a health system using Epic to be quite clear. An Epic site will have an on-premise interface engine with various inbound and outbound interfaces that can be leveraged to satisfy digital health vendor’s data needs. Additionally, they will have dedicated staff that are capable of executing various tasks like building flowsheet rows for inbound clinical values from a medical device. Our model is built on minimizing the amount of effort required by health system IT resources, but you still need someone capable of picking up the phone and completing a few critical tasks. When it comes to small sites and vendors, even the smallest task can prove to be quite difficult, as there’s fewer people around to help. I’d like to mention here that Cerner sites also have ample staff available to execute tasks and a clear path to integration. Shoutout to Allscripts and their ADP program as well. These results show they’ve made significant strides in making integration achievable for vendors, and they should be applauded for their efforts.

2. Third party integration providers are making their presence felt, but still have a ways to go.

This graph is particularly interesting for us as our product and services most likely fall under the “third party integration engine” category. We should all take a mental snapshot of this breakdown and revisit this question in a couple years; I believe the difference will be staggering. The limitations of batch processing are obvious with the development of more sophisticated solutions that rely on real-time data flow, and the idea of building against individual APIs for each EHR vendor when you could build against a consistent standard by working with a third party like Redox feels silly. Digital health solutions are built with a certain group of patients or providers in mind, not which EHRs are in use. Working with a vendor that allows your solution to implement wherever you users are without worrying about what systems are in place just seems prudent.

3. Digital health applications still feel they need to work with the EHR vendor to integrate their solution.

Going directly to an EHR vendor for help integrating your product is a tough path to take. Very rarely are incentives aligned, and, more likely than not, your solution represents direct competition to functionality they provide (or are working on). Additionally, if your solution requires an integration that needs significant involvement from the EHR vendor at your customer site, it’s probably worth questioning your strategy. We speak with groups all the time who have grandiose visions of magic buttons and embedded iframes, and while these integrations are possible, they require more time, effort, and present more opportunities for someone to say “no” and squash the project all together. We work with our partners to develop integration strategies that cover absolute must-haves and limit the work required by the health system. We often execute complete integration projects without ever bringing the EHR vendor into the conversation. If you haven’t been able to integrate because of push back from an EHR vendor, give us a call—there might be a different way.

4. Even when available, EHR vendor APIs leave a lot to be desired.

The availability of APIs in healthcare is undeniably a step in the right direction. That being said, it is important to understand that they can be frustrating to work with because not all APIs are created equal. Excluding athenahealth, it appears all EHR vendors have a long way to go before their APIs are loved by developers. Our team is working hard to create the most consistent, delightful API in healthcare—and we’d love to hear what you think of it. If you’ve reviewed our docs (create a free developer account to check them out) what did you think? Where would you rank us compared to other APIs? What are some APIs that you look to as the gold standard (they don’t even have to be in healthcare)? Comment below if you have any thoughts.

The benefits of access to clinical data for digital health solutions is undeniable. Even the vendors that have not integrated their solution admit that it would “enrich their application and improve user experience”. For too long, the technical complexity and costs associated with integration forced digital health solutions to settle for a less-than-optimum-experience for their users. This needs to change and we’re incredibly excited to be developing a new paradigm where the focus is solely on providing the best experience for patients and providers.

With FHIR and Meaningful Use Stage 3 on the horizon, the landscape of healthcare APIs will continue to evolve. This survey is a fantastic snapshot in time of where digital health stood in 2016, and it will be incredibly interesting to come back to in the coming years. Many thanks to everyone who helped make this a reality!

Stay in the know! Subscribe to our newsletter.