EHR Integration APIs have finally made their way to healthcare. While they promise to change the way health information is shared, there are a few things you should know before treating them like any other API.
1. They generally require human collaboration.
Most APIs are pretty hands off—you read the docs, acquire an API key, set up a verification token, and if you follow the rules, you’re up and running in no time. Healthcare APIs are different—due to security concerns around personal health information (PHI), healthcare APIs are never 100% hands-off experiences.
EHR vendors who create their own APIs for data exchange will publish how you’ll send, receive, and query information. They’ll show you the structure of the messages and what to expect, and in some scenarios, they’ll even offer sandbox environments and developer tools that allow you to simulate exchanging information. Before you exchange health information in a production setting, though, there will need to be negotiations between the organization that owns the data and the organization looking to utilize it.
In other instances, because the EHR vendor has developed the API, there are two stages of negotiations before they are usable: with the healthcare organization and the EHR vendor itself.
2. Available information varies wildly.
Each EHR vendor has developed their API independently from one another and because of this, available functionality of each is very different. Certain vendors offer read-only APIs while others allow you to query for specific use cases like “available open slots” in a provider’s schedule. Some may allow you to write in discrete values but not contextual notes. You will need to closely examine each EHR vendor’s API to understand what functionality they support.
The one thing to remember: don’t expect them to be the same or that a workflow you executed using one EHR API will be supported at another site.
3. How data is structured varies wildly.
How does the EHR API list male and female? When and where do they use SNOMED or ICD-10 codes? How do they structure dates for medications? Because all vendors are independent, each has developed unique APIs. This leads to incompatibilty and variance across systems, and as any developer can attest to, not all APIs are created equal—functionality, ease-of-use, and supporting documentation differ from API to API.
As you explore EHR APIs, a wide range of quality and functionaliy may leave you more frustrated than excited.
4. EHR APIs aren’t always well supported.
Here’s a dirty little secret: a lot of EHR vendors don’t put a lot of energy or resources into supporting their APIs or vendor programs that are required to use them. Don’t get us wrong, some are very supportive and 100% behind their APIs, but others… well, let’s just say it isn’t rare for an EHR vendor to make a marketing push, put up a web page, and then just point to it as a way to show they are supporting the push for healthcare APIs.
Another common practice is to create an intentional bottleneck when it comes to granting access to APIs by staffing one or two people to handle all of the requests from vendors. This inherently limits the speed at which access is granted and APIs are used. The best data around this is found in Health2.0’s recent survey on using EHR vendor APIs.
5. They’re here to stay.
Healthcare APIs offer exciting advancements on what can be done with health information. They promise to make it easier to adhere to HIPAA’s “minimum necessary” mandate and offer flexibility when it comes to querying for specific things like “open slots in a provider’s schedule”. When delivered and utilized effectively, they’ll open the door for more developers and innovators to create solutions that leverage the wealth of data created and stored in EHRs.
There are real limitations around them being developed independently and they have a long way to go before they offer robust, delightful experiences, but regardless, it’s an undeniably promising time for the future of health information exchange.
Feeling frustrated yet?
We don’t blame you—variance across EHR APIs can lead to prolonged projects, endless product redevelopment, and the need to constantly be learning new APIs.
Luckily, Redox realized that the only way to eliminate these issues to offer a single API that is vendor agnostic and delivers a consistent experience across all EHRs. This means that instead of interacting with hundreds of APIs, you only have to experience one—and it’s easy to use, too!
Our solution helps you exchange healthcare information without the headache. Reach out to learn more about our API and how it solves healthcare interoperability.