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.
You may also need a backfill if you're using data on demand. If so, the same scoping considerations and backfill options apply. Learn more about data on demand.
There are two common options for backfilling:
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.