Do you believe Meaningful Use is best for you?

The area was cordoned off with yellow crime scene tape. Crime scene investigators searched the trampled grass, careful so as not to disturb the evidence. People and horses craned their necks to watch. The lead investigator knelt and retrieved a small piece of shell with a pair of tweezers. It looked like the dozens of other pieces they had already collected. The yolk was congealing at the base of the wall.

On the other side of the wall, a rookie patrolman noticed shoe imprints in the wet earth.
“Humpty-Dumpty was pushed,” he yelled to the lead investigator.

Humpty-Dumpty didn’t fall. Even long held beliefs can prove false. Not everything is the way it seems. Just because you believe something is true doesn’t make it so. Ask the Flat Earth Society; ask the people think the moon landing was faked. Sometimes it just requires a little more thought.

Sometimes you need to be the needle in the haystack. There’s not much value in being the hay.

Just because everyone believes chasing Meaningful Use is the right thing to do doesn’t make it so.  This is not a cause and effect relationship. The belief seems to be that meeting the standards set by the CMS is the best metric for determining the value of your EHR.  Wrong. They are only the best metric for determining if you will be receiving incentive money.

Believing something doesn’t make it true. Ask the person who pushed Humpty-Dumpty.

Project Management lessons from Alice and Wonderland

During my career I’ve been involved with hundreds of project teams, some quite gifted, others whose collective intellect was rivaled only by simple garden tools.  I’ve been asked often if I can define what distinguishes the two types of teams.  For me it always comes down to leadership.  It doesn’t matter how hard the people work, it matters how well they are lead.  Does the leader know what to do tomorrow?

That got me to thinking.  Are there some leadership secrets, some project management gems that may have been overlooked?  Rather than offering traditional mish-mash consulting jargon, I thought it would be helpful to find a common ground by which we can form a basis for this discussion.  Hence the following narrative: Everything I learned about project management I learned from Alice in Wonderland.

So, you have spent tens of millions on an electronic health records system.  Some did so without even defining their requirements.  The project is chugging along, new regulations and penalties are appearing through the diaphanous mist like the Cheshire Cat’s toothy grin.

“Well! I’ve often seen a cat without a grin,” thought Alice.  “But a grin without a cat! It’s the most curious thing I ever saw in my life!”


How fast must you run so as not to lose ground?  How many milestones do you have to meet, how many due dates do you have to check?  What can be learned from the Red Queen in Alice in Wonderland?  She told Alice, “It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast.”




For the EHR project to progress it requires extraordinary effort.  This begs a question of the project leader, where does the project need to go?  In a conversation with the Cheshire Cat Alice asks,

Would you tell me, please which way I ought to go from here?” “That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where,” she said.
“Then, it doesn’t matter which way you go.” “So long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

If you only walk long enough.  What is enough for a three year project?  When are you done?  When the money runs out; when there are no more tasks in the work plan.  It seems many EHR projects are much bigger than allowed for by the plan.  They get big, impossibly big.  A lot of that size comes from underestimating the effort to support workflow improvement, change management, and user acceptance.

“Sorry, you’re much too big.  Simply impassible,” said the Doorknob to Alice.   “You mean impossible?” “No, impassible.  Nothing’s impossible.”

We don’t have the benefit of getting advice from talking doorknobs which is why we get so stymied when confronted with having to do the impossible. What is impassible or impossible for your project?  It might be deciding or knowing when to stop.

Alice laughed. “There’s no use trying,” she said: “one can’t believe impossible things.”
“I daresay 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.”

Believing it does not make it so.  Never has, never will.  Belief does not beget success.  Planning does.  Defining your requirements may.  There is no shortage of ex-CIOs who believed their EHR vendor.

Then there’s the skill of managing your EHR vendor.  Perhaps Eaglet said it best, “Speak English! I don’t know the meaning of half those long words, and I don’t believe you do either!”

There will always be those select members of every project team who are so dense that light bends around them; those who have not learned that it is better to keep their mouth shut and appear unintelligent than to open it and remove any doubt; those who have the right to remain silent, who just don’t have the ability.

“You couldn’t deny that, even if you tried with both hands.”

“I don’t deny things with my hands,” Alice objected.

“Nobody said you did,” said the Red Queen. “I said you couldn’t if you tried.”

Do you find yourself sitting through a status meeting unable to tell if the project is moving backwards or forwards, unable to tell what is hiding around the bend?  You think so hard your head feels like your ears are trying to switch places with your eyes.  When all else fails, try this bit if advice.

