Common Examples of Healthcare IT Failure

This is a story about how a medical informatics professional moved a failed project to success via reliance on fundamental principles of medical informatics and clinical medicine itself.

The chief and clinical staff of a busy invasive cardiology (cardiac catheterization) lab at a large American tertiary care hospital, responsible for a significant percentage of the hospital's revenues, desired a data collection system to improve performance and outcomes, perform benchmarking, reduce dictation, increase efficiency of clinical communications, and end expensive inventory spoilage or risky shortages.

The hospital's business-computing department (i.e., management information systems or MIS) was engaged to assist the cardiac catheterization lab in this information technology need. This department’s clinical expertise was nil.

From the very start, the project was poorly managed by MIS and by senior hospital executives.

The MIS deparment spent almost two years going through analysis, market investigation, K-T decision grids, and other business "process" before deciding on a product to purchase. What they were doing during this time is unclear, as there are very few vendors offering products for this environment. In-house development was ruled out by MIS as unnecessary and not consistent with an MIS policy of "turnkey solutions only," despite several senior cardiologists feeling that customization would be critical. Such one shoe fits all, business computing-oriented thinking is symptomatic of a lack of understanding of clinical medicine that's often found in healthcare MIS departments.

After purchase, the vendor product sat unused for almost a year before operationalization was considered by MIS. When it was finally decided to implement the package, gross underestimation of the resources needed resulted in only 0.75 FTE's assigned. Even worse, the MIS person chosen had no experience working in tough, high-volume, critical care areas. The project was, in fact, doomed to fail even before it even got off the ground.

A Steering Committee was initiated, led by a new, competent cardiac administrator who was unfamiliar with information technology. It soon became apparent that the MIS personnel did not understand the clinical environment and culture of a cardiac catheterization laboratory. MIS was adamant that the vendor product should not be modified, an "appliance operator" mentality, even though the clinicians wanted the data and workflow components of the package to be adjusted to their busy clinical environment and customs (rather than the other way around).

Conflicts began. The MIS department began to blame the physicians for being "non-cooperative" with them, stubborn, unable to finalize decisions about the package, and responsible for lack of project progress. The cardiac administrator was blamed by senior officials for "not controlling the doctors", representative of this organization's somewhat unreasonable attitudes towards its lifeblood, its clinicians. (Unfortunately, to use a medical metaphor, while this genre of negative behavior by a healthcare organization towards its clinicians may "feel good" to executives in the short term, in the long term the consequences are usually deleterious to organizational health.) MIS insisted that the cardiac administrator take "ownership" for the project, and assume the role of clinical champion. The cardiac administrator tried to understand the issues, but without expertise in information technology was highly dependent on the MIS personnel for guidance on any technical issue. MIS itself could not provide significant guidance as they were in over their heads in such a clinical setting.

The clinicians began to realize that MIS had greatly understaffed the project, and that MIS resources, skills, and understanding of the environment were inadequate for the job. Further, their requests for MIS to perform customizations of the application to match their culture and environment were met with jargon-heavy reasons why it "couldn't be done".

The MIS department continued with its "template delay, false-start, peek-a-boo, tag-you're-it" games (as the administrator described it) with the doctors and cardiac administrator. As a result, the attempted install in the cath lab went so poorly, and was so misaligned with needs, expectations, work flow, and the tremendous patient responsibilities, that the demoralized and frustrated cath lab staff demanded in overtly hostile tones that the MIS people "get out of our cath lab."

In a common hospital IT politics ploy, blame for the project paralysis and failure was shifted by MIS to the cardiac administrator and clinicians, using language about 'process', 'ownership', 'nurturing', 'mentoring', 'feelings', and other impressive-sounding but shallow and almost mystical puffery and rhetoric. This made the invasive cardiology clinicians, with a culture characterized by directness and action, even angrier.

An outside consultant was brought in for several days, but could not resolve the difficulties between MIS and the clinical staff.

A medical informaticist was then hired, albeit as an "internal consultant” to the MIS department and lacking executive presence and direct control of resources, after a senior executive found out about the existence of such specialized personnel. (This organizational structural choice itself was perhaps symptomatic of the problems that led to the project failure, that is, an inversion of essential healthcare IT leadership roles whereby business IT personnel operate far outside their competencies.)

The informaticist first asked to see what had been installed in the cath lab by MIS. The informaticist found workstations running the application under Windows 3.1, an unreliable platform especially unsuited for critical care environments, because "Windows NT and other OS's such as UNIX were not supported by MIS." When shown a short demo of data entry by a nurse after a cardiac cath case, the workstation crashed, displayed a "general protection fault" error and hexadecimal debugging data. It had to be rebooted, with resultant time and data loss.

