Best practices vs. recommendations: Who will win?

It seems as though every time I walk into a hospital and meet with the Health Information Management (HIM) department, decision makers always ask the same question: “Can you share best practices about workflows?

At first, this request seemed harmless. Sort of a “what are other hospitals doing to achieve success?” inquiry. There are times the best practice conversation is prompted before a new project begins, and the organization is busy preparing for how the future state will look. But, on the contrary, there are times this conversation is prompted due to a failure in the current process and there is a need to revamp.

Is it possible to replicate best practices in healthcare?

The idea of replicating what another hospital is doing to achieve success (as it relates to HIM) is a misunderstood concept. The variance across healthcare organizations is so broad, to replicate an established best practice from another organization would require the matching of very specific points such as healthcare organization size, patient population, mix of hospitals/surgery centers/physician offices, geographic spread, employee counts, and budgets (just to name a few). So, let’s rethink this. How can healthcare organizations take the investments they have already made in projects, such as implementing an electronic health record, and validate they are using the solution and process to the fullest potential? The answer is in recommendations, not best practices. The first thing to recognize is this: When your organization makes the decision to implement a new solution, it must understand that solution = software + process. Simple math, right? So many times, software is expected to just work, and that is not the case. Software is only half the equation. With every software implementation, there are people and processes surrounding the software that make it a success. Without them, the project will fail. It is painful to hear HIM departments tell me, “We use to scan in a different software, so we won’t need much training. The staff already knows how to scan.” An organization that is converting from a legacy solution to a new solution is in more jeopardy of failure due to the misnomer: “The process we previously used will work with the new solution.”

3 lessons from the battle

Working with healthcare organizations, I’ve learned three lessons when I’ve seen best practices go up against recommendations. Here they are.

Lesson 1: Software + process = Success.

Old processes will not work with new software. Take my word for it, don’t find out the hard way.

Most healthcare organizations think: Now that we have determined we need a new process to go along with our new software, how are we going to figure out the best process? I mean, if it’s new software that we have never used before, how are we expected to know what processes go along with it?

That may be the million-dollar question. Spending time working with the new software in a test environment along with accepting recommendations from the software vendor based on data collected is key.

Wait a minute! That was a lot of information in one sentence!

How many of you out there have implemented a new software solution and the first time the end users saw it was in training? That’s right. Not the executives who made the decision. Not even the managers who oversee the end users.

THE end users. You know, those people who will be using the software every minute they are working.

Yeah, maybe we should work with them on developing processes!

Trust me, they have “workarounds” that save time that you don’t even know about! Engaging them will result in processes that will work for your department. And the end users will feel more connected to the new solution, resulting in a better adoption rate.

Lesson 2: Engage the end users when developing new processes around the new software

Gosh, it seems as though I started this out with the goal of talking about best practices, and what I’ve done is give best practices on developing best practices. So let’s get back on track with recommendations. I love them. I love getting them. I love giving them. They are personal, tailored to the organization based on important things like goals (both strategic and tactical), software capabilities, budget, employees, and organizational structure.

What good is a best practice if it is not in line with the above? I am happy to copy the “scanning best practices” Word document from my C drive and email it to everyone, but it will not apply to 95 percent of you. My recommendation is to focus on recommendations (LOL).

Recommendations can be used as a bridge to achieve best practices (in some cases). In all cases, they are tailored to what your specific organization is working with and towards. The time I spend on recommendations for healthcare organizations yields success hand over fist.

Delivering a best practices document can lead to frustration due to the organization being so far away from achieving them, they feel the best practice is out of reach. Best practices are only achieved by a small percentage of organizations due to the sheer nature of what they are; best practices are pinnacles.

Recommendations, however, focus on what you can achieve and outline how to do so both technically and operationally.

Lesson 3: Recommendations focus on the specific goals and resources of an organization while a best practice is a set of standards across a broader scope.

At the beginning of this post, I stated that best practices are requested often, yet hard to achieve based on the variances across healthcare organizations. So I talked about my love for the concept of recommendations.

When a resource can help an organization lay out a recommended way to perform tasks that results in achieving desired goals, it’s like having a private trainer vs. going to the gym and following the pictures on the machines. When adopting new solutions (remember, solution = software + process), it is not the organization’s responsibility to know the recommended way.

It is, however, the organization’s responsibility to hold the software vendor’s feet to the fire and deliver a resource that will help them to develop recommendations. Because guess what? If not, the vendor and the customer will end up with solution failure. I guarantee neither the vendor nor the customer want this. An epic battle, if there ever was one.

But for me, recommendations win. Every time.