“Fan her head!” the Red Queen anxiously interrupted. “She’ll be feverish after so much thinking.”  A little thinking won’t hurt, who knows; in small doses it might even be beneficial.

Now, let’s assume you’ve got yourself all worked up.  You and your team are pouring over your work plan, trying to decide what’s left to accomplish, or what can’t be accomplished.  How do you know what’s what and which is which?

“Begin at the beginning,” the King said, very gravely.  “And go on till you come to the end: then stop.”

I’ll take the King’s advice and do the same.

Jihad Joe EHR selection

When competing hypotheses are equal in other respects, the principle recommends selection of the hypothesis that introduces the fewest assumptions and postulates the fewest entities while still sufficiently answering the question. It is in this sense that Occam’s razor is usually understood.  There is no corollary that works with EHR vendors.

What if we look at HIT vendor selection logically?  Have you ever noticed at the grocery store how often you find yourself in the longest checkout line, or when you’re on the highway how often you find yourself in the slowest lane?  Why is that?  Because those are the lines and lanes with the most people, which is why they move the slowest.

If you are asked in which line is Mr. Jones, you would not be able to know for certain, but you would know that the most probable option is the one with the most people in it.  You are not being delusional when you think you are in the slowest lane, you probably are, you and all the people in front of you.  The explanation uses simple logic.  It’s called the anthropic principle– observations of our physical universe must be compatible with the life observed in it.

It can be argued that the business driver which shapes the software selection process of some is the aesthetics of efficiency, a Jihad Joe approach to expediency.  Buy the same system the hospital down the street bought, the one recommended by your golfing buddy, or the one that had the largest booth at the convention.  Or, one can apply the anthropic principle, rely on the reliability of large numbers and simply follow the market leader.

Might work, might not.  My money is on might not.  There’s still plenty of time to do it right.  If that fails, there will always be time to do it wrong later.  Of course, you can always play vendor darts.  If you do, you should sharpen them so they’ll stick better.

What should you think about HIEs

Part of the problem I have with HIEs is similar to the old Wendy’s commercial, “Where’s the beef.” Only in this case the question becomes, “Where’s the value add?”

There are hundreds of them, HIEs that is. Each one developed autonomously. Some are built within a hospital which has more than one EHR. Others are being built to serve among a hospital group, and others are geographical. Which of the HIEs is being built by a team of people who have ever built one? To my knowledge, none.

Hundreds of HIEs being built independently from one another by people who’ve never before built an HIE. Hundreds being built to transport the electronic medical records of providers using a few hundred different EHRs, each EHR operating with different standards, none of which benefits from interacting with another.

What is the purpose of the HIE? It reminds me of this children’s’ icebreaker game where the children sit in a circle. The first child starts by whispering a phrase into the ear of the person sitting next to her. She can only say the phrase once. The child she whispers it to must then whisper it to the child next to her. This continues until it goes all the way around the circle. Usually, by the time the phrase gets back around to the original person, it is completely different.

Like shuffling an EMR from one place to the next through a series of intermediaries. What does it look like when it comes out the back end?

After all, what is the purpose of the HIE? It should act like a handoff, like a mini N-HIN. It does not modify the data, at least not intentionally. If there is a more complex way to get a person’s health record from point A to point B, I have not seen it. HIEs are healthcare’s Rube Goldberg mechanism.

I think that when all is said and done, HIEs will have faded away. Until then providers should keep their focus on developing an EHR which actually serves their business model.

How hospitals should deploy EHR to attract Docs

This is a response I wrote to Brian Ahier’s post on HealthsystemCIO.com

Here’s an idea I raised a few months ago which discusses how to use EHR to your advantage in retaining ambulatory physicians. What prompted the idea was knowing of a hospital which spent nine figures on their EHR, only to find out that its functionality essentially ended inside its four walls. At the time nobody wrote that it wouldn’t pass muster. This idea may die before anyone finishes reading the comment; if not perhaps it merits at least a look-see.

From the perspective of the business model of the hospital, what do we know?

• Hospitals work at attracting and retaining good physicians
• In many markets, ambulatory physicians may choose to send their patients to any one of a number of hospitals
• The competition to attract patients and physicians is building
• The hospital and physicians both benefit if they are:

o On the same EHR
o On an EHR which interfaces easily

