Technical Onboarding

Technical Onboarding

Welcome to Redox! We’re excited to help you get your application ready for integration! If you’re looking for more detailed information about how Redox works or how to set up your integration, please reference our Developer Guide.

Designing your Integration

At Redox, we like to think of integrated workflows in three steps:

  1. Enrollment – the moment that you become aware that there is work to do and the information you collect and store at that point. This could be an action that occurs in the EHR that you’ll get as a notification, or it would be an action that happens in your application, and you’ll query the EHR for the information you need to support it.
  2. Supplementation – the gathering of additional information to provide context about the patient. Sometimes this is past results or visits for the patient, but it could also be information about the provider, patient demographic/insurance details, or a full Clinical Summary.
  3. Writeback – what (if anything) needs to be sent back to the EHR when your workflow is completed? Is that information a summary report, or something more discrete?

When you have a question about how the integration should work, it’s also good to come back to these steps – at what point do you need any given piece of information? At what point do you need to have a patient already enrolled in order for your application to do the work that needs to be done?  When you work with the Redox team, they’ll help you think of these steps in relation to your workflow and design an integrated strategy.

Find out more about integration strategies for:

The Redox Engine

Redox uses a networked approach to integration architecture. Each node on the network connects directly to Redox, then those nodes can be connected to each other without having to do a lot of customization for each individual connection.

Redox performs several jobs that you would normally have to do within your own application to simplify your integration experience:

  • Connectivity – Redox will work with the health systems and applications that you want to connect with to make sure that they’re connected to the network through their preferred method.
  • Translation – Redox uses a library of configurations for various integration methods and EHRs in order to translate whatever we’re receiving from your clients into a standardized API that you work with.
  • Infrastructure – If you don’t need the data right away, Redox can store it for you so that you can retrieve it when you’re ready for it. We also maintain the connections and queuing to verify that they stay up and maintain FIFO.
  • 24/7 Support – Redox monitors live connections for errors, handles retries against both your system and your client’s system, and will work the appropriate group to resolve any issue that does arise on a live feed.

Find out more about how the Redox Engine works in our Developer Guide

Connecting to Redox

Redox relies on Sources and Destinations to route information between nodes on the network. 

  • A source is where data originates – this could be a pushed notification or the initiation of a query.
  • A destination is the intended recipient – this could be the endpoint that a notification is pushed to or the database that is being queried.

Each organization on the network may have one or many sources and destinations depending on the connection methods, data types, and data models in use. You will need to create sources and destinations for your own application and be ready to recognize or specify the sources and destinations in use by the organizations where you plan to connect your application.

Redox uses several environment types to identify the type of data that will flow over a given connection. Sources and destinations are specific to a given environment type, and can only be connected to other sources and destinations of the same environment type.

There are three environment types used by the Redox Engine:

  • Development environments are used for testing between you and Redox only – these will automatically be connected to Redox for all data models, but can never be connected to other sources and destinations.
  • Staging environments are used for testing either with specific Redox sandboxes, with your own testing app, or with a health system partner.
  • Production environments are used any time there is real patient data that will pass through the connection, either a live production feed or a testing feed in an environment with PHI.

The Redox API

The Redox API uses a JSON model to communicate the information that’s available for any given concept or Data Model such as Scheduling, Orders, or Notes. In the Redox Data Model documentation, you’ll find the list of the trigger events that we see for each data model, the queries that are available, the fields available for each event or query, as well and the reliability of each field.

Redox uses three values to indicate the reliability of each data element:

  • Reliable indicates that we expect to see this item in about 90% of the messages that we receive
  • Probable means that we expect to see this item in more than 50% of messages
  • Possible means that this item is something we’ve seen before, but we don’t expect it to be available often.

Each data model event also includes a section for metadata, including the source and destination IDs for the message to aid with routing.

Find out more about our data models here, or check out our full Data Model documentation


