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 exchange is typically asynchronous. 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 exchange is typically synchronous.
Writeback: WRITE information back to your connection's system. This exchange is typically asynchronous.

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

Redox uses the metadata of exchanged requests to process, partition, and route data appropriately.

Sources, API keys, and destinations

Your system must have at least one source and API key to send data. A source identifies your system and communication method, while 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 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 Endpoints tab of the Developer page.

You may send data across multiple connections via the same source. If you need multiple communication methods, then 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).

What you're responsible for

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

For your connection's system, you must be able to specify their destinations, 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 source ID of your connection's system on incoming requests.

Redox responsibilities

During your implementation process, we share the destination 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 destinations, depending on the type of integration and data.

Environment types

Environment types identify the kind of data flowing between systems. We have three basic environment types:

Development environments are only for testing between your organization and Redox. Your development environment automatically integrates 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.

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.

Environments can also help you manage user access to your system's configuration settings. Learn about environments.

Confidential data

Personal health information (PHI) shouldn't be visible to just anyone in your organization. The ability to view log payloads—which may contain PHI—is restricted based on a user role assignment. Learn about roles. We recommend assigning user access as though all log payloads contain confidential data.

Although we build all environment types with the same level of security, you should never send PHI to development or staging environments. Users in staging or development don't expect to interact with confidential data and may not treat it with sensitivity. We also can't guarantee that one of your connections won't include PHI by accident, so being preemptive about user access is the safest bet.

Dates and timezones

An inherent part of data exchange is knowing the 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). 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 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

Exceptions for date and time conversion

Redox may handle date and time conversion differently if:

You have an alternative integration.
You don't use the Redox dashboard at all.
You or your connection send data without requiring any kind of mapping. In this case, if your integration is pass-through only, Redox doesn't convert any timestamps.
A Redoxer configures your organization record. There may be other factors during that process to determine whether there's a conversion or offset for a timestamp.

Be sure to talk through this with the Implementation team if you have questions about what to expect for your date and time conversions.

Message and file size limits

Redox has message and file limits for both incoming and outgoing traffic. If a message exceeds these limits, the message will error.

Type of traffic	Size limit
Redox API traffic (e.g., Redox Data Model API or Redox FHIR® API)	40 MB
Carequality Interoperability Framework (for Redox Access™)	40 MB
HL7v2 messages over MLLP	30 MB
Uploaded files	30 MB
Embedded files	10 MB
All other integrations or APIs	10 MB

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®.