APIs have been the preferred means of information exchange by developers for some time now. They allow querying of large data sets for specific pieces of relevant information that can be used for a variety of purposes in a clearly outlined, repeatable way.
The explosion of niche technology solutions that leverage information collected and stored by larger platforms has been driven by APIs. Mint, for example, wouldn’t exist without APIs facilitating the access and exchange of personal financial information from banks and credit card providers. Buffer wouldn’t be useful if they weren’t able to use APIs to access information and directly post to social media sites like Facebook, Twitter, and LinkedIn.
In a sense, APIs have liberated data and laid the foundation for a world where one organization with enough useful data can give rise to an entire ecosystem of companies finding valuable ways to use that information to grow their own business while adding value to the original platform and it’s users.
The preferred method of data exchange for nearly every other industry is finally here to make patient information accessible and actionable—healthcare, an industry that has long sat firmly in the “laggard” portion of innovation adoption, is finally embracing APIs. This article will introduce you to the organizations leading this charge; in subsequent articles, we’ll will discuss the unique challenges facing healthcare API providers as well as what developers need to know in order to navigate the evolving (and admittedly convoluted) landscape.
Understanding the healthcare API landscape
Healthcare is a pretty broad term. When politicians refer to it, it’s often to point out that it’s driver of 1/6th of the United States’ GDP. A recent publication shared that roughly one in nine Americans works in healthcare. Obviously, an industry so large has a lot of moving pieces, so for the sake of this article, we’re going to focus on patient health information (PHI) that’s collected and stored as part of care received at healthcare facilities (practices, hospitals, etc.). More specifically, we’ll focus on PHI and the associated claims data which is used to bill and collect payments from insurers. We will also briefly touch on the growing field of quantified self-data (collected by wearables and other means) and the APIs making that information usable.
Player 1: EHR vendor healthcare APIs
For the healthcare newbie, an EHR is an Electronic Health Record (synonymous with EMR or Electronic Medical Record). At a high level, it is the digital representation of a patient’s medical record. At a “how it’s used in real-life” level, it’s the software system that healthcare organizations use to treat patients (place orders, prescribe medication, etc.), document encounters, store patient information, and submit claims to get paid for services delivered.
There is a broad range of EHR software systems with certain players dominating specific areas of the market. Epic and Cerner are the largest and dominate the large hospital and academic medical center market. Other systems such as athenahealthand drchrono cater to practices. The long-term/post-acute market is primarily owned by PointClickCare, while niche EHRs like Flatiron target specific specialties like oncology.
We won’t list them all here because there are hundreds of EHR vendors (Redox alone has established integrations with 35+ unique EHR systems), but the thing to note is that these software systems are the main PHI repositories being used everywhere from your dermatologist office to the emergency room.
Though health information is technically “owned” by the patient, it also belongs to the organization which bought the EHR and maintains the record in a digital format. This dynamic is why healthcare organizations—not patients—are the leading brokers of health information today. Ultimately, the healthcare organization “owns” the healthcare data and authorizes who gets access to utilize it.
While the healthcare organization decides who can access health information, the EHR vendor is the one that dictates how that information is obtained from a technical perspective. For a long time, the functionality of EHRs left quite a bit to be desired—read any of the hundreds of articles bemoaning healthcare’s interoperability problem and the claims of data blocking laid at the feet of EHR vendors and you’ll quickly realize that this has been a point of contention for some time.
Bringing this landscape overview full-circle, this is where we come to healthcare APIs created by EHR vendors. In an attempt to satisfy their customers—the practices and hospitals who have purchased their software—EHR vendors have begun to expose APIs that improve how stored PHI is made available to authorized parties.
While most EHR vendors proudly market their APIs as sophisticated and efficient mechanisms for health information transfer, the actual success and usability of these APIs has been a mixed bag.
In 2016, Health2.0 and the California Healthcare Foundation released a report titled Accessing & Using APIs from Major EMR Vendors. This report solicited responses from hundreds of digital health companies about their experience working with APIs made available by EHR vendors. You can view the full results of the survey here, but a few of the main takeaways are:
- Not all APIs are created equal—functionality, ease of use, format, and other features differ from product to product.
- EHR APIs are still very nascent and have a long way to go before they can match the clarity and ease of use of an API like Stripe or Facebook.
- EHR APIs are not true APIs in the sense that they are published and made available to anyone who follows the outlined instructions—even when a healthcare organization grants a new vendor access to information, the EHR vendor themselves has to get involved in order for groups to actually use the available APIs.
- Excluding athenahealth and Allscripts, the partner programs that help technology providers understand the various EHR APIs lack true commitment and support from the EHR vendors themselves.
The major issue facing healthcare APIs is that functionality varies wildly by both the vendor as well as the organization using the EHR. The reason? Each vendor has embraced APIs to varying degrees, and some are far more mature than others.
Furthermore, remember that part about healthcare being firmly in the laggard portion of technology adoption? Well, this also applies to how organizations treat their installed software systems. Even where EHR vendors have made more robust APIs available, for that functionality to be used at an organizational level for data exchange, the hospital or practice needs to update their existing system. More often than not, healthcare organizations act like your friend who ignores every iOS update—for a real life example of how lagging updates can be impactful, look at the recent ransomware attack on the NIH that exploited the fact that the majority of computers were running an outdated version of XP.
Today, most major EHRs have made some form of APIs available. We will provide an inside look at each of these at a later date. For now, you can explore a few by following the links below:
- allscripts Developer Program
- (note there are 3 distinct ways to connect)
- athenahealth API
- Cerner API
- drchrono API
- Epic API
One key thing to remember about EHR APIs…
They are only useful for that vendor’s customers. This is one of the biggest challenges facing healthcare innovators today—their product’s functionality is severely influenced and limited by the existing software systems in use by their customers. Most healthcare technology solutions have a consistent workflow.
Let’s take a canceled-appointment-filling solution that helps practices minimize revenue lost and gives patients the option to schedule appointments as they open up. This application needs scheduling information, notification of canceled/changed appointments, and the ability to schedule new appointments directly into those slots. This is a fairly straightforward concept that provides obvious value to patients and providers. Unfortunately, that technology vendor will need to learn what systems each of their customers use and how to execute this same workflow with different systems. This requires custom development, and at times, the realization that the systems in place can’t support the functionality required with available APIs.
We’ll get into this more later, but this reality is one of the reasons we’ve seen a new entrant into the healthcare API market: the vendor-agnostic API.
Player 2: Claims-specific healthcare APIs
There are two primary sources of truth when it comes to health information: EHR data and Claims data. Claims data covers services performed, for whom, by whom, at what facility, at what cost, and who is supposed to pay for it. As you may have been able to guess, they are, of course, generally stored in different places by different vendors using different data standards. (Reminder: this is the Rise of Healthcare APIs, not the “fully realized and awesome to use reality of healthcare APIs”.)
When it comes to healthcare APIs focused on Claims data, two solutions dominate the space, Eligible and Pokitdok. While both do little with data direct from EHRs, these organizations have taken a Claims-focused approach to sharing health information and offer robust APIs that offer valuable services.
Player 3: Quantified self-specific healthcare APIs
While what we’ve talked about to this point has been health information stored and made available at a macro level, there’s been exciting developments when it comes to empowering patients to be the owner and broker of their health information. One of the trends leading this push (beyond patient’s inarguable right to access and share their health information) is the explosion of wearables and the ability for patients to track everything from their activity levels to consumer-grade genomic data from providers like 23andme. When it comes to enterprises using information collected from wearables, Validic has taken a dominant position in the market. While they don’t have expertise in EHRs or Claims, they are a skilled aggregator and broker of data collected by devices such as Fitbit. A competitor in the space is Human API, who also focused on patient-generated data and offers APIs to make sense of it all.
Player 4: Enterprise API providers
Healthcare is too big to go unnoticed by major players from other industries. Over the last few years, we’ve seen more and more bets placed on healthcare by everyone from Apple to Under Armour. When it comes to Healthcare APIs, the notable entrants are major API providers and management solutions used in other industries like finance. To be sure, what they lack in healthcare expertise, they make up for in size and financial resources. The two that are making the strongest moves into the space are apigee–apparently on behest of acqui-hiring boss Google–and Mulesoft. Dell Boomi and Jitterbit have also made their intentions to expand their offerings to healthcare known.
To date, these groups are more focused on helping enterprise customers manage their APIs rather than exposing a standard API to facilitate health data exchange. They’re likely to support integrations and services outside of health information, and while they possess a lot of resources, it’s still unclear what their direct play in healthcare will be. They can’t help but explore healthcare’s vast marketplace, but when it comes to their core products, they’re likely to continue focusing on less regulated and faster moving industries.
One thing is for certain, though: massive companies are sniffing around, and their marketing teams are ready to make it seem like they have the answers to all of healthcare’s problems. Separating the wheat from the chaff with these groups will be an ongoing process.
Player 5: Vendor-agnostic APIs
Rounding things out are healthcare APIs that homogenize EHR variance and empower health information exchange between any two entities through a single API. Redox has taken the lead in this market by offering the only publicly available healthcare API that integrates with any EHR, regardless of its vendor or data standards. If this sounds too good to be true, it’s actually not—it’s the product of years of development and thought on how to truly solve interoperability.
A vendor agnostic API is only possible by taking a networked approach to healthcare interoperability. By acting as the central intermediary to which various healthcare organizations and technology providers connect to, Redox can account for and abstract away site-specific variances. Simply put, this allows organizations to share data with anyone.
The unique realities of healthcare have produced databases like EHRs that are impossible to utilize in a consistent way. However, Redox’s networked approach accounts for variance across sites and provides an API that adapts to whatever standard and data format is being used by a given EHR. This results in an API experience that is consistent, reliable, and compatible for use with any authorized entity.
Where do healthcare APIs go from here?
If you’ve made it this far, congratulations—you have a solid background of how and why healthcare APIs are on the rise. And we’ve got good news to round out this post: the future of healthcare APIs and what people can do with healthcare data is inarguably bright. The best way to exchange information is finally taking root and will facilitate innovative medical breakthroughs getting into the hands of patients and providers faster.
The major challenge moving forward will be how various healthcare APIs evolve. Will they focus on a specific area? Will they evolve to support additional use cases? How will the market shake out? That story is currently being written, and all we can do now is keep an eye on how things develop and see which direction groups decide to go.
As the only truly interoperable healthcare network and the only healthcare-focused, vendor-agnostic API on the market, there is a lot we can help with. If you’re an organization looking to share health information, contact our solutions team at [email protected] or check out our developer portal to learn how you can start building and testing an integrated healthcare application in just a few minutes.