Subscriptions are how Redox determines where data is allowed to flow. Each subscription is a unique combination of a Source, a Destination, and a Data Model, and they can only be created between a source and destination of the same environment type. For each integration, you will have one subscription per Data Model. Redox will create and manage subscriptions for you – if you need a new connection set up, let us know!

Redox maintains a unique queue per subscription and will send through the messages in the order in which they are received. For example, you should not expect to get a discharge message before an admission message for the same patient. In the case of an error, we will first attempt to retry the message, then pause that subscription and queue any messages received until the issue is resolved. If a queue is paused due to an error on your side, we will send a notification to an alert email address you set up in the Dashboard upon account creation so you can troubleshoot on your end and we will also notify our on-call engineers to confirm if it is a Redox issue to further diagnose. Once the issue is resolved, we will send the subsequent messages in the queue in the order in which they were received. 

Learn more about error handling here.

Testing your Integration

Redox allows applications to test without an EHR on the other side through several types of testing tools.

With a free dashboard account, you can use the Redox dev tools, which will allow for messages sent between your application and Redox, with real-time proof of success or failure via 200 or 400 success/error messages. Once you have authenticated your Destination, you can utilize our development tools to send our sample messages or customized versions of them to your server. On the Source side, Redox has Postman and Curl tools to help you test sending data to Redox or performing queries to see what the messages will look like, or you can set up your application to call Redox directly and receive the appropriate 200 or 400 back based on the message contents.

After you’ve signed a contract with Redox, you’ll be able to create staging sources and destinations which can be connected to other sources and destinations within the network. This allows you to create your own test apps that either manually (with curl or postman) or through code push the messages you need to your own endpoint to test your workflows. We also have a sandbox available with test data for testing queries. If you would like to set up either of these options, talk to your Redox team.

To ensure that your first implementation moves as quickly as possible, you will need to test your workflow end to end against the Redox testing tools to verify that your application is ready when you begin working with a health system. Your team is responsible for making sure that you can send and receive the in-scope data models. While there may be variances in the actual data that you receive or need to send at each site, completing this testing before you kick off a project will validate that your product and Redox can communicate as expected. This will allow your team and your Redox support to focus on any issues that are unique to the integration project for faster resolution of project blockers.

Building for Flexibility

Every healthcare data source is different, but there are few strategies that you can use to reduce the customizations needed as you integrate with different health systems and EHRs.

  1. Only run completeness checking on the fields actually required for your application to run – it may be tempting to check for everything in our sample message, but doing so will increase the number of errors on your feed. Limiting your completeness checks to only the fields actually required for your application to run will avoid those unnecessary errors and ensure that we can identify the most critical missing items to resolve while testing.
  2. Build-in settings to specify the ID type that you plan to use for any given site. This way you’re able to take advantage of whatever ID type makes most sense for any given health system. In some cases, you may want to be prepared to store and track multiple identifiers sent to you for a patient. This is often the case when you’re integrating with multiple systems at the healthcare organization that may use different identifiers or if you’re working with a larger IDN that has many regions that maintain their own patient identifiers.
  3. Set up your application to be able to perform mappings of your internal concepts per health system that you work with – this allows you to recognize the values that you care about, no matter what codeset the health system is using. If you use a set of values more globally (as is often the case for something like diagnoses) we recommend making sure that your application can recognize and use any standard code sets for that data. Redox can work with the HCO to send your preferred code set wherever possible, but following these best practices will allow you to flex in cases where the health system isn’t able to comply.

Are you Code Complete?

To complete onboarding and be ready to kick off a project with your first site, you should meet the following criteria:

  • You can receive and parse any data models pushed to you as part of your scope
  • You can construct and send any data models you’ll push to the EHR
  • You can perform any in-scope queries and parse results
  • You can test your application’s workflow end-to-end again the Redox testing tools
  • You’ve created your staging and production sources and destinations
  • You have a strategy for handling patient, visit, order, etc identifiers, and mappings
  • You have a strategy for managing source and destination identifiers for the sites where you’ll connect.

Once you’ve completed this list, let us know! We have a few quick Validation tests that we’ll run against your endpoints to make sure everything looks ready.