Redox framework for data exchange

Last updated: Jul 31, 2024

HEALTH TECH VENDOR

PRODUCT OWNER

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.

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 Redox setup. 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 time zones

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.

Visualize data exchange

To get a better picture of how data goes from one system to another (and back again, sometimes), check out connections in the Redox dashboard. Also, check out logs to see how data is actually processed.

Monitor data exchange health

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 alerts

Redox sends alerts when there's a system issue, like a VPN heartbeat or log failure for up to 60 days in the past. These are Redox-generated and Redox-resolved, but you can view the statuses and history. Learn how to monitor alerts history.

Your custom alerts

You may proactively 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.

You may create traffic alert rules for two scenarios: No Traffic or Error Threshold. Create your own traffic alert rule.

Log inspector

If you want to do some troubleshooting to find where in the processing the error occurred, check out log inspector.

Quotas and constraints

Review technical quotas and constraints for data exchange, including message, file, and rate limits.

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