Keywords: failures,debacles,Informatics,medical informatics,medicine,MIS,clinical computing,management computing,financial computing,management information science,management information services,management information systems,healthcare IT,information technology,territorial issues,politics,organizational dysfunction,expertise,leadership,management,management fad,management mysticism,skill,ability,WWW

Typical examples of healthcare IT mismanagement

Examples of preventable, costly healthcare information technology failure As healthcare information technology (IT) becomes increasingly more complex, and as it supports increasingly complex medical science 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. IT personnel in hospitals often believe that mastery of computers supersedes or actually renders unnecessary the mastery of medicine in leading and controlling implementation of clinical computing tools. Yet, mastery of applied IT is in large part mastery of process and tedium, 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 is evidenced by the fact that most areas of IT can actually be done well (and often are) by those with little or no formal training. Medicine, on the other hand, 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 exposure to a huge body of biomedical knowledge, and significant practical experience. The belief that mastery of IT process and tedium positions IT personnel to lead and control implementation and operationalization of 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 whitewashed quality to publications about healthcare IT regarding these issues. I believe, however, that depth of understanding of any subject comes from the Hegelian dialectic of thesis and antithesis. If you don't consider the negative sides of a domain, you're not developing a deep understanding or accurate model of the domain. In addition, such 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 anesthesia during surgery. A critical reader might question why articles about IT personnel needing to allow clinicians to participate in healthcare IT still appear in print. These familiar stories of healthcare IT failure and organizational discord 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. These stories are dedicated to medical informaticists, whose personnel strive hard to utilize computers to improve the quality, science and art of medicine.

### INDEX: Problems of basic leadership: dangers of incorrect CIO choices Serious clinical computing problems in the worst of places: an ICU Muddled thinking: a major cause of healthcare's dangerous lag in Y2K remediation MIS inadequacies in tough clinical environments: an invasive cardiology example Inadequate data modeling causes Medicare misallocation of billions New technology under tinkerers: how one person can impair progress for entire organizations Disrespect for the needs of clinicians: platform bias taken to an extreme University mistreats its young informaticists, destroying clinical IT and causing an international fiasco Chaos from MIS mismanagement of a clinical information system project Salesperson performs frontal lobotomy on industry healthcare group Insufficient IT management depth results in Justice Dept. investigation Who serves whom: physicians felt completely unnecessary in clinical IT decisions Cultures of mismanagement: toxic to healthcare quality Intranet server or rocket science? A hospital MIS dept. fails on basic tasks A thousand MIS personnel cannot merge two healthcare systems? The cost of lost opportunity: Medical Informatics can't gain a foothold (4 stories) Abusive IT: technology making clinical work more difficult A single informaticist could have prevented this South Carolina clinical IT debacle Perhaps the most significant shortcoming More stories to come - please submit yours by email

### 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). 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.]

### 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. Postscript: 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 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 "GOMCL" (get out of my 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. Postscript: This heart center information system in its first two years of operation has allowed this organization to save well over a million dollars in cath lab operating costs, through stronger contracting, efficient equipment stocking and utilization, etc. Despite this, in an unfortunate example of the suboptimal management that can result from unqualified decisionmaking in a discipline as complex as healthcare computing, the senior executive assigned to oversee both clinical operations and IT (despite lack of a background in IT) now refuses to allow the chief of cardiology at this hospital to sit on the organization's strategic information technology committee because the cardiologist 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.

