Here are some helpful definitions and tips as you browse through our Redox data model schemas.
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.
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 schemas, 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.
We do our best to not make any of the following types of changes:
- changing field types (e.g., string to array, number to string)
- removing fields that already exist
- adding new required fields
- decommissioning a non-beta data model or event type
If we do change any of the above, rest assured that we’ll notify all customers well in advance and create transition plans if the update affects you.
We may make these changes, however:
- adding new field types (e.g., array, string) to existing data models
- creating new data model event types
Review our Change Log for any updates about existing data models, or join our Slack community to watch for announcements. Any change will automatically reflect in our data model schemas. Download our data model schemas to explore them for yourself.
A best practice for building to the Data Model API is to not parse everything into strongly typed objects and ignore unnecessary data fields. If that’s not possible, or if you run into issues based on your stack or environment, submit a ticket via our Help Desk so we can talk through solutions.
Articles in this section
1 Article