I am going to leave the CPOE topic this week. But, it was a good week to point out that our industry is pursuing CPOE without the proper planning or evidence that it will improve patient safety. So, I will move to the other phrase maxing out the “hype meter.”

I have a new rule. I am forbidding anyone to discuss “Electronic Health Records” unless they can describe three clear expected benefits of an EHR system and how the EHR will accomplish that. Furthermore, “Going paperless” does not count as a benefit.

Luckily, we are pretty much past that phase at Affinity. Certainly at the executive level. I still have some others ask me when I am getting an Electronic Health Record. My standard response is: “You are not allowed to use that phrase.”

I see some CIOs pursuing Electronic Health Records without any vision regarding what they want to accomplish. This is usually in the form of a CIO sending an email to a CIO list-serve asking if anyone has a EHR RFP. There is so much wrong with that request I don’t know where to begin. It is like asking if anyone has a good recipe. Well, I have great recipe for a Green Bay Packer tailgate, but if your medical staff is expecting a 5-course meal you are both heading for disappointment.

I truly believe folks need to develop their own functional requirements. At least the core requirements. But, that should only take place once they have developed a common vision with the leadership and medical staff. Once you know what you are trying to accomplish, then you can decide what features/functions you will need.

We have put together an Electronic Health Record manifesto. I love it, but I love my own cooking. I will post it later in the week to continue the EHR theme.

If CPOE was such a promising technology to improve patient safety, why has the Leaprog Group failed to deliver its CPOE evaluation tool? In November of 2001 Leapfrog promised to collaborate with FCG to deliver an evaluation tool in 2002.

The first version of the CPOE evaluation tool may still be coming. In mid-2005 Leapfrog promised that the tool would accompany the next survey. I believe that is due in April 2006. This is over THREE years after it was initially promised. Even my worst projects are not delivered this far off schedule.

Why does Leapfrog expect 100-bed community hospitals to implement technologies that it can’t seem to master, even with all of the financial backing of its members / funders and the intellectual capital of the country’s largest healthcare IT consulting group (FCG)?

Was Leapfrog premature in suggesting that CPOE was an immediate opportunity to improve patient safety? Sure CPOE is great in theory, but then again, so are flying cars.

I do appreciate that Leapfrog has provided a definition of true CPOE, which they say includes three elements:

1. Assure that physicians enter at least 75% of inpatient medication orders via a computer system that includes prescribing-error prevention software;
2. Demonstrate that their inpatient CPOE system can alert physicians of at least 50% of common, serious prescribing errors, using a testing protocol now under development by First Consulting Group and the Institute for Safe Medication Practices [this is the missing evaluation tool]; and,
3. Require that physicians electronically document a reason for overriding an interception prior to doing so.

Despite this clear definition health systems continue to claim that all kinds of things are CPOE, like clinic e-prescribing systems. Ambulatory CPOE is an oxymoron.

Most CPOE implementations that I see don’t even try to tackle 2 and 3. For that matter they can’t meet the threshold of the first criterion. What is the value in that?

And even though the Leapfrog survey instructions are clear there are many instances where hospitals submit CPOE claims that are, at best, overly ambitious. It will be interesting to see how many hospitals report true CPOE success in their 2005 survey after reporting that they were a year away from full CPOE in the 2004 survey.

Update: a few hours after posting this I was heading to the bathroom (I know, TMI) and I grabbed whatever was on top of my mail pile. That turned out to be the HIMSS 2006 materials. As I was flipping through it I saw that FCG and University of Pennsylvania Health System will present the benefits of the CPOE Evaluation Tool (Education Session Number: 58). Perhaps Penn is the beta site.

It appears, by the title of the seminar, that the intent is for the tool to be available before HIMSS. So, Leapfrog and FCG may be making some headway. Then again, since the HIMSS submission deadline is in May this may have been wishful thinking.

I have sat through a few presentations with titles such as “What Went Wrong With Our CPOE Implementation.” A recurring theme in those powerpoint slides is a perceived “lack of strong senior managment support.” In my opinion, this is an incomplete analysis.

Is it really the case that senior leaders are too lazy or uncaring to champion these new information systems? I don’t think so. I think the trouble lies a little deeper. I suspect the scenario goes like this:

