Backfill your database before go-live

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 appointment. 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 prior to you integrating with your connection. This means you need a backfill of appointment and patient data so that your app can start sending reminders to the existing patients with appointments.

Even if you don't have a client-facing need for historical data, it may be useful to have historical patient data even 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 and decide the best option to backfill your system prior to going live.

There are two common options for backfilling:

1. Your connection uses an existing configuration to push historical data to Redox to populate your backfill prior to going live. If available, we recommend this option since it simplifies the effort to process the backfill and leverages existing mechanisms for real-time integration. 
2. 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's system.

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 requesting.

For example, it may be nice to have laboratory results from the past 10 years, but it could extend your implementation timelines in order for your connection to compile the data–and for your system to actually consume that much data.

When deciding how much data to request, make sure to (a) prioritize only the absolutely critical data elements for a backfill; and (b) consider how quickly your system can consume the amount of data you're requesting.