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.

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.

When your ACO gives you lemons—make Lemonade

This weekend the temperature warmed enough to cause the neighborhood children to set up the season’s first lemonade stand.  One of the moms suggested the stand be set up in the corner of the cul-de-sac.  By definition, a cul-de-sac is roundish, as in no corners.  When I laughingly questioned the mom as to which corner of the round cul-de-sac she had in mind, she failed to see my humor.

Each of the children brought different supplies; lemons, paper cups, a table, a hand-painted sign, water, and pre-mixed lemonade.

By closing time they had collected twenty-one dollars and seventeen cents.  They met at our house to divide the spoils of their venture, a task that sounded easier than it was.  The corner cul-de-sac child felt the money should be divided equally.  As her only contribution to the venture had been a tablecloth, her suggestion was met with a robust debate.

I suggested they look at using some of the money to pay back those children according to what their supplies cost—according to the children the supplies did not cost them anything because they took them from their homes.

By now you have figured out where this ACO conversation is going.  Without knowing ones’ costs, how can one really allocate profits against those costs?  The children knew what they charged, and they knew what they made, but they knew nothing of their costs.  The same concept applies when viewing the problem of performing a hip replacement instead of simply selling lemonade.

Perhaps providers should start with opening a lemonade stand to get a better understanding of the business requirements, and then work their way up to the ACO model.

What is IT’s role in Accountable Care Organizations?

