One of the most popular options for exchanging data is using the Redox Data Model API. With this modern, standardized API, we handle all of your data mapping, translation, and connectivity.
The Data Model API uses standardized data models, which describe the categories of data that can be exchanged with your connection via an encrypted communication method, typically HTTPS. You can combine data models to perform a given action to accomplish your unique workflow. All your outgoing messages via the Data Model API should be sent to https://api.redoxengine.com/endpoint.
Learn how to authenticate your system so you can initiate requests, then learn how to configure and verify an endpoint to process requests.
There are two possible methods for exchanging data using our Data Model API:
- Push: This is an event-based method where user actions within your connection's system trigger a request. The request is then pushed to a webhook that you have established. For example, when a new appointment is scheduled or a new patient is registered in the EHR system.
- 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 is marked as required, it means that you must include this field for your request to be successfully processed.
We can help you determine which data models fit your needs best.
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.
The Data Model API works with all of our data models, but check out some of the caveats below.
Some data model fields can only contain a limited set of values, which is called a valueset. Whether you are sending or receiving API requests, you should use or expect only the supported values listed for the relevant data field.
Our data models support a wide range of data, but as we noted above, we may not have access to certain fields. This means that some fields may not be populated, depending on your connection's system.
To help illustrate this in our data model reference, we provide a reliability rating for each field:
Field rating | Estimated reliability | Description |
|---|---|---|
Reliable | >90% | This field is present in requests from nearly every organization. |
Probable | >50% | This field is present in requests from most organizations. |
Possible | <50% | 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.
Some data models might have an option for including extensions with additional data. Read more about extensions.
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.