How Redox Works

Redox is the modern API for EHR integration. Our engine facilitates the easy, fast, and secure exchange of patient health data that powers applications improving healthcare. With Redox, a single connection to our engine enables interoperation with EHRs and other applications. We accomplish this through a network approach. By sitting in between organizations that wish to share health information, we are able to accommodate wide ranges of data standards and data variance. When two organization agree to exchange data, we facilitate the exchange by handling connectivity, data translation into the expected format of the receiving system, and data delivery.

After people learn about our engine, one of the most common questions we hear is “how does Redox work?”

Though the answer would seem complex, it’s fairly straightforward to understand how data flows and is managed across an application, our engine, and a health system. Those are the three places data is processed and stored within its journey—let’s take a closer look at each.

Application to Redox

Applications code and then connect to Redox once over an HTTPS webhook. Redox will send messages to an application’s callback URL and receive messages and queries. Redox has standard JSON data models that represent a wide variety of patient-centric data. When we send messages to an endpoint, we include an application secret in the message headers. Conversely, we provide an API key for messages being sent to Redox over the webhook. In the event of a transmission error, Redox automatically retries a number of times before throwing an error alert notifying the application’s escalation path and our on-call engineer to investigate further.

What Happens in the Engine…

Messages go through three stages of transformation to standardize into our JSON specifications. First, messages are parsed according to type (HL7 v2, CCD, Custom API, etc.). Secondly, they are configured for vendor-specific specifications. Finally, they are configured for the health-system-level workflow customizations that can affect these messages. At this stage, field-level filters can be applied before messages are routed to their proper destination and transmitted in the specified format.

Health System to Redox

Our integration experts work with health systems to identify the most efficient integration strategy for their unique EHR implementation. For HL7 integrations, Redox most commonly maintains a secure VPN tunnel for MLLP traffic. HL7 messages originating in the EHR are normally routed through an on-premise interface engine already in use in the health system before being pushed to our VPN. Conversely, Redox pushes HL7 messages back to the EHR through this infrastructure as well. We also worked with health systems to connect to EHR-vendor-custom APIs as well as supporting DIRECT protocol.

The bottom line here is that we handle the mapping and configuration of messages in our engine, making it easy and lightweight for IT teams to work with us.

Throughout this entire process, best practice safeguards are in place to protect patient data. Check out our Security Overview for more information on how we protect client data.

Data Translation

This diagram shows how data consumed from an external source is transformed into our normalized data models. Though this shows an HL7v2 message transformed into JSON, please note that a variety of other standards such as CDA, FHIR, X12, and Web Services can be both consumed and produced.