Redox supports a few ways to integrate and exchange data via FHIR®:
- FHIR® notifications
- FHIR® query/response
- FHIR® writeback
FHIR® notifications are real-time, asynchronous messages about specific events that occur within a healthcare setting. For example, these events could be:
- administrative (e.g., a patient books an appointment)
- clinical (e.g., a diagnostic result is posted to the patient’s chart)
- financial (e.g., a charge was added to the patient’s account)
How this works is that your connection allows you to track events for a patient, like a patient’s upcoming and current encounters with a specific provider. Or you could track any changes to a patient's record. The data about the event or change comes via webhooks. On the flip side, you could send notifications with relevant events to your connection's system instead. Either way, learn how to respond to asynchronous events like FHIR® notifications.
We support both lightweight and detailed notifications.
Lightweight notifications are ideal if you 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 FHIR® data on demand.
These notifications are deliberately minimal, which reduces mapping complexity so you can start integrating faster with your connection. Lightweight notifications contain the relevant patient identifier, timestamp, and FHIR® references to related resources (e.g., Patient, Encounter, Appointment). You can always query for more information using the resource references. Combining lightweight notifications with FHIR® queries reduces the need for a complex storage infrastructure so that you can rapidly integrate with a healthcare organization.
Or instead of querying, lightweight notifications could kickstart a workflow within your own system. For example, you may want to receive a notification about a patient's discharge so you can follow up with a customer satisfaction survey about their inpatient stay. But the notification would only contain the bare minimum patient information, not all the details about their stay.
Detailed notifications contain the full payload message with extended information about what happened, who was involved, and when it happened. So you get everything from the lightweight plus all the extra sauce and sides, so to speak.
Detailed notifications are useful if you do want to store lots of patient data or you don't want to bother with follow-up queries. So if data storage and mapping aren't a concern, detailed might be the way to go.
Queries are synchronous, which means that one system queries another (using a RESTful HTTP API) and waits for a response. Read about handling responses to queries. 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.
Writebacks are a “save” type of operation, which allows you to push and write data to your connection’s system. Behind the scenes, this is like a cross between a notification and a query: you initiate a writeback like a query, but it’s asynchronous like a notification.
Our preferred writeback operation style has a unique name that describes the kind of action you're performing (e.g., $patient-create). Check out our FHIR® API reference to see a list of writeback operations for each resource.