When you go live with an integration, you start receiving patient data from your connection's system from that point going forward. Depending on your unique workflow, you may require historical data to provide enough context for your system to do its job.
Let's say you have a scheduling app that reminds patients about their upcoming appointments. You plan to start sending reminders to patients from your connection's system once you go live with the integration. But some existing patients booked appointments before you started integrating with your connection. So you need a backfill of appointment and patient data so that your app can start sending reminders to existing patients with appointments.
Even if you don't have a client-facing need, it may be useful to have historical data for patient searches from your system. Without a backfill, you could only search for new patients created from the point of your implementation going forward.
During the scoping process, we recommend that you work with your connection to define what historical data you may need. You can also discuss which is the best option to backfill your system before going live.
We understand the importance of backfilling quickly and efficiently. To make sure you can go live as soon as possible, Redox processes upwards of 100K logs per hour. Actual throughput varies, of course, depending on several factors like the data exchange method and throughput capabilities of both the sending and receiving organizations. A Redoxer can help you pick the best backfill option based on your specific integration needs.
There are two common options for backfilling:
- Your connection uses an existing configuration to push historical data to Redox to populate your backfill before go-live. If available, we recommend this option since it simplifies the effort to process the backfill and leverages existing mechanisms for real-time integration.New beta option: Child queues for subscriptions
- Your connection populates one of Redox's CSV flat file templates for historical patient and appointment, then sends it to your system. The file can be uploaded to populate your backfill. This option is sometimes easier for your connection.
When deciding how much data to ask for, make sure to:
- prioritize only the absolutely critical data elements for a backfill; and
- consider how quickly your system can consume the amount of data you're asking for.
There are also different things to consider depending on whether you're backfilling for Redox Nexus™ or Redox Nova™.
It’s typical to backfill an entire patient population, six months of future appointments (from the go-live date), or a current inpatient census. Whatever you decide, we recommend carefully considering the quantity and type of data that you backfill. Make sure you prioritize only the absolutely critical data elements for a backfill.
For instance, consider how quickly your system can consume the amount of data you're asking for.
For example, it may be nice to have laboratory results from the past 10 years. However, it could extend your implementation timeline for your connection to compile the data—and for your system to consume all that data, too.
For cloud users, you likely need a full longitudinal view of your patient population. So you may want patient- and encounter-level clinical summary documents or other supplemental data so you can identify ties and gaps in patient care. To create that kind of patient picture, it's likely you'll need a backfill of tens of millions of records in your cloud provider's repository.
If we run large scale backfills (e.g., more than 5M messages), we'll set up the system to separate backfill data from real-time data. That way we can process your data efficiently while not disrupting other real-time traffic. Coming soon in the Redox dashboard, you'll be able to see your logs that are classified as backfill traffic versus real-time. Stay tuned!