### An International fiasco: University mistreats its young informaticists, destroying clinical IT This story of wasted opportunity, attempted misappropriation of intellectual property, ethical and legal improprieties perpetrated by senior university officials, and academic suppression and dismissal comes from the Yale University Center for Medical Informatics. It is a good example of the losses to the healing arts that result from organizational dysfunction. It is also a story about a rare victory of a "little guy" over the powerful "Old Boy's Club." (The story is also a detailed, blow-by-blow illustration of academic "Bahramdipity," a term coined to describe autocratic academics ('Bahramdipity' and Scientific Research, The Scientist, T.J. Sommer, Volume 13, #3, Feb. 1, 1999). Bahramdipity is the suppression of a discovery by the often-egomaniacal acts of a more powerful individual who does cruelly punish, not merely disdain, a person of lesser power and little renown who demonstrates sagacity, perspicacity, and truthfulness. From a story about Bahram of Persia in the fairy tale The Three Princes of Serendip.) Also see a similar story of academic abuses at http://www.justice4t.org.uk/. An informaticist (the first of two in this story) volunteered to take a position as Director of Clinical Informatics for Yale-New Haven Hospital to help customize a new computer order-entry system. The hospital's leadership had decided to mandate the electronic order-entry system for all patient orders, completely replacing paper. It was announced that any physician who would not use this system "could leave the organization." A mainframe-based system was purchased and a huge team was assembled to operationalize it throughout the hospital at a cost of tens of millions of dollars. As the system was implemented and tested, it was realized that as delivered, the system was not easily usable in this hospital's environment due to workflow fit, nomenclature, grouping of screens, and many other issues involving features and functionality. The informaticist was enlisted to customize the thousands of screens, screen relationships and screen flow (logical arrangement of screens), order sets, data, and so forth. The informaticist was to report to two bosses: hospital MIS and University informatics. The territorial issues of working in an MIS department, and the precarious position of reporting to two bosses, were bad enough, but did not prove to be the biggest challenge. This informaticist spent over a year spearheading and overseeing the revisions to the order-entry system. Even after this extensive work, because the system was simply mandated by administration, the extra time, effort and work required to use the system was strongly resented by many staff and attending clinicians, and unfortunately this resentment was targeted to a great extent on the most available and vulnerable target, the informaticist. One senior physician actually refused to attend any meeting where the informaticist was present, another threw pencils at the informaticist after an argument, and the informaticist's name came up in a very negative manner among the house staff who spoke as if they wanted to burn him in effigy (if not literally). The medical leadership of the medical center were not very sympathetic nor supportive to the informaticist. Despite a successful technical implementation of the order-entry system, the sociological ramifications and negativity experienced by the informaticist caused him to resign suddenly. After six months of purposeful unemployment for R&R, this informaticist took a position outside both academia and hospitals, with a healthcare IT vendor. Meanwhile, another faculty informaticist at the University who had been working on electronic medical records was approached by the hospital's senior medical leader, Ed Cadman (a person who was both Chief of Staff and Senior VP for Medical Affairs, and had been the former Chairman of Internal Medicine) to take over the role of physician liaison and Director of Informatics at the Hospital. This informaticist had a background very similar to the first informaticist, including a Medical Informatics postdoctoral fellowship at the University, and was working on clinical IT for a complex research setting in Saudi Arabia. The second informaticist began a series of formal interviews with Chief of Staff, clinical leaders and MIS. The interviewers were pleased with the results of the interviews. The Chief of Staff then wrote a letter to the informaticist stating that he would be "delighted to create a position for you...the organization needs people with your skills and commitment." The Chief of Staff also promised the informaticist that the new position would be structured so as to avoid the problems experienced by the departed predecessor. A reasonable salary level was negotiated and agreed upon. The Chief of Staff informed the informaticist that the hospital had extensive funds for expert resources to ensure this project was a success. In addition, the position was to report to this Chief of Staff himself, not to MIS or to the academic Informatics department head. The informaticist was also told the Informatics department head, Perry Miller, was "overcontrolling" and had problems getting along with people, and such behaviors had been a strong factor in the resignation of the original hospital Director of Informatics. The informaticist, a person of high standards who believed strongly in collaboration and fairness, attempted to defend Dr. Miller, saying that perhaps various territorial issues were causing him anxiety. The informaticist defended his boss despite earlier signs of exactly the behaviors mentioned by the hospital Chief of Staff. Miller once coldly asked the informaticist how he could "get rid of" one postdoc he didn't like, who had difficulty writing research papers, as rapidly as possible. (The informaticist instead volunteered to help the postdoc, and the resulting paper was successfully published. That postdoc is now head of informatics at a major New York teaching hospital.) In addition, the informaticist had been prohibited from submitting a paper for publication because an algorithm he'd developed showed significantly better results than an earlier NIH-sponsored work by the Informatics department head. The Informatics department head wanted the results "adjusted to more closely correspond with my own", which the informaticist refused to do. The paper remained unpublished due to this academic suppression (and perhaps worse). (Miller was a stockholder and consultant for a medical software company registered in his wife's name, who was also an informatics faculty member. This private company was staffed by a scientist who also worked in the university Informatics department, and a postdoc in the department was enlisted to write code for the company as an "academic project" without pay or acknowledgement.) In any case, it was apparent the Chief of Staff did not like Miller. The informaticist had seen such personality issues many times in academic settings and at this point did not think too much of it (as it turned out, unfortunately so). The informaticist agreed that he would take the new informatics position after returning from a month-long research trip to Saudi Arabia to install the software application he'd authored. He was promised that the new position would begin shortly after his return. As a due diligence, the informaticist registered his software with the university's technology transfer office before his departure, in accordance with University policy. He felt it contained innovative and marketable ideas. According to the technology transfer office and the University copyright policy on such works, they could help market the software, although copyright remained with its faculty author. Signs of trouble appeared very early. Shortly before the Middle East trip, Miller had seemed intimidated by the informaticist's incorporation of a complex controlled vocabulary into his program. It took him only a few days to implement this vocabulary. The informatics department head commented in a tone of disbelief that "it took another staff member over a year to do that a few years ago." The informaticist sensed something amiss and tried to disarm his boss by saying that he had "better programming tools to work with" compared to several years prior, which was at least partially true. Miller repeatedly cut off the informaticist at a meeting with the medical school's director of administrative computing, not letting him get a word in edgewise. The administrative computing department was seeking new user interface ideas for an executive application being developed to cut costs. The informaticist wanted to point out that the novel user interface concepts he'd developed for the Middle Eastern computer program might be adaptable, but was interrupted repeatedly by Miller. Miller's wife, Sandra Frawley, a member of the department, sent the informaticist an unexpected email "nastygram" regarding not having informed her about some very trivial matter on another project. This type of communication from Frawley had never before occurred. The informaticist had worked in tough environments before and tried to ignore these atypical events. On the evening prior to his departure for the Middle East, the informaticist received a mysterious departmental email from Miller about a special meeting to occur on his first day of travel. The topic of the meeting was not mentioned. Signs of trouble continued. The informaticist's distance was taken advantage of. Several days after he arrived in the Middle East, he received an international phone call from a consultant friend. A minor contract the informaticist had helped arrange between his university clinical department and the consultant (for customization of an administrative computer program) had been usurped by Miller without the informaticist's knowledge or involvement. According to the consultant, the already-written contract had been turned over to another faculty person in the informatics section, and the work was to be performed for free. The informaticist thought this embarrassing breach of etiquette was particularly odd, considering the faculty person in question was extremely busy and had his hands full writing bioinformatics tools. It was a tremendous waste of this person's talents to write trivial administrative programs. (This opprobrious behavior by the Informatics department head turned out to be a warning sign for what was to come.) In another odd sign of trouble ahead, the informaticist was able to use the Internet overseas and logged into the department Sparcstation. When he attemped to use the UNIX 'talk' feature to open real-time dialog with his colleagues, his overtures were mysteriously ignored or quickly dismissed. He'd though people would have been excited by typing to him real-time from halfway around the world. The informaticist and the computer program were extremely-well received by the Middle Eastern hosts. So well did the trip go that his hosts offered the informaticist a full-time position in medical informatics in their hospital. This was despite the fact that he was of an ethnic background not even permitted entry into their country just a few years prior. Ironically, the positive feedback from the Middle Eastern hospital to the informatics department head probably sealed the informaticist's fate (it seems no good deed goes unpunished in a pathological environment). It was on his return from the Middle East that this second informaticist's real troubles began. Upon the informaticist's return, he found the environment had changed completely. His boss, Perry Miller, demanded copies of all his correspondences with the hospital and the Chief of Staff. (It should be noted that the hospital was organizationally not part of the University.) Even more dramatically, he left an intimidating handwritten note with those demands taped to the informaticist's workstation, instead of sending it by email as he had done with all messages over the prior several years. Miller also informed the informaticist that after a meeting that occurred while he was overseas, it was decided that the salary level for the new hospital position would be one-half (50%) of the figure he had agreed upon with the hospital Chief of Staff. Due to the concerns of the MIS director, he said, the position would also report not to one, not to two, but to three individuals, Miller himself, the hospital Chief of Staff, and the MIS director, who would meet after six months and decide "if the informaticist was doing the job well enough to merit a full salary." Miller also strongly discouraged the informaticist from seeking a job title of Director at the hospital. He thought a manager or consultant title more "appropriate." This opinion was given with a distinctly odd tone. It was an especially odd request, considering that the first informaticist in this story held exactly that title, and that the Director title (at minimum) was needed for credibility with powerful hospital executives and clinicians. (The reasons for this 'advice' from Miller would not become apparent until several years later, below.) In reality, Miller should not have had authority to make such decisions for the hospital, which had its own independent HR department. How he may have had such influence was not to come out until several years later, as described below. The informaticist was shocked by the changes, and concerned that the position as described now was unworkable and that the salary issue as above was absurd if not illegal (a "trial salary" as it were, and worse, at a level that came out to be 25% lower than the salary paid to the first informaticist). However, the Chief of Staff seemed afraid to talk to him and was unable to reverse these "changes." Within a few weeks, the informaticist was informed by a middle MIS manager that the budget did not contain enough money for another FTE (full-time employee) and that the position of Director of Clinical Informatics at the hospital was therefore no longer available. Unfortunately, the leadership of this Middle Eastern country changed, and research funding to the University from this country was to be discontinued. (To this day, the informaticist still wonders if some of the events below contributed to the Saudi funding discontinuation.) Shortly after the letter from the middle MIS manager, the informaticist was informed by Miller and geneticist collaborator Dr. Ken Kidd that his University appointment would end as well due to "lack of funds". (The informaticist had received a letter from the clinical department overseeing informatics that talked of significantly increased revenue for the year.) The dismissal letter from Miller and Kidd also mentioned "if the Saudi project does continue, we will try our best to insure it includes continuing support for you." Ominous choice of words, though the informaticist... (The informaticist remembered a comment made a few months prior to his trip to the Middle East. The informaticist was laboring over a grant proposal with a pharmaceutical company collaborator, seeking funds for an advanced IT application. Miller boasted and laughed about how he could write the proposal "in just a few hours." This was a clear put-down of some kind, and he did not offer to help.) It also had not helped that Miller had refused to take on a self-supporting physician from Saudi Arabia as a postdoctoral fellow for informatics training. The informaticist had interviewed the candidate while overseas and found him very well-qualified, feeling he would be an asset to the field. Unfortunately, the Informatics department head had emailed the physician's sponsor (the head of IT at King Faisal Specialist Hospital) that he could not make any commitment, and that such an appointment needed to await word of the continuation of the country's funding of the university. This was rightly viewed by the foreign collaborators as an insult, especially since Miller had a number of foreign nationals from Asia and India working under his aegis. The informaticist encountered the Saudi head of IT at a conference the following year and heard his expression of incredulity about this decision by Miller. Miller, who has his own private software company as an outside venture, also demanded that the informaticist surrender his current research work and computer programs prior to departure. He told the informaticist that the program was "university property" since the university "paid for it." He said the Associate Dean for Scientific Affairs, Dr. Carolyn Slayman, who had been a PI of the overall international project, agreed. However, Miller would not commit to a role for the informaticist in any future use of the work. The informaticist pointed out that the university copyright policy stated: "the university disclaims ownership of works by faculty...except where the assignment explicitly states that the work will be owned by the university...the university advances no ownership claim to copyrights...the copyright policy is legally binding." The informaticist noted that no special agreement regarding university ownership of his work had ever existed in this project, implicitly or explicitly, nor had such an agreement ever been discussed. Miller did not care at all to hear about the copyright policy or the informaticist's already-established relationship with the University's Technology Transfer office regarding the work, which was of potential commercial value. Miller simply wanted the source code turned over without any agreements or understandings on its use. It was as if Miller simply felt himself above any university policy or law that infringed on his unfettered use of others' work. The informaticist wrote a polite letter to Dr. Carolyn Slayman, Sterling Professor of Genetics and Associate Dean for Scientific Affairs, letting her know that he wished to continue a collaborative role in the further development and use of his own work. He sought her thoughts on the matter. The letter was ignored. Simultaneously, geneticist Kidd, who was a close friend of Miller, also joined in the effort to "find a way to take the software away" from the informaticist. (Apparently these words were used by Kidd, as reported to the informaticist by a staff member in the Technology Transfer Office, Henry Lowendorf). Although Kidd had essentially ignored the software during its development, Kidd apparently found the software highly innovative and potentially useful and marketable upon the software's initial roll-out (debut). When he'd requested the software from the informaticist to send to a genetics colleague in France, the informaticist informed him that the university technology transfer office required any such transfers to be preceded by an NDA (nondisclosure agreement). This angered Kidd. He growled about "those damn lawyers getting in the way," but made no effort to have such papers signed so that the transfer could occur. Instead, Kidd tried in a rather disingenuous manner to obtain the software from a scientist from Saudi Arabia, Marios Kambouris, who'd become a friend and colleague of the informaticist, while Kambouris was visiting Yale. Kidd requested the software and the instruction manuals from Kambouris repeatedly while failing at all to mention that there was an intellectual property issue. This proved unsuccessful as Kambouris had been forewarned about the dispute by the informaticist. This was deeply embarrassing to both Kambouris and the informaticist. Kambouris had frantically emailed the informaticist seeking advice when confronted by these requests from Kidd. Actually, this should not have surprised the informaticist. Several months before the informaticist's departure to the Middle East, Kidd (who'd been to this country several times) called the country's culture "very odd" at a department meeting. Shortly after arriving in Saudi Arabia with the informaticist, Kidd complained that there was an insufficient supply of paper towels in an airport bathroom he used, and made snide remarks to the informaticist about this "being typical of a third-world country like this." The informaticist was shocked at such a rude comment, especially considering the gracious hospitality shown by his hosts. The informaticist also recalled that Miller had called this country "weird" after an exploratory trip there a few years before. As a member of a minority group himself, the informaticist could only wonder what the blue blood Informatics department head and geneticist thought of his background. The irony of this situation was that Kidd was a leading figure in an international genetics study of indigenous peoples, the Human Genome Diversity Project. The study was strongly opposed by a number of such indigenous populations around the world. Despite promises to the contrary, the indigenous populations feared misappropriation of their genetic material and of commercial discoveries made from their blood and tissues. Perhaps those fears were not inappropriate. (This incident apparently cost Kidd some rare blood samples he wanted from Saudi Arabia. Kambouris, upon his return to Saudi Arabia, told his boss, a member of the Saudi Royal Family, that "the informaticist had really gotten screwed." This apparently did not go over very well, in terms of trusting American geneticists with Saudi citizens' genetic material and confidential medical records.) The levels of hypocrisy shown by the turn of events over the software, and the rude and perhaps racist comments, disappointed the informaticist to a degree unparalleled in any of his prior career experiences, some of which involved working in a big-city transit authority dealing with labor unions, workman's compensation, drug testing and abuse, and the like. (It was this experience that perhaps gave the informaticist the strategies and tools to fight effectively. Most scientists would probably not have been able to respond well. The principals of this story forgot to ask themselves the question "do we feel lucky?" prior to committing their actions.) In an attempt to defend his intellectual property, the informaticist once again pointed out to Miller and Kidd that by written University policy, copyrights belonged to faculty, not to the University. Miller did not care to hear anything about this and raised the issue of insubordination on not following his orders to turn over the intellectual property. This did not surprise the informaticist, as he had already observed Miller misappropriate the work of postdoctoral fellows into his personal company's products without attribution. (As an aside, with modern computer code being so complex, the informaticist was amazed at the apparently backwater "FORTRAN mentality" of these supposedly world-class people. They clearly coveted a single instantiation of a person's work -- a computer program whose misappropriation and modification would be quite difficult without the author's involvement -- over what was really important, a modern computer professional's mind and creativity. This shows a near-complete misunderstanding of what's strategic in IT, namely good people and creativity, vs. transient and tactical, e.g., a specific instantiation of a leader/creative person's work.) The department yearbook was published, and not surprisingly it failed to make any mention of the informaticist's Mideast trip or work. When asked about this, Miller replied that "he'd forgotten to put it in." Miller was also not very supportive of the informaticist's desire to have the trip mentioned in the academic medical center's monthly news publication. Miller neglected to tell the informaticist about a meeting with representatives of one of the largest pharmaceutical companies in the world, Pfizer, seeking collaborations. Such a collaboration could obviously have preserved the informaticist's university position, or given him an employment opportunity with the pharmaceutical company. The informaticist had not intended to be in the office that day, and only found out about it by accident the afternoon of the meeting. He attended, but when he tried to speak he was cut off by Miller. Miller actually laughed and found funny a rambling, incoherent, disruptive letter shown to him by the informaticist. The letter had been sent to a number of the informaticist's associates by a close relative who'd recently suffered a severe psychological trauma. The informaticist had shown it to make sure its source was understood, and to seek possible sensitivity towards the family pressure the informaticist found himself under simultaneously with the career stress of the intellectual property issue. Instead, the informaticist found only the most callous insensitivity. Coming from a fellow physician, the laughter was all the more offensive. Far worse, he questioned the informaticist about the "possibility" the letter was written by the informaticist himself in the middle of the night and that he didn't remember doing so, perhaps due to effects of "sleeping pills" or drug abuse of some kind. Such a reprehensible insinuation, right out of the "clear blue sky", shocked the informaticist and his family immeasurably. Due to an intolerable work environment, the informaticist cleaned out his office unannounced over the weekend and submitted a letter of resignation the following Monday, several months before the official end of his appointment. Even after his departure he received emails from the informatics department (sent by a staff member who'd been requested to do so by Miller) and Kidd for the software, and even a request to show the staff programmer "how it all worked." The informaticist asked for a written request from Miller. This was refused in an email from Miller himself. The informaticist then sent an explicit notice of copyright to the university, as advised by an intellectual property attorney he retained. In the end, as a result of this dispute, the informaticist found himself blacklisted by his former department and the University. His medical staff appointment at a new medical center was deliberately blocked. Miller refused to fill out repeated requests for references and verification of postdoctoral training. Several friends of the informaticist told him "weird things were said about him at a party at Miller's home." On two occasions, Miller told one caller in a reference-checking request that he "didn't have the time to give a reference," even when the caller said the need was urgent. In addition, there was an outright disavowal given to this caller of the informaticist's training at Yale University ("sorry, never heard of him") by Miller's second-in-command, the associate education director Rick Shiffman, with whom the informaticist had enjoyed cordial relations. Needless to say, this was a disgraceful and egregious violation of the University's written policies and the state's labor laws. (Fortunately for the informaticist, but very unfortunately for Miller and Shiffman, this particular caller was a private detective hired by the informaticist. The detective's report is quite chilling, showing an utter disrespect for the career and livelihood of the informaticist and his family.) The extramural programs division of the National Library of Medicine was kind enough to send the informaticist a letter verifying his postdoctoral training at the University when informed of this problem, but the letter was insufficient for the requirements of new medical staff appointment. It was also highly unusual for NLM to have to verify such training because the funded University refused, needless to say. The NLM otherwise said they could not intervene in this matter, not having authority to do so, even though they extensively funded Miller's informatics training program. To save his career the informaticist had to file a blacklisting grievance with the state's Department of Labor. He initiated a lawsuit as well. Worse, this terrible situation was accompanied by the refusal of a lawyer in the University's Office of General Counsel, Susan Sawyer, to enforce the University's policies on such reference requests until the intellectual property issues were settled, a rather unsubtle form of extortion. The informaticist also found himself locked out of any further interaction or communication with the Technology Transfer office on the use of his work. The Technology Transfer Office said it could not share with the informaticist any information about companies to whom the software had been shown, or whether any income had been generated. (An uncooperative cooperative research office, as it were.) This was in violation of provisions of the federal legislation that set policy on University technology transfer, the The Bayh-Dole Act of 1980, and explicit provisions in the University's own copyright and patent policies guaranteeing income-sharing. An uninvolved informatics department system administrator (and friend of the informaticist), Matt Healy, was apparently ordered by Miller to retrieve copies of the informaticist's code from encrypted departmental backup tapes. Despite written assertion of copyright by the informaticist, the system administrator retrieved the code from the tapes. This demand had put him in a clear situation of double jeopardy (at risk for becoming involved in possible copyright litigation, or being accused of insubordination if he refused). Placing him in such an uncomfortable situation was very bad HR practice and was probably unethical. It also damaged the friendship the informaticist had enjoyed with his former colleague. Apparently under orders from Miller, department staff members disassembled and examined the source code retrieved by the system administrator, completely ignoring the informaticist's explicit copyright assertion. Then an Associate General Counsel at the university, Susan Sawyer, offered a series of absurd claims and supposed interpretations of case law on copyright issues to the informaticist's copyright attorney. These claims attempted "in every which way but sideways" to prove university ownership of the informaticist's work. (More on this person's qualifications and authorization to practice law appear later in this story.) Sawyer's material included frivolous claims such as the geneticist Kidd having "contributed ideas" and therefore being an owner of the program (completely irrelevant to copyright which applies only to tangible works). An outrageous, absurd claim was even made that another university faculty member contributed a small programming language extension (a 'get file number' function distributed for general use that conveniently replaced about 15 lines of code), giving the university ownership rights to the informaticist's program. This is analogous to saying that using a function such as SQR(X) in Microsoft BASIC (instead of writing a square root algorithm in a few lines of code) makes Bill Gates, the author of Microsoft BASIC, an owner of any BASIC program itself! The informaticist both marveled at, and was saddened by, the idiotic arguments coming from the legal authorities of a university with one of the finest law schools in the world. (Ironically, Kidd had all but ignored the program during its development by the informaticist. His "ideas" included such critical issues such as drawing pedigree diagrams with conventional straight rather than angled lines, and coloring control buttons red, green, and yellow as a cue to their effects.) It's been said that when lawyers can't argue the law, they argue the facts. When they can't argue the facts, they argue the law. When they can't argue the law or the facts, they attack the witness. True to this saying, Sawyer, who made these absurd arguments to the informaticist's copyright attorney, only to be soundly rebuffed through the facts and the law, then circulated a letter accusing the informaticist of acts of computer hooliganism. According to this lawyer, these acts reflected the informaticist's "inability to appreciate or understand collaboration." These "acts" supposedly had occurred many months before his departure from the University and were now being circulated, along with this ad hominem character attack, many months after his departure. These allegations (actually, a condemnation of guilt) were apparently initiated by Miller and were now being heard by the informaticist for the very first time. No opportunity whatsoever had been given to the informaticist to address these allegations prior to their circulation. This was in violation of University and federal policies on fair process, as well as the founding principles of this country's justice system, needless to say. Sawyer also produced and circulated a written statement from another informatics staff member, Xia Liu, a young citizen of China hoping to establish American citizenship. Liu had drafted a very early conceptual working prototype of a novel user interface invented by the informaticist, done to the informaticist's specifications. Now, she made a new claim that she had invented the user interface and that it was copied by the informaticist, and that she had written significant parts of the program itself! Unknown to Liu or her boss Miller, the informaticist had retained in his own personal records detailed, dated lab notes including his original sketches of the user interface created at a preliminary meeting where staff member Liu was not present. He also retained his drawings of it that had been passed out and minimally annotated (with editorial suggestions) by others, in their own hand, at a staff meeting some weeks afterward. It was at that meeting where Liu saw the invention for the very first time. The informaticist had also retained extensive printouts of his evolving code, printed almost daily as he worked. These were annotated in his own hand with planned changes, modifications and improvements, that were then implemented as his code evolved. (As a physician, he'd learned the value of documentation both in facilitating clear thinking and in legal situations.) Yale University never responded to these rather embarrassing disclosures and materials. It is not known if Liu had been pressured into making these claims. She had been having severe personal difficulties, involving an estranged husband who had literally kidnapped their child back to their home country, forcing Liu into a difficult international child-custody situation. Liu left the university several months after making the above claim. For self-protection, the informaticist filed a grievance with the State Bar Association against Associate General Counsel Sawyer for numerous legal practices he felt were inappropriate, in addition to the already-filed blacklisting grievance with the State Labor department. As a result of the informaticist's blacklisting grievance to the State Labor Department, a state field agent began an investigation. Miller actually came within a few days of the Labor Department's issuing a warrant for his arrest for obstruction of the Labor Department investigation, as he repeatedly ignored calls and would not reply to the field investigator's inquiries and site visits. Somewhat spectacularly, as a result of the grievance with the State Bar Association, it was discovered that Susan Sawyer, author of the "hooliganism" letter and the tying of the University's reference letters to the intellectual property issue, was found to have never passed the State's Bar Exam. Sawyer was therefore unauthorized to practice law in the state. In fact, by state law it was not legal for such a person to even use the title "counsel." The informaticist, at the suggestion of the State Bar Association, therefore filed an "unauthorized practice of law" grievance against this unauthorized practitioner, somehow employed as Associate General Counsel at this prominent university. The University's Office of General Counsel was now forced to intercede, removing unauthorized Associate General Counsel Sawyer from the case (and merely agreeing with the Bar Association to change her title, since state law forbade the use of the title "counsel" by a person who had not passed the Bar exam.) This was a University oversight that to this day the University denies as negligence. In medicine, unlicensed physicians who injure patients are treated somewhat differently than a title change and a slap on the wrist. In fact, the University disingenously refused to turn over documents about these matters to the informaticist's attorney during legal discovery, based on a claim of not knowing what the term "the alleged incident [of hooliganism]" meant in the requesting documents. Likewise, the State Bar Association would not turn over information to the informaticist or the Connecticut Freedom of Information Commission on how they made the decision not to sanction Sawyer. (Sawyer had hired a prominent Yale-trained attorney to represent herself in this matter, so this outcome is not surprising.) The University Office of General Counsel also put in writing to the Labor Department that University human resources policies would be followed, and that behaviors by Miller and Shiffman such as refusal to verify the informaticist's training at the University and outright disavowal of the informaticists' ever having worked in the department would cease. The malicious accusations by unlicensed lawyer Sawyer against the informaticist were also retracted. However, the informaticist had incurred legal fees of over ten thousand dollars that the University refused to reimburse. The university's official position was put in a letter to the informaticist. A university Deputy General Counsel, William Stempel (authorized to practice law in this case; the informaticist checked) wrote that he "does not at all agree with suggestions that 'basic fair play' was not followed." The Technology Transfer Office and the Office of General Counsel still refused to share information about any possible commercial interest or income generated from the informaticist's software. Meanwhile, the Director of the Technology Transfer Office was reported in a national publication to sit on the Board of a company he helped found that does research in an area related to the domain of the computer program. It took intervention by the office of Senator Joseph R. Biden, from whom the informaticist requested assistance regarding the violation of the Bayh-Dole act, to finally cause the Office of Cooperative Research to divulge information about what was done with the computer program. (The University denied that any income had been generated. However, the Office of Cooperative Research refused to reveal what companies or organizations they might have shown the work to.) Somewhat predictably, the Medical Informatics departmental Web pages were altered to "erase" mention of both the computer project by the informaticist and any mention of his work as a faculty member, despite numerous requests by the informaticist for restoration of the information. This persists to this day. The Chief of Staff at the hospital, Dr. Ed Cadman, left the organization himself, to take a better position with higher-quality people, in a much nicer climate (figuratively and literally), as Dean of the University of Hawaii School of Medicine. He was kind enough to offer the informaticist a letter of recommendation that reflected the informaticist's accomplishments and reputation accurately. This letter helped saved the informaticist's career. One very tragic aspect of this story was that the informaticist had been, and in the new position had planned to continue to be, a strong proponent and ally of Perry Miller. Instead, the informaticist was forced to oppose his former boss and mentor to save his own career. Multiple written and personal attempts to obtain assistance from numerous university officials, including Roberta Hines, the department chair over the informatics section, associate dean for scientific affairs Slayman, the medical school dean, the deputy provost, the provost, the equal opportunities representative, human resources, the university president's office, and others were simply ignored. The informaticist could never satisfactorily explain this "blind eye" towards Miller's behavior until several years later. The informaticist found out several years later in an Yale obituary that the Miller's father had been an influential Dean, an adviser to President Harry S. Truman, and Yale executive of national prominence at the University decades prior. This fact had been kept very low key and nobody else in the informaticist's department seemed to know, either. This perhaps explained to the informaticist the favoritism shown this professor. His father had been alive at the time of these events. (Miller's father had written a book several years prior about his career. It seemed to have been a career of integrity. In the forward, he thanked his son, Miller, and daughter for contributions of ideas and their critiques of the manuscript. Ironically, the copyright of the book rested solely with the father. It seemed apparent to the informaticist that the son was not the father.) The informaticist also discovered that Miller had been a candidate for a multi-million dollar Endowed Chair in Medical Informatics at the University, but that hospital Chief of Staff Cadman (who had supported the informaticist for the hospital informatics position) opposed the candidacy of Miller for the Endowed Chair. Instead, an informatics leader from another prominent university, Dr. Clement McDonald of the Regenstrief Institute at the University of Indiana, was preferred. The informaticist later found out that Dr. McDonald had actually toured the department while the informaticist was overseas (but much later decided not to accept the Chair). The informaticist believed this helped explain a great deal of what had occurred. Perhaps it also explained the earlier resistance of Miller to a hospital title "Director" for the informaticist. Miller may have wanted that title for himself. (One other puzzling event that occurred months before, early in the promotion process, now made sense as well. Minutes prior to the initial, critical meeting between hospital Chief of Staff Cadman, informaticist, and Miller to discuss the Director of Informatics position, Miller had asked the informaticist a most unusual question. He asked the informaticist "Do you have a toothbrush?" The informaticist was perplexed by this question. He told Miller that he didn't keep a toothbrush in his office, and inquired about the purpose of such an odd question. Miller told the informaticist that "his breath was terrible and could be smelled from many feet away." The informaticist was shocked, as he had never before been told such a thing. The informaticist was then even more perplexed by Miller's annoyance at the informaticist's quick action in running to the nearby hospital gift shop for breath mints. It was now clear to the informaticist that this "bad breath" pretense had been an execrable attempt by Miller to disrupt the informaticist's performance at the critical meeting. In retrospect, realized the informaticist, this was not a surprise, coming from a person who once called his own wife an idiot in front of many others at an informatics departmental meeting.) The Ombud at the university, Merle Waxman, had been highly concerned about these events, but expressed a lack of real authority to intervene. The Ombud at Harvard who read this story had this pithy statement for the informaticist: "Your story is a nightmare." (Linda Wilcox, EdM, CAS, The Ombuds Office, Harvard Medical School). True to the highly territorial nature of computers, information and networks, it was obvious the informaticist had gotten caught in the middle of a three-way battle between the hospital Chief of Staff, the Informatics department head (with his powerful political connection and rather tasteless tactics), and the MIS director for influence, territory, and money. The informaticist, to whom the Chief of Staff had written that "the organization needs people with your skills and commitment," nearly had his career destroyed. Not one, but two bright young informaticists were literally mugged and eaten alive by this University, apparently due to political and territorial battles and extremes of back-stabbing. Ironically, the technology issues were quite simple compared to the sociological ones. The principals in this story were approached by a number of the informaticist's colleagues and by the informaticist himself about apologizing for the events in this story, but they refused and continue to shun the informaticist, and rudely so in front of others, at national meetings. Their ego space issues apparently will not permit an admission of wrongdoing or any apologies. Breaking the "unwritten rules" of this academic medical center (i.e., that junior faculty members have no rights, even if those rights are in written policy) is apparently a far more serious matter than potentially criminal violation of state law, fair process, and holding back state-of-the-art healthcare IT progress for an entire community. That point recently became explicitly apparent. A few years after the above story occurred, the informaticist received an ironic email from an IS staffer in the organization he left. The IS staffer had recently seen some of the informaticist's commentary about electronic medical records in an informatics listserv, but had not known of the issues in the story presented here. The IS staffer wrote: We are implementing an interdisciplinary automated medical record at Yale-New Haven Hospital and are struggling to identify an evaluation tool to measure overall success of the project implementation. Open to suggestions or references. Thanks, [name withheld]. Ironically, Yale-New Haven Hospital was only starting on an electronic medical record implementation, while another organization had received the benefits of the informaticist's expertise and had already succeeded in exactly the areas the first hospital was now struggling with, several years later. The electronic medical record system he'd implemented had facilitated documented, substantial improvements in appropriateness and thoroughness of care, significant improvements in immunization and preventive medicine rates, and good acceptance of cultural change by the organization's clinicians. This university seems afflicted with what author Diane Vaughan calls "the normalization of deviance in organizations." Behaviors within the organization that deviate from societal norms of conduct outside the workplace become accepted, due to overgrowth of bureaucracy and 'politics' (a euphemism for intimidation or other unprofessional behavior shrouded in a veneer of propriety). This phenomenon often results in occurrence of significant errors, due to suboptimal use of expertise. See "The Challenger Launch Decision," University of Chicago Press, 1996. (In another strange twist, it turned out that the wealthy retiree funding the Endowed Chair in informatics, Lynn Williams, son of the former second-in-command at IBM in its heydey, had actually been the person who'd led the informaticist to this university for informatics training. They had struck up an electronic friendship years before on the CompuServe "MedSIG" (medical special interests message board). Williams had praised his alma mater and its informatics program to the (future) informaticist. Miller had not known of this connection. When Williams found out what had occurred to the informaticist, he probably was not very happy. It may not be merely coincidental that the Endowed Chair remains unfilled, several years later. Chief of Staff Cadman, who left to become Dean at the Univ. of Hawaii Medical School, told the informaticist that Miller would probably never get the chair. Perhaps there is some justice in this world.) The informaticist in this situation has created a detailed web site about this episode, including extensive document images of related letters and correspondences. He is willing to share this information with others for educational purposes. He may be contacted via an email to this web site's author, at scotsilv@aol.com. Addendum: The informaticist, now in the management ranks at one of the largest pharmaceutical companies in the world, recently saw an article about New Haven's Biotech Boom in the publication "Yale Medicine" that wrote of how well the Office of Cooperative Research (OCR) collaborates with faculty to develop their ideas into commercial products. "The OCR worked closely with faculty whose discoveries had commercial value", the article states. He emailed the URL of the story you are now reading to a number of faculty and senior university officials listed as involved in OCR, including: Henry Lowendorf, Sharon Oster, Ian Shapiro, Ian Ayres, Susan Carney, Benjamin Bunney, Richard Edelson, Richard Flavell, John Geanakoplos, Andrew Hamilton, Susan Hockfield, Pierre Hohenberg, Lawrence Manley, Robert Shulman, Jon Soderstrom, Stephanie Spangler, Richard Szary, and Michael Zeller. The informaticist told these Yale personnel in his email that the "Yale Medicine" statement about OCR apparently had not applied to him, and that only intervention by Senator Biden caused the OCR to reveal whether any money had been generated from his work. In his web logs, the informaticist subsequently noted a number of viewings of this story about his experiences by some of these people whose IP's carry their names (e.g., spangler.hgs.yale.edu), by people using workstations in the Office of Cooperative Research (e.g., cr45.ocr.yale.edu), and by people using workstations in the Office of General Counsel (e.g., ogc15.councel.yale.edu). To date, however, he has not had any replies from any of these people, nor does he expect any. He has heard from friends at Yale that he'd been labeled a "disgruntled former employee", a type of semantic chicanery sometimes used by the powerful to discredit and blame their victims. Readers of this story may find the following story about abuse of a postdoc at another University quite interesting: http://www.justice4t.org.uk/. At this URL is a story of similar injustices and abuses of power at one of France's most prestigious scientific research schools. But it is also another story of a how a scientist can stand up to such overwhelming odds and fight back.

### 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." Postscript: 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...

### Abusive IT: technology making clinical work more difficult (hyperlink)

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

### 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?

Please send me Comments and related material