As an organization begins the conversion process to a new EMR, one of the first problems to solve is deciding which data to migrate and how much. A complete migration of all data will be costly, in terms of both time and money, and is unnecessary in most cases. However, migrating too little data can result in spotty patient history and a violation of legal requirements.
You must first identify which kinds of data need to be present in your new EMR; then, decide how far back you need to go in your legacy system to ensure that you have complete data sets post-migration. In this post, The HCI Group’s Data Technical Lead Mustafa Raja takes a look at three factors an organization should consider before migrating their legacy EMR data into a new EMR system.
1) Migration vs. Archiving
The first step in this process will be coming to a consensus on how much data you will migrate and why it should be migrated. There is often a tendency to think that only six months of acute care data and a years’ worth of ambulatory data is necessary. The problem here lies in the fact that acute care data is made up of several different data types, such as:
- Demographics
- Immunizations
- Allergies
- Medications
- Orders/Results
- Labs
- Radiology
- Flowsheets
These are just a few examples of data types that your health system will need to evaluate while planning the migration. On the ambulatory side, data migration is typically less complex, as organizations usually just need to know what medications that patients are on. Additionally, some health systems request the last years’ worth of diagnostic codes – with this information, physicians will know what ailments a certain patient has, what drugs they are on, their allergies, and what treatments they have undergone in the past year.
Once you have determined which data will be migrated into your new EMR, there will still be masses of data in the old system that will need to be migrated, archived, or taken out of the old system. This old data will have to be put into a manner that is:
- Not costly to maintain
- Readily available and easily accessible
There are two reasons why this excess data must be preserved: auditing and compliance. Auditing comes into play when there is a question about exactly what happened when certain data was breached or accessed; compliance will be questioned during major legal concerns when issues such as malpractice lawsuits arise. In these instances, it will be important to have the audited information available so you have the necessary data to provide a comprehensive understanding of what transpired.
2) Data Complexity and Standards
Complexity of the data must be taken into consideration when deciding what to migrate from your legacy EMR. There will be variance in the data type, as well as the way in which it was stored in the old system versus the new system. Complex data may not be stored in the same fashion as it was in the legacy EMR, so it is important to make sure you have an understanding of the differences.
Typically, there will be a lot of standards in place within the data structure of a new system. However, usually organizations are migrating off of a non-standard legacy system and into a standard system. Therefore, the legacy data will not be set to the standards of the new EMR. You will have to evaluate whether or not a standardization process should be a part of your migration. An alternative to this standardization process would be to simply archive the data. However, using an archival solution means the data won’t be easily accessible, modifiable, or discrete – it will simply be in a readable form.
3) Clinical Rules and Workflows
Often, many of the clinical rules applied to some of the legacy system functionality tend to not relate properly in the new system. This is usually because the new system has improved workflows, is better suited for clinicians, and is less technical than the legacy system. In the case of less clinically-optimized legacy systems, clinicians probably used “workarounds” to navigate through modules, which will necessitate changes in the new system.
For example, you might have non-required fields on a form from the legacy system that are now required in the new system. As you can imagine, this often leads to missing data. More than likely, this information can’t be imported into the new system because it probably doesn’t exist. Now what? Do you use filler to compensate for the empty space? Do you try to hunt down the information and map it into the system? These are the types of questions that must be asked from the standpoint of clinical rules.
These issues necessitate a mapping of rules going forward. You will have to decide whether to keep requirements from the old system, or create requirements for the new system. This will also affect whether or not you train the users to start asking for that data and entering it into the new system. From a migration standpoint, the development of the rules is your main concern. However, remember that training and workflows will be affected by what you decide to migrate. The rules must be understood by your end users; if they were present in the legacy system, you have to ask if the rules need to be implemented the same way into the new system.
A common rule to have in place when going through a data migration project is the simple adage of “junk in is junk out.” With that being said, it is vital that your organization take the time to look at exactly what they are migrating, why they are migrating it, and how they can be consistent with the data they put in to their new system.
For more information on common questions or concerns with regards to data migration, check out our recent post on 8 Solutions to Data Migration Problems.