Receiving notifications via polling

Let's say your connection's EHR system develops and maintains their own API. Snazzy, right? The catch is that they don't support real-time event notifications with traditional messaging.

Not to worry. With Redox, you can receive real-time notifications via API polling.

Redox polls the API to determine what changed, then creates a request to send back to you as a notification with the changed data.

Let's break it down a bit more technically:

1. Redox polls the integrated system to find out what changed.
2. Polling intervals

   Redox doesn't have a default polling interval. You decide the polling interval that makes sense for your system and workflow. That interval could be as frequent as once per minute or only once per day.

   You also have the flexibility to either use the same or different polling intervals for different API actions in your workflow. For example, you may want to poll for new orders once per day, but for new patients every 10 minutes.

3. The EHR system returns the identifiers for the records that have changed. The returned identifier could be a patient identifier for a patient with a new order.
4. Redox creates a container for each changed item to prepare to send a notification back to your system.
5. Redox uses the returned identifier(s) to request information about the changed record.
6. Redox collects additional information from the EHR system and populates the container with the rest of the notification details.
7. You receive one notification per changed record.

With polling, you can leverage your existing configuration with Redox to derive the same value from an integration with an API.

Redox polls the integrated system once per minute to ask something like, “Did any patient appointments change since I last called you 60 seconds ago?” Technically speaking, this may look a little something like this:

1
https://fakedata.com/appointments?changedsince=2022-05-10T10:00:00

The integrated system returns an array of appointments that have changed since May 5, 2022 at 10:00. Each appointment object includes a patient identifier so that Redox can poll for more data for that patient whose appointment changed, using their identifier, like thi

1
https://fakedata.com/patient/{patientID}

Redox then has enough data to send one traditional scheduling update for that patient to your system.

In this example, Redox receives relevant scheduling updates from the integrated system and processes them as what-has-changed notifications. Then we deliver them to your endpoints as if the EHR system sent a scheduling update themselves. Neat, huh?