What if we change the question being asked, or at least change what constitutes a desirable answer from the perspective of the hospital? Let us go back to what we know.

• Non-hospital based doctors will not be part of the calculation to determine if the hospital meets Meaningful Use.
• Each of those doctors benefit from implementing and EHR system, and they will either qualify for stimulus money or be fined.
• Those same doctors and their patients benefit from having a seamless relationship with a hospital.
• None of those doctors has anything close to what can be considered an actual IT department.

o If 400 providers who practice at your hospital have to select an EHR, how many dozens of different EHRs will they select
o Not only do the providers lack the skills to select a good system, they lack the skills to implement it successfully.
o Most IPAs are not even offering a recommendation

What happens if we rephrase the question and ask, “What steps can a hospital take to:”

• Make ambulatory doctors want to send their patients to them
• Make it easy for the patient/physician/hospital relationship to appear seamless
• Possibly be paid for facilitating the EHR for their ambulatory physicians

If it were my hospital, here’s what I would do:

• Pull together a plan to figure out how a hospital could offer an EHR solution for each of the ambulatory doctors. This EHR solution could:

o Be the same EHR or one which can integrate with their EHR
o Be offered as a managed services solution
o Be offered as an outsourced solution

• Figure out what information is needed to determine the viability of offering its ambulatory doctors an EHR solution:

o Staffing
o Marketing
o Incentives
o Cost
o Roll-out
o Training

• Determine if the ambulatory doctors can somehow sign-over their incentive payments to the hospital.

o If yes, the incentive payment from 400 ambulatory doctors could fund about $18 million of the roll-out cost
o If not, there are still a number of great business reasons to think about helping the doctors get on the hospital’s EHR.

What is the long-term ROI, say five years and beyond, of having an ambulatory doctor send its patients to a given hospital? I bet it exceeds the cost of installing an ambulatory EHR.

May I have receipt for my EHR in case I return it?

The hospital we use just dedicated a new wing.  For months the job site was a maze of people, duct, and tools.  It cost $145 million.  There’s a plaque displaying the name of the architect, the contractor, the mayor, and the rest of the adults who made it happen.  While it was being built there were numerous permits, certifications, and sign-offs taped to the building.  Their purpose was to ensure the public that the adults were keeping an eye on things.  A phase of work couldn’t be started until the prior phase had all the requisite sign-offs.

Those in authority had to be licensed.  Had to be certified as qualified.

They have another project underway.  One that costs more than the new wing and impacts more people.  This one doesn’t have a blueprint.  There are no building permits.  No certifications.  No licensed professionals.  You can’t even see it.  There are no hard-hatted workers.  No foreman.  You know who’s in charge of the project?  A hospital executive—prior experience—zero.  Has he ever built one before?  No.  Does he know what to do when he encounters risks, pitfalls?  No.  There is one other person running the show—a vendor—that should let everyone get a good night’s sleep.

Would anyone let this same executive be in charge of building a new wing?  Of course not.  Why then do we not employ the same standards for what will turn out to be the most expensive and far reaching non-capital project that the hospital will ever undertake?  If you think you know, please share your answer.

By the way, I asked one of those executives how it was that he happened to be selected to lead the EHR project.  “I forgot to duck,” he quipped.  I guess that’s as good a reason as any.

You’re no Aristotle

Everything is written with the idea of persuading the reader; either explicitly—what is written is true, or implicitly—what is written is informative or funny, thereby persuading you that the author is informative or funny. Aristotle employed three forms of rhetorical persuasion; pathos, ethos, and logos. For those of you thinking, “Yeah, but you’re no Aristotle,” you’ll get no argument from me, but you have to admit, it’s a good likeness.

I basically write from whatever stream of clatter happens to be knocking about at the time. For me, writing is a little like speaking in parenthesis, only a little quieter and with more ambiguity. So, what is lurking up there at the moment? Sure you want to know?

I’m trying to convince my son the futility of not doing something correctly the first time he does it, arguing that it takes twice as long to do it wrong as it does to do it correctly. I call it the DIRT-FIT Principle—Do It Right the FIrst Time. For instance—loading the dishwasher. It takes a certain amount of time after clearing the counter to place the dishes, glasses, and utensils in the dishwasher pell-mell. It takes twice as long to redo it.  The same principle applies to making his bed, putting away his shoes, and brushing his teeth.