1. The project folks go to senior management to dsiscuss adoption problems with the hope that they will “force” the physicians to use the system.
2. The CEO or COO approach the top admitters to discuss the situation.
3. The physician responds by stating that the system sucks and s/he would rather practice at the competing hospital than use the system.

Is it really strong senior leadership that would turn away a significant amount of patient revenue and jeopardize the ability to fund the mission of the organization?

I think the real issue is that the planning and anlysis failed to ask some real hard questions about the risk of physician resistance and the limited options the organization may have in that event.

I also think that usability has to be a primary focus and it may be that most products are not to a state that they are easy to use.

Hospitals with hospitalists and teaching staff have an advantage. But even those will have a large number of physician customers that can take their business elsewhere.

I believe a key to a successful IT project is ensuring that it has a clear business purpose. In my opinion, this works best when the project is being lead by someone outside of IT that has a stake in the long term success. At Affinity we strive to assign a non-IT Project Champion to each project and make them accountable for the results.

In an earlier post regarding statements of work someone commented: “In my view a SOW included the commitments (read “promises”) that the internal personnel are making to each other. I submit that it is MUCH more important to make the promises to ourselves before we make them to vendors! “

This is my view too and I appreciate that I am not alone. The first draft of that internal agreement is developed by the Project Champion using our Project Champion Agreement.

Feel free to borrow from this liberally. Please tell me what you think.

Most managers think an IT project follows this sequence:

• Demonstrations
• Software Acquisition
• Implementation

We have to beat this out of them. OK, we need to educate them. But we need to beat the vendors who reinforce this mindset.

I go ballistic when I am invited (along with a list of others) to attend software demonstrations for the purpose of choosing some new computer system. To accomplish what? Much more time needs to be spent setting goals and criteria for choosing said system (if it is needed at all).

Just as importantly, we fail to spend time putting the plans together before the software is purchased. One can easily spend 6 months planning an average size IT project before the software even arrives. There are processes to re-design, interfaces to spec, conversion extracts to write, training plans to develop. Why start this after the software contract is signed? So the software can sit on the shelf and the vendors can spend our money while we do the prep work?

Every project is going to be different. But a better model is:

• Develop goals, success metrics and required features/functions to achieve the goals
• Demonstrations
• Software Selection
• Intense, detailed planning
• Acquisition
• Implementation
• Success

In my years as a consultant I observed that most projects failed to accomplish their business goals. As a CIO one of my most important charges is to keep projects from failing. My observation is that projects fail for two reasons.

Firstly, projects fail because they don’t have any clear business goals. These projects are easy to spot because they typically begin with someone coming to me and asking to buy a computer system. When the computer system is the focus, and not solving a particular business problem, then we are in trouble (see the Barbie Syndrome post).

But even when project goals are clearly defined and success measures are in place projects can fail. This typically happens when the project becomes so burdensome the focus changes to just getting the project done.

In my consulting engagements I remember attending meetings toward the end of a long project where the clients were trying to figure out what went wrong. Their observation was generally that over time they lost sight of the project goals because there was too much work.

I now realize that this is not something that happens gradually. Instead, there is a point in time when an in influential member of the project or senior management will state that it is OK to forget the goals and just get done. It turns out that this happens as fast as a “click.”

Of course the best way to guard against this is to develop plans that accurately estimate the resources and total effort. This is easier said than done. Most organizations are terrible project planners. There is always a push to buy the software and get started.

Today, If someone ever asserts that it is time to let go of the business goals I will say “click” . Most of the people here know what that means. If not, they will by the end of the meeting.

I know Cam Jansen does the “click” thing too, but I think I did it first.

Like many, we are trying to automate the release of some records to patients and parents/legal guardians. Unfortunately, MEDITECH (and every other vendor I know) do a poor job of tracking who has legal access records. There is no way to setup an electronic linkage to say one person (identified by a key field) has legal acess to another person’s records.

Even if that existed it really is not granular enough to manage the complexities or HIPAA and other privacy laws. For example, in Wisconsin, children 12 and older have additional rights relating to behavioral health, reporoductive health and HIV status. All of this is tracked manually because there is no way to manage this with the systems we have.

Ideally a system would allow a child’s record to be linked to legal guardians. Also, there would be the capability to create additional linkages to support a person’t legal right to provide access to their spouse.

As we make health information available to people over the web, parents will also want to see their children’s records. Unfortunately, we don’t have a systemized way of identifying their children. We know which babies were born to which mothers, but even that falls short since the child could have gone to an adoptive home.

Of course the computer system changes to link patients with legal guardian would need to be followed with process changes in the registration and medical records areas.

In my 10+ years as a CIO it is painful to see how many IT purchases turn into shelfware. It is difficult to keep management focused on realizing the benefit of investments made.

I believe this is human behavior. I have tried to create an analogy so our business leaders can see this behavior in ourselves. In my attempt to change our culture I have begun to preach about the “Barbie Syndrome.”

As a father of two girls I have observed that when they are in a toy store they seem to forget the closet full of Barbies® and accessories back home. The Barbie on the store shelf is always more desirable than the one in their closet. Like those girls, we seem to think that the systems we don’t own are much more appealing than those we already own.

Unlike those Barbies, new systems are not ready to use out of the box. These systems require a great deal of coordination during implementation to ensure they begin useful life without negatively impacting operations. Just as importantly they require a great deal of effort after implementation to ensure that they provide the benefits that were envisioned when they were purchased.

I am not looking down on my co-workers. I am guilty of this as well (and there isn’t anyone there to remind me that I am under the influence of the Barbie Syndrome). I have purchased a couple of systems over the last few years because I thought they would be the quick answer to a problem. Of course it was just software and I still had to do all of the hard work I was trying to avoid.

Too often we are lured to purchase new systems, somehow forgetting the closet of systems that we already own that are awaiting our attention.

I realize I am not using the word “syndrome” properly. But the phrase reminds me of the Pepsi Syndrome skit from Saturday Night Live, so I am sticking with it.

Truthfully, I have always enjoyed the perks of being a CIO. Having the second most capital to spend (behind construction) gets you lots of attention.

One way that vendors show their attention is to take you some place to talk business. As a CIO you have lots of opportunities to eat good meals and then get a case of short arms when the check arrives. Ethically I don’t have a problem with this, if it isn’t abused. I am probably treated to 10 or so vendor dinners a year. Sometimes it is a burger at the pub, but often it is a steak at Lombardi’s.

Some of the offers I receive are unbelievable. I don’t understand how any CIO can ethically accept some of the junkets that we are offered. Recently, I received an invitation that tops them all. Avaya (the telephony vendor) sent me a letter from the Chairman and CEO offering to fly me and a guest to Germany to watch the World Cup. This was the real deal. As the letter states (see attached) this is going to be a first class junket. Just, not for me. The mailing alone was impressive. The letterhead was the best paper I have ever seen (living in the Paper Valley I notice things like that).

As I get more offers I am going to post them here to show folks the lengths a vendor will go to get cozy with a CIO. If word gets out I suppose I will receive a lot fewer offers.

This entry was recently featured in an article by SearchCIO.com.

I could spend all day long participating in phone surveys. So, I don’t usually do any. More and more the surveyors are offering some incentive like a gift certificate or a donation to the hospital’s foundation. I appreciate that they value my time, but that generally isn’t going to change my mind.

I participated in a HIMSS Analytics survey today. This is the first survey that I have been subjected to in over a year. I consider HIMSS Analytics to be a respectable name, but this was a disaster. The surveyor had no understanding of the topic and had a difficult time reading her script. Worse, the questions were very poorly constructed.

They asked me which database platforms I used (SQL Server and MEDITECH MAGIC). Then they proceeded to ask me to rank other DBMS platforms on a number of different criteria (reliability, manageability, performance, etc.). Well, I don’t use those – so why would I have an opinion? The survey also asked me to rate the DBMS of my top three clinical applications. These are all MEDITECH applications so I answered the same questions three times.

I suspect that the survey was sponsored, I would guess by Cache.

One third of the way into the survey I lost respect for the methodology and began answering questions while reading email. That survey won’t be worth the paper it is printed on.

One more thought about surveys, I would much rather complete an online survey than a phone based survey.