IMO: Tell me a bit about the book
Eric Rose: H.I.T. or Miss is a set of case histories about health IT projects that didn’t go as planned. So, everything from issues that were really technical at their heart, to issues around training or around how a system was implemented. For each case, there is a brief history of what happened followed by commentary from the author about the root causes behind the failure or unanticipated consequences of the project. This is followed by a commentary from an editor who wasn’t involved in the project but has extensive experience in similar work.
All of the cases in the book are real cases—true stories. And they come from a broad swath of healthcare. Everything from high acuity inpatient environments to ambulatory, long term care and home care; all the way from very large multi-state organizations down to small private physician practices.
IMO: How did the idea first come about?
E Rose: The book arose from a set of informal discussions [with] people who all believe that information technology can make healthcare better. At the same time, we clearly saw that many health IT projects don’t succeed, and that there is as much to learn from failure as success. There wasn’t a common [way] for projects not to succeed, so we started out with a very broad perspective on what failure meant, and also [with] a deep commitment to the idea that failures shouldn’t be swept under the rug.
Sometimes failure is very dramatic, with a project having to be canceled, or a system deinstalled, or a product never being brought to market. But failure can also take many other forms, such as people just not wanting to use [the technology], or it being used but having unanticipated and undesirable effects. We wanted to examine any situation where a health IT project didn’t fulfill the goals that were envisioned for it, however that played out.
IMO: Why is a book like this important?
E Rose: It’s important for two reasons. First and foremost, whatever you’re trying to do, unless you can identify how and why things go wrong, you can’t increase their chances of going right. In every field where high reliability and high performance have been achieved, there has been a willingness to carefully examine and learn from failure.
I think the other reason why it’s important is that it helps emphasize to those who are working in this field not to be too overconfident. To be aware that there’s a lot that can go wrong. Even though there’s a lot that can go right. And to have an appropriate degree of alertness and preparation for that.
IMO: Was it difficult to find participants?
E Rose: It wasn’t difficult at all. An open call for cases was put out through a number of avenues including the personal networks of all the editors and a lot of professional societies. We absolutely had no lack of people willing to share stories. Everyone who has worked in this field for a while has had projects that could have gone better, so there’s a lot of pent up enthusiasm from people who were relieved to have a way to tell their stories, and to analyze them a bit more closely than they might have previously done.
IMO: Can you talk about a couple of examples from the book? Were there any surprising or unexpected findings?
E Rose: One of the cases involved implementation of a new order entry system. This hospital had a legacy system very carefully tailored for the hospital’s pharmacists to ensure complex orders were entered correctly and without any omissions.
The new system involved electronic [instead of paper] order entry. This totally upended the experience from the pharmacists’ perspective and resulted in a serious slow down of pharmacy orders that actually required that the implementation be halted.
No one was harmed, but it was a very disruptive, expensive and frustrating experience for everyone involved. This case went on to describe [a] subsequent implementation that occurred several years later, which was informed by the prior failed implementation. [They] used the lessons they learned to get it better – to do more training, to keep in mind the entire flow of information [for] all user types. This case illustrates what can happen when there is too much focus on just one type of user – the physician – without thinking necessarily about the impact of the system on other professionals in the hospital, like in this case, pharmacists.
Some of the other cases have to do with the paradoxical problem of too much information. A big selling point of clinical information systems was the fact that in a paper-based world, information frequently is simply unavailable because a patient’s chart is missing. This requires clinicians to make important decisions in the absence of critical information. Now there is often the opposite problem.
One case describes a system that provided notifications to primary health physicians when their patients had some kind of care event at a hospital. It was intended to reflect really important events like when a person was seen at the emergency room or admitted to the hospital. But unfortunately, the system didn’t distinguish between the visits for things like routine laboratory work and being admitted to the ICU with a life-threatening illness. There was a lot of noise there.
IMO: What do you hope readers will take away from the book?
E Rose: First, a healthy respect for the fact that there are a lot of ways for health IT projects to not go right. Second, a feeling of encouragement that as a community, those of us working in this field are committed to and actively engaged in identifying and overcoming the challenges that lead to that reality. And third, I hope readers are energized to get involved, to take the lessons from the book and apply them to their own organizations to help ensure optimal outcomes.