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 queues are available for:
- async production or staging subscriptions
- subscriptions with any communication method, whether API or non-API
- outbound traffic flowing from Redox to a destination (not incoming traffic flowing from a source to Redox)
Queues must be set up by a Redoxer. If you're interested in implementing this feature, talk to a Redoxer.
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.