Hospital

EHR Strategy: The Wildebeest Postulate

Posted by

0

The Kalahari; vast, silent, deadly. The end of the rainy season, the mid-day heat surpasses a hundred and twenty. One of the varieties of waterfowl, most notably the flame red flamingo that nested in the great salt pans in Botswana, has begun its annual migration. In the muck of one of the fresh-water pools that had almost completely evaporated, writhes a squirming black mass of underdeveloped tadpoles. A lone Baobab tree pokes skyward from the middle of the barren savanna. In its shade, standing shoulder to shoulder and facing out, a herd of wildebeest surveys the landscape for predators.  Sir David Attenborough and PBS can’t be far away.

Some things never change. I make my way across the freshly laid macadam to meet the school bus. Fifty feet in front of me is a young silver maple tree, the buds of its green leaves yielding only the slightest hint of spring hidden deep within. The late afternoon sun casts a slender shadow across the sodded common area. One by one they come—soccer moms; big moms, little moms, moms who climb on rocks; fat moms, skinny moms, even moms with chicken pox—sorry, I couldn’t stop myself—as they will every day at this same time, seeking protection in its shade. My neighbors.  It’s only sixty-five today, yet they seek protection from the nonexistent heat, a habit born no doubt from bygone sweltering summer days. A ritual. An inability to change. In a few weeks the leaves will be in their full glory, and the moms will remain in the shadow of what once was, standing shoulder to shoulder facing outward, scanning the horizon for the bus. A herd. Just like wildebeest.

The children debus–I invented the word.  Mine hand me their backpacks, lunch boxes, and musical instruments.  I look like a Sherpa making my way home from K-2.

I shared this analogy with the neighborhood moms—the bruises will fade gradually. I can state with some degree of certainty they were not impressed with being compared to wildebeest. So here we go, buckle up. By now you’re thinking, “There must be a pony in here somewhere.”

Some things never change; it’s not for lack of interest, but for lack of a changer.  For real change to occur someone needs to be the changer, otherwise it’s just a bunch of people standing shoulder to shoulder looking busy. How are you addressing the change that must occur for EHR to be of any value?  EHR is not about the EHR.  It’s not about ARRA money, and it is not about IT.  It is about moving from a 0.2 business model to 2.0.  You need someone who sees the vision of what is is—sorry, too Clintonian—must lead.  Be change.

One of the great traits of wildebeest is that they are great followers.

 

HIT: The Change Keeps Changing

Posted by

0

Hello to those whom I’ve yet to meet.  This is rather long, so you may wish to grab a sandwich.

I write to share a few thoughts.  I reside in the small place where those who refuse to drink the Kool Aid reside. For those who haven’t been there, it’s where those who place principle over fees dare to tread.

Where to begin? How to build your provider executive team? (Those who wish to throw cabbages should move closer to their laptops so as not to be denied a decent launching point.)

I comment on behalf of those in the majority who have either not started or hopefully have not reached the EHR points of no return—those are points at which you realize that without a major infusion of dollars and additional time your project will not succeed. Those who have completed their implementation, I dare say for many no amount of team building will help. Without being intentionally Clintonian—well, maybe a little—I guess it depends on what your definition of completed is.

If I were staffing a healthcare organization, to be of the most value to the hospital, I’d staff to overcome whatever is lying in wait on the horizon, external influences—the implications of reform and Stages 2 and 3 of Meaningful Use, and a national roll out of EHR with no viable plan to get there.  Staffing only to execute today’s perceived demands will get people shot and will fail to meet the needs of hospital. To succeed we need to exercise an understanding of what is about to happen to healthcare and to build a staff to meet those implications.

Several CEOs have shared that they are at a total loss when it comes to understanding the healthcare implications of reform and IT.  They’ve also indicated—don’t yell at me for this—they don’t think their IT executives understand the business issues surrounding EHR and reform.  I somewhat disagree with that perspective.