The informaticist asked the nurse about the crash and was told it happened frequently, up to several times per day per workstation. When the informaticist asked if MIS had requested a detailed log be kept of the crashes and error messages to help resolve the problem, the answer was no. MIS felt diagnosis and repair was the vendor's responsibility. When the informaticist asked the nurse exactly what had been explained to clinicians about the crashes, the nurse replied that cath lab staff had been told by MIS "don't worry about it, you can't understand it, we'll make it better."

The informaticist remembered, from medical school and residency, being told never to say such a thing to patients as it was considered inappropriate and too paternalistic in the modern age of medicine, especially with the elderly. This was an ironic and somewhat perverse scenario for a critical care area, the informaticist thought.

The informaticist set out to correct the problems, although the path ahead proved challenging even with informatics skills. Workstations were asked to be changed to NT to ensure reliability. The informaticist was first told that the application would probably not run under NT, and that it also needed "RAID disks" (an intimidating buzzword to must physicians) to run. The informaticist replied that RAID, a hardware-based continuity and disaster recovery measure, was an operating system issue, not an application issue, and that testing the application under NT would be easy. Testing would end the need for speculation and debate, he also said. The informaticist requested that two ordinary business PC's be set up in a test environment on a table, one PC to run the server, and the other to run the client under NT to test compatibility.

Upon realizing that this doctor was technically knowledgeable, MIS moved the production application to NT in a few days and thereafter it ran quite reliably. Under the informaticist's insistence, against political resistance from MIS and operations who seemed more concerned with appearances and "process" then with supporting the cardiologists ("results"), the staffing was increased. Four had been requested, and a compromise of three was reached. The informaticist was able to hire a new MIS manager based on the informaticist's beliefs about proper abilities, skill set, insights, and personality fit (e.g., a "can-do, when do you want it?" attitude) in the dynamic cath lab environment. This new manager had leeway to act independently to a large degree from the corporate MIS department. The new MIS staff in the cath lab were able to function as a decentralized, more flexible, local "island" of MIS support for the cardiologists.

The informaticist first created a collaborative and participatory work environment between the new MIS cath lab personnel, the cardiac administrator, and the cardiologists, a non-traditional methodology in MIS but crucial for clinical computing settings (see Participatory Design of Information Systems in Healthcare, Sjoberg C, Timpka T: Journal of the Amer. Medical Informatics Assoc. 1998;2:177-183). A highly user-centric, iterative and incremental development process was also instituted, which was at significant variance to the traditional designer-centric “systems lifecycle” methodologies traditionally employed by MIS. This created considerable opposition by the MIS leadership, who seemed to view such an approach as some type of sacrilege. Such a belief, even in the face of years of failure, appeared to the informaticist to be dogmatic to the point of religious conviction, or perhaps worse. (Einstein on insanity: doing the same thing over and over again and expecting different results.) A table from Kling’s work on social informatics outlining the profound differences between user-centric (“social view”) and designer-centric ideologies is here.

Next, the informaticist jettisoned the traditional MIS approach of viewing a person's skills in using a specific database application (e.g., Oracle) as a critical factor. The informaticist identified as crucial the data modeling process for the cardiologist's needs. This process has very little to do with software or computer science and much to do with medical informatics. The finest technical expert in the world in database development systems such as Oracle, client-server tools, etc. is not very useful in such a function, since it is a high-level cognitive function requiring clinical experience combined with medical data modeling expertise, not computer or MIS expertise. The lack of recognition of the need to partition strategic, high-level, cognitive informatics functions such as healthcare data modeling from more mundane, low-level programming and implementation tasks in clinical projects inhibits progress in healthcare and biomedical IT.

It is with amazement that informaticists such as the one in this story observe a blindness to this issue in biomedicine, including healthcare and the pharmaceutical industry. The highest levels of informatics expertise should be sought for any clinical initiative in busy clinical settings. In such settings, the data development and customization process (a largely cognitive process requiring extensive cross-domain experience) is an essential competence.

Once the critical cardiology data set and data definition issues were on the mend with the informaticist's expert assistance, the group was then able in a flexible, iterative manner to customize the application data set and work flow components, and evaluate and modify prototypes to zero in relatively quickly on a usable system. As a result, within several months regular and reliable data collection and reporting had begun. In fact, the cath lab staff began to get more involved in the customization process and the designing of reports, and started to find the process intellectually challenging, educational, and sometimes even fun.

Perhaps even more importantly, the informaticist re-framed this project from one that could be perceived solely as a negative "report-card" system about the cardiologists, to one that would enable them to meet their own data needs and interests (e.g., for research, domain-specific and new-device specialty areas, education, and other topics). In doing so, the standard vendor-supplied package was only used as a 'vehicle' or starting point for the project, while dataset customizations almost completely replaced the supplied vendor "internals". In modeling the data of such a complex field in an optimal manner, the value of the medical informatics discipline was very apparent.

