Hospital Executives: Can you answer these questions?

Been there, done that, got the T-shirt.  Every hospital executive who thinks they have their arms around EHR and healthcare reform, take one step forward……whoa, where are you going Sparky?

The questions below resulted from a round-table discussion I recently had  with six healthcare executives about EHR and healthcare reform. The topic we discussed was what questions should C-Level executives be prepared to answer and what questions should boards be asking. What do you think? Are their others you’d add?

Are we taking adequate advantage of stimulus funding to improve our readiness?

How is health care reform going to impact our business and when?

Are we doing enough to be ready to succeed in an environment where we get paid for outcomes rather than inputs?

Are we ready to comply with Federal policies for Electronic Health Record reporting and sharing?

Are we achieving our own business improvement standards? Do we have the right standards?

Are we ready to use web 2.0 technologies to improve clinical outcomes for our clients?

The Patient as Customer

The headline for a recently published McKinsey survey stated “Ninety percent of hospital CEOs ranked Patient Experience Management (PEM) as their first or second priority over the next three years.

Buried deep within the article was a throw away statement that little will be done regarding PEM because nobody knows who owns the patient.

Any journalism student worth their salt would tell you the real headline for the survey should read something like “Ninety percent of hospital CEOs and COOs do not know who owns the patient at their hospital.”

From a business perspective, in the conversation about patients and PEM one thing is always overlooked.  These people, the patients, also have a business avatar.  They are also customers.  PEM from a business perspective focuses on all the non-clinical aspects of the patients as a customer.

There are dozens of non-clinical processes that affect each customer (patient)—admissions, discharge, billing, scheduling, disputes, claims…

Many of these processes are ineffective and inefficient.  Many are redundant and duplicative.  Many add more cost than value.

If you want to improve the patient experience, look first at these.  You will be surprised by how much better your organization will be perceived.

Why is the large provider business model obsolescing?

Margaret Thatcher said, “Anyone who finds themselves on public transport after the age of 26 must consider themselves a failure.” There’s probably some sort of corollary for anyone twice that age that spends part of every day writing to imaginary people on the web.

When I write I like to pick a side and stand by it instead of standing in the middle of the road where you can get run over by the traffic from both sides. Likewise, I don’t look for consensus around an idea. Consensus is the process of everyone abandoning their beliefs and principles and meeting in the middle. When was it decided that meeting in the middle is beneficial? So, achieving consensus about a problem is nothing more than that state of lukewarm affection one feels when one neither believes in nor objects to a proposition.

Having this approach to solving business problems tends to yield a high number of critics. I don’t mind critics; those are the same people who after seeing me walk across a swimming pool would say that my walking only proves that I can’t swim. I rather enjoy it when someone offers a decidedly personal attack on something I wrote if only because it means they can’t find a legitimate business principle on which to base their argument. I love the debate, and I don’t expect anyone to agree with me just because I say it is so.

In trying to promote a different way of looking at the large provider business model, I’ve learned that it’s not possible to lead from within the crowd. The “as-is” hospital business model (how the hospital is run) was created over time, by followers. I may be wrong, but the most innovative alteration I have seen to the hospital business model in the last decade has been the addition of mini Starbucks, and the revamping of their lobbies to make hospitals look more like hotels.  The future will be created by someone who believes the strategy of how hospitals run can be done better. I believe firmly in the notion that improving the business model by building off the current one is like trying to cure a cold with leeches.

The approach that has been used to grow the business for the last fifty years is that the hospital is responsible for everything. And yet, who is responsible for the hospital? Who is accountable for the fact that the business model is obsolescing itself?  We have loads of new stuff—expensive stuff.  No other industry can tout new and improved services better than healthcare.  However, in those industries new and improved means faster, smaller, cheaper–it means adding services to reach significantly more customers, not fewer.

Each new and improved procedure with its more costly overhead has application to a smaller percentage of the health population, thereby allocating that overhead across fewer patients.  In turn, that makes the low-margin services unprofitable.  Those services will be cut lose, picked up by new entrants with lower overhead.  Those entrants will make a good business out of services discarded by hospitals.  The cycle will repeat, as it has for decades.  The profitable new entrants will move up-market.

Is it a question of scale versus scope, or scale and scope?  What happens if instead of continuing to repeat the cycle, large healthcare providers were to invert it?  What makes them more relevant, adding the capability to perform a procedure used once a month or one used once an hour?  Which is more important to the future model, inpatient care or outpatient care?  I suggest that “in” or “out” will become irrelevant.

Those phone booths in the photo used to be the way to make public calls, now you can’t even find a booth.  Maybe some day someone will take a photo of a group of hospitals stacked next to each other in a vacant lot.

When Patients Rule: Crowdsourcing & S-CRM

