The Data Factor with EHR Migrations: How Much Is Too Much?

Swapping or Merging EHRs? Don’t Make Me Start with a Blank Chart! Or Should We?

You’re kidding right? No one wants to start with a blank EHR screen when seeing patients. There has to be a way to automatically move data from [fill in name] EHR to [fill in name] EHR. Right? Right?

It is a tale as old as time (or at least since the early 2000’s when clinics started installing Electronic Health Records). Hey, my EHR sucks! That other one over there must be better. Let’s rip out the current one and put in a new one. Surely that will fix everything!

First of all, that is a fallacy. Twenty percent of the success of an EHR project is due to technology; 80 percent is due to socio-political skills and workflow designs of those doing the installation.

Secondly, maybe we’re too late, and the new system is nearly fully installed. We’re just waiting on the data-load. How much data do you pull out of the current system and push into the new? Easy, right? All of it! Surely all that typing, mousing, clicking that our physicians and APPs and nurses and staff did entering data can’t be wasted.

In fact, I’ll make it easy. Here’s a list of data to pull over

• Problems (clinical diagnoses, billing diagnoses, problem list)
• Medications (historical meds, active prescriptions)
• Allergies
• Immunizations
• Past Medical History/Surgical History/Social History/Family History
• Progress Notes, Hospital Notes, Emergency Department Notes

Done! Our new system is pre-loaded with lots of useful stuff!

Not so fast, Sherlock.

Below is a sample of the problems we encountered trying to make this happen in our organization.

Problem List

We tried loading ICD-10 codes from one EHR to another. Maybe half of the codes come across okay. Others start with “Adrenal Adenoma” and end up with “Adrenal Mass, Not Otherwise Specified.” In many charts, our physicians complained that “It would have been easier to enter new diagnoses rather than fix the details of the ones that imported incorrectly.”

Another issue: sometimes you end up merging EHRs between two organizations. You’ll get “Diabetes, type 2” and then a semi-duplicate “Diabetes, poorly controlled, type 2” and “Elevated Glucose” and “Diabetes, type 2, well controlled.” And then your physicians end up cleaning duplicates — or worse, just leaving the mess as is.

Medications

We transitioned EHRs, years ago, from Allscripts Touchworks to Epic. We pulled 2 million medications out of one EHR and ported it into the other. Unfortunately, data stored in Allscripts looked like this:

Lisinopril/10mg/2 tablets/once daily/quantity 180/refills 3

The data Epic expected was:

Lisinopril/10mg/total dose: 20mg/once daily/quantity 180/refills 3

As a result, the third field caused an error, and now the result of the import:

Lisinopril/10mg/__ (defaulted to 1)/once daily/quantity 180/refills 3

And the physician using the new system might prescribe the wrong dose. Thus, we hired a team of pharmacy technicians to go through each patient and fix the errors. It turns out to be much faster to enter an entirely new prescription than to correct an imported one. Booooo.

A Human Team for Importing Data

We ended up hiring a team of abstractors. How did we do this cost-effectively? As UCHealth grew as a system, we would add new clinics and hospitals, often with patients in common (eg, electronic data in 2 EHRs, in health systems that were coming together). Automation and importing tools are still not up to the task of seamlessly merging data sets (eg, here is a lisinopril prescription from 9/2019, here is another one from 3/2020. Are they the same?). As a result, we thought about the most efficient way to fund a team to do this work. We ended up with Pharmacy Technicians, supervised by a Pharmacist.

Import Team Work

We would send a team into a clinic to look at the schedule and import Problems, Meds, Allergies, and Immunizations. We decided against importing Past Medical History, Past Surgical History, Social History, Family History. These last 4 were generally of poor quality. Garbage In, Garbage Out (and costly in person-hours).

Pharmacy Techs do well at meds, allergies and immunizations, and diagnosis selections were easily trained.

Sometimes clinics would pay overtime to MAs, RNs and clinicians in advance of the EHR cut-over (bonus: increased time spent on the newer EHR helped grow their skills).

The team would abstract charts up to 3 to 6 months while using the new system, thinking that the most complex patients in a clinic would be seen more frequently, and then the bulk of the complex patients would be loaded.

Scanning

We chose not to bring scanned images wholesale into the new EHR. We did a trial for a busy primary care clinic, scanning 1 month of images (about 30,0000. Usage/viewing of those images by clinicians and staff after a year was … 1 percent. About 300 images were ever viewed, and most of the views were insurance cards! This is a very low utilization rate for a high cost, slow process of scanning, importing, and indexing. Perhaps newer OCR (optical character recognition) and AI self-categorization tools might help in the future.

Instead, we asked clinicians to do either (or both) of the following:

1. Incorporate data from old notes/EHR into the new one in their progress notes or problem list. We kept the old EHR live for one year so that clinicians could cross reference without importing.
2. Allow clinicians to “tag” individual scans from the old EHR to be individually moved to the new This resulted in a small, manageable list of scans to bring over that were most useful (discharge summaries, consultant notes, critical radiology reports).

Data transitions between EHRs? Hire a team.

This piece was written by CT Lin, MD, CMIO, UCHealth and Professor of Medicine, University of Colorado. To view his blog, Undiscovered Country, click here.