# Exchanging FHIR data

There’s more than one way to send or receive data via FHIR. One or a combination of types might be necessary to achieve the needs of your workflow.

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

| **FHIR exchange type** | **Traffic type** | **Use case** |
| --- | --- | --- |
| <u>**FHIR notifications**</u> | Async | Receive a real-time notification when an event you care about happens (e.g., a new appointment is scheduled).  The message header contains metadata about the date and time the message was sent. This metadata is visible in your logs. |
| <u>**FHIR query / response**</u> | Sync | Search for specific data from your connection and wait for an immediate response (e.g., search for a patient’s scheduled appointments). The query or response don’t include message headers with metadata like notifications. |
| <u>**FHIR writeback**</u> | Async | Save or push data to your connection’s system. These are initiated like a query but processed like a notification. |

Dive into more detail about each FHIR exchange type below.

## FHIR notifications

<u>**FHIR notifications**</u> are real-time, asynchronous messages about specific events happening in your connection’s system. 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)

### Technical details

A notification comes via a webhook and contains metadata in a message header. Notifications are a type of the broader FHIR messaging framework. [Learn about FHIR messaging](https://build.fhir.org/messaging.html).  

[Review Redox FHIR notification specs](https://docs.redoxengine.com/permalink/fhir-notification-landing-page). Or, for more general information, [learn more about handling notifications](/basics/data-exchange-with-redox/handling-notifications-and-responses) in your system. 

You can opt in to receive either <u>**lightweight**</u> or <u>**detailed**</u> notifications. 

##### Lightweight notifications

**Contains:** 

- patient identifier(s)
- timestamp
- FHIR references to related resources (used for follow-up queries)

**Benefits:** 

- <u>Reduced mapping complexity</u>: These are deliberately minimal, making it easy and fast to implement.
- <u>Simpler storage infrastructure</u>: Get notified when something changes for a patient, rather than querying repeatedly to find out. Then, decide whether you need more details instead of storing a large volume of data. Eliminating the need to build a storage infrastructure also makes it faster to implement.

**What to do after:** 

- Decide whether to query your connection—or a <u>data on demand</u> repository—for more details about what changed. [Learn about FHIR data on demand](/basics/redox-fhir-api/understanding-fhir-data-on-demand).

**Example:**

You receive a notification about a patient’s discharge so you can follow up with a customer satisfaction survey about their inpatient stay. The notification only contains the bare minimum patient information, not all the details about their stay.

##### Detailed notifications

**Contains:** 

- patient identifier(s)
- timestamp
- FHIR references to related resources
- full payload (describes what happened, who was involved, and when it happened)

**Benefits:** 

- <u>Robust storage infrastructure</u>: Get notified when something changes for a patient, rather than querying repeatedly to find out. Store all the data you need so you have it available as soon as it happens.

## FHIR query/response

Queries are synchronous, which means that one system queries another (using a RESTful HTTP API) and waits for a response. Redox supports the full suite of RESTful interactions mandated by USCDI and more. For more general information, [learn about handling queries and responses](/basics/data-exchange-with-redox/responding-to-queries).

The most common type of queries are FHIR search interactions. Learn more about: 

- [Redox FHIR searches](/basics/redox-fhir-api/understanding-fhir-search)
- [HLv2 FHIR search](https://build.fhir.org/search.html)

## FHIR writeback

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`). [Review our FHIR API reference](https://docs.redoxengine.com/permalink/fhir-resources-landing-page) to see available writeback operations for each resource.

> **FHIR passthrough**
>
> You might be thinking that FHIR offers generic writeback operations like `$write` or `$update`. While that’s true, Redox only supports generic writebacks for passthrough exchanges, i.e., FHIR to FHIR.

> **Limited writeback support**
>
> Most EHR systems don’t support FHIR writeback, but in these cases, we can translate your writeback messages to other more common standards like HL7v2. We currently support translating between FHIR and these standards:
>
> - [CDA](/basics/redox-fhir-api/translating-between-cda-and-fhir)
> - [HL7v2](/basics/redox-fhir-api/translating-hl7v2-to-fhir)
> - [X12](/basics/redox-fhir-api/translating-x12-to-fhir)
> - [DICOM](/basics/redox-fhir-api/translating-dicom-to-fhir)
> - [360X](/basics/redox-fhir-api/translating-360x-to-FHIR)