Here’s a simplified version of the targets I think most of today’s hospital CIOs are trying to hit.

1. Certification
2. Meaningful use
3. Interoperability—perhaps
4. Budget
5. Timing
6. Vendor management
7. Training
8. User acceptance
9. Change management
10. Work flow improvement
11. Managing upwards

There are plenty of facts that could allow one to conclude that these targets have a Gossamer quality to them.  Here’s what I think. You don’t have to accept this, and you can argue this from a technology viewpoint—and you will win the argument. I recently started to raise the following ideas, and they seem to be finding purchase—I like that word, and since this is my piece, I used it.

Before we go there, may I share my reasoning? From a business perspective, many would say the business of healthcare must move from a 0.2 to a 2.0 business model. (This is not the same as the healthcare business—the clinical side.)  The carrot?  The ARRA incentives—an amount that for many providers will prove to be more of a rounding error than a substantive rebate.

Large healthcare providers are being asked to hit complex, undefined, and moving targets, and they are planning on adapting to reform and reforming their own business model while they implement systems which will change how everyone works.  Hospitals are making eight and nine figure purchase decisions based in part on solving business problems they have not articulated. If success is measured as being on-time, in-budget, and fully functional and accepted, for any project in excess of $10,000,000, the chances of failure are far greater than the chances of success.

Their overriding business driver seems to be that the government told them to do this. Providers are making purchasing decisions without defining their requirements. Some will spend more on an EHR system than they would to build a new hospital wing.  Many don’t know what the EHR should cost, yet they have a budget. Many don’t know if they need a blue one or a green one, if it comes in a box, or if they need to water it.

So, where would I staff to help ensure my success—this is sort of like Dr. Seuss’, “If I ran the Circus”—the one with Sneelock in the old vacant lot.  I’d staff with a heavy emphasis on the following subject matter experts:

• PMO
• Planning & Innovation
• Flexibility
• Change Management
• PR & Marketing

Contrary to popular belief, not all of these high-level people need to have great understanding of healthcare or IT. You probably already have enough medical and IT expertise to last a lifetime.

Here’s why I think this is important. Here’s what I believe will happen. Three to five years for now the government would like us to believe there will be a network of articulated EHRs with different standards, comprised of hundreds of vendor products, connected to hundred of RHIOs, and mapped to a N-HIN.  Under the proposed model, standardization will not occur if only for the fact that there is no monetary value to those vendors whose standards are not standard.

Interoperability, cost, and the lack of standardization will force a different solution—one which is portable.  I think the solution will have to be something along the lines of a single, national, open, browser-based EHR.  It will be driven by consumers.  Consumers will purchase the next generation of super-smart portable devices that offer a combination of iPad/iPhone functionality.

The Personal Health (PRH) will have evolved to become the EMR.  How is this possible?  What do smart devices do?  They do one thing, billions of times each day, and they do it perfectly—they send and receive ones and zeros.  That is what today’s EMR are—ones and zeroes.  Those next-gen devices will be EMR-capable.  Why?  Because there are more than a hundred million customers who will keep buying these devices.

The so-called N-HIN will be the new Super Internet—not some cobbled together network of RHIOs.

Firms like Apple, Google, and Microsoft will drive this change.  We already buy everything they offer, in fact, we line up at midnight to do so.  By then, those firms will care less about selling the devices than they will about transporting the ones and zeroes that comprise the data.  Their current PHRs are their way of introducing themselves to consumers as players in healthcare.

The point I am trying to drive home is that from being able to adapt to change and reform, lean towards staffing the unknown.  Staff with leaders, innovators, and people who can turn on a dime. Build your organization like turning on a dime is your number one requirement. Don’t waste time and money worrying about Certification or Meaningful Use. If anyone asks you why, you can blame me.

