BLOGSCAN - Health IT Debacle Down Under?

From the blog "Australian Health Information Technology" by Dr David More MB, PhD, FACHI:

Monday, January 03, 2011

NSW Health Has A Full Blown Health IT Failure on Its Hands. As I Predicted in 2006!

The Healthelink Project, which was to provide a prototype for a Shared EHR for NSW has essentially imploded.

Information provided to this blog confidentially confirms both the number of participants in the project and their information transmission activities have both fallen through the floor over the last 12 months! To protect sources I can’t provide much detail concerning the evidence I have seen, but it is clear and dramatic and confirms what I have been saying for a good while. Sadly HealtheLink is such a badly wounded animal that it really now needs to be helped to pass to a much better place!

Are the national health IT efforts in the US headed in the same direction?

Read the entire post at the link above.

-- SS

Unintended errors with EHR-based result management: a case series, and a special pleading for health IT

As I wrote at "Report of an AMIA special task force on challenges in ethics, safety, best practices, and oversight regarding HIT", articles in the premier journal of Medical Informatics, the Journal of the American Medical Informatics Association (JAMIA) on real and potential downsides of health IT appear to be becoming a trend.

Another article just appeared in JAMIA as the result of a study of healthcare IT related errors: "Unintended errors with EHR-based result management: a case series"; Thomas R Yackel and Peter J Embi; JAMIA 2010 17: 104-107; doi: 10.1197/jamia.M3294.

The article presents a series of health IT-related errors and categorizes them systematically, and thus adds to our knowledge on the issue of cybernetic clinical test results management. It also makes recommendations for increased vigilance and remediation.

The abstract is below (access to the article itself requires a JAMIA subscription.)

ABSTRACT

Test result management is an integral aspect of quality clinical care and a crucial part of the ambulatory medicine workflow. Correct and timely communication of results to a provider is the necessary first step in ambulatory result management and has been identified as a weakness in many paper-based systems. While electronic health records (EHRs) hold promise for improving the reliability of result management, the complexities involved make this a challenging task. Experience with test result management is reported, four new categories of result management errors identified are outlined, and solutions developed during a 2-year deployment of a commercial EHR are described. Recommendations for improving test result management with EHRs are then given.

The article begins:

Over a 2-year period from 2005 to 2007, coinciding with the first 2 years of a planned 3-year deployment of the ambulatory EHR to multiple practice sites, the vast majority of laboratory result routing events functioned as intended. However, seven error types were identified as causing a substantial delay or disruption in result delivery to providers’ electronic inboxes [no statement is made about patient harm or "close calls" that may have resulted - ed.] and led to further investigations and case finding by our group.

Upon analysis, these seven error types were logically grouped into four distinct error categories: (1) interface and results routing logic errors, (2) provider record issues, (3) EHR system settings, and (4) system maintenance.

This was at OHSU, a leading institution in medical informatics, not at some organization that's a newcomer to health IT.

Each of the "error categories" is described in some detail. The article then makes recommendations for improved systems, which sound simple, but are going to be far more resource intensive on a national scale than meets the eye:

1. Develop fault-tolerant systems that automatically report delivery
failures.
2. Use robust testing to find rare errors that occur both within and between systems.
3. Implement tracking mechanisms for critical tests, such as cancer screening and diagnostics.
4. Deliver results directly to patients.

I find myself uncomfortable with the possible human resource costs of implementing the recommendations, especially on a national scale. These costs would be over and above the hundreds of millions per institution and the hundreds of thousands per private doctor already spent, or planned to be spent.

My other issue regarding the article (my main issue, actually) is its editorializing for a product, health IT, in a scientific article, and making a special pleading for the technology.

The next to last paragraph of the article appears more of an editorial, perhaps to make vendors comfortable, than a scientific statement of fact supported by the article:

Finally, while it might be tempting to attribute the errors noted above to the use of a particular health information system or even Health IT in general, an examination of the cases reveals that most of these errors actually resulted from local configuration and implementation decisions rather than to the technologies themselves. Indeed, the authors believe that these cases further support the emerging truism [wow! This is news to me - ed.] that errors related to Health IT are in most cases the result of human error in the implementation of new information and communication systems into our existing complex healthcare environments.[10] Therefore, we contend that the main lesson arising from these cases is that care must be taken by those responsible for implementing health information systems to remain aware of the kinds of errors that might occur and monitor for the unexpected consequences that will undoubtedly take place, but not to avoid use of such systems that likely have the capacity for far greater benefit than harm, if implemented and monitored properly.

In this paragraph the authors state: "... while it might be tempting to attribute the errors noted above to the use of a particular health information system or even Health IT in general, an examination of the cases reveals that most of these errors actually resulted from local configuration and implementation decisions rather than the technologies themselves."

As for "rather than the technologies themselves", technologies themselves are never a problem by themselves, even the atomic bomb. In a reductio ad absurdum, which is maybe not so absurd, it took a B29 Superfortress to drop two A-bombs; the bombs could have been deactivated and put in a museum instead.

However, consider a poorly designed A-bomb that could unpredictably go "BOOM" - now that would be a problem.

While I agree some errors are due to mismanaged implementation, in the article, no differentiation is made of design issues vs. implementation (i.e., local configuration and implementation decisions). Yet fundamental design is crucial, according to industry leaders and non-industry experts, in areas that cannot be vastly improved by local configuration decisions:

HIMSS's former Chairman of the Board admits the technology remains experimental:

... We’re still learning, in healthcare, about that user interface. We’re still learning about how to put the applications together in a clinical workflow that’s going to be valuable to the patients and to the people who are providing care. Let’s be patient. Let’s give them a chance to figure out the right way to do this. Let’s give the application providers an opportunity to make this better;

While HIMSS itself admits in this 2009 PDF that

"Electronic medical record (EMR) adoption rates have been slower than expected in the United States, especially in comparison to other industry sectors and other developed countries. A key reason, aside from initial costs and lost productivity during EMR implementation, is lack of efficiency and usability of EMRs currently available";

While the National Research Council (the highest scientific authority in the U.S.) last year reported that:

"Current Approaches to U.S. Health Care Information Technology are Insufficient" and that the technology "does not support clinicians' cognitive needs." The study was chaired by Medical Informatics pioneers Octo Barnett (Harvard/MGH) and William Stead (Vanderbilt);

It is very difficult if not impossible to make a clinical IT silk purse out of a poorly designed sow's ear, no matter how many sound "local configuration and implementation decisions" are made.

Further, it is stated in the JAMIA article that human errors in implementation as the cause of health IT woes are an "emerging truism".

Making the case that some observation reflects a "truism" is a powerful claim. Such a claim deserves more than one reference, but here's what we have:

"... the authors believe that these cases further support the emerging truism that errors related to Health IT are in most cases the result of human error in the implementation of new information and communication systems into our existing complex healthcare environments" [10].

10. Ash JS, Berg M, Coiera E. Some unintended consequences of information technology in health care: the nature of patient care information system-related errors. J Am Med Inform Assoc 2004;11:104–12.

Perhaps the term "truism", emerging or otherwise, should be avoided in 2010 regarding errors related to health IT.

