3 questions to ask your healthcare API vendor
May 06, 2016
If you're reading this, you likely have a need to integrate your application with EHRs across the country (maybe even the world!). There are a handful of API companies out there, with us at Redox pushing the pack. As you review available solutions, it is important to ask the right questions and get past the marketing. This post overviews some really tough decisions we have had to make in designing our product, and why we made the choices we did.
What's Under the Hood?
Without a doubt, your API vendor is using some kind of data translation engine. For example, Mirth Connect is an open-source interface engine that supports lots of different standards. It is important to know just what your vendor is using and why. Redox is 100% built from the ground up by our dev team.
The reason we ultimately built or own engine is two-fold:
Cloud-scalability: Our vision for Redox is a massive network of data exchange that can only be accomplished through leveraging the computing power of the cloud. A micro-services style architecture means that your client's 5th health system is as easy to set up as their 500th.
Support the latest and greatest technologies: We love continuous integration and constantly improving our product. Depending on another project (even if open source) will not let us move fast enough to get the coolest new technology into your hands.
How Do You Connect to Health Systems?
We don't track of the number of years of Epic experience on the team anymore because we've been growing so fast, but it's over 100 years. In those 100 years, we learned what really works in getting projects live and reducing the burden on the IT team. Our approach to connecting to health systems is to establish a secure VPN between the health system and our cloud. Other approaches require an on-premise tool to collect the data and ship it out (something like this).
We think that VPNs are superior. Here's why:
A VPN often has the least amount of setup, and the most flexibility for the health system.
No Redox code lives at the health system, meaning we can provide the most powerful, flexible and up to date features to everyone.
Is the Back-End Standards Based?
As much as I tend to bash HL7 and others' standards bodies on this blog, we love them because they are all we have. They've been adopted. We've managed to get such a large number of projects off the ground so quickly mostly beacuse we are using standards-based exchange. James (our CTO) and I wrote a bunch of the code that does this at Epic, and most EHR vendors speak HL7 in one form or another. Would it be easier for us to plug directly into the EHR database? Maybe, but that brings with it a lot of maintenance issues as well as very real security concerns.
Here's why we love standards:
Less need for contracting with the EHR vendor. EHR vendors explicitly make standards-based interfaces to share data! This is a no-brainer.
EHR vendors will try their best to maintain backwards compatability. At Epic, we took great care to make sure messages coming out of an interface stayed the same from release to release. If you're tapping directly into the underlying database, there are no guarantees about what you are going get.
Why Redox?
We believe our answers to these three questions are positioning us (and you) to be the best API for all forms of healthcare exchange. We know that you can set up VPNs, learn how standards work, and build out a connectivity engine infrastructure. We're betting that we can save you time and money by doing it for you and letting you focus on making your application amazing. We're also taking the path most travelled when connecting to EHRs, meaning we can move fast, get the health system IT team onboard, and get you live in weeks, not months.
The Dev Team really loves working on our platform and we're happy to answer any questions you may have on Slack: https://www.redoxengine.com/community/.