If you want a real reason, I have two. First, they won’t mean a thing five years from now. Second, if I am the person writing an incentive check, I want to know one and only one thing—will your system connect with the other system for which I am also writing a check?  That is the government’s home run.

 

What if hospital business models weren’t so tribal?

Posted by

1

I tend to look at it from the perspective of the business model of many hospitals.  How does one transform a 0.2 business model to function in today’s let alone tomorrow’s changing healthcare model?

The clinical side of healthcare, the healthcare business, in juxtaposition to the business of healthcare, would never quarter to the idea of buying millions of dollars of technology without first knowing how they were going to use it.

Plenty can be gained by applying what other industries have done to become more effective.  In some respects the inherent structure, cost duplication, and rigid departmental silos remind me a lot of how the various agencies under Homeland Security function, operating in isolation, performing much of the same work, and not sharing information.

Other industries operate with a much less tribal model than healthcare.  Hospitals have created tribes and tribal chiefs.  In some hospitals the tribes have names like radiology, general surgery, psychiatry, and OBG/YN.  Other hospitals have redundant tribes named admissions, human resources, IT, and payroll.  Each tribe is run by the tribe’s chief.  The chief’s dominant weapon is his or her budget which is lorded over its individual tribe, and a dispute vehicle of the other tribes.

The tribal organization is more a reflection of how the hospital evolved over the years, not a result of an inept business strategy.  Nobody set out to build an ineffective and internally competitive model, or one that duplicated support functions.  Acquisitions have reinforced and exacerbated the problem, duplicating and increasing costs without yielding a resultant increase in value.

Before the business of healthcare is prepared to cope with the unknowns of the myriad of external influences it will face in the next few years, it must first change how it functions under its current structure.  It might begin by revisiting its present structure and making sure that its performance and quality precede the application of technology.

I frown on using the term efficient.  To me, efficiency implies speed, and doing bad things faster is no solution.  Let us work at improving effectiveness and good things will happen.

 

Patient Relationship Mangement–who’s kidding who

Posted by

0

(AP) New York. CNN reported that Patient Relationship Management (PRM) and Patient Experience Management (PEM) died. Services will be held next Monday at Dunkin Donuts. Patients are asked not to attend, but instead to forward their complaints to Rosie O’Donnell.

PRM is what hospitals tend to use; it measures against their standards.  It is a push model.  PEM is what patients tend to use; it is a pull model.

A fellow, David Phillips, wrote, “Relationships should be considered part of the intrinsic value of the corporation”—he is an auditor. A group of PhDs who concluded that the six components for measuring relationships include; mutuality, trust, commitment, satisfaction, exchange relationship, and communal relationship. I feel better just knowing that.

Patient Relationship Management—PRM. I hate being the one to break the news but, PRM is dead. I didn’t kill it. It’s dead because it never existed.  Relationship Management.  Who is actually measuring a relationship?  What unit of measure do you use to measure a relationship? Inches, foot-pounds, torque?  PRM carcasses are strewn about. You can’t manage what you can’t or don’t measure.

“What are you talking about?” She hollered. “We measure. We measure everything. If it’s got an acronym, we’ve got a measure for it. KPIs. CSFs. ACD. IVR. ATT. AHT. Hold time. Abandonments. Churn.”

Just because something is being measured, it doesn’t mean that the measure has anything to do with the desired outcome. Nobody has a single quantifiable metric that precisely points to the health of an individual patient relationship. Seems silly? No sillier than really believing you have an ability to manage something as ephemeral and esoteric as relationships.

Just how good are those relationships everyone thinks they’ve been managing? Five percent higher than last month?  Down three percent over plan?  Permit me a brief awkward segue. Joseph Stalin said, “One death is a tragedy, one million deaths are a statistic.” The point is that scale matters—a great deal.  One death versus a million.  One patient interaction versus millions.  It makes a difference. The things we do that impact patient experiences impact patients individually, one patient at a time.

