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 |
|---|---|---|
FHIR® notifications | 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. |
FHIR® query / response | 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. |
FHIR® writeback | 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 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)
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.
Review Redox FHIR® notification specs. Or, for more general information, learn more about handling notifications in your system.
You can opt in to receive either lightweight or detailed notifications.
Contains:
- patient identifier(s)
- timestamp
- FHIR® references to related resources (used for follow-up queries)
Benefits:
- Reduced mapping complexity: These are deliberately minimal, making it easy and fast to implement.
- Simpler storage infrastructure: 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 data on demand repository—for more details about what changed. Learn about 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.
Contains:
- patient identifier(s)
- timestamp
- FHIR® references to related resources
- full payload (describes what happened, who was involved, and when it happened)
Benefits:
- Robust storage infrastructure: 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.
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.
The most common type of queries are FHIR® search interactions. Learn more about:
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 to see available writeback operations for each resource.