I published this article today in healthsystemcio.com (http://ow.ly/4ecmg), and thought you might find it interesting. Please feel free to comment.

 

 

 

When was the last time you looked at a hospital bill, or one sent directly from your physician? The reason I ask is I have been spending some time trying to develop a clear enough picture of Accountable Care Organizations (ACOs) to describe them easily. After all, ACOs are not something you can touch and see. You cannot just walk up to the third floor of Our Lady of Perpetual Billing and be shown an ACO.

 

I think it is extremely important to understand what an ACO is before trying to build one. Much of the difficulty in building an ACO has to do with the fact that something, in fact a great many somethings, will have to change for an ACO to function. The question then becomes, change from what to what?

Back to the hospital bill. Scan through the list of charges, and then press the F5 key to let me know when you are ready. Now, highlight all the line items that charge you for the care you received … I found the same thing; there are not any. Volume versus value. Caring for you versus doing stuff to you. The bill of charges under today’s business model is a blow-by-blow description of what was done to you; x-rays, medicines given, IVs, etc.

Hospital billing is not unlike a hotel bill; it is just longer and you do not earn frequent illness points. Embedded in your hospital bill are charges for food and cable television, just like you had been staying at the Four Seasons.

So, as we move from volume to value, how will that impact healthcare information technology, assuming anyone remains standing after Meaningful Use and ICD-10? I keep preaching about how the hospital’s business model must change in order to understand what will be required of IT. To do so, let us compare two very different business models and their operations, both of which are in the same industry.

Hyundai and Bentley. Volume to value. Just-in-time manufacturing versus don’t-rush-me manufacturing. Nobody would argue with the fact that the information systems and business processes needed to run Hyundai’s business are very different from those of Bentley.

I watched a show on how Bentleys are built. A team of people is assigned to each car. Depending on the car’s options, some people roll off the team and others are added, but the team “owns” the car from start to finish, and each subsequent person inspects the work of the prior person.

At Hyundai, it is not apparent that anyone “owns” the car. People have line responsibility; they own a piece of a process. I could be the “left lug nut guy,” having absolutely no responsibility for the rest of the car.

I think this is the degree of change an ACO will require in order to be effective. We will have to change from being lug nut specialists to becoming care owners. This then brings us back to the question of what IT systems will be needed to charge for and manage care.

Unlike moving from ICD-9 to ICD-10, there is no mapping model to guide the change from today’s business model to an ACO model. Three IVs and one MRI do not translate well to 4.5 Accountable Care Units (ACUs) which are then billed at whatever happens to be the going rate.

Today’s systems calculate charges based on what was done to you — $86 million gazillion for the MRI. If requested, nobody in finance or information technology will be able to vivisect the bowels of SAP or Lawson and show you where the information is that records how much the MRI procedure costs. Few can explain how the business processes and information systems that support today’s lug-nut charging model can support and report how the hospital manages its business. Nobody even pretends to explain how effective those same processes and systems are at reporting the quality of care delivered.

The ACO model will require processes and systems that capture, allocate, and report costs. The ACO model will also require processes and systems that can aggregate people and procedures into ACUs and relate patient costs against those ACUs.

We do not have those systems. Since current hospital systems are incapable of really managing today’s business requirements, we should not adapt them to the ACO model.

 

There is no ‘I’ in team, but there is in failure

As a guy, I am entitled to be a fan of badly made war movies if for no other reason than they are war movies and come with a built-in plot, which minimizes the need to think too much—which is why some are so fond of Meaningful Use, but lest I get ahead of myself.

One such film, A Bridge Too Far, starred everyone but Mel Brooks.  The movie depicts Operation Market Garden, the allied attempt to break through German lines and seize several bridges over the Lower Rhine in Arnhem in the occupied Netherlands.  The operation fails, with many of the allied soldiers killed or taken prisoner.

At the conclusion of the movie the British generals are assessing their performance in a formal manner only the British can pull off.  Ignoring the failures, the dead, and those captured by the Germans, the last lines are:

Lt. General Frederick “Boy” Browning: I’ve just been on to Monty. He’s very proud and pleased.
Major General Urquhart (played by Sean Connery): Pleased?
Lt. General Frederick “Boy” Browning: Of course. He thinks Market Garden was 90% successful.
Major General Urquhart: But what do you think?
Lt. General Frederick “Boy” Browning: Well, as you know, I always felt we tried to go a bridge too far.

For those who have not seen the movie, the allied failure resulted from having spread their resources too thinly, for trying to accomplish too much with too little with too little time.

A bridge too far.  A euphemism for biting off more than one should, for the idea not being amongst the best laid plans of mice and men, one having the intelligence of a bowl of mice.

EHR.  Meaningful Use. Accountable Care Organizations.  ICD-10.

Which of these is a hospital’s bridge too far?  Or, is it all of them.

 

CIO shift, happens–or shift happens

Another comment of mine to Barbara Quack’s post; http://ducknetweb.blogspot.com/2010/12/cio-confidence-in-meaningful-use-drops.html#comment-form

I think you hit the nail on the head.  I think a lot of this can be attributed to the fact that stuff rolls down hill and that shift happens.

In healthcare, as in every significant industry, part of the problem seems to come from the fact that CIOs are often considered to be part of the C-suite in name only.  There are several notable exceptions to this observation, CIOs who drive business strategy instead of merely implementing the business strategy that was developed in the “real” C-suite.  Many C-suiters perceive the real role of the CIO is to apply technology to accomplish what they (the C-suite) want done.

Many executives, CFOs, CMOs, COOs, and CEOs regard the position of CIO such that the “C” (chief) and “O” (officer) are honorariums; officers in name only, officers with commensurately sized offices located on the third floor or in an offsite location.  Responsibility often without authority.

I think the issue of Meaningful Use is a clear example of how the practice works.  I worked with a large group of hospitals whose CIO had a detailed IT strategy and plan—projects, ROIs, resources, and capital.  His plan was tied to the business plan which he helped author.

He did EHR and CPOE before EHR was de rigueur.  Then along came Meaningful Use.  Without any understanding of the business issues or consequences associated with meeting Meaningful Use, the C-er’s and the board decided that not meeting Meaningful Use was not up for discussion.  The analysis was thorough, but unimportant.

In a nutshell, the organization which had already implemented EHR and CPOE because of his thought leadership—and long before DC got into the EHR thought leadership business—was instructed to meet Meaningful Use, all else be damned.  The “all else” included whatever it was that eighty percent of his IT staff would have worked on during the next three years.

For the sake of a check, the IT strategy was sacrificed, and the IT strategy’s alignment to the business strategy was sacrificed.  Did they get the check?  Will they pass the Meaningful Use audit?  IT will be blamed if they fail to meet Meaningful Use.  They will be blamed when they fail to deliver all of the other parts of their original plan.  And, they will be blamed if the standards shift in mid-stream.  Why?  Shift happens.  Responsibility often without authority.

“Memo from the CFO: How’s that whole ICD-10 initiative coming?  Holler if I can do anything.”

And guess what’s coming around the corner?  The new hot topic to roll down hill will be the decision that comes out something like this; “Memo from the CEO: The board decided we need to be seen as an Accountable Care Organization by the end of 2012.  Holler if I can do anything.”

Information Technology—IT.  “That must be where we keep all the technology in case we need it.”  Just send out a request and one of those technology guys will put it in for us.

There is only one thing that will stop this train from making the office of the CIO the bucket into which the downhill water is running.  Lead.  Plan.  Instead of planning for what technology and IT resources you need to deliver to meet their orders, draft a healthcare strategy instead of an IT strategy.  Bring forth a business plan addressing business problems that uses technology as a solution to solve the problems.

Define what is needed, on top of what you already need, to meet ICD-10.

Define what is needed, on top of what you already need, to make ACOs viable.

If you wait to respond to their IT orders, it will be too late.