PRM metrics in use at hospitals apply to patients—plural.  PRM metrics are benchmarks and averages—patients aren’t.  Hospitals measure against the masses, against the pool of patients.  The patient mass does not churn, does not leave your hospital, does not ask to speak to a supervisor.  Consider a patient, not a single metric.  Not a single measure in your hospital accurately depicts the success or failure of that patient’s experience.

So, what’s a hospital to do? Stop trying to manage your hospital’s performance by managing relationships.  Here’s what you can do, manage your hospital using things you can measure. Once you can measure it you can manage it.  A hospital can start by defining metrics for the following;

Patient Referral Management—how many patients came via referral?

Patient Resolution Management—how many patient problems were fixed?

Patient Recovery Management—how many patients did you win back?

Patient Retention Management—how many patients did you prevent from going elsewhere?

If you are the CIO, show the VP of Operations your ideas for tracking the answers to these questions. This is step one to having a real PEM program.  If you are really serious about having a patient experience management program, change the word “experience” to the word “equity.”  Patient Equity Management—all of a sudden you have something worth talking about.

 

HIEs: Too Many Cooks Spoil the Broth

Posted by

0

Is the number of people working on developing Health Information Exchanges (HIEs) is greater than the total number of people who attended HIMSS in Orlando; more than 30,000?  Why are five hundred HIEs are being built?

Let us assume for a moment that there is a set of standards somewhere, a blueprint perhaps, for what a good HIE should be able to do.  Granted, if we are going to be honest, an HIE does not have to do very much; does it?  It does not change the data in a health record.  It does not add data.  And, it neither creates nor destroys health records.

In its simplest form, a health record comes in from some place, and that same record goes out to some other place.  And what is in that health record?  If we are trying to keep it simple in order to show the problem is in fact solvable, what is in the health record is a formatted collection of ones and zeroes.  And how does the HIE “move” the ones and zeroes?  The movement is caused by writing computer applications; code—ones and zeroes.

The blueprint for an HIE is nothing more than a pipe to move formatted zeroes from point A to point B.  Now in reality, we have about five hundred HIE teams working hard to build disparate HIEs.  To what end?  To move ones and zeroes from point A to point B.  So, the 500 HIE teams are writing 500 different HIE applications using ones and zeroes to move ones and zeroes.

Doing the math—500 HIE teams * 1 HIE application per team = 500 different HIE applications.  If done correctly—which is an entirely different conversation—we will have 500 HIEs, each of which are capable of doing the exact same thing; which is—moving ones and zeroes.

Let us dissect the ones and zeroes concept for a moment.  When Al Gore created ones and zeroes he did so with the premise that all ones were created equal, all zeroes are created equal, and that ones and zeroes are equal.

Now, what makes the one and zero concept particularly great with regard to HIEs and all of healthcare IT is there is never a need for a “two”.  No CIO worth his or her salt will ever sit at a steering committee meeting and state, “If I only had a 2, this whole problem would go away.”

If one looks correctly at the issue of HIEs by breaking it down to its simplest elements, it is a unique problem to solve.  Unique—as in singular.  Two HIEs do not solve the problem better than one HIE.  Once you have two, you no longer have a unique solution, and when you have 500 HIEs, you have a mess.

Here is the kicker to this argument.  What else do you have when you have a single HIE capable of reading the data from all of the various EHR platforms?  Exactly.  You have the N-HIN—the Nationwide Health Information Network.  Why?  Because when push comes to shove, the N-HIN is nothing more than a glorified HIE.

However, once you have more than one HIE, you then need an HIE for the HIEs, which is the only reason there is any discussion about building an N-HIN.

So, in addition to the fact that 500 HIEs are 499 too many, do they create any other problems?  Of course they do.  They add a very high and unnecessary degree of additional complexity to the healthcare IT systems of every healthcare provider.  Some providers offer services within many different HIE footprints.  Every provider will need to adapt their systems so that the provider’s healthcare records can be accepted by their corresponding HIE pipe.

