I was recently hired to help a large health system migrate their ambulatory platform. They previously ran a best-of-breed system, with different vendors for their inpatient and ambulatory platforms. I’ve been working with them for some time now, although my previous engagements were around optimizing their outpatient workflows and helping them bring on new specialties and practices as the employed physician group expanded. Due to problems with their inpatient vendor, however, they decided to go for a single-vendor solution.
Their idea of a system selection process was pretty sad. They didn’t even really go to market. The decision had been made without much input from anyone except the CIO and the CFO. Of course, the employed physicians were upset, especially since they were happy using their current software and felt a bit like the health system had thrown the baby out with the bath water. It’s hard enough to do a migration when you have a legacy system that providers hate, but trying to do one with a legacy system that providers actually like and use efficiently is another challenge altogether.
My client’s parent organization doesn’t have a CMIO at the corporate level, although it has several medical directors who work together to fill that function across the different areas – ambulatory, inpatient, home care, hospice, etc. Although they’re a great group of physicians and dedicated to making systems work better for users, they’re unfortunately all part-time informaticists. Between their clinical practices and current EHR-related duties, none of them really have time to spearhead the migration efforts.
This led to an understandable amount of chaos as the IT department steamrolled ahead making decisions about architecture and setup. The IT department also made determinations on what clinical data should be migrated and what shouldn’t, without getting any kind of clinical approval. No one even knew it was going on until an analyst sent a conversion file to one of the physicians to ask a question about the data.
The physician informaticists demanded an immediate halt to any conversion or migration work until they were pulled into the loop. That’s how I was tapped to assist, since I’ve assisted with plenty of migrations off their soon-to-be legacy system. I haven’t done much work with this receiving vendor, however, and it’s been an eye-opening experience, especially since they’re one of the big three vendors that purports to have their act together. What I’ve seen behind the scenes has been concerning, with occasional episodes of being thoroughly horrified.
To start with, the vendor didn’t provide any recommendations on what kinds or how much clinical data should be brought into the new system. They left it completely up to the health system to define. The vendor’s front-line teams weren’t prepared to have any conversations around what similar clients have done or how things worked for them. They also didn’t make any recommendations on how to clean up the MPI for the most successful conversion of patients, which is a recipe for filling the new system with junk.
I’m not expecting a vendor to make detailed recommendations, but some basics, such as, “You may want to only consider bringing active patients in to the new system” might be helpful. I’m not sure if their lack of recommendations is truly systematic since I’ve only been working with a couple of vendor employees, but they’ve been less than helpful.
From the clinical side, the health system had decided to “bring everything over” on their patients regardless of data integrity or usefulness. Part of this was driven by the fact that they didn’t want to pursue an archive solution for the legacy patient records, which was in turn driven by cost concerns. I’m not sure those concerns are well founded, especially when you look at the potential risks of bringing across so-called “dirty data” due to an ineffective migration plan. Plus, do you really want to populate your new system with expired patients and those who have moved away? Do you really want to fill your brand new charts with 10 years’ of medication history?
I was brought in largely to help ask the hard questions around these topics, plus to help the client’s team of informaticists to learn what they don’t know so they can start to take on some of the migration tasks. I was able to help them focus their specifications on what they wanted to bring across.
We started with medications, since those are typically straightforward given the preponderance of NDC and RxNorm codes in most systems. Although we had a couple of blips, we were able to finally get a good data set of medications which have been active in patient charts over the last 18 months. The entire medication history will be pulled as well, but it will be turned into a PDF document that will be stored in their scanning solution rather than inserting all that data into the prescribing module.
We are now working on the patient problem lists, immunizations, and diagnosis history data. The latter is unfortunately complicated by the recent migration to ICD-10, so there’s a fair amount of duplicative data that we’re still trying to figure out. At the same time, I’m lobbying the leadership to reconsider an archive solution for some of the other data, including all the patients who are never going to be seen in the new system.
I’m surprised by how difficult this fight has been, but I need to learn to not be surprised by anything from clients. Once you think you have them figured out, there’s always something that comes up to remind you that you haven’t thought of everything.
In parallel, there have been rapid design sessions going on where the physicians are supposed to be designing their future-state workflows. The build environment that was set up by the vendor included data from previous clients, which was easily identifiable (physician and facility order sets) and for the “vanilla” content from the vendor, I’m surprised by how rudimentary it was. With the availability of high-quality order sets and clinical decision support, I’m surprised they’re not incorporating more in their base installation.
The expertise of vendor reps in some of these design sessions has been lacking. They’re still working as if they’re bringing up new clients who have never been on EHR and haven’t been prepared to address the issues faced by organizations that have been live on a system for years. It’s as if their implementation process is stuck in 2002.
The project continues to suffer from scope creep, which is OK for me as a consultant since the client has asked to extend and expand my engagement. Job security in this economy is important and it will keep me busy for several months. Even better, it’s in a great location. I might just have to conduct more onsite visits than I might otherwise do for a project like this. Best of all, the client-side people I work with are not only helpful but fun, which is an asset for any consultant.
Where’s the most fun place you ever worked and why? Email me.
Email Dr. Jayne.