The one application of crowdsourcing that is most overlooked is one which hardly fits the definition. This type is not premeditated. It is the type where the “machine” is a means to an end, and it does not originate at the organization. In fact, the organization is the target of this type of crowdsourcing—Social-CRM.

Most definitions of crowdsourcing include the notion of a call going out to a group of individuals who are then gathered via the call to solve a complex problem, acting like a shared problem solving methodology, much like the theory of Law of Large Numbers.

The crowd is likely to have an upper limit in terms of the number of members. By default, traditional crowdsourcing is fashioned to work from the top down; it is outbound, a push model.

Social-CRM (S-CRM) tends to work from the bottom up. There are no boundaries to the number of members; in fact, there can be thousands of members. Also atypical is the fact with S-CRM no single event or call to action drives the formation of the crowd. The crowd can have as many events as it has members.

The unifying force around S-CRM is each member’s perspective of a given firm or organization. Members are often knitted together by having felt wronged or put-off by an action, product, or service provided or not provided by said organization. Most organizations do not listen to, nor do they have a means by which they can communicate with the S-CRM crowdsource. This in turn causes the membership to grow, and to become even more steadfast in the individual missions of their members.

In traditional crowdsourcing, once the problem solving ends, the crowd no longer has a reason to exist, and it disbands. With S-CRM crowdsourcing, since the problem never seems to go away, neither does the crowd.

Every firm has one or more S-CRM groups biting at its ankles, hurting its image, hurting the brand, causing customers to flee, and disrupting the business model. Even so, most organizations ignore the S-CRM crowd just like someone ignores their crazy Uncle Pete who disrupts every family gathering.

Healthcare IT: A premonition

As I walked through the offices of one of my clients last week I kept passing errant lines of code that had fallen to the floor throughout the hospital.  Each time I passed one I retrieved it and dropped it in a folder.  Eating lunch in the cafeteria, I laid the lines of code in front of me on the café table—HIE, EHR, Meaningful Use, HIPAA, and one bit of code on Accountable Care Organizations—not sure how that one got in there; probably written by a healthcare futurist with a pet unicorn.

I was reminded of the time a purchased an unassembled gas grill—why pay an extra hundred dollars to have someone connect Part A to Part B?  As I learned, the reason to pay the hundred dollars is so that at the end of the process you are not left with parts K and Q and no idea where they go.  The grill started just fine.  Apparently, parts K and Q had a lot do with turning off the grill—the lid melted seven years ago, and the grill has served as our home’s eternal flame ever since.

I dare say there are many organizations whose systems are missing important lines of code.  Maybe that is why more than half of the large providers will soon discover their EHR functions more like a multi-million dollar scanner than an EHR.

A major problem for healthcare information technology (HIT) is the disruption it has brought upon itself.  If we are honest about HIT, it was not working all that well before we started disrupting it.  EHR was not a natural fit on the prior architecture.  To make EHR fit required that bits of the old be cut away and new applications had to be hammered and welded into place.  Many chasing Meaningful Use have to take short cuts to meet it.  Getting something to fit is not the same as getting something to function.

Once the EHR is in place, out come the hammers to get EHR to meet Meaningful Use.  The code and interfaces are chiseled away, and functionality is sacrificed.  Now leaders are trying to figure out what must be sacrificed to get ACOs hammered into place.

The old architecture was never architected to support an EHR or an ACO.  That means that many, many hospitals are a few months or one or two years away from having to rethink their EHR strategy.  The short cuts and dropped lines of code will have degraded the EHR’s performance to such an extent that it will have to be replaced.

The next trend in HIT will not be ACOs.  Instead it will be large teams of outside consultants swarming like locusts to provide disaster recovery on hundred million dollar EHRs.

Hospital Business Strategy–One size fits none

One size fits none, or is it one.  The patient rarely buys what the hospital is selling.  The hospital sells a hip replacement—the patient is buying the ability to play golf for ten more years.

Clayton Christensen conducted a study which showed that seventy percent of today’s patients would have been in the ICU thirty years ago, and seventy percent of the patients in today’s ICUs would have died thirty years ago.  The question the study seemed to leave unaddressed is who is now caring for those patients who were not in the ICU and who didn’t die.  Wanna’ bet most have been outsourced to non-hospital care givers?

There was a successful business model in that group of patients when they were treated at the hospital thirty years ago.  There is an even larger business model today for that same set of patients; only it is no longer owned by the hospital.  Neither are the associated revenues.

Hospitals have more high-end capability—and cost—than the average patient will utilize—sort of an 80/20 rule on steroids.  Each successive clinical breakthrough enables the hospital to solve a problem for a mere handful of patients; one that will have no application to 99% of patients in their service area.

What if instead of continuing to expand the reach for the stars model ad nauseam, the hospital flipped the model on its side and catered to the ninety-nine percent?  What if the business model centered on serving mainstream customers?  But then who or what would handle the other one percent of the cases?  An autonomous business unit could be established to serve those cases, or they could be outsourced to a group which did.