Instead of building 500 HIEs, and forcing them to some semblance of a standard, why not just build one HIE and have that be the standard?

 

Abi-normal

Posted by

0

I remember the first time I entered their home I was taken aback by the clutter.  Wet leaves and small branches were strewn across the floors and furniture. Black, Hefty trash bags stood against the walls filled with last year’s leaves. Dozens of bright orange buckets from Home Depot sat beneath the windows. The house always felt cold, very cold. After a while I learned to act normally around the clutter.

There came a time however when I simply had to ask, “Why all the buckets? What’s the deal with the leaves?”

“We try hard to keep the place neat,” she replied.

“Where does it all come from?” I asked.

“The open windows, the stuff blows right in.”

I looked at her somewhat askance. “I’m not sure I follow,” I replied as I began to feel uneasy.

“It’s not like we like living this way; the water, the cold, the mess. It costs a fortune to heat this place.  And, the constant bother of emptying the buckets, and the sweeping of the leaves.”

Trying to assume the role of thought leader I asked, “Why don’t you shut your windows? It seems like that would solve a lot of your problems.”

She looked at me like I had just tossed her cat in a blender.

When you see something abnormal often enough it becomes normal. Sort of like in the movie The Stepford Wives.  Sort of like Patient Experience Management (PEM). The normal has been subsumed by the abnormal, and in doing so is slowing devouring the resources of the hospital.

Are you kidding me? I wish. It’s much easier to see this as a consultant than it is if you are drinking the Kool Aid daily. When I talk to people about a statistic that indicates that 500 people called yesterday about their bill, and everyone looks calm and collected, it makes me feel like I must be the only one in the room who doesn’t get it—again with The Stepford Wives.

If I ask about the high call volume they always have an answer, the same answer.  “Billing calls are usually around 500 a day.”  They say that with a straight face as though they are waiting to see if I will drink the Kool Aid. It’s gotten to the point where no matter how bad things get, as long as they are consistently bad, there not bad at all.

This is the mindset that enables the PEM manager (I know you don’t have one—I am being facetious) to be fooled by his or her own metrics. When is someone going to understand that repeatedly having thousands of people calling to tell your organization you have a problem, means you have a problem?

It would probably take less than a week to pop something on your web site, and post a YouTube video explaining how to read the bill.  Next week, do the same thing and help patients understand how to file claims and disputes—granted, you may need more than a week for this one.

 

 

EHR: The 40-chicken crocodile

Posted by

1

Got a couple hundred million burning a hole in your pocket?  Why not buy an EHR?  Indeed.

Riddle me this Batman, “What is a 40 chicken crocodile?”

It is the number of chickens you have to feed it each day to keep it from eating you. What is the crocodile at your hospital?  Is it your EHR?

Let me recount to you a true story about the details of one of the EHR “success” stories.  A major hospital who selected their EHR from among one of what I like to call the oligopoly EHR Flavor of the Month Club.  You know the suspects.

Permit me to throw a wrench to those clairvoyants who think they know where this is going before I’ve even written it.  Admittedly, I have a tendency to throw metaphorical tomatoes in one direction—that of the vendors.  That’s because, they are often easy targets.  Slow down Pepito.

This hospital, and from what I was told, the vendor, did it right.  I am not sure I would have differed from the approach of either.  The hospital spent a few years in its vendor selection process, and they were very thorough.  They spent two years building their process maps, ensuring the vendor implemented the EHR to meet their needs, not the other way around.  Operations led the nine-figure project.

They implemented many of the support functions and a few of the specialty functions.  Here come the chickens.  After implementation, cash flow dropped by 80 percent for several months due to significant issues they encountered cleaning up the revenue side.  Doctors were instructed to cut their hours by fifty percent to allow them to learn to use the system.  Hours are still down by twenty percent, well more than a year later.  Users use about one-third of the functionality, even after a rigorous training program.

