Logs represent what data is transferred between two parties via Redox. Specifically, a log represents:
A specific data payload or request sent between a source and a destination on the Redox Network.
There are two primary types of requests for transacting data via Redox, and each has a pair of actions taken by the source and destination on either side of the request:
|Request Type||Source||Data Flow||Destination|
|Asynchronous, one-way requests||——->|
|Synchronous, two-way requests||——–>|
These are the four ways that your application or system can interact with Redox.
Every Log has a “type” equal to one of these actions, depending on whether your organization is acting as a source or destination for each type of request.
In some error cases during initial processing, it is not possible to determine the Log type before an error occurs. These Logs will be of type `UNKNOWN` and may not have available data model, event type, or destination information.
Asynchronous requests are event streams whereby the originator of the data (a source) does not wait for a response or verification of receipt from the destination receiving the data.
Further, asynchronous requests are guaranteed to be delivered at least once and in “first-in, first-out” (FIFO) order. Redox ensures that, for each subscription, each data payload is sent to the desired destination only after it’s predecessor (if any) succeeds.
As a result, a Log of type
RECEIVE may include multiple attempts for processing and delivery.
If a request is successfully processed by Redox, but fails to be accepted by the desired destination, it is automatically retried. After the first failure, Redox will retry the request immediately, then again after another 10 seconds and again after another 10 seconds. After the third retry, the period between retries will increase in the following order: 20, 30, 50, 80, 120 seconds. From there, retries will continue at 120 second intervals until the destination acknowledges successful receipt of the data, or they are manually paused by Redox. Automatic retries are only performed for destinations in the “Production” environment.
If a request is unsuccessfully processed by Redox, it will not be sent to the destination. Instead, the payload of the failed request, along with any incoming data payloads after it will be queued to send later. The Redox support team monitors these queues and works to resolve processing failures. Once resolved, the failed log can be manually retried, creating a new log attempt. A manual retry can be initiated from within a specific log entry in the Dashboard.
Asynchronous requests can be duplicated and sent to any number of destinations, depending on how many subscriptions are in place and how many destinations are designated within the request. A single asynchronous request routed to N destinations will generate N log entries.
Synchronous requests are requests whereby the originator of the request does wait for a response or verification of success. In this case, a source may be querying data from or requesting to write data to a destination system.
In order to translate between each system, these types of requests are processed by Redox twice, once for the original request from source → destination and again for the response on the way back from destination → source system.
Logs of type
RESPOND represent synchronous requests.
Every log has a distinct status that reflects it’s current or final state:
|SUCCEEDED||request was successfully brokered between source and destination systems|
|FAILED||request failed to fully complete due to an error within Redox or either source or destination system, and will not be retried.|
|FILTERED||request was intentionally filtered so that it did not complete. See Filters for details on setting up filter criteria.|
|PENDING||request is being processed, is queued, or has been resubmitted to be reprocessed|
Of these states, PENDING is an interim state that will always change into one of the other three end states.
This interim state is most common for asynchronous request logs that have been partially processed by Redox but not yet sent to the destination, or logs that have reached a previous end state and have been retried to process and send again (either manually or automatically).
Log records are searchable in the Dashboard or via the Platform API. Searchable terms include log metadata and unique payload information within the following categories:
|Redox metadata identifiers, such as Log ID, Message ID, Transmission ID, or FacilityCode.|
|Any Patient ID or name, including MRN. Name search terms must be in one of the following formats (without quotes):|
“FirstName LastName”, “F LastName”, “FirstName L”, or “LastName”
|Any Provider ID for a provider involved with care given, including NPI number|
|A VisitNumber or Visit ID|
|Any other ID value specific to a data model. For example, Order ID, Document ID, Device ID, etc.|
Search matches case-insensitive, exact terms only. There is no fuzzy matching or string correction.
"Message" & "Transmission" Terminology
You may see or be familiar with these terms from working with the Redox JSON API or in some areas of the dashboard.
A “message” is the payload sent by a source to Redox
A “transmission” is the payload sent to a destination from Redox
Logs replaces the concepts of “message” and “transmission”, by combining them. Each log is a unique combination of a message and a transmission, and resubmitted transmissions are analogous to log “attempts”.
You can find the Log for a given message or transmission by searching for it by ID in the “Metadata” category on the Logs page of the Dashboard.