Understanding FHIR data on demand

Last updated: Aug 25, 2023
HEALTH TECH VENDOR
PRODUCT OWNER

Depending on your system and your connection’s capabilities, we may recommend sending and receiving data via polling or data on demand. We can help you decide what may suit your system the best based on your unique integrations.

There are three typical configurations for data on demand with FHIR®:

  1. Data on demand (standard)
  2. Data on demand + writeback
  3. Data on demand + notification

Data on demand (standard)

Using Redox FHIR® with data on demand saves you time by simplifying the amount of effort needed to consume the HL7v2 data directly. Instead, a Redox FHIR® server ingests your connection’s data into a data on demand repository. Then, you can query for your connection’s data from Redox. Learn more about our standard data on demand configuration.

Standard configuration
Standard configuration

Data on demand + writeback

With data on demand, you can query the repository, but you typically can’t write back to it to update your connection’s system. However, it's possible to write data back to your connection using FHIR® messaging. Learn more about messaging.

For a conventional EHR integration with HL7v2, the data you write back eventually ends up in the data on demand repository after the EHR system processes the message. You may do this if you want to rely on the EHR system as the ultimate source of truth. And it works, so long as you allow time for the EHR system to mediate and validate the data before it gets to your data on demand repository.

For example, let's say that you create a patient record and send it back to the EHR system. But the EHR system already has a record for that patient. Part of processing the new record that you send may include merging the patient record in the EHR system. After processing is complete, you could query for that patient, knowing that the EHR system is the source of truth.

Writeback configuration
Writeback configuration

Data on demand + notification

Another potential data on demand configuration relies on notifications to trigger your workflow. Let's say that you listen for notifications from your connection. So, a healthcare organization sends a message to your system whenever there's a relevant update. When you receive this notification, you may want to query your data on demand repository for more information. For example, if you receive a notification that a patient was discharged from the hospital, you may want to retrieve a transition of care document to get details about their inpatient stay.

Notification configuration
Notification configuration