The authors contend, presumably from the above observations that:

... we contend that the main lesson arising from these cases is that care must be taken by those responsible for implementing health information systems to remain aware of the kinds of errors that might occur and monitor for the unexpected consequences that will undoubtedly take place

"Might occur?" How about "that do occur" - as in the paper? Above all, these involve patients.

Unexpected consequences - these involve patients, too.

My mother was nearly killed by "unexpected consequences:" of health IT in May 2010. Perhaps that makes me less cavalier about health IT.

In fact, the certainty that UC's will "undoubtedly take place" reaffirms that these are still experimental technologies.

I remind that it might be best to focus on fundamental design issues before expensive systems are put into place that can cause errors and unexpected consequences, because these are mission critical systems involving live patients who have not, incidentally, been afforded informed consent to the use of these medical devices in their healthcare.

Another editorial comment follows:

[the lesson is that those responsible should remain aware] but not to avoid use of such systems that likely have the capacity for far greater benefit than harm, if implemented and monitored properly

Once again, this is an editorial and value judgment. Who knows if ultimately health IT has a capacity for far greater benefit than harm? If these systems will have predictable, unexpected consequences, how do we know that? Why should critical-thinking practitioners not avoid such systems for now until a better understanding of how to design them to improve usability and support clinician cognition is achieved?

Why put patients at risk en masse as part of a national experiment when studies even at advanced HIT sites show fundamental problems that could harm or kill?

I argue this paper and others that are "emerging" on the downsides and lack of ROI of health IT make the case for great caution and slowness (i.e., avoidance) in their adoption.

Yet the authors seek special accommodation for this technology, something that is perhaps unprecedented with (unregulated) medical devices of unknown risk.

The lesson is actually that we need to slow down with HIT; reboot and start to solve the problems of this technology before national rollout attempts.

This is the ethical position regarding any experimental medical technology that is proving risky at a level not clearly known.

-- SS

NIST Provides Healthcare IT Industry with Remedial Undergraduate Computer Science Education

The National Institute of Standards & Technology (NIST) has published a guide entitled:

NIST Guide to the Processes Approach for Improving the Usability of Electronic Health Records

It is available free at this link in PDF: http://www.nist.gov/itl/hit/upload/Guide_Final_Publication_Version.pdf (hat tip to an AMIA colleague for posting the URL on an AMIA mailing list.)

The NIST was commissioned by HHS/ONC to study Health IT issues such as usability and report on them.

I find the publication both welcome, and pitiable.

As I started to read ch. 6, for example, I observed material that is suitable for undergraduate computer science instruction:

6. User-Centered Design Process in EHRs

