On Hypervigilance Due to Bad Health IT: "Texting While Doctoring: A Patient Safety Hazard"

An Opinion piece "Texting While Doctoring: A Patient Safety Hazard" appeared in the Annals of Internal Medicine of 3 December 2013, authored by Christine A. Sinsky, MD and John W. Beasley, MD.  Dr. Sinsky is known to me to be what some would call a "heatlhcare IT iconoclast" (more accurately represented by the term "healthcare IT gadfly/realist" IMO).

In the piece the authors comment on the distractions caused by the technology, leading to doctors missing important cues in the exam room and to and impaired problem-solving.  This is part of a larger phenomenon that has been called "skill-degrading" or "de-skilling", e.g., see my April 16, 2010 post "Health Information Technology Basics From Calif. Nurses Association and National Nurses Organizing Committee" at http://hcrenewal.blogspot.com/2010/04/health-information-technology-basics.html).  

These effects are likely to be further worsened as more and more clerical tasks such as order entry, the authors point out, get shifted to medical professionals.  To new readers: note that computerized order entry is often a complex and convoluted process; the CPOE systems are most decidedly NOT mere "typewriters for orders."  See, for instance, part 6 of my series on "Mission-hostile health IT" at http://hcrenewal.blogspot.com/2009/02/it-makes-healthcare-easier-is-this.html.

Most of the Annals article is available as a free preview at http://annals.org/article.aspx?articleid=1784295 as of this writing and is worth reviewing.

Article preview, click to enlarge

