Logs represent what data is transferred between two parties via Redox. Specifically, a log represents:
A specific data payload sent between two systems that are integrated with Redox.
As stated in Data Exchange via Redox, there are two primary types of requests for transacting data via Redox, and each has a pair of actions taken by the system on either side of the request:
|Request Type||Action||Data Flow||Action|
|Asynchronous, one-way requests||——->|
|Synchronous, two-way requests||——–>|
Every Log has a “type” equal to one of these actions (
RESPOND) that reflects the interaction that your system has for a given 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 routing information.
Asynchronous Logs may be manually retried or require multiple attempts for successful delivery. As described in Data Exchange via Redox, Redox will continuously retry a request that fails to be successfully delivered to a receiving system in order to retain FIFO ordering.
Each time this occurs, it is referred to as an “attempt”. A Log that can have any number of attempts.
Asynchronous requests can be duplicated and sent to any number of destination systems, depending on how many subscriptions are in place and how many destination systems are designated within the request. A single asynchronous request routed to N systems will generate N log entries.
Every log has a distinct status that reflects it’s current or final state:
|SUCCEEDED||request was successfully brokered|
|FAILED||request failed to fully complete due to an error within Redox or either integrated 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, PENDING is an interim state that will always change into one of the other three end state statuses.
This interim state is most common for asynchronous request logs that have been partially processed by Redox but not yet sent to the receiving system, 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 spelling correction.