The hospital held off doing most of the clinical implementations for two years.

I asked for some recommendations.  What would you have done differently?  Here’s what I learned.  If you have a research organization you need to spend extra special attention to their workflows.  Managing post-go-live was a big issue to begin to offset productivity losses. Without a continuous process improvement program the EHR would not have been accepted. Do not pick a go-live date at the outset of the project as it causes the organization to be paralyzed simply to hit the date.  Testing was compromised to meet the go-live date. The post go-live issues are still being fought.  Do not let the design or build teams skimp on either reporting or testing, they are still playing catch-up.

So, after doing a pretty bang up job, at least from where I sit, there are still a lot of chickens being fed to the crocodile.  Wonder how many chickens it would have taken had the users not been as involved as they were.  How many had the users not spent two years pre-build defining processes?  A lot.  Now comes the rest of the clinical effort.  See you at the poultry counter.

 

HIE: Are two HIEs one too many?

Posted by

4

The is my most recent post at healthsystemcio.com

According to Wikipedia, Health information exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system. HIE provides the capability to electronically move clinical information among disparate health care information systems while maintaining the meaning of the information being exchanged.

That seems really straight forward, at least to me. I find it helpful to whittle complex ideas down to a point that enables me to explain them to my parents, without either of us having to reach for the Tylenol.

In its simplest form, an HIE is a pipe, a pipe that transports ones and zeroes. Back in the days when I still had hair, one of my clients was the CEO of a large cable television company. He explained his business this way; “We are just like the water department. We put a pipe in the ground, send something through it, and every month people mail me money.”

He also sent ones and zeroes.

Now, there are those around us, apparently thousands of them, who have made it their mission to convince those in the minority that HIEs are far more complex than they really are. Maybe I just do not understand the concept of ones and zeroes.

You probably know that several hundred HIEs are in the process of being built—and they are all being built by people who have little to no experience building HIEs. Now, here is where everything gets a little hairy. Let us look back on the definition of an HIE and let us focus our conversation on building just one HIE. The tricky part about getting the HIE to work is that pesky little word “disparate,” as in disparate health information systems, and the last time I counted EHRs, I hit 300 before giving up.

That is where all that disparate clinical information comes from. However, when push comes to shove, the information from all of those different EHRs is pretty much the same, but the various EHR vendors just line up their ones and zeroes differently, thus enabling them to prevent others from playing in their sandbox.

There is another disparity surrounding HIEs, one that is unspoken. Suppose you and I decide to build an HIE, a good one. After some period of time, we get rid of all the little disparities among the various EHR vendors and are able to zip those little ones and zeroes from one end of the HIE pipe to the other. Let us also suppose we used a very long pipe, so we could use this HIE anywhere. It would work for a hospital, or at an Integrated Delivery Network (IDN), or across a region.

Our HIE is able to move our individual healthcare information from one end of the pipe to the other wherever the other end may be.

I forgot to mention the disparity. The unaddressed HIE disparity is the one created from having hundreds of HIEs, each designed in its own vacuum by people who have little experience filling vacuums. And when those HIEs have been built, what will they do? Exactly. They will move clinical information among disparate healthcare information systems. In laymen’s terms—ones and zeroes from EHR vendors who do not play well together.

The new ones are identical in functionality to the one we just built, only now there are 500 of them.

Now to the meat of the issue. If we build an HIE correctly, and build it to be able to handle any disparity, is there any more need for HIE 2, since in theory HIE 2 will be able to do the same things as HIE 1?  Let us extend this same thinking from HIE 1 through HIE 500. At some point—irrespective of certain technical issues—can it be concluded that the total number of HIEs needed to move ones and zeroes is one?

