The Redox Engine platform allows you to access and interact with a wide variety of healthcare-related data via a consistent, normalized, REST-inspired API. Our platform is based on a truly standardized format and uses HTTPS communication with JSON to allow you to securely and conveniently build the next generation of innovative healthcare applications. Our JSON format organizes information into predefined data models based on the type of data you need to send or receive.
You’ll work closely with our team to understand the integration options available for your workflow needs and how to navigate discussions with healthcare organizations about your product’s integration capabilities. Using the Redox data models is the first step in making sure your team is building a reusable and scalable integration strategy. Redox provides you with a normalized method to interact with the variety of standards used by different EHRs on the market.
This documentation provides information on what Redox can do. However, the specific method used to send and receive the information is dependent on the capabilities of the EHR that your healthcare partners use. 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.
Events and Structure
Each of our data models have supported event types. Some of these correspond to messages being pushed based on events (usually an action a user takes) within an EHR or an application; Scheduling – New is an example of this, where messages are created and pushed to the connecting system as new appointments are scheduled. Other event types are query-based; Scheduling – AvailableSlots and ClinicalSummary – Query are examples of this, where the requested data is synchronously returned to the application that initiated the query rather than being pushed based on some real-time event in the EHR.
Each data model can have multiple supported event types based on the event triggers or queries that generate the message. PatientAdmin, for example, has many, many event types. For each event, the Data Model may look a little different, as different information is passed from the EHR depending on the event or query that took place.