My thoughts on “One EMR Vendor’s View of Meaningful Use”

Posted by

3

What if Meaningful Use turns out to be no more relevant to EHR than agriculture is to bull fighting?  Even worse, what if meeting Meaningful Use (MU) damages a provider’s business?

There is a world of difference between EHR and Meaningful Use.    It is a square and rectangle proposition.  All instances of MU require an EHR.  However, all EHRs do not require MU.

When I evaluate changing a business strategy, I like to do so under the following test:

  • Is it necessary?
  • Is it sufficient?

For the strategy to be beneficial to an organization it must be both necessary and sufficient.

Let us begin with whether MU is necessary.  Necessary for what—to make the provider’s caring for its patients better; to make their business better.  MU does neither.  Implementing an EHR, though it is optional, is important.  So is meeting MU.  The last time I checked, there were no long queues in Madison to grab an EHR, and no people camping outside of the CMS offices to be first in line for the ARRA money.  MU does not pass the test of necessity.

Does MU pass the test of sufficiency?  Is it adequate?  Again, for what?  The way to answer this question is to ask, “How would your organization implement EHR if MU did not exist”?  your answer to this question defines what is necessary.

Much of MU has to do with how EHR is implemented and adopted.  For all the attention vendors are paying to MU, it is a bit nonsensical.  Most of the onus on MU is tied to the provider.  The most the vendor can offer is that they will not do anything to encumber a provider’s chances of meeting MU.  Many of these vendors are the ones who will require you to implement an upgraded version of their product in order to meet certification.

In closing, will the MU money run out?  On the contrary, I think they will not be able to give it away.

EHR: Pass me the wrench

Posted by

0

Watching some work with EHR is a lot like watching a chimp trying to use tools for the first time.

Some vendors are like a fine wine

Posted by

0

Have a vendor for dinner tonight.

Fashion can be reinvented every 6 months, healthcare can’t.

That’s plenty of reason to try to get EHR/HIT right.  Remember this little principle; DIRT-FIT–Do It Right The First Time.  Don’t know how?  There are some who do.  There is even a larger group who think they do.  If you look pretenders in the eye, sometimes they blink.  Some vendors are like a fine wine—you have to stomp on them and keep them in the dark until they’re ready to have for dinner.  To be fair, they may feel the same way about me.

A vendor client of mine mentioned their customers told them the vendor did not understand their customer’s business. The vendor thought the customer’s comments were unfounded–their basis for believing this is that they had been in the business for years.  I told the CEO I would buy dinner for everyone in their firm who previously worked on the clinical side of a healthcare provider.

I ate by myself, no wine.  A nice Chianti served with a side of fava beans would have been nice.  Clarice?
Kind Regards,

Paul

Paul M. Roemer
Managing Partner, Healthcare IT Strategy

1475 Luna Drive, Downingtown, PA 19335
+1 (484) 885-6942
paulroemer@healthcareitstrategy.com

My profiles: LinkedInWordPressTwitterMeetupBlog RSS
Contact me: Google Talk/paulroemer Skype/paulroemer Google Wave/paulroemer

EHR–One time at band camp…

Posted by

0

Like many of you, I see two distinct groups who do not play well in the same sandbox—clinical and IT.  Having clinicians go to the HIT summer camp to pick up a few skills is not the same as pulling a few costly and hairy projects from the bowels of project hell any more than it would be to have an IT executive take an EMT course and then assume that person was qualified to perform surgery—this one time at band camp…

Before I get up on my stool and knock myself off, I know CMIOs and CIOs who have made HIT and EHR very successful.  To them I ask, do not rake me across the Twitter coals as I try to make a point.

There’s knowledge, and then there’s qualified.  Doctors do four years of medical school, they intern, and if they specialize, they throw in a few more years before they become the in-charge.  Years of training and practice before the doctor is allowed to run the show.  Why?  Because what they are about to undertake requires practice, tutelage, and expertise.  Most of the actual learning occurs outside the classroom.

There are those who suggest the skills needed to manage successfully something as foreboding as full-blown EHR can be picked up at HIT Camp.  This does a disservice to seasoned IT professionals.

Most large IT projects fail.  Large EHR projects fail at an even higher rate.  Most clinical procedures do not fail, even the risky ones.