User-centered design is a bedrock principle for creating usable systems and devices. [You don't say? - ed.] One of the most common reasons why systems are poorly designed is that designers and developers fail to engage users in appropriate ways at appropriate times. [Hear that, my young Paduan learners? - ed.] At its core UCD is a process that relies on systematic understanding of users and their environments, and iterative design and testing based on user performance objectives. (Details on usability testing are provided in Section 9.)

UCD has been shown to be effective in many fields. In aviation, for example, this method has been used to develop cockpit navigation displays for low-visibility surface operations. [22] By taking the limitations and capabilities of the flight crew into account, navigation errors have decreased by almost 100%. The adoption of UCD has also been shown to be effective in the design of personal computers. When working on a redesign of the laptop computer, a UCD process was employed. Users were asked to offer feedback about the current model and to offer input about ways to improve the current design. User-centered design was successful in increasing market share, brand equity, and customer satisfaction. [23] In fact, user-centered design has been elevated to an ISO standard. [24] UCD serves to engineer improved human performance into a system or device, and has been crystallizing for several decades as a design philosophy. [25]

While there is no singular model of UCD, the instantiations embody the following principles:

• Understand user needs, workflows and work environments
• Engage users early and often
  
• Set user performance objectives
• Design the user interface from known human behavior principles and familiar user interface models
• Conduct usability tests to measure how well the interface meets user needs
• Adapt the design and iteratively test with users until performance objectives are met

[HHS needs ONC to commission NIST to provide schooling for the HIT industry on these bons mots? - ed.]

As an iterative process, UCD is a cycle that serves to continually improve the application. For each iteration, critical points and issues are uncovered which can be improved upon and implemented in subsequent releases. An illustration of the UCD process is included in Figure 1.

"User centered design process in EHR's." Undergraduate-level computer science 101 instruction from NIST for the healthcare IT industry? (click to enlarge)

Here is Figure 1:

User centered design 101 (click to enlarge)

I might even have used this in teaching high school students about computer programming.

Readers can download the entire report at the above URL.

I find this publication, or, rather, the need for it to exist at all in 2010, remarkable. Absurd and an embarrassment, in fact. Master of the Obvious [1] material that apparently was not so obvious to this industry.

This is after all a multi-billion dollar industry making claims its products will "revolutionize medicine" and other exceptional claims (but without exceptional evidence). These claims have been pushed so hard that many tens of billions of dollars (with penalties) have been earmarked to either entice -- or coerce -- physicians and hospitals to use these products.

What has this industry, including vendors and highly paid management consultants and contractors, been doing, exactly, for the past thirty+ years?

What have been their product design and development practices, such that leaders of their own trade group HIMSS (as I pointed out in other posts) opine we should be "patient" for them to figure it all out about how to do health IT better and they need more time, and that the technology does not support its users properly due to lack of efficiency and usability of EMRs currently available? (As at my July 2010 post "The National Program for Healthcare IT in the U.S., and the Elephant in the Living Room".)

That HHS needs NIST to provide undergraduate level remedial teaching to the multibillion dollar health IT industry is a very poignant commentary indeed on the priorities of that industry regarding engineering rigor, talent management, attention to safety, and other factors affecting human lives.

These observations speak strongly to the need for regulation for this industry, for a talent management and trade association shakeup of major proportions, and most especially for an awakening of our government servants to exactly what the real situation is with respect to HIT on the ground.

12/14/10 addendum: it struck me that the Guide might need another chapter. I suggest a chapter entitled:

"Listening to informatics experts when they say your product will kill people, instead of firing them."

-- SS

[1] This was another pithy line from my early medical mentor, pioneering cardiothoracic surgeon Victor Satinsky, MD at Hahnemann Medical College.

Professors at Harvard and Nottingham Medical School (UK): Are we repeating the UK's clinical IT failures in the US?

In the opinion piece "Don't Repeat the UK's Electronic Health Records Failure" (Huffington Post, Dec. 5, 2010), Dr. Stephen B. Soumerai, Professor of Population Medicine at Harvard Medical School and Dr. Anthony Avery, Professor of Primary Care at the University of Nottingham Medical School, UK share familiar themes on health IT.

These themes will be especially familiar to HC Renewal readers and to my students and other readers of my Medical Informatics teaching website.

The professors wrote:

Fueled by the economic stimulus passed by Congress in 2008 [The ARRA a.k.a. "American Recovery and Reinvestment Act" and the HITECH legislation it contained - ed.], the federal government has embarked on a controversial $30 billion program to induce doctors throughout the country to adopt electronic health records (EHRs) by 2014. The purpose is to create an interconnected system of electronic health records to improve safety and reduce medical costs.

But the United Kingdom has spent the last 6 years working on the same idea, and it's proven to be a colossal failure -- so much so that the government is drastically cutting its program. What happened to their plan? Should we be paying attention before rushing ahead with our own?

My response to that question is clear, such as at my Nov. 2008 post "Should The U.S. Call A Moratorium On Ambitious National Electronic Health Records Plans?" and the followup Jan. 2009 post "I Ask Again: Should The U.S. Call A Moratorium On Ambitious National Electronic Health Records Plans?" where I wrote:

$50 billion a year is big money that might be better spent elsewhere - such as providing care for the poor and for disadvantaged children - until we know how to get HIT right.

I suggest it may be best not to go all-out for HIT under the current paradigm. It is my belief, in fact, based on the above issues [UK and US issues - ed.] plus a chronic influx of HIT difficulty and mismanagement stories I hear from colleagues, ex-colleagues, recruiters, etc., that healthcare organizations not contractually obligated should consider a postponement of plans to purchase clinical IT (i.e., systems for direct use by clinicians such as EHR's).

This postponement should last at least until the issues that lead to ineffective and counterproductive HIT can be better understood and corrections initiated in the industry.

The professors further write:

In 2005 the United Kingdom embarked on the largest investment ($18 billion) in health information technology in the world. Yet despite expectations that the system would increase efficiency and reduce medical errors, their efforts neither improved health nor saved money -- in fact in some cases, they may have led to patient harm.

Britain's government-run medical system is obviously different from our complex public-private insurance system. [I had written that a smaller, socialized healthcare system should be far easier to automate than our own in the US - ed.] However, its electronic health record project bears an uncanny resemblance to the program President Obama is starting.

They then delineated a number of problems:

Too large and ambitious: The UK project tried to accomplish too much, too fast, attempting to digitize health records for the whole population in a period of four years. This massive undertaking is years behind schedule and has delivered only a fraction of what it promised. Despite all the money poured into the system, the vast majority of hospitals in the UK still don't have integrated electronic health records.

Why? The reasons sound familiar:

... Because non-clinicians developed the system, the electronic forms they designed have little to do with how doctors treat patients -- making it unworkable for many physicians. As the Chair of the British House of Commons Public Accounts Committee recently stated, "This is the biggest IT [Information Technology] project in the world and it is turning into the biggest disaster."

The "biggest IT disaster in the world" is not an honor I wish to see repeated in the U.S.

On another familiar problem:

Too dependent on commercial, proprietary companies: Rather than create one system and beta-test it, the UK government depended on four companies to build the system, two of which quit or were fired for missing deadlines. So the health records were never developed in the south of England. The computer software was secret and proprietary. There was no accountability to the public, and the vendors did not provide enough technical support to clinicians having trouble using the records.

The resulting software errors and crashes caused missing or incorrect clinical information and sometimes threatened patient safety, for example by causing surgical delays and the cancellation of hundreds of operations.

The inquiring mind would want to know about actual patient injuries and deaths that likely resulted from such problems...

The professors observe:

If a country like Britain -- which already has a national health system and is a fraction of the size of the US -- had so many problems with electronic health records, imagine the problems America would face.

This sounds like my comments in a public comment letter of March 9, 2010 to HHS/ONC (Re: RIN 0991-AB59, "Proposed Establishment of Certification Programs for Health Information Technology") where I wrote, among many other things:

... We ignore the UK experience at our peril, an experience in a medical environment smaller and far more government-controlled than our own.

... I believe that a rushed National Program for HIT in the United States will suffer the same fate as the aforementioned National Programme for IT in the UK, and perhaps even a worse fate as the UK’s socialized medicine system is certainly a smaller, more homogeneous and more controllable testbed environment for experimenting with HIT.

The professors relate:

Even our partial adaption of electronic health records is causing problems. Over the last couple of years, doctors and hospitals have reported to the FDA dozens of medical injuries -- including six deaths and preventable heart attacks -- caused by problems related to computerized health records such as software errors and unreadable computer screens. Some errors resulted in drug doses that were 10 times higher than intended. FDA officials called this the "tip of the iceberg."

I wrote about the FDA's findings here, and conducted a "thought experiment" regarding what those numbers might extrapolate out to in my April 2010 post "If The Benefits Of Healthcare IT Can Be Guesstimated, So Can And Should The Dangers."

They continue:

... More than 50 medical organizations, including the AMA, have called on the Secretary of Health and Human Services to delay the program. In response, the administration delayed some of the required health IT functions, but kept the same 2014 deadline.

Indeed. They are courting disaster in my opinion, both clinically and financially, as I wrote in a Feb. 2009 Wall Street Journal letter to the editor entitled “Digitizing Medical Records May Help, but It's Complex”:

Dear WSJ,

You observe that the true political goal is socialized medicine facilitated by health care information technology. You note that the public is being deceived, as the rules behind this takeover were stealthily inserted in the stimulus bill.

I have a different view on who is deceiving whom. In fact, it is the government that has been deceived by the HIT industry and its pundits. Stated directly, the administration is deluded about the true difficulty of making large-scale health IT work. The beneficiaries will largely be the IT industry and IT management consultants.

For £12.7 billion the U.K., which already has socialized medicine, still does not have a working national HIT system, but instead has a major IT quagmire, some of it caused by U.S. HIT vendors.

HIT (with a few exceptions) is largely a disaster. I'm far more concerned about a mega-expensive IT misadventure than an IT-empowered takeover of medicine.

The stimulus bill, to its credit, recognizes the need for research on improving HIT. However this is a tool to facilitate clinical care, not a cybernetic miracle to revolutionize medicine. The government has bought the IT magic bullet exuberance hook, line and sinker.

I can only hope patients get something worthwhile for the $20 billion.

The professors then note:

How do we avoid the UK's failure? The administration or Congress should slow down the program and delete those parts of the legislation that fine doctors for not using this technology. There's no need to have this system in place by 2014. Instead, we should conduct rigorous studies of the cost-effectiveness of electronic health records systems before mandating their use. Rather than force doctors to choose from dozens of commercial software products developed in secret, we should take a hint from the non-commercial sector, such as the Veterans Administration, which uses "open-source" coding so people can work collaboratively to continuously improve the system.

Slowing down the program and performing rigorous studies of HIT before wide scale rollout are themes I raised, among other places, in my Dec. 2009 post "Tensions and Paradoxes in Electronic Patient Record Research: Critical Thinking on Health IT" where I wrote:

In conclusion, I believe this literature review supports the notion expressed in other studies and opinion pieces here and elsewhere that we really need to SLOW DOWN the current HIT stampede, largely promoted by the HIT industry lobby. We need to take the appropriate time to better understand how to "do HIT well" before plunging in as if we actually know what we're doing

as well as at my Oct. 2009 post "Washington Post Article: Electronic medical records not seen as a cure-all" where I wrote:

... The literature is indeed conflicting, and the need for rigorous scientific study has never been more essential considering the commitment of tens of billions of dollars towards health IT. The time for story telling, marketing based on opinion, name calling, leap-of-faith extrapolations of light year dimensions, and other forms of pseudoscience and non-science are over. The time for objective study is now.

The professors conclude:

The Obama administration wants government programs to be based on evidence of effectiveness. Simply following the lead of "IT believers" and salesmen without the requisite evidence will repeat the UK's failures. Now is the time to proceed carefully, consider existing research and the British experience, and chart a more rational course into the digital age of medicine.

I do not know if these two professors were familiar with my writings, but I am happy to see these themes (once treated as verboten and as grounds for marginalization by the HIT industry) increasingly going mainstream.

Patient well being - which includes you, dear readers - depends on that.

-- SS

Avatar fails. (No, not the Cameron movie, but yet another lousy EMR system implemented by amateurs.)

A story "Designed for Efficiency, New Computer Software at Health Dept. Misfires" by The Bay Citizen senior writer Katharine Mieszkowski appeared in the New York Times today regarding San Francisco's Dept. of Public Health.

"Misfires?"

That's a mild term indeed. In the realm of incendiary comments in the interest of patient care:

In this story, mental health and social workers, and the disadvantaged people suffering mental illness, drug addiction, etc. that these professionals attempt to raise up from misery one difficult step at a time, are being used as unconsenting experimental subjects and free software debuggers and beta testers:

This story follows a script very familiar to Medical Informatics professionals:

• Poorly designed and implemented healthcare IT causes clinical and other chaos;
• Vendor and implementation leaders claims "glitches" and "teething pains" and blame the users for inexperience and/or incompetence;
• Vendor promises relief in the "next version";
• These principals hope it all "goes away" until the system implodes on itself and needs replacement, starting the cycle anew, and/or-
• The principals hope newspapers stop paying attention to the chaos caused by the IT and the users simply surrender, and let the information systems control them, rather than the other way around.

Considering the patient population involved here, one might wonder if the project leaders have any more compassion than the machines they proffer:

New York Times
Designed for Efficiency, New Computer Software at Health Dept. Misfires
By KATHARINE MIESZKOWSKI
November 18, 2010 (from the Bay Citizen)

In July, the San Francisco Department of Public Health started using an $11.2 million electronic medical records system, Avatar, that was designed to streamline billing and improve care for tens of thousands of clients. Thus far, however, it has brought administrative chaos to the mental health and substance abuse services in the city.

Documents obtained by The Bay Citizen under a California Public Records Act request show that shortly after installing Avatar, providers struggled to use the new software, causing health officials to lose track of millions of dollars of services.

Officials are scrambling to fill in the missing data to meet deadlines to qualify for reimbursement from the state.

In addition to mere financial chaos:

... Problems related to the conversion to Avatar delayed for months the payment of about $450,000 to individual therapists, Anne Okubo, the health department’s deputy financial officer, told the San Francisco Health Commission on Tuesday night. The department was forced to use a third party to make the payments, which are still incomplete.

In addition, some therapists and social workers report that the demands of the new software have cut into the time they spend with patients, eroding the quality of care.

In an Aug. 19 e-mail headed “problems with Avatar,” Steven Schreibman, a social worker at Sunset Mental Health, a city-run clinic, wrote that the software required “excessive time charting and performing data entry” and had led to “shorter sessions with clients” and “delays in our capacity to accept new clients.” [This is not news to anyone familiar with poorly designed, mission hostile healthcare IT - ed.]

The customary excuses were presented. Growing pains, ignorant users:

Senior health department officials and Netsmart Technologies, Avatar’s developer, said the problems were glitches that were to be expected as the city made the transition to a more efficient record-keeping system.

“We knew it was going to be rough initially, because there is a learning curve,” said Jo Robinson, who heads the Community Health Behavioral Services division, where Avatar was introduced.

Kevin Scalia, a Netsmart Technologies executive vice president, said that he does not see this as a big problem. “From our point of view,” he said, “everything is going swimmingly.” [Translation - they're making good money - ed.]

Here's the key passage:

Department managers told the Health Commission that Avatar would lead to “improved client care” and had “positive fiscal impacts,” but they acknowledged there had been problems.

In September, the department compared the cost of mental health and substance services reported by the hospital, clinics and organizations in March, before the software was put into use, to those reported in July using the new system.

The data showed that the mental health services reported had plunged 55 percent. Substance abuse services reported fell 32 percent. The large discrepancies caused alarm because they indicated that providers were having problems using the software, according to documents and interviews. [I can also predict they've had problems _providing_ those services under the time duress added by the software - ed.]

As someone who was once a Medical Review Officer for drug testing in the public transit industry, and a colleague of the company's Employee Assistance Program liaison, I can assure readers that implementation of health IT will not effect a one-third reduction in drug abuse problems and recidivism.

After a month of use:

A month later, as more providers gained access and proficiency with the software, the picture improved, but significant discrepancies remained.

Some data modeling issues are apparent:

But some organizations worry that the services they are providing will not be fully reflected in the new system.

Here's a reverse twist on HIT vendor "Hold Harmless" clauses:

At the Health Commission meeting, Estela Garcia, executive director of the Instituto Familiar de la Raza, a community organization that provides mental health services, asked the commission to protect organizations like hers from any financial liability related to Avatar.

“I want a hold-harmless policy until the system is fully up and running,” Ms. Garcia said.

How long that will take is unclear. One mental health program director, who would not allow his name to be used because it could jeopardize his relationship with the department, said his staff had gone to repeated training sessions to try to get up to speed.

“Avatar turns out to be a total disaster,” the program director said. “What is going to happen to contracted agencies if their billing is short at the end of the fiscal year as compared to the terms of their contract, because they can’t master Avatar?”

As in typical in health IT, system users are afraid to speak candidly:

A psychologist who works with a community organization under contract to the city, who spoke on the condition of anonymity because he was afraid of losing his job, said he used to do all his charting and billing on paper and was told that the new system would be more efficient. So far, that has not proved to be the case, he said.

“We are seeing the same number of patients,” he said, “but we are providing substantially less service to them, because the time we are now spending just to do the billing alone, not to mention the record keeping, it’s become the majority of our time.”

Labor unions are taking a look:

Greg Cross, a field representative for Service Employees International Union Local 1021, which represents hundreds of social workers, psychologists and counselors who work for the city, said he had met with officials to discuss Avatar’s impact on workload as well as performance expectations.

I invite SEIU Local 1021 and national SEIU leaders to read this blog, and review my academic site on HIT failure here, to better understand why these debacles repeatedly occur.

At the Health Commission meeting, Fred McGregor, the health department’s senior information technology manager for community programs, said that the department was aware that providers find the demands of Avatar “a little onerous” and that it was working on a redesign to make clinical assessment more efficient.

A "little onerous"?

"Working on a redesign to make clinical assessment more efficient"?

What about getting it right the first time, based on the significant amount of literature that exists on proper IT design?

I, for one, am tired of hearing this corporate mumbo-jumbo every time another health IT system impairs users.

What is needed here is a full scale investigation and evaluation of the competence and expertise of the project leaders, designers, and implementers to be experimenting in the complex field of healthcare information technology.

Mr. Schreibman, the social worker, made it clear in his August e-mail that change was needed quickly.

“The kind and amount of work skill involved using this software represents a change in our job description,” he wrote. “This is not the job we accepted when we chose to do clinical work for the city.”

In other words, they did not accept a job as data entry clerks and directors of workarounds to the mission hostile user experience presented by poorly designed healthcare information systems.

I note that missing in this story are the human tragedies (such as pain & suffering, injury, death) these IT "glitches" may have caused.

Until the memes of complete health IT beneficence and "anyone can do it" are soundly pounded into the ground and out of the heads of hapless politicians, healthcare leaders, and IT personnel, this type of mishap will continue.

Sadly, health IT mishaps are likely to be occurring on a national scale, soon, in a neighborhood near you, thanks to the timelines and penalties expounded in the HITECH act. HITECH was an integral part of the legislation known as the ARRA (American Recovery and Reinvestment Act of 2009).

-- SS

EHRevent: survey amateurism, bias, or something else?

At my post EHRevent.org: Web Site to Collect EHR Safety Reports, I wrote of my questions about a new organization, EHRevent.com, that seems to supercede or compete with the FDA's MAUDE and Medwatch medical device and medication adverse events reporting and analysis services.

Reviewing the EHRevent report form on this day (archived here, PDF), I note the following multiple choice question on page 7 (emphasis mine):

Notwithstanding the event you are reporting, has the adoption and use of an EHR by your practice added to patient safety, improved care or improved documentation? Select one option.

o Yes, definitely

o Likely

o Not sure

o No impact

A bias and/or survey amateurism is clearly evident in this question. And perhaps something more?

Missing is this option:

o None of the above; EHR adoption did not "add to"; rather, it subtracted, as worsening occurred

A fundamental rule of surveys is that the choices should not artificially limit the survey taker's ability to provide critical or relevant information.

As Ross Koppel, PhD, a sociologist studying healthcare IT at the University of Pennsylvania stated at the Feb. 25, 2010 HHS Certification/Adoption Workgroup Meeting on Health IT Safety (minutes of that meeting are archived at this link, PDF):

... Like everyone else, I want HIT to increase patient safety, care efficiency, treatment quality, savings, and drug ordering guidance. I want HIT to provide coherent structures for test results and other data, and I wanted to provide better visualization of complex clinical data.

Unlike many of my colleagues here who are HIT scholars and advocates, however, because of my training perhaps, I‘ve studied the surveys that have been used to guide and explain the current HIT strategy.

These surveys explored why doctors and hospitals have not embraced HIT‘s benefits. The findings pointed to the cost of HIT, to the physicians‘ resistance. They called them technophobic, hide bound, and perhaps most gruesome, too old. It also talked about overwhelmed hospital IT staff and other user pathologies or user inadequacies.

Now the years of research on HIT suggested that those answers could not be complete. They weren‘t right. The reasons the surveys found this, I‘ve been investigated, was I looked at the questions that were asked of the doctors and hospitals. And the only answer options dealt with the problems of hospitals and doctors. In other words, they found only the questions that they asked about physician difficulties, doctor difficulties. They didn‘t look for any other options, and they didn‘t even give other option answers to talk about the following issues.

So they could have asked, does HIT slow or speed your clinical work? Are EHR data presented in helpful ways, or do they generate unnecessary cognitive burdens because, for example, the data that should be contiguous are in five separate screens, where you‘re scrolling across vast wastelands of rows and columns looking for the needed information. How many information displays are understandable or are disarticulated, confusing, or missing key data? Does HIT distract from your patient care or improve it? And the last one I‘ll ask, although I have about 50 others, how responsive are HIT vendors to acknowledging and repairing defects? How quickly are these defects repaired?

The absence of the relevant questions divert us from understanding the actual HIT needs of clinicians and patients. Now I‘m certain that the people who asked these questions, designed these surveys, were not intentionally deceptive. Well, I‘m certain most were not intentionally deceptive. But the restricted options reflects a series of assumptions or … that says HIT is intrinsically beneficial. Anything that encourages HIT is good for patient safety. Anything that discourages it or retards it is bad by definition.

The creators of the EHRevent survey apparently were not present, or not listening, during Dr. Koppel's presentation.

I have not yet reviewed in depth the other survey questions for similar issues, but this one stood out like a sore thumb.



I cannot imagine an objective, competent scientist committing such an error.

-- SS

Why I find the healthcare IT industry so disappointing

At "Background On The 'Ecosystem' of Commercial Healthcare IT" I wrote:

... In reading about HIT difficulties it is important to understand the “ecosystem” of commercial health IT, that is, the identity and nature of the principal constituents and stakeholders, and their interrelationships. Familiarity with this environment is useful in order to place the social and organizational issues affecting HIT diffusion in the proper context.

By implication, I made the case that the commercial HIT ecosystem was far from healthy.

Recently at Healthcare Renewal and at another blog I visit, HISTalk, frequented largely by IT industry workers and officials, I've noted an uptick in comments from anonymous commenters that resort to ad hominem, strawman arguments, or other forms of logical fallacy in a fairly clear cut attempt not to seriously debate the issues but to de-legitimize serious arguments. I generally respond to such comments, but a few have been so debased here that I have simply deleted them.

Here is an example of a duplicitous strawman argument recently posted at the aforementioned other site with regard to my HC Renewal post "21st century EMR experiments: screwing around with people's lives in a broke city, while not having a clue what you're doing":

... Jumping to conspiracy theories about cover-ups whenever there is an IT problem acknowledged by an organization does not really help improve the state of health IT.

I find the sicknesses of the commercial health IT ecosystem very disappointing and, in fact, revolting due to the implications for patients.

Perhaps a little background as to why I feel that way is in order.

Note:

I believe my background is not too dissimilar from the background of many physicians, who have had similar experiences. The following is therefore not so much about me, but about the challenges of medical training and practice in general and the life experiences imparted:

Pre- informatics, while a resident at Abington Memorial Hospital in Pennsylvania and then as a Manager in a regional transit authority’s medical department, I handled situations such as these:

• Being admitting officer in the ED in the busiest night, ever, in the hospital’s history to that time, New Years Eve 1985-6, having to see perhaps a hundred patients and admit ~ 30. The ED staff needed to -- and did -- perform flawlessly after participating in the highly upsetting and depressing, unsuccessful resuscitation effort of a medical colleague shot in the chest in his home (link) around midnight. It was I who performed heart massage on him -- open-chest style -- with my gloved hands after the surgeons on the trauma team cracked his chest;
  

• Running three near-simultaneous cardiac arrests in the ICU’s during family visiting hours, while being trailed by a Mennonite minister-in-training as an observer. Dealing with the patients' crises and their families was not easy and in fact was extremely stressful. The minister-in-training at the end of it all after several hours stated he was amazed at how I and the intern I was overseeing kept our cool during the affair;
  

• Not telling an intern colleague on the telephone whose mother I’d just declared deceased in the MICU that she had died, because his call was coming from his father’s funeral. His father had died a few days before in the CCU right next door, previously healthy but having had an MI from the stress of his wife's condition. (The intern later thanked me for not telling him about his mother's death until after dad's funeral).

• Repairing a malfunctioning GE CT scanner's computer to get it up and running late one Sunday might ca. 1986, which permitted a life-saving CT scan of the head of an unidentified young man brought in in a delirious state. A repairman left near midnight and said it was fixed, but it was not, and service, I was told, was unavailable between midnight and 7 AM Sun-Mon. so he could not be called back. I'm not sure if this was a vendor policy or a contractual issue (either of which would reflect Titanic lifeboat-like stupidity, since people need CT scans 24x7), but due to radiology training and computer expertise I knew what the problem was and fixed it, going above and beyond the call of duty of an internal medicine resident.
  

• Dealing strongly and firmly with militant labor union leaders and drug-troubled vehicle and train operators as Mgr. of Medical Programs and drug testing in a large regional transit authority. I was very firm in my stance about keeping these operators off the street, and getting them help, to protect the public from possible catastrophe. I was threatened more than once, including being threatened with my life, by operators I had to put out of service.

• Standing up to a police officer and a FOP union official regarding what I believed was gross exaggeration of a minor injury, with no objective findings to substantiate the reported symptoms, multiple inconsistent findings on exam (indicative of 'acting'), and ongoing injury-clinic (a.k.a. fraud-factory) hot pack and massage "treatments" for more than a year, to take advantage of the injury compensation system. This type of activity was unfair to truly injured personnel, to the city that had to pay for these activities at the expense of other needed services, and to the taxpayer.
  

Experiences such as this impart a sense of the fragility of life, of responsibility, obligation, and an understanding of the need for critical thinking and serious and uncompromising attitudes where patients are concerned into physicians of good character.

(Somehow, the hospital, pharmaceutical and medical device executives written about at Healthcare Renewal seem to have missed those points in their own life experiences.)

Most serious, critical-thinking physicians thus would find irrational arguments coming from the HIT industry, marketing spin, petty character attacks on those who report on HIT difficulties, and other unpleasantries quite unserious and disappointing. I certainly do.

After all, IT industry personnel in large part went through educations far simpler than that of a physician. They generally have bachelor's or masters' degrees, have had no medical school experience, internships, residencies, postdocs, etc. They have what are essentially comfortable desk jobs, no liability for patient harm, and compared to most physicians, a cakewalk in their professional lives.

On the other hand, as a physician who had such experiences, I’m a serious professional concerned about serious issues that affect people's lives in their time of need.

I expect nothing less from others involved in aspects of healthcare that can be life or death (as my own mother recently experienced via EHR-initiated iatrogenic catastrophe).

From that perspective, I find the commercial HIT ecosystem quite disappointing indeed.

-- SS

21st century EMR experiments: screwing around with people's lives in a broke city, while not having a clue what you're doing

I was astounded to read the following passage in an interview of the current chief medical information officer at Detroit Medical Center ("DMC") Detroit, MI:

DMC tried CPOE in 2003 and said it would regroup and try it again. What lessons were learned from that first attempt?

In 2003 we did try at one hospital — a more community-based hospital — on two units. We did it on our rehab unit, the psych unit. I think the first lesson we learned there was that it was really just designed as, or worked out as, an IT project. I mean, it was really IT-led and there wasn’t clinical involvement from the get-go.

There wasn’t really a leadership pattern that had physician and nursing components to it. There wasn’t a design phase that included a lot of clinicians. There wasn’t leadership buy-in from the hospital. We took the product from the vendor and implemented what they gave us. It was really doomed to fail from the start. [Doomed, that is, due to inexcusable health IT illiteracy for the year 2003 - ed.]

This is striking for a number of reasons, least of which is the tone in which the failure is presented, a tone that suggests this failure and its "lessons" were banal in character and something that "just happens." It's as if by 2003 there was no other way to have done due diligence and learned these lessons, other than by actual experimentation on hospital floors with live patients and busy clinicians.

If this story had appeared about a health IT project in, say, 1983 or 1993, it would have been less remarkable. By 2003, however, the literature on how do do health IT "right" (and on how not to do it, including all the faults mentioned about DMC's efforts), was quite voluminous.

The medical informatics literature from AMIA and IMIA, textbooks such as Lorenzi and Riley's "Organizational Aspects of Health Informatics: Managing Technological Change" (ed. 1 - 1995), sites such as my own on HIT failures (freely available and one of the first hits one received via google on searches on "Healthcare IT failure" and similar concepts even then), and other resources could have prevented the CPOE failure - if someone at DMC or their consultants had had the meta-knowledge to know of their existence or the managerial savvy to ask, and the initiative to actually read the materials and heed the advice of experts.

Instead, this sounds like a classic example of hospital mismanagement, via not knowing what you don't know, and not caring.

What is described is a failure due to HIT naivete and managerial dyscompetence (or incompetence) around technology management that should not have existed in hospitals in an American city in 2003. One should wonder what other mishaps occured in other domains of medical technology under this type of "leadership."

Clinical personnel and patients are the potential victims - not laboratory rats. The story is certainly remarkable in terms of risk presented by this experiment on live patients, and again for its banal tone regarding that crucial issue. It is well known that poorly done CPOE is associated with medication errors, not a happy event on a psychiatry unit or PM&R/rehab unit (where elderly frail patients often abound).

The story is also remarkable due to the waste of money it represents in a city not exactly rolling in money, looking somewhat like Dresden after the WW2 firebombing and with wide sections of former residential land designated for demolition and "return to nature."

Instead of spending money on "let's try to figure out CPOE today, all by ourselves!" health IT experiments, perhaps the money could have been used for better care of Detroit's poor.

The "lessons learned" in 2003 could and should have been learned for free and without risk to patients - in a public library.

I ask:

• Did patients get injured in this debacle? If they did, are the records sealed? We may never know.

• Has DMC truly learned the lessons of 2003 fully, or do similar problems continue?

• Were the executives responsible for this failure held accountable in any meaningful fashion?
  

Finally - and this is my major point - how many organizations in 2010 and beyond are similarly stuck in the stone age regarding how to "do health IT well"?

I believe the answer is "far too many."

-- SS

Cerner's Blitzkrieg on London: Where's the RAF?

In the Battle of Britain in WW2, the Royal Air Force (RAF) heroically repelled a foreign invasion of the UK.

The Supermarine Spitfire, key defense tool in the Battle of Britain. (Worked without major glitches.)

Now, the invasion is American, and the battlefield is healthcare...

I have often said health IT remains an experimental technology. However, the technology is being inexplicably force-fed with a vengeance to hospitals by IT companies and governments, force-fed with respect to the actual evidence of benefit.

In the case of the NPfIT in the UK, we have items such as those below from a 2009 government report "The National Programme for IT in the NHS: Progress since 2006 - Public Accounts Committee." Emphases in italics mine:

The termination of Fujitsu's contract has caused uncertainty among Trusts in the South and new deployments have stopped. One option being considered for new deployments is for Trusts to have a choice of either Lorenzo provided through CSC or the [Cerner, an American company - ed.] Millennium system provided through BT. There are, however, considerable problems with existing deployments of Millennium and serious concerns about the prospects for future deployments of Lorenzo. Before the new arrangements for the South are finalised, the Department should assess whether it would be wise for Trusts in the South to adopt these systems. Should either of the Local Service Providers take on additional commitments relating to the South, the Department should take particular care to assess the implications of the extra workload for the quality of services to Trusts in the Local Service Providers' existing areas of responsibility.

The Programme is not providing value for money at present because there have been few successful deployments of the [Cerner] Millennium system and none of Lorenzo in any Acute Trust. Trusts cannot be expected to take on the burden of deploying care records systems that do not work effectively. Unless the position on care records system deployments improves appreciably in the very near future (i.e. within the next six months), the Department should assess the financial case for allowing Trusts to put forward applications for central funding for alternative systems compatible with the objectives of the Programme.

In 2010 Londoners continue to be used as cannon fodder for the health IT experiment, which continues to rain IT bombs down upon them. The result?

Mayhem:

St George’s suffers Cerner teething pain
E-Health Insider
Jon Hoeksma
26 Aug 2010

St George’s Healthcare NHS Trust is facing teething problems with its installation of a Cerner Millennium hospital information system.

"Teething" problems? As if to imply problems with health IT are as minor as an infant's dental discomfort? That's some spin:

Health IT problems? Just baby issues; nothing a good cry can't solve ...

(The health IT baby must have serious endocrinological problems. Even after decades, it never seems to grow up, and is forever teething.)

The spin and excuses surrounding the health IT industry are simply nauseating, considering it's people's lives that are being screwed with.

Let's translate to everyday language: the project has been a disaster.

... The trust went live with the Millennium in March, under a new local delivery model from local service provider BT.

Five months later, the trust, which is one of the largest in London, has had to second additional senior management expertise into the project team and institute an additional programme of workflow changes and training.

The trust says the new system is creating difficulties in tracking patient notes in some areas and in managing outpatient appointments; creating backlogs of work that have required extra staff to deal with.

Health IT is touted as improving clinician-clinician communication. Allow me to translate "difficulties in tracking patient notes." In King's English (as opposed to health IT political-ese and other mumbo-jumbo), this translates to "patient notes are getting lost."

That means that health IT is obstructing patient care. I'm sure the patients didn't consent to the use of unproven technology that could get them killed.

Health IT is also the supposed cure to healthcare's financial and staffing woes:

They have also had a knock-on effect on the trust’s ability to meet and report on activity. Sources familiar with the implementation say the trust was fortunate that the coalition government dropped the national requirement to meet 18-week referral to treatment time targets in the revised NHS operating framework.

The problems are understood to mainly relate to staff finding it difficult to adjust to new processes and to using the unfamiliar Cerner system.

...“Since the programme deployed some staff have found it challenging to follow the new workflows. Therefore, where appropriate, we are simplifying processes by modifying workflows and administrative procedures.”

Translation: staff are finding it difficult to perform clinical-related work according to the capricious diktats of non-clinician health IT developers. In other words, they have difficulty being coerced to work for the computer, instead of the computer working for them.

The south London trust told E-Health Insider this week that the implementation was just the beginning of a major change programme; a project it calls iCLIP.

Only the beginning? God save the King....

“Although we successfully avoided some of the major pitfalls of other deployments, the new systems have presented some challenges to staff, particularly in relation to outpatient clinics and the tracking of case notes,” said chief operating officer Patrick Mitchell in a statement.

How major could those "major pitfalls" have been? Perhaps he means, the software actually runs and no longer crashes?

He added: “We have allocated additional temporary support while the new system and processes fully embed in these areas. A further programme of training and workflow changes are also underway as we continue to support staff and prepare for the next stages of the programme.”

"Temporary?" We'll see about that. Per the recent article "Electronic Medical Records, Nurse Staffing, and Nurse-Sensitive Patient Outcomes: Evidence from California Hospitals, 1998–2007" (Health Services Research, 9 APR 2010, DOI: 10.1111/j.1475-6773.2010.01110.x), on a longitudinal analysis of 326 short-term, general acute care hospitals in California:

... Our results suggest that advanced EMR applications may increase hospital costs and nurse staffing levels, as well as increase complications and decrease mortality for some conditions. Contrary to expectation [I'm not sure whose expectation, and on what basis - ed.], we found no support for the proposition that EMR reduced length of stay or decreased the demand for nurses.

On to the issues of skills:

Julia Crawshaw, the general manager for maternity services, has now been seconded into the project team “to lead on the work looking at optimisation of workflows, operational procedures and further training.”

Will this GM for maternity be looking at workflows in, for example, neurosurgery?

The problems now being addressed occurred despite 1,600 staff being comprehensively trained prior to go-live.

"Comprehensively?" What does that mean, exactly? The results seem to belie that assertion. Or are these systems and their user experience so ill conceived, tedious, cryptic and complex that no amount of "training" is adequate? (I believe the latter.)

However, Mitchell stressed that thanks to the hard work of staff, the new information system is delivering benefits, including “real-time reporting in the A&E department and more complete monitoring of bed occupancy.”

How many millions of pounds and person-years were spent to achieve these startling results, I wonder?

Mitchell said: “Reporting in real-time requires that staff report more promptly and accurately so additional training needs are also being identified to help individual staff become more comfortable with the system.”

Perhaps the system - and its designers - should be "trained" to be more comfortable with the users?

A spokesperson for BT told EHI: “Obviously these are operational issues the trust is dealing with. It is not for BT to comment. But you would expect that on a major deployment programme of this scale there would be issues.”

This is a classic appeal to common practice. Such "issues" might be tolerable for inventory systems of widgets (perhaps Cadbury Schweppes products?), but no, in mission critical areas I would not "expect" problems such as lost clinical notes.

In the most recent trust newsletter, the chief executive said: “I do fully appreciate that iCLIP has been far from smooth sailing. However, all major projects have their ups and downs and I know that many colleagues are focused on the long-term success of this important project.”

More spin and appeal to common practice.

This voyage was smooth sailing, until a little glitch was encountered...

"Far from smooth sailing?" Why does the HMS Titanic come to mind?

... The next trust due to go live with Millennium in London is meant to be Imperial, scheduled to take the system in 2011, under Cerner’s Method M delivery model.

"Method M delivery model"? How many "models" does it take to implement information systems in mission critical healthcare environments?

In summary, the NPfIT, already by the government's admission a multi-billion pound debacle, continues to drag on. Patients and hospital workers are the fodder for this experiment, spearheaded this time by an American invasion.

The Blitz is on.

Unfortunately, this time there's no RAF in sight to repel the foreign invasion.

The upside down world of commercial health IT. Is healthcare in St. George's Trust being incernerated?

-- SS

Are computers in medicine narcotic? "Why did the National Programme for IT fail?"

I noted an article Why did the National Programme for IT fail? by an "ex-IT person" at the site Smart Healthcare.com in a series entitled "Patient from Hell."

Aside from the intoxicant qualities of crisp bank notes, I am beginning to suspect that computers exert a narcotic effect, like Kool Aid laced with morphine or alcohol, on many in the population.

Many people who should know better of the challenges, dangers and myths surrounding these tools are drawn in to comparisons and analogies that I would charitably call magical thinking and puerile - and absurdist and stupid when not so charitable.

This article shows the muddled thinking behind the health IT mania. My observation: when you see the word "revolutionary" in the same paragraph as health IT you're dealing with hysterics.

The "patient from hell" asks:

Why is the road to electronic healthcare so much more rocky than computerising other bits of the economy? Other professions, including bankers, accountants and lawyers, have made the jump, some 30 years after the advent of personal computers. Even musicians, poets, journalists, artists, philosophers and MPs have got up to speed.

"Even?"

Yes, and you can train a dog to fetch a stick, therefore you can train a potato to dance.

Why is the road to HIT more rocky than the road to computer poetry or art?

Perhaps because the endeavors of clinicians are not like those of a musician or poet or lawyer or banker, but just a bit more informationally, operationally, cognitively, scientifically, and socially complex?

I was amazed at the time by the irresponsibility, primarily of the consultants [i.e., physicians - ed.], who were effectively opting out of the planning process. They showed no interest in playing a part in designing a new way of working – for themselves, for nurses and all others involved in the revolutionary changes which digitalisation would bring to their working practices.

In fact, they were showing responsibility - to patients - in not being so eager to "change to new ways of working" according to the diktats of computer geeks, government and other bureaucrats and myriad non-clinicians running around like drunks, hysterically screaming "revolution!"

I fear that communication between clinician and IT has now got so contaminated that crazy solutions will come out of the deliberations of the coalition government on the future of IT in the health service. All I ask is that clinicians and IT people talk to each other. Is that so hard?

If you have the right tools on your kitchen table, shouldn't it be easy to generate nuclear fission at home?

Due to factors such as the asymmetry in responsibilities, obligations and liabilities between the two fields, of differences in knowledge and expertise, and in mindset and qualifications to attain privileges to intervene in people's lives (who qualifies IT personnel to be involved in clinical affairs?), yes, idealistic "let's all play nice in the sandbox together" dreams are "so hard."

Unfortunately, these types of comparisons and sentiments are extremely common in the Healthcare-IT-industrial complex.

The reality is:

The NPfIT failed because its purveyors and promoters hadn't a clue about the complexities and wicked problems involved in such an endeavor, problems known and described in the Medical Informatics and Social Informatics literature, among others, for decades.

It also failed because of collective ignorance of these domains among its leaders, and among those who chose the leaders. For instance, as I wrote here:

The Department of Health has announced the two long-awaited senior management appointments for the National Programme for IT ... The Department announced in February that it was recruiting the two positions as part of a revised governance structure for handling informatics in the Department of Health.

Christine Connelly will be the first Chief Information Officer for Health and will focus on developing and delivering the Department's overall information strategy and integrating leadership across the NHS and associated bodies including NHS Connecting for Health and the NHS Information Centre for Health and Social Care.Christine Connelly was previously Chief Information Officer at Cadbury Schweppes with direct control of all IT operations and projects. She also spent over 20 years at BP where her roles included Chief of Staff for Gas, Power and Renewables, and Head of IT for both the upstream and downstream business.

Martin Bellamy will be the Director of Programme and System Delivery. He will lead NHS Connecting for Health and focus on enhancing partnerships with and within the NHS. Martin Bellamy has worked for the Department for Work and Pensions since 2003. His main role has been as CIO of the Pension Service.

Excuse me. Cadbury Schweppes (candy and drink?) The Pension Service? As national leaders for healthcare IT?

Instead of sobriety, attitudes about health IT seem to universally be "sure, the experts think you shouldn’t ride a bicycle into the eye of a hurricane, but we have our own theories." (See here and here.)

The domain of health IT needs a very stiff period of detox and rock-solid sobriety before it can achieve the (non-revolutionary) benefits of which it is capable.

-- SS

EPIC's outrageous recommendations on healthcare IT project staffing

"Critical thinking always, or your patient's dead" - Victor Satinsky, MD, NSF-funded summer science training program (SSTP) for high school students, Hahnemann Medical College, early 1970's.

Health IT projects are incredibly complex undertakings in equally complex, mission-critical medical environments. They are definitely not an area for novices.

From conception to design to implementation, faulty systems can endanger patients.

Further, one astute author of an article entitled "Faulty Construction" in the journal ForTheRecord.com (link) observes that:

Critics wonder what good it is to invest in EHR technology if it fails to engender itself to users who feel betrayed by its lack of intuitiveness.

Inexperience is a critical factor in creating and implementing HIT that "betrays" users in many ways (see, for example, here on mission hostile HIT).

With these issues in mind, here is how the major HIT vendor, EPIC, recommends hospitals staff their clinical IT projects. It also follows that they staff their own development teams in the same manner.

The recommendations are largely outrageous, especially in the context of medical environments where uninformed, unconsenting patients are subjected to IT experimentation in clinical matters.

From this link at the "Histalk" site on staffing of health IT projects, Aug. 16, 2010. Emphases mine:

Epic Staffing Guide

A reader sent over a copy of the staffing guide that Epic provides to its customers. I thought it was interesting, first and foremost in that Epic is so specific in its implementation plan that it sends customers an 18-page document on how staff their part of the project.

Epic emphasizes that many hospitals can staff their projects internally, choosing people who know the organization. However, they emphasize choosing the best and brightest, not those with time to spare. Epic advocates the same approach it takes in its own hiring: don’t worry about relevant experience, choose people with the right traits, qualities, and skills, they say.

The guide suggests hiring recent college graduates for analyst roles. Ability is more important than experience, it says. That includes reviewing a candidate’s college GPA and standardized test scores.

I bet many readers were taught by their HR departments to do behavioral interviewing, i.e. “Tell me about a time when you …” Epic says that’s crap, suggesting instead that candidates be given scenarios and asked how they would respond. They also say that interviews are not predictive of work quality since some people just interview well.

Don’t just hire the agreeable candidate, the guide says, since it may take someone annoying to push a project along or to ask the hard but important questions that all the suck-ups will avoid.

Epic likes giving candidates tests, particularly those of the logic variety.

While there's some good here, the part about "not worrying about relevant experience" and about "hiring recent college graduates as HIT project analysts" is downright frightening.

Medical environments and clinical affairs are not playgrounds for novices, no matter how "smart" their grades and test scores show them to be, and these practices as described, in my view, represent faulty and dangerous advice.

The advice also is at odds with the taxonomy of skills published by the Office of the National Coordinator I outlined at the post "ONC Defines a Taxonomy of Robust Healthcare IT Leadership."

One wonders if these recommendations are simply the idiosyncratic opinions of EPIC's leadership. They certainly deviate wildly from medicine's culture (e.g., of rigorous domain-specific training, and certification where the test cannot even be taken without prerequisite, very specific experience).

One could also look at these recommendations from an economic perspective. The word "cheap" and a corollary concept, "age discrimination" come to mind regarding a stated preference for recent graduates over experienced personnel.

Finally, from a personal perspective, my grades and test results out of college were very high. Yet the ‘modern me’ (after medical, IT and informatics education and hard earned experience) knows I would not have wanted the ‘young me’ to have been involved in critical clinical IT functions on that basis.

-- SS