I had an old physician colleague whose favorite hobby was bitching about EHRs, and one day told a story about…
Curbside Consult with Dr. Jayne 6/24/19
I wrote last month about my experience with a dysfunctional registration process for imaging at Big Medical Center. I was sharing the story recently with a colleague who uses Epic at another institution and was gratified to learn that they have a much more seamless process. My Epic Jedi set up a demo for me, showing me all the bells and whistles on the system at his early adopter facility.
Like other vendors, Epic is working hard to get its clients up on the latest and greatest code. It’s certainly easier for support to have fewer versions live in the field. Several vendors are also starting to ship their upgrades with new functionality enabled, under the premise that clients won’t bother to turn the features off. Compared to what I saw with my Jedi, it sounds like Big Medical Center is either on an older version of Epic that doesn’t have some of the nice features for online check-in or has somehow failed to enable them.
My colleague and I discussed our shared belief that patients take more time when completing pre-visit activities at home. This might be because they can look up information they don’t know for sure, or call a family member, or because they’re not flustered because there is a clipboard standing in the way between them and their doctor.
We also talked about the release of results. My study results came by mail in 10 days, which was the same interval for their appearance on the patient portal. The results had been signed off by the physician within 24 hours of the study, so I’m not sure why the organization chooses to embargo them for another week when it’s a test that patients are allowed to have without a physician order. The old attitudes about protecting patients from their own results need to go by the wayside. He did show me some nice functionality for trending of patient-generated data that might be encouraging for physicians who are worried about incorporating that data into the chart.
The majority of my urgent care patients seem to be using MyChart, so we talked about some available features where patients can email their continuity of care documents to other providers via Direct. It seemed like it would be more nearly seamless than the “break the glass” functionality offered by Share Everywhere, with the added benefit of being able to actually consume and utilize the data not just view it.
We also talked about Epic’s Happy Together functionality that allows patients to see aggregated data across multiple instances of the system. For patients in my area where there are multiple competing health systems, it should be useful. It was a great conversation and gave me some ideas to help patients better manage their data when I see them in the urgent care.
Patients are embracing technology and are using apps during the office visit, whether it’s to look up a medication at the pharmacy or to show me lab results. According to recent data, more than half of all physicians are offering patients mobile apps for processes like appointment scheduling or retrieval of lab results. I know I would much rather interact with my providers’ offices through my phone or a laptop rather than have to call them and get stuck in the land of voicemail.
That assumes that the practice has an efficient online process as well, unlike the five days it took my ophthalmologist to respond to my appointment request through the patient portal. I can’t fault them too much, though. Just having an online appointment request is light years ahead of what some practices are offering or what they decide to “allow” patients to use. Plenty of clients decide not to embrace new features, which is why vendors are now in the position of having to “force” clients to use new features. I’m sure they’re tired of getting a black eye from patients and users when the real fault is in the client’s decision-making layer.
Vendors are getting better at serving up smaller, more frequent upgrades and updates that don’t overwhelm users or bring down the system for days at a time (with a few notable exceptions). This seems to make client leaders more comfortable with the process. In theory, as long as quality remains stable and the new features deliver what they promised, clients will be more willing to apply and use new code.
On the other hand, if an upgrade package is a dud (or worse, if it breaks any existing workflows) the vendor will have to work hard to regain its credibility. I’ve been on the losing end of a bad upgrade before and it wasn’t pretty, although it did lead to lifelong friendships made with the developers who spent weeks onsite keeping us in business. Without those relationships, it’s sometimes hard for customers to trust their vendors, which might be one reason that clients don’t like to enable new functionality that they don’t consider critical. Another issue is the fact that organizations are trying to deliver many initiatives at the same time, and when push comes to shove, something just has to be cut from the implementation and training schedule.
Hopefully over time vendors and their clients will be able to perfect that balance between delivering frequent releases of high quality while avoiding upgrade fatigue. We’re in a relative lull from a regulatory requirement standpoint, so it’s certainly a good time to catch up on new releases.
As a physician in a practice that seems a bit laggard, I have to confess I’m often jealous of early adopter sites that are embracing the bells and whistles. My organization is focused on expansion of new sites and growth of practice volumes, so it’s not surprising that they don’t want to spend a lot of time on technology projects. We’re also onboarding dozens of new staffers and a handful of new providers, so at the moment, stability seems to be the watchword.
How often does your organization take upgrades? Do you find them frictionless or irritating? Leave a comment or email me.
Email Dr. Jayne.
Many of our newer contracts for software require that we stay relatively current with upgrades, such as the being no more than one full release behind the current production release. These ‘N-1’ provisions seem to be good for our business and also for the vendor. The vendor doesn’t have to provide backward compatibility for five releases in use so they can put more effort into current fixes and future enhancements. They also work harder on the testing of new releases because if they don’t, half of their clients are going to be really mad because they’re taking that version. N-1 contracts also set an expectation internally with our departments. We tell them they’re getting on a treadmill and they don’t get to jump off without paying a hefty software maintenance premium for supplemental support. Upgrading also puts downward pressure on customization and shifts the emphasis to configuration, which is where it should be. Most every organization where I’ve worked believed that they were so special that they needed customization (or even custom software). They have been wrong in every case. What they needed to do was to pick a solid product and then really learn how to use it to best effect.
Keep up the good work, Dr. J. How you keep your BP within normal range with all the knucklehead clients you have, I can’t imagine.
As a customer, we had contractual requirements to stay at Current or Current-1 versions, 20+ years ago.
IIRC, you could still run on even older versions but there was a maintenance fee premium to pay then. I’ve always thought this type of agreement struck a fair balance. It allows customers to keep the doors open and lights on even under difficult conditions. Meanwhile it creates a clear incentive to stay current and shows that the vendor places significant value on doing so.