Curbside Consult with Dr. Jayne 3/26/18

I received quite a bit of feedback on last week’s piece that mentioned the concept of moral distress. Someone experiences moral distress when they know there is a “right” thing to do, but are blocked from pursuing it by institutional constraints. It was previously spoken of in clinical circles and can contribute to burnout. We’re seeing more and more people experiencing these symptoms even if they’re in support roles as opposed to being frontline clinicians.

One reader noted:

Spot on. Having been in the vendor side of the house for over 40 years, I’ve seen the challenges of performing daily duties grow exponentially, especially in the clinician environment. Volume over value is one direct contributor to this headache. As long as earnings per share remain king in the mind of the C-suite (indirectly, but this is how the folks on the carpet think if you ever have a meaningful discussion with any of them) and maintaining decent margins is the most important focus, the system will never be people-centric. Empowering mid-level leadership has been the nemesis of success for many, many years. We have a disease management system in that generates $3.7 trillion annually; makes this system the largest employer in the domestic US (outside of the US government); and is trying to transition to a true healthcare system. Until the right entities and people are brought to bear and focused upon, status quo will remain king.

With the push towards analytics and true disease management (capturing the most expensive patients and figuring out how to care for them in a way that is less expensive) we’re starting to see some movement, but not enough. Many primary care practices are caught in the chicken-or-egg situation where you have to have money to buy software and hire care coordinators to manage complex patients to get paid for care coordination. Even the “incentives” available as CMS payments don’t cover the overhead of actually performing the care coordination for many practices, and unless you’re involved in full risk contracting, you’re not likely to see that money returned to your practice as “savings.”

On the software front, I see many vendors pushing slick-looking analytics platforms, but they’re not able to deliver the education needed to help practices actually move the needle. It’s one thing to learn how to identify the patients and document on them, but it’s another thing entirely to learn how to interact with those patients and come up with creative strategies to work around their barriers to care. Most of the care coordinators I know are magicians, pulling from a bag of tricks to fight complex situations involving lack of financial resources, unemployment, neglect, depression, anxiety, abuse, trauma, food insecurity, and more. When the frontline team caring for these patients doesn’t have enough “tricks” in that bag, it really doesn’t matter whether you’re working from the shiniest application or from the much-maligned Excel spreadsheet to track your patients.

Still, people are working hard to try to minimize the problems that care teams face. A reader on the Informatics side of the house had this to say:

We implemented quarterly release cycles. We first defined what we considered support and maintenance (change a price on a fee schedule, update a med on an order set, add a new employee to a work queue, etc.) with specific turnaround times. This was ongoing work that was on a daily o rweekly basis. Everything else, including optimization enhancements and projects, were on a strict quarterly release cycle. Originally, we implemented this as a way to achieve economies of scale with our build, testing, training, updates to policies and procedures, etc. For example, prior to release cycles, we ran the same test script multiple times to test a variety of build items for different projects. With release cycles, we streamlined this so we only had to run the script once that would test the build for those same projects. We found that we gained a significant amount of capacity back to those same teams.

In an employee engagement survey conducted approximately nine months after the implementation of release cycles, we noticed an almost 40 percent improvement in scores related to stress, burnout, and anxiety. It was the best improvement across the entire survey. Because of the significant increase, HR conducted many follow-up surveys and focus groups to try to better understand the increase. One of the major contributing factors was the implementation of the release cycles. When asked why, people (nurses, physicians, IT, etc.) almost universally said that the predictability of the release cycles (we started a new cycle the first Monday of a calendar quarter and would go live on the last Tuesday of the quarter) allowed for better change management and to plan their schedules accordingly. Part of their stress levels was that people felt everything changing constantly on them from a day-to-day basis. The release cycles allowed them to better understand the changes to their workflows and adopt the new change before introducing additional changes. We never thought about release cycles in those terms, but it became a significant factor in its continuing success. In fact, when we had to deviate from our cycles for ICD-10 implementation due to external factors, it created significant pushback from operations. I just wanted to share my experience for a potential strategy that other organizations might find useful.

Well said, and solid concepts. I continue to see organizations (and vendors) who don’t have a well thought out release strategy. Or perhaps it’s well thought out but poorly executed. From an end user standpoint, I see the best adoption when break/fix is separated from enhancements and new features, even though that might mean a bit of overlap in training strategies. It’s tempting to say lump it all together, but that can mean users spending more time on broken platforms while trying to save a buck.

Employees are more resilient than we think as far as being able to compartmentalize different types of change. In my CMIO life, we rolled out “urgent fixes” such as new drugs or charge changes after hours on a relatively real-time basis, with notification to those who had logged the issues. The rest of our fixes were deployed monthly, with communication of the emergency items added to that communication so that we weren’t bombarding general users with all the “urgent” items. The monthly package was always deployed the same night as the physician IT advisory board meeting, so that we could re-communicate the changes (and because the analysts were already staying late, so we could save on the catering by feeding both crews at the same time).

Major upgrades to the application happened twice yearly and we opted to hold some workflow changes until those releases — even though they may have been patched earlier — in the event that we thought more intense training was needed for successful adoption. Those major releases included Web training, in-person training, and 1:1 training where needed, whereas the monthly patches were basically described in newsletter format.

It worked well for us and seemed logical, so I was surprised when I went out into the larger world and saw the mess that some groups make of application change management. One organization just threw patches on the system every Thursday night, regardless of whether the patches addressed issues of record. There was no communication to end users. Another communicated every little thing, whether it was relevant or not, causing the users to miss important issues.

Of course, if you’re on a vendor-hosted platform, you might not have the choice to identify how and when you’ll be updated and upgraded. In my clinical world, I often come in to some surprises regardless of how well the team has tried to communicate them. Usually they’re small, though, and our clinicians are adaptable, so not having that level of control isn’t as major of an issue as one might think. Of course I might feel differently if this was software for the operating room, the ICU, or another high-stakes environment, but for urgent care, it works.

I always appreciate hearing from readers, especially when there is concrete advice involved. How is your organization working to reduce burnout? Leave a comment or email me.

Email Dr. Jayne.