The same principle applies to implementing an EHR system. It costs twice as much to put it in twice as it does to implement it correctly the first time. I bet you know a hospital who is busily implementing EHR 2.0.  There is the difference between EHR implementations and sons. Implementations have the right not to do it correctly the first time—my son doesn’t.

Do EHR vendors have a built-in bias?

I write from the perspective of hospitals and physicians who are required to pass tests of certifiable, meaningful use, and interoperability. As would be expected, comments made by EHR vendors are quite different from miine.   Forgive me for stating the obvious–their job is to get you to buy what their firm sells, to make you a believer.

There are more than four hundred firms who have something to sell you, something they believe will make your life better. How do you know which one of them is offering something that may work for you? How can you tell? Heck, how can you tell which product will still be viable in three years?

A question worth considering.  As passionate as the vdenors’ sales reps are, when a sales rep moves from Vendor A to Vendor B, does their passion remain with Vandor A?  Of course not.  The new “best thing since slided bread” is the thing offered by Vendor B.

Where does that leave you?  For starters, don’t buy it on faith.  Don’t buy it just because somebody else bought it–is their judgement better than yours?  You need a way to make an objective decision about some very subjective information.  One way to do that is to turn the subjective issues into quantifiable business requirements.

What do you think?

Pass the salt

Okay campers, we’re going to jump right in to this one. There was a point not too long ago when the US was involved in the SALT talks, the Strategic Arms Limitation Treaty. For those too young to remember, the US and the Soviets—that’s what we used to call the Russians. Actually, they were called Russians before they got married and changed their name to Soviets which is neither here nor there.

This came about because the two countries were MAD at each other. Not in the usual sense, but in the sense of mutually assured destruction—of the world—several times over. Anyway, it finally occurred to both sides that perhaps we only needed enough weapons to blow up the world a few times instead of hundreds of times. What was the result? We’re still here. We’re here because the people who built the weapons agreed to greatly reduce their number of weapons. They learned how to function differently. Instead of saying we can’t do that, they took the approach of saying, “If we wanted to do that, how would we do it?” Getting rid of nuclear weapons—no small feat.

Segue. I realize this is a bit of a stretch just to make a point, but since we’ve come this far we might as well make it. What would you do if you came to work one day and received an email which read that your organization had decided against ever implementing an EHR?

To me that is a perfectly reasonable idea. Of course, I’m someone who wonders how the color purple feels. But why not stop all of this foolishness around EHR?  Agree, or is killing EHR a foolish idea?

I think it’s much less foolish than implementing an EHR and having no reasonable expectation that it will work.  The odds are that your EHR has a better chance of failing than it has of succeeding.

I have no problem with EHR.  I do, however, have a problem with businesses constantly making the same mistakes, making EHR a multi-million dollar repository for their mistakes, and then complain about the fact that the EHR isn’t doing a good job.

What do you think?

How measuring Brittan can improve your EHR success

So, last night I am watching NOVA.  The episode discussed fractal geometry and aired the same time as the Viking Bears game.  Admittedly, not a typical Y chromosome choice, but interesting none-the-less.

A fractal is a fragmented geometric shape that can be split into parts, each of which is a reduced-size copy of the whole.  Simple enough.  Common examples of fractals include the branching of trees, lightning, the branching of blood vessels, and snowflakes.  In the seventies the mathematician Benoît Mandelbrot discovered that fractals could be described mathematically.

It turns out that a shoreline is another example of a fractal.  For example, let’s say you wanted to determine the length of the coast of Brittan by measuring it instead of just using Google.  The coastline paradox says the measured length of the coastline depends on the scale of measurement.  The smaller the scale of measurement, the longer the measurement becomes.  Thus, you would get a longer measurement if you measured the coastline with a ruler than with a yardstick.  This paradox can be extrapolated to show that the measured length increases without limit as the unit of measures tends towards zero.  In the first picture, using a 200 km ruler, the coastline measures 2,400 km.

In this photo, using a 50 km ruler, the coastline measures 3,200 km.

I’m not sure why this idea needed to be discovered, it seems a little obvious—more information yields more informed results.

A few years ago I was hired by a firm to report to their board on their vendor selection process.  The firm was about to issue a two-page RFP to two vendors.  I convinced the firm to redo the process.  They ultimately issued an RFP of more than a thousand requirements and selected a vendor who was not on their original list.

Again it seems obvious, but being obvious doesn’t always result in smart behavior.  If you’re getting ready to spend seven to nine figures on and EHR, wouldn’t you like some degree of confidence that you selected the best one for your hospital?