Event notifications are primarily used for one-way, event-based data streams where systems SEND or RECEIVE data asynchronously. You can think of these like CRUD type of requests you want to send to or receive from your connection's EHR system.
We use recoverable messages to guarantee delivery of asynchronous traffic. We save these messages into highly durable queues so that they can survive restarts or other failures. We won't respond with a 200 OK status unless we successfully saved the message in a highly durable queue first.
Read about our business continuity and disaster recovery plan.
Event notifications are delivered via Redox to the desired system using a first-in, first-out (FIFO) method. We work to maintain the order of asynchronous events in the order they're triggered.
One exception to that, though, is that Redox sometimes processes events in parallel before sending in FIFO order. So you shouldn't use the log ID to sequence requests, especially if the endpoint receives different data models or FHIR® resources. Instead, use the timestamp for when the data arrived at the endpoint to sequence it against other asynchronous traffic.
If failures happen during processing, we pause the queue for the intended endpoint so that we can maintain FIFO delivery after the issue is resolved.
Meanwhile, we send a notification to the sender or receiver, depending on where the failure occurred. Either way, the notification goes to the Alert Email, which is listed in the Organization Profile of the Redox dashboard.
Some packages don’t get to their intended destination. Amazon knows this well.
Sometimes your asynchronous messages also don’t get to their intended endpoint(s). The good news is that we can let you know whether your message arrived safely. But remember that asynchronous messages are one-way, so you won’t get a response back from your connection's system. Much like Amazon doesn’t get thank-you packages for successfully delivered orders.
Any responses to asynchronous traffic are from Redox specifically about your outgoing message. And if your message went to multiple endpoints, you receive only one overall response. Check out the details about each scenario below.
If Redox successfully accepts your message, you receive a 200 OK status and a response body with any relevant details.
A successful status doesn't mean that the message was delivered to the intended endpoint. It only means that we received the message, saved it to a highly durable queue, and are ready to process. Then, we'll deliver it to the intended endpoint(s).
Later, if you want to know for certain whether your message was successfully processed and delivered, you can check the status of the related log. Learn more about logs.
The difference between a response and a log is that Redox sends a response to a message for multiple endpoints, but we create a log for each endpoint. So if you send one message to 10 endpoints, you receive one response with 10 log objects and IDs in Meta.Logs[].ID array (for the Data Model API).
On occasion, Redox can’t process a request because of an issue with the request or within Redox itself. If this happens, you receive a 4XX or 5XX HTTP status code and a response with the array in the body populated: Meta.Errors[] array (for the Data Model API) or the issue[] array (for the FHIR® API). Review HTTP errors.
These arrays contain an error object with the type of failure and corresponding details. At a minimum, a Text field provides the error message details.
We recommend that your system have queuing capability for your outgoing requests to Redox in case of any kind of failure. This way, your system can queue any additional outgoing requests until the issue is resolved.
We rely on you to send an HTTP status code to let us know whether you successfully received a message from your connection's system. We wait for your response before deciding what to do next.
If you successfully receive an event from Redox, your system should send back a 200 OK status with an empty Meta.Errors[] array (for the Redox Data Model API) or issue[] array (for the FHIR® API) in the body of the response. This response means that your system has processed the most recent data and is ready for the next payload. We proceed with sending your next asynchronous data payload.
If unable to receive an event, your system should send back to Redox the relevant 4XX or 5XX HTTP status code and a response with the relevant array in the body populated: Meta.Errors[] array (for the Redox Data Model API) or the issue[] array (for the Redox FHIR® API). Review HTTP errors.
This array should contain an error object with the type of failure and corresponding details. At a minimum, a Text field should provide the error message details.
If you send us a failed HTTP status code in response to an asynchronous message, our next action depends on the type of environment your destination is in.
- Production environment: We wait a few seconds before we automatically retry sending the message. We also pause the queue until the message succeeds. Learn more about automatic retries.
- Staging or development environment: We don't automatically retry the failed message or pause the queue. Learn how to initiate a manual retry.
For non-critical errors, we expect you to send back a 200 OK status prior to performing data validation or after finding an error that can be resolved at a later time. This way, we don’t pause data for production environments and your development/staging environments can proceed with business as usual. This option ensures continuity in your data delivery so that your data flow doesn’t get hung up on one troublesome data payload.
If you identify a non-critical issue with an incoming message, log an error in your system. Then submit a ticket via our Help Desk if you need help resolving it.
If you're experiencing downtime or another critical error, we recommend sending a 4XX or 5XX status to initiate pausing on our end so that none of your data is lost while you work to resolve your system.