I found one passage in particular striking, though.  In my ongoing discussions with computer scientist/informaticist/polymath Dr. Jon Patrick at U. Sydney (http://www.healthll.com.au/?page_id=440) , the issue of hypervigilance necessitated by bad health IT came up, and we arrived at the definition of same seen at my teaching site at http://cci.drexel.edu/faculty/ssilverstein/cases/:

Bad Health IT ("BHIT") is defined as IT that is ill-suited to purpose, hard to use, unreliable, loses data or provides incorrect data, is difficult and/or prohibitively expensive to customize to the needs of different medical specialists and subspecialists, causes cognitive overload, slows rather than facilitates users, lacks appropriate alerts, creates the need for hypervigilance (i.e., towards avoiding IT-related mishaps) that increases stress, is lacking in security, compromises patient privacy or otherwise demonstrates suboptimal design and/or implementation. 

Note this passage in Dr. Sinsky and Beasley's opinion piece:

"I am always multitasking ... I am entering orders, checking labs, downloading information while I talk to the patient.  It requires chronic hypervigilance, which is exhausting and demands conscious effort to stay in the 'present' with the patient" (Day S., Personal communication.)  Click to enlarge.

I don't know if Dr. Day had seen my materials, but I suspect the exhausting hypervigilance is all too common, just not much publicized due to the secretive, closed, retaliatory-towards-whistleblowers nature of the healthcare IT sector.

I ask:  is this what we really want, in pursuit of some uncertain cybernetic miracle?

I note that the healthcare IT experiment (and the technology is experimental), long usurped from the Medical Informatics pioneers who trained me and put in the hands of commercial interests and those of a mercantile/manufacturing/management computing background, is increasingly a failure.

-- SS

Wisdom from the Medical Journal of Oz: "Good HIT and bad HIT"

The recognition and partitioning of "good health IT" from "bad health IT" is now a mainstream meme.  I have few comments about this new article; it reflects views frequently expressed here at Healthcare Renewal (indeed, one of its references is to this blog and this author):

Good HIT and bad HIT
Jon D Patrick and Susan Ieraci
Medical Journal of Australia 2013; 198 (4): 205.

First and foremost, do no harm. Second, do some good

One of the key issues for high-volume, high-risk workplaces like hospital emergency departments (EDs) is the struggle of conflicting aims. While hospital managers need information systems for data collection and storage, clinicians need efficient clinical documentation, data retrieval and order-entry systems that save time rather than steal it from the patient. The work of clinicians is aided by reliable data but impaired by the delays of real-time input, difficult system navigation, suboptimal presentation of information, and other problems in the user experience of health information technology (HIT).1

Mohan and colleagues’ study of the impact of an electronic medical record information system on ED performance had some limitations.2 It was retrospective and unable to control for all confounders, and therefore could only show a correlation with ED delays, not causation. However, the premise for the study delivers an important message — the work required to use the information system was perceived by the ED staff to directly conflict with time spent with patients.

Another study has shown that the same electronic medical record information system is perceived to have had a negative impact on the care of patients, as well as the productivity and morale of staff, in six EDs in New South Wales.3 The need to be hypervigilant about the accuracy of the information supplied by the electronic health record compounds an already stressful clinical environment, which in turn leads to resentment towards the technology and the people who have imposed it. This makes it “bad” HIT. Unless this is corrected, HIT efforts will overuse precious health care resources, will be unlikely to achieve claimed benefits for many years to come, and may actually cause harm.4,5

The large HIT corporations produce a type of technology that is best categorised as enterprise resource planning (ERP), which has its roots in the manufacturing industry. It is based on the idea that all processes within an organisation can be standardised, and that all processes of the same type should have their information modelled and processed in the same manner. If this high degree of standardisation were considered the best way to process and model information derived from clinical activity, then ERP would be a favoured technology to adopt, as has happened in many places.

However, there is an alternative, almost contradictory, perspective on the nature of clinical work: that it is non-deterministic and performed by a group of diverse staff working in an ecologically stable network of people that has to respond to diverse medical needs and diseases. The ecology model accommodates staff joining and leaving the process, with differing needs emerging at different times, so that the other individuals in the network have to adapt and modify their behaviour and improvise in an unpredictable manner. Amid all this variability is the ever-demanding imperative to improve the processes of care and attention to the patient, while also increasing staff productivity.6

Where the ERP model has been imposed in the clinical setting, staff may be coerced into an approach to their work that is at odds with established best practices. This could only be considered “good” HIT if it brought greater staff productivity with at least no loss (and, preferably, improvement) of patient safety and services and staff morale.

It is not enough just to identify problems: effort must be invested in transforming bad HIT into good HIT. This process must identify and optimise all the operative factors: human behaviour, system design, equipment performance, skills of the IT participants, and the operational policy framework.7 Good HIT should include clinician control of the interface design for content, dataflow and workflow. It includes the ability to change the system in real time, and it incorporates inbuilt data analytical capability, natural language processing, and native interoperability and clinical coding.8 Finally, there must be an appropriate opportunity to test systems for useability, effectiveness and suitability before their release.

There must be a move away from standardised processing models and towards improving the user experience in the clinical setting. Clinicians should not have to shoehorn their activity into predefined, externally imposed work processes that do not reflect actual activity and will not improve efficiency. A true patient-focused system aligns all its components towards the same aim. Like a good clinician, good HIT does no harm — to patients or staff.

American medical / HIT journals are perhaps a bit too beholden to industry to directly commit such health IT heresy.  Thank the stars those Down Under are a bit more bold.

-- SS

Michael Millenson and "the adamant refusal by hospitals and doctors to adopt electronic records no matter what the evidence"

Over at Health Beat by Maggie Mahar appears a piece critical of NYT reporter Julie Creswell's Feb. 20, 2013 article "A Digital Shift on Health Data Swells Profits in an Industry."  (The piece was also cross-posted at The Health Care Blog.)  There have been several responses highly critical of the NYT article recently in various venues.

The Health Beat piece "The Health IT Scandal the NY Times Didn’t Cover" is by Michael L. Millenson, president of Health Quality Advisors LLC in Highland Park, IL, and the author of the critically acclaimed book, Demanding Medical Excellence: Doctors and Accountability in the Information Age published in 2000.

I bought and read that book at the time.

The posting at Health Beat contains the following statement:

The actual scandal is more complicated and scary. It has to do with the adamant refusal by hospitals and doctors to adopt electronic records no matter what the evidence. 

I am profoundly disappointed by this statement in view of issues (frequently written about here and elsewhere) such as:

• The conflicting literature by credible and responsible parties on health IT's real-world value and risks as it exists today;  
• Fiduciary obligations of hospital executives to maintain safe operating conditions; 
• Legal and ethical obligations of physicians to resist technology they find or believe harmful without rigorous proof of its beneficence and efficacy (which includes the absence of major evidence conflicts); 
• The evidence of major and frequent flaws, bugs and "glitches", some of which are alarming;

not to mention:

• The 500+ reader comments in response to Creswell's article, many by clinicians describing why they don't like today's health IT; 
• Examples of unintended adverse consequences such as here (plus at least 5 other IT-related crippling injuries and/or deaths of infants I know of but cannot speak about), and here, and here;
• Other factors as at this blog and at my teaching site here.

I am trying to find a polite term for the statement, and struggling to do so in view of the author's prior work, which I admired.

The statement really is saying:

... It [the "scandal"] has to do with the adamant refusal by hospitals and doctors to adopt electronic records no matter what the evidence ... which is all exceptionally robust and positive, leaving no room whatsoever for reasonable doubt or caution.

Regrettably, here is the most polite term I can come up with describing the statement:

Preposterous.

If anyone takes offense to that term, please suggest a more precise one.

Perhaps a book needs to be written entitled "Demanding Information Technology Excellence: Health IT and Accountability in the Information Age."

-- SS

Mar. 4, 2013 addendum:

In a response to a reader's comment to the cross-posting of this piece at The Health Care Blog (link), Millenson responds:

"platon20: my point, that EMRs were available in the 1970s but never changed their interface because doctors never cared enough to demand it, is not refuted by your argument, but confirmed."

This is bizarre and inconsistent with my experience and that of other Chief Medical Informatics Officers I've mentored or spoken with.  Since my entry into the domain of Medical Informatics 21 years ago I've heard many physicians, myself included [1], demand that health IT sellers and/or hospital IT departments "improve the user interface", among other areas for improvement. 

Based on my own observations and that of others (e.g., via reader comments at my teaching site dating to at least 1999), these pleas have often fallen on the deaf - and in some cases ill-informed and/or incompetent - ears of hospital senior and IT executives and industry pundits.  The latter have often responded by accusing the physicians of being "Luddites" or technophobes, and the advocates for change such as myself "anti-health IT."

The most stunning example regarding this phenomenon is the industry pushback against Prof. Jon Patrick at U. Sydney, and the ignoring of his work (on both the user experience and the fundamental software engineering quality) sitting on a University server for several years now, regarding a major U.S. ED EHR slated for rollout in an entire state of Australia.  

With usability issues now being forced of the industry for reconsideration by HHS via NIST, the industry response has been to claim that "usability is in the eye of the beholder" and other frivolous claims, up to and including interference in the the public comments period on Meaningful Use via ghostwriting, and possibly outrageous statements (although that issue became anechoic), to get their way, which is to do little or nothing on that score.

I remind Millenson that "improving the user experience" of health IT cuts into the bottom line.

[1] e.g.,  in a project initiated 20 years ago by the clinicians themselves - in a critical care area no less - in which I had to take over through force of will from the hospital's own IT department and COO and  re-engineer not just the commercial user interface but the entire dataset itself.  The project ultimately proved successful after my intervention, but the mid-level executive who facilitated my takeover to do that, and I, were punished by our superiors for our efforts.

-- SS

Guest post by Dr. Jon Patrick, U. of Sydney: On the ECRI Institute's recommendations following a "deep-dive" study of HIT-related events

At my Feb. 9, 2013 post "ECRI Institute PSO Uncovers Health Information Technology-Related Events in Deep Dive Analysis", I wrote about an ECRI Institute study of well-defined client data submitted over a 9-week period (a "deep dive" study) on EHR problems.  Risk-creating events at a level that should be a significant concern to patients and clinicians fell into the following categories: 

• inadequate data transfer from one HIT system to another 
• data entry in the wrong patient record
• incorrect data entry in the patient record
• failure of the HIT system to function as intended 
• configuration of the system in a way that can lead to mistakes

Dr. Jon Patrick at U. Sydney, a scientist and medical informatician who sees the issues from a number of unique perspectives (link to bio), has offered the following critique of the key recommendations made by the ECRI Institute as a result of this study of health IT events (see aforementioned post for the text of those recommendations). 

One caveat is that neither he nor I have the full report as of this writing in part due to expense:

The ECRI has produced a report on HIT errors. I was concerned about the manner in which the Key Recommendations minimised, generalised or failed to concretise important issues that I offer these comments.

On ECRI Key Recommendations:

1. Enlist leaders’ commitment and support for the organization’s health IT projects.

JP: This is clearly a comment from one level of  management to those levels above it. It doesn't seem to be a comment about the nature of the HIT itself but more about the internal processes to getting it established. There is really not much to say here because if upper management don't want to do anything about the introduction of HIT then engaging in the task is probably futile, hence it was difficult to understand why it was included.

2. Involve health IT users in system planning, design, and selection.

JP: yes, this is crucial to successful solutions.

3. Conduct a review of workflow and processes to determine how they must be modified.

JP: the missing clause at the end of this sentence is "to fit the introduced HIT system". This is putting the cart before the horse. The notion that a piece of software designed by engineers should have priority over the team of clinicians who are experts in their business is highly naive. Also this statement is in contradiction to point 2 above.

The privileging of the functioning of  the IT system as the expert over that of the clinical team, AND making a recommendation in contradiction to an earlier recommendation is absurd enough by itself  to undermine the credibility of  the report.

4. Evaluate the ability of existing IT systems within the organization to reliably exchange data with any health IT system under consideration.

JP: And after the evaluation what should be done. This is hardly an informative recommendation. It is of the form "Do Something, it doesn't matter what you do, just do something."  A more compelling statement that would have enhanced the credibility of the authors and demonstrate their knowledge of the industry would have been: " Establish unambiguously and conclusively that any health IT system under consideration has the ability to reliably exchange data with existing IT systems within the organization". Note the focus needs to be on the incoming system being the object of conformity not the incumbent systems.

5. Conduct extensive tests before full implementation to ensure that the health IT system operates as expected.

JP: this is a clearly a desirable goal and applies to point 4 above as well as all other aspects of the system functions.

6. Provide user training and ongoing support; educate users about the capabilities and limitations of the system.

JP: This is a motherhood statement that does nothing to contribute to the nub of training issues in the use of HIT. Training is an ongoing issue for two reasons: staff change and new staff come on to the roster and need to be trained, and, these systems are complex and expert advice and skill needs to be available to staff as an ongoing service so that work is not delayed due to confusion on how to use the IT. An alternative proposal to reduce training costs and investment would be to design the system so that it matches current best practice of the clinical team so that learning the system is minimised because it fits seamlessly into their work processes.

Surely the issue of educating users about the capabilities and limitations of the system is independent of the training topic. The users will discover on their own bat the limitations of the system as they try to use it.

7. Closely monitor the system’s ease of use and promptly address problems encountered by users.

JP:This is a quite inadequate description of the action that needs to be taken. The real consideration is for them to have an effective avenue for expressing the limitations in a manner that is acceptable and they are NOT chastised as malcontents [or Luddites or technophobes - ed.] AND that the unnecessary or dangerous limitations are addressed promptly.

8. Introduce alterations to a health IT system in a controlled manner.

JP: It is hard to understand what is meant by this statement. Firstly I would have said "introduce alterations to the clinical processes  in a controlled manner". Secondly, alterations to the HIT system need to be done promptly  when it is defective. Once again, as in point 3 above the technology is being preferenced over the clinical processes which I argue is back-to-front.

9. Monitor the system’s effectiveness with metrics established by the organization.

JP: This is definitely something that should be done but it also needs a more directed purpose. It is easy to say to assess patient safety but most systems don't readily capture relevant data or supply analytical devises to easily draw a picture of patient  safety. However there is an equally important factor in care that is often overlooked and that is staff productivity and by implication morale. There is a need to understand better ways of assessing staff productivity in positive ways and the effect a CIS has on staff morale.  Typical comments about CISs is that they cost staff  up to 20% more time to maintain the patient record. Staff wouldn't mind giving up that time if it was returned in some other form, but it isn't, so they feel the time is stolen from them or from their patients.

10. Require reporting of health IT- related events and near misses.

JP: This is poorly stated and is probably meant to read "health IT - related adverse events". This is a positive recommendation but does not go far enough. A more comprehensive statement would be "Install a process and technology for reporting adverse events and establish methods for evaluating the reports and recommending changes to clinical practice, or technology functionality and implementing them.

11. Conduct thorough event analysis and investigation to identify corrective measures.

JP: This  goes some way to dealing with my point in item 10 above. Its weakness is in not identifying the types of problems and taking a firm stance on completing the correct action.

SOME of the Items that have been OVERLOOKED

1. The system needs to be alterable at any time by the clinical leadership so as to immediately emplace revised work practices when they are approved.

2. The system needs to have native analytics so that the clinical leadership can monitor the activities of their teams and provide evidenced based feedback to support continuous process improvement.

3. The system needs highly accurate natural language processing so that the search for required content though the clinical record can be fast, efficient and reliable.

Professor Jon Patrick
Chair of Language Technology
School of Information Technologies
Faculty of Engineering
University of Sydney
Health Information Technologies Research Laboratory

http://www.it.usyd.edu.au/~hitru

This is excellent advice coming from perhaps the only computing expert in the world who's conducted a forensic analysis of a major commercial EHR product, one intended for high-risk ED's.  His analysis of that product, intended for government-mandated rollout in public hospitals in Dr. Patrick's Australian state of New South Wales, is at this link.

This work has largely been ignored by the health IT industry and the academic Medical Informatics community.  However, I can assure the industry and the academic community that the report will not be ignored by those in the legal community if (perhaps I should say when) patients are injured or killed by the system's deficiencies.

-- SS