(reposted from this week’s healthsystemcio.com)
I have spent time over the past few weeks speaking with healthcare executives to get their perspective on ACOs, also known as Attorneys and Consultants Opportunities. For the most part, people are in general agreement when it comes to describing the function of an ACO.
So much for the good news. Where the process breaks down is when those same executives were asked to describe what approach is required to enable an ACO to work in a generic hospital.
While there are many people claiming to know the in’s and out’s of ACOs, we all know there is not a lot of expertise regarding how to implement an ACO. There are not a lot of people who have “Been there, done that, got the T-shirt.”
When faced with finding a solution to a problem which I have no way to solve, I find it helpful to redefine the problem into one which I do know how to solve. If I take this approach with ACOs, it helps me to redefine it for what it is—a big, ugly program—a BUP. The good news is that I know what works and what does not work when it comes to dealing with BUPs.
There are two ways to tackle a BUP. One way is to study your organization and figure out how to get the program to work within your hospital’s framework. The other way is to figure out what the program needs to deliver, and then determine what needs to happen to the framework to enable the program to work.
I liken the two approaches to fitting puzzle pieces together. Let us define Puzzle A as the hospital’s framework, and Puzzle B as the ACO program (not an IT program). Under the first approach, you remove pieces from Puzzle B until you get it to fit. The problem with this approach is that by the time you finally get it to fit Puzzle B, the ACO no longer resembles an ACO.
Using the other approach — figuring what pieces must be removed from Puzzle A in order for Puzzle B, the ACO, to remain whole — provides the best chance of creating a viable ACO. One may wish to argue against this approach by saying that to create the ACO requires dismantling part of the hospital’s framework.
Indeed it does, but maybe that is not as bad as it sounds.
Many EHRs were implemented in such a way as to dismantle a lot of their functionality in order to get the EHR to fit the hospital’s framework. This “lesser” EHR is now part of that disrupted framework and has made it even more disrupted.
Perhaps the time has come to think about reengineering the framework before sacrificing the functionality of yet another program.