Redox framework for data exchange

With an integration to Redox, there are a few ways that you can exchange data with your connections:

Event notification: SEND data triggered by an event in your system or RECEIVE data triggered by an event in your connection's system. This is typically an asynchronous exchange. Learn about polling, which is a type of notification exchange.
Query: REQUEST data from your connection to gather supplemental information about a patient record, or RESPOND with your data to your connection's query. This is typically a synchronous exchange.
Writeback: WRITE information back to your connection's system. This is typically an asynchronous exchange.

Explore our API actions for common ways to exchange data to get some ideas for creating your own unique workflow.

Exchanging FHIR data

The Redox FHIR® API has some slight distinctions. Learn more about FHIR® data exchange.

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.

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. Learn more about authentication.

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.

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.

What you're responsible for

For your own system, you're responsible for configuring your API keys and endpoints. You must create at least one of each per environment type and communication method.

For your connection's system, you must be able to specify their system endpoints, 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. Also, you must be able to recognize the ID for your connection's system on incoming requests.

Redox responsibilities

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.

Environment types

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

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.

PHI permissions

Within the Redox dashboard, you can set PHI permissions to restrict visibility to patient data for certain users in your organization. But this permission only applies in a production environment since the staging or development environments shouldn't contain PHI. Those user permissions don't apply for staging or development so that implementation team members can complete all appropriate testing. Learn how to manage user permissions.

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.

FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.