For an outside consultant, one of the most challenging aspects of helping an organization through an implementation is dealing with the attitudes, expectations, and beliefs of stakeholders. In my experience, turf battles and organization politics cause more project failures than technology issues. More often than not, stakeholders bring a range of backgrounds and viewpoints to the table, and these factors significantly affect a project’s likelihood of success.
While at UAB, I taught a course on clinical information systems that focused on how organizations select and implement systems. Students were required to select an organization (no size requirement) and perform a detailed analysis of its approach to system procurement and implementation. This included mandatory site visits and interviews with key clinical, administrative and technical stakeholders. During my time as course director, a few dozen sites were analyzed in this manner giving me an opportunity to interact with a range of clinical, business, and IT professionals.
As a result of these interactions, I noticed that there was a well-defined set of deeply-held viewpoints about IT and its use in health care organizations, which often affected how organizations approached IT projects. Since leaving UAB, my experiences as a consultant have mirrored those of my teaching days. The same attitudes and viewpoints are prevalent in many healthcare organizations and are independent of organizational size. Naturally, I was intrigued to discover an article that acknowledged and explained my observations.
Health Information Technology: Fallacies and Sober Realities by B.T. Karsh, et al. discusses what the authors refer to as fallacies related to HIT utilization.
The ‘Risk Free HIT’ Fallacy
Many designers and policymakers believe that the risks of HIT are minor and easily manageable. However, because HIT is designed, built, and implemented by humans, it will invariably have ‘bugs’ and latent failure modes.
The ‘HIT Is Not a Device’ Fallacy
An off-shoot of the ‘risk free HIT’ fallacy is the belief that HIT can be created and deployed without the same level of oversight as medical devices.
The ‘Bad Apple’ Fallacy
It is widely believed that many healthcare problems are due primarily to human (especially clinician and middle manager) shortcomings. Thus, computerization is proposed as a way to make healthcare processes safer and more efficient. Further, when HIT is not used or does not perform as planned, designers and administrators ask, “Why won’t those [uncooperative, error-prone] clinicians use the system?” or “Why are they resisting?” The fingers are pointed squarely at front-line users.
The ‘Use Equals Success’ Fallacy
Equating HIT usage with design success can be misleading and may promulgate inappropriate policies to improve ‘use.’
The ‘Learned Intermediary’ Fallacy
One of the drivers of the ‘risk free HIT’ fallacy is the ‘learned intermediary’ doctrine, the idea that HIT risks are negligible because ‘the human alone ultimately makes the decision.’
The ‘Messy Desk’ Fallacy
Much of the motivation for HIT stems from the belief that something is fundamentally wrong with existing clinical work, that it is too messy and disorganized. It needs to be ‘rationalized’ into something that is nice, neat, and linear.
The ‘Father Knows Best’ Fallacy
While HIT has been sold as a solution to healthcare’s quality and efficiency problems, most of the benefits of current HIT systems accrue to entities upstream from direct patient care processes–hospital administrators, quality improvement professionals, payors, regulators, and the government.
The ‘Field Of Dreams’ Fallacy and The ‘Sit-Stay’ Fallacy
The ‘field of dreams’ fallacy suggests that if you provide HIT to clinicians, they will gladly use it, and use it as the designer intended. This fallacy is further reinforced by the belief that clinicians should rely on HIT because computers are, after all, smarter than humans.
The ‘One Size Fits All’ Fallacy
HIT cannot be designed as if there is always a single user, such as a doctor, working with a single patient. The one doctor-one patient paradigm has largely been replaced by teams of physicians,nurses, pharmacists, other clinicians, and ancillary staff interacting with multiple patients and their families, often in different physical locations.
The ‘We Computerized the Paper, So We Can Go Paperless’ Fallacy
Taking the data elements in a paper-based healthcare system and computerizing them is unlikely to create an efficient and effective paperless system. This surprises and frustrates HIT designers and administrators. The reason, however, is that the designers do not fully understand how the paper actually supports users’ cognitive needs. Moreover, computer displays are not yet as portable, flexible, or well-designed as paper.
The ‘No One Else Understands Healthcare’ Fallacy
Designers of HIT need to have a deep, rich, and nuanced understanding of healthcare. However, it is misguided to believe that healthcare is unique or that no one outside of the domain could possibly understand it. This fallacy mistakes a condition that is necessary for success (i.e., the design team must include clinicians in the design process) from one that is sufficient (i.e., only clinicians can understand and solve complex HIT issues).
Here’s a suggestion. Read over this list and keep it in mind when you attend the next meeting of your HIT implementation group—especially if the group has been formed recently. Pay attention to the arguments, pro and con, for whatever HIT system is under consideration. I guarantee that at least 50% of the fallacies mentioned by Karsh and his co-authors will be referenced in some way during the meeting.
As a consultant, I have found that if one can determine which viewpoints a stakeholder is particularly fond of, that knowledge can help when trying to reconcile differences among the group. If you are chairing an implementation committee, you may find this strategy helpful.
Dr. Karsh and colleagues have created an excellent list of pet beliefs that are all too common in healthcare organizations. Unfortunately, they also often factor into the success of HIT projects. At best, referencing these fallacies during IT-related discussions could lead to a more enlightened dialog among organizational stakeholders; at worst, well – duck!