Exchanging FHIR data

Redox supports a few ways to integrate and exchange data via FHIR®: 

1. FHIR® notifications
2. FHIR® query/response
3. 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 enables you to track changes or events for a patient (e.g., a patient’s upcoming and current encounters with a specific provider) via webhooks. Or, 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 or detailed notifications.

Lightweight notifications are ideal if you only want to understand if something 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) in case you want to query for more information. 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 also potentially kickstart a workflow within your own system. For example, you may want to receive a 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 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.

This is useful if you do want to store a significant amount of patient data from your connection. Or, detailed notifications may be a better suited option if you don't want to bother with follow-up queries and data storage or mapping aren't a concern.  

This is typical synchronous data exchange, 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.

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.