Access Historical Records. Simply.
Powered by Harmony Healthcare IT. Call Us (800) 781-1044

EHR Conversion Hurdles: Merging Data from Multiple Sources

Posted on | May 10, 2017

Visit our Resource Center

Healthcare merger and acquisition activity is prevalent as hospitals and health insurance companies look at growth and alliances to drive success in a post-healthcare-reform world. But with M&A comes real-world data sharing and EHR conversion problems as it pertains to information systems and electronic health records.  Successfully merging data from multiple sources is, perhaps, one of the most misunderstood and consistently underestimated problems in health IT today.

Harmonizing EHR Data to be Usable Outside of its Source Systems

If you are combining data from multiple sources and want the data to be usable outside of the source system then you will need to merge the data into a harmonized database or dataset.  A “harmonized” dataset offers the benefit of storing data from different systems in a discrete and re-usable form for extraction and import to a reporting or other EHR system. In converting to new EMR, the process involves taking data from a legacy system and doing the best you can to map and “fit” the data into a new system. It may sound simple, but it’s not as easy as connecting the pipes, turning on the water, and getting drinking water out the other end.

What Makes EHR Data Harmonization Difficult? 

What makes data harmonization in healthcare difficult is not the volume, variation, or other “V’s” of Big Data (although they do present their own unique challenges).  Data harmonization in healthcare is difficult because of the high level of ambiguity and complexity in the data concepts themselves. For example, patient demographic information can be merged fairly easily from one system to another. Demographic concepts (age, gender, address, etc.) are highly certain, or unambiguous.  This means there is general agreement as to what “age” means in relation to a patient.  It’s easy to identify the field for age in a legacy system and map it to the field for age in the go-forward system. There may be formatting issues at play, MMDDYYYY versus YYYYMMDD for example, but everyone is operating under the same definition for the data point itself.  But, the certainty ends there. Once you get past the simplicity of demographic data, you quickly find that financial and clinical data points aren’t as easy to map between systems for a multitude of reasons.

The Challenges of Mapping Clinical and Financial Data for Conversion

First, there is a high level of ambiguity surrounding clinical and financial data.  Much of this ambiguity stems from the lack of standardization in healthcare practices, processes and payment. Recall any recent article about how healthcare prices are determined — the seeming lack of rhyme or reason —  and you can easily see where inconsistency in practices leads to ambiguity of the concepts themselves. Second, EHR conversion is challenging because not all systems store data in the same discrete format, and many systems use proprietary logic that determines how and where data is stored in the underlying database. Third, the flexibility of commercial EHRs has been both a blessing and a curse. Many organizations chose to customize their EHRs to “fit” local operations, realizing too late that they had opted out of a standardized workflow that would have collected data in a clean, consistent, and re-usable way.  Some missed the opportunity to critically evaluate business as usual, automating bad business practices that led to bad data collection. Other organizations made poor design choices inserting mandatory fields at inopportune times during patient care that led to workarounds and bad data capture.  Local EHR configuration and workflows directly determine how data is captured, and ultimately, the interoperability, quality and re-usability of the data for other purposes.

Six Healthcare Data Considerations When Replacing an EHR

In our work with hundreds of acute and ambulatory healthcare organizations, we’ve identified six health data migration considerations when replacing one EHR with another.

  1. Filtering Patient Records. This is a method for filtering out certain patients to exclude from migration. For example, you may not want to migrate patients who are deceased or inactive. Is there a deceased patient flag in the system? If so, can it be trusted? If the plan is to move recent patients only, then what criterion will be used to filter those patients? Will you use last appointment date, encounter date or charge date? It is important to validate the integrity of your healthcare data prior to migration.
  2. Starting with a Clean Slate. Demographics are, of course, a must-migrate. Beyond that, the ability or cost to logically map detailed collections of data from one system to another can become a limiting factor. For example, it is sometimes difficult to neatly convert insurance plan identifiers between two databases. So, while it may entail a lot of manual entry, many providers use the new EHR system implementation as a trigger point to re-collect insurance information from patients at check-in and start fresh entering it manually into the new EHR.
  3. Matching Patients. If you are migrating health data to a system that is already in use (as opposed to a brand new system that is not yet in use) and there is not a common identifier between the current EHR and the go-forward EHR, a patient matching event should certainly occur. First, clean-up duplicate patient accounts on the current system. Next, determine which fields to use for matching logic. Common fields to match off of include: First Name, Last Name, Middle Name/Initial, DOB and SSN. You can take it one step further by also matching on street address.

