Process asynchronous traffic with child queues

Last updated: Dec 19, 2023

Asynchronous traffic refers to one-way traffic, like one-way streets in every downtown area. Sometimes it's hard navigating around those one-way streets. Haven't we all missed our turn or been stuck in a jam that's impossible to get around?

Since Redox processes async traffic in a first-in, first-out (FIFO) method, there might also be jams in healthcare data traffic. Learn more about async traffic. Traffic jams may especially be a consideration for high volumes of traffic, like during backfilling. Learn about backfilling before go-live.

Good news, Redox offers a beta feature to alleviate your interoperability stress or road-rage. We call them child queues for subscriptions.

Essentially, Redox can split one subscription into child queues so that event notifications can process in parallel while maintaining FIFO within each queue. In other words, one subscription may map to several queues so that async traffic processes simultaneously. The main benefit to multiple queues is faster throughput for high-volume feeds. Just make sure that the destination can handle that volume of incoming traffic.

Child subscription queues are for async traffic via the Redox Data Model API. Also, they're currently only available for staging environments and must be set up by a Redoxer. If you're interested in implementing this feature, talk to a Redoxer.

Note about ADT feeds

If you're setting up an admission, discharge, and transfer (ADT) feed, there's a possible conflict scenario with PatientMerge events.

Typically, we'll split a feed by patient identifiers. However, if one of the queues processes more slowly, you could hypothetically receive a PatientMerge event for a patient that hasn't finished processing through one of the queues.

For example, let's say Patient 1 processes on Queue A while Patient 2 is coming through Queue B, which gets backed up. In theory, a PatientMerge event requesting you merge Patient 1 and Patient 2 could process successfully on Queue A before Queue B catches up, so Patient 2 doesn't exist in your system.

If this kind of conflict happens, you can retry the log message for the PatientMerge event. Learn how to retry a log.