Other than the redundancy and expense of building a few hundred things that each perform the same function, the real problem of having multiple HIEs is that each new HIE greatly increases the complexity of moving a personal health record from point A to point B. If HIE 2 is the same as HIE 1, we do not need HIE 2. If the two HIEs are not alike, when we try to transport a personal health record from a patient in HIE one and move it to a doctor in HIE 2, the disparity created between the two almost requires a new HIE to resolve the problem. We will have infinitely compound the complexity of moving ones and zeroes by deploying 500 HIEs and hundreds of thousands of healthcare providers and a few hundred million patients, and we have designed quite a mess.

And why does the mess exist? It exists to move those same ones and zeroes we were moving quite nicely by the HIE we built. One can argue that scale may create its own design issues, but those issues do not make this idea dead in the water. Issues of scale are solvable; those of compounded complexity are self-imposed due to an overzealous design.

The proposed way to solve the upcoming problem of compounded complexity is to build the National Health Information Network, the NHIN. We need the NHIN to act as a super HIE, to remove the disparities that result from having multiple disparate HIEs.

Adding further unwarranted complexity to the multi-HIE model is the fact that each HIE has resulted in several hundred providers designing and retooling their healthcare IT systems to adapt to these anomalous HIEs.

Sometimes the most difficult solution to envision is the least difficult one to implement.

 

ICD-10: the true cost of having no experience

Posted by

0

The thing I like least about flying has to do with my control issues; someone else controls the plane and there is nothing I can do about it.  The pilot’s voice seemed to say “Put yourself in my hands.”  Like nails, I thought, like carpentry nails.  As a result I find myself creating caricatures of the people seated around me—I can choose do that, or I can choose to rush the cockpit and wind up being a two-minute feature on CNN with the other passengers asking how I got the gun on board.

I get as excited about someone sitting next to me as a dog does about a new flee crawling around on his hind quarters.  Picture the woman who sat next to me.  I was tempted to ask her how she could dress like that but, I worried she would reply “From years of practice.”  She looked like a disaster victim might be expected to look—a tattered, grey wool blanket draped over her shoulders.  The only thing missing from the scene was a reporter standing over her asking her how she felt about the plane crash.  Her face was strong and equine, with a straight nose that veered slightly leeward.  As she gnawed angrily at her gum with her front teeth, her fingers gripped the armrests so tightly I could foresee the need to call a flight surgeon upon landing to amputate her arms at her wrists.

Anyway, that was my flight.  Yours?  Here’s the segue.

Picture the makeup of the attendees of your last meeting (circle the topic that best describes its purpose; EHR, Meaningful Use, ICD-10).  As I look around the conference table, sitting directly across from the bagels is Jackie.  Jackie has been a member of the IT team since the invention of punch cards.  Bill still prefers to use the “portable” Compaq suitcase PC he was issued during the time the US was playing Reggae hits over loudspeakers trying to coax Manuel Noriega out of Panama.  And Mindy has stormy eyes—sorry about that—Mindy has a coffee mug collection acquired at the going away parties for the prior seven CIOs.

Our Lady of Perpetual Billing’s hospital information technology A-team is waiting to see exactly what type of fertilizer is about to be loosed upon the windmill of their little shop of horrors.  They run a taught ship; nothing slips by them, and nobody can match their job performance.  The last unpaid claim was six years ago, and their efforts have made patient satisfaction so high that the hospital cafeteria’s reservations are booked solid through year end.

It is usually good to have experienced people.  People with twenty years of experience.  Is it twenty years of experience or twenty in one year’s worth of subject matter?  My son has three years of Pokémon experience which makes him an expert on all things Pokémon.   This turns out to be a pretty valuable skill as long as the conversation stays on point.  Unfortunately, being an expert on Pokémon does not translate as readily as he would like me to believe to other areas requiring his attention, areas like cleaning his room.

So, let’s get back to the issue of Jackie, Bill, and Mindy, and our collection of three IT projects.  We can all agree people with their level of experience are very good at what you need them to do, in fact, they are probably irreplaceable.  They know what to do from the moment they enter the building until the moment they leave.  They are in their comfort zone, even though the hospital may not be in its.

