Don’t Leave Any Patients Behind in Your Legacy EHR

Don’t Leave Any Patients Behind in Your Legacy EHR


Data Migration Blog Series: Considerations When Preparing For a Data Migration

One of the most important and surprisingly often overlooked parts of a data migration is appropriate planning to determine the patient population scope.  The focus of the scoping process is typically dedicated to deciding what clinical data elements should be included, but not necessarily a detailed discussion on what specific patients need to have their data migrated.  Some of the overlooked considerations when solidifying the patient scope include: date range of patient’s last visit, providers who “own” the patient’s data, location of previous visits, and the patients’ status.

Many times, the people responsible for scoping are not involved with the technical aspects of how the data is stored and how that data can be extracted and translated to send into the new EHR.  This leads to generalized details in the scope of work that need further discussion and decisions once the project begins and access to the legacy system is obtained.  Often, the data migration project team will begin working on extracting the clinical data, and at that point try to refine the actual patient scope.  Galen has encountered many different situations when it comes to analyzing and refining patient scope.  We have compiled some of the areas that organizations should consider when planning out what patient population to include in their data migration and how to prepare for them.

Shared EHR Database

  • An uncommon scenario we encountered in a recent project consisted of the organization we were working with planning on moving a group of providers to their new EHR, but those providers had previously shared their EHR with other providers who were moving to a different organization.
  • The organization responsible for moving the data into their current EHR had to be careful from a legal perspective to not move any patient data that was associated with one of the other providers not coming to their organization.
  • To migrate the data for the correct patients, we needed to work out a plan on how we would identify the patients we were legally allowed to migrate. This was achieved by using a combination of their documented PCP and the location they were last seen at to determine if they would be in scope.

Limited Patient Scope

  • Another consideration is whether all patients in the legacy EHR should have data migrated to the new EHR. Sometimes, it’s difficult to separate out how for back to pull patient records based upon visit from how many years of a specific data element is needed.  For instance, there may be a desire to migrate demographic information for all patients who have been seen the last 5 years, but only 3 years of notes to be migrated.  Many times, clients want to migrate all patients to the EHR, but migrate a limited amount of clinical information.
  • On the other hand, the sole objective may be migrating data to achieve clinical continuity of care, and the migrated patient population should reflect clinical data scope. This scenario dictates considerations that must be weighed. If migrating 3 years of notes, should all patients seen in the last 3 years be migrated, or migration of patients who have a note in their chart in the last 3 years? This would omit from migration those patients which have been seen, but do not have a note on them.
  • Another factor involves filtering of patient statuses. This factor is typically not fully appreciated until the data has been thoroughly analyzed. The most obvious filter includes test patients, typically identified through naming convention or another flag. That said, deceased patients or patients that have become inactive due to not having a visit in a certain period of time must also be considered. Further, if archival of the legacy data will not be pursued in parallel to data migration, deceased and inactive patients should be kept in scope to comply with record retention requirements.

ADT Feed or Bulk MPI Load?

  • If pursuing a bulk load of MPI data to be fed into the target system, a process/resource should be put in place to perform these into the test environment before each round of migration validation.
  • If an active ADT feed from the source PM system exists, that usually simplifies the MPI load timing. The feed should be bifurcated such that the test environment is also receiving this feed (or is copied from your Production environment). However, using a live feed can be difficult when dealing with patient matching and identifiers such as MRNs. Most of the time the legacy MRN will need to be migrated to the new EHR and populate an alternate ID field, thus it will need to be included in the live feed.
  • In either scenario, patient demographic clean-up is a possible scenario as the target system might already have the patients in the system and/or the legacy system has duplicate patients. It’s important to discuss the implications of patient merges prior to a data migration.  Depending on how the legacy and target systems are set up, how the data is migrated, and what matching criteria is being used, merging patients before a data migration can lead to patient matching errors.  It’s very important to discuss with the data migration vendor and involve registration/HIM resources in the discussion early on to work out these types of issues. Knowing who will be responsible for this task and the timeline needed to get their work done is a must for any data migration project.

These are just a few of many patient related questions that need to be considered when preparing for a data migration.  You may not know the answers until you are able to analyze the source data in greater depth, but if you can start the discussions early on with the correct resources involved you will have a better foundation to make decisions when the project starts.

Facebook Twitter Email

+ There are no comments

Add yours

This site uses Akismet to reduce spam. Learn how your comment data is processed.