Contemporary Issues in Medical Informatics: Good Health IT, Bad Health IT, and Common Examples of Healthcare IT Difficulties
Health Information Technology Chaos: Some Down Under Get It

Why Healthcare IT Projects “Go Bad”

 

After noting some Australian hits on this web site, I tracked the hits to an entry on the Australian Health Information Technology blog by "Aus HIT Man", a.k.a. Dr. David More MB, PhD, FACHI.  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 blog are as follows (emphases on the key phrases are mine):

 

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.

 

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.


I feel this is well said.  Healthcare organizations should take heed of these observations.