Where do you set the bar for a patient match? Think about how many fields need to matchup to be considered a true match: 5 out of 5? 4 out of 5? Perhaps you will schedule a manual review at 3 out of 5 and 4 out of 5? You also need to decide if anything less than 2 out of 5 matches are automatically marked as a fail.

For patients who do not have a match in the go-forward system, should a new master patient identifier (MPI) be assigned? If the MPI is sent over empty, will the go-forward system create the MPI on the fly? Determine if an MPI should be assigned prior to that patient being migrated to the go-forward system and set a standard to follow when generating that MPI:

  • How many digits should it be?
  • What schema will it follow? (i.e., 10xxxx or ABCxxx)
  • Most importantly, will that new MPI play nicely with identifiers in systems interfaced with the go-forward system? For example, when migrating data from CPSI to Cerner, let’s say that MRNs for unmatched patients were auto-generated with no standards. If that were the case then once the site was live on Cerner, it stands to reason that they could realize some of the identifiers used were MRNs in their PACS system that was interfaced with Cerner. That could entail data from a patient in Cerner being sent over to a different patient MRN in the PACS system. This is why pre-planning is critical.
  1. Timing it Out. How long will it take for the final data pull to be done and pushed into the new system? The answer requires some decision making and some math. Determine if you will utilize a differential or do dual entry. Depending on data content and size, estimate the time it will take (typically 1-2 weeks). Planning ahead and allow ample time for the healthcare data migration can avoid some headaches for the rest of the EHR implementation.
  2. Cross-walking Data Elements. Determine if a crosswalk is needed before you start the health data migration. They can become complex, so, think about how your use of LOINC, SNOMED, or RXNorm codes in the current system will parlay into the go-forward EHR. Does the new system use these codes as well? Or, if these codes were not used in the current system but are used in the go-forward EHR, what will the exercise be to match these up? This also is the time to consider the handling of provider codes, facility codes, pay codes, fee schedules, insurance providers, insurance plans, etc.
  3. Securing Resources. If yours is like most organizations, often the IT staff is extremely busy building, planning for and training in the new system and you don’t have resources available to assist on items pertaining to the healthcare data migration. Three areas that require time and attention include: data validation in the test environment, manual clean-up on patient matching and building out the crosswalks. Don’t skimp in these areas. If internal resources aren’t available, make sure as trusted healthcare data migration vendor can provide these critical services.

Overcoming the Hurdles of Data Harmonization

If you consider all of the issues listed above, and multiply those by the number of different data sources you are trying to combine, you can see how converting to a new EHR can be a very difficult challenge. But, there is a way through the complexity. Seasoned resources who understand workflow can determine how and why your data was created, unlocking the value of how that data can be re-used to support quality improvement, population health, operational efficiency, or whatever business goals drive your institution. Harmony Healthcare IT and CETA solve these complex data challenges on a regular basis. If you need best practice recommendations or consultation to define a data strategy, please contact us.

Guest Blog submitted by Michelle Currie, RN, MSN, CPHIMS, CPHQ

emr conversionMichelle is a registered nurse with more than 15 years of experience in Clinical Informatics. She received her BSN from the University of Michigan and her MSN in Clinical Informatics from the University of California at San Francisco. In addition to serving as Chief Data Officer at CETA, Michelle volunteers her time as an annual Conference Presentation Reviewer, Mentor and Moderator for HIMSS.

Editor’s Note: Some of the information contained in this blog has been updated from a previously published entry from 2015.

Posted in Data Migration, Mergers and Acquisitions Tagged with: ,