Redox supports a few ways to integrate and exchange data via FHIR®:
This is the asynchronous, or one-way, type of data exchange with FHIR®. Messaging is triggered by an event from one side of the integration, then sent via webhook to the other side of the integration. Your system can send or receive FHIR® messages. See what HL7 has to say about messaging and read our overview on asynchronous requests.
Since it’s an asynchronous request, the message header contains metadata about the date and time when the request was sent. This metadata is visible in your logs in the Redox dashboard as well. This type of metadata isn’t included with synchronous requests.
There are two types of messaging: one with a full payload and one with a lightweight payload. The messaging type with lightweight payloads are called event notifications. For the full payload option, stay tuned for more details on that in the future.
FHIR® events are light, real-time notifications around specific interactions that occur with a patient in a healthcare setting. For example, these interactions could be:
How this works is that your connection enables you to track and monitor changes or events for a patient (e.g., a patient’s upcoming and current encounters with a specific provider) through webhooks.
Event notifications are ideal if you don’t need all the data but only want to understand if something has changed for a patient. Then, you can decide whether to query your connection—or a data on demand repository—for more details about what changed. Find out more about data on demand.
Alternatively, the full payload messaging might be a better suited option for you if you do need to store a significant amount of patient data from your connection or don’t want to retrieve additional details with follow-up queries.
FHIR® events are deliberately light-weight, reducing mapping complexity in order to accelerate getting integrated with a healthcare organization. While they contain limited data, event notifications allow you to gather more information around the event with referenced FHIR® requests for the key resources involved (e.g., Patient, Encounter, Appointment). The combination of lightweight FHIR® events with FHIR® queries (see more on that below) reduces the need for a complex storage infrastructure so that you can rapidly integrate with a healthcare organization.
Event notifications contain the details for the event that triggered the message so that you can either query for more details or kickstart a workflow within your own system. For example, you may want to receive an event notification about a patient being discharged from the hospital so that you can follow up with a customer satisfaction survey about their inpatient stay. But the event notification would only contain the bare minimum patient information, not all the details about their inpatient stay.
This is typical synchronous data exchange, which means that one system queries another (using a RESTful HTTP API) and waits for a response. Read our overview on synchronous requests. Redox supports the full suite of RESTful interactions mandated by USCDI and more.
The most common type of queries are FHIR® search interactions. Learn more about FHIR® searches.
This is a “save” type of operation, which allows you to write data back to your connection’s EHR system. Behind the scenes, this is kind of a cross between messaging and a query—that is, you initiate a writeback like a query, but it’s asynchronous like messaging.
Most EHR systems don't currently support direct FHIR® writeback, but Redox can translate your writeback messages to other standards like HL7v2 that are more commonly used for these scenarios.