Filtering asynchronous notifications

Last updated: Sep 19, 2025

HEALTH TECH VENDOR

PRODUCT OWNER

IMPLEMENTATION

The beauty of data exchange is you can get the data you need. But what if opening the data exchange highway leads to overload? If you’re tired of sifting through 100 notifications you don’t need for the 10 you do, try out Redox filters.

What are filters?

A filter is a rule you define to conditionally allow or automatically stop certain asynchronous notifications from being delivered to your destination(s). You should use filters to:

Reduce noise: Prevent irrelevant data from reaching your system.
Manage workflows: Only process notifications that meet specific criteria (e.g., only accept PatientAdmin messages for patients in the cardiology department).

You can create filters for specific asynchronous Redox data models or FHIR® notifications.

Filters are one of many operations that can be applied during log processing. .

How filters work

Let’s explain this with an everyday analogy: You only need a sip of water to quench your thirst, but someone offers you a drink from a fire hydrant. The hydrant opens, and you’re overwhelmed by the jet of water that comes out. Basically, it’s too much water and pressure for what you need.

Being connected to a massive healthcare organization with tens of thousands of incoming notifications per day might feel a bit like drinking from that fire hydrant. Our filters help to “turn down the pressure” to reduce that high-volume data stream to the specific dataset you need.

For example, you might only interested in a subset of patients from a healthcare organization, like the cardiology unit. You could use a filter that would accept all incoming payloads for patients seen only in the cardiology unit and block the rest. Without the filter, you'd receive all the data payloads from every unit, leaving you to decide which to keep after processing them yourself.

Only for engineer or support roles

All environment users may view data operations like filters. You must be assigned to an engineer or support role to create or edit filters. Learn about roles.

If you choose to filter fields with PHI, users assigned to an observer role may unintentionally access confidential data. Keep that in mind when assigning user roles, since access to viewing log payloads and viewing filters are managed by different permissions.

Filter scope

A filter can only be linked to one subscription. You have to create one for each subscription you want to filter.

Also, a subscription can only have one filter link. This means there’s a 1:1 relationship between filters and subscriptions. Learn about subscriptions.

Example scope

Let’s say you have two subscriptions for receiving Order.New notifications from two different healthcare organizations.

The first subscription is with Baylor Hospital. You create a Send if filter with a rule that looks for certain order type(s).
The second subscription is with UT-Southwestern. You want only the same order types as from Baylor, but you can’t link the Baylor filter to UT-Southwestern. This subscription needs its own filter, even if you want the same rule applied.

However, you could add a rule to the Baylor filter if you only want to get orders from a specific facility within the health system. Then your filter would have two rules to conditionally allow new orders (of a specific type) from a specific facility.

Remember that both of your subscriptions now have linked filters. This means you can’t create or link a new Block all filter to either of them.

Redox FHIR® API vs Redox Data Model API

We support filters for Redox data models and Redox FHIR®. Filters work the same for either API, but there are two different modes for defining FHIR® filters. Learn how to define filters for specifics.

Which type of filter to use

There are two types of filters:

Send if: Conditionally allow certain notifications based on one or more defined rules.
Block all: Don’t allow any notifications for this subscription.

Send if filters

You can use two types of rules to define a Send if filter:

is in: The notification should only be sent if the value(s) for the specified field path exist in the payload.
is not in: The notification should only be sent if the value(s) for the specified field path doesn’t exist in the payload.

For either rule type, you can define a comma-delimited value set to look for.

Filters for null values

It’s possible to filter a specific field by whether it’s populated or not. You can do this by treating null as a string value, so the filter looks like this: is not in null. You can create this kind of filter so that you don’t receive a specific field unless it’s populated.

Filtering arrays

Some fields are arrays, meaning there might be multiple values at one field path. You can tell if a field path is an array if it has brackets ([]) in the title. In this case, if any value within the array meets the filter rule, then the filter applies.

Let’s say you create the following example filter:

Send if $.Animal.Type[*] is in (walrus).

Then an incoming notification payload contains this:

$.Animal.Type[*] = [badger,rabbit,walrus,penguin].

Since (walrus) is one of the values in the array, you receive the notification.

Alternatively, if you specify is not in instead, then you wouldn't receive this notification because (walrus) appears at the specified field path in the payload.

Block all filters

Block all restricts any notifications for this subscription. Only deleting the filter will allow notifications to resume.

Blocking is helpful when preparing for a new integration that’s not quite ready for go-live.

Log processing and filters

In the Redox dashboard, a filter immediately applies once it’s saved. With the Redox Platform API, the filter applies after it's linked to a subscription.

On the Logs page of the dashboard, any filtered logs have the status of Filtered.

Filtered status

Selecting the log opens the processing stages, which have a Filtered label and icon if a filter was applied. You can select the processing stage to view the log details, then click the filter label to see the specific filter details. These details include the status of the log and the outcome of each filter rule.

Learn about filter outcomes in a log.

Promoting filters

During implementation, you can build and test a filter in a staging environment. Once you have any kinks ironed out, you can then promote the filter to production. This saves you time and avoids introducing errors by rebuilding in a different environment. Learn about promoting assets in your Redox organization. Then learn how to promote a filter.

Restoring filter versions

Every time you edit a filter, you create a new version of the asset. If you run into errors or unexpected outcomes after editing, you can restore to a different version to help troubleshoot and find where any errors were introduced. Learn how to restore a filter.

FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.