Data exchange with Redox

Data exchange is the core function of the Redox platform. It’s the process of sending, receiving, and querying healthcare information between your application and your connected partners. Whether you’re sending a newly booked appointment to a hospital’s EHR system or receiving clinical notes about a patient, you’re performing data exchange.

Redox provides a robust framework for you to exchange healthcare data with your connections. Let’s break down the fundamental concepts and tools of how we support data exchange.

First, you have to establish connections with your partners. Learn about connections and review the implementation process.

Then, you have to work out which communication method you’ll use to exchange data. Review our supported communication methods.

Once you have connections and communication methods set up, the Connections > Subscriptions page of the Redox dashboard gives you a picture of how data flows from one system to another (and back again, sometimes).

Your system has to be authorized to send data to Redox with API keys. You should also have authentication credentials in place to verify requests coming from Redox. Learn more about authenticating both sides of the data exchange flow:

• Authenticate and send data to Redox
• Receive data from Redox

Next, decide how you want to exchange data. Redox supports three types of exchange:

1. Asynchronous notification (SEND): A notification tells you that something happened in your connection’s system. Some kind of event (e.g., a patient arrived for an appointment) automatically triggers a notification. This type of traffic is a one-way push of data that doesn’t wait for a response.

   Alternative method to support notifications

   What if your connection doesn’t support traditional event notifications? Don’t worry, check out how to use polling instead.

2. Synchronous query (REQUEST/RESPOND): A query asks for information from your connection’s system and waits for a response. Your connection gathers data about the patient, encounter, or other requested item, and responds immediately. Sometimes there will be results and sometimes not.
3. Asynchronous writeback (WRITE): A writeback tells your connection that something happened in your system. This is often used for updating a patient’s chart with data from your app. This type of traffic is a one-way push of data that doesn’t wait for a response.

In your Redox organization, you must have at least one source to send and one API key to authorize your data. A source tells us who your system is and how you connect. An API key lets your system send and request data from your connection. You can view and create both sources and OAuth API keys on the Developer > Sources page of the Redox dashboard. Learn more about authentication.

Your system must have at least one destination, or endpoint, to process incoming requests. A destination is a URL that can RECEIVE data from and RESPOND to your connection’s requests. In the Redox dashboard, you can view and create destinations under the Destinations tab on the Developer page.

You can use the same source to send data to multiple destinations. If you need multiple communication methods, though, you’ll need a source for each type. But at a minimum, your organization must have one source and API key to initiate requests and one destination to receive requests from your connection(s).

Once you and your connection are set up to exchange data, you can start sending requests. Redox uses the metadata of requests flowing through your Redox organization to process, partition, and route data appropriately.

Here are some primary examples of what we use to route requests:

• source or destination IDs (learn how to manage source metadata)
• environment types
• dates and time zones

Environment types identify the kind of data flowing between systems. Learn about environments.

You can only exchange data with the same environment type. For example, if you send data from a staging environment, it can only be received by another staging type of environment.

An inherent part of data exchange is knowing when—that is, when outgoing requests are delivered or when incoming requests are received. Redox generates relevant date and time metadata for this.

Also, there may be date and time pieces in a request that are significant to the data itself (e.g., the date that a patient was admitted to the hospital). Redox doesn’t add a timestamp to a time field if the request doesn’t contain one. It’s also important for you to not include a time value if only the date is known or appropriate.

Given that different organizations are likely in different time zones, Redox converts timestamps to UTC time zone in ISO 8601 format (i.e., YYYY-MM-DD or YYYY-MM-DDThh:mm:ss.sTZD). Learn more about ISO 8601.

Sometimes data doesn’t make it to its intended destination. The good news is we provide alerting and troubleshooting options to help you stay on top of the health of your integration.

• Redox system alerts: Redox sends alerts when there’s a system issue, like a VPN heartbeat or log failure. These are Redox-managed alerts, meaning we both generate and resolve them. However, you can view active and historical system alerts up to 60 days in the past. Learn how to check system alerts.
• Your traffic alert rules: You can monitor a Redox organization with your own traffic alert rules. These are unique alerts you define for your organization. When the conditions of your traffic alert rule are met, we send an email to the users you designate. Traffic alert rules notify you about irregularities so you don’t have to constantly check the Redox dashboard just to see if traffic is flowing appropriately. Bonus, you can independently monitor the health of your integration based on conditions you define without relying on Redox support. Create a traffic alert rule.
• Log inspector: A log error prevents data from reaching its destination. You can use log inspector to see where an error occurred during processing so you can troubleshoot errors more effectively.