Somebody has to work on EHR, Meaningful Use, and ICD-10.  Do you pick people with twenty years of one-year experience?  You may not have a choice.  Twenty years of one-year experience may be the worst kind of experience to add to your team.  It is a given that nobody in your organization is pushing around a wheel barrow full of Meaningful Use or ICD-10 experience.

I spoke with the CIO of a large hospital and listened as he described the hospital’s ICD-10 initiative.  I did not have the heart to tell him that the use of the word “initiative” was overly ambitious.  The initiative was little more than a meeting of a half-dozen “experienced” people; people from operations, finance, and IT.  People who were very good at their jobs—naturally, they had been doing them for…say it with me…twenty years.  One of the CIO commemorative coffee mugs sat on the conference table.

These meetings generally begin and end with unblemished legal pads sitting in front of each participant.  Why?  Let us explore that question for a minute.  The group’s charter is to figure out what the hospital needs to do to be HIPAA 5010 ready by the end of 2011, has to be ICD-10 compliant by the end of 2012, and has to determine what it will cost and what resources will be needed.

Suppose that is your charter, or the charter of someone in your hospital.  How will those with twenty years of one-year experience help you?  What is the first thing you need to do?  What is the second?  What should the group be doing two weeks from Tuesday?

Maybe the best thing to write is “We do not know how to do this!  We need help.”

 

EHR: When you are in a hole, stop digging

Posted by

2

 March 21, 2011 07:05

I was thinking about the time I was teaching rappelling in the Rockies during the summer between my two years of graduate school.  The camp was for high school students of varying backgrounds and their counselors.  On more than one occasion, the person on the other end of my rope would freeze and I would have to talk them down safely.

Late one day, a thunderstorm broke quickly over the mountain, causing the counselor on my rope to panic.  No amount of talking was going to get her to move either up or down, so it was up to me to rescue her.  My total amount of rappelling experience was probably only a few more hours than hers.  Nonetheless, I went off belay, and within seconds, I was shoulder to shoulder with her on the face of the cliff.

The sky blackened, and the wind howled, raining bits of rock on us.  I remember that only after I locked her harness to mine did she begin to relax.  She needed to know that she didn’t have to go this alone, and she took comfort knowing someone was willing to help her.

That episode reminds me of a story about a man who fell in a hole.  The man continues to struggle but can’t find a way out.  A CFO walks by.  When the man pleads for help, the CFO writes a check and drops it in the hole.  A while later an EHR vendor walks by—I know this isn’t the real story, but since I am the one writing I’ll tell it the way I want.  Where were we?  The vendor.  The man in the hole pleads for help and the vendor pulls out the contract, reads it, circles some obscure item in the fine print, tosses it in the hole, and walks on.

I walk by and see the man in the hole.  “What are you doing down there?”  I asked.

“I fell in this hole and don’t know how to get out.”

I felt sorry for the man—I’m naturally empathetic—so I hopped into the hole.  “Why did you do that?”  He asked.  “Now we’re both stuck.”

“I’ve been down here before” I said, “And I know the way out.”

I know that’s a little sappy and self-serving.  However, before you decide it’s more comfortable to stay in the hole and hope nobody notices, why not see if there’s someone who knows the way out?

Drafting someone to sort out your EHR problems doesn’t do anything other than add another name to the org chart.  Work plans and org charts are very similar in one key respect—they both have a lot of blank space between the all of the boxes.  And, that is where a lot of the problems arise—in the blank spaces, spaces that have to do with planning, process improvement, and change management.

Everyone is implementing an EHR, but not everyone is doing it correctly.  There is a very special set of IT skills needed to meet the challenges of a failed or failing project.  People with those skills are disaster recovery specialists.  They are the people who jump in the hole with you because they have been in the hole before and they know the way out.