EHR–the five stages of grief

Being a blogger is not too dissimilar to being a failure’s biographer.  Unless you simply repeat the ideas of your contemporaries, good blogging requires a certain avidity to oppugn those who revel in the notion that theirs was the only good idea.  To me, their Sang-froid calmness has all the appeal of a cold omelet.  Good writing requires that you make intellectual enemies across a range of subjects, and that you have the tenacity to hold on to those enemies.  So let us step off Chekhov’s veranda and bid farewell to the sisters of Prozorova.

The Kübler-Ross model, commonly known as the five stages of grief, was first introduced by Elisabeth Kübler-Ross in her 1969 book, On Death and Dying.  I heard a story about this on NPR, and it made me think about other scenarios where these stages might apply.

My first powered form of transport was a green Suzuki 250cc motorcycle.  My girlfriend knitted me a green scarf to match the bike.  One afternoon my mother walked into the family room, saw me, and burst into tears.  When I asked her what was wrong, she told me that one her way home she saw a green motorcycle lying on the road surrounded by police cars and an ambulance—she thought I had crashed.  I asked her why, if she thought that was me lying on the road, she did not stop.

My girlfriend’s mother, didn’t like my motorcycle—nor did she like me.  Hence, my first car; a 1969 Corvair.  Three hundred and fifty dollars.  Bench seats, AM radio.  Maroon—ish.  It reminded me a lot of Fred Flintstone’s car in that in several places one could view the street through the floor.  Twenty miles per gallon of gas, fifty miles per quart of oil.

Buyer’s remorse.  We’ve all had it.  There is a lot of buyer’s remorse going around with EHR, a lot of the five stages of grief.  I see it something like this:

  • Denial—the inability to grasp that you spent a hundred million dollars or more on EHR the wrong EHR, one that will never meet your needs
  • Anger—the EHR sales person received a six-figure bonus, and you got a commemorative coffee mug.  The vendor’s VP of Ruin MY life, took you off his speed dial, unfriended you in Facebook, and has blocked your Tweets. You phone calls to the vendor executive go unanswered, and are returned by a junior sales rep who thinks the issue may be that you need to purchase additional training.
  • Bargaining—when you have to answer to your boss, likely the same person who told you which system to purchase, as to why productivity is below what it was when the physicians charted in crayon.
  • Depression—you come in at least fifteen minutes late, and use the side door, taking the stairs so you won’t see anyone.  You just stare at your desk; but it looks like you are working. You do that for probably another hour after lunch, too. You estimate that in a given week you probably only do about fifteen minutes of real, actual, work. (Borrowed from the movie, Office Space.)
  • Acceptance—the EHR does not work, it will never work, you won’t be around to see it if it ever does.  Your hospital won’t see a nickel of the ARRA money.  You realize the lake house you were building will never be yours, but the mortgage will be.

The five stages of EHR grief.  Where are you in the grieving process?

True, there are a handful of EHR successes.  Not nearly as many as the vendors would have you believe.  More than half of hospital EHR implementations are considered to have failed.

If you are just starting the process, or are knee-deep in vendor apathy you have two options.  You can bring in the A-team, people who know how to run big ugly projects, or you prepare to grieve.

If it was me, I’d be checking Facebook to see if I was still on my vendor’s list of friends.

Should you meet Meaningful Use-a PowerPoint

Here is the presentation on whether one should meet Meaningful Use I am giving in May at New England’s HFMA conference. Please let me know what you think.  http://ow.ly/4Joet

“Our Lady of Perpetual Implementations”

“There is no use trying,” said Alice;
“one can’t believe impossible things.”
“I dare say you haven’t had much practice,” said the Queen.
“When I was your age, I always did it for half an hour a day.
Why, sometimes I’ve believed as many as
six impossible things before breakfast.”

There are a number of people who would have you believe impossible things.  I dare say some already have.  Such as?

“My EHR is certifiable.”

“They told me it will pass meaningful use.”

“We’re not responsible for Interoperability; that happens at the Rhio.”

“It doesn’t matter what comes out of the reform effort, this EHR will handle it.”

“We don’t have to worry about our workflow, this system has its own.”

Sometimes it’s best not to follow the crowd—scores of like-thinking individuals following the EHR direction they’ve been given by vendors and Washington.  Why did you select that package—because somebody at The Hospital of Perpetual Implementations did?

There is merit in asking, is your organization guilty of drinking the Kool Aid?  Please don’t mistake my purpose in writing.  There are many benefits available to those who implement an EHR.  My point is is that there will be many more benefits to those who select the right system, to those who know what business problems they expect to address, to those who eliminate redundant business functions, and those who implement proper change management controls.

Fitting Your Square Hospital into a Round ACO Hole

(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.