What’s the spin line from this discussion?

  • Rule 1—large EHR projects fail at an alarming rate
  • Rule 2—sending a clinician to band camp probably won’t change rule one

Don’t believe me?  Ask friends in other industries how their implementation of an ERP or manufacturing system went.  There are consulting firms who make a bundle doing disaster recovery work on failed IT projects.  They line the halls like turkey vultures waiting for CIO or project manager carrion.

Back to Rule 1 for a moment.  How can I state that with such assurance?  Never before in the history of before—I know that’s not a proper phrase—has any single industry attempted to use IT to:

  • impart such radical charge (patients, doctors, employees)
  • impart it on a national basis
  • hit moving and poorly defined targets—interoperability, meaningful use, certification
  • take guidance from nobody—there is no EHR decider
  • implement a solution from amongst hundreds of vendors
  • implement a solution with no standards
  • move from an industry at 0.2 to 2.0 business practices
  • concurrently reform the entire industry

Just what should a CMIO be able to do?  What are the standards for a CMIO?  To me, they vary widely.  Is a CMIO considered an officer in the same sense as the other “O’s” in the organization, or is it simply a naming convention?  The answer to that question probably depends on the provider.

Here’s how I think it should work—I realize nobody has asked for my opinion, but this way I’ll at least provide good fodder for those who are so bold as to put their disagreement in writing.

I love the concept of the CMIO and think it is essential to move the provider’s organization from the 0.2 model to the 2.0 model.  Same with the CIO.  However, getting them to pool their efforts on something like EHR is likely to fail as soon as one is placed in a position of authority over the other.  It’s sort of like getting the Americans and French to like one another.

I liken the CMIO’s value-add to that of the person providing the color commentary on ESPN—it adds meaning and relevancy.  The CMIO owns and answers a lot of the “what” and the CIO owns and answers a lot of the “How”.

Still unanswered are the “Why” and “When”.  A resource is needed who can state with assurance, “Follow me.  Tomorrow we will do this because this is what needs to be done tomorrow.”  That skill comes from an experienced Project Management Officer, the PMO.  It does not come from someone who “we think can handle the job.”  Nobody will respect a PMO’s  ability if they do not have the requisite expertise.  EHR needs someone who can state from their experience, “One time at band camp…”   If the EHR can’t lead, or the team is not willing to follow the PMO, you can plan on doing the project over.

How does Heisenberg’s Uncertainty Principle affect EHR?

Posted by

2

One of the great things about social media is its ability to infer attributes of both the readers and the writer.  When you finally meet your virtual pen pal the mind wanders—I thought he sounded taller.

There are those among us who when they picture me writing, see me sitting at my desk, wearing my baby seal-skin slippers, and supping on a bowl of loggerhead turtle soup.

Segue.

According to Heisenberg’s Uncertainty Principle (used in physics) certain pairs of physical properties cannot both be determined simultaneously.  That is, the more precisely one property is known, the less precisely the other can be measured. For instance, the next time you are standing by the side of the road, and cars are whizzing by you, try to decipher the speed of the car, and its exact location.  If I remember my math correctly, the first derivative is its velocity, the second, its acceleration.  To know exactly where the car is at a precise moment in time, the car must be stationary—as in not moving.  Thus, to ascertain its position, the position must be fixed.  The Heisenberg Uncertainty Principle requires that for someone to determine B, A must cease to be a variable.

The Uncertainty Principle can be represented as something like this:

One can see that as additional properties are tossed into the mix the probability of predicting any particular outcome goes to zero.

Thus follows Roemer’s EHR Uncertainty Principle—if you don’t know where you are going, you arrived a long time ago (A little like Pink Floyd’s, “How can you have any pudding if you don’t eat your meat?”).

The conflicting principles include;

·         Implementation date

·         Completion date

·         Final cost

·         Your functional requirements

·         The vendor’s capabilities

·         Acceptance testing

·         What should the EHR do

·         How do you know when you are done

·         Should you meet Meaningful Use

·         Will you receive the ARRA money

Here is the point of the allegory.  The chances of a physician group or hospital knowing the answer to all but one of the above principles are zero.

