It seems like I’ve covered EMR updates quite a bit before. However, I keep hearing more examples that are very good illustrations of the challenges associated with software updates to an EMR.
Today’s example has to do with a simple change to the template interface on an EMR. This was a small change in relation to the 116 pages of release notes/documentation that was provided with the update. All it did was make the Submit, Cancel and Reset buttons always appear at the bottom of the template. It’s kind of like freeze panes from Excel if you’ve ever used that.
This is a great feature if you’re filling out a long template and half way through you want to submit the template and come back later to finish it. Who would have ever expected that this would become a problem?
Well, turns out that the same template interface is used for doctors who are filling out templates and also for patients who are filling out templates when filling out their paperwork at check in (something we’ve loved doing for the past 4 years). The problem is that now that the Submit, Cancel, and Reset buttons always appear at the bottom, the patients don’t realize that the intake paperwork has more questions. Most of them don’t look at the scroll bar to see that they’ve only filled out a portion of the paperwork. So, the patient submits the paperwork half done. You can imagine how nice that is for a clinic.
I won’t go into how to resolve this issue. There are a ton of different options from educating the end user to requiring certain questions to getting our EMR vendor to change it back to the old way. However, the point of this isn’t how to fix it (maybe a topic for another post).
The point is that a minor change to your EMR software can have some really annoying unintended consequences in places you might not have ever considered.
Many might argue that this is a reason not to implement an EMR. However, that would only be looking at part of the story. I could list a dozen other features that were added during the update which improve how we care for patients.
So, is it painful when an update causes problems? Absolutely. Is this an important reason to have a tight relationship with your EMR vendor? Absolutely. Should you still update your EMR regularly? Absolutely. Is EMR still the future of healthcare? Absolutely.
A “tight relationship with your EMR vendor” is one thing; vendor lock-in is closely related. MS Windows and the Oracle database are examples of companies whose success depends not primarily on technical excellence, but making their customers so dependent that they find it almost impossible to use an alternative product.
“Is EMR still the future of healthcare?” Certainly — in some form or another yet to be determined! The open source revolution (a la Linux) has yet to reach the EMR world, which is still in the pre-PC stages (when mini-computer makers like DEC, Data General, and Sun sold proprietary hardware/software solutions, and the customer was forced to “take it or leave it”). So users should be very picky when choosing an EMR solution, scream bloody murder when things go wrong, and (most importantly) be prepared to switch vendors and let your vendor know that.
Meanwhile “Caveat Emptor”.
Sure, “tight relationship with vendor” and “vendor lock-in” are 2 very different things. Tight relationship with the vendor means that when you ask for changes, patches, support that you actually get a response from them. I can tell you about each of the support people for my EMR company along with the development people. It’s that important to me.
The form is still being determined. Although, I think that’s part of what’s so exciting about EMR.
You should always do a ‘regression’ test with any upgrade… or change. Meaning testing every function of the EMR. This sounds time consuming, but there are many tools that can automate this process to a one button click operation. Imagine testing your whole EMR with one click…. its not that hard to do. Software has been around for a long time, and EMR is just software at its core.
Thanks,
Grant Z Price, CPEHR
grantzprice@comcast.net
[…] « Previous article EMR Updates Next article […]
Grant Price,
You’re right that regression tests are absolutely important when doing an upgrade. However, even the best regression test wouldn’t have caught the problem described above. The problem described above isn’t that their was a bug in the software or that the software functioned different than what was part of the feature. It was users habits around the new feature which caused the problem. Something that you would not likely find out until it was in place.
Even once the problem started happening it was hard to figure out why exactly we were having that problem.
[…] think doing the above would solve a common phrase I’ve heard after doing an EMR software update: “Why did they add that feature?” followed by the question “Why don’t they […]