Introduction to Data Models
Our Data Models use a standardized JSON format to create the Redox API framework, which enables third party applications to read and write data with any electronic health record (EHR) system via a single HTTPS connection. Redox handles all data mapping, translation, and connectivity to the health system, ensuring the developer experience remains consistent across all health system sites. JSON schema v4 files for all of our data models are available for download here.
There are two kinds of methods for syncing data: the first is a push model, where messages are triggered by user action within the EHR (e.g. a new appointment is scheduled, a new patient is registered, etc.) and automatically pushed to an established webhook; the second is query based, where instead of being triggered and posted automatically, clinical data is pulled by request and is sent to an application on demand. Every data model has supported event types, with some corresponding to pushed data and others to queries.
Every Redox data model event type is made up of key/value pairs in a JSON structure and this documentation lists the data points included in each. Pay particular attention to the Consistency and Required badges. We can only pass on the data that we have access to, and from health system to health system and vendor to vendor, some fields may or may not be available to us. We do our best to work with each health system to get as much data as possible, but there will always be some differences. Part of the testing process will be to identify which fields we can rely on for a given health system. For messages sent to us from your application, certain data points (such as a patient identifier) will be required in order for the message to be successfully processed by the EHR.
The data models listed within this documentation provide information on Redox capabilities. The ability to send and receive the information outlined in the data models and the available method (event based vs query based) is dependent on the capabilities of the EHR that your healthcare partners use. You’ll work closely with our team to develop an integration strategy that supports your workflow needs. If your application design works best by requesting the data you need instead of persisting pushed data, ask about our Data Chateâu feature.
Redox supports a wide range of integration standards, connection methods, and use cases, and we are constantly striving to broaden that support and reduce the barrier to entry that external systems face in obtaining healthcare data. With more innovative solutions being developed every day, the need for different data integration needs continues to grow. If your solution requires data that isn’t represented here, let us know — often we can combine models to fit your needs, or create an entirely new one to support our customers.
Data Model Updates
One thing that sets the Redox API apart from API's like HL7 FHIR is our ability to rapidly support newly emerging use cases and get them live in production quickly. As our data models evolve with new data points, our first focus is always on developer satisfaction. Below, you’ll find information on how we handle updates to our models today and what our plans are down the road.
What Will Stay Constant?
We do our best to not make any of the following types of changes:
If we ever do run into a fringe case where any of the above updates need to be made (which has yet to happen), please know that we would notify all customers far in advance of the update and that in appropriate cases we would provide a transition plan to affected customers.
Additions to the Redox Data Models
Current additions to models that Redox may make include:
When we make an addition to a data model we will post it in our Change Log, which will also post to our public Slack General channel. You can join our Slack community here. Additionally, any changes made to our models will be automatically reflected in the schemas available for download here.
The best way to build against our models and account for these additions is to be as “tolerant” a reader as possible by ignoring data points that aren’t necessary and not parsing everything into strongly typed objects. If this isn’t feasible for your project or if you’re running into issues with this based on your specific stack or environment please let us know so we can talk through any other potential solutions.
We have lots of exciting projects in the works that will make using the Redox API even easier to consume and more enjoyable to use. As our API evolves, we do plan to introduce versioning so that our customers have greater flexibility over when to introduce certain additions that we make to our models.
Please let us know if you have any feedback on our updates process or our product roadmap.