Thoughtful Data Mapping: The Key for Usable Data
In previous blog articles, we have shared important considerations and insights for achieving a successful data migration. Data mapping is not only an essential part of the migration process, it is central to all other project activities. At its simplest level, the process of data mapping involves analyzing data from system A, and then finding its match in system B. There are, however, many variables to consider when mapping data. These include: where end users will expect to find the data in the target EHR, or how they will be able to identify the origin of the data. Thoughtful and accurate data mapping is a complex topic. Applying careful analysis to mapping decisions is key to ensuring accurate migrated data.
The data mapping process takes place early in the data migration project lifecycle. For every unique piece of data in scope, such as note types, problems, or encounter types, a crosswalk is created between codes from the source and target EHRs. The process begins with a Technical Data Migration Analyst extracting data from the source EHR. They must make sure to account for all areas where the data might be stored.
This data is provided to a Clinical Data Migration Analyst. Using extracts obtained from the target environment they make the initial determination of data mappings. The goal of mapping source data elements is to find their matches in the target system. This can be accomplished by a 1:1 match between dictionaries or data sets so that converted data appears nearly identical in the target system. However, complexities often arise that require creative mapping solutions or even building of new clinical elements in the target system.
Challenges frequently occur when mapping note types because EHRs contain specific note type designations based on established workflows. Incongruities between source and target EHR workflows can result in particular note types lacking a 1:1 match. The initial reaction might be to build a new note type in the target EHR to accommodate the workflow. This may not be the best solution. In such cases, Galen has worked closely with the client’s implementation team to determine how this data will be stored and utilized moving forward. An example of one solution implemented was to map both “New Patient” and “Follow Up” notes from the source EHR to “Progress Note” notes in the target EHR to align with future workflows.
Problem mapping poses its own set of complexities due to the various codifications used to define problems, and the fact that source EHRs associate problems to multiple code sets, such as SNOMED, ICD-9, and less frequently ICD-10. Since ICD-10 codes provide a more detailed description of a patient’s condition, automated mapping based on older code sets can cause mismatches between problem descriptions that are not clinically equivalent. Problem mapping requires experience and additional scrutiny to ensure accuracy, and a tiered analysis has proven to be the most effective approach.
In a recent data migration project, we identified the diagnosis code used in the source EHR by the provider at the time of assessment. Once identified, all other codes associated with the problem were discarded. After the initial mapping, clinical resources reviewed data where problem names of the migrated problems had no clinical match, and all migrated codes associated with these problems were removed. These problems crossed over as “unmapped” and displayed in the target EHR exactly as they were documented in the source EHR for the benefit of end user reconciliation.
Throughout the mapping process, it is important to consider that organizations have a myriad of reasons to distinguish migrated data from data entered directly into their EHR. One of the best ways to accomplish this is by mapping migrated data to something that denotes “conversion” in the target EHR. As an example, one organization decided to create a “conversion” encounter type so that it is clear to anyone using the target EHR that the data tied to a “conversion” encounter came from an external source.
These are just some important considerations to take when performing thoughtful data mapping with the goal of producing usable migration data. For additional information, check out the full data migration blog series!
Looking for more information? Contact us below
+ There are no commentsAdd yours