Data exchange via Redox

The purpose of Redox is to enable you to exchange data with your connections. With a Redox integration, there are four ways that your system can exchange data:

  • SEND
  • RECEIVE
  • REQUEST
  • RESPOND

These data exchange options relate to (a) the type of request (i.e., asynchronous or synchronous), and (b) whether your system initiated an outgoing request or received an inbound request.

API keys and endpoints

Your system must have at least one API key to initiate requests. An API key authorizes your system to SEND data to and REQUEST data from your connection. You can view and create API keys on the Developer page of the Redox dashboard, under the API Keys tab.

Your system must have at least one endpoint to process incoming requests. An endpoint is a URL that can RECEIVE data from and RESPOND with data to your integrated connection's requests. You can view and create endpoints on the Developer page of the dashboard, under the Endpoints tab.

Environment types

Redox use a few environment types to identify the type of data that flows between a given integration.

We use three environment types for Redox:

  • Development environments are only for testing between you and Redox. Your development environment is automatically integrated with Redox.
  • Staging environments are for testing either with specific Redox sandboxes, your own testing system, or your connection's system.
  • Production environments are for real patient data with PHI passing through the integration, which could either be for live production or testing.

Your system can only exchange data with a system that has the same environment type. For example, requests sent from your staging environment can only be received by another staging environment.

How to set up data exchange

When everything is set up appropriately, Redox uses the metadata of the exchanged requests to process, partition, and route data appropriately.

What you're responsible for

First, you must configure your system with Redox. You must create at least one API key and endpoint per environment type and communication method. Essentially, you may send data across multiple integrations via the same communication method, but you're only required to have one API key to initiate requests and one endpoint to receive requests from multiple endpoints.

Second, you must be able to specify the appropriate endpoints for your connection's system, which you define in the metadata of an outgoing request. You can find the endpoint IDs for your connections on the Connections page of the dashboard.

Third, you must be able to recognize the ID for your connection on incoming requests.

What Redox does

During your implementation process, we share the endpoint data for Redox and your connections. We also create the Redox organization records for the healthcare organizations you integrate with. Healthcare organizations may have one or more endpoints, depending on the type of integration and data.

Dates and timezones

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

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

Given that different organizations are likely in different time zones, Redox converts all 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.

Type
Format
Example
Date
YYYY-MM-DD
2019-09-22
DateTime
YYYY-MM-DDThh:mm:ss.sssZ
2021-09-22T10:20:30.000Z

Date and time conversion for alternative integrations

Redox may handle date and time conversion differently if you have an alternative integration or you don't use the Redox dashboard at all.

If Redox handles how your organization record is configured, there are other factors that determine whether there's a conversion or what offset a timestamp should have. Be sure to talk through this with the Implementation team if you have an alternative integration.