Using polling for notifications

One of the most common ways to get the healthcare data you need is through asynchronous notifications. These notifications are automatically triggered when an event you want to track happens in your connection’s system (e.g., a patient arrived for an appointment). A notification keeps you up-to-date without having to query for data all the time.

However, not all EHR systems support real-time event notifications with traditional messaging. This could be because they developed and maintain their own proprietary API.

Does that mean you have to query on a regular basis just to see if information you want to keep tabs on is available? Not with API polling, you don’t.

Polling is an alternative to traditional notifications, which are automatically triggered and pushed to your system.

With polling, Redox routinely polls the API to find out what has changed in your connection’s system since the last time Redox asked. If something is new or has changed, Redox sends the data as a notification to you. But while it looks like a notification, it’s not a traditional notification from your connection.

We can think of the differences between notifications and polling like this:

• Notifications are like mail or packages automatically getting delivered when a sender addresses something to you.
• Polling is like having a courier regularly visit the post office on your behalf to ask if there are any new letters or packages for you.

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.

   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.

   Keep in mind that you can 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.

2. 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.
3. Redox creates a container for each changed item to prepare to send a notification back to your system.
4. Redox uses the returned identifier(s) to request information about the changed record.
5. Redox collects additional information from the EHR system and populates the container with the rest of the notification details.
6. You receive one notification per changed record.

In this way, polling lets you use your existing configuration with Redox to get the same value from one API integration.

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 EHR system returns an array of appointments that have changed since May 5, 2022 at 10:00. Each appointment object includes a patient identifier, which Redox uses to poll for more data about that specific patient and modified appointment. It looks a little like this:

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 destination as if the EHR system sent a scheduling update themselves. Neat, huh?