Lucy, the Chocolate Factory, and Governance

There’s a famous scene from the hit show, “I Love Lucy,” where Lucy and Ethel are on an assembly line wrapping chocolates. At first the chocolates come through the line slowly; then, the foreman decides to speed it up. Soon we see Lucy eating the chocolate, stuffing it into pockets; anything to get rid of the ones she can’t wrap quickly. Can you relate to this? I know I certainly can.

At OhioHealth, we went live with Epic at seven of our hospitals and ambulatory practices over the course of one year, including a “big bang” go-live that included bringing up labs as well. During the go-lives, anyone and everyone was able to place requests for optimization that were tabled for post-implementation work. Guess what happened? Yes, Lucy and the chocolate factory. Anyone and everyone did indeed submit them — as a result, we were faced with prioritizing 1,800 requests.

For the provider vertical, I began sorting out the requests by application, then specialty, and created ticket trackers for each. After sorting them out, we were left with 800 provider requests. Our Physician Envoys became the leadership for our providers in the governance structure, approving or denying the requests by committee. It’s three years later, and we are still working through the pile.

Eight hundred requests from providers alone is a lot. The requests ranged from, “I want the banner to be purple,” to “Can you auto check my ibuprofen?” In order to hopefully prevent the same pain for any of you, I’m going to share some of our lessons learned.

1. Wait until the go lives are over to open it up to optimization requests. As we went through the go-lives and end users learned more and more about the system, requests for optimization were resolved through practice. For example, the provider with the ibuprofen request learned that he could personalize his set to auto-check it. But, because it was an optimization request, we needed to review the request, check out the ability in the system and then determine it was an educational need. We then dispatched one of our elbow support associates to assist with personalization. Another thing we did is conduct blitz sessions for similarly themed requests. When several requests came in to optimize the patient banner, a blitz session was created to address all of those requests. And in case you’re curious, we didn’t make the banner purple.
2. Learn to say no early on in the process. We are currently looking at changing our intake and prioritization process to ensure we are focusing on high-value items. Requests that deviate from foundation, are not based on enterprise goals, or serve only one provider or group are more than likely rejected. Because we adopted an informal policy early on that anyone can submit anything with the assumption it would be built, we are now faced with changing culture in addition to introducing a new intake and prioritization process. That’s a lot of change management.
3. The build should be approved by those affected by it. One positive lesson that we learned early on is to ensure the proper stakeholders are reviewing the request. If Pharmacy entered a request to create an alert that would fire for providers, it was the providers that determined if that request would be completed. If providers requested something that would have downstream effects on nursing, it was nursing that would approve the change. We definitely had to mature this concept as we went through the process, but found that this one governance decision saved a lot of rework and workflow issues long term.

I’m sure we’ll continue to learn as we develop our new model, and I’ll share those lessons as well. For now though, back to the assembly line — those chocolates are not going to eat themselves.

Katie Foster is System Director of Provider Informatics for Ohio Health, where she has held various roles since 2012. Previously, she worked as an ER Nurse for Nationwide Children’s Hospital and Licking Memorial Health Systems.