Permit me to throw a wrench into the loggerhead soup and let you know that not having the answers to all but one of the variables is okay.  That is the way projects work.

Since most of you implementing EHR have not ‘been-there, done-that’ with respect to implementing EHR, it is reasonable to expect there are more unknowns than knowns (spell-check indicates that it is not a word, but I know you are keeping up with me).

So, how can you use Heisenberg’s Uncertainty Principle to your advantage?  It is actually rather simple.  Do not allow your implementation to be guided by the unknowns.

·         Do not set an arbitrary budget for something you have never purchased

·         Do not set an arbitrary implementation deadline

Do what you must to make sure you implement an ERH that does what you need it to do.  Do not let yourself be constrained by principles whose only possible effect will be to derail your project.

If you are willing to take that risk, the other principles become moot (the correct terms is moot, not mute—look it up—sorry about the preposition).

If all else fails, consider getting a pair of the seal-skin slippers.

Paul M. Roemer

Managing Partner, Healthcare IT Strategy

1475 Luna Drive, Downingtown, PA 19335

+1 (484) 885-6942

paulroemer@healthcareitstrategy.com

My profiles: 

My blog: Healthcare IT Strategy How to Revive a Failed EHR Implementation

How to Revive a Failed EHR Implementation

Posted by

1

My latest post on www.healthsystemCIO.com.  Here’s an idea I think merits consideration.

http://healthsystemcio.com/2010/07/30/how-to-revive-a-failed-ehr-implementation/

What do you think?

Finally, an EMR worthy of a T-shirt

Posted by

4

Those who are regular readers know I’ve commented on more than one occasion that you never see anyone at the HIMSS convention walking around wearing a T-shirt imprinted with the slogan, “I love my EPIC”, or one stating, “McKesson forever”–unless they were talking about the implementation plan.

Today, my perspective changed–I’m going to start selling T-shirts printed with the phrase, “SRS-Soft Rocks my Docs.”

You may ask, ‘Who is SRSSoft’?  Fair question.  I could not have given an adequate response to that question prior to today.

I spent some time with them, ran their demo–I played doctor but they stopped me before I was able to insert a chest tube.  I ran the demo.  Why is that important?  It went like this.

“So, if you were a doctor, what would you do?”

With enthusiastic anticipation, I searched for my scalpel–that wasn’t what he meant.  “I’d see who my next patient is.”

“Do it.”  (Mind you, all of what I am doing happens on one screen faster than a sneeze.)  I clicked the schedule and up popped all the patient’s information.

“Next?”

“I’d probably want to review their chart.”

