If you’re new around here, there’s something we have to get out of the way: healthcare is weird. It doesn’t work like any other industry. So if you’re used to APIs with financial institutions and social media platforms, brace yourself. While most of what you see will be very familiar, there are some key differences to keep in mind.
#1 Redox does not sit on a single database of information.
Remember when I said healthcare was weird? Well, in most cases, health information is stored in highly customized, siloed databases on premise of healthcare organizations around the country/world. There is no single database of health information. It is fragmented across organizations which cover specific patient and provider populations and use different software systems.
Two problems that most APIs don’t have to solve, Redox solves for healthcare:
- Connectivity to on premise systems
- Data standardization across implementations
We connect to and gain access to the data stored in these different systems and allow you to receive, send, and query information with them over web services via a consistent data standard.
Before you can use Redox to exchange health information with another organization, they must also be established as a node within the Redox network. That is the only way we can access that unique database and execute the workflows your product requires. Thankfully, organizations only need to connect once with Redox before being able to share information with any other authorized member of the Redox network. More on that later.
#2 You will need to work with us before exchanging production data with another member of the Redox network.
We offer developer tools that allow you to exchange sample messages as if you were integrated and sharing information through Redox, but before you can do so in “real life”, you (or someone on your team) will need to work with our solutions team. Our Solutions team is responsible for making sure entities are authorized to share information legally and technically through Redox. One part of this is business stuff—contracting, legal, security review, etc. The other part is technical—we have to set certain flags in our engine that allow two nodes to share specific pieces of information. You’ll learn about this later, but these are called “Subscriptions” they show what information types have been authorized to be exchanged between what nodes. When it comes to getting things setup, there are three possible scenarios:
- Net new nodes
- One new node, one established node
- Two established nodes
For this brief overview, note that the level of work and time required to get live and exchanging information covers these three scenarios and goes from most work to least work (Option 1 > Option 3).
Why do we need to get involved? One acronym—PHI. Personal Health Information for the healthcare newbie. It’s a really big deal to exchange people’s health information and because of that, there are a lot of regulatory and compliance hoops to jump through before you can access it. It’s a good thing and we make the process pretty painless so don’t worry too much. Just know that it is a little different from APIs you’ve used in other industries. The data will look the same. The way you will send and receive it will be just as we’ve outlined. But before you are doing so in a production setting, you’ll need to work with us and your partner/customer on the other side to make sure everything is kosher.
#3 Redox is “REST-inspired,” not truly RESTful.
GET, PUT, POST, and DELETE right? Everything you need is waiting for you, ready to rock-n-roll… right? Not exactly. Redox is in many ways an abstraction layer. We sit on top of a bunch of systems that have different data standards and preferred methods for exchanging information and we distil it down to one data standard and one means of exchange. That being said, we have to accommodate the source systems and their little quirks. One of those that is common in healthcare but diverges from other industries is the EVENT based architecture that most Electronic Health Records (EHRs) use to exchange information. Basically, instead of a central database that you can query at any time, these systems are set up to send messages any time an event takes place. It’s transactional and a lot of our integrations leverage this.
What does that mean for you? Well, instead of planning to GET things like scheduling information, you’ll most likely subscribe for EVENT updates any time scheduling messages are sent from the source system. This means instead of issuing GET requests on a certain interval, you will establish a webhook (your Destination endpoint) that we can POST to any time the source system has a relevant transactional event.
When you use this subscribe for event updates at a webhook versus when you issue GET requests depends entirely on the system you are sharing information with on the other side. In healthcare, the majority of systems are setup to send information via the subscribe model but more and more are expanding functionality to act more like RESTful APIs you’re familiar with.
Today, the most common queries utilize our ClinicalSummary and PatientSearch data models. These allow you to retrieve a patient’s Continuity of Care Document (snapshot of their medical record) and Medical Reference Number (MRN) respectively. Additional queries to support your information exchange needs will be made clear as part of the implementation process and will depend on the system you are integrating with’s capabilities.
At the end of the day, this all goes back to #1 and #2. Healthcare is weird and we have to accommodate for a wide range of systems. The specific workflow that will be relevant for an integration with a partner will vary based on their existing architecture and what those systems are capable of. What you can count on is that Redox will enable you to exchange information with that system over web services via a consistent data standard. The slight workflow variances across sites will be made known as part of your initial setup that our Solutions team will guide you through.
Ok, Redox is different from other APIs. I got it. How do I get started?
The best way to get started is to get familiar with our terminology and how we structure things. We’ve written a few articles designed to get you up to speed as quickly as possible. After you’ve read all of our “Introduction to Redox” articles you will understand:
- How we handle connectivity and data translation across nodes of the Redox network
- How we structure our Data Models
- What it means to be a Source and/or a Destination
- What Subscriptions are and why they matter
- The difference between Messages and Transmissions
- How to navigate your Dashboard
After that, you’re ready to create your own Organization by signing up for a free Developer account. From your Redox dashboard, you will be able to use our Dev Tools to start testing what integration will look like. Simply follow the “Getting Started” articles listed below to get up and running.
When you’re ready, the next step is to reach out to our Solutions team to let them know who you need to integrate with and what kind of information you need to exchange. Our team will then outline exactly what needs to happen to get the integration up and running.
If you have questions along the way, we’re here to help. Our Slack group is a great place to get real-time support from our team as well as fellow developers building on Redox. With over 1,000 members it is one of the largest communities of healthcare developers in the world today.
We also have support staff available during business hours. Simply click the speech bubble in the bottom right of your screen to speak directly with a Redox employee.
Finally, you can always send us an email at: support@redoxengine.com.
Welcome to Redox! We can’t wait to get you up and running as an official member of the only truly interoperable network in healthcare.