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. 20% of the success of an EHR project is due to the technology. 80% is due to the 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! W00t! Our new system is pre-loaded with lots of useful stuff!
Happy, nāive CMIO moving data around.
Not so fast, Sherlock.
Here are a sample of problems we encountered trying to make this happen in our organization:
PROBLEM LIST
We tried loading ICD10 codes from one EHR to another. Maybe 1/2 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 EHR’s between two organizations. Then, 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 EHR’s, 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 was, for example:
Lisinopril / 10mg / 2 tablets / once daily / quantity 180 / refills 3
The data Epic expects on the import 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 brand 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 EHR’s, 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 clinic schedule and import Problems, Meds, Allergies, 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 MA’s, RN’s and some clinicians in advance of the EHR cut-over (bonus: increased time spent on the newer EHR grew 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, and scanned 1 month of about 30,000 images. Usage / viewing of those images by clinicians and staff after a year was … ONE 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 for 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: A) 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.
And/Or, B) Allow clinicians to “tag” individual scans from the OLD EHR to be individually moved to the NEW EHR. 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. Maybe give them Red Shirts.
