How are archived data and “migrated” or “converted” data different? There must be a clear distinction made between converted data and archived data, as the drivers and considerations for each are different. Retiring a legacy application and housing the data in an archival solution has markedly different requirements than migrating data from an existing clinical application to another.
Retiring legacy systems typically do not necessitate changing the “shape” of the data to fit a particular model. However, with EMR migration, data typically needs to be mapped and translated to facilitate proper import into the target system. The main difference between archived data and converted data is volume. A data archive includes most if not all of the data in its full integrity.
Why Not Just Migrate?
The process of EMR data migration almost always results in some fairly fundamental alteration of the legacy EMR data. The underlying data models used by EMRs differ greatly from one another, and it’s not a matter of export/import. Instead, it’s a true ETL process – extract, transform, load. The shape of the data is changed. Sometimes data types undergo conversions, such as a number to a string, which, if done poorly, can result in loss of precision.
From a clinical perspective, it’s probably not useful to take 15 years of legacy data and load that directly into your new EMR. While Some EMR vendors will even expressly limit the
mechanisms for data import to something like a CCD (clinical continuity document) import, which inherently limits the scope and quantity of available data that can be preserved. On top of vendor restrictions, there are two significant data sets that are rarely if ever included in a migration effort: audit trails and clinical item version history
Bottom line: It’s complex and expensive and, in many cases, not possible for the same reasons that audit trails are not possible (EMR vendor limitations).
Why Not Just Archive?
Clearly, a migration isn’t going to cover all of the legal scenarios, and if the archive has everything we need legally and clinically, why not just skip that time-consuming and expensive migration process and only archive. Primarily, it’s because an archive-only approach means abandoning millions of dollars’ worth of hard-won documentation and all the automation and analytics that goes with that once the transition to the new EMR is complete.
Approaching a Clinical System Transition
It may be tempting to leave the data behind, especially if the data is tied to a system with a poor implementation and substandard data integrity. In addition, there may be reservations to coalesce the data with the existing system when not starting from a blank slate EMR implementation. One thing is for certain, it is not a sound strategy to abandon the single most valuable asset HCOs possess (this data), especially given the endless usages of that data for reporting. Even if the data is not converted, a plausible scenario would be to house the data in an archival solution, providing contextual single-sign-on (SSO) to the archival system. This approach not only mitigates concerns around the reconciliation of the data, but is also allows for the sunset of the legacy system (and the licensing and maintenance costs that go along with it.)
Data conversions are not only an essential part of the clinical system migration process, but they also play a major role in the overall lifecycle of the source system. The primary goal is mapping source data elements to 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 systems.
However, complexities often arise that require creative mapping solutions or even the building of new dictionary items in the target system. Learn more by downloading our EMR Archival Whitepaper we’ll take you through Mapping & Translations, Custom Conversion Logic, and Detail & Version Data. Or, if you’re interested in learning the ins-and-outs of archival, Download our Healthcare Archival Strategy Whitepaper.
Contact us below with any questions: