Medical Informatics Perspectives on Clinical IT:
Common Examples of Project Difficulties

Scot Silverstein, M.D.

About the author
Medical Informatics and Leadership of Clinical Computing homepage

Note: This web site is an older version left online for historical purposes. The current version is at this link.

Announcing the new Healthcare Renewal blog of the Foundation for Integrity and Responsibility in Medicine, dedicated to open discussion of healthcare's current dysfunction with the hopes of generating its cures.

NOTE: An interesting collection of related articles on sociotechnical aspects of clinical IT can be seen via a PubMed search initiated by clicking on this link.

Medical Informatics Perspectives on Clinical IT: Examples of HIT Difficulties

An understanding of the complex sociotechnologic or "human factors" issues associated with any major information technology (IT) initiative is of vital importance towards project outcomes. In healthcare, strong comprehension of these issues is of paramount importance to clinical IT success and to patient safety. This author seeks to illustrate why the relative lack of attention in healthcare IT towards sociotechnologic issues prevents clinical IT from achieving the quality, cost and efficiency benefits of which it is capable.

This website focuses on the leadership aspects of clinical IT, and promotes viewpoints based on repeated obervations by this author and medical informatics colleagues of IT personnel and their non-medical management stepping outside the bounds of their expertise into roles that directly affect clinical medicine and research.

As clinical and biomedical IT becomes increasingly more complex, and as it supports increasingly complex medical science, research and practices, the number of ways that failures and mishaps can occur from errors in judgment, inadequate knowledge, mismanagement, and related factors increases markedly. Competence, excellent management, logical decisionmaking, and the wide-angle view of true cross-disciplinary expertise have therefore become imperatives for leadership and success in this field.

Unfortunately, the reality in today's hospital and research organization IT departments falls far short of this.

As far back as 1969, EMR and Medical Informatics pioneer Donald A. B. Lindberg, M.D., now Director of the U.S. National Library of Medicine at NIH, made the following observation. He wrote that "computer engineering experts per se have virtually no idea of the real problems of medical or even hospital practice, and furthermore have consistently underestimated the complexity of the problems…in no cases can [building appropriate clinical information systems] be done, simply because they have not been defined with the physician as the continuing major contributor and user of the information" (Lindberg DAB: Computer Failures and Successes, Southern Medical Bulletin 1969;57:18-21).

Surprisingly, there has been little change in this issue in thirty-five years. Today the IT personnel and non-medical managers (e.g., non-degreed IT staff, BS or MS in computer science, MBA's, even PhD's) who often hold leadership roles in EMR and clinical data research initiatives via control of critical decisions, budgets and resources, often have inadequate or nonexistent clinical experience and insight. Specifically, personnel of an information technology background, with little or no background in the biomedical sciences, often are empowered as enablers, rather than facilitators, of such initiatives. They retain a major say in what is -- and is not -- done, and in the tools provided to perform clinical care and biomedical R&D.

From a dual perspective as both a clinician and computer professional, it is evident that this arrangement is faulty, and that critical clinical computing projects benefit greatly from an alternate approach to project preparation, development, implementation, customization and evaluation as compared to management information systems (MIS) projects. Clinical computing and business computing are different, highly distinct subspecialties of computing.

IT personnel in hospitals often believe that success in implementing management information systems applications ("business computing") supersedes or actually renders unnecessary the mastery of medicine in leading and controlling implementation of clinical computing tools. Yet, mastery of applied IT towards implementing management information systems is in large part mastery of process (e.g., in acquiring and supporting vendor-written software) and repetition, as opposed to the practice of medicine, which requires mastery of complexity.

In other words, applied IT is a field of a relatively small number of principles, a large number of arbitrary conventions and rules, and a narrow body of knowledge applied repetitively and programmatically, often without scientific rigor. This may be illustrated by the fact that most areas of applied IT can be done well, and often are, by those with little or no formal training. This is not to imply that applied IT is itself easy, which it is not. There is no substitute for talent and real-world experience.

In clinical IT settings, however, there must be the right experience. Experts in clinical computing must provide effective solutions via seasoned application of the concepts, techniques, knowledge, and processes of medicine, and display an expert level of critical thinking in applying principles, theories, and concepts on a wide range of issues that are unique to clinical settings. Business IT experience alone does not provide a sufficient background for such responsibilities to be carried out effectively. Further, medicine is a domain of many difficult, nonintuitive principles, experimentally-derived natural laws, and a large body of knowledge applied in a broad, interconnected manner, ideally with critical scientific rigor. It cannot be practiced successfully without significant mastery of an enormous body of biomedical knowledge and significant hands-on patient care. The IT model of "If it's information, we do it" starts to fall apart and impede progress in such organizationally and sociologically-complex environments.

Leaders in clinical IT must be experienced in medical sciences and in the complex social and organizational issues of healthcare, such as the need for multiple, contextual levels of confidentiality, the politics and psychology of medical practice and referral, the complex medical workflow and the need to rapidly improvise due to the unexpected ("there are no committees in cardiac arrest situations"), and societal and personal sensitivities towards the physician-patient interaction.

In effect, management information systems and clinical systems are highly distinct. The belief that mastery of IT process and repetition for management information systems implementation entitles IT personnel to lead and control implementation and operationalization of essential tools in complex domains such as medicine (e.g., electronic medical records systems) is presumptuous and creates an environment strongly misaligned with the business of healthcare delivery. The belief often results in the exclusion or misutilization of medical informatics experts, appropriate clinicians, and other forms of mismanagement exemplified in the typical cases below.

Unfortunately, there is often a "whitewashing" of these issues in publications about healthcare IT. Remarkably, healthcare IT publications commonly offer articles acclaiming the value of IT personnel allowing clinicians to participate in clinical systems implementation. Clinician involvement is so obviously necessary that such articles might be compared to the New England Journal of Medicine publishing articles on the value of employing sterile technique during surgery. A critical reader should question why articles about IT personnel needing to allow clinicians to participate in healthcare IT still appear in print.

The familiar stories of healthcare IT failure and organizational discord in hospitals and academia below reflect, as their root cause, basic mismanagement due to significant inadequacies in organizational thinking, structures and support of healthcare information technology. Such technology is vital to healthcare quality improvement and prevention of errors. As these stories illustrate, however, this technology is not always treated as such by healthcare leadership, including officers at the "C" level (CEO, COO, CIO etc.) and Boards of Directors.

It should be remembered that failed healthcare IT projects are not caused by immutable organizational or political issues. Importantly, failures are caused by the mismanagement of the organizational and political issues and of the people who create the problems associated with these issues.

The direct economic costs of such IT failures (often caused by a minority of personnel in an organization) is in the millions of dollars per year per healthcare organization. The resultant, less tangible costs of lost opportunity and are more difficult to quantify, but are probably much greater than the direct losses in the long term.

Medical professionals are being held to increasingly stringent standards of quality and accountability at the same time they are becoming highly dependent on healthcare IT in taking care of patients. Those who are responsible for healthcare IT, including senior healthcare management, have not been held to the same standards of quality and accountability as the medical professionals dependent on this critical IT. This needs to change.

Healthcare, pharmaceutical, and other biomedical R&D organizations that conflate "information provision" with "information technology" and depend on business-IT personnel to do the work of medical informaticists and clinical information scientists do so at their peril.

These stories are dedicated to medical informaticists, whose personnel strive hard to utilize computers to improve the quality, science and art of medicine.


Serious clinical computing problems in the worst of places: an ICU

In an East Coast (USA) tertiary hospital intensive care unit, an electronic patient record and physiologic monitoring system was desired by the medical and nursing staff to save time and improve care. The MIS department was put in charge of software and hardware selection and configuration.

The MIS department by policy only used Compaq computers. Any other computer manufacturer's computer was deemed "risky." There were stories of a bug in a model of Macintosh causing packet storms and taking down a network. Other computer brands might also have compatibility problems and require special drivers (not that this was ever tested). Therefore, Compaq PC's were the "one shoe" that would "fit all" needs in the organization.

The ICU rooms were very small. In order to fit the standard-issue Compaq desktop computer into such rooms, along with a standard CRT monitor, custom (expensive) cages were designed and ordered so that the machines could be bolted to the ceiling of each room. Special custom poles and cabling harnesses were also designed, ordered and installed, custom-made to fit each room at great expense. On each pole was mounted a standard computer CRT monitor, keyboard and ordinary computer mouse.

Issues such as air filtration, maintenance, and contaminant circulation from the power supply fans of each machine, heat generation from the CRT's, dirt accumulating on the mouse and keyboard, and other ergonomic and medical issues were not considered.

Industrial form factor computers (small, convection-cooled or low-air-circulation, and boltable to a wall), flat-screen LCD monitors (compact, low-power-consumption, low-heat-producing), easily-cleanable trackpads, and other ergonomically better-suited solutions were immediately dismissed with the refrain "we don't support them". No such technology was purchased for evaluation. In fact, as it turned out, the MIS system architects had actually never before seen a combination keyboard/trackpad that had been off-the-shelf available for a number of years from nearby CompUSA outlets (for about $50 retail).

The ICU system had problems. A clinician hit his head on one ceiling-mounted computer. A monitor nearly toppled and caused an injury. Redesign and relocation of the hardware mounting cages and poles had to be performed at more expense. The ICU room crowding and tight workstation ergonomics were not appreciated by busy ICU personnel.

The system was also repeatedly crashing and an informaticist was finally consulted. The informaticist noted the ergonomic problems and recommended solutions, but was resented since the technology being suggested (e.g., industrial/clinical computing form factors, track pads instead of mice, and flat screens from a number of non-Compaq vendors) were "not supported by I.S."

The informaticist noted portable x-ray machines in frequent use in patient rooms, as happens in ICUs, and realized x-ray scatter could be a cause of PC crashes. MIS personnel, on the other hand, thought insufficient RAM might be causing the crashes (empirically - there was no actual evidence for this) and were set to spend a large amount of money to upgrade each machine.

When the informaticist inquired if the computers used parity-checked RAM as a precaution against memory errors caused by x-ray radiation or other factors (a reasonable question for an ICU setting), it became apparent to him that the MIS personnel, including the MIS director, did not know if the computers were so-equipped, and worse, did not know what parity checking memory was or why it might be needed in such a setting.

After this basic question and a lack of response, the informaticist reported the potential problem to the head of the ICU. The response of the MIS personnel was to shun the informaticist and say non-complimentary things to administration about the informaticist's role and beliefs. The MIS personnel assured administration that all computers had the parity feature, and that is was not very important anyway since only "satellites in Earth orbit" needed protection from x-rays.

The informaticist pulled a memory module from a machine and found it was an 8 bit, not a 9 bit, module and therefore did not support parity checking. However, administration did not believe the informaticist's concerns about ergonomics or technical issues such as this, after the assurances and spin from MIS.

It later turned out that neither x-ray scatter nor memory quantity was causing these particular crashes. In fact, a vendor software design deficiency was found to be causing the crashes. The vendor had designed the system so that each individual client workstation was responsible for initiating printing of periodic reports on the patient in its room, rather than centralizing this function at the server. This introduced a manifold increase in potential points of failure and was found to be the major source of the trouble. Significant modifications to make the reporting function server-based solved the problem.

This was a design deficiency that the informaticist, who had developed significant software in the past, would have recognized quickly as suboptimal for a critical care setting such as an ICU in the first place. Also, the informaticist still recommended parity memory for any critical care setting as a relatively inexpensive legal due diligence. This advice was not heeded.

The informaticist's credibility with administration had been tarnished by MIS. The informaticist's concerns about the technical abilities of the MIS department to support equipment so closely involved in this critical patient care setting were also resented by administration.

Meanwhile, the system proved more costly to support than MIS had predicted, requiring extensive development and customization (over and above the inflated costs of the fancy mounting accouterments), since it was immature, not entirely reliable, and user-unfriendly. One very valuable system feature, the severity scoring system, was never enabled. That feature might have allowed patients to be transferred out of the ICU earlier, saving a significant amount of money.

The system struggled with proving a return on investment, was nearly canceled after a year, and was given a "try-it-for-one-more-year-but-prove-the-ROI" reprieve only after a large degree of pleading and politicking by key personnel (including the informaticist). Its future is uncertain, plans to spread the technology to other ICU's in the organization were canceled, and administration has been needlessly "turned off" to this type of technology.

Muddled thinking: a major cause of healthcare's dangerous lag in Y2K remediation

An overworked, understaffed hospital MIS department suffering from generally low morale was trying to gear up to fix the organization's Y2K problems, well-aware of the berating being done by the government (e.g., Sen. Dodd of the special Senate Subcommittee on Y2K) about the unpreparedness and liability in healthcare.

An informaticist who was concerned about the MIS department's ability to handle this challenge alone suggested at a meeting that bringing in an IT consulting company such as CSC, EDS, or the like who've formed Y2K divisions would be very prudent. Several industry senior CIO's also acting as consultants in IT to the organization agreed with this at the meeting. The response from the senior executive overseeing MIS in this hospital (himself having no background in information technology whatsoever) was that "We know how to handle these things best ourselves, consultants will only slow us down" and "I'm not enthusiastic about fixing the Y2K problem, since it will utilize resources and detract from our mission to serve the community." (?!?)

The top executives were informed by the informaticist that such attitudes were potentially reckless or even catastrophic in view of dire, almost daily warnings from many sources about healthcare's unpreparedness in Y2K, risk to the community, liability that could extend into the hundreds of billions of dollars, and other factors. The informaticist also told them of a number of "train wrecks" he'd personally seen that occurred due to similar attitudes. Somewhat like noncompliant patients ignoring a physician's expert advice, however, the top executives were concerned mainly about whether the "proper process" had occurred at the meeting and did not revisit the meeting's decisions, e.g., concerning Y2K consultants.

The Ivy League-trained informaticist was frightened by the disdain of the leadership towards such matters. Further, the informaticist realized that there was a literal abyss between the thinking in informatics about rigor, science, and best engineering practices, and the cavalier thinking of this organization's management towards information technology. The informaticist left this organization shortly thereafter.

Many months later, this organization now finds itself so starved for resources and scrambling to accomplish Y2K remediation by itself, that virtually all other computing projects, especially clinical computing projects serving clinician's needs, have been halted or postponed. Even minor improvements to existing clinical applications have been stopped so that "MIS can devote all its efforts to Y2K." In an unfortunate illustration of cascading dangers that occur when critical healthcare IT issues are mismanaged by technology-unlettered executives, clinicians at this organization no longer have expert informatics assistance, their clinical IT projects have lost significant momentum and have been marginalized, and their needs are being neglected.

Needless to say, all of this has not helped the morale and image of the MIS department.

The company that produces this organization's HIS (hospital information system) and other critical information systems has just been sued for securities fraud involving the misreporting of finances. The company has also been named as defendant in a multitude of shareholder class-action lawsuits. This may diminish the company's ability to assist its clients with its HIS and other information systems.

It should probably be noted that the people responsible for the financial problems at the company are business and financial people, the same occupational background as those at this hospital who decided to ignore the informaticist on bringing in outside help on Y2K remediation as early as possible. (The informaticist believed in a rigorous approach to critical, unpredictable problems such as Y2K, and in optimizing resources to guard against unexpected contingencies.) The scenario just mentioned could have become a spectacular example all-around of the wrong people making the wrong decisions for healthcare at an exceptionally wrong time.

Now that January 2000 has come without apparent major interruptions in computer services, the news media is reporting the Y2K bug "squashed" and appear to be insinuating that the problem was severely exaggerated. This is being done even in the face of hundreds of billions of dollars having been spent in remediation of important systems known to harbor flaws. The flaws would have made important applications such as financial systems or HIS's (hospital information systems) inoperative or erroneous.

The Loma Linda (Calif.) Medical Center offers a different perspective. An experiment conducted there after Jan. 1 is illuminating. Out of curiosity, IT personnel at this 653-bed hospital did nothing to upgrade an existing billing system that was being phased out. After the Y2K transition, financial transactions were fed into the old system. "Everything it produced was wrong; it had gotten completely confused," said CIO Bob Blades. "We're just grateful we upgraded everything else" (Modern Healthcare, 1/31/2000, p. 40).

This bizarre conclusion ("on the basis of not having experienced problems, we conclude there never was a problem") is a sad commentary on the ability of many to think rationally and make sound judgments on complex technological issues.

In another footnote, the organization that is the subject of this story also survived the Y2K transition, but at the cost of several years' needless delayed progress in clinical computing initiatives. Yet, the administration of this organization has been touting the Y2K effort as "a clear example of Unsurpassed Excellence." This statement comes at the very time the U.S. Government is considering legislation on the medical errors problem, which will undoubtedly result in the need for significant advancements in clinical IT. Such puffery, word hyperinflation and blind self-aggrandizement are characteristic of many hospital and MIS bureaucracies.

MIS inadequacies in tough clinical environments: an invasive cardiology example

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 MIS department was engaged to assist the cardiac catheterization lab in this information technology need.

From the very start, the project suffered from severe mismanagement 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 the shallow 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, muddled thinking and 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.

A Steering Committee was initiated, led by a new, very 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 for "not controlling the doctors", representative of this organization's somewhat unreasoning attitudes towards its life blood, 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 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 a hostile tone that the MIS people "get out of our cath lab!"

Blame for the project paralysis and failure was shifted by MIS to the cardiac administrator and clinicians, using convincing-sounding language about process, ownership, nurturing, mentoring, feelings, and other impressive-sounding but shallow and almost mystical puffery and rhetoric. This made the clinicians, used to 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.

An informaticist was then hired as an "internal consultant" (instead of as leader, itself symptomatic of a "control pathology" existing in this organization's executive team), after a senior executive found out about the existence of such specialized personnel. The informaticist 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 bizarre scenario, 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).

Next, the informaticist jettisoned the customary, stale 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 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 pharmaceuticals. 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 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 to customize the application data set and work flow components, and 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.

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 is "uncooperative and an obstructionist" (i.e., he thinks critically and does not simply follow orders from the non-medical executive in question).

This accusation and 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 now tells 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 mismanagement flavors (at great waste of money) received generous promotions.

Sadly, it is clear this organization learned nothing from medical informatics.

Inadequate data modeling causes Medicare misallocation of billions

As a striking illustration of the potential dangers of inadequate data modeling, insufficient granularity in Medicare's current system of diagnosis-related groups (DRG's) has caused revenue shifting over the past decade away from cash-starved urban medical centers to smaller facilities. Many billions of dollars are involved. This revenue shifting is due to the fact that the current 491 DRG categories do not adequately capture the differences in severity of illnesses within a single DRG, resulting in underpayment to some providers (i.e., those that have the capability to handle very sick patients, often transferred from small facilities) and overpayment to others (small facilities that keep the simpler cases).

In fact, it is proposed that the number of DRG's be increased by almost one hundred percent, to a total of 900 groups. This reflects not an adjustment, not an iterative change, but a stunning complete overhaul of a defective DRG system. It is especially important to note that healthcare has not recently doubled in its complexity! (See "Panel may support doubling of DRG’s", Modern Healthcare, 31 Jan 2000.)

Such problems are complex, and it may be unfair to say the DRG situation might have been prevented. However, it is clear that correct modeling the medical world is not a process of "luck." The highest levels of medical informatics expertise must be deployed appropriately (in leadership roles) in organizational or national data initiatives that determine resource allocation, best practice determination, drug development, compensation, and other major healthcare decisions.

Yet, advertisements for healthcare and biomedical data project leadership often appear similar to the following:

"Data Architect: As a leader in data modeling and development for the company, this position entails supporting software development activities and internal database usage. Primary responsibilities logical and physical data modeling, data application development, supporting of R&D projects through the vending of data services (SQL development, data transformations, database design & development, etc.), and limited DBA functions. Candidates must have real experience in database design (1-3 yrs), advanced SQL (2+ yrs), implementing concurrent large distributed databases, dimensional data modeling, developing data-driven applications, and the ability to work on a team. Additionally, knowledge of Oracle 7+ (UNIX & NT), and Business Objects WebIntelligence Query tool, are highly desirable. Requires a BS in IS, or equivalent."
Skills in medicine, healthcare, or any biomedical field are considered optional or unnecessary. As in the example above, often only a bachelor's degree in "Information Systems" is called for. Unfortunately, optimal healthcare data modeling requires a background in both biomedicine and information science. Specific software or hardware package experience is far less important, yet this is usually unrecognized in the job formulation and hiring process. (It should also be noted that experience in management information systems is not the same thing as experience in information science and scientific computing).

The common blindness to the primacy of the medical modeling process over specific software and hardware skills in hospitals, industry and government is astonishing to many medical informaticists. They understand that medicine is of unparalleled informational complexity, and that mis-categorization or mismodeling of the healthcare environment can have significant, unexpected consequences on an individual, organizational or societal scale.

Such blindness usually stems from a common business and MIS belief that "medical data is like everybody else's data" and that "if it's data, we can do it." Instead of selecting individuals optimally, high-level cognitive abilities such as biomedical data modeling are sacrificed for fluency with the latest whiz-bang software platform. Interestingly, the business and MIS leaders who adhere to such beliefs and practices almost always have no clinical experience or training.

New technology under tinkerers: how one person can impair progress for entire organizations

This story comes from a major U.S. academic institution. The informatics director, a tinkerer and bully with major political connections, usually got his way at a major academic teaching hospital. The director believed himself an expert on all aspects of computing and communications.

The director was asked to perform a demonstration to V.I.P.'s of voice and visual communication for telemedicine applications over the campus computer network. This person knew there were experts on staff in telecommunications and in this area in particular, including an informaticist on his own staff with significant amateur radio expertise, including slow-scan and fast-scan television.

Rather then engage these individuals and share the spotlight, this director created a demonstration without such expert assistance. Small cameras were hooked to two computers, one in the campus library where the demo was to be performed, another in an office across campus. Simple communications software was installed. Minimal testing was done since "unless the network was down, nothing could go wrong."

At the demo, the software was started while a dozen or so senior leaders in the organization observed. The first few moments went well, with the director in the library talking to his wife in the office across the campus. However, the demo was performed in the early afternoon, during a time of peak network traffic. Network delays started to cause pauses in transmission and reception. When it appeared one party had finished speaking, the other party would begin, only to be interrupted by the completion of the first party's transmission.

These "packet collisions" continued for several minutes and made meaningful communication of even simple information difficult and frustrating. The assembled V.I.P.'s got a very bad first impression of this technology, and first impressions are very, very important (especially with non-technical people who are responsible for funding of new technologies).

At the wrap-up discussion of this demonstration, the embarrassed director-tinkerer concluded that the technology was immature and may not yet be ready for fruitful use until higher network speeds were available. This discouraged those in the audience who hoped this would be a good technology for medically-underserved areas in the poorer rural communities of this state.

The informaticist amateur radio expert in the audience begged to disagree and stated that a simple communications protocol could suffice to facilitate use of the technology, even under heavy traffic situations. He explained that a mutually-agreed upon protocol of saying "over" (or similar acknowledgment) to signal the end of a statement would be a foolproof mechanism to prevent collisions.

The director responded in a sarcastic manner that this was a 'ridiculous idea', that he would never say things like 'roger, over', and that others would feel the same way in the age of fast communications. The amateur radio enthusiast replied that this was not the case. He pointed out that radio operators had been using such protocols for almost a hundred years, especially with Morse Code or any form of half-duplex communication such as radioteletype or voice. A senior member in the audience, the medical school educational computing director, agreed with the radio expert about this, himself knowing a bit about telecommunications, but the audience still left the demonstration quite disappointed.

Unfortunately, the amateur radio expert was to learn the problems with challenging someone politically well-connected, and not surprisingly no longer works for that organization.

Disrespect for the needs of clinicians: platform bias taken to an extreme

An informaticist who was consulting with a large east coast hospital was called by the Chairman of the Department of Medicine about a very frustrating problem that had been ongoing for about two years.

The Chairman was not knowledgeable about computers but had purchased a home Apple Macintosh computer several years before to perform useful tasks such as word processing and medical information searches. It was a PowerPC-based unit, which he thought was handsome and fit well with his home decor. (Perhaps even more importantly, it had obtained spousal approval.)

The MIS department of his hospital had adopted a strict "PC only" rule, however. All connections into the organization, whether to the mainframe or other GUI-based clinical applications, were via PC-based terminal emulator software or winframe applications.

The Chairman of Medicine liked the Mac at home and did not want to install a second computer, a PC, into his home for hospital connectivity. The MIS department "did not do Macs" and therefore would make no attempt to look for Macintosh applications or emulators that could allow this physician to connect to the hospital network. MIS leaders told senior executives that making the Chairman's Mac connect to the hospital network was impossible. They would not even touch the Macintosh. Stalemate.

The Chairman had, on his own, obtained a PC-on-a-board for the Macintosh from a well-established third-party vendor, Orange Micro, but did not have the experience to install it. The MIS department was adamant that this could not work, that any PC emulator would have bugs, that it could not reliably run the PC software used for hospital connections. They refused to assist the Chairman of Medicine install his purchase. This was certainly not good for intercultural relations between MIS and the clinical staff. The Chairman turned to the informaticist for assistance.

The informaticist, not being a platform religionist, was proficient with both the PC and Mac platforms and the third-party add-on. He explained to the MIS department leaders that the add-on board was a complete PC, with its own Intel CPU, memory, serial ports, etc. running native Windows. The Macintosh would just share the keyboard, disk drives, and cabinet, and that this board would turn the Mac into a true PC when it was operational (a "MacCharlie", to those who remember the mid-1980's). The add-on was an industry standard itself and would convert the Chairman's Macintosh into a 'PC living in the Mac box', he said, with a great chance of success in running the needed telecommuniations software.

The informaticist stated he was going to attempt to install the third-party board and wanted MIS support. The MIS personnel remained adamant. They felt such a contraption could never work, that a Mac would not be compatible, that even if it were a "PC in Mac clothing" it was not the Standard Vendor Brand PC they utilized exclusively, that they don't support Macs. MIS still refused to touch it, as if it was a heresy. In fact, they never researched the third-party add-on board, showing one basic difference between clinical and MIS culture. Clinicians are used to researching new potential clinical tools and treatments.

MIS somewhat sarcastically wished the informaticist luck, and hoped it "all worked out." Behind the scenes, as the informaticist discovered, the CIO ridiculed the informaticist to other senior executives, wondering aloud where the informaticist "gets the time" for such adventures. The informaticist could not fathom how assisting the Chairman of Medicine in such a basic need could be trivialized in such a manner and obviously felt such behavior highly inappropriate.

This behavior is symptomatic of irrational thinking. The Chairman of Internal Medicine is an absolutely key leader in the difficult cultural transition of a hospital's physicians to electronic medical records, computerized order-entry, etc. The undivided support of such key medical leaders is absolutely crucial. This CIO represented himself as a religiously-devout person who nonetheless took pride in admitting his work-world philosophy came from the ancient Chinese book "The Art of War", perhaps indicating an ability to rationalize that tragically exceeded by a wide margin the ability to think rationally.

The informaticist installed the new board into the Macintosh, installed MS-Windows, and had the communications software installed and operational in a few hours. The MacCharlie was now able, with a single keystroke, to appear as either a Macintosh or a fully-functional PC. Compatibility with the communications software was not an issue and the Chairman now "had his cake, and could eat it, too." So ended several years of frustration for the Chairman.

The only gratitude received by the informaticist was from the Chairman of Medicine, although other executives in the organization (acclimated to an MIS culture representing computers as mystical) thought of this trivial, teenager-level accomplishment as something of a miracle.

Chaos from MIS mismanagement of a clinical information system project

An informaticist took a full-time position as a Director of Informatics at the healthcare organization where he obtained his Medical Informatics education. He was to lead the clinical team working on a full-blown inpatient Computerized Patient Record. The project plan included nursing documentation, full online medical records, and physician order entry. The experience the project would provide and the prestige if the project were successful were very attractive to the informaticist.

For the first 6-9 months the project seemed to go well. The clinical data repository implementation was progressing and interface specs for lab results and data coming from ancillary systems were largely done with what seemed to be a few minor issues left to resolve. The hospital had just hired more clinical analysts to start the design and implementation of the physician order entry system, and that phase of the project was underway.

Then, due to muddled thinking and basic incompetence by the hospital’s MIS leaders, the bottom fell out.

The informaticist and his clinical team actually found themselves excluded from preliminary interface testing. Significant obstacles causing long delays in clinician participation in the project started to appear. Further, numerous essential aspects of the design had been delayed. As the clinical team finally began to see a test system, there were numerous clinically-important configuration settings that had not been addressed by MIS.

The delays in implementing the interfaces to other systems (e.g., lab) ran into months. Fortunately (or unfortunately, depending on one's point of view), there was a major network infrastructure problem that had to be fixed before new production systems could come on line. (Of course, that issue should been realized well beforehand by MIS, but we digress.)

The network issue, plus the Y2K issue, gave the organization a four-month ‘reprieve’ on the planned go-live date. Despite that, major interfacing problems continued to persist. What could only be described as outright incompetence by senior MIS personnel followed, both in understanding the technical issues and their clinical significance and in establishing consensus on how to resolve them. As a collateral injury, this caused even more delays in the informaticist and clinical team being informed of (and helping provide solutions to) these issues.

MIS wasted considerable resources and time with band-aid solutions, that, when the informaticist and clinical team found out about them, made them literally groan, as they usually were unacceptable and actually clinically nonsensical. MIS would then re-think the problem and possible solutions, often with still-unsatisfactory results!

Furthermore, the "go-live" date was by edict made a drop-dead date. Senior IS management and senior health-system management, lording it over the informaticist and clinical team, gave no heed to concerns that the clinical information system was not yet "ready for prime-time." Therefore, the project team was forced to either push ahead with ridiculous solutions to major interface problems, or simply postpone some interfaces crucial for full system effectiveness.

As it turned out, the clinical information system went "live" with only about 50% of the functionality and interfaces that had been planned.

The incompetence of the vendor's on-site personnel was another major factor contributing to delays. They quite literally could not understand the concerns of the clinical team or the clinical significance of the issues, and were instigators of several absolutely idiotic "solutions" to significant interface problems. Worse, many of the so-called "solutions" would actually not work with their data repository upon testing!

In other words, the vendor’s personnel came up with solutions not just clinically absurd, but also technically unfeasible! Also, they could tell the clinical team precious little about how the database and interface designs would influence the display and functionality of the GUI, which was another huge causative factor in delays and system rework. Between MIS and the vendor, it was like the blind leading the deaf.

As is typical in hospitals, MIS (not the project committee or clinicians) controlled the budget and the MIS resources that were responsible for executing the design and implementation of the data repository. Due to this, clinical concerns were often simply ignored.

The informaticist and clinical team compiled a list of about a dozen configuration changes that affected the GUI that were essential prior to bringing the system live ("go-live issues"). These dozen issues were simple preference settings that could be made with GUI tools provided by the vendor. They did not involve vendor enhancements or new code from the vendor.

At least half of these trivial configuration changes were not made for months, despite the fact that it would have only taken the informaticist or someone even minimally technically competent about an hour to do them. Of the remaining half, several were still not done at go-live. Senior MIS management simply never put them on the priority list, and they never got done, to the severe detriment of the success and ROI analysis of the system to date. It is amazing how MIS always seems to concentrate on "process" to the exclusion of needs and results.

The escapade that finally sparked this informaticist to resign his position is as follows: At a meeting of the senior MIS and clinical stakeholders of the project (the informaticist, the Medical Director of the project, the MIS project manager, and the MIS staffers), it was decided that since the current security functions did not meet the needs of the psychiatric hospital, the initial implementation would not include psychiatric data until the vendor redressed the security deficiencies. Several other options, all of which were "hacks," and would have compromised the functionality of the system for other users, were discussed and rejected at this meeting.

In fact, no users would be able to access psychiatric data even if it were included. The team did not plan to roll out the system to users with clearance to access psychiatric data for at least a year. Thus, the lack of psychiatric data would be of absolutely no clinical significance for at least a year after go-live.

However, when it came time to meet with the psychiatric stakeholders, a mid-level MIS manager sent an email listing "options" that were to be discussed at the meeting with psychiatry. To the informaticist’s horror, they were the very same "hacks" that had been ruled out at the previous meeting!

The informaticist and clinical team quickly challenged this MIS person, and the MIS senior managers, on this rather egregious breach of a consensus decision. They requested that the MIS manager and the manager’s superiors NOT present these options at the meeting.

Despite this, the MIS manager went ahead and presented the options anyway. When the Medical Director of the project stated at the meeting that those options were not acceptable to him, the whole Clinical Information System project quickly lost all credibility with the psychiatrists, and irreparable damage to morale had been done.

The options had been presented at the direction of the senior MIS person on the project. This person had apparently made promises to the psychiatrists that the informaticist and clinical team had not been consulted on, promises that were impossible to keep. It was that day that the informaticist realized that MIS was completely unresponsive to clinical end-users, and that the Clinical Information System project was in serious jeopardy as a result of its inappropriate leadership.

The informaticist sent resumes out that day. In less than two months he had a new position at another organization.

The MIS CIO, the Medical Director, and the academic Medical Informatics director pleaded with the informaticist to stay and even offered a salary increase and the promise that MIS would have more accountability to clinical members of the project. However, one senior VP in MIS was extremely reluctant to allow any changes, and did not want to remove the senior MIS manager responsible for the psychiatry debacle. The senior VP apparently felt a sense of loyalty to this MIS manager. It would have taken a serious restructuring of this person’s position to effect real change. The position would have to report directly to the Medical Director of the project. It was clear this was just not going to happen.

The promise of change was therefore window dressing, not the substantial change needed to make the project successful, in the informaticist’s opinion. He accepted a very attractive job offer with a healthcare IT vendor. Hospitals thus lost one more informaticist and abundant intellectual capital due to inappropriate leadership and organizational structures, structures that inappropriately put MIS in the pilot’s seat of an initiative to create a clinical tool.

The informaticist had hoped his leaving would send a strong signal and that real change would result. However, he later reported that he’d heard from a close friend (another clinician) on the project that things had actually got worse starting just a few weeks after his departure.

Salesperson performs frontal lobotomy on industry healthcare group

The healthcare IT vendor industry is not immune from the mismanagement and unqualified decisionmaking afflicting the healthcare delivery sector, one informaticist reports.

An informaticist was contacted by a national recruitment firm for a "director of clinical IT" position in the healthcare group of a large, respected information technology vendor. The healthcare group had focused on leasing of expensive medical equipment.

Due to decreasing life cycles of IT-related equipment including medical machinery, making leasing less profitable, and a corporate mandate from the company’s CEO, the healthcare group was moving to a services delivery model. The role of the informaticist would be to provide strategic guidance to this transition, help in new product development, and assist the sales force in navigating the complex territorial waters of healthcare IT. The sales force was very unfamiliar with healthcare IT per se. They had predominantly interacted with medical officials and CFO’s, not CIO’s or M.I.S. in hospital settings.

The informaticist noted that the healthcare managerial staff all seemed very intelligent, with a senior VP approaching genius level. People were generally affable, creative, and entrepreneurial. His boss-to-be was relatively new to healthcare IT and was quite friendly. True partnering with this person seemed possible.

His interviews went well. Despite a salary offer lower than his background really merited, and the presence of a "medical instamaticist" as Director of Informatics (an MIS person with no clinical or informatics training or background, see "What medical informatics is not"), he decided to accept the position. He was impressed by a corporate-wide telecast in which the company’s CEO announced a major push in healthcare IT. Also, the "instamaticist" was smart and affable, and the informaticist was to join a technology group of people with healthcare backgrounds (including some new hires). The informaticist hoped to be able to advance through the ranks of this company to make up for these issues, and thought his accepting the position was a good career move.

BAD mistake!

Due to political turmoil that began at about the same time as the informaticist started the new position, the position could only be described as stillborn. For several months, not much happened and the informaticist was rarely called upon to do much, other than help in an early product development initiative. This was primarily due to political turmoil regarding leadership of the healthcare group. The technology subgroup he was now part of found itself similarly marginalized. This was a shame, as this technology group consisted of hard-to-find, extremely competent people who collaborated as a team extremely well.

The informaticist noted other signs of impending doom. One senior networking person explained at lunch that he believed in practices such as "therapeutic touch." He was not amenable to the informaticist's explanation that a prominent medical journal had published a scientifically-valid survey debunking such practices ("A Close Look at Therapeutic Touch", Rosa et al, Journal of the American Medical Association, April 1, 1998). The networking person objected with the statement that "medicine doesn't know everything."

(The informaticist refrained from explaining that medicine indeed doesn't know everything but sure as hell has a superior path to knowledge and wisdom compared to pseudoscience and pop mysticism, namely, the scientific method. He also refrained from telling the networking person about "therapeutic computer touch," where people diagnose failed hardware, disk corruption, and computer viruses by wearing long robes and waving special digital divining sticks to sense sick computer spirits.)

There were more serious signs of brain damage in this company's comprehension of healthcare. One of the company’s technical divisions had a healthcare accrediting agency of national prominence as a client. The company's technical division did not pay much attention to this account as it was very small, dollar-wise. As a result, the computer technicians and MIS managers in the technical division did not aggressively adhere to their own standards of rigor, doubtlessly saving such rigor for "bigger, more important" accounts.

Predictably, they failed miserably in crucial matters related to the accrediting agency’s IT, in an area exactly corresponding to the new product being developed by the healthcare group and informaticist, and lost the account to a competitor. Worse, they could not even understand the impact of this debacle: namely, pissing off a national healthcare accrediting agency and the effects on the healthcare group’s hopes of securing national contracts with hospitals. Worst of all, nobody in the company thought to ask the informaticist about any of this.

Then, the politics fell apart. The division VP over healthcare was moved. The genius-level Senior VP over healthcare was also asked to move to another division of the company. He declined and chose retirement instead. The informaticist’s boss then resigned suddenly, and the informaticist and his technology group found themselves with an "acting boss" and even less opportunity to do any useful work.

A new Senior VP was appointed. In a staggering example of decision-making through the Dilbert school of management, a sales manager of a real estate background who’d been with the healthcare group for several years was appointed. This person had been a good salesman but lacked both technical skills and intellectual bandwidth, the informaticist thought. The division VP was also changed to someone far less visionary than the original. Once again, the domain experts, the informaticist and the technology group, were not even consulted for advice about such appointments.

What followed was what the informaticist could only describe as a "theatre of the absurd." At the healthcare group sales meeting where the new VP debuted in his new role, he told the assembled group in Darth Vader-like tones that "sales figures would need to increase at least 300% the next year, that salespeople needed to work harder and that slackers would be out of a job." Great news for a group of tired salespeople in a healthcare industry on the verge of collapse due to the cuts of the Balanced Budget Act and impact of managed care. The roar of silence was deafening.

To help accomplish these goals, he announced a "restructuring" soon after. In a brilliant move, nearly the entire technology group, including the medical informaticist, was summarily dismissed!

Not surprisingly, the "instamaticist" was about the only person retained. In his short announcement to the group, the new VP told the healthcare IT experts, including the medical informaticist, that "your backgrounds are too specialized for our needs."

This is truly a spectacular attitude to have in a field at the intersection of medicine and information technology, two of the most specialized of all human endeavors, where good people are exceptionally hard to find. The informaticist thought of the slogan "frontal lobotomies are good for business!" to describe this new debacle.

Apparently, word of this debacle spread rapidly to senior management. This real-estate-salesman-turned-clinical-IT-expert was apparently demoted back to a regional sales manager within weeks of the layoffs. An intelligent healthcare IT marketing person was promoted to become the healthcare group general manager. However, the damage was already done, and competitors began snapping up the laid-off technology team.

The motto of this story may well be "allowing the wrong people to make the wrong decisions at the wrong time is a generic route to failure, always."

Insufficient IT management depth results in Justice Dept. investigation

A large University medical faculty practice plan, noted for doctors who are among the finest in the world with expertise in cutting-edge therapy, entrusted the hospital's MIS department to upgrade their administrative and financial information systems. The plan, consisting of almost 1,000 physicians of over one hundred specialties and subspecialties, was seeing over a quarter of a million patients yearly.

The management team, as management teams do, assembled a large Task Force to draft the system requirements, send out RFP's, and work deals with possible vendors. Several high-powered business and MIS executives were brought in to run this Task Force. The institution's informatics specialists were kept at a distance from these proceedings because they were academics and not business-minded. On the few meetings they attended, their input was treated as secondary to the executives.

After some time, a commitment was made by MIS to a vendor package in the usual MIS way, with all the "proper business process." A series of preview meetings were held for the package. Two informaticists who attended the preview sessions for the financial software package felt that the software package looked rather like a Rube Goldberg contraption, with a primitive and cryptic user interface, needless complexity, poor manageability, difficult navigability, poor customizability, obtuse documentation, and other highly concerning characteristics at odds with many basic precepts of informatics.

Even the informaticists were severely confused by the demonstrations, and wondered aloud to each other how this package and these people could ever make this application fly successfully in such a complex environment. On the basis of their familiarity with those environments and with IT, they were concerned about a project 'flame out and crash.' Unfortunately since they were not empowered they were afraid to speak up, and what they did say was not taken very seriously.

About two years later, The U.S. Department of Justice and U.S. Attorney's Office announced an investigation of several million dollars worth of overbilling by the Faculty Practice Plan. In a press release, University officials downplayed overbilling as a common failure of medical centers across the country.

"The allegation is that we were not doing the refunding," the University said in a press release. "We don't yet know how much of the credit balance is overbilling. ... We've been vigilantly working with the federal authorities to determine the credit balance of the University." Of course, with the computer billing system as discombobulated as it was, determining that information, let alone anything more complex, proved to be quite a challenge.

Individuals and organizations with gripes against the University hyped the government probe. A former medical school worker, who was suing the University for over $3 million on charges of sexual harassment, suggested that the School of Medicine Dean had been fired as a result of the investigation. Several University officials said sources from the University unions told reporters that the dean was carried away in handcuffs by the police and that the sum under investigation was in the area of $20 million.

After a few years of investigations, the University faculty practice plan announced a settlement. Under the settlement, the plan would refund about $500,000 to the federal government with respect to Medicare and other federal health care programs, and make available approximately $2 million to designated health care carriers, and about $2.5 million to individuals and other entities. Furthermore, the University would make a settlement payment of $700,000 to the federal government in complete resolution of all claims.

The University announced that the credit balances included accounting entries for payments or portions of payments that the Faculty practice plan had been unable to match against outstanding charges for patient care, in many cases because information was erroneous or incomplete, as well as excess amounts resulting from duplicate payments from multiple payors. The inability to resolve these payments resulted from "faulty administrative and inadequate computer systems."

The University also announced it had voluntarily taken steps to upgrade its systems and their management, and would need to invest roughly $15 million more in "state of the art computer billing and information systems." (The old system, which cost several million in capital and heaven knows how much in operational costs, was scrapped.)

The medical director of the Faculty practice plan intoned that "the growing complexity of health insurance demands a billing and clinical administrative system as world-class as the quality of our patient care, and we have aggressively taken the necessary steps to put that system into place." The faculty practice plan resumed its practice of world-class patient care and perhaps learned that approaches to information technology can be as important as approaches to medicine.

In an uncharacteristic and somewhat stunning act of candor, the University attributed the shortcomings of the management team in a press release to "inadequate management depth." The informaticists were saddened but not surprised by how this Titanic billing system debacle led to a successful (for the Justice Department) diving expedition.

Who serves whom: physicians felt completely unnecessary in clinical IT decisions

An informaticist is involved in an informatics program that is not expected to survive due as he says "to the very political scenes you so aptly describe in your web site." He describes the hospital as run by a "MIS"-mash of at least 5 different systems, 3 of which don't talk to each other, and one that can get some messages from the other three, but only if things are running well. Specifically, the lab and radiology systems (LIS & RIS) are completely stand-alone and require totally different terminals for users. There are increasing number of PCs breeding around the facility, but some are still Windows 3.1, most are Win95, and a few are Win98. Macs exist within individual departments, but the IS department officially declared the Mac a dead-end and, of course, does not support such an "obtuse and moribund" platform.

The major machine for the enterprise is a piece of mainframe "big iron" (software platform unknown) running many user-hostile programs leftover from the Johnson administration. Using this machine is not for the faint of heart. First a person must find either a functioning terminal with its light pen still attached, or one of the aforementioned PCs with a terminal emulator. (The light pen equivalent is cleverly mapped to the right mouse button, but there's no documentation to that or any other effect.)

Very few docs learn to use the beast, but those who do discover that they can actually get to read and/or print old H&Ps and discharge summaries. This is the only electronic text available on previously admitted patients. There is no information if the patient is new. The mainframe does have access to labs and radiology reports (text only, no images) but there is an 8 to 24 hour delay before that information is batched from the originating systems.

The PCs were recently bred in captivity and populated into a new clinic building. All faculty and housestaff were issued an email account if they had not had one before. The username, password and POP server name were emailed to the account itself as a way of informing users of their new capabilities. Unfortunately, this did not work. The new PCs had cleverly been outfitted with the newest layer of Netware which required a different signon and password than the email account. This signon and password were never distributed to the housestaff, because the housestaff didn't come in for the 4 hours of training and setup for the accounts.

(The informaticist points out there's a very, very appropriate Dilbert cartoon in which Dilbert's password becomes invalid, but he can't log in to send a Help Request because....)

The reason that no house staff carved four hours out of their already busy day for training was because the computer programs that could obtain patient information (terminal emulators) were placed in the default Start Menu of all of the PC's, even if there was no one logged into that PC. It took over four months of complaining before a WWW browser was placed into this open availability status. When asked why a WWW browser couldn't be put there in the first place, IS reported that that would be a breach of security.

The informaticist found this highly ironic. Software that leads to patient information is readily available, but software which is public domain, and can't reach patient information is protected by a non-documented sign-on identity. Browsers were added only when the point was made that the hospital formulary and clinical lab definition handbook were no longer available in print, and thus could only be accessed via browser, and the lack of a browser constituted a major inconvenience and perhaps breach in patient care. Risk Management concurred with this analysis. The WWW browser appeared in the StartMenu the next day.

The PC's will still jam the attached printer if a user attempts to print a document from the "open" account. This is not documented. The user can't clear the jam, because both the open accounts and the named accounts don't have access to any control panels, the local explorer or any other software tools for the afflicted PCs.

Lastly, even those who have been through the training and have named accounts on the PCs don't use them. This is due to the simple fact that it takes the machines a full 2 minutes (120 seconds) to logout/login from the open account to your own. As the informaticist relates, "try doing that in a clinic environment more than once. Hah!"

For the future, this hospital is in the middle of trying to pick a super-system, turnkey 'this-will-solve-all-your-problems' vendor. Notably absent from the specification stage were any physicians (!) After some complaining, a few MDs were permitted to join the committee to discuss proposals which came in from the RFP. One of the physician informatics leaders objected to the way that MD needs were being relatively ignored. He was removed from his informatics position and now is in an office at the remote campus, and has no further responsibility or involvement with informatics at this hospital.

Some months ago, the three vendor finalists were invited for a 1 week (each) demo of their product. By word-of-mouth, one system was very well received by the MDs and many of the RNs and adminstrators. Not one word on final selection has since been heard since by the informaticist. As he says, "it may only be a coincidence, but one of the other finalists was the same company that had perpetrated its mainframe mentality on us 20 years ago. It may also only be a coincidence that the CIO is quite fond of the current system, and has announced that he is not going to retire until after this selection issue is done. It should be noted that he has neither CS nor medical training."


The plan to purchase the new system was quietly withdrawn, without so much as a "sorry for getting your hopes up," according to a followup message from this informaticist. He relates there are rumors that the procurement project is on hold "for 2 years" but the rumors can't be confirmed or tracked to origin. Nonetheless, suggestions for improvements in the RIS, LIS and Mainframe systems continue to be rejected out of hand by Information Services because "these systems are going to be decommissioned after the new system gets here. We're not going to spend good money upgrading an obsolete system."

The informaticist, also a practicing physician, points out that by this thinking process there would be no reason to treat someone's grandmother because she is obsolete and going to die anyway. This counter-argument doesn't seem to make much sense to the Information Services staff, who seem to forget physicians take care of patients, a process I.S. is there to support, not to control and certainly not to obstruct.

"Please, have pity on us" asks this informaticist.

Cultures of mismanagement: toxic to healthcare quality

In a large regional healthcare system, the CEO and the executive VP/COO seemed not at all to agree on the value of, and role for, an Ivy league-trained Medical Informatics professional. The CEO, himself a physician, had hired the informaticist in a previous role as Sr. VP for Medical Affairs. He had done so since the organization's clinical information technology was in disarray due to leadership problems. Expensive business consultants and even an industrial psychologist had been brought in, but were unable to facilitate improvements or change. The CEO seemed to understand the value of informatics expertise in invigorating clinical computing projects that were in difficulty, breaking up old ideas with visionary IT thinking tempered by a clinician's work ethics and insights, and so forth. Unfortunately, the VP/COO, who also oversaw MIS, apparently did not share these views.

This manifested itself after the informaticist wrote an op-ed to a popular healthcare MIS journal about the importance and value of informaticists in hospital IT projects. The informaticist and other clinicians working on clinical computing projects were heartened to see the op-ed actually published in a journal directed towards the healthcare MIS world.

A short time later, the Healthcare Advisory Board, a think-tank that scans the periodic literature for new ideas and topics of relevance to healthcare organizations, reviewed the article and found it interesting. The Advisory Board is a membership organization representing over two thousand member hospitals, health systems, physician practices, insurers, pharmaceutical companies and medical technology firms, and whose publications and white papers on trends in the industry are widely used in setting policy and making purchasing decisions.

The Advisory Board wrote to this organization's VP/COO (who was their listed contact person) about the op-ed on informatics, seeking more information on a topic that they found of interest. Despite good progress at this hospital system on many fronts in which the informaticist had taken a leadership role (e.g., strategy, EPR, GMPI, procedural medicine databases, etc.), and acknowledgment by the organization's medical staff that the 'new thinking' of formal medical informatics had changed the environment very positively, this VP/COO's reaction for whatever reason was to severely downplay to the Advisory Board the value and role of a professional informaticist. The informaticist was represented as a relatively unimportant 'internal consultant' to this VP/COO and to his MIS department, who were the 'real' movers and shakers.

(One reason might have been that this VP/COO and the MIS director reporting to him oversaw some of the failed clinical IT projects that were later made successful by the informaticist. I leave it up to the reader to surmise what might motivate such a reaction.)

To compound the unfortunate marginalization of informatics as a field that occurred here, the letter from the Advisory Board was never shown to the informaticist and was thrown away by the VP/COO. The informaticist found out about the Advisory Board's interest completely by accident several days later. The Advisory Board wasn't directed by the VP/COO to the informaticist author of the article that attracted their attention, which would have been a basic common courtesy. Finally, due to ambivalence about informatics, other senior executives did nothing upon being informed of the breach of etiquette (at best) represented by this revealing incident.

At worst, on the other hand, thousands of Advisory Board-subscribing healthcare organizations were potentially denied hearing about informatics in a positive light due predominantly to the partiality of one executive and the ambivalence of others. Further, due to incidents like this occurring repeatedly, the informaticist resigned from this organization, depriving the clinicians of informatics expertise.

This VP/COO also repeatedly obstructed the informaticist's presentation to an panel of senior industry CIO's who were advising the organization on IT at the board's request. These CIO's had very little knowledge of healthcare. Extremely verbose, complex and intimidating diagrams and charts on healthcare IT from a large, expensive management consultant firm were shown to them by the VP/COO and MIS director. These documents confused the CIO's, by their own acknowledgement. In fact, the informaticist thought the quality of these documents was appalling, which is a serious matter since they were the product of a multimillion-dollar consulting engagement. The informaticist's critiques, however, were glossed over by the organization. That is a story for another time.

A concise, clean, clear presentation assembled by the informaticist on 'healthcare computing for business IT professionals' was suppressed by the VP/COO using a number of subtle and direct tactics, such as "forgetting to put it on the schedule" or allowing other discussions (once it was on schedule) to run overtime, then forgetting to put the presentation on schedule for the following meeting. In effect, the organization was deprived of the CIO advisory panel's full value. Although possible explanations for this behavior range from ineptitude and sophistry to high-level political intrigue and sabotage, God only knows the true reasons for such behavior. This executive often micromanaged, could be ingratiating when he needed to be, but was generally cold, authoritarian and a bully. This combination of characteristics can be very destructive to innovation spearheaded by creative people. Bright people should beware such executives and the "intellectual hospice" atmosphere they sometimes create.

Not surprisingly, other executives did little when informed about this matter, since this was just the "way of business." Even the CEO remarked that this was a good VP/COO, that such views about IT excellence were a form of "extremism" and that "other views had to be taken into account" (i.e., views of those with little or no knowledge, skills or experience in computing or medicine, the chiropractors of clinical computing).

Even under the most favorable of circumstances, this executive did not let up on such territorial tactics. Despite this executive's starving the budget of an EPR project (electronic patient record) for a large primary-care clinic, causing key personnel to resign, the medical team successfully implemented the EPR on-time and under-budget anyway. They did this through advanced informatics thinking, ingenuity, medical will and true collaboration. The reaction of this executive at a meeting with other senior executives about minor fine-tuning and future directions for this project were that "the project was improperly managed in that the style was too collaborative." The delivery of such rhetoric had to be seen to be appreciated for its breathtaking combination of smooth self-confidence and patent absurdity.

To make matters worse, the executive team then gave a key EPR staff member, a Senior Resident who'd done an excellent job writing and programming custom templates for the EPR system, a difficult time on promised payment for his services. They believed such a customization function was trivial and wasteful, and essentially reneged on their agreements with the Resident. When challenged by the informaticist and others that this person's services were essential, the views were met with indifference, if not disdain, for facts and logic. In fact, the executive team clung persistently to a mind-numbing leap of logic: they seemed to believe that just as home computers were "plug and play", so was clinical IT. Their attitudes seemed to reflect a belief that the EPR team and resident were basically deceiving them.

These attitudes and actions inflamed the Resident and the entire EPR team. The services of this resident were lost as a result, a problem in a clinical computing project requiring iterative development and frequent change. This is a concept that seems beyond the cognitive grasp of this type of executive. This is a typical example of the problems caused by progress-inhibiting bureaucrats who seem common in healthcare. (In a sense, current healthcare turmoil is beneficial in that it may cause bureaucrats who cannot handle rapid technologic change, or who are incompetent, to seek jobs elsewhere.)

Unfortunately, healthcare IT is never plug-and-play, and in IT a person is either part of the solution or part of the problem. Such executives are the latter. One thing is certain: patient care ultimately becomes the unfortunate victim of such behaviors and beliefs. The presentation on healthcare IT to the panel of senior industry CIO's was actually never given because the informaticist left the organization due to its chronic casuistry and culture of mismanagement.

It is interesting to note that many such executives in healthcare, such as in this example, have no background in either medicine or in information technology.

Intranet server or rocket science? A hospital MIS dept. fails on basic tasks

A three-hospital integrated delivery system invested approximately a quarter of a million dollars in online access to its financial databases, as part of an "executive information system." Gerald Nussbaum, a consultant with Hamilton HMC, New York, noted the project yielded little return due to a number of major errors in very basic areas.

First, the intranet as set up suffered from technical problems. It lacked sufficient server capacity and lacked adequate bandwidth. Worse, it suffered from flawed programming such that database queries timed out, causing report requests to fail.

But basic technical errors weren't the only problem. The reports that were produced were not formatted to print in a way that staff members desired or were accustomed to, causing frustration even when reports were produced by the system. [From Health Data Management, Nov. 1999, p. 62.]

Such basic technical and workflow errors are often secondary to basic mismanagement by project leaders, either due to micromanagement by their non-knowledgeable superiors, or by direct acts of commission or omission due to insufficient skills and insights in information science, healthcare, and IT itself.

It must be remembered that IT is only a raw tool. Only with proper insights in the domain area, in information science and in user interaction design (a research area that addresses how computer applications behave, communicate and inform) can IT be implemented to facilitate delivery of useful information. This is especially true in complex healthcare environments.

It often surprises me when adverse outcomes in healthcare IT are treated differently than adverse outcomes in other fields, such as in clinical medicine itself. If a contractor builds a building with an inadequate foundation and concrete and the building collapses, this is attributed to incompetence at best, and criminal behavior at worst. If a clinician fails to diagnose a cancer or has an adverse patient outcome due to suboptimal therapy, this is called malpractice.

Yet, in healthcare information technology it seems such words are forgotten when the causes of failure are dissected. Instead, one sees or hears only milder, indirect words. One never hears that a patient's adverse outcome resulted from "delayed clinical progress and cost overruns due to technical or sociological issues." The term malpractice is used. Yet, one rarely hears terms such as mismanagement to describe why clinical computing or other healthcare IT projects fail. It is ironic that healthcare IT seemingly gets treated preferentially or with "kid gloves" compared to the very field it is supposed to facilitate: clinical medicine. The dynamics of this phenomenon deserve further study.

A thousand MIS personnel cannot merge two healthcare systems?

The leaders of a newly-merged multi-hospital integrated delivery system have given up on the two-year-old merger of their distinguished academic medical centers. "The results of the merger have been even more disastrous than had been anticipated," said one hospital staffer.

After posting an estimated $43 million in losses over its life, officials said it was decided the new system will be dismantled. The two university systems that made up the merged entity are to go their separate ways.

"With great anguish I have concluded that, in our efforts to find bold solutions to the problems of academic medical centers, we have taken on too much," one of the University's presidents said in an Oct. 28 letter to the other University's President. "We have failed to achieve a new common culture that would provide the wholehearted support needed." The letter outlined his desire to unwind the financially troubled merger. The 1997 merger had brought under one umbrella four hospitals with a total of 1,350 beds, with two hospitals coming from each University.

The decision came less than three months after the university presidents sent a joint letter to the system's board challenging the merger and asking for a review. The top two executives at the merged system subsequently resigned, and a state audit outlined the merger's financial shortcomings.

The merger's architects originally predicted a $65 million profit in fiscal 1998 and 1999. But in the most recent fiscal year ended Aug. 31, the system had actually realized an operating loss of $86 million and a net loss of $73 million on operating revenues of $1.5 billion.

Instead of reducing staff, the system had added nearly 1,000 employees during its first year and a half, primarily to integrate financial and other information technology systems. The attempted information system merge was running far behind schedule and had not been highly successful. The cost of merging the two systems' computer networks jumped fivefold, from the original estimated $25 million to a whopping $126 million.

A troubled-hospital management consultant "rescue" firm was called in. A leader of that firm stated that "A poorly executed merger causes trouble; there's no doubt about it. I think there were certainly execution difficulties in this one. I think it was a good concept that was not executed as effectively as everybody would have liked it to have been."

He also stated that the projected cost savings were real, but the merger's leaders didn't pursue them hard enough. Among specific failures were a lack of meaningful consolidation, an unwillingness to cut expenses and expensive corporate overhead, he said.

What has been missed is why 1,000 employees were unable to merge the information systems of the two institutions. One thousand I.S. employees should be able to merge General Motors. Considering such a number amounted to about one I.S. person for every 2-3 physicians in the system, this is an astonishing failure.

It is apparent that MIS in this situation was not operating very efficiently (in fact, spectacularly poorly may be a more fitting description), but unfortunately there rarely are any "morbidity and mortality" conferences to address such shortcomings. Healthcare IT seems to exist in an isolated, siloed environment, immune to the same critical scrutiny and discipline that healthcare itself is subject to. Metrics and standards for healthcare IT are necessary. A system of "managed computing" analogous to the system of "managed care" that's been placed upon healthcare itself (on the basis of measuring and improving efficiency) may be of great benefit to the healthcare industry.

The cost of lost opportunity: Medical Informatics can't gain a foothold (4 stories)

A reader in the United States writes:

Thank you for your messages to the CISWG listserv -- and for your web site. As a recent graduate of a medical informatics training program, I have devoured most of it and am now taking the time to digest and reflect. Currently I am struggling in a relatively new informaticist position for me and for my organization.

Two years ago I accepted a position with a not-for-profit integrated healthcare delivery network. Though I was not a novice in the business world, my excitement upon graduating and joining the "real world" again may have contributed to the "blinders" I was apparently wearing during setting up the position. My far-too-many bosses (problem #1) understood that to have a medical informaticist on staff would be a good thing on paper -- but claimed they didn't really know what to do with a person with this expertise. I attempted to help provide structure to my position and responsibilities. Unfortunately, I soon ran into some well-established organizational and cultural obstacles which were not initially apparent that prevent me from applying my informatics expertise, to the detriment of the organization.

In any case, the time has come to fish or cut bait, as it were. We have a new CIO who, although not informatics or medically-trained, seems to understand that IT isn't just about hardware and software. For example, he is proposing a Medical Management team led by clinicians that, in the course of the larger scope of their work, would help set IS priorities (whatever that means). Perhaps that has potential, if the team is not just a figurehead. Not surprisingly, I had proposed a similar idea a year ago. The executive clinicians had loved my proposal. IS ignored it and would not allow me to continue work on it, and everyone else got involved in planning for the new budget year, etc. etc., so it died. Perhaps this was just a classic case of political marginalization as your site indicates. It certainly didn’t help the organization in any way and may have harmed it in the long run, strategically and financially.

The present challenge: finally, I have been able to schedule a meeting with my current supervisor, a Director of Clinical Information Systems (not an informaticist), our new CIO and an executive clinician on staff. The topic is "Who am I in this organization? Exactly what am I going to do? And where organizationally do I belong?" As if the answers weren’t obvious. That’s like asking where a surgeon belongs. In the operating room, perhaps?

I am preparing to present some very concrete, realistic ideas that are in line with what I understand of the priorities of our new CIO and the corporation as a whole. My bottom line is whatever responsibilities we agree to must be supported by the appropriate organizational position, authority, and resources.

Truly, I am not on some sort of a power trip here. I just want to spend more time doing meaningful work than wringing my hands in frustration. Above all, I don't want to give up and move on prematurely. Nevertheless, I am aware that my pride in not being a "quitter" may be getting in the way of making the decision to cut my losses and move on. My greatest concern is that I am not growing. Practicing Medical Informatics is not just a job for me; it is my chosen profession and an integral part of my personality and life.

I am not a clinician, although none of the people in IS are either, nor do they have any formal medical informatics background. I have been and continue to be diligent in learning all the clinical material I can -- reading, attending seminars, rounding with physicians and nurses, asking lots of questions. I hold a Master’s in Organizational Behavior, did some time with a Big 5 consulting firm, conducted my research in data mining of real-world ER / specialty data pertaining to the treatment of acute, life-threatening medical presentations.

It is a shame this organization cannot get its act together in leveraging the expertise of medical informatics in its healthcare IT projects.

A reader in a European country writes:

I've recently taken up a position as Director of Medical Informatics at a not-for-profit hospital. I have been greatly heartened and encouraged by your comments to the CIS-WG (AMIA Clinical Information Systems working group listserve) and the pieces you have on your WWW site.

We are implementing a major-vendor suite of applications (EMR, Order entry, ICU, ER, Surgical documentation, Theatre Management, etc). My five months here seemed to have mirrored a lot of your experience with Information Services departments. The CIO here has a background in health administration and business, with no formal training in computer science and no clinical background.

As you've noted in your postings to the AMIA listserve, the "Director of Clinical Information Systems" position seems all to frequently to be "director of nothing." I too have very little control over decision making for our CIS project, in fact I have been actively excluded from the real decision making process.

One of the problems is that administrations of hospitals make themselves dependent upon Heads of MIS/CIOs/etc to advise them about the set up of projects mostly well before our kind are involved, thus ensuring that power and resources are not shared.

Cheers and keep up the excellent postings and WWW content on your web site.

Another reader in the United States writes:

We definitely have the same problem here. Everything that is not the MIS "gold standard" is considered completely "unsupported" and they will do their best to "get rid of it" - people included!

One of our former attending physicians was on our hospital's MIS-dominated pediatric electronic medical records (EMR) committee. He always told me that his biggest fight, when they were in the planning stage, was convincing the EMR committee that you can't have "people on separate sides of the fence". You need to have physicians that speak and understand computer talk and programmers that speak some "medicine". Otherwise, it will never work, he said. He also pointed out that MIS people ONLY need to be involved in the deployment of the database, not in the development. An informatics-familiar physician should lead that process. This type of thinking, of course, "ticked" MIS off.

It was very difficult for MIS to accept any of this. Eventually they gave in, sort of, and the physicians on the committee picked one of our former neonatologists as pediatric EMR project leader. However, the neonatologist had to do so much "head butting" with MIS, and MIS made the project so politically unbearable for him, that he quit within two years.

An orthopedic surgeon in the United States writes:

An excellent website! I discovered it in a discussion forum on Physicians Online.

I am beginning my "hard knocks" education in medical informatics on the smallest scale: implementing electronic medical records in our office. Although "micro-informatics" differs in many ways from the "macro-informatics" you discuss in your site, there are obviously similar basic principles involved.

Your grim tales of Dilbert-ish CIOs and befuddled healthcare execs would be amusing if they didn't impact so negatively on our ability to efficiently manage patients and patient information. One of our local hospitals "upgraded" their hospital information system with an expensive, user-hostile system which was obviously designed by someone who hasn't the faintest idea of what a clinician needs. Example: when I request my rounding list, I receive a gigantic compendium of every patient whom I've "encountered". This means that my inpatients are scrambled with discharged or even deceased patients, consults, patients for whom I'd given voice orders while on call, etc. There is no way to sort through this mess, and I have to resort to checking the census floor by floor to find my inpatients. Complaints to the "help desk" yield no useful information, only suggestions to attend additional "training sessions" (which are 50% propaganda) and the assurance that "this is the best patient management software available". Despite the superlative qualities of the software, we have been informed it will be "upgraded" again next year!

Be careful not to attribute to malice that which can be explained by mere stupidity...

A single informaticist could have prevented this South Carolina clinical IT debacle (hyperlink)

Problems of basic leadership: dangers of incorrect CIO choices

A large hospital in the United States hired a new president who had quite limited knowledge of computers. This hospital had previously tried unsuccessfully to implement a hospital information system (HIS). The new president set the HIS area as a top priority and hired a friend and former colleague whom he trusted as his chief information officer (CIO). This colleague had no background in medicine or healthcare. A flamboyant character to say the least, this new CIO swept into the organization, loudly announcing that he had come to bring enlightenment to the technological barbarians.

At the more personal level, he often lamented loudly and long to anyone who would listen about the horrors of living amid provincials, far from his beloved and sophisticated home.

After considerable deliberation, the CIO selected a system from a new division of an established older company that had no experience in the health care industry. Further, the decision was made with little or no user input and with limited inputs from the managers of the other major systems with which the HIS had to connect.

The hospital president strongly supported his CIO's choice, and millions of dollars were spent on the new system. The systems people were never able to get this system to work. One disastrous crash followed another. Finally, the hardware was sold for pennies on the dollar, and the CIO rode off into the sunrise toward his beloved home.

Incidentally, the same hospital then selected another person to head its computer efforts and settled for much more modest goals. Instead of an HIS, the hospital implemented a basic hospital accounting system that satisfied its administrative needs. However, the clinical staff, with hopes raised by previous wild promises, was left unsatisfied and frustrated.
[from Organizational Aspects of Health Informatics, Nancy Lorenzi and Robert Riley, Springer-Verlag, 1995.]

Perhaps the most significant shortcoming in healthcare IT

The preceding stories represent suboptimal use of resources, intellectual capital, high cost of lost opportunity, and risk to patients and to the well-being of healthcare organizations. The people in these stories all note a "metaproblem": the difficulty bringing the obvious problems to the attention of senior healthcare leadership, and be heard and have significant action taken. Politics is commonly one of the problems, although just as frequently the reported problems are not well-comprehended.

That it is very difficult to have such problems dealt with decisively speaks to a weakness in current healthcare leadership structures. That these stories are apparently commonplace should be troubling to all who think critically. The individuals currently charged with planning and implementation of healthcare information technology, in particular healthcare executives and CIO's, must accept an authoritative role for clinicians and informaticists in healthcare IT decisions. In addition, when executives are made aware of problems with clinical IT by clinicians and informaticists, they need to see, look, listen, and pay very careful attention to the messages. Once given information on the problems, they should turn to the clinical informatics specialists and allow them to address the problems in a collaborative manner.

In summary, clinicians and informaticists need much stronger authority in clinical computing. A system where critical decisionmaking about clinical IT is made by executives who may be unqualified must evolve and become more appropriate to patient care needs.

This site calls for such changes in healthcare, consistent with the compassionate patient advocacy traditions of the medical profession. Comments?