Introduction to the Redox Data Model API

Last updated: Sep 26, 2023

One of the most popular options for exchanging data is the Redox Data Model API. This modern, standardized API handles all your data mapping, translation, and connectivity needs.

The Data Model API relies on standardized data models, which describe the categories of data that you can exchange with your connection. Data exchange happens via an encrypted communication method, typically HTTPS.

You can combine data models to perform a given action to accomplish your unique workflow. All outgoing messages via the Data Model API should be sent to Learn how to authenticate your system so you can initiate requests, then learn how to configure and verify an endpoint to process requests.

Push vs. pull methods

There are two possible methods for exchanging data using our Data Model API:

  1. Push: This is an event-based method where user actions within your connection's system trigger a notification. Your connection then pushes the notification to a webhook that you've established. For example, when a new appointment is scheduled or a new patient is registered in the EHR system.
  2. Pull: This is a query-based or polling method where you request clinical data and receive the data from your connection's system on demand. For example, you search for a patient using their demographic data and the EHR system returns the relevant results.

Each data model has supported event types with a corresponding push or pull method. These event types consist of JSON fields and values. We note for you in each data model which fields are required. If a field has a required tag, you must include this field for Redox to successfully process your request.

We can help you determine which data models fit your needs best.

Data on demand

Depending on your system, we may recommend sending and receiving data via polling or data on demand. We can help you decide what may suit your system the best based on your unique integrations. Learn more about data on demand.

Things you need to know about data models

The Data Model API works with all of our data models, but let's talk about some caveats.

Value sets

Some data model fields can only contain a limited set of values, which is called a value set.

Whether you're sending or receiving API requests, you should use or expect only the supported values listed for the relevant data field.

Example value set for the Patient.Demographics.Citizenship array
Example value set for the Patient.Demographics.Citizenship array

Field reliability

Our data models support a wide range of data, but we may not have access to certain fields. So, some fields may not be populated, depending on your connection's system.

In our data model reference, we provide a reliability rating for each field:

Field rating
Estimated reliability
This field is present in requests from nearly every organization.
This field is present in requests from most organizations.
This field is present in requests from some organizations.

Don't worry too much if a field is only Probable or Possible. By default, healthcare organizations may restrict the data they send for these reasons:

  • A core tenet of healthcare security is to only send data that's absolutely necessary. This way, there's a minimal amount of compromised data in the event of a breach.
  • Backwards compatibility is a core principle of integration developers. Some data may be available with new versions of software, but to ensure backwards compatibility, the newly supported data isn't included by default.

Before onboarding, it's important to have a clear understanding of what data your connection will or won't provide. Our Implementation team works with you to document the data integration needs or plan for any customization. Review our data model reference to see what you can expect.


Some data models might have an option for including extensions with additional data. Read more about extensions.

Data model updates

With the Data Model API, we can rapidly support newly emerging use cases and quickly go live with them in production. As our data models evolve with new data fields, our focus is always developer satisfaction. Check out the information below to learn how we handle updates to our data models and what our plans are down the road.