“Do it.”  (Don’t try this at home unless you are a devotee of Scrubs or other medical training.

Same screen, up pops the chart.

“Next?”

I click on the notes from their last visit, compare their labs by pulling up a comparison chart–new versus old; scan the X-RAY, and review their list of medications.  I did this all on one page and figured out in less time than it took you to read this.  We did the demo using two screens.  That way, if I am describing what I am seeing to the patient on their X-RAY, instead of holding the film up at the ceiling and hoping my patient understand what I am talking about, I point to it with my mouse and let the patient see it one their screen.

Tomorrow I was going to issue an EHR RFP for a small clinic.  Not any more.  No point in having them pay me to hunt down a solution when I’ve already found one.  Did I mention you can also get it with a world-class practice management system?

So what makes me think this EMR can handle a practice size of up to a few hundred doctors?  Let me try to summarize its benefits with the following.  If we separate healthcare into two arenas–the business of healthcare (the business side) and the healthcare business (the clinical side)–this EMR is so well designed, it makes the mundane business tasks almost invisible to the doctor.  Instead of spending twenty percent of each day moving charts, filling out forms, sending faxes, dictating and transcribing notes, the clinical team can either spend more time with their patients or see more patients.

Now, let me tell you about their secret sauce, part of what makes it so special.  You are going to think I’ve lost my mind when you read this.

One of the first questions most doctors are going to ask a vendor is whether or not the system is certified.  (Do not repeat this to anyone–that is why I am writing in parentheses–this system is not certified.  They have no plans to get it certified.)  Why?  Because certification is as relevant to the value of an EMR as agriculture is to bull fighting.  Certification will not improve care, will not enhance the doctor patient relationship, it will not improve the patient experience, it will not increase productivity.  Certification does one thing.  It enables you to get a check provided that your EMR implementation does not fail, provided that you pass the Meaningful Use audit, and provided you are willing to upgrade your existing system to your vendor’s new and improved certifiable version.  That certifiably makes little to no business sense.

Anyway, if you want a system that makes the stuff you hate doing go away, take a look at this.

I’ve also written about way hospital EHRs fail.  A big reason for their failure is the drop in productivity they experience, and a lack of acceptance from the doctors.  Sort of makes me wonder if they could use this tool as a front-end for those big pricey EHRs.

Me, I printing T-shirts.  PayPal accepted.

A little IT knowledge can kill you

Posted by

1

It almost killed me.  Curious?  I lived in Colorado for a dozen years, and spent almost every other weekend in the mountains, fly-fishing, skiing, climbing, and painting—any excuse would do.  Colorado has 54 peaks above fourteen thousand feet.  In my twelve years I climbed most of them.  Some solo; some with friends.

I owned almost everything North Face made, including a down sleeping bag with thermal protection which would have made me sweat on the moon and a one-burner propane stove which cranked out enough BTUs to smelt aluminum.  Two of my friends and felt we needed a bigger challenge than what Colorado’s peaks offered.

The dot in the photo is me.

We decided on a pair of volcanoes in Mexico, Pico de Orizaba and Popocatépetl—both over 18,000’.  We trained hard because we knew that people who didn’t died.  We trained with ropes, ice axes, carabineers, and crampons.  One day in early May we arrived at the base ofPico de Orizaba.  The man who drove us to the mountain made us sign the log book, that way they’d know who they were burying.  After a six hour ride from a town with less people than a K-Mart, we were deposited at a cinder-block hut—four walls, tin roof, dirt floor.  Base camp.

Before the sun rose we were hiking up ankle-deep volcanic ash; gritty, coarse, black sand.  The sand soon turned in to thigh-deep snow.  We took turns breaking trail, stopping only long enough to refill our water bottles by hand-pumping glacier melt from the runoff in the bottom of cobalt blue ice caverns carved from solid glacier.

Ice Cave we used to collect drinking water

Throughout the trek we passed crude wooden crosses that were stuck into the ash and snow, serving as grim reminders of those who’d gone before us.

We knew the signs of pulmonary edema, but were reluctant to acknowledge them when we first saw it.  It was about one the following morning when we decided to make camp.  My roommate was having trouble concentrating, and his speech was slightly slurred.  When we asked him if he was ill, he responded much like one would expect an alcoholic would respond when asked if he was okay to drive.  “I’m fine.”

We were at about 16,000’.  The slope seemed to be at about forty-five degrees.  The sheet of ice upon which we stood glistened from what little light the stars emitted.  I removed my tent pole from my pack and placed it on the ground—we were going to camp for the night.  We watched in awe as the pole gained speed and hurtled down the side of the volcano, quickly lost in the darkness.

Realizing my friend wasn’t doing well, and that I was now feeling somewhat punkish, we made the difficult decision to turn back.  The only survival for edema is to lose enough altitude until you reach an altitude where there is enough air pressure to force the oxygen into the blood.  Eighteen hours of climbing.  Pitch black.  And then it started to snow.  Any other time the view would have been awesome.  We headed down, me carrying my pack and his, he with our friend.

We arrived at the block hut around four that morning.  By then I was no longer making any sense.  My roommate had recovered, but I had become somewhat delirious—at least that’s what they told me later.  Not knowing right from left or wrong, I was determined to keep walking.  The two of them took turns laying on me to prevent me from sneaking out during the night.

A little knowledge almost killed us.  The scary thing is that we knew what we were doing.  We had trained at altitude, had a plan, worked the plan.  The plan shifted.  Sometimes shift happens.

It happens more with IT.  Much more.  Do you know what the chances are of any IT project ‘working’ that costs more than$7-10 million?  (Working is defined as having a positive ROI, a project that was delivered on time, withing the budget, and delivered the expected results.) (IT includes workflows, change management, training, etc.)  Two in ten.  Twenty percent.  That’s below the Mendosa Line—non baseball fans may have to look up that one.  Remember the last industry conference you attended?  Was it about EHR?  Pretty scary knowing most of them were planning for a failure.

Put your best efforts, your brightest people on planning the EHR.  Make them plan it, then make them plan it again, and then make them defend it, every piece of it.  If they don’t convince you they can do it in their sleep, you had better redo it.  Do they know what they’re planning to do?  Do they know why they’re planning to do it that way?  If they haven’t done it before, this may not be the best time for them to practice.  EHR is not a good project for stretching someone’s capabilities.

Planning is difficult to defend twice during the life of a large program.  First, at the beginning of the program when the C-Suite is in a hurry to see people doing things and signing contracts.  The second time planning is difficult to defend is the moment the C-I-Told-You-Sos are calling for your head for having such an inadequate plan.

How would I approach planning an EHR program for a hospital?  If we started in September, my goal would be to;

  • Have a dedicated and qualified PMO in place in four weeks
  • Begin defining workflows and requirements by October (I’m curious.  For those who have done or are doing this piece, how many FTE’s participated?  I ask because i think chances are good that your number is far fewer than I think would be needed.)
  • Issue a requirements document by mid-January.
  • Be able to recommend a vendor by the end of March.

That seems like a lot of time.  There are plenty who will tell you they can do ‘it’ quicker.  Good for them.  The best factor in your favor right now is time.

Reread this in a year and see where you are…

…See, I told you so.  Anyone want to go hiking?

Paul M. Roemer
Managing Partner, Healthcare IT Strategy

1475 Luna Drive, Downingtown, PA 19335
+1 (484) 885-6942
paulroemer@healthcareitstrategy.com

Would you be willing to help me?

Posted by

0

Please let me know if you would be willing to connect me with any good executive search firms.

Thanks, Paul

How can you solve the EHR puzzle?

Posted by

0

Seth Godin wrote about the “Perfect Problem.”

A perfect problem, in its existing state, is unsolvable.  The way most of us handle it is to click our heels together three times and hope it goes away.  We tend to work on imperfect problems, those that can be solved.

What is the difference between the two?  The first step is the ability to understand what makes the perfect problem uniquely unfixable.  Perhaps a few examples would help.

  • The CEO imposed a deadline for the implementation of EHR.
  • CMS Meaningful Use rules do not fit with our operational strategy.
  • If we do not implement EHR by this date, we do not get the money.
  • We must meet Meaningful Use
  • We do not have enough resources from the EHR users to understand their processes.
  • We cannot continue to support these low-margin services
  • We do not have enough time to define our requirements
  • We cannot afford to spend the time required to assess our processes before we bring in the EHR vendor.

What can be done?  The easy answer is to plan for failure and do your best to minimize it.

What is another way to describe the above examples?  They are constraints.  They can all be rewritten using the word “can’t”.  Rewritten, we might say, “We had a chance to succeed, but because of X, Y, and Z we can’t.”  If that assessment is correct, you will fail, or at least under-deliver at a level that will be remembered for years to come.  That’s a legacy none of us wants.

There are a few solutions to this scenario.  You can eliminate the seemingly intractable constraints; the organization can determine to re-implement EHR and hope for different results; or they can simply find someone else to solve the perfect problem.

Experience teaches good leaders really want reasoned advice.  They want the members of the C-suite to tell them what must be done to be successful.  Good leaders do not accept “can’t”—not on the receiving end, not on the delivering end.

Some will argue, “This is the way our organization works.”  Even if that is true one must consider what is needed to make an exception to the constraint.  Would you accept this logic from a subordinate?  Of course not.  You’d demand a viable solution.  If you are being constrained in your efforts to solve a perfect problem, perhaps it is time to restate the constraints.

One of my college professors—way back when we still had inkwells on our desks—told me that if you cannot solve the problem the way it is stated, it is to your advantage to restate the problem.  Maybe the solution to the perfect problem is to restate it in a manner that makes it imperfect—solvable.

saintPaul M. Roemer
Chief Imaginist, Healthcare IT Strategy

1475 Luna Drive, Downingtown, PA 19335
+1 (484) 885-6942
paulroemer@healthcareitstrategy.com