By Kavon Kaboli, Galen Healthcare Solutions
Twitter: @GalenHealthcare
This is part of our data migration blog series – a range of topics intended to help organizations who are migrating from one EHR to another.
In the next phase of the migration blog series, we will touch on the data loading processes that occur close to go-live and the conversations your organization will need to have to ensure that all data makes it into your new Electronic Health Record (EHR) in a timely fashion.
First, let’s set the scene. With Galen’s assistance, your organization is undergoing a data migration – migrating clinical data from one EHR to another. From a project timeline perspective, the scope and planning of the migration have been assessed, clinical data elements have been appropriately mapped, and validation of converted data is underway – now it’s time to start discussing go-live data and gap (catch-up) load plans. The first step is to determine when to start loading data into your target EHR’s production environment and whether or not gap loads will be necessary. Let’s delve a little deeper to better understand this process.
What is a gap load and why is it needed? For most migrations, the majority of the data is loaded into the target system weeks in advance of go-live. While this data is being loaded, end-users are still seeing patients and documenting new clinical information in the legacy EHR. Enter gap loads. The purpose of a gap load is to capture this new clinical data, as well as clinical data that has been updated in the legacy EHR since initially being migrated into your target system. Therefore, the fundamental purpose of a gap load is to shore up any “gaps” that may exist when moving clinical data into your target EHR. Some decisions and circumstances that can impact the need for a gap load are:
- Whether or not your organization plans to allow end-users to reconcile migrated data prior to go-live. Reconciling data requires time, meaning that data will need to be loaded into your production environment several weeks in advance of go-live.
- The time at which your legacy EHR will be switched to a status of read-only. After the legacy EHR has been switched to read-only, it will not be possible for end-users to add new information that would then need to be migrated to your target EHR.
- Loading data takes time, especially notes and scans. To ensure that all data makes it into the target system prior to go-live, Production loads will need to begin weeks to months in advance.
Why is it important to practice loading data prior to go-live? It is important to practice loading data not only to understand the time it takes to execute each step, but also to ensure that all involved resources can perform each task flawlessly. As the go-live date approaches, the margin for error decreases, so timing and execution are paramount. If something goes awry, you may not have time to apply fixes prior to go-live, in which case end-users and providers may not have access to the clinical information they need. Once the team has determined how long it takes to extract, transform, deliver and load a large fraction or all in-scope data elements into the target EHR, a data load date can be established. Keep in mind that certain data types might take longer to load than others (for example, HL7 messages take longer to load the CCDs) and that the volumes across in-scope clinical elements will vary.
Why is it important to load data into the target EHR as close to go-live as possible? The goal of a data migration is to move clinical data from your legacy EHR into the target EHR. With this goal in mind, it stands to reason that your organization would want that data to be as recent and up-to-date as possible. By waiting to load data as close to go-live as possible, you are ensuring that this is the case. Loading the most recent data possible also helps to minimize the number of gap loads that are necessary.
Why is it important to minimize the number of gap loads? As discussed above, implicit in determining if or when a gap load is needed is how current the migrated data is. Minimizing the number of gap loads reduces the amount of testing that is necessary, the potential for error, along with other undesired outcomes. For example, loading gap CCDs requires the import of a second CCD, meaning that a patient with gap CCD data will have more than one CCD on their chart. Likewise, gap lab result data will show as edited results as opposed to final results, while gap notes will show as updated/amended as opposed to signed/finalized. Due to these idiosyncrasies, it is almost always preferred to minimize the volume of gap data and the number of gap loads.
Keep in mind that while loading gap data can result in additional CCDs, or different statuses associated with results, notes, and other clinical elements, gap loads should never result in duplication of clinical data. In other words, if an allergen or a note is updated, that updated allergen or note should still only exist once in your target EHR.
Where do we come in? Here at Galen we have completed 220+ data migration projects. Each of one of these projects has resulted in a high quality end product – the accurate, methodical, and efficient conversion of useable clinical data from one EHR to another. We have the know-how and expertise to help your organization navigate any and all situations that might arise while undergoing a data migration. If you are interested in learning more about the services we can provide, please contact sales@galenhealthcare.com.
For further information, make sure to catch our full data migration blog series.
This article was originally published on The Galen Healthcare Solutions Blog and is republished here with permission.