Lessons Learned from our EMR Upgrade – Part 3
It is after 11 PM and I have just arrived home after a meeting with our practice leadership. Why so late? The meeting doesn’t start until 7 PM. We docs can’t afford to take time out of our practices to meet during the day. We moonlight as CEOs, CIOs, managers, etc. for our own practices.
This was the first meeting since March that was not dominated by unhappy discussions about the system upgrade. It wasn’t even mentioned. Tonight’s EMR discussions were forward looking, including e-prescribing, which just went live for us yesterday, and the pending results of our meaningful use gap analysis that will come out next week. I think we have reached an appropriate point to take some perspective on our difficult upgrade.
To state the obvious first, we bit off too much at once. Going 6 years without a software upgrade is bad enough. But doing a major database conversion at the same time? And buying all new servers? And switching to VMware? What the heck were we thinking?
As I mentioned yesterday we were afraid of using the database merge program (a.k.a. the migration tool) on our precious database until the vendor got more experience with it. We also thought it was a reasonable strategy to feel all the pain all at once rather than spread it out over several smaller steps. Regarding our 6 figure server purchase we were trying to cheat the old rule that any computer you buy will be obsolete by the time you get it home and plug it in.
In retrospect those were all good thoughts. They just weren’t enough. We failed to realize that while the migration tool was getting better through time, our database and applications were at the same time getting bigger and more complicated. Every year we added an average of 50,000 new patients to our database. We also added applications like our web portal and more automated document scanning / indexing. Time also allows strange things to happen…such as when one office accidentally started scanning clinical documents into the practice management database. Tens of thousands of documents were in the wrong place. We picked up on it ahead of time and thought we had fixed it but the migration tool still had a problem with those image files. Sometimes I wonder if we should have upgraded sooner and taken our chances with a less mature migration tool running on a smaller, less complicated, less entropy-riddled database.
The upgrade was harder and far more stressful than the original implementation in 2005. I think this was because we no longer had paper charts as a lifeboat when the system wasn’t working well. The gradual, no-hassle approach to EMR implementation that I wrote about months ago is not an option when you are switching databases. I have a new found respect for practices that are forced to switch EMR programs.
VMware was a much bigger hassle than I expected.
When one considers that the upgrade occurred at the end of 6 years of relatively hassle-free system performance it really wasn’t that bad. But it sure felt bad at the time, not knowing when or if we were going to get the bugs fixed.