Further, in operationalizing the system, the informaticist made sure that a large degree of effort went into creating tools to allow replacement of dictation, often a time-consuming process in invasive cardiology, with a computer-generated case report. A very creative, intelligent, computer science-minded programmer was carefully selected by the informaticist to code the tools to create this capability. (The informaticist here did not believe all programmers were created equal. As author Bob Lewis points out in his book IS Survival Guide, Sams Publishing, 1999, p. 247, three decades ago Harold Sackman researched the performance gap between programmers. He found that the best ones were able to write programs 16 times faster and debug then 28 times faster than those created by "average" programmers, and when they were done their programs were six times more compact and ran five times faster.) In a field as critical and complex as medicine, the need for star performers is especially acute. This is hard to detect from a resume. Informaticists who know both medicine and computing are often especially good at identifying such programmer qualities, for example through interviews.

Medical Records and transcription were also strongly involved to enhance the cardiology computer system so that addendums, if needed, could be flexibly dictated and added to the computer-generated report on a section-by-section basis. Another area requiring significant effort was automation for FAXing computer-generated reports on a timely basis to referring clinicians and to electronically send reports to a central clinical data repository for viewing at workstations in the medical center. This "value added" approach to the project, strongly supported by the cardiac administrator, proved crucial. It helped win physician support, since it had the potential to save them significant time and labor while increasing their accuracy and timely communications with referring colleagues.

The cardiac administrator, an extremely capable and forward-thinking individual, learned a lot about medical informatics and its value as a specialty, and many fine points about the innocuous-sounding but unprecedentedly difficult task of defining precise, fine-grained data to model an area as complex as invasive cardiology. Unfortunately, in the opinion of the informaticist, the cardiac administrator had become somewhat of a "scapegoat" for deficiencies of MIS and senior executives in understanding clinical computing issues, and had lost a bonus (and much peace of mind) as part of the lesson.

Postscript:
This heart center information system in its first two years of operation has allowed this organization to save well over a million dollars in cath lab operating costs, through stronger contracting, efficient equipment stocking and utilization, etc.

Despite this, in an unfortunate example of the suboptimal management that can result from unqualified decisionmaking in a discipline as complex as healthcare computing, the senior executive assigned to oversee both clinical operations and IT (despite lack of a background in IT) now refuses to allow the chief of cardiology at this hospital to sit on the organization's strategic information technology committee because the cardiologist was felt to be aggressive and uncooperative (i.e., he thinks critically and does not simply follow orders from the non-medical executive in question).

This exclusionary decision was made despite the cardiologist's now probably being the most informatics-savvy in the organization after intensive collaboration with the informaticist, who has since moved on. This has once again infuriated the cardiology staff, who are one of the largest revenue-generators for the organization amidst a sea of potential competitors and declining revenues due to recent government regulation cutting Medicare reimbursement (Balanced Budget Act). This type of executive behavior should not be tolerated in hospitals.

Further, after years of being non-helpful to this project, the same senior executive told other executives he "does not see the value of the data", that the informaticist was "way out there", and that the physicians are wasting money. This executive clearly has both feet firmly planted in the Stone Age. As was recently observed in a book about business practices, only those interested in the future build tools. Whatever they might say, those who build few tools are not interested in the future ("Building Wealth", Lester C. Thurow, HarperCollins Publishers, 1999).

This senior executive's opinions flew in the face of an evaluation by invasive cardiology experts of national prominence. These experts rated the data project "extremely important" and "an exceptional initiative" during an independent evaluation of the facilities, requested by the cardiac administrator for performance improvement purposes.

Those truly interested in improving healthcare and reducing medical errors must critically evaluate the obsolete, defective organizational structures that allow medically and technologically-unknowledgeable persons to domineer qualified, competent professionals on such data initiatives.

This story illustrates one danger to clinicians and to patient care of permitting non-clinician business personnel to take charge of clinical matters. The business personnel, often more politically-savvy, may then engage in behaviors to call attention away from deficiencies and shift blame for problems onto the clinicians. Clinicians must stand up for progressive and constructive behaviors from management on clinical information technology in the service of patients.

It should be noted that invasive cardiologists and other such subspecialists are necessarily quite tough. As one of my mentors, Dr. Victor P. Satinsky (inventor of the Satinsky clamp used in cardiac surgery, among many other things) used to say about his tough training programs, "If you don't like it, don't come." MIS personnel and executives who are unqualified or uncomfortable with the rigor required in such demanding clinical environments should find positions elsewhere, in simpler settings, rather than engage in politics that obstructs technology used to improve patient care.

Finally, in an example of the “Peter Principle” running amok, the bright cardiac services manager decided to leave the organization after being passed up for promotion, while those who had impaired this project and numerous other projects through illogical thinking, clinging to the past, and various other flavors of mismanagement (at great waste of money) received generous promotions.

It is clear this organization still has much to learn from medical informatics.