Dr. More referenced my site and has an excellent summary of the reasons why healthcare IT projects "go bad." It is clear this is an international phenomenon unrelated to the type of healthcare system (e.g., socialized vs. private sector model), and that the root causes are similar.
The reasons cited by Dr. More from his website are (emphases mine on the key phrases):
1. Many believe a key point is that managerial and organisational instability is a major cause of failure. I agree this is really important and, indeed, when one reflects on the Public Health Sector it is really a relative rarity to have an Area Health Service CEO or CIO serve out their full five year contract. This flux is due, in part at least, to a combination of Government and Ministerial changes, changing policy priorities, some being perhaps promoted beyond their capabilities and the unexpected events that precipitate management change. Conducting any significant project in the absence of continuing stable senior management support is a recipe of disaster.These reasons are well-stated. Healthcare organizations should heed them.
2. Especially in the public sector, there is often a disconnect between the managerial responsibility placed on a project manager and the freedom to act they are accorded. At times this leads to the “wrong” staff being retained in roles for which they are no longer suited, to the detriment of the project as a whole. The disconnect (and budget inflexibility) also often leads to difficulty in attracting and retaining suitably skilled staff as well as excessive delay in staff acquisition. The other problem that is almost universally encountered in Hospital projects in my experience is the “drip feed” of funds and the difficulties in getting suppliers paid. More than once I have seen competent project managers just resign in disgust when they realise they have neither the spending authority, money or the staff to deliver the project they are required to make happen.
3. Because executive health-care management are often uncomfortable regarding many aspects of Health IT, frequently associated with a fairly limited understanding of what is required, at an executive level, for project success, the quality of project sponsorship and support is less than is needed. Senior executives, like everyone else, prefer to stay within their “comfort zone” and, if the Health IT project is not within that zone, real difficulties are almost inevitable. The project manager has a difficult responsibility to carry the project sponsor along on the journey, and to make it clear what they must do for the project to be a success on their watch!.
4. Clinicians inevitably see a new system as a very low priority in their “caring for their patients” activities. This will lead to all sorts of difficulties with change management, training and effective use of a new system, unless both executive management are fully committed and real “clinician” evangelists and enthusiasts are recruited to work with their peers.
5. Involvement of all relevant categories of clinicians in the selection and later configuration of systems is crucial. The clinicians really have to be confident the system will work for them and be convinced of its value and utility or the project will be at extreme risk before it even starts.
6. There is a real tendency to underestimate the complexity of and the effort required to implement say a new laboratory or patient management system – to say nothing of clinician facing systems such as Computerised Physician Order Entry or Computerised Nursing Documentation which involve virtually all key staff changing the way they work. Careful planning and an really adequate emphasis on education and change management are vital as is developing real clinician ownership of the project.
7. It is clear that all organisations need to develop organisational competence and teamwork with Health IT. I think the best way to do this is to choose one or two easily “doable” projects and get them done on time and within budget. Only once this capability is proven should an organisation try the larger and more complex implementations. Success, as they say, builds on success.
8. It is clear that when implementing systems in hospitals size really does matter. It is a relatively straightforward process to put basic systems in a 100 bed regional hospital in 3-6 months with very little difficulty. The 1000 bed tertiary teaching referral hospital is a horse of a totally different colour. The budget is likely to be in the millions, the complexity of what is needed much higher and the work practices more entrenched. All this means both risk and duration are much higher. Additionally these organisations cannot be fed a ‘one size fits all’ solution. The systems that are deployed must not only be flexible but be flexibly implemented in consultation with ALL involved.
9. It is vital to work hard to develop an open and frank relationship between the system vendor and the organisation which is implementing the new system. No contract will prevent a disaster but work on ensuring a constructive, frank and balanced relationship will make a huge difference.
It was recently once again driven home that this does not occur often enough, even in very large medical centers. I’ve left the Director of the Institute for Healthcare Informatics position I’ve held for the past few years and am now adjunct faculty. The reasons why are at this link on the Healthcare Renewal blog at "Medical Informatics still round peg in square hole?"
As a result, I'm seeking applied Chief Medical Informatics Officer (CMIO) positions once again. I just completed two full rounds of interviews at a prestigious hospital system that recently experienced a decline in its clinical quality stats. The organization feels the quality stats themselves were inaccurate, in part due to lack of good healthcare IT.
From what I was able to gather, their leadership was displeased. Board members were seasoned executives from a heavy-manufacturing industry that is extremely dependent on information technology and concurrent supply chain data. These executives ordered the organization to move quickly on EHRs.
The organization is thus planning to implement EHRs for a large number of skeptical physicians, most of whom are not employed by the hospital, plus integrated systems drawing on EHR data to automate quality reporting to regulatory agencies and to support ongoing, funded clinical drug and device trials.
I was interviewed by the usual mix of clinician eager adopters, clinician skeptics, knowledgeable executives, skeptical executives who knew little about clinical IT, IT personnel who seemed overconfident, and those who were clearly frightened by the prospect of being held accountable for a project of this magnitude. In the end, I did not get the position due to the organizational leaders being adamant the incumbent CMIO needed to also practice medicine.
I'd thought this issue had been settled after the first round of interviews, leading to the invitation for round two. This line of questioning was revisited, however, in round two in a group interview setting. The group interview was attended by a number of people with whom I'd already discussed this issue via individual meetings in round one. This suggested my time was being wasted and was rather annoying, especially considering that I'd had to fly cross-country not once but twice to an organization not in consensus about a very basic hiring requirement. I asked myself what other major executive disagreements about the role might exist that were not being expressed. (One fundamental principle I'd penned a decade ago in an essay "Ten critical rules for applied informatics positions: what every CMIO should know" was the importance of executive consensus.)
It is not as if such a role would have ample free time where the incumbent would be idly sitting at their desk unless this time were absorbed seeing patients in the clinic. It is my opinion that healthcare organizations requiring that a CMIO practice medicine part-time either believe the CMIO role is not truly strategic and critical, or they believe the task at hand for the incumbent is easy and can be accomplished essentially by a part-time CMIO.
Ironically, I was told during my interviews that a CMIO they'd hired a few years ago had left, in part due to being overextended. I was also told that some of the clinical IT problems I'd solved as a CMIO in the past were problems this organization had not been able to solve around the same time period.
Regarding underestimation, this organization appeared to have little idea of the difficulties they are getting into. This is even after I, an experienced ex-CMIO, tried to explain this to their leadership, among other methods via recommending my web site on health IT failures.
I should also point out that another indication that this organization didn't know what they didn't know came quite early. I was informed that the organization had selected their EHR vendor prior to seeking a medical informatics expert. This implies they really did not understand what a medical informatics specialist does and can do, which is far more than being a tactical "EHR implementation assistant." It also left open the possibility that the selection process may have been "biased" (e.g., via IT domination of the process, back room dealing, etc.)
If this was the case, the risk is that the informatics incumbent might find themselves performing "damage control" to force-fit a square peg into a round hole, i.e., forcing an EHR product with suboptimal "fit" down the throats of (appropriately) resistant clinicians.
I've been there, and done that. It is not rewarding and I actually had decided not to take the risk, even before the organization decided they wanted an (effectively) part